Google Cloud Next 2026 : 200 Milliards de Capex N'Achètent Pas la Maturité de Production

L'article d'Alex Scroxton dans Computer Weekly sur Google Cloud Next 2026 atterrit sur la bonne inquiétude — l'industrie produit trop de slop d'IA et pas assez de valeur — mais s'arrête un étage avant l'endroit où je voudrais avoir la conversation. En tant qu'ingénieur DevOps qui doit réellement mettre ces stacks en production à l'échelle enterprise, mon problème avec Cloud Next n'est pas le DJ set avec Gemini. C'est la distance entre la keynote et le runbook.

Thomas Kurian a ouvert l'événement avec une phrase qui devrait faire ciller n'importe quel SRE : « Vous avez dépassé le pilote, la phase expérimentale est derrière nous. » Il l'appuie d'un chiffre réel — trois quarts des clients Google Cloud utilisent déjà l'IA de Google d'une manière ou d'une autre — et d'un chèque réel : environ 200 milliards de dollars de capex engagés en infrastructure IA. Du nouveau silicium (TPU 8i pour l'inférence, TPU 8t pour l'entraînement). Le Gemini Agent Platform officiellement dévoilé. Le cas Capcom : un workbench multi-agent tournant 30 000 heures humaines par mois de travail. Citi Sky, un conseiller patrimonial bilingue construit sur l'intégralité du stack IA de Google.

Ça, c'est le package marketing. Le package technique, celui dont personne au Moscone n'avait envie de parler sur la scène principale, c'est la facture opérationnelle qui vient avec les mots « en production ».

La critique du slop est juste, mais ce n'est pas le problème porteur

La préoccupation centrale de Scroxton est créative : musique générée par IA, art généré par IA, le coût culturel de remplacer des humains par de la médiocrité statistique. C'est légitime, et je la partage en grande partie personnellement. Mais d'où je suis, le slop est en aval d'une décision plus dangereuse : envoyer des workloads IA dans des environnements de production partagés sans la maturité opérationnelle que ces environnements exigent.

Le slop dilue une playlist Spotify. Une mauvaise IA en production dans une banque dilue l'audit trail. La première chose est agaçante. La seconde est une invitation ouverte au régulateur.

Le cadrage hype-versus-réalité que choisit Computer Weekly est l'artistique. Moi je veux insister sur l'ingénierie, parce que c'est là que les corps vont apparaître.

« Au-delà du pilote » n'est pas un vibe. C'est une discipline.

Quand Kurian dit que la phase expérimentale est derrière nous, la traduction honnête est : beaucoup de clients ont un notebook Vertex AI, une clé API Gemini et au moins un feature flag qui pointe du vrai trafic vers un modèle. Ce n'est pas la même chose que « en production » au sens où une équipe paiements ou une équipe SRE utilise le terme.

Pour mettre un modèle en production, au sens que je défendrais devant un board ou un régulateur, il te faut au minimum :

• Une observabilité qui comprend le workload. Latence p99 par modèle et par route. Coût en tokens par requête. Cache hit rate. Eval drift sur un benchmark figé. Rien de tout cela ne vient « gratuitement » avec un déploiement Gemini Agent Platform. Tu le construis.
• Une attribution de coût jusqu'à l'équipe. Si trois pods partagent un endpoint d'inférence, qui paye quel pic ? Avec 200 Mds$ de capex en amont, la facture cloud cesse d'être une note de bas de page de la finance et devient une préoccupation primaire d'ingénierie.
• Une réponse à incident qui connaît les systèmes non déterministes. Un modèle correct hier et faux aujourd'hui n'est pas un bug de déploiement. C'est une régression comportementale sans cible claire de rollback. Le runbook doit le refléter.
• Une gouvernance qui survit à un audit. Lineage de quelle template de prompt a produit quelle décision, contre quelle version de modèle, avec quel contexte de retrieval. Si tu ne peux pas répondre à ça sous déposition, tu n'as pas un système de production. Tu as une démo avec du trafic.

Aucun de ces points n'a fait la une à Cloud Next. Ils ont été présumés. C'est le trou.

