Midjourney ne propose pas d'API publique officielle : l'intégration réelle vise généralement un service d'encapsulation tiers. Les chemins, champs et machines à états diffèrent d'un fournisseur à l'autre, mais le flux sous-jacent est proche : soumettre une tâche et obtenir un ID, interroger l'état, télécharger l'image en cas de succès, puis lancer si besoin un upscale ou une variante. Cet article suit cette chaîne, en insistant sur les différences qui posent problème et sur les limites de conformité.

Marques : Midjourney est une marque de Midjourney, Inc. ; Discord est une marque de Discord Inc. Cet article est purement technique et n'implique aucun partenariat, aucune représentation ni approbation. Midjourney ne fournit pas d'API officielle à ce jour ; les conditions et la stabilité des interfaces tierces doivent être vérifiées par vous-même.

1. Choisir le fournisseur avant d'écrire le code

Les interfaces Midjourney tierces n'ont pas de standard commun. Pour une même « soumission de tâche », l'une renvoie task_id, l'autre job_id ; l'une utilise /imagine, l'autre /v1/midjourney/imagine ; l'une fait de l'upscale et des variantes des tâches distinctes, l'autre des actions. Avant de choisir, vérifiez six points :

  • Le mode d'authentification et l'URL de base sont-ils stables, avec des chemins versionnés ?
  • Quels types de tâches sont pris en charge : texte-vers-image, upscale, variante, inpaint, blend, describe ?
  • Quels champs d'état et énumérations finales, avec distinction entre succès, échec, refus de modération et timeout ?
  • Combien de temps les résultats sont-ils conservés, quelles limites de téléchargement, les callbacks sont-ils pris en charge ?
  • Quelles règles de concurrence, de file et de limitation, et les échecs sont-ils facturés ?
  • Le fournisseur est-il durable, avec un mécanisme de sortie, des contrats courts et une suppression des données possible ?

Plus l'interface ressemble à votre système existant, plus la migration sera simple. Ne jugez pas sur la démo : lisez d'abord la documentation des codes d'erreur et les capacités d'interrogation des tâches.

2. Authentification et conventions de requête

La pratique courante place la clé API dans un en-tête, avec un corps JSON. Le nom exact de l'en-tête dépend du fournisseur : Authorization: Bearer, X-API-Key ou un en-tête personnalisé. Placez la clé, l'URL de base et le timeout dans la configuration, sans les disperser dans le code.

Avant l'appel, confirmez trois choses : l'environnement est-il de test ou de production, la clé est-elle liée à une IP ou à un quota, la requête passe-t-elle par le proxy de sortie de l'entreprise. Beaucoup de 401 et 403 ne viennent pas d'une mauvaise clé, mais d'un environnement mal configuré ou d'un proxy qui réécrit les en-têtes.

3. Soumettre une tâche : prompt et paramètres

Voici une requête de soumission typique ; les champs ne sont donnés qu'à titre d'exemple :

export MJ_API_KEY="votre-cle-fournisseur"
export MJ_BASE_URL="https://provider.example.com"

curl -sS -X POST "$MJ_BASE_URL/v1/midjourney/imagine" \
  -H "Authorization: Bearer $MJ_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "prompt": "photo produit minimaliste, tasse en ceramique, lumiere douce de fenetre --ar 4:3",
    "aspect_ratio": "4:3",
    "callback_url": "https://api.example.com/callbacks/mj"
  }'

Le passage direct des paramètres --ar, --v, --style du prompt varie selon les fournisseurs. Certains extraient le ratio dans un champ distinct, d'autres analysent le prompt ; ne supposez pas qu'un paramètre s'applique, vérifiez-le dans le détail de la tâche après soumission.

Dès que la soumission réussit, écrivez dans une table des tâches l'ID de tâche, le numéro métier, le prompt, les paramètres, l'heure de soumission et l'opérateur. Le polling, les tentatives, le rapprochement et l'imputation des coûts s'appuieront sur cet enregistrement.

