Une IA infiniment rapide ne te sauvera pas : ce que dit Jeff Dean de Google

#Une phrase qui dérange tout le discours sur la vitesse de l'IA

À la GTC 2026 de Nvidia, Jeff Dean, chief scientist de Google DeepMind, a lâché une phrase qui coupe net l'enthousiasme ambiant autour des modèles toujours plus rapides :

"Si tu rends ton modèle infiniment rapide, tu obtiens — selon ce que tu fais — un facteur deux ou trois de réduction de latence si tes outils représentent une part significative de ce que l'agent fait."

Traduction : même avec un modèle qui répond en zéro seconde, ton agent ne sera pas dix fois plus rapide. Il sera deux à trois fois plus rapide. Le goulot d'étranglement a déjà changé de place.

Cet article explique pourquoi, ce que ça implique pour les développeurs qui construisent des agents avec Claude Code ou n'importe quel autre outil, et quelle est la prochaine bataille — qui n'est pas celle des modèles.

#La loi d'Amdahl, en une minute

L'argument de Dean repose sur un résultat classique en informatique : la loi d'Amdahl.

L'idée est simple. Imagine une tâche qui prend 10 minutes. Tu identifies que 5 minutes sont parallélisables (tu peux les faire en même temps que d'autres choses) et 5 minutes sont séquentielles (elles doivent se faire l'une après l'autre). Tu mets à disposition 1000 processeurs pour accélérer la partie parallélisable.

Au mieux, la partie parallèle passe de 5 minutes à quasi 0. La partie séquentielle, elle, prend toujours 5 minutes. Total : 5 minutes. Tu as divisé par 2 le temps total, pas par 1000.

Dean applique cette loi au cas d'un agent IA. Un agent, ce n'est pas juste "le modèle pense et répond". C'est une boucle qui alterne :

1. Le modèle raisonne (inférence LLM)
2. Le modèle appelle un outil (bash, API, compilateur, recherche web)
3. L'outil s'exécute et retourne un résultat
4. Le modèle lit le résultat et continue

Si l'étape 3 prend plusieurs secondes par appel, et que le modèle fait vingt appels dans une tâche, le temps total est dominé par les outils, pas par l'inférence. Accélérer le modèle ne touche pas à ce plafond.

#Les exemples concrets de Dean

Pour que l'argument soit tangible, Dean cite trois domaines où ce plafond se voit déjà.

Les compilateurs C. Un compilateur a été conçu pour un humain qui tape make une fois par minute. Son temps de démarrage — quelques centaines de millisecondes — est totalement invisible pour nous. Pour un agent qui compile cinquante fois pour tester cinquante variantes d'un patch, ce démarrage devient le goulot d'étranglement.

Les tableurs et documents bureautiques. Ouvrir un fichier Excel, naviguer vers une cellule, déclencher un recalcul : chaque étape prend une à deux secondes. Parfait pour un humain. Catastrophique pour un agent qui voudrait faire cent manipulations.

Les outils de codage. C'est le seul domaine où, selon Dean, la réingénierie est déjà en cours. Les LSP rapides, les IDE pensés pour les agents, les environnements d'exécution sandbox qui démarrent en quelques millisecondes — tout ça est né précisément parce que les développeurs d'agents ont rencontré le mur.

#Pourquoi ça concerne aussi les agents Claude

Tu n'as pas besoin de construire pour Google pour être touché par ce problème. Dès que tu utilises Claude Code avec des MCP, tu vis cette tension tous les jours.

Prends un cas simple : tu demandes à Claude Code de refactorer une fonction dans un projet Node. L'agent va :

• Lire le fichier source (quelques ms)
• Raisonner sur la refacto (quelques centaines de ms)
• Écrire le nouveau fichier (quelques ms)
• Lancer bun test pour vérifier (plusieurs secondes)
• Lire la sortie et décider

Si le test prend 8 secondes et le raisonnement 500 ms, rendre Claude 10x plus rapide ne te fait gagner que 450 ms sur une tâche de 8,5 secondes. Gain réel : 5%. Le vrai levier, c'est rendre les tests plus rapides, pas le modèle.

