Midjourney n'a pas d'API publique universelle, ce qui détermine la structure réelle des « relais » et « proxys » : ils ne se contentent pas de changer de domaine sur une interface officielle, ils ajoutent une couche d'orchestration de tâches et de facturation au-dessus d'un pool de comptes tiers. La chaîne est plus longue qu'une API de texte, et les points de défaillance plus nombreux.

Cet article part de la chaîne réelle pour expliquer les états de tâche, la conservation des résultats, le rapprochement de facturation, les risques liés aux clés et aux comptes, les conditions du fournisseur, puis la migration et la recette.

Remarque : Midjourney est une marque de Midjourney, Inc. ; les autres noms de produits cités sont des marques de leurs détenteurs. Cet article est purement technique et n'implique aucune affiliation ni coopération avec Midjourney ; l'interface, les états et la facturation d'un relais font foi dans la documentation et le contrat du fournisseur. Ce texte ne constitue pas un avis juridique.

1. Distinguer d'abord quatre types de « relais »

Type Rôle Risque principal Cas d'usage
Proxy à pool de comptes Le fournisseur maintient des comptes Midjourney et soumet automatiquement Contrôle des comptes, file d'attente, conditions PME ayant besoin d'une forme d'API
Passerelle agrégatrice Point d'entrée unique vers plusieurs modèles d'image Mapping d'états, écarts de paramètres, panne de la couche intermédiaire Activité multi-modèles
Revente / recharge Revente d'abonnements ou de quotas Stabilité amont, solde et remboursement Essai de petit volume, besoin ponctuel
Automatisation interne Vous maintenez comptes et scripts de soumission Exploitation, fermeture de compte, responsabilité totale Équipe technique voulant maîtriser les données

Ce que vous achetez — un « service technique » ou un « quota de modèle » — détermine qui répond en cas de problème. Interrogez le contrat, la facture et les clauses de données selon cette distinction.

2. Les étapes supplémentaires d'une tâche asynchrone dans un relais

Une chaîne typique : votre service soumet une requête ; le relais authentifie, limite et débite ; il enregistre en base une correspondance entre numéro métier et ID de tâche amont ; le pool de comptes soumet en file et attend la génération ; le relais interroge ou reçoit le résultat et effectue le mapping d'état ; enfin il transfère l'image ou transmet un lien temporaire.

Chaque saut supplémentaire crée un endroit où l'état peut se perdre :

  • Le relais redémarre ou change d'instance et la correspondance des tâches en mémoire disparaît.
  • L'amont expire mais la tâche a déjà été créée ; le relais renvoie un échec et l'appelant, en réessayant, obtient deux images.
  • Un refus de modération est mappé en échec ordinaire et l'activité réessaie en boucle.
  • Le lien de résultat expire : la tâche indique un succès mais le téléchargement échoue.
  • Le webhook n'a pas de clé d'idempotence et l'activité enregistre deux fois le résultat.

Pour évaluer un relais, ne demandez pas seulement « supportez-vous Midjourney ? », mais comment l'ID de tâche est persisté, comment les états sont mappés et comment les échecs sont compensés.

3. États de tâche et conservation des résultats

Les états courants sont : en file, en génération, succès, échec, refus de modération, timeout ou expiré. Le nom importe peu ; ce qui compte est le mapping : l'activité doit distinguer « peut être réessayé » de « réessayer ne servira à rien ».

Un refus de modération, une erreur de paramètre et un solde insuffisant ne doivent pas être réessayés automatiquement ; un timeout et un 5xx peuvent l'être avec backoff ; un succès dont le téléchargement échoue exige une compensation séparée. Chaque tâche doit avoir une clé d'idempotence pour éviter double débit et double génération.

Quatre questions sur la conservation : combien de temps les enregistrements de tâche sont-ils conservés ; les images sont-elles stockées pour vous, et où ; le retour est-il un lien temporaire ou une adresse durable ; après expiration, peut-on encore retrouver la tâche par le numéro métier. Les liens d'image sont généralement temporaires : téléchargez et transférez dès le succès.

4. Vérifier la transparence de la facturation

La facturation des tâches d'image prête plus facilement à discussion, car une demande peut inclure imagine, upscale, variantes et tentatives. Avant de signer, confirmez :

  • L'unité est-elle la tâche, l'image réussie, ou une conversion de quota d'abonnement ?
  • L'upscale et les variantes sont-ils facturés séparément ?
  • Échec, timeout, annulation et refus de modération sont-ils facturés, et comment ?
  • Les soumissions en double et les tentatives sont-elles refacturées, avec déduplication idempotente ?
  • Existe-t-il un minimum de consommation, un seuil de prépaiement, des règles de remboursement et un type de facture ?
  • Le détail d'usage inclut-il l'ID de tâche, le type d'action, l'état et le montant débité ?

Ne regardez pas seulement la remise affichée. Faites tourner vingt à cinquante tâches réelles pendant une semaine et alignez le nombre d'images réussies, le nombre de tâches et la facture. En cas d'écart, exigez un détail par ID de tâche, pas seulement un total. Les coûts des autres modèles du site font foi sur la page Tarifs des modèles ; les prix évoluent avec l'amont.

5. Clés, comptes et risque amont

Un relais signifie que prompts, images de référence et images générées traversent un tiers. Vérifiez au minimum :

  • Les prompts et images sont-ils stockés, combien de temps, et utilisés pour l'entraînement ou l'amélioration du service ?
  • La clé peut-elle être limitée en quota, IP et durée, et comment est-elle bloquée en cas de fuite ?
  • L'amont est-il un pool unique ou plusieurs canaux, et comment basculer si un compte est fermé ?
  • Les conditions autorisent-elles l'accès automatisé et la revente, et où passe la frontière de responsabilité ?
  • En cas de litige de modération de contenu, qui gère la contestation et le remboursement ?