4. Polling : machine à états et backoff

État Signification Traitement conseillé
queued En file Attendre, éviter les soumissions en double
running En génération Interroger avec une stratégie de backoff
succeeded Succès Lire le résultat et le transférer immédiatement
failed Échec Enregistrer le code, décider si une tentative est possible
moderated Refus de modération Modifier le prompt, ne pas réessayer à l'identique
expired Timeout ou lien expiré Consulter le détail, resoumettre si nécessaire

Commencez le polling après 3 à 5 secondes, puis augmentez progressivement jusqu'à 15 à 30 secondes, avec un timeout global. N'interrogez pas toutes les secondes et ne laissez pas plusieurs instances consulter la même tâche. Dès qu'un état final est atteint, arrêtez le polling et enregistrez l'état final et l'adresse du résultat en base.

Si le fournisseur propose des webhooks, ils peuvent servir de notification principale, mais il faut vérifier la signature, assurer l'idempotence et conserver un polling périodique de secours. La perte de callbacks est fréquente chez les services d'encapsulation.

5. Téléchargement et transfert

Les adresses d'images renvoyées après succès sont généralement temporaires : quelques minutes à quelques jours, parfois des URL signées éphémères. Ne les intégrez pas directement dans une page front-end et ne les livrez pas telles quelles au client.

L'ordre correct : dès réception du succès, téléchargez, transférez vers votre stockage objet, enregistrez l'ID de tâche, le chemin de l'objet, la taille du fichier, la somme de contrôle et l'heure de téléchargement, puis écrivez l'adresse interne dans la base métier. Le téléchargement doit avoir timeout, tentatives et limite de concurrence ; pour les grandes images, passez par un proxy serveur pour éviter les problèmes CORS et la fuite de liens.

Midjourney renvoie généralement une grille de quatre images plus l'image upscalée. Lors du transfert, nommez séparément la grille et l'upscale en conservant l'ID de tâche d'origine, afin de pouvoir associer plus tard variantes et inpaint.

6. Upscale, variantes et inpaint

L'upscale et les variantes dépendent généralement de l'ID de tâche d'origine et de l'index de l'image. L'appel courant consiste à soumettre une nouvelle tâche avec task_id et index, ou à appeler l'interface d'action du fournisseur. L'index commence à 1 ou à 0 selon les fournisseurs : vérifiez avec une tâche de test avant l'intégration.

Quelques recommandations :

  • Reliez la « tâche d'origine » et les « tâches dérivées » par une relation parent-enfant pour éviter d'upscaler deux fois la même image.
  • Une variante peut produire une nouvelle grille de quatre images, facturée comme une nouvelle tâche : estimez le coût avant un lancement en lot.
  • L'inpaint, l'inpaint local et le blend ne sont pas pris en charge partout ; la documentation fait foi.
  • L'image upscalée reste soumise à la durée de vie du lien amont : transférez-la dès le succès.

7. Limitation, concurrence et coût

Le débit d'un service d'encapsulation dépend de son pool de comptes et de sa file amont : acheter de la concurrence ne garantit pas de l'obtenir. Les limites courantes sont le nombre de tâches par minute, le nombre de tâches simultanées et le quota quotidien par compte. En cas de 429, réduisez la concurrence et appliquez un backoff exponentiel, sans réessayer aveuglément.

Le coût se calcule sur les « images livrées avec succès », pas sur les soumissions. Pour obtenir un coût réel par image, incluez dans le dénominateur les échecs, les refus de modération, les soumissions en double et les upscales de variantes. Lancez un petit lot, vérifiez le taux de réussite et la durée moyenne, puis augmentez progressivement.

8. Erreurs courantes et diagnostic

  • 401 : clé absente, mal formée, environnement incohérent ou compte amont invalide.
  • 403 : IP hors liste blanche, quota insuffisant, permission non activée.
  • 404 : chemin ou ID de tâche erroné, ou tâche déjà nettoyée.
  • 429 : limitation déclenchée ; réduire la concurrence et appliquer un backoff.
  • 5xx : panne amont ou de la couche d'encapsulation ; vérifier avec la clé d'idempotence que la tâche n'a pas été créée avant de réessayer.
  • Tâche failed : lire le code d'erreur pour distinguer paramètres, modération et panne amont.
  • Lien 403/404 : adresse de résultat expirée ou protégée ; revenir au détail de la tâche pour la récupérer.

Consignez l'ID de requête, l'ID de tâche, le code d'erreur et les paramètres masqués dans les logs. Les messages des services d'encapsulation sont souvent réenveloppés : conserver la réponse brute raccourcit nettement le diagnostic.

9. Liste de vérification pour une migration

Pour passer d'un fournisseur à un autre, ou d'un proxy interne à un service hébergé, vérifiez chaque point :

  1. L'URL de base, les en-têtes d'authentification et les chemins sont-ils remplacés dans leur ensemble ?
  2. Le nom du champ d'ID de tâche, les énumérations d'état et la détection des états finaux sont-ils cohérents ?
  3. Les paramètres du prompt sont-ils transmis ou extraits en champs, et --ar / --v fonctionnent-ils ?
  4. L'appel upscale, variante et inpaint et les règles d'index sont-ils identiques ?
  5. La durée de vie des liens, les limites de téléchargement et la logique de transfert sont-elles vérifiées ?
  6. Les callbacks sont-ils pris en charge, avec signature et idempotence ?
  7. Les limites de débit, la concurrence, les timeouts et les tentatives ont-ils été retestés en charge ?
  8. La base de facturation, le remboursement des échecs et le rapprochement de facture concordent-ils ?

Après la migration, faites tourner un lot de cas métier réels, comparez taux de réussite, durée moyenne et coût par image, puis basculez l'ensemble. Sans rapprochement ni plan de retour, ne changez pas tout d'un coup.

Questions fréquentes

L'API Midjourney renvoie-t-elle les images de façon synchrone ?

En général non. La soumission renvoie seulement un ID de tâche ; il faut interroger l'état ou attendre un callback, puis télécharger l'image en cas de succès. Une conception synchrone provoque facilement des timeouts et des soumissions en double.

Combien de temps faut-il interroger une tâche ?

Cela dépend de la file et de la charge amont : de quelques dizaines de secondes à plusieurs minutes. Commencez à 3–5 secondes, augmentez progressivement, fixez un timeout global, puis consultez le détail de la tâche au lieu de resoumettre immédiatement.

Combien de temps un lien d'image reste-t-il valide ?

Cela varie fortement : minutes, heures ou jours. En production, ne dépendez pas du lien amont : transférez l'image dès le succès vers votre propre stockage objet.

Comment appeler l'upscale et les variantes ?

Il faut généralement l'ID de tâche d'origine et l'index de l'image, puis soumettre une tâche dérivée ou appeler l'interface d'action. L'origine de l'index et les noms de champs diffèrent : validez avec une tâche de test.

Que vérifier pour une équipe hors de Chine ?

Vérifiez d'abord l'accessibilité réseau, le transfert de données et la conformité du contenu, puis évaluez les conditions du fournisseur et le risque d'arrêt de service. Pour un point d'entrée unifié, inscrivez-vous sur ZSQH AI Gateway et consultez les modèles pris en charge sur la page Tarifs des modèles ; ne considérez pas une interface d'images non OpenAI comme directement compatible.

Étape suivante

Faites d'abord fonctionner les quatre étapes — soumission, polling, téléchargement, transfert — avec un prompt simple, puis ajoutez upscale, variantes et callbacks. Au moment de choisir un fournisseur, placez la conformité et le mécanisme de sortie avant les effets visuels. Pour gérer plusieurs points d'entrée de modèles, inscrivez-vous sur ZSQH AI Gateway et vérifiez les modèles et la facturation sur la page Tarifs des modèles.

À lire aussi :