Jeff Dean sur la prochaine phase de l'IA : du TPU aux agents auto-évoluants

À la YC Startup School 2026, la voix de Jeff Dean était un peu rauque.

Au début de l’interview, il a expliqué qu’il avait perdu la voix, et qu’il sonnait différent de d’habitude aujourd’hui. Mais cela n’a pas affecté l’attention du public. Diana Hu, associée de YC, assise en face de lui, a énuméré d’un seul souffle une série de noms dignes d’entrer dans l’histoire de l’informatique : MapReduce, BigTable, TensorFlow, TPU, Gemini.

Chaque projet suffirait à constituer une œuvre maîtresse de la carrière d’un ingénieur. Pourtant, ils sont regroupés dans le parcours de Jeff Dean et de ses collègues ingénieurs de Google.

Diana n'a pas fait de l'entretien un bilan de réalisations. Elle s'intéresse davantage à une autre question : alors que l'IA générative a déjà envahi l'industrie du logiciel, qu'est-ce que Jeff Dean, l'un des meilleurs spécialistes pour restructurer les systèmes à la base, observe aujourd'hui ?

La réponse n'est pas un modèle plus grand.

Au cours de cette conversation d’environ une heure, Jeff Dean a répétitivement abordé le matériel d’inférence, l’énergie, le déplacement des données, l’ingénierie du contexte, les agents à longue durée d’exécution et les systèmes automatisés d’expérimentation, ainsi que la manière dont les startups peuvent éviter une confrontation directe avec les modèles généraux. Ce qu’il a dit peut sembler dispersé, mais il y a derrière une ligne directrice très claire : la prochaine étape de l’IA ne consiste pas seulement à rendre les modèles plus intelligents, mais à les intégrer dans un système capable de fonctionner sur le long terme, d’expérimenter en continu, de valider automatiquement et d’accumuler progressivement des compétences.

Cela signifie également que la concurrence dans l'IA passe de « qui a le modèle le plus grand » à « qui peut mieux organiser l'intelligence ».

En mai 2025, Jeff Dean a fait un jugement qui a suscité un large débat : les capacités de l'IA approchent celles d'un ingénieur junior.

Un an plus tard, Diana lui a demandé comment la prédiction s'était réalisée.

La réponse de Jeff Dean est directe. Il estime que ce jugement est « assez précis ». Les progrès du modèle en matière d'agentisation, de codage sur de longs processus et de tâches complexes ont été encore plus rapides qu'il ne l'imaginait à l'époque.

« La capacité du modèle à accomplir des tâches de plus en plus complexes augmente plus vite que ce que j’attendais », a-t-il dit.

Plus remarquable encore, cette capacité ne se limite plus à l'écriture de code. De plus en plus de systèmes d'agents pénètrent dans les domaines scientifiques, techniques et autres professions spécialisées. Ils ne se contentent plus de répondre à des questions, mais décomposent les tâches, utilisent des outils, exécutent des expériences, lisent les résultats et poursuivent leurs actions en fonction des retours.

Comparer l'IA à un ingénieur junior incite à concentrer l'attention sur la substitution humaine. Mais Jeff Dean s'intéresse davantage à un autre changement : lorsque cet « ingénieur junior » peut être dupliqué en dizaines, voire centaines de copies, travaillant en parallèle pendant plusieurs jours ou semaines, comment la production organisationnelle va-t-elle évoluer ?

Dans une équipe traditionnelle, les ingénieurs juniors doivent s’approprier les activités métier, comprendre les outils et recevoir constamment des retours. Il en va de même pour les agents ; toutefois, leurs supports de formation ne se limitent plus aux documents, mais incluent des invites, des descriptions d’outils, des fichiers de compétences, des systèmes de tests, des évaluateurs, ainsi que l’ensemble du contexte.

Cela crée une nouvelle répartition des tâches dans le domaine de l'ingénierie de l'IA.

Par le passé, les ingénieurs se chargeaient principalement d'écrire du code. À l'avenir, un plus grand nombre d'ingénieurs se concentreront sur la définition des problèmes, la mise en place des environnements, la rédaction des spécifications, la conception des boucles de rétroaction, puis sur la coordination d'un groupe d'agents pour accomplir les tâches.

La prédiction de Jeff Dean pour 2027 est exactement celle-ci. Il estime que les systèmes d'apprentissage automatique participeront de plus en plus à l'amélioration des systèmes d'apprentissage automatique eux-mêmes. Ils décomposeront les objectifs en sous-problèmes, exécuteront automatiquement de nombreux expériences, compareront les résultats et combineront les solutions efficaces pour créer de nouveaux systèmes plus puissants.

Lorsqu'un domaine présente des objectifs mesurables, il existe des opportunités de réaliser de grands progrès.

This sentence is the first key to the entire interview.

L'automatisation par l'IA n'envahit pas nécessairement d'abord les domaines les plus knowledge-intensifs, mais ceux où les retours sont les plus clairs. Les codes peuvent-ils passer les tests ? La disposition des puces peut-elle réduire la surface ? La structure du modèle peut-elle améliorer la précision ? Les propriétés des matériaux répondent-elles aux exigences ? Ces questions ont des critères d'évaluation relativement précis. Dès lors que l'évaluateur est suffisamment fiable, la machine peut effectuer des essais répétés à une fréquence extrêmement élevée.