#Trois implications pour ceux qui construisent des agents

#1. Tes outils sont maintenant du code critique

Pendant vingt ans, la latence d'un outil CLI était un détail de confort. Tu vivais avec npm install qui prend 30 secondes parce que tu le lançais trois fois par jour. Un agent le lance trois fois par minute. La latence n'est plus un détail, c'est le budget de l'agent.

Concrètement : si tu écris un MCP ou un outil pour un agent, ton temps de démarrage et ta latence de réponse deviennent des métriques de premier ordre. Pas "ça marche", mais "ça marche en moins de 200 ms".

#2. Les outils taillés pour humains vont être remplacés

Dean l'affirme clairement : beaucoup d'outils existants — ERPs, CRMs, pipelines de données, interfaces d'admin — ont été conçus pour être utilisés par un humain à une cadence humaine. Leur interface suppose un navigateur, des clics, des temps d'attente acceptables.

Ces outils devront être réingénierés pour une cadence machine, soit en ajoutant des API rapides à côté, soit en étant remplacés par des alternatives pensées agent-first. C'est un chantier qui va durer plusieurs années et créer des opportunités pour de nouveaux produits.

#3. Le conseil "utilise Flash / Haiku" prend un autre sens

Quand Google pousse AI Mode sur Flash plutôt que sur Pro, ce n'est pas une économie de coûts déguisée. C'est une application directe de la même logique : si le goulot n'est pas dans le modèle, utiliser un modèle plus petit mais plus rapide libère de la capacité pour faire d'autres choses — plus d'appels d'outils, plus d'itérations, plus de résultats.

#Comment auditer ton propre agent

Si tu veux voir où passe ton temps quand Claude exécute une tâche, la méthode minimale tient en trois étapes.

#Étape 1 — Mesurer avant d'optimiser

Lance une tâche représentative et active les logs de temps. Pour Claude Code, tu peux demander à l'agent de tracer chaque appel d'outil avec son temps d'exécution. Exemple de prompt :

Pour cette tâche, note à chaque étape :
- le nom de l'outil appelé
- le temps d'exécution en ms
- si c'était bloquant ou en arrière-plan
Fais un résumé à la fin avec le pourcentage du temps passé par outil.

#Étape 2 — Identifier le goulot dominant

Tu vas probablement découvrir qu'un ou deux outils concentrent 70% du temps. Souvent : le lancement de tests, l'installation de dépendances, un appel réseau vers un service interne. C'est là que tes gains se trouvent.

#Étape 3 — Attaquer le goulot, pas le modèle

Si le goulot est bun test qui prend 8 secondes à cause de tests d'intégration lourds, tu as plusieurs options qui n'ont rien à voir avec le modèle : tests en parallèle, caching, mode watch, sous-ensemble de tests pour les vérifications rapides. Chaque seconde grattée sur cet outil rend l'agent plus rapide que n'importe quel upgrade de modèle.

#Le récapitulatif

L'argument de Jeff Dean est inconfortable parce qu'il déplace l'attention là où personne ne veut regarder : les outils, pas les modèles.

• Une IA infiniment rapide ne donne qu'un gain de 2 à 3x en latence d'agent, parce que les outils dominent le temps total (loi d'Amdahl)
• Les outils conçus pour un rythme humain — compilateurs, tableurs, interfaces — deviennent le vrai goulot dès qu'un agent les utilise à cadence machine
• Le vrai chantier des prochaines années n'est pas "un meilleur modèle" mais "des outils repensés pour des agents"
• En pratique, avant d'espérer le prochain modèle, chronomètre ton agent : tu trouveras des gains immédiats dans les outils que tu utilises déjà

La bonne nouvelle : contrairement à l'entraînement d'un modèle de frontière, rendre tes outils plus rapides est à portée de n'importe quel développeur. C'est exactement le genre de travail invisible qui sépare les démos impressionnantes des agents qui marchent vraiment.