Une feuille de route de juin bâtie sur un modèle de juillet
Une responsable produit à Paris avait inscrit Gemini 3.5 Pro dans un plan de sortie de juin, avec une démonstration client organisée autour. Puis Google a repoussé le modèle au 17 juillet 2026 et, plus inhabituel encore, a dit avoir jeté l'architecture de base sous-jacente et l'avoir reconstruite de zéro. La démonstration repose désormais sur un modèle qui n'existe pas encore.
C'est la deuxième décision cachée dans une seule annonce. Google a fait un choix dur sur son propre produit. L'équipe parisienne en a fait un plus mou des mois plus tôt, quand elle a traité une date de lancement promise comme une donnée fixe. Une seule de ces deux décisions était disciplinée, et ce n'était pas celle de l'acheteur.
Pourquoi Google a jeté un modèle fini
Google DeepMind n'a pas ajusté l'ancien modèle ; il l'a abandonné. Des évaluations internes ayant fuité ont montré que l'ancienne architecture de base de Gemini 2.5 Pro tenait sur du texte simple, mais s'effondrait sur les appels d'outils récursifs et les mises en page complexes à plusieurs niveaux, et trébuchait sur le raisonnement mathématique. Plutôt que de livrer un produit phare qui échouait là où ses rivaux sont forts, Google a reconstruit la base et remis la date à zéro.
Le successeur vise une fenêtre de contexte de deux millions de jetons, une couche de raisonnement plus profonde et des flux de travail plus stables sur la durée, dirigés droit contre GPT-5.6 d'OpenAI et Fable 5 d'Anthropic. Le contexte n'était pas calme : des chercheurs de haut niveau sont partis chez OpenAI et Anthropic en juin, et Alphabet a perdu environ 225 milliards de dollars de valeur boursière en une seule séance le 22 juin. Livrer un produit phare faible dans cette situation aurait été l'erreur facile et coûteuse.
La discipline que la plupart des équipes sautent
Le difficile, avec un coût irrécupérable, c'est qu'il ressemble à un progrès. Un développement fini à quatre-vingt-dix pour cent, avec de l'argent réel et des mois déjà dépensés, est justement le projet que les équipes se convainquent de livrer. Le test rationnel ignore ce qu'un projet a coûté et demande seulement ce que vaut son achèvement à partir d'ici. Google a appliqué ce test à un modèle presque complet et l'a arrêté. La plupart des organisations, face au même développement presque prêt, le livrent puis gèrent les dégâts.
La leçon n'est pas que les retards sont bons ; c'est que la décision d'arrêter doit tenir à la valeur future, jamais à ce qui a déjà été investi. Si un projet ne franchit pas la barre pour laquelle il a été bâti, les mois engloutis sont perdus que vous livriez ou non, et livrer n'ajoute que le coût du nettoyage. Google vient d'avancer cette leçon en public, à l'échelle d'un produit phare.
Ce que cela change pour votre propre feuille de route
Traitez chaque modèle non publié comme une hypothèse datée, pas comme un engagement. Si un lancement est sur votre chemin critique, notez la date sur laquelle vous comptez, le modèle de repli que vous utiliserez en cas de glissement et le dernier jour où vous pouvez changer sans rompre une promesse client. Une dépendance notée se gère ; une qui ne vit que sur une diapositive vous gère.
Les entreprises qui ont souffert ce trimestre sont celles qui ont signé des livraisons contre un lancement qui n'avait pas eu lieu. La disponibilité est une variable d'achat, et ce mois-ci elle a bougé pour tout le monde en même temps. Planifiez sur ce qui est déjà livré, gardez une solution de rechange testée à un seul basculement, et laissez les fournisseurs porter leurs propres dates glissées au lieu de passer le risque à vos clients.
À lire ensuite: Pourquoi le laboratoire d'IA le plus précieux n'est-il plus le plus célèbre ? | Quand le croyant le plus investi dans l'IA prend du recul, que vous dit-il ?