Ainsi, l'unité la plus importante à l'ère de l'IA ne sera peut-être plus une seule réponse, mais un cycle complet : proposer une solution, l'exécuter, mesurer les résultats et ajuster la direction.

Beaucoup des travaux emblématiques de Jeff Dean proviennent d'un point de départ très simple : d'abord, calculer les ordres de grandeur.

En 2001, la recherche Google dépendait encore largement des disques durs. Les disques durs avaient une grande capacité, mais une vitesse d'accès lente. Jeff Dean et Sanjay Ghemawat ont effectué une estimation et ont constaté que l'index de recherche complet de Google à l'époque pouvait déjà tenir dans la mémoire de tous les serveurs.

Aujourd'hui, cela semble simplement être une mise à niveau du support de stockage. Mais à l'époque, cela signifiait une conception de système complètement différente.

Si l'index est principalement stocké sur le disque dur, les requêtes doivent attendre le déplacement mécanique de la tête de lecture. En plaçant simplement l'index en mémoire, la latence d'accès chute drastiquement. Les deux hommes ont rapidement rédigé une nouvelle version et l'ont déployée en production quelques jours plus tard. La recherche Google est devenue nettement plus rapide.

Cette histoire est souvent présentée comme une illumination géniale. Cependant, la version de Jeff Dean ressemble davantage à un ingénieur exposant une évidence : les conditions du système ont changé, une solution précédemment invalide est soudainement devenue viable, il faut donc la réévaluer.

De nombreuses innovations industrielles se produisent à ce moment-là.

Un problème ancien persiste depuis longtemps, et les gens s'y sont habitués en y appliquant des correctifs. Plus tard, le prix du matériel, la capacité de la mémoire, la bande passante réseau ou la capacité du modèle franchit un seuil critique, et les contraintes initiales disparaissent. Pourtant, la plupart des gens continuent d'utiliser l'architecture ancienne, car elle est devenue une évidence.

Ce que Jeff Dean excelle à faire, c'est de transformer le bon sens en hypothèse.

Il demandera : Pourquoi faut-il absolument que ce soit ainsi ? Le volume d'aujourd'hui est-il le même que celui d'hier ? Si on remplace la étape la plus coûteuse, le système ne prendrait-il pas une forme complètement différente ?

C’est aussi ce qu’il conseille aux entrepreneurs : ne vous concentrez pas seulement sur les lacunes des solutions existantes, mais reconsidérez le problème à partir des principes fondamentaux. Peut-on augmenter les performances d’un ordre de grandeur ? Peut-on réduire les coûts de deux ordres de grandeur ? Peut-on abandonner les chemins de mise en œuvre par défaut de l’industrie ?

Parfois, il suffit de regarder un problème à travers un léger voile, sans s’ancrer à la solution d’aujourd’hui, mais en réfléchissant selon les principes fondamentaux la manière dont il devrait être résolu.

Cela ne semble pas mystérieux. La vraie difficulté réside dans le fait que la plupart des gens, une fois entrés dans un secteur, apprennent rapidement toutes les réponses par défaut de ce secteur. L'expérience améliore l'efficacité, mais elle fait aussi perdre la capacité de poser à nouveau des questions.

En 2013, la reconnaissance vocale par apprentissage profond de Google a commencé à dépasser nettement les anciens systèmes. Le taux d'erreur a été divisé par deux, ce qui équivaut à vingt ans de progrès en reconnaissance vocale concentrés en quelques mois.

L'équipe produit était bien sûr enthousiaste. Mais Jeff Dean a d'abord fait un calcul.

Si la reconnaissance vocale devient vraiment meilleure, les utilisateurs seront plus enclins à l'utiliser. Supposons qu'un seul utilisateur Google utilise la reconnaissance vocale trois minutes par jour, combien de serveurs Google aurait-il besoin pour le supporter ?

Les résultats ne sont pas optimistes. Selon l'efficacité des processeurs de l'époque, Google devrait peut-être doubler la taille de son infrastructure serveur.

C'est le point de départ de TPU.

Ce n'est pas parce que l'équipe de recherche a soudainement voulu concevoir des puces, ni pour prouver que Google est capable de fabriquer du matériel, mais parce qu'un modèle réussi allait engendrer un coût de service insoutenable.

Cette histoire révèle une régularité souvent négligée dans les produits d'IA : l'amélioration des performances du modèle ne réduit pas toujours les coûts. Au contraire, plus les performances sont bonnes, plus l'utilisation augmente, et plus la pression sur le système s'intensifie.

Lorsque la reconnaissance vocale ne fonctionne pas bien, les utilisateurs l'utilisent rarement. Le coût du système n'est pas un problème. Lorsque le taux d'erreur diminue fortement, la demande est soudainement libérée, et les contraintes de puissance de calcul auparavant cachées en arrière-plan deviennent visibles.

Le chemin choisi par TPU consiste à concevoir un matériel dédié au modèle de calcul le plus fondamental de l'apprentissage automatique. Il n'a pas besoin d'exécuter de navigateur ni de gérer tous les programmes généraux. Il excelle principalement dans l'algèbre linéaire dense et à faible précision. Ce type de calcul se situe exactement au cœur de l'apprentissage automatique moderne.

