DevNews

Google éteint ses points d'entrée d'API Imagen 4

Sur cette page
  1. Ce qui s'éteint
  2. La réécriture, concrètement
  3. Les quatre paramètres qui n'ont nulle part où aller
  4. Pourquoi la perte de numberOfImages coûte plus qu'il n'y paraît
  5. Une autre date en août
  6. Sources et pour aller plus loin

Les trois points d'entrée Imagen 4 de l'API Gemini atteignent leur date d'extinction le lundi 17 août 2026, deux mois après que Google les a marqués obsolètes dans les notes de version du 15 juin. Le remplacement recommandé est gemini-3.1-flash-image, et la migration ne se résume pas à changer une chaîne de modèle. L'appel de génération d'images disparaît, l'objet de configuration se scinde en deux, et quatre paramètres sur lesquels les utilisateurs d'Imagen s'appuyaient n'ont aucun équivalent, dont celui qui renvoyait plusieurs images par requête. Si un build appelle encore imagen-4.0-generate-001, voici précisément ce qui casse.

The short answer

Les points d'entrée Imagen 4 standard, fast et ultra de l'API Gemini atteignent leur date d'extinction le 17 août 2026, après avoir été marqués obsolètes dans les notes de version du 15 juin. Google recommande gemini-3.1-flash-image. La migration remplace ImagenModel par GenerativeModel et generateImages par generateContent, scinde la configuration en GenerationConfig plus un ImageConfig imbriqué, et supprime numberOfImages, negativePrompt, imageFormat et addWatermark sans remplacement.

3points d'entrée Imagen 4 éteints le 17 août
4paramètres sans aucun équivalent
1image par réponse, là où vous pouviez en demander plusieurs
Carte réponse : les trois points d'entrée Imagen 4 de l'API Gemini s'éteignent le 17 août 2026, avec gemini-3.1-flash-image en remplacement recommandé, et quatre paramètres retirés dont numberOfImages, negativePrompt, imageFormat et addWatermark.
La date, le remplacement et les quatre paramètres qui disparaissent. Source : les notes de version de l'API Gemini et le guide de migration Imagen de Google. PNG

La plupart des obsolescences se règlent par un rechercher-remplacer sur une chaîne de modèle, et c'est pour cela que nous avons tous appris à survoler l'avis. Celle-ci n'entre pas dans cette catégorie, et ce qui surprendra n'est pas la qualité du modèle. C'est qu'un appel unique qui renvoyait quatre images n'en renvoie plus qu'une.

Ce qui s'éteint

Trois points d'entrée atteignent leur date d'extinction le lundi 17 août : imagen-4.0-generate-001, imagen-4.0-fast-generate-001 et imagen-4.0-ultra-generate-001. Google les avait listés comme obsolètes dans les notes de version de l'API Gemini du 15 juin, soit un préavis d'environ deux mois.

Les équipes sur Vertex AI sont déjà passées par là. Les points d'entrée Imagen 4.0 équivalents y ont dépassé leur date d'obsolescence le 30 juin, ce qui explique pourquoi les deux plateformes donnent des réponses différentes à la même question depuis six semaines.

Le remplacement recommandé est gemini-3.1-flash-image, de la famille d'images Gemini. Même fournisseur, même compte, forme d'API différente.

La réécriture, concrètement

Quatre changements structurels, tous mécaniques dès lors qu'on sait qu'ils existent.

La classe de modèle change. ImagenModel devient GenerativeModel, la classe que vous utilisez déjà pour le texte, si bien que la génération d'images cesse d'être un chemin de code séparé dans votre client.

L'appel change. generateImages, ou generate_images selon votre SDK, devient generateContent. La forme de la réponse change donc aussi, et tout ce qui en aval dépaquetait une réponse Imagen par index demandera de l'attention.

La configuration se scinde en deux. ImagenGenerationConfig devient un GenerationConfig portant un ImageConfig imbriqué, et le rapport d'aspect entre dans cet objet imbriqué plutôt que de rester au premier niveau. La configuration de sécurité suit la même consolidation : ImagenSafetySettings devient la classe SafetySetting standard, partagée avec les autres modèles Gemini.

Liste de migration d'Imagen 4 vers les modèles d'image Gemini : remplacer ImagenModel par GenerativeModel, remplacer generateImages par generateContent, déplacer aspectRatio dans un ImageConfig imbriqué, remplacer ImagenSafetySettings par SafetySetting, boucler pour plusieurs images, abandonner negativePrompt, prévoir du PNG uniquement et un filigrane SynthID sur chaque image.
Huit changements entre l'ancien appel et le nouveau. Les quatre derniers n'ont aucun paramètre à migrer, seulement un comportement à accepter. PNG

Les quatre paramètres qui n'ont nulle part où aller

C'est la partie à lire deux fois, car aucun de ces cas ne produit d'erreur utile à la compilation.

numberOfImages n'existe pas. Les modèles d'image Gemini renvoient toujours une seule image, et la recommandation de Google est d'exécuter la génération dans une boucle pour obtenir le même résultat. C'est à la fois un changement de code et un changement de budget, nous y revenons plus bas.

negativePrompt n'existe pas. Aucun paramètre de remplacement, donc ce que vous supprimiez doit passer dans l'invite positive ou être traité après génération.