Ne placez jamais une clé de production dans un front-end, un dépôt public ou des logs. Pour les contenus très sensibles, privilégiez un fournisseur sans stockage et proposant un accord de données ; à défaut, masquez avant l'envoi.

6. Conditions du fournisseur et frontière de responsabilité

Un relais vend parfois un « service technique », parfois un « quota de modèle » ; la responsabilité diffère. Un prestataire technique doit répondre de la disponibilité, de la perte de tâches et des délais de réponse ; un revendeur de quota ne peut souvent promettre qu'un « transfert au mieux », et une évolution amont est difficile à compenser.

Le contrat devrait préciser : niveaux de service et notification d'incident, compensation des tâches échouées, préavis en cas de changement de règles amont, obligations de traitement et de suppression des données, export des données et sort du solde à la fin de la collaboration. N'acceptez pas une collaboration longue sans contrat, fondée uniquement sur un historique de chat.

7. Étapes d'une migration vers un relais

  1. Inventorier les appels existants : modèles, paramètres, concurrence, durée moyenne de génération et types d'échec.
  2. Vérifier les chemins, l'authentification et les différences de champs du relais, et établir une table de correspondance.
  3. Faire fonctionner en environnement de test les quatre parcours : soumission, consultation, annulation et téléchargement.
  4. Lancer une exécution miroir avec les mêmes prompts, une copie sur l'ancienne chaîne et une sur le relais, en comparant sans basculer.
  5. Comparer taux de réussite, temps d'attente, durée P95, taux de téléchargement et coût utile par image.
  6. Basculer progressivement 5 à 20 % du trafic, avec un interrupteur de retour à l'ancienne chaîne.
  7. Observer trois à sept jours et vérifier que facture, détail des tâches et numéros métier concordent.
  8. Après bascule complète, conserver quelque temps un canal de secours, puis simplifier l'architecture.

Pendant la migration, ne supprimez ni l'ancien compte ni l'ancienne clé, et n'écrivez pas les deux jeux de tâches sous le même numéro métier : le rapprochement deviendrait impossible.

8. Comment valider un relais

# Soumettre une tâche minimale et noter task_id et l'heure ; chemins et champs selon la documentation
curl -sS -X POST "$RELAY_BASE_URL/v1/images/generations" \
  -H "Authorization: Bearer $RELAY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"prompt":"un chat baille pres de la fenetre, lumiere naturelle","async":true}'

# Interroger l'etat et enregistrer le cycle complet
curl -sS "$RELAY_BASE_URL/v1/tasks/$TASK_ID" \
  -H "Authorization: Bearer $RELAY_API_KEY"

Pendant le test, provoquez des anomalies : annuler juste après la soumission, envoyer un mauvais paramètre, soumettre en concurrence, interrompre un téléchargement. Vérifiez la cohérence des états, des messages et de la facture. Revenez sur l'adresse du résultat vingt-quatre heures plus tard, puis consultez l'enregistrement de tâche après sept jours. Ce n'est qu'après avoir passé ces trois épreuves que le relais mérite un déploiement progressif.

9. Surveillance et retour après migration

  • Compter les tâches par état, en particulier la part d'échecs, de refus de modération, de timeouts et d'annulations.
  • Enregistrer séparément le temps d'attente et le temps de génération pour localiser le goulot : pool de comptes ou amont.
  • Surveiller le taux de téléchargement des images et placer les échecs dans une file de compensation.
  • Suivre les 401, 404, 429 et 5xx pour distinguer clé, paramètres, limitation et panne amont.
  • Calculer le coût « par tâche générée avec succès », pas seulement le prix d'un appel.
  • Définir un seuil de retour, par exemple revenir à l'ancienne chaîne si le taux de réussite reste nettement sous la référence pendant deux heures.

Questions fréquentes

Quelle différence entre un relais et un abonnement direct à Midjourney ?

L'abonnement direct est le produit officiel, destiné à l'usage manuel ; le relais est une encapsulation en forme d'API, pratique pour l'automatisation. Paramètres, concurrence et visibilité des tâches peuvent différer, et le relais supporte en plus le risque du pool de comptes et des conditions.

Le relais conserve-t-il mes prompts et mes images ?

Cela dépend du service. Demandez si les données sont stockées, combien de temps, où, qui y a accès, si elles servent à l'entraînement et comment fonctionne la suppression. Pour des contenus clients, privilégiez un fournisseur aux clauses claires.

Que faire si une tâche disparaît côté relais ?

Cherchez d'abord l'enregistrement local par numéro métier, puis les logs du relais et la tâche amont. Sans récupération possible, il faut resoumettre : vérifiez donc avant la migration que le relais persiste la correspondance des tâches.

Pourquoi la facture ne correspond-elle pas au nombre d'images ?

Causes fréquentes : soumissions en double, tentatives sur échec, facturation séparée des upscales et variantes, règles différentes pour les refus de modération, minimum de consommation ou solde expiré. Exigez un détail par ID de tâche et vérifiez ligne par ligne.

Faut-il modifier le code pour migrer ?

Si le relais est compatible avec l'interface existante, il suffit souvent de changer l'URL de base, la clé et quelques champs ; si le mapping d'états ou le format de callback diffère, il faut adapter le polling et l'écriture en base. Une exécution miroir révèle la plupart des écarts à l'avance.

Étape suivante

Créez d'abord une clé de test sur ZSQH AI Gateway, validez les quatre chaînes — soumission, polling, téléchargement et rapprochement — avec une tâche minimale, puis migrez progressivement ; les modèles disponibles et les coûts font foi sur la page Tarifs des modèles, et les prix peuvent évoluer.

À lire aussi :