La première génération de TPU a finalement apporté un gain d'ordre de grandeur. Selon Jeff Dean, elle était 30 à 80 fois plus économe en énergie que les CPU et GPU de l'époque, avec une latence 20 à 30 fois plus faible.

Il existe également une échelle de conception souvent négligée.

TPU est très spécialisé, mais pas au point de ne pouvoir exécuter qu'un seul modèle fixe. L'équipe savait que les algorithmes d'apprentissage automatique évolueraient rapidement, elle a donc conçu la puce comme un système d'algèbre linéaire plus général. Elle a sacrifié la capacité d'exécuter Chrome ou Word, tout en conservant la possibilité de prendre en charge l'évolution future des algorithmes.

C'est un équilibre difficile à trouver. Trop peu de dédicace, et les rendements ne sont pas significatifs. Trop de dédicace, et un simple changement d'algorithme rend le matériel obsolète.

Le jugement de Jeff Dean sur les matérielles d'inférence d'aujourd'hui résonne clairement avec celui de la TPU à l'époque. Il estime que la prochaine grande opportunité réside toujours dans la spécialisation, mais que le focus se déplacera davantage vers l'inférence à faible latence et faible consommation d'énergie.

Imagine ce que tu pourrais faire si la latence pouvait être améliorée de 50 fois.

Lorsque la réponse du modèle prend plusieurs secondes, les gens le considèrent comme un outil consulté occasionnellement. Lorsque le délai approche l'instantanéité, il peut véritablement intégrer les interfaces interactives, les robots, les vidéos en temps réel, les systèmes d'exploitation et les processus de prise de décision continue.

L'attente n'est pas un simple problème d'expérience. L'attente modifie la forme du produit.

Si l'on devait mettre à jour la liste « Les chiffres de latence que chaque ingénieur devrait connaître » pour les ingénieurs en IA de 2026, Jeff Dean estime que l'accent devrait passer des temps d'accès au disque, des manques de cache et des latences réseau intercontinentales vers les flux de données à l'intérieur des puces.

Les ingénieurs doivent connaître : la bande passante entre la mémoire principale et la mémoire sur puce, la bande passante entre la mémoire sur puce et les unités de multiplication, l'énergie requise pour une seule multiplication, la manière dont les puces sont interconnectées, et comment l'efficacité du réseau diminue lorsqu'on passe de 500 puces à 10 000 puces.

Ces chiffres semblent éloignés du produit, mais ils déterminent en réalité quel produit peut réussir.

Jeff Dean a fourni une proportion extrêmement frappante. Effectuer une multiplication mathématique ne nécessite qu'environ un picojoule d'énergie. Déplacer les données de la mémoire à haute bande passante vers l'unité de calcul peut coûter environ 1000 fois plus d'énergie.

En d'autres termes, les actions coûteuses dans les systèmes d'IA aujourd'hui ne sont pas souvent « le calcul », mais « déplacer les données à calculer ».

Cela explique également pourquoi le traitement par lot est si important.

Une fois que les poids du modèle sont transférés de la mémoire vers l'unité de calcul, si un seul token est traité, le coût de transfert de données est entièrement supporté par ce seul token. En traitant simultanément un lot plus important, les mêmes poids peuvent servir davantage de calculs, répartissant ainsi le coût énergétique et en bande passante.

Mais le traitement par lots et la faible latence sont naturellement en conflit. Pour rassembler un lot de demandes, le système doit souvent attendre. Le débit augmente, mais la réponse pour un utilisateur individuel peut ralentir.

Ainsi, de nombreux problèmes qui semblent provenir de la couche modèle sont en réalité des problèmes matériels et systémiques. La raison pour laquelle l'entraînement utilise de grands lots, la raison pour laquelle l'inférence nécessite un KV Cache, la raison pour laquelle les modèles recherchent une faible précision, et la raison pour laquelle les systèmes nécessitent une quantification, sont toutes liées à la mobilité des données et aux contraintes énergétiques.

Jeff Dean se concentre actuellement davantage sur l'inférence, précisément parce que l'inférence est extrêmement sensible à la latence. Ralentir une tâche d'entraînement ne fait que retarder la fin de l'expérience. Chaque seconde supplémentaire d'attente lors d'une tâche d'inférence affecte directement l'expérience utilisateur et l'efficacité des agents.

Si un Agent doit appeler le modèle 1000 fois consécutivement, une réduction de 50 % de la latence par appel peut entraîner une différence considérable dans le temps total de accomplissement de la tâche. Sans parler du fait que, à l'avenir, les Agents devront s'exécuter pendant plusieurs jours ou semaines.

Ainsi, le « problème énergétique » de l’IA n’est pas un enjeu environnemental lointain. Il détermine directement si les modèles peuvent servir un plus grand nombre de personnes à moindre coût, si les agents peuvent fonctionner en continu, et si la marge brute des startups est saine.

Au cours des dernières années, l'industrie de l'IA a traditionnellement mesuré les progrès par le nombre de paramètres, les données d'entraînement et les scores de référence. En 2026, Jeff Dean met davantage l'accent sur tout ce qui entoure le modèle.