Le chiffre de Capcom, lu en SRE

Le workbench de Capcom est sincèrement impressionnant : un agent d'inspection visuelle sur Gemini Vision, un agent prédictif sur données historiques, un agent de savoir institutionnel, un agent d'efficacité données. Résultat, selon la keynote, « 30 000 heures humaines chaque mois ».

Lis ça en ingénieur DevOps, pas en CMO.

Trente mille heures par mois, c'est à peu près 170 ETP équivalents de travail d'agents tournant en continu contre des données de production. Les questions auxquelles je voudrais une réponse avant de signer :

• Quel est le SLO de chaque agent ? Pas le SLA du fournisseur du LLM. Le SLO composite end-to-end, incluant retrieval, post-traitement et la boucle de revue humaine.
• Quel est le failure mode quand l'agent prédictif se trompe silencieusement pendant une semaine ? Les prédictions ne crashent pas. Elles dérivent. Est-ce que tu as un eval offline qui tourne sur un golden set figé, et une alerte quand les sorties de l'agent divergent de plus de X% ?
• Qui est d'astreinte sur le stack d'agents ? Si l'agent d'efficacité du pod A affame l'index de retrieval du pod B en cache, qui page qui ? « L'équipe plateforme » ne marche que si elle existe et a l'autorité.
• Quel est le chemin de rollback ? Les modèles sont versionnés, mais les templates de prompts, les index de retrieval et les définitions d'outils, généralement non. Un mauvais changement dans l'un de ces trois peut dégrader la qualité sans déclencher une seule alarme de déploiement classique.

Rien d'exotique. C'est la checklist ennuyeuse SRE qui a fait la différence entre « on utilise l'IA » et « l'IA marche pour nous » depuis deux ans. Le ton de la keynote — la phase expérimentale est derrière nous — risque de pousser les clients dans le premier quadrant en sautant le second.

Le stack de l'Agent Platform : plus de couches, même astreinte

Le Gemini Agent Platform repose sur Vertex AI qui repose sur TPU qui repose sur la nouvelle génération 8i/8t. Du point de vue d'un acheteur, ça ressemble à une histoire intégrée. Du point de vue DevOps, ça ressemble à quatre couches de plus dans le graphe de dépendances, chacune avec son propre failure mode, son propre système de quotas, sa propre courbe de prix et sa propre console où un incident peut se planquer.

Mets ça en face de la réalité authentiquement multi-cloud de la plupart des entreprises et tu obtiens un schéma familier : un Gemini Agent qui s'intègre à des workloads sur AWS, des données dans Snowflake, de l'auth dans Okta, de l'observabilité partagée entre Datadog et un Grafana self-hosted. La slide propre du Moscone cache une pelote de fils.

Deux conséquences auxquelles je ferais attention en tant que CTO en ce moment :

1. Le vendor lock-in n'est plus une question d'achats, c'est une question opérationnelle. Une fois que tes templates de prompts, tes suites d'evals et ton orchestration d'agents vivent dans la plateforme d'un vendor, le coût de migration ne se mesure plus en licences mais en mois de travail SRE.
2. Les engagements de capex sont des paris que tu fais à la place de quelqu'un d'autre. Quand un hyperscaler annonce 200 Mds$ de capex, la promesse implicite est que les prix restent favorables pendant que la charge monte. Le risque implicite est que, trois ans plus tard, l'économie unitaire force un reset de prix qui atterrit directement sur la roadmap de ton équipe plateforme.

Aucun de ces deux risques n'est apocalyptique. Les deux sont le genre de risque que tu intègres dans un plan plateforme à trois ans quand tu l'écris honnêtement.

Citi Sky et la partie de l'annonce que j'endosse vraiment

Le cas que je dresserais contre la critique du slop est Citi Sky. Un conseiller patrimonial bilingue, construit sur le stack IA de Google, explicitement cadré comme augmentation des conseillers humains, pas comme substitution. Ce cadrage est celui que je répète à chaque post de ce blog : l'IA est implémentable et précieuse quand elle élargit ce qu'un expert peut faire par heure, pas quand elle essaie de remplacer l'expert.