imageFormat n'existe pas, la sortie étant toujours au format PNG. Si vous demandiez un autre format en le convertissant avant stockage, cette étape de conversion devient inconditionnelle.

addWatermark n'existe pas, car les images générées portent toujours un filigrane SynthID au lieu d'en faire une option. Cela reste cohérent avec la direction prise par Google toute l'année, y compris l'interrupteur de filigrane visible ajouté à l'application Gemini. Les restrictions sur la génération de personnes changent aussi de comportement, autorisées par défaut plutôt que conditionnées par un paramètre.

Pourquoi la perte de numberOfImages coûte plus qu'il n'y paraît

La boucle est facile à écrire. Les conséquences le sont moins.

Un appel qui renvoyait quatre candidats devient quatre appels, si bien que votre nombre de requêtes décomptées du quota est multiplié par l'ancienne valeur de numberOfImages. Tout tableau de bord, toute alerte et toute limite de débit exprimée en requêtes par minute a été calibrée sur l'ancien rapport et se trouve maintenant fausse du même facteur.

La latence change aussi de forme. Une réponse qui arrivait devient quatre réponses qui arrivent, ce qui est plus rapide si vous parallélisez et nettement plus lent si votre client boucle en série parce que c'était le plus petit diff. Toute grille de variantes présentée à l'utilisateur dépend désormais de plusieurs requêtes qui aboutissent plutôt que d'une seule, ce qui exige aussi une gestion de l'échec partiel dont vous n'aviez pas besoin auparavant.

La comptabilité des coûts vient en troisième. Si votre reporting interne suppose qu'une requête d'API égale une génération facturable, cette hypothèse tenait sous Imagen et ne tient plus.

Une autre date en août

Gemini Robotics ER 1.6, le modèle en préversion gemini-robotics-er-1.6-preview, s'éteint le 31 août 2026. Les remplacements annoncés sont gemini-robotics-er-2-preview et gemini-robotics-er-2-streaming-preview.

L'habitude à prendre de tout cela est modeste. Lisez le tableau des obsolescences de Google plutôt que les notes de version. Les notes vous disent quand une chose a été annoncée, ce qui est intéressant. Le tableau liste les dates d'extinction au plus tôt, et c'est la colonne qui décide vraiment si votre build fonctionne encore un lundi matin.

Sources et pour aller plus loin

Questions fréquentes

Quels points d'entrée s'arrêtent et à quelle date ?

Trois modèles de l'API Gemini atteignent leur date d'extinction le 17 août 2026 : imagen-4.0-generate-001, imagen-4.0-fast-generate-001 et imagen-4.0-ultra-generate-001. Google les avait marqués obsolètes dans les notes de version de l'API Gemini datées du 15 juin 2026, soit environ deux mois de préavis. Le versant Vertex AI a déjà passé cette étape, puisque les points d'entrée Imagen 4.0 équivalents y ont atteint leur date d'obsolescence le 30 juin 2026. Le remplacement recommandé par Google est gemini-3.1-flash-image.

Le remplacement est-il transparent ?

Non, et le prendre pour tel est la principale façon de rater cette migration. La classe instanciée passe d'ImagenModel à GenerativeModel et l'appel passe de generateImages, ou generate_images selon votre SDK, à generateContent. La configuration se scinde : ImagenGenerationConfig devient un GenerationConfig contenant un ImageConfig imbriqué, et ImagenSafetySettings devient la classe SafetySetting standard utilisée par les autres modèles Gemini. Le rapport d'aspect passe dans cet ImageConfig imbriqué au lieu de figurer sur la configuration du modèle.

Quels paramètres n'ont aucun équivalent ?

Quatre. numberOfImages disparaît, car les modèles d'image Gemini renvoient toujours une seule image, si bien que la génération par lot devient une boucle de votre côté. negativePrompt disparaît sans remplacement. imageFormat disparaît, la sortie étant toujours au format PNG. addWatermark disparaît, car les images générées portent toujours un filigrane SynthID au lieu de le rendre optionnel. Les restrictions sur la génération de personnes se comportent également différemment, autorisées par défaut au lieu d'être conditionnées par un paramètre.

Quel est l'impact concret de la perte de numberOfImages ?

Elle change votre modèle de coût et de latence, pas seulement votre code. Un appel Imagen unique qui renvoyait quatre candidats devient quatre appels Gemini, si bien que le nombre de requêtes décomptées de votre quota est multiplié par l'ancienne valeur de numberOfImages. Tout ce qui supposait qu'une requête égale une unité facturable est à revoir, et tout parcours utilisateur qui affichait une grille de variantes dépend désormais de plusieurs requêtes qui aboutissent plutôt que d'une seule réponse. Si vous paginez ou limitez le débit au nombre de requêtes, vérifiez ces seuils avant de livrer.

D'autres modèles Google partent-ils à la même période ?

Un de plus en août. Gemini Robotics ER 1.6, le modèle en préversion gemini-robotics-er-1.6-preview, s'éteint le 31 août 2026, avec gemini-robotics-er-2-preview et gemini-robotics-er-2-streaming-preview annoncés en remplacement. Au-delà, la bonne habitude consiste à lire le tableau des obsolescences plutôt que les notes de version, car il liste les dates d'extinction au plus tôt et non les annonces, et c'est cette colonne qui casse réellement les builds.