Un système AI véritablement utile, en plus du modèle, nécessite une récupération, des outils, une mémoire, des informations historiques, un environnement d'exécution et des mécanismes de retour. Le modèle doit connaître les outils disponibles, savoir quand les appeler, comment décomposer un problème complexe en une série d'actions, et être capable de comparer plusieurs solutions pour déterminer laquelle a le plus de chances de réussir.

C'est pourquoi l'ingénierie du contexte commence à prendre le devant de la scène.

Jeff Dean affirme que les informations vues par le modèle pendant la phase d'entraînement sont finalement « mélangées » dans des centaines de milliards, voire des trillions de paramètres. Elles ressemblent à une soupe épaisse : les connaissances sont présentes, mais pas nécessairement claires. Les informations réellement intégrées dans le contexte actuel sont plus directes pour le modèle et plus facilement utilisables avec précision.

Cela laisse une opportunité importante aux petites équipes.

Former un modèle de base nécessite un capital, des données et une puissance de calcul massifs. L'ingénierie de contexte, en revanche, peut commencer avec une API. Les entrepreneurs peuvent organiser les connaissances métier, les processus outillés, les données clients et les critères d'évaluation autour d'un business spécifique, afin de rendre un modèle généraliste plus fiable dans un scénario étroit.

Jeff Dean a donné un exemple personnel.

Il optimisait fréquemment les bibliothèques de base internes de Google avec Sanjay Ghemawat. Ces structures de données pouvaient s'exécuter sur des millions de processus, une Clic Les différences de performance sont amplifiées par l'échelle. La méthode traditionnelle consiste pour les ingénieurs à d'abord écrire des micro-benchmarks, mesurer les performances actuelles, puis modifier le code, relancer les benchmarks, observer l'utilisation du cache et les changements de performance, avant de continuer l'itération.

Les deux personnes ont documenté cette méthode de travail comme une compétence d'agent. Le modèle a appris à exécuter des benchmarks, à modifier le code, à comparer les résultats, puis à optimiser en fonction des mesures.

Nous lui avons simplement fourni les méthodes que les humains utilisent, sous une forme qu'il peut exploiter.

This sentence can almost be considered a naive definition of prompt engineering.

Ce n'est pas une astuce secrète de prompt, ni une accumulation de matériel contextuel. C'est répondre à trois questions : quelles sont les étapes suivies par les experts, quels outils fiables le système propose-t-il, et comment les résultats doivent-ils être vérifiés ?

Lorsque ces contenus sont structurés, le modèle n'acquiert pas davantage de connaissances, mais un ensemble de méthodes exécutables de manière répétée.

C’est pourquoi les « compétences (skill) » deviennent un actif clé dans l’écosystème des agents. Un bon fichier de compétence peut encapsuler des années d’expérience implicite d’une équipe. Il indique au modèle quoi faire en premier lorsqu’il rencontre un type de problème, quelles erreurs sont les plus courantes, quels outils sont fiables et ce qui constitue une tâche accomplie.

La différenciation des entreprises futures sera probablement présente non seulement dans les poids des modèles, mais aussi dans ces expériences intégrées aux flux de travail.

Presque toutes les équipes ayant réellement travaillé sur des agents ont déjà rencontré le même scénario.

Les premières étapes se déroulent bien. Le modèle peut lire les exigences, appeler des outils et écrire du code. À l'étape 30 ou 50, il commence à oublier l'objectif, à mal interpréter l'état, à répéter des actions ou à s'éloigner de plus en plus dans une mauvaise direction.

Jeff Dean attribue l'une des raisons à des problèmes hors distribution.

Le modèle a été exposé à de nombreuses tâches courantes pendant l'entraînement. Tant que la tâche reste sur la « voie familière » qu'il connaît, ses performances sont généralement bonnes. Dès qu'une série d'opérations le conduit à un état inconnu, ses performances chutent brusquement. Plus il s'éloigne de sa zone de confort, plus les erreurs ont tendance à s'accumuler.

L’une des solutions consiste à fournir des compétences et des conseils pour limiter le modèle aux chemins qu’il maîtrise. Une autre méthode consiste à utiliser un système multi-agent.

Plusieurs agents peuvent essayer différentes approches, tandis qu'un autre modèle agit comme évaluateur pour déterminer les directions les plus prometteuses. Les branches échouées sont éliminées, tandis que les branches réussies continuent d'avancer. Cela revient fondamentalement à effectuer une recherche pendant la phase d'inférence.

Il n'est pas étranger au fonctionnement de l'équipe humaine. Face à des problèmes complexes, une personne propose une solution, une autre évalue les risques, et une troisième lance des expériences. L'équipe ne mise pas tout sur la première idée, mais répartit les tâches et utilise les retours pour réduire les erreurs ponctuelles.

Plus l'agent fonctionne longtemps, moins le système doit dépendre d'une seule bonne exécution.

Un agent à long terme véritablement fiable nécessite des points de contrôle, une gestion d'état, des rollbacks, une exploration de branches, une évaluation externe, un contrôle des autorisations et une récupération en cas d'erreur. Il ressemble davantage à un système distribué qu'à une fenêtre de discussion extrêmement longue.