Citi Sky laisse aussi un signal plus discret qui vaut le coup d'œil : une institution financière régulée ne mise pas un produit de conseil patrimonial sur l'IA sans contrôles sérieux en dessous. Quoi qu'ait montré la keynote, l'équipe derrière a du data lineage, du logging de décisions, de la revue model-risk-management et un pattern human-in-the-loop défendable face à l'OCC. C'est la partie de l'iceberg que le congrès ne met pas sur la slide.

Si ton initiative IA n'a pas un iceberg équivalent, tu n'as pas un Citi Sky. Tu as un chatbot avec une marque.

Ce que je voudrais voir à la keynote de l'année prochaine

Si Google Cloud Next 2027 veut convaincre les gens qui maintiennent réellement ces systèmes debout, voici ce que je mettrais sur la scène principale à la place d'un DJ Gemini :

1. Des patterns de production pour systèmes agentiques avec SLOs nommés. Pas « on tourne 30 000 heures par mois ». Montre-moi la latence p99, les bandes de eval drift et le taux de revue humaine, et dis-moi quels chiffres ne sont pas négociables.
2. Une histoire de cost-attribution de premier niveau. Par équipe, par agent, par route. Avec des primitives de chargeback dans la plateforme elle-même, pas bricolées par-dessus par chaque client.
3. Des failure modes honnêtes pour l'Agent Platform. Que se passe-t-il quand le retrieval est stale ? Quand les appels d'outils bouclent ? Quand une API en aval rate-limite un agent en plein milieu d'une conversation ?
4. Un modèle opérationnel de référence pour les équipes plateforme. Dimensionnement, rotation d'astreinte, séparation entre ingénieurs produit d'agents et ingénieurs plateforme. Le pitch Coinbase des solo operators purs est un extrême ; l'hypothèse non dite que l'hyperscaler absorbera la complexité opérationnelle pour toi est l'autre. Les deux sont fausses.
5. Une conversation adulte sur les evals. Comme l'a montré le propre paper ActionNex de Microsoft pour les AIOps, l'état de l'art sur les incidents réels tourne autour de 53% de recall. Ce n'est pas un chiffre que tu mets derrière un conseiller patrimonial sans une grosse couche de revue humaine. Le ton de la keynote devrait le refléter, pas le maquiller.

La ligne que je trace

Scroxton a raison : l'industrie produit trop de slop. Mais le slop est un problème d'économie créative. Le problème d'infrastructure — et c'est celui avec lequel je dois vivre — est que « en production » a été redéfini silencieusement comme « en appelant un LLM depuis une request path qui sert déjà des utilisateurs. » Ce n'est pas la même chose. La première chose exige des SLOs, de l'observabilité, du cost-attribution, de la gouvernance et de la réponse à incident conçus pour des systèmes non déterministes. La seconde exige une clé d'API.

Deux cents milliards de dollars de capex achètent beaucoup de TPUs. Ils n'achètent pas une équipe plateforme. Ils n'achètent pas un runbook. Ils n'achètent pas la maturité opérationnelle qui décide si l'IA dans ton stack est un multiplicateur de productivité ou un incident latent qui attend son premier mauvais vendredi.

Les entreprises qui gagneront les deux prochaines années d'IA ne seront pas celles qui ont adopté le plus vite. Ce seront celles dont l'équipe plateforme aura refusé d'appeler « production » quelque chose qui ne l'était pas encore.

---

Sources :

• Alex Scroxton, Google Cloud Next: It's time to create value, not slop, from the AI boom, Computer Weekly, 23 avril 2026. computerweekly.com
• Keynote Google Cloud Next 2026, Thomas Kurian — chiffres d'adoption clients, TPU 8i/8t, Gemini Agent Platform.
• Études de cas Capcom et Citi telles que présentées à Google Cloud Next 2026.

Tu mets de l'IA en production et tu ne sais pas si ta plateforme peut porter le poids opérationnel ? Parle à un CTO — on t'aide à séparer la keynote du runbook.