Google ferme les endpoints Imagen 4 : la face cachée du risque de plateforme

Un modèle ne meurt jamais d'un coup : il est d'abord déprécié, puis débranché. Google vient d'illustrer ce cycle en coupant, le 17 août, ses trois endpoints de génération d'images Imagen 4 sur l'API Gemini — les versions standard, fast et ultra. Les applications qui appelaient encore `imagen-4.0-generate-001` et ses variantes ont cessé de recevoir des réponses, selon la documentation officielle de l'API Gemini. Un non-événement pour le grand public, un chantier pour les équipes techniques qui avaient bâti dessus.

Une migration qui n'a rien d'un copier-coller

Google recommande de basculer vers Gemini 3.1 Flash Image. Mais le remplacement n'est pas une simple substitution de nom de modèle. La méthode dédiée `generate_images()` disparaît purement et simplement : la génération d'images passe désormais par `generate_content()`, le même appel que celui utilisé pour le texte. En clair, ce n'est pas une ligne à changer, mais une partie de la logique d'intégration à réécrire — gestion des réponses, formats, paramètres. Pour une équipe, cela signifie du temps d'ingénierie non prévu, des tests de non-régression et, souvent, une facture d'inférence revue à la hausse sur le modèle de remplacement.

Le coût, souvent, s'invite dans l'équation. Passer d'un modèle spécialisé et amorti à un modèle plus récent et généraliste se traduit fréquemment par un tarif par image supérieur, sans que la qualité perçue par l'utilisateur final justifie toujours la hausse. Pour un service qui génère des milliers de visuels par jour, l'addition n'est pas anecdotique : elle transforme une contrainte technique en arbitrage budgétaire, décidé unilatéralement par le fournisseur et subi par l'éditeur. La génération d'images, très gourmande en calcul, est de ce point de vue l'un des terrains les plus volatils du marché.

Ce n'est pas un incident isolé, mais l'aboutissement d'un calendrier. Google avait déprécié l'ensemble des endpoints Imagen 3 et 4 sur Vertex AI le 24 mars 2026, avec une date butoir au 30 juin côté Vertex, avant de fermer Imagen 4 sur l'API Gemini ce 17 août. La dépréciation — cette phase où l'API fonctionne encore mais est signalée comme condamnée — est censée laisser le temps de migrer. Encore faut-il avoir surveillé les journaux de version.

Le vrai sujet : le risque de plateforme

Derrière la question technique se cache un enjeu stratégique que les directions techniques européennes connaissent bien. Construire un produit sur une API propriétaire, c'est accepter que le fournisseur puisse, à son rythme, modifier ses tarifs, changer ses interfaces ou débrancher un modèle. Le fournisseur optimise son propre catalogue ; le client encaisse les migrations. Quand ce fournisseur est un hyperscaler américain et que le produit sert des utilisateurs européens, le risque de plateforme se double d'une question de dépendance.

La parade n'est pas de renoncer aux meilleurs modèles, mais de s'interposer une couche d'abstraction entre son code et eux. C'est tout le sens des passerelles de routage — dont le rachat récent d'OpenRouter par Stripe vient de rappeler la valeur : en isolant l'application derrière une interface unique, changer de modèle sous-jacent devient une décision de configuration, pas un projet. La contrepartie, on l'a vu, est de bien choisir qui contrôle cette couche.

Ce que ça dit de l'année 2026

L'épisode Imagen 4 est mineur en soi, mais représentatif d'un marché qui accélère. Les fournisseurs sortent des modèles tous les mois, en retirent tout aussi vite, et fusionnent leurs interfaces pour simplifier leur propre exploitation. Pour un éditeur, la stabilité n'est plus un acquis : c'est une compétence à internaliser. Cela passe par une veille active sur les journaux de version, par des tests automatisés qui détectent une réponse d'API qui change de forme, et — pour les usages sensibles — par la capacité à basculer vers des modèles ouverts hébergés en Europe quand la dépendance devient trop risquée. La génération d'images est un terrain de jeu ; demain, ce sera un modèle de raisonnement critique pour la production. La question n'est pas de savoir si un fournisseur débranchera à nouveau un endpoint, mais quand — et si vous serez prêt.