C'est précisément là que le parcours de Jeff Dean redevient essentiel.

L'un des problèmes fondamentaux résolus par MapReduce consiste à permettre à un grand nombre de machines peu fiables d'accomplir des calculs fiables. Les systèmes d'agents d'aujourd'hui font face à une contradiction similaire : une seule appel de modèle n'est pas parfait, les outils peuvent échouer, mais la tâche entière doit tout de même être accomplie aussi stablement que possible.

La plateforme d'agents excellente de l'avenir pourra intégrer de nombreuses idées provenant des systèmes distribués. Les tâches peuvent être divisées, les résultats peuvent être vérifiés, les échecs peuvent être réessayés, les états peuvent être restaurés, et une erreur locale ne doit pas détruire l'ensemble du processus.

Lorsque Jeff Dean dit que les agents fonctionneront pendant plusieurs jours ou même plusieurs semaines, il ne décrit pas une conversation plus longue. Il décrit une nouvelle infrastructure de calcul.

Dans le contexte de Startup School, la question la plus关注ée est bien sûr l'opportunité entrepreneuriale.

Google peut concevoir conjointement des puces, des centres de données, des modèles et des produits. Des modèles généraux comme Gemini étendent encore rapidement leurs limites de capacité. Comment une équipe de deux ou trois personnes pourrait-elle gagner ?

La réponse de Jeff Dean n'est pas romantique.

Les opportunités pour de petites équipes se trouvent généralement dans des domaines spécifiques que les modèles généraux n'ont pas suffisamment pris en compte. Les entrepreneurs peuvent combiner l'interface produit, les données propriétaires, les flux de travail et les compétences sectorielles pour offrir une précision plus élevée et une meilleure expérience dans un scénario restreint.

Mais il a immédiatement mis en garde : les modèles généraux deviennent rapidement plus puissants. Les fonctionnalités de produits qui semblent indépendantes aujourd'hui pourraient être directement couvertes par les modèles de base dans six ou douze mois.

Les entrepreneurs doivent donc évaluer si leurs avantages sont durables.

Jeff Dean a établi un critère de sélection très précis : rechercher des tâches dont le taux de réussite des modèles généraux actuels est proche de 0 % ou 1 %, et non celles qui atteignent déjà 20 %.

Si le modèle échoue complètement, cela pourrait être un bon signe. S’il parvient déjà à accomplir une partie de la tâche, mais le fait mal, ce n’est pas nécessairement un bon signe.

La raison est simple. 20 % signifie que les capacités commencent à apparaître. Plus de données, des modèles plus grands et une inférence plus longue permettront probablement de les rendre rapidement utilisables. 0 % ou 1 % indiquent que la tâche manque probablement de données clés, d'outils spécifiques, de retours du domaine, ou nécessite une capacité que les modèles généraux ne peuvent pas acquérir à court terme.

Cela peut être appelé la « règle du 1 % » de Jeff Dean.

Il ne s'agit pas de conseiller aux entrepreneurs de choisir uniquement les problèmes les plus difficiles, mais de rechercher des problèmes où les modèles généraux présentent des lacunes structurelles.

Il existe environ trois types de ces zones aveugles.

La première catégorie est les données propriétaires. Les modèles généraux peuvent organiser les informations du monde, mais ils ne peuvent pas nécessairement accéder à l'ensemble du profil d'un utilisateur, aux processus internes d'une entreprise ou aux données en temps réel générées par un appareil spécifique. Dès qu'un produit startup obtient ces données, il développe une perspective différente de celle des modèles de base.

La deuxième catégorie est l'évaluation professionnelle. De nombreux secteurs ne manquent pas de capacité de génération, mais de jugement fiable. La médecine, les matériaux, les puces, la fabrication et la recherche scientifique nécessitent tous des validateurs de haute qualité. Celui qui définit « ce qui est correct » peut permettre à l'agent de s'optimiser en continu.

La troisième catégorie est celle des modèles étroits mais profonds. AlphaFold n'est pas un modèle de discussion généraliste ; il a développé des capacités hautement spécialisées pour résoudre des problèmes liés à la structure des protéines. Des opportunités similaires pourraient également émerger dans les domaines de la science des matériaux, de la conception de puces et d'autres domaines spécialisés.

Ce jugement n'est pas facile pour les entrepreneurs. Il exige que l'équipe comprenne à la fois les limites des capacités du modèle et les problèmes profonds de l'industrie. Ne comprendre que l'IA, c'est risquer de créer des fonctionnalités rapidement absorbées par les plateformes. Ne comprendre que l'industrie, c'est risquer de sous-estimer la vitesse des progrès du modèle.

The real opportunity lies at the intersection of both.

Diana pose une hypothèse : si, à l'avenir, chaque fondateur peut gérer simultanément 50 ou 100 agents, et que tout le code est écrit par des agents, quelles compétences deviendront rares ?

La réponse de Jeff Dean est « le goût ».

Plus précisément, il s'agit de déterminer ce que l'Agent doit faire.

