7 min read Stratégie modèles

Le retard de Gemini 3.5 Pro : pourquoi votre feuille de route ne doit jamais dépendre d'un seul modèle

Le retard de Gemini 3.5 Pro : pourquoi votre feuille de route ne doit jamais dépendre d'un seul modèle

Le 21 juillet 2026, Google DeepMind a publié trois nouveaux modèles Gemini : 3.6 Flash, 3.5 Flash-Lite et une version Flash Cyber spécialisée dans la détection de vulnérabilités. Aucun des trois n'était Gemini 3.5 Pro. Le modèle phare, présenté en mai avec une disponibilité générale annoncée pour le mois suivant, reste inaccessible, et la gamme Pro n'a pas été mise à jour depuis février. Cinq jours plus tôt, Bloomberg rapportait que le lancement avait été repoussé parce que le modèle n'atteignait pas les objectifs de performance internes de Google, en particulier sur les tâches de codage.

Le réflexe devant cette séquence est d'y lire un verdict sur la course aux modèles : Google décroche, OpenAI et Anthropic prennent l'avantage. C'est la lecture qui a dominé la couverture financière, et c'est la moins utile pour une équipe technique. Ce retard ne dit pas grand-chose sur qui gagnera la course. Il dit en revanche qu'un fournisseur disposant de ressources quasi illimitées peut manquer une date de disponibilité de plusieurs mois, sans préavis et sans engagement de remplacement. La question à se poser n'est donc pas de savoir si vous avez choisi le bon modèle, mais combien vous coûterait d'en changer.

Cette question prolonge celle posée dans l'article sur le harness plutôt que le modèle : si l'essentiel du comportement d'un agent tient à sa configuration et non au modèle sous-jacent, alors une architecture bien construite devrait absorber un changement de fournisseur sans réécriture. Le retard de Gemini 3.5 Pro est une occasion de vérifier si c'est vrai chez vous.

Plateforme de feuille de route reposant sur trois piliers dont un est incomplet et en pointillés
Une feuille de route produit adossée à un modèle non encore disponible transfère au fournisseur une décision qui appartient à l'équipe.

La chronologie d'un décalage de six mois

Google a présenté Gemini 3.5 Pro en mai, en accompagnement du lancement de 3.5 Flash, en indiquant que la version Pro était déjà utilisée en interne et serait déployée le mois suivant. Juin est passé sans annonce. Le 16 juillet, Bloomberg publiait, sur la base de témoignages d'employés actuels et anciens, que la sortie était bloquée par des résultats de codage en deçà des cibles internes, et qu'une mise à jour des données d'entraînement fin juin avait dégradé les performances au lieu de les améliorer. Alphabet a clôturé cette journée en baisse de 4,4 %, effaçant environ 200 milliards de dollars de capitalisation.

Ce n'était pas le premier choc du trimestre. Le 22 juin, l'action avait déjà perdu plus de 5 %, soit près de 225 milliards de dollars, après le départ en une semaine de cinq chercheurs seniors de DeepMind vers des laboratoires concurrents, dont John Jumper, prix Nobel de chimie 2024 pour AlphaFold, parti chez Anthropic, et Noam Shazeer, co-responsable de Gemini et co-auteur du papier fondateur sur les Transformers, parti chez OpenAI.

Pendant cette même fenêtre, les concurrents ont livré. OpenAI a sorti GPT-5.5 puis a commencé le déploiement de GPT-5.6 le 9 juillet. Anthropic a lancé Claude Opus 4.8 fin mai, Claude Sonnet 5 le 30 juin et élargi l'accès à Fable 5 en juin. Le 21 juillet, Logan Kilpatrick, responsable produit chez Google DeepMind, indiquait que Gemini 3.5 Pro était en test chez des partenaires et que l'équipe espérait le livrer bientôt, tout en annonçant le démarrage du cycle de pré-entraînement le plus ambitieux jamais lancé pour Gemini 4.

Un détail mérite d'être noté au passage, parce qu'il coupe court à la lecture catastrophiste : sur la même période, le chiffre d'affaires de Google Cloud a progressé de 63 % sur un an pour atteindre 20 milliards de dollars, et le résultat opérationnel du segment a environ triplé. Un retard sur un modèle phare n'est pas un effondrement industriel. C'est un aléa d'exécution, et c'est précisément ce qui le rend intéressant : les aléas d'exécution arrivent à tout le monde, y compris aux fournisseurs les plus solides.

Ce qu'un retard fournisseur coûte vraiment

L'erreur classique consiste à traiter une date de lancement annoncée comme un engagement de roadmap. Rien dans une pré-annonce de modèle n'est contractuel, ni la date, ni les performances promises, ni même le fait que le modèle sorte un jour sous la forme présentée. Les équipes qui ont inscrit une fonctionnalité produit au planning du troisième trimestre en supposant que Gemini 3.5 Pro serait disponible en juin ont transféré une décision de calendrier à un tiers qui n'avait rien signé.

Le coût réel se mesure au moment où il faut basculer. Dans les déploiements matures, les équipes qui ont isolé leur couche modèle derrière une interface stable rebasculent une partie du trafic vers un autre fournisseur en quelques jours, avec une dégradation de qualité qu'elles ont déjà mesurée. Celles qui ont codé en dur les particularités d'un fournisseur découvrent que changer de modèle est un projet de plusieurs semaines : format d'appel d'outils différent, structure de prompt système à réécrire, comportement de cache incompatible, jeu d'évaluations à reconstruire parce qu'il n'existait que pour un seul modèle.

Cette asymétrie ne dépend presque jamais de la taille de l'équipe ni du budget. Elle dépend d'une décision d'architecture prise tôt, souvent implicitement, quand quelqu'un a intégré le SDK d'un fournisseur directement dans la logique métier plutôt que derrière une abstraction. Le retard de Gemini n'a pas créé ce risque, il l'a rendu visible.

Grille de quatre critères pour mesurer la dépendance à un fournisseur de modèle unique
Quatre critères pour évaluer la dépendance réelle de votre architecture à un fournisseur de modèle unique.

Quatre critères pour mesurer votre dépendance

Le premier est le délai de bascule. Combien de temps faut-il à votre équipe pour rerouter 10 % du trafic de production vers un modèle d'un autre fournisseur, sans dégradation fonctionnelle. Si personne ne connaît la réponse, c'est que l'exercice n'a jamais été fait, et une estimation optimiste ne vaut rien tant qu'elle n'a pas été testée en conditions réelles.

Le deuxième est la couverture du jeu d'évaluations. Vos evals tournent-elles sur au moins deux fournisseurs, avec des résultats comparables et historisés. Un harness d'évaluation qui n'existe que pour un modèle ne mesure pas la qualité de votre système, il mesure la qualité de ce modèle sur votre cas d'usage, ce qui n'est pas la même chose et ne se transfère pas.

Le troisième est l'exposition de la feuille de route. Combien de fonctionnalités engagées auprès du métier ou du board dépendent d'un modèle qui n'est pas encore en disponibilité générale. La règle raisonnable est de n'engager publiquement que ce qui repose sur des capacités déjà accessibles, et de traiter les modèles annoncés comme des accélérateurs potentiels, jamais comme des prérequis.

Le quatrième est le seuil de bascule défini à l'avance. À partir de quelle dégradation de latence, de coût ou de qualité déclenchez-vous un changement de fournisseur, et qui prend cette décision. Sans seuil écrit, la bascule se décide dans l'urgence, au pire moment, avec les arguments de la personne la plus insistante dans la réunion.

À mettre en route cette semaine

Lancez un test de bascule sur un service de production non critique : reroutez une fraction du trafic vers un modèle d'un fournisseur alternatif et chronométrez le temps réel entre la décision et le trafic réellement servi. Le chiffre obtenu est votre véritable indicateur de dépendance, pas l'architecture décrite dans la documentation.

Passez en revue les engagements pris auprès du métier pour les deux prochains trimestres et isolez ceux qui supposent la disponibilité d'un modèle non encore livré. Requalifiez-les en hypothèse plutôt qu'en engagement, et prévenez les parties prenantes avant que la date ne devienne un problème pour elles.

Étendez votre jeu d'évaluations à un deuxième fournisseur, même de façon partielle, sur les dix cas les plus représentatifs de votre usage. L'objectif n'est pas de départager les modèles mais de disposer d'une base de comparaison le jour où il faudra décider vite.

Écrivez les seuils de bascule et le nom de la personne qui déclenche la décision. Un document d'une page suffit, à condition qu'il existe avant l'incident et pas après.

Conclusion

Le retard de Gemini 3.5 Pro finira par se résorber, et Google livrera probablement un modèle compétitif. Ce qui restera, c'est la démonstration qu'aucun fournisseur, quelle que soit sa capitalisation, ne garantit une date de disponibilité. Les équipes qui ont conçu leur architecture pour rendre la substitution peu coûteuse traiteront cet épisode comme une information de marché. Celles qui ont adossé une feuille de route à un modèle non encore livré le traiteront comme une crise, et passeront le trimestre à reconstruire ce qui aurait dû être abstrait dès le départ.

Sources : As of July 2026

Godwin AVODAGBE