• Le 17 août 2026, Google a éteint les endpoints imagen-4.0-generate-001, imagen-4.0-fast-generate-001 et imagen-4.0-ultra-generate-001.
• Le remplacement annoncé est Gemini 3.1 Flash Image, mais ce n’est pas un échange d’identifiant : la méthode generate_images() disparaît entièrement.
• La dépréciation avait été annoncée le 24 mars 2026, soit près de cinq mois de préavis — largement suffisant, et pourtant régulièrement manqué.
• La leçon n’est pas « Google coupe des API » : c’est que l’identifiant de modèle est une dépendance de production et doit être traité comme telle.
Hier, 17 août 2026, trois identifiants de modèles ont cessé de répondre chez Google : les variantes standard, fast et ultra d’Imagen 4. La documentation officielle est sans ambiguïté : ces endpoints sont dépréciés et arrêtés à cette date, avec pour consigne de migrer vers Gemini 3.1 Flash Image afin d’éviter toute interruption de service.
Sur le papier, c’est un non-événement. Une dépréciation annoncée le 24 mars 2026, un préavis de près de cinq mois, un modèle de remplacement clairement désigné. Le genre de changement que l’on traite en quinze minutes entre deux tâches.
En pratique, la migration nous a occupés deux jours. Pas à cause de Google : à cause de la façon dont nous avions intégré l’appel. Et c’est cette partie-là qui mérite d’être racontée, parce qu’elle se reproduira avec un autre fournisseur, un autre modèle, une autre date.
Ce qui a été coupé, et selon quel calendrier
Le cycle de vie complet de ce modèle tient en cinq dates, et il est instructif de les aligner. Imagen 4 est annoncé les 20 et 21 mai 2025. Il arrive en préversion sur l’API Gemini le 24 juin 2025. Il atteint la disponibilité générale sur Vertex le 14 août 2025. Il est déprécié le 24 mars 2026. Il est éteint le 17 août 2026.
Entre la disponibilité générale et l’extinction, il s’écoule donc environ douze mois. Ce n’est pas scandaleux, et c’est même plutôt correct au regard des pratiques du secteur. Mais c’est un ordre de grandeur qu’il faut intégrer : un modèle en disponibilité générale n’est pas une dépendance stable sur plusieurs années. Il faut le considérer comme un composant dont la durée de vie utile se compte en trimestres.
C’est un changement culturel réel pour des équipes habituées à des bibliothèques dont les versions majeures restent supportées pendant des années. Le rythme n’est pas le même, et l’architecture doit en tenir compte dès l’intégration.
Notre avis d’expert n°1 — le préavis n’a jamais été le problème
Cinq mois de préavis, c’est confortable. Pourtant, la majorité des équipes que nous croisons découvrent ce type d’extinction le jour où leur service renvoie une erreur. Ce n’est pas un défaut d’attention : c’est un défaut de chaîne d’information.
L’annonce arrive dans une note de version que personne n’est chargé de lire, ou dans un courriel adressé au titulaire du compte de facturation — qui n’est pas la personne qui écrit le code. Entre les deux, il n’existe aucun mécanisme automatique. Le préavis existe, mais il ne traverse pas l’organisation.
Le correctif est modeste et efficace : désignez nommément une personne responsable de la veille sur chaque fournisseur critique, avec un créneau récurrent, et journalisez les en-têtes de réponse de vos appels. De nombreux fournisseurs signalent une dépréciation dans leurs en-têtes bien avant le courriel. C’est une détection gratuite, et elle atterrit au bon endroit : dans vos journaux, pas dans une boîte aux lettres partagée.
Pourquoi le remplacement n’est pas un simple échange d’identifiant
L’hypothèse implicite de toute dépréciation annoncée avec un modèle de remplacement est qu’il suffira de changer une chaîne de caractères dans un fichier de configuration. C’est précisément ce que nous avions supposé, et c’est ce qui explique l’écart entre les quinze minutes prévues et les deux jours réels.
Le guide de migration de Google est explicite sur ce point : la méthode generate_images() disparaît entièrement. Il ne s’agit donc pas d’un modèle équivalent derrière la même interface, mais d’une autre façon d’appeler, avec une structure de requête différente et une réponse à traiter différemment.
S’ajoute le travail que personne ne budgète : la vérification que les images produites restent acceptables. Un modèle de génération d’images n’est pas une fonction déterministe dont on vérifie l’égalité de sortie. Il faut regarder des échantillons, confronter le résultat aux attentes du métier, et parfois réécrire des consignes qui avaient été ajustées empiriquement pour l’ancien modèle. C’est là que partent les heures.
L’erreur d’architecture que cette coupure a révélée
Notre appel n’était pas isolé. L’identifiant du modèle apparaissait à quatre endroits : dans le service de génération, dans un script de traitement par lots, dans un test d’intégration, et — le pire — codé en dur dans une fonction utilitaire écrite un an plus tôt « pour dépanner ».
Cette dispersion transforme un changement de configuration en chasse au trésor. Elle explique aussi pourquoi les deux premiers jours de la migration ont surtout consisté à trouver les appels plutôt qu’à les réécrire.
La règle que nous appliquons désormais tient en une phrase : un identifiant de modèle ne doit apparaître qu’à un seul endroit du dépôt, dans un fichier de configuration, et tout le reste du code passe par une fonction interne. Cette fonction devient le point unique où l’on absorbe un changement de fournisseur, un repli, ou une différence de format de réponse. Le même raisonnement vaut pour les couches de routage que décrivent nos confrères de Plug-Tech à propos des passerelles multi-modèles.
Un identifiant de modèle codé en dur quelque part dans votre code ?
Nous auditons vos dépendances externes, isolons les points d’appel et rendons les migrations de fournisseurs indolores.
Notre avis d’expert n°2 — traitez l’identifiant de modèle comme une version de dépendance
Nous avons collectivement appris à gérer les versions de bibliothèques : fichier de verrouillage, mise à jour contrôlée, tests avant bascule, outil qui signale les versions obsolètes. Rien de tout cela n’existe pour les identifiants de modèles, alors que la nature du risque est identique — voire supérieure, puisqu’une bibliothèque obsolète continue de fonctionner, là où un endpoint éteint ne répond plus du tout.
Le geste minimal est un inventaire généré automatiquement. Une recherche dans le dépôt sur les motifs d’identifiants de modèles, exécutée à chaque intégration continue, qui produit la liste de ce que vous appelez réellement. Cela prend une heure à écrire et supprime définitivement la question « est-ce qu’on utilise encore ce modèle quelque part ».
Le geste suivant est de faire figurer, à côté de chaque identifiant, la date de fin de support connue. Quand elle n’est pas publiée — ce qui est fréquent — inscrivez la date de mise en disponibilité générale et considérez par défaut une durée de vie de douze mois. Cette hypothèse vaut mieux que l’absence d’hypothèse.
Le cas particulier des préversions
Un détail du calendrier mérite l’attention : les endpoints concernés ici sont des instantanés de préversion promus en disponibilité générale, puis retirés. Beaucoup d’équipes intègrent une préversion pendant une phase d’exploration, puis oublient de repasser sur ce choix une fois le projet en production. Le code de démonstration devient le code de production sans qu’aucune décision explicite n’ait été prise.
Une préversion n’offre, par définition, aucun engagement de stabilité. L’utiliser n’est pas une faute ; l’utiliser sans le savoir en est une. La discipline utile consiste à marquer explicitement, dans le fichier de configuration, quels identifiants sont des préversions, et à traiter cette liste comme une dette à résorber avant la mise en production.
Sur les projets où nous accompagnons des équipes — qu’il s’agisse de construire un CRM sur mesure ou d’une plateforme de mise en relation — cette liste tient généralement en trois à cinq lignes. C’est un coût de tenue à jour négligeable pour un risque qui, lui, est binaire.
Ce que nous avons changé après coup
Trois modifications, toutes peu coûteuses, toutes applicables à n’importe quel fournisseur.
Un point d’appel unique. Toute génération passe désormais par une fonction interne qui prend une intention et rend un résultat. Le reste du code ignore quel fournisseur répond. Retirer Google de l’équation est devenu un changement dans un seul fichier.
Un inventaire automatique. Une vérification en intégration continue liste les identifiants de modèles présents dans le dépôt et échoue si l’un d’eux ne figure pas dans le fichier de configuration central. Cela empêche mécaniquement le retour de l’appel codé en dur « pour dépanner ».
Un test de fumée quotidien. Un appel réel, une fois par jour, sur chaque fournisseur utilisé, avec alerte en cas d’échec. C’est ce qui aurait transformé cette extinction en notification calme un matin, plutôt qu’en incident. Sur le volet supervision et alerte, les équipes de WebGuard Agency font la même recommandation pour les dépendances externes en général : la panne d’un tiers doit produire un signal chez vous, pas chez votre utilisateur.
Notre avis d’expert n°3 — ce que cela dit du rythme réel des dépendances IA
L’enseignement le plus durable de cette coupure n’a rien à voir avec Google. C’est que l’écosystème des modèles fonctionne à une cadence de renouvellement bien supérieure à celle des bibliothèques auxquelles nos pratiques sont adaptées.
Une conséquence concrète, souvent négligée : les fonctionnalités bâties sur un modèle précis doivent être conçues comme remplaçables, pas comme définitives. Cela veut dire éviter d’exposer à vos utilisateurs des garanties qui dépendent du comportement exact d’un modèle donné, et documenter en interne ce que la fonctionnalité promet réellement, indépendamment de qui l’exécute.
Une autre conséquence est budgétaire. Si un modèle vit environ douze mois en disponibilité générale, alors une fonctionnalité qui s’appuie dessus porte un coût de maintenance récurrent, pas seulement un coût de construction. Ce coût doit être annoncé au moment de la décision, sinon il apparaît en cours d’année sous forme d’une urgence que personne n’avait planifiée.
Questions fréquentes
Quels endpoints Imagen 4 ont été coupés exactement ?
Trois identifiants de modèle sont concernés : imagen-4.0-generate-001, imagen-4.0-fast-generate-001 et imagen-4.0-ultra-generate-001, soit les variantes standard, fast et ultra. La documentation de Google indique qu’ils sont dépréciés et arrêtés le 17 août 2026, et oriente vers Gemini 3.1 Flash Image comme remplacement. La dépréciation elle-même avait été annoncée le 24 mars 2026, ce qui laissait un préavis d’environ cinq mois.
La migration vers Gemini 3.1 Flash Image est-elle un remplacement à l’identique ?
Non, et c’est le point qui piège les équipes. Le guide de migration de Google précise que la méthode generate_images() disparaît entièrement : il ne s’agit pas de changer une chaîne de caractères d’identifiant de modèle dans la configuration. L’appel change de forme, et par conséquent le traitement de la réponse aussi. Une équipe qui avait budgété quinze minutes de modification découvre un travail d’adaptation réel, plus les tests de non-régression sur la qualité des images produites.
Comment détecter à l’avance qu’une API que nous utilisons va être coupée ?
En ne comptant pas sur les annonces. La méthode fiable tient en trois mécanismes : tenir un inventaire des identifiants de modèles et de versions d’API réellement appelés en production, extrait automatiquement du code plutôt que maintenu à la main ; journaliser les en-têtes de réponse, car beaucoup de fournisseurs y signalent une dépréciation avant tout courriel ; et faire relire les notes de version des fournisseurs critiques par une personne désignée, à intervalle fixe. Un préavis de cinq mois ne sert à rien s’il arrive dans une boîte aux lettres que personne ne lit.
Faut-il éviter les modèles en préversion pour du code de production ?
Pas nécessairement, mais il faut les traiter pour ce qu’ils sont : des composants dont le contrat de stabilité est explicitement absent. La règle praticable consiste à autoriser une préversion uniquement derrière une couche d’abstraction interne, à ne jamais laisser son identifiant apparaître ailleurs que dans un fichier de configuration, et à prévoir dès le départ le modèle de repli. Le coût de cette discipline est d’une demi-journée au moment de l’intégration ; le coût de son absence se paie en urgence, un jour où le service répond soudainement une erreur.
En résumé
Une extinction annoncée cinq mois à l’avance, un modèle de remplacement désigné, une documentation claire : sur tous les critères, cette dépréciation a été correctement gérée par le fournisseur. Et elle a quand même coûté deux jours, parce que le problème n’était pas chez lui.
Les dépendances aux modèles se comportent comme des dépendances logicielles ordinaires, avec un cycle de vie plus court et aucun outillage établi pour les suivre. Trois gestes suffisent à absorber la prochaine coupure sans douleur : un point d’appel unique, un inventaire généré automatiquement, un test de fumée quotidien. Aucun des trois ne demande plus d’une journée de travail, et ensemble ils transforment une catégorie entière d’incidents en simple tâche de maintenance.
Vos dépendances externes survivraient-elles à une coupure demain matin ?
Inventaire des appels externes, isolation des points de dépendance et mise en place des alertes qui transforment une panne fournisseur en simple notification.