Il estime que la majeure partie de la valeur d'une recherche ne réside pas dans la perfection de l'exécution des expériences, mais dans le choix d'une question digne d'être étudiée. Une équipe peut utiliser les méthodes les plus sophistiquées pour mener à bien une recherche sans importance. Elle peut aussi s'attaquer à une question cruciale, dont la résolution pourrait transformer tout le domaine.

Après que l'agent ait réduit le coût d'exécution, l'importance du choix des problèmes augmentera encore.

Autrefois, une idée vague disparaissait naturellement en raison de coûts de développement trop élevés. À l'avenir, tant qu'on mobilise suffisamment d'agents, de nombreuses idées pourront être transformées rapidement en prototypes. Le monde ne verra pas pour autant apparaître automatiquement davantage de bons produits, seulement davantage de produits.

The specifications will also become more important.

Jeff Dean affirme que plus l'objectif est clair lors de la collaboration avec des agents virtuels, plus le taux de réussite est élevé. Par le passé, les demandes vagues étaient confiées à un ingénieur expérimenté, capable de poser des questions et de compléter l'intention grâce à un contexte partagé. Bien que les agents puissent également poser des questions, ils ont tendance à faire des suppositions en l'absence de contexte.

Une tâche à haut taux de réussite typique consiste à migrer un logiciel d’un langage de programmation à un autre. La raison n’est pas que la migration soit simple, mais que les spécifications soient extrêmement complètes. Le code ancien définit le comportement, les tests définissent les limites, et l’agent peut les comparer point par point jusqu’à ce que la nouvelle version se comporte de manière identique.

Maintenant, les agents peuvent écrire des logiciels pour vous, mais il devient plus important de bien expliquer ce que vous voulez exactement.

Cette phrase a des implications directes pour les organisations nativement basées sur l'IA.

Les futurs gestionnaires ne se limiteront pas à attribuer des tâches, mais devront définir des objectifs et des critères d'acceptation plus clairs. Les documents de conception ne seront plus seulement des supports de communication pour l'équipe, mais aussi des entrées pour l'exécution par les machines. Les tests, les indicateurs, les contraintes et les exemples seront déplacés depuis la fin du processus de développement jusqu'à la phase de définition des tâches.

Concernant la manière d'entraîner le « goût », Jeff Dean propose une approche très pragmatique.

Écrivez une liste de choses que vous pensez devenir importantes au cours des 12 prochains mois. Vous n'avez pas besoin d'en faire toutes. Réévaluez dans 12 mois : lesquelles se sont réalisées, lesquelles ont été réalisées par d'autres, et lesquelles n'ont pas avancé. En accumulant progressivement des prédictions, on affine progressivement son jugement.

Le goût n'est pas seulement un don. Il peut aussi être développé par l'analyse et l'entraînement.

Dans la seconde partie de l'interview, Jeff Dean a partagé une expérience de pensée assez folle.

Au cours des 60 dernières années, l'industrie des puces a toujours cherché à produire des transistors plus petits, plus stables et avec un taux d'erreurs plus faible. On supposait que les puces fabriquées selon le même design devaient être aussi identiques que possible, avec le moins de bits inversés possible.

Dans les grands systèmes distribués, les ingénieurs acceptent depuis longtemps qu'un composant unique puisse échouer. Les disques durs peuvent se détériorer, les machines peuvent tomber en panne, les commutateurs peuvent présenter des problèmes. La fiabilité du système ne provient pas du fait que chaque composant soit parfait, mais de la réplication, de la vérification, de la redondance et de la récupération.

Alors Jeff Dean a demandé : que se passerait-il si les transistors subissaient 20 erreurs par jour, au lieu d'une erreur tous les quelques millions d'années ?

Ce n'est pas un plan de produit réel. Il tente simplement d'éliminer une hypothèse courante. Peut-être que des transistors extrêmement peu fiables pourraient être fabriqués d'une manière complètement différente, tandis que le système garantirait les résultats grâce à des chemins multiples et à une redondance de haut niveau.

La plupart des expériences de pensée ne se transforment jamais en produits. De nombreuses pratiques industrielles persistent depuis des décennies, et il existe de bonnes raisons à cela. Mais Jeff Dean estime qu'il faut régulièrement réexaminer ces raisons.

MapReduce provient d'un processus similaire.

Les systèmes d'araignées et d'indexation de Google au début contenaient de nombreux codes parallèles manuels, des points de contrôle et des logiques de reprise après défaillance. Les calculs métier réels étaient souvent simples, comme lire tous les pages web et déterminer la langue de la page. Toutefois, une grande partie du code système noyait cette intention simple.

Jeff Dean et Sanjay Ghemawat ont puisé leur inspiration dans la programmation fonctionnelle. Ils ont abstrait de nombreuses tâches en des opérations Map et Reduce, en déplaçant la parallélisation, l'ordonnancement, la tolérance aux pannes et les réessais vers un cadre unifié. Les développeurs métier n'ont plus qu'à exprimer le calcul lui-même.

Cette conception n'a pas rendu la machine infaillible. Elle a rendu les erreurs absorbables par le système.

Les agents d'aujourd'hui pourraient également se trouver à un stade similaire. De nombreux équipes continuent de configurer manuellement les invites, les logiques de réessai et les appels d'outils pour chaque tâche. À l'avenir, un abstrait aussi simple que MapReduce émergera-t-il, permettant à la décomposition, à la validation, à la récupération et à l'exploration parallèle des agents à long terme de devenir des capacités sous-jacentes ?

