Choisissez Auto, TokenLab Verified ou Official pour chaque demande, avec les prix affichés à l'avance.Voir les nouveautés

Meilleure API de génération d'images par IA en 2026 : un cadre de sélection

·19 septembre 2026·11 min de lecture·Mis à jour 26 septembre 2026·2029 vues
#génération d'images#API d'image IA#modèles#multimodal
Meilleure API de génération d'images par IA en 2026 : un cadre de sélection

Le prix affiché par image constitue un mauvais premier filtre. Deux modèles au même tarif nominal peuvent différer selon qu'ils acceptent ou non des images de référence, qu'ils prennent en charge les retouches avec masque, la manière dont la taille de sortie est sélectionnée, et si la facturation s'effectue par requête ou par token. Filtrez d'abord les candidats par fonctionnalité, puis comparez le coût par résultat accepté sur vos propres prompts.

Cet article est un cadre de sélection pour les API de génération d'images. Il couvre la génération d'images, et non la vidéo. Lorsqu'un pipeline nécessite les deux, les mêmes mécanismes asynchrones et de facturation s'appliquent, mais la vidéo est hors de portée ici.

Étape 1 : Faire correspondre l'opération prise en charge

Le premier tour d'élimination est opérationnel. Un endpoint qui génère uniquement à partir de texte ne peut pas effectuer d'édition avec masque, et un modèle conçu pour l'inpainting n'est pas un outil polyvalent de prompt-to-image.

Sur TokenLab, la génération et l'édition sont généralement des endpoints distincts :

Ce dont vous avez besoin Endpoint Remarques
Texte-vers-image POST /v1/images/generations La requête commence uniquement à partir d'un prompt
Image-vers-image / génération guidée par référence POST /v1/images/generations Modèles qui acceptent operation: "image-to-image" avec des URL de référence
Retouche avec masque ou multipart POST /v1/images/edits Modèles documentant un flux d'édition
Variation d'une image existante POST /v1/images/variations Pour les intégrations qui utilisent déjà le format de variations
Statut de la tâche GET /v1/tasks/{id} Lorsqu'une réponse de création renvoie task_id, status: "pending" ou poll_url

Consultez le guide de génération d'images pour le tableau de décision et les références Create Image et Edit Image pour les champs de requête.

Une règle de routage provoque un nombre disproportionné d'échecs : les requêtes d'images de référence Nano Banana (nano-banana-2, nano-banana-pro) vont à /v1/images/generations avec operation: "image-to-image" et image_urls, et non à /v1/images/edits. À l'inverse, les éditions de gpt-image-2 doivent être adressées à /v1/images/edits, où il accepte les téléversements multipart image, le JSON image_url / image_urls, et les références images[] jusqu'à 16 images sources.

Regroupements utiles issus du catalogue actuel de TokenLab :

  • Génération et édition : flux-2-klein-4b, flux-2-klein-9b, flux-2-pro, flux-2-flex, flux-2-max, flux-kontext-pro, flux-kontext-max, gemini-3-pro-image, gemini-3.1-flash-image, nano-banana-2, nano-banana-2-lite, nano-banana-pro, gpt-image-2, gpt-image-2.5-flare, gpt-image-2.5-sunburst, grok-imagine-image, grok-imagine-image-quality, grok-imagine-image-2.0, qwen-image-2.0, qwen-image-2.0-pro, qwen-image-3.0, seedream-4.0, seedream-4.5, seedream-5.0, seedream-5.0-lite, seedream-5.0-pro, vidu-image-lite, vidu-image-pro.
  • Texte-vers-image uniquement : flux-1-dev, flux-pro-1.1, flux-pro-1.1-ultra, sd3.5-medium, sd3.5-large, sd3.5-large-turbo, sd3.5-flash, stable-image-core, stable-image-ultra, z-image, z-image-turbo, kling-image, kling-omni-image, hy-image-lite.
  • Outils d'édition spécialisés : stability-inpaint, stability-control-sketch, stability-control-structure, stability-style-guide, stability-upscale-fast, stability-upscale-conservative, image-upscaler, image-background-remover, flux-pro-1.0-fill, qwen-image-edit.

Vérifiez les opérations par modèle plutôt que par famille. GET /v1/models?recommended_for=image renvoie l'ensemble actuellement recommandé, et la référence Get a Model affiche le champ supported_operations qui indique ce qu'un identifiant spécifique accepte.

Étape 2 : Vérifier la façon dont le modèle accepte les images de référence

La gestion des images de référence est l'endroit où les intégrations échouent. Les noms de champs ne sont pas interchangeables :

  • image_url — une seule image de référence.
  • image_urls — une ou plusieurs références en JSON.
  • reference_image_urls — références supplémentaires pour les modèles qui séparent les entrées principales des références.
  • image — un téléversement de fichier multipart, pour les images sources privées ou protégées par des en-têtes.
  • images[] avec image_url ou file_id — un format de flux d'édition ; non accepté sur /v1/images/generations.

Contraintes importantes à prendre en compte lors de la conception, d'après la référence de l'API :

  • Les références distantes doivent être des URL http/https publiques, sans identifiants intégrés ni fragments, et ne doivent pas pointer vers localhost ou des plages d'adresses IP privées ou réservées. Chaque redirection est revérifiée.
  • Images récupérées par URL : 50 MiB par image, 200 MiB cumulés par requête (masque inclus), délai d'expiration de récupération de 30s, jusqu'à 3 redirections. La charge utile récupérée doit être un véritable PNG, JPEG ou WebP.
  • Les limites d'images sources diffèrent : gpt-image-2 en accepte jusqu'à 16 ; la limite documentée de 3 images d'entrée s'applique spécifiquement à grok-imagine-image et grok-imagine-image-quality (qui échouent avec 400 too_many_images au-delà de 3) et n'est pas documentée pour grok-imagine-image-2.0.
  • Un masque (mask) doit être un PNG de moins de 50 MiB ayant les mêmes dimensions que l'image source.

Si vos images sources sont privées, prévoyez un téléversement multipart ou une référence /v1/files plutôt que de transmettre une URL signée avec expiration. Une URL signée qui expire avant le début du traitement constitue une entrée rejetée, et non un échec de génération.

Étape 3 : Comparer les contrôles de sortie, pas seulement les noms de modèles

Deux modèles d'un même niveau peuvent proposer des contrôles de taille et de qualité totalement différents. Confirmez le contrat du sélecteur avant de concevoir une interface utilisateur autour de celui-ci.

Contrôle Ce qu'il faut vérifier
size Les familles de style OpenAI acceptent auto ou LARGEURxHAUTEUR. Pour gpt-image-2, les dimensions doivent être des multiples de 16, le bord le plus long au maximum de 3840px, le rapport long/court au plus de 3:1, et le nombre total de pixels entre 655 360 et 8 294 400
aspect_ratio Les familles d'images Google et Grok Imagine utilisent 1:1, 16:9, 9:16, 3:2, 2:3 et des valeurs similaires
resolution gemini-3.1-flash-image, gemini-3-pro-image, nano-banana-2 et nano-banana-pro prennent en charge 1k, 2k, 4k, tandis que nano-banana-2-lite prend uniquement en charge 1k. Grok Imagine prend en charge 1k et 2k
quality Les modèles GPT Image utilisent auto, low, medium, high. D'autres modèles peuvent utiliser des valeurs différentes
n Nombre d'images par requête, selon le modèle
response_format url ou b64_json. Les tâches asynchrones renvoient des URL quel que soit le format demandé
background, output_format, output_compression Documentés pour gpt-image-2 ; transparent n'est pas pris en charge
async Pris en charge pour gpt-image-2 et les modèles d'images officiels FLUX/BFL

L'envoi d'un champ non documenté n'est pas sans conséquence. Par exemple, input_fidelity ne fait pas partie des champs actuellement pris en charge pour gpt-image-2 et renvoie 400 unsupported_parameter. Les champs non pris en charge sur d'autres modèles échouent de la même façon. La liste complète des champs se trouve dans la référence Create Image.

Étape 4 : Identifier l'unité de facturation avant toute comparaison

Les comparaisons de coûts sont faussées lorsqu'un modèle facturé au token est comparé à un modèle facturé à l'image comme s'il s'agissait de la même unité.

  • gpt-image-2 est tarifé au token. TokenLab suit la ventilation d'utilisation du concepteur pour les tokens d'entrée de texte, d'entrée d'image, d'entrée en cache signalée et de sortie d'image ; il n'est pas facturé comme un modèle fixe par image.
  • La plupart des autres modèles d'images sont tarifés par requête, par image ou selon une autre unité indiquée sur la page du modèle.

Conséquence pratique : pour gpt-image-2, le même prompt avec les mêmes paramètres nominaux peut coûter différemment selon la résolution, la qualité et le prompt lui-même, car le volume de tokens en sortie varie. Mesurez avant de vous engager sur une règle de routage.

Consultez l'unité de facturation et le prix en vigueur au moment de la requête plutôt que de figer un tableau en dur dans le code :

  • Facturation et tarification explique le fonctionnement des frais, des estimations et de la réservation asynchrone.
  • Get a Model renvoie tokenlab.pricing et tokenlab.pricing_unit pour un modèle individuel.
  • List Models renvoie le catalogue avec tokenlab.pricing, tokenlab.capabilities et tokenlab.deliveryAvailability.
  • La page Modèles présente les mêmes informations pour la consultation.

Un tiret dans la colonne des prix TokenLab signifie qu'aucune offre TokenLab Verified n'est actuellement disponible pour ce modèle, et non que le modèle est gratuit. Les modèles disposant d'un approvisionnement Official restent accessibles via l'option de distribution Official ou Auto.

Étape 5 : Choisir entre un flux synchrone et un flux basé sur des tâches

Les requêtes d'images en haute résolution peuvent prendre près d'une minute ou plus. Réglez le délai d'attente (timeout) de votre client HTTP sur au moins 120s pour les appels synchrones, ou utilisez le flux de tâches.

  • Envoyez async: true avec gpt-image-2 ou les modèles d'images officiels FLUX/BFL pour obtenir un task_id et une poll_url au lieu d'une image finale.
  • Ne codez pas un modèle en dur comme étant toujours synchrone ou toujours asynchrone. Examinez la réponse de création : si elle contient status: "pending", task_id ou poll_url, interrogez l'URL poll_url renvoyée.
  • Les statuts sont pending, processing, completed et failed. Une lecture de statut réussie renvoie un code HTTP 200 même si la tâche a échoué ; basez-vous sur le champ status, pas sur le code HTTP.
  • Les résultats d'images asynchrones sont renvoyés sous forme d'URL. Si vous avez besoin de b64_json brut, utilisez une requête synchrone.
  • Effectuez un sondage (polling) toutes les quelques secondes et arrêtez-vous à un statut terminal. Les URL de résultat HTTP(S) des images générées peuvent être conservées sous forme de copies médias pendant 30 jours ; consultez media_retention.items pour connaître le statut de chaque élément et sa date expires_at.

Les détails figurent dans le guide des tâches asynchrones et du polling et dans la référence Get Image Status.

Les nouvelles tentatives constituent un risque de facturation, pas seulement de latence. Une requête de création réessayée après un dépassement de délai peut générer une seconde tâche et des seconds frais. Conservez request_id, task_id et tout billing_transaction_id, et vérifiez si une tâche a été créée avant de réessayer.

Étape 6 : Évaluer sur votre propre jeu de prompts

Aucun classement de qualité indépendant des fournisseurs n'est inclus dans cet article, et aucun ne doit être tiré d'arguments marketing. Justifiez votre choix par des mesures appliquées à votre propre charge de travail :

  1. Constituez un ensemble fixe de prompts reflétant votre distribution en production — les sujets, styles et formes d'instructions que vous recevez réellement. Des prompts de démonstration génériques ne vous permettront pas de différencier les modèles.
  2. Exécutez le même jeu sur vos modèles candidats avec des paramètres identiques, et enregistrez le temps de génération par requête, nouvelles tentatives comprises.
  3. Notez les résultats selon une grille fixe, automatisée ou via un panel d'évaluation humaine, plutôt que d'évaluer des échantillons à l'œil nu.
  4. Calculez le coût par image acceptée, et non le coût par image générée. Un modèle moins cher qui nécessite deux tentatives par résultat utilisable ne revient pas moins cher.
  5. Si votre produit est sensible à la latence, enregistrez des centiles plutôt que des moyennes, car c'est la queue de distribution que remarquent les utilisateurs.
  6. Répétez la comparaison lorsque vous changez de fournisseur ou de cibles de résolution, car les unités de tarification tout comme le comportement des modèles peuvent évoluer.

Le coût par image acceptée est le seul chiffre qui permet de déterminer si un modèle plus coûteux justifie son tarif pour votre charge de travail.

Exemple de requête

L'exemple suivant illustre la structure de l'appel de génération et ne constitue pas un résultat mesuré. Il utilise un modèle qui expose aspect_ratio et resolution.

curl https://api.tokenlab.sh/v1/images/generations \
  -H "Authorization: Bearer $TOKENLAB_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gemini-3-pro-image",
    "prompt": "A cinematic portrait of a white cat sitting on a rainy windowsill",
    "aspect_ratio": "16:9",
    "resolution": "2k"
  }'

Si cette réponse renvoie status: "pending", interrogez la poll_url renvoyée plutôt que de considérer qu'il s'agit d'un échec.

L'accès aux modèles n'est pas uniforme selon les formats d'API. TokenLab accepte les formats de requêtes Chat Completions, Responses, Anthropic Messages et Gemini, et un modèle donné peut n'en prendre en charge qu'une partie. Vérifiez tokenlab.accepted_request_formats sur le modèle avant de réutiliser un client existant — voir Formats d'API.

Limites de cet article

  • Aucun banc d'essai de qualité indépendant, mesure de latence ou chiffre de débit pour un quelconque modèle d'image n'est inclus ici. Le positionnement des fournisseurs sur l'anatomie, le rendu du texte ou le photoréalisme n'est pas repris comme un fait.
  • Aucun prix n'est mentionné. Les unités de facturation des modèles d'images diffèrent et évoluent ; consultez la valeur actuelle sur la page Modèles ou via GET /v1/models/{model}.
  • La disponibilité des modèles varie selon l'option de distribution et l'espace de travail. tokenlab.deliveryAvailability décrit la prise en charge configurée ; elle ne garantit pas la disponibilité en temps réel, qui est vérifiée lors de l'exécution d'une requête.
  • Des restrictions régionales publiques s'appliquent.

Lectures connexes

Sources

Modèles liés

Modèles récemment publiés

Construire avec les modèles de ce guide

Comparez les prix, testez les routes et transformez la recherche en appel API fonctionnel.