Cela pourrait bien être l'opportunité pour les prochaines entreprises d'infrastructure.

Jeff Dean est le plus enthousiaste à l'idée d'automatiser la méthode scientifique elle-même.

Le processus traditionnel de recherche scientifique consiste à formuler une hypothèse, concevoir une expérience, la mener à bien, analyser les résultats, puis générer une nouvelle hypothèse. La vitesse de ce cycle a longtemps été limitée par le coût des expériences et les retards de validation.

L'IA peut modifier deux parties.

Une partie consiste à soumettre et exécuter automatiquement davantage d'expériences. L'autre partie consiste à transformer des validateurs coûteux en modèles d'approximation peu coûteux.

Jeff Dean a cité l'exemple de la chimie quantique. Pour déterminer les propriétés d'une configuration moléculaire, les chercheurs peuvent exécuter une simulation de la théorie de la fonctionnelle de la densité. Une seule simulation peut nécessiter une nuit entière. Les chercheurs de Google ont entraîné un approximateur neuronal à l'aide de nombreux jeux d'entrées et de sorties de simulations. Celui-ci atteint une précision proche de celle du simulateur original, tout en étant environ 300 000 fois plus rapide.

Après le changement de vitesse de vérification, la forme des questions scientifiques change également.

Autrefois, filtrer 10 millions de candidats pouvait être un projet nécessitant plusieurs mois de puissance de calcul. Aujourd'hui, le système peut effectuer le filtrage initial pendant le temps qu'un chercheur prend pour déjeuner. Les expériences ne sont plus des paris uniques et précieux, mais des recherches à haute fréquence.

C'est aussi la logique commune derrière des systèmes comme AlphaEvolve et AlphaChip. Le modèle propose des solutions, les outils les exécutent, et l'évaluateur filtre les résultats ; les meilleurs résultats passent à la prochaine itération. Tant que la boucle est suffisamment rapide, le système peut continuer d'explorer un espace de solutions immense.

L'apprentissage automatique deviendra lui-même un objet de cette science automatisée.

Aujourd'hui, les grandes équipes de recherche sont généralement dirigées par des humains qui proposent de nouvelles architectures ou méthodes d'entraînement, effectuent d'abord des expériences à petite échelle, puis sélectionnent les approches les plus prometteuses pour les amplifier. Jeff Dean estime qu'il n'existe aucun obstacle fondamental empêchant les modèles de prendre en charge un nombre croissant d'étapes. Les humains fournissent une direction globale, tandis que le système explore automatiquement les structures, les recettes de données et les stratégies d'entraînement, puis combine les expériences réussies pour créer de nouveaux modèles.

Les indicateurs futurs de l'efficacité de la recherche pourraient ne plus se limiter aux opérations en virgule flottante par seconde, mais plutôt à « la quantité de découvertes utiles générées par unité de puissance de calcul ».

La puissance de calcul est bien sûr importante. Il est encore plus important de savoir comment transformer cette puissance en découvertes.

En 2014, Jeff Dean, Geoff Hinton et Oriol Vinyals ont soumis un article sur la distillation de connaissance. Aujourd'hui, la distillation de connaissance est une méthode fondamentale dans la compression de modèles et le transfert de compétences. Les grands modèles, en tant qu'enseignants, transmettent leurs compétences à des modèles étudiants plus petits, plus rapides et moins coûteux.

Ce document, qui a eu un impact profond par la suite, a été rejeté par NeurIPS à l'époque.

Un relecteur a estimé qu'il « est peu probable qu'il ait un impact majeur ». Les lecteurs intéressés peuvent consulter « Refusé ≠ Échec ! Ces articles à fort impact ont tous été rejetés par des conférences de haut niveau ».

Jeff Dean n'a pas exprimé de colère en parlant de cette expérience. Il a déclaré que les relecteurs pourraient ne pas comprendre les défis réels auxquels sont confrontés les services AI à grande échelle. Pour Google, il est clairement essentiel de transformer des modèles coûteux et volumineux en modèles plus petits capables de servir des centaines de millions d'utilisateurs. Pour les relecteurs se concentrant uniquement sur la nouveauté théorique, cela ne semble peut-être pas suffisamment « fondamental ».

Après le rejet de l'article, l'équipe l'a publié sur arXiv. L'industrie l'a tout de même lu et a commencé à l'utiliser.

Aujourd'hui, le modèle Flash de Gemini maintient de fortes performances avec une taille réduite et une faible latence, et la distillation est l'une des méthodes clés permettant d'y parvenir.

Cette histoire ne se limite pas à un simple message d'encouragement du type « persévérer mène au succès ». Elle montre que tout système d'évaluation comporte des lacunes. La valeur d'une solution est parfois visible uniquement pour ceux qui ont réellement subi les goulets d'étranglement de ce système.

It is equally important for entrepreneurs.

Le rejet du marché, des investisseurs et des pairs peut signifier une mauvaise direction, ou simplement que l'autre partie n'est pas sur le même terrain de problème. La différence réside dans le fait que l'équipe dispose-t-elle de preuves suffisamment concrètes pour comprendre pourquoi ce problème est important et pourquoi il peut être résolu maintenant.

Jeff Dean n'encourage pas à persister aveuglément. Il encourage à comprendre le problème, à vérifier continuellement, puis à ne pas considérer une seule évaluation comme le jugement ultime du monde.

À la fin de l’interview, Diana a posé une question imaginaire.

Si le jeune Jeff Dean, qui a rejoint Google en 1999, était transporté en 2026, rejoindrait-il un laboratoire de pointe ou fonderait-il une entreprise avec deux ou trois amis ?

Jeff Dean n'a pas donné de réponse standard.

Les grandes organisations possèdent des structures, des plateformes et de nombreux collègues exceptionnels. Au sein de celles-ci, on peut accéder à des connaissances que l'on ne maîtrise pas encore et utiliser des produits matures pour influencer des utilisateurs à travers le monde. Les petites équipes, en revanche, offrent plus de liberté, mais aussi des risques plus élevés. Le fondateur doit véritablement croire en un problème et être prêt à endurer l'incertitude pendant plusieurs années.

Les critères qu'il a fournis sont plus fondamentaux que « rejoindre une grande entreprise ou créer sa propre entreprise ».

Si je résous ce problème et que le meilleur résultat se produit vraiment, le monde deviendra-t-il nettement meilleur, ou tout le monde dira simplement : « C’est cool », et c’est tout ?

Si la réponse n'est que « assez cool », alors il ne vaut probablement pas la peine d'investir son temps le plus précieux.

Il a également souligné l'importance des coéquipiers : il faut chercher des personnes aux compétences complémentaires, ainsi que des individus modestes, disposés à collaborer et à bien s'entendre. Les problèmes véritablement difficiles nécessitent souvent une collaboration à long terme. Les membres de l'équipe devraient idéalement posséder chacun des outils uniques, et continuer d'élargir leur « ceinture d'outils » au cours de leur travail commun.

Ces propos ont une simplicité d'ingénieur traditionnel.

L'industrie de l'IA aime parler de croissance exponentielle, d'intelligence supérieure et de financements massifs. Mais Jeff Dean revient finalement à trois petites choses : s'occuper d'un problème qui vous tient à cœur, travailler avec des personnes que vous aimez, et faire de son mieux pour améliorer le monde.

La carrière de Jeff Dean compte de nombreuses légendes racontées à plusieurs reprises.

Il a réécrit le système de recherche en quelques jours avec Sanjay Ghemawat pour charger l'index en mémoire. Une estimation de trois minutes pour une voix a poussé Google à créer des TPU. MapReduce a caché le parallélisme à grande échelle et la tolérance aux pannes derrière une abstraction unifiée. La distillation de connaissance est passée d'un article rejeté à une technologie fondamentale de l'industrie.

Ces histoires rendent facile d’imaginer qu’il est un génie en constante quête d’inspiration.

Mais d'après cet entretien, sa méthode est en réalité très cohérente.

Commencez par déterminer l'ordre de grandeur. Ensuite, identifiez le véritable goulot d'étranglement. Puis, remettez en question les hypothèses par défaut et établissez une abstraction plus simple. Enfin, utilisez la mesure et la rétroaction pour faire évoluer continuellement le système.

L'industrie de l'IA traverse aujourd'hui un moment de transition similaire.

Le modèle est déjà suffisamment puissant pour assumer des tâches de niveau ingénieur junior. Ce qui détermine désormais la productivité réelle, ce n'est pas seulement l'intelligence du modèle, mais le coût d'inférence, l'organisation du contexte, la qualité des outils, la vitesse de validation et la fiabilité à long terme.

Les agents deviendront de plus en plus comme des membres d'équipe. Mais ils ont besoin de spécifications claires, de compétences, de points de contrôle, d'évaluateurs, et d'un système qui accepte les échecs.

Les opportunités pour les startups ne disparaîtront pas, elles deviendront simplement plus exigeantes. Il vaut mieux éviter de s’attaquer à des tâches que les modèles généraux peuvent déjà accomplir à 20 %, et privilégier les problèmes dont le taux de réussite reste proche de 0 % ou 1 %. C’est là que l’on peut trouver des données propriétaires, des évaluateurs spécialisés, des modèles à domaine restreint ou de nouvelles abstractions systémiques.

Lorsque la génération de code devient de plus en plus bon marché, ce qui sera véritablement coûteux, ce sera le problème lui-même.

Qu'est-ce qui mérite d'être fait ? Quelles contraintes sont devenues obsolètes ? Quels changements viennent de franchir le point de bascule ? Quel système deviendrait un produit complètement différent s'il était 50 fois plus rapide ?

Jeff Dean n'a pas fourni une liste d'opportunités pour 6 000 entrepreneurs. Il a offert une manière de penser plus durable.

Ne vous précipitez pas pour suivre la réponse la plus populaire.

D'abord, calculez la question.

Lien de référence

https://x.com/ycombinator/status/2082938685071491219

https://www.ycrootaccess.com/p/jeff-dean-the-1-rule-for-building

Cet article provient du compte WeChat « Machine Heart » (ID : almosthuman2014), auteur : Panda