En 2026, lors du YC Startup School, la voix de Jeff Dean était un peu rauque.
Dès le début de l'interview, il expliqua qu'il avait perdu la voix, qu'il sonnait différent aujourd'hui. Mais cela n'affecta pas l'attention des auditeurs dans la salle. Face à lui, Diana Hu, partenaire de YC, aligna une série de noms suffisants pour entrer dans l'histoire de l'informatique : MapReduce, BigTable, TensorFlow, TPU, Gemini.
N'importe lequel de ces projets pourrait être le point culminant de la carrière d'un ingénieur. Pourtant, ils sont tous présents dans le parcours de Jeff Dean et d'un groupe d'ingénieurs de Google à ses côtés.
Diana ne fit pas de l'interview une simple rétrospective des réalisations. Elle s'intéressait davantage à une autre question : alors que l'IA générative a déjà envahi l'industrie logicielle, que regarde aujourd'hui Jeff Dean, ce spécialiste de la reconstruction des systèmes depuis les fondations ?
La réponse n'était pas des modèles plus grands.
Au cours de cette conversation d'environ une heure, Jeff Dean parla à plusieurs reprises de matériel d'inférence, d'énergie, de déplacement des données, d'ingénierie de contexte, d'agents de longue durée, de systèmes d'expérimentation automatisée, et de la manière dont les startups peuvent éviter l'affrontement direct avec les modèles généraux. Ses propos semblaient dispersés, mais ils suivaient une ligne directrice très claire : la prochaine étape de l'IA n'est pas seulement de rendre les modèles plus intelligents, mais de les intégrer dans un système capable de travailler à long terme, d'essayer et de se tromper en continu, de valider automatiquement et d'accumuler constamment des compétences.
Cela signifie également que la compétition dans l'IA passe de « qui a le plus grand modèle » à « qui peut mieux organiser l'intelligence ».
I. L'IA est déjà comme un ingénieur junior, mais ce n'est pas le changement le plus important
En mai 2025, Jeff Dean avait émis un jugement qui avait suscité un large débat : les capacités de l'IA sont proches de celles d'un ingénieur junior.
Un an plus tard, Diana lui demanda comment cette prédiction se réalisait.
La réponse de Jeff Dean fut directe. Il estima que ce jugement était « assez précis ». Les progrès des modèles en termes d'agents, de codage de flux longs et de tâches complexes étaient même plus rapides qu'il ne l'avait imaginé à l'époque.
« La capacité des modèles à accomplir des tâches de plus en plus complexes croît plus vite que ce à quoi je m'attendais », dit-il.
Plus notable encore, cette capacité ne se limite pas à l'écriture de code. De plus en plus de systèmes d'agents commencent à pénétrer les domaines scientifiques, techniques et autres spécialités. Ils ne se contentent pas de répondre à des questions, mais décomposent des tâches, utilisent des outils, exécutent des expériences, lisent des résultats, puis agissent en fonction des retours.
Comparer l'IA à un ingénieur junior peut facilement attirer l'attention sur le remplacement de la main-d'œuvre. Mais Jeff Dean se préoccupe davantage d'un autre changement : lorsqu'un « ingénieur junior » peut être dupliqué en dizaines, voire en centaines, et travailler en parallèle pendant des jours ou même des semaines, comment la manière d'organiser la production va-t-elle changer ?
Dans une équipe traditionnelle, l'ingénieur junior doit se familiariser avec les activités, comprendre les outils, recevoir des retours constants. Il en va de même pour un agent. Sauf que ses supports de formation ne sont plus seulement des documents, mais des invites (prompts), des descriptions d'outils, des fichiers de compétences, des systèmes de test, des évaluateurs et l'ensemble de l'environnement contextuel.
Cela crée une nouvelle division du travail dans l'ingénierie de l'IA.
Dans le passé, les ingénieurs étaient principalement responsables de l'écriture de code. À l'avenir, de plus en plus d'ingénieurs seront responsables de la définition des problèmes, de la mise en place des environnements, de la rédaction des spécifications, de la conception des boucles de rétroaction, puis de la planification d'un groupe d'agents pour accomplir les tâches.
La prédiction de Jeff Dean pour 2027 va dans ce sens. 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 nombreuses expériences, compareront les résultats, puis combineront les solutions efficaces pour former de nouveaux systèmes plus performants.
« Dès qu'un domaine a un objectif mesurable, il est possible de réaliser de grands progrès. »
Cette phrase est la première clé de toute l'interview.
Les domaines que l'automatisation par l'IA pénétrera en premier ne sont pas nécessairement ceux qui possèdent le plus de connaissances, mais ceux où la rétroaction est la plus claire. Est-ce que le code passe les tests ? La disposition des puces réduit-elle la surface ? L'architecture du modèle améliore-t-elle la précision ? Les propriétés des matériaux répondent-elles aux exigences ? Ces questions ont des critères d'évaluation relativement clairs. Tant que l'évaluateur est suffisamment fiable, la machine peut répéter les essais à une fréquence extrêmement élevée.
Ainsi, l'unité réellement importante à l'ère de l'IA n'est peut-être plus une réponse unique, mais une boucle complète : proposer une solution, l'exécuter, mesurer les résultats, corriger la direction.
II. Ce qui a changé la recherche Google, c'est un calcul arithmétique
De nombreux travaux emblématiques de Jeff Dean proviennent d'un point de départ très simple : commencer par 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 un accès lent. Jeff Dean et Sanjay Ghemawat firent une estimation et découvrirent 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 n'être qu'un changement de support de stockage. Mais à l'époque, cela signifiait une conception de système totalement différente.
Si l'index résidait principalement sur le disque dur, les requêtes devaient attendre le positionnement mécanique des têtes. En plaçant l'index en mémoire, la latence d'accès chutait considérablement. Les deux hommes écrivirent rapidement une nouvelle version et la mirent en environnement de production en quelques jours. La recherche Google devint ainsi nettement plus rapide.
Cette histoire peut facilement être embellie comme une illumination géniale. La manière dont Jeff Dean la raconte ressemble davantage à un ingénieur exposant du bon sens : les conditions du système changent, une solution qui ne fonctionnait pas devient soudainement viable, il faut donc la recalculer.
De nombreuses innovations sectorielles se produisent à de tels moments.
Un vieux problème persiste longtemps, les gens s'habituent à y apporter des rustines. Ensuite, le prix du matériel, la capacité mémoire, la bande passante réseau ou les capacités des modèles franchissent un certain seuil, et les anciennes contraintes disparaissent. Pourtant, la plupart des gens continuent d'utiliser l'ancienne architecture, car elle est devenue une évidence.
Ce que Jeff Dean sait bien faire, c'est retransformer l'évidence en hypothèse.
Il se demande : pourquoi cela doit-il forcément être ainsi ? Les ordres de grandeur d'aujourd'hui sont-ils les mêmes qu'hier ? Si on remplace l'étape la plus coûteuse, l'ensemble du système ne pourrait-il pas prendre une forme totalement différente ?
C'est aussi le conseil qu'il donne aux entrepreneurs. Ne regardez pas seulement ce qui ne va pas dans les solutions existantes, mais reconsidérez le problème à partir des principes premiers. Peut-on améliorer les performances d'un ordre de grandeur ? Réduire les coûts de deux ordres de grandeur ? Cesser de suivre les chemins de mise en œuvre par défaut du secteur ?
« Parfois, il suffit de regarder un problème en plissant les yeux, de ne pas se laisser ancrer par les solutions d'aujourd'hui, mais de réfléchir à partir des principes premiers à la manière dont il devrait être résolu. »
Cette phrase ne semble pas mystérieuse. La vraie difficulté est que la plupart des gens, lorsqu'ils entrent dans un secteur, apprennent rapidement toutes les réponses par défaut de ce secteur. L'expérience aide à améliorer l'efficacité, mais elle peut aussi faire perdre la capacité de reposer des questions.
III. Trois minutes de parole, pourquoi ont-elles donné naissance à un TPU
En 2013, la reconnaissance vocale par apprentissage profond de Google commença à dépasser significativement les anciens systèmes. Le taux d'erreur diminua de moitié, équivalant à vingt ans de progrès en reconnaissance vocale concentrés en quelques mois.
L'équipe produit était bien sûr enthousiaste. Jeff Dean fit d'abord un calcul.
Si la reconnaissance vocale s'améliorait vraiment, les utilisateurs seraient plus enclins à l'utiliser. Supposons que chaque utilisateur de Google n'utilise que trois minutes de reconnaissance vocale par jour, combien de serveurs Google aurait-il besoin pour le supporter ?
Le résultat n'était pas optimiste. Selon l'efficacité des CPU de l'époque, Google aurait peut-être besoin de doubler la taille de ses serveurs.
Ce fut le point de départ du TPU.
Il n'est pas né parce que l'équipe de recherche voulait soudainement fabriquer des puces, ni pour prouver que Google pouvait faire du matériel, mais parce qu'un modèle performant allait générer un coût de service insoutenable.
Cette histoire révèle une loi souvent négligée dans les produits d'IA : l'amélioration des performances d'un modèle ne réduit pas toujours les coûts. Au contraire, plus les performances sont bonnes, plus l'utilisation est importante, plus la pression sur le système est forte.
Lorsque la reconnaissance vocale fonctionnait mal, les utilisateurs la sollicitaient peu. Le coût du système n'était pas un problème. Lorsque le taux d'erreur chuta fortement, la demande fut soudainement libérée, et les contraintes de puissance de calcul, jusqu'alors cachées en arrière-plan, firent surface.
Le chemin choisi par le TPU fut de créer du matériel dédié au mode de calcul le plus fondamental de l'apprentissage automatique. Il n'avait pas besoin d'exécuter un navigateur ni de traiter tous les programmes généraux. Il excellait principalement dans l'algèbre linéaire dense en basse précision. Ce type de calcul se trouve justement au cœur de l'apprentissage automatique moderne.
La première génération de TPU finit par apporter un gain d'un ordre de grandeur. Selon Jeff Dean, elle était 30 à 80 fois plus économe en énergie que les CPU et GPU de l'époque, et avait une latence 20 à 30 fois plus faible.
Il y a ici une échelle de conception facilement négligeable.
Le TPU était très spécialisé, mais pas au point de ne pouvoir exécuter qu'un seul type de modèle fixe. L'équipe savait que les algorithmes d'apprentissage automatique évolueraient rapidement, elle conçut donc la puce comme un système d'algèbre linéaire relativement général. Elle sacrifiait la capacité à exécuter Chrome ou Word, mais conservait l'espace nécessaire pour supporter l'évolution future des algorithmes.
C'est un équilibre difficile à trouver. S'il n'est pas assez spécialisé, les gains ne sont pas évidents. S'il est trop spécialisé, lorsque l'algorithme change, le matériel devient obsolète.
Le jugement de Jeff Dean sur le matériel d'inférence actuel fait clairement écho au TPU de l'époque. Il estime que la prochaine vague d'opportunités importantes réside toujours dans la spécialisation, mais l'accent se déplacera davantage vers l'inférence à faible latence et faible consommation d'énergie.
« Imaginez ce que vous pourriez faire si la latence s'améliorait de 50 fois. »
Lorsque la réponse du modèle nécessite une dizaine de secondes, les gens le considèrent comme un outil occasionnel de consultation. Lorsque la latence est quasi instantanée, il peut véritablement intégrer les interfaces interactives, les robots, la vidéo en temps réel, les systèmes d'exploitation et les processus décisionnels continus.
L'attente n'est pas un simple problème d'expérience utilisateur. L'attente change la forme des produits.
IV. Le centre de coût de l'IA n'est pas le calcul, mais le déplacement des données
S'il fallait mettre à jour, pour les ingénieurs en IA de 2026, une version de « Les nombres de latence que chaque ingénieur doit connaître », Jeff Dean pense que l'accent devrait passer de la recherche sur disque, des défauts de cache et de la latence réseau intercontinentale, vers le flux de données à l'intérieur des puces.
Les ingénieurs doivent connaître : quelle est la bande passante entre la mémoire principale et la mémoire à l'intérieur de la puce, quelle est la bande passante entre la mémoire à l'intérieur de la puce et les unités de multiplication, combien d'énergie nécessite une multiplication, comment les puces sont interconnectées, comment l'efficacité du réseau diminuera lorsque l'on passera de 500 puces à 10 000 puces.
Ces chiffres semblent éloignés des produits, mais ils déterminent en réalité quels produits peuvent exister.
Jeff Dean donne une proportion très frappante. Réaliser une multiplication mathématique ne nécessite qu'environ un picojoule d'énergie. Déplacer des données de la mémoire à haute bande passante vers l'unité de calcul peut coûter environ 1000 fois plus cher en énergie.
Autrement dit, l'action coûteuse dans les systèmes d'IA actuels n'est souvent pas le « calcul », mais « le fait d'amener les choses à calculer ».
Cela explique aussi pourquoi le traitement par lots (batch) est si important.
Lorsqu'un ensemble de poids de modèle est transféré de la mémoire vers l'unité de calcul, s'il ne traite qu'un seul jeton (token), le coût du déplacement des données repose entièrement sur ce jeton. Si l'on traite simultanément un plus grand lot, le même ensemble de poids peut servir plus de calculs, et les coûts énergétiques et de bande passante sont amortis.
Mais le traitement par lots est naturellement en conflit avec la faible latence. Pour constituer un lot de requêtes, le système doit souvent attendre. Le débit augmente, mais la réponse à un utilisateur individuel peut ralentir.
Ainsi, de nombreux problèmes qui semblent appartenir à la couche des modèles sont en réalité des problèmes de matériel et de système. Pourquoi l'entraînement utilise-t-il de gros lots ? Pourquoi l'inférence a-t-elle besoin du KV Cache ? Pourquoi les modèles visent-ils la basse précision ? Pourquoi le système a-t-il besoin de la quantification ? Tout cela est lié aux contraintes de déplacement des données et d'énergie.
Jeff Dean s'intéresse davantage à l'inférence récemment, précisément parce que l'inférence est extrêmement sensible à la latence. Si une tâche d'entraînement est plus lente, cela ne fait souvent que retarder la fin de l'expérience. Si une tâche d'inférence attend une seconde de plus, cela affecte directement l'expérience utilisateur et l'efficacité de travail de l'agent.
Si un agent doit appeler le modèle en continu 1000 fois, une réduction de latence de 50 % par appel peut entraîner une énorme différence dans le temps d'exécution de l'ensemble de la tâche. Sans parler des agents qui devront fonctionner pendant des jours ou des semaines à l'avenir.
Par conséquent, le « problème énergétique » de l'IA n'est pas une question environnementale lointaine. Il détermine directement si les modèles peuvent servir plus de personnes à moindre coût, si les agents peuvent fonctionner en continu, et si la marge brute des startups est saine.
V. Le modèle n'est qu'une pièce, le contexte est le lieu de travail de l'agent
Ces dernières années, l'industrie de l'IA avait l'habitude de mesurer le 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 insiste davantage sur tout ce qui entoure le modèle.
Un système d'IA vraiment utile, outre le modèle, nécessite la recherche, les outils, la mémoire, les informations historiques, l'environnement d'exécution et les mécanismes de rétroaction. Le modèle doit connaître les outils disponibles, savoir quand les appeler, savoir comment décomposer un problème complexe en une série d'actions, et doit également pouvoir comparer plusieurs solutions pour juger laquelle a le plus de chances de réussir.
C'est pourquoi « l'ingénierie du contexte » commence à occuper le devant de la scène.
Jeff Dean explique que les informations vues par le modèle pendant la phase d'entraînement sont finalement « mélangées » dans des milliards, voire des milliers de milliards de paramètres. Elles ressemblent à un bouillon concentré, les connaissances y sont présentes mais pas nécessairement claires. Les informations réellement placées dans le contexte actuel sont plus directes pour le modèle et plus faciles à utiliser avec précision.
Cela laisse une opportunité importante aux petites équipes.
L'entraînement d'un modèle de base nécessite d'énormes capitaux, données et puissance de calcul. L'ingénierie du contexte peut commencer avec une simple API. Les entrepreneurs peuvent, autour d'une activité spécifique, organiser les connaissances du domaine, les flux d'outils, les données clients et les critères d'évaluation, pour rendre le modèle général plus fiable dans un scénario étroit.
Jeff Dean donne un exemple personnel.
Lui et Sanjay Ghemawat optimisent souvent les bibliothèques internes de bas niveau de Google. Ces structures de données peuvent s'exécuter sur des millions de processus, et une minuscule différence de performance est amplifiée par l'échelle. L'approche traditionnelle consiste à ce que les ingénieurs écrivent d'abord des micro-benchmarks, mesurent les performances actuelles, modifient le code, relancent les benchmarks, observent l'occupation du cache et les changements de performance, puis itèrent.
Les deux hommes ont codifié cette méthode de travail en une compétence d'agent. Le modèle a appris à exécuter des benchmarks, modifier du code, comparer des résultats, puis continuer à optimiser en fonction des mesures.
« Nous avons simplement fourni à l'agent, sous une forme qu'il peut utiliser, la méthode qu'un humain adopterait. »
Cette phrase peut presque être considérée comme la définition simple de l'ingénierie du contexte.
Il ne s'agit pas de techniques d'invite mystérieuses, ni d'empiler plus de matériel contextuel. Il s'agit de répondre à trois questions : quelles étapes un expert suivrait-il, quels outils fiables le système possède-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 plus de connaissances, mais une méthodologie exécutable de manière répétable.
C'est pourquoi « les compétences (skills) » deviendront un actif clé dans l'écosystème des agents. Un fichier de compétences excellent peut encapsuler des années d'expérience implicite d'une équipe. Il indique au modèle quoi faire en premier face à un certain type de problème, quelles erreurs sont les plus courantes, quels outils sont dignes de confiance, et quel résultat constitue une réalisation.
La différenciation future des entreprises ne résidera probablement pas seulement dans les poids des modèles, mais aussi dans ces expériences encodées dans les flux de travail.
VI. Pourquoi les agents commencent-ils à perdre le contrôle à l'étape 30
Presque toutes les équipes ayant réellement travaillé avec des agents ont rencontré le même scénario.
Les premières étapes se passent bien. Le modèle peut lire les exigences, utiliser des outils, écrire du code. Arrivé à l'étape 30 ou 50, il commence à oublier l'objectif, à mal interpréter l'état, à répéter des actions, ou à s'enfoncer dans une mauvaise direction.
Jeff Dean attribue l'une des raisons au problème de la distribution hors domaine (out-of-distribution).
Le modèle a vu de nombreuses tâches courantes pendant l'entraînement. Tant que la tâche reste sur la « voie éclairée » qu'il connaît, ses performances sont généralement bonnes. Dès que des opérations continues l'amènent à un état inconnu, ses performances chutent soudainement. Plus il s'éloigne de sa zone de confort, plus les erreurs s'accumulent facilement.
L'une des solutions consiste à fournir des compétences et des invites pour contraindre le modèle autant que possible sur des chemins qu'il connaît. Une autre méthode est d'utiliser des systèmes multi-agents.
Plusieurs agents peuvent essayer différentes solutions, puis un autre modèle joue le rôle d'évaluateur pour juger quelles directions sont plus prometteuses. Les branches qui échouent sont abandonnées, les branches qui réussissent progressent. Cela revient essentiellement à effectuer une recherche pendant la phase de raisonnement (inference).
Cette méthode n'est pas étrangère au fonctionnement des équipes humaines. Face à un problème complexe, une personne propose une solution, une autre examine les risques, une troisième exécute l'expérience. L'équipe ne mise pas tous ses espoirs sur la première idée, mais réduit les erreurs ponctuelles par la division du travail et les retours.
Plus un agent fonctionne longtemps, moins la conception du système peut reposer sur une seule réussite.
Un véritable agent de longue durée fiable nécessite des points de contrôle, une gestion d'état, des retours en arrière, l'exploration de branches, une évaluation externe, un contrôle des autorisations et une reprise sur erreur. Il ressemble davantage à un système distribué qu'à une fenêtre de chat très longue.
C'est là que l'origine de Jeff Dean redevient cruciale.
L'un des problèmes fondamentaux résolus par MapReduce était de permettre à un grand nombre de machines peu fiables d'effectuer des calculs fiables. Les systèmes d'agents d'aujourd'hui font face à une contradiction similaire : un appel de modèle individuel n'est pas parfait, les outils peuvent échouer, mais la tâche globale doit être accomplie aussi stablement que possible.
Les futures plates-formes d'agents performantes hériteront probablement de nombreuses idées 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, l'état peut être restauré, une erreur locale ne devrait pas détruire l'ensemble du processus.
Lorsque Jeff Dean dit que les agents fonctionneront pendant des jours, voire des semaines, il ne décrit pas une conversation plus longue. Il décrit une nouvelle infrastructure de calcul.
VII. Comment deux ou trois personnes peuvent-elles battre Google : chercher les problèmes où le taux de réussite du modèle n'est que de 1%
Dans le contexte du Startup School, la question la plus suivie est bien sûr celle des opportunités entrepreneuriales.
Google peut co-concevoir des puces, des centres de données, des modèles et des produits. Des modèles généraux comme Gemini continuent d'étendre rapidement leurs capacités. Comment une équipe de deux ou trois personnes peut-elle gagner ?
La réponse de Jeff Dean n'est pas romantique.
Les opportunités pour les petites équipes existent généralement dans des domaines spécifiques que les modèles généraux n'ont pas suffisamment explorés. 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 et une expérience supérieures dans un scénario étroit.
Mais il émet aussitôt un avertissement : les modèles généraux deviennent rapidement plus puissants. Des fonctionnalités produit qui semblent indépendantes aujourd'hui peuvent être directement couvertes par les modèles de base dans six ou douze mois.
Par conséquent, les entrepreneurs doivent évaluer si leur avantage est durable.
Jeff Dean donne un critère de filtrage très spécifique : recherchez les tâches pour lesquelles le taux de réussite actuel des modèles généraux est proche de 0% ou 1%, et non celles où ils atteignent déjà 20%.
« Si le modèle échoue complètement, c'est peut-être un bon signe. S'il peut déjà faire une partie, mais pas très bien, ce n'est pas nécessairement un bon signe. »
La raison est simple. 20% signifie que la capacité commence à apparaître. Davantage de données, un modèle plus grand et un raisonnement plus long peuvent rapidement le rendre utilisable. 0% ou 1% indiquent que la tâche manque peut-être de données clés, d'outils spéciaux, de retours sectoriels, ou nécessite une capacité que les modèles généraux auront du mal à acquérir à court terme.
Cela peut être appelé la « règle du 1% » de Jeff Dean.
Il ne suggère pas aux entrepreneurs de choisir uniquement les problèmes les plus difficiles, mais de rechercher les problèmes où les modèles généraux présentent des angles morts structurels.
Ces angles morts se divisent grossièrement en trois catégories.
La première concerne les données propriétaires. Les modèles généraux peuvent organiser l'information mondiale, mais ils n'ont pas nécessairement accès à l'intégralité des données personnelles d'un utilisateur, aux processus internes d'une entreprise, aux données en temps réel générées par un équipement. Une fois que le produit d'une startup obtient ces données, il peut former une vision différente de celle du modèle de base.
La deuxième concerne les évaluations professionnelles. De nombreux secteurs ne manquent pas de capacité de génération, mais d'un jugement fiable. La médecine, la science des matériaux, les puces, la fabrication et la recherche scientifique nécessitent des évaluateurs de haute qualité. Celui qui peut définir « ce qui est correct » peut permettre à l'agent d'optimiser continuellement.
La troisième concerne les modèles étroits et profonds. AlphaFold n'est pas un modèle de conversation général ; il a développé une capacité hautement spécialisée pour le problème de la structure des protéines. La science des matériaux, la conception de puces et d'autres domaines spécialisés peuvent également offrir des opportunités similaires.
Ce jugement n'est pas facile pour les entrepreneurs. Il exige que l'équipe comprenne à la fois les limites des capacités des modèles et les problèmes profonds du secteur. Ne comprendre que l'IA conduit à créer des fonctionnalités rapidement absorbées par la plateforme. Ne comprendre que le secteur peut conduire à sous-estimer la vitesse de progression des modèles.
La véritable opportunité se situe à l'intersection des deux.
VIII. Lorsque le code n'est plus rare, les spécifications, le goût et le choix des problèmes deviendront plus précieux
Diana émet une hypothèse : si, à l'avenir, chaque fondateur pouvait gérer simultanément 50, 100 agents, et que tout le code était écrit par des agents, quelle capacité deviendrait rare ?
La réponse de Jeff Dean est le « goût ».
Plus précisément, la capacité à juger ce que les agents devraient faire.
Il estime que la plus grande part de la valeur des travaux de recherche ne réside pas dans l'exécution impeccable des expériences, mais dans le choix d'un problème qui mérite d'être étudié. Une équipe peut utiliser les méthodes les plus raffinées pour accomplir une recherche insignifiante. Elle peut aussi saisir un problème clé qui, une fois résolu, change tout le domaine.
Lorsque les coûts d'exécution baissent grâce aux agents, l'importance du choix du problème augmentera encore.
Dans le passé, une idée vague disparaissait naturellement en raison des coûts de développement trop élevés. À l'avenir, tant qu'on peut mobiliser suffisamment d'agents, de nombreuses idées pourront être rapidement prototypées. Le monde ne verra pas automatiquement plus de bons produits, mais plus de produits tout court.
Les spécifications deviendront également plus importantes.
Jeff Dean explique que lors de la collaboration avec des agents virtuels, plus l'objectif est clair, plus le taux de réussite est élevé. Autrefois, une demande vague confiée à un ingénieur expérimenté pouvait être clarifiée par des questions et un contexte partagé. Bien que l'agent puisse aussi poser des questions, il est plus susceptible de deviner par lui-même en l'absence de contexte.
Une tâche typique à haut taux de réussite est la migration d'un logiciel d'un langage de programmation à un autre. La raison n'est pas que la migration est simple, mais que les spécifications sont extrêmement complètes. L'ancien code définit le comportement, les tests définissent les limites, l'agent peut vérifier point par point jusqu'à ce que la nouvelle version se comporte de manière identique.
« Maintenant, les agents peuvent écrire le logiciel à votre place, mais définir précisément ce que vous voulez devient plus important. »
Cette phrase a une implication directe pour les soi-disant organisations natives de l'IA.
Les futurs managers ne se contenteront pas d'attribuer des tâches, ils devront rédiger des objectifs et des critères d'acceptation plus clairs. Les documents de conception ne seront plus seulement des outils de communication d'équipe, mais aussi des entrées pour l'exécution machine. Les tests, indicateurs, contraintes et exemples passeront de la fin du processus de développement à la phase de définition de la tâche.
Quant à la manière d'entraîner le « goût », la méthode donnée par Jeff Dean est très pragmatique.
Notez une liste de choses que vous pensez importantes pour les 12 prochains mois. Vous n'êtes pas obligé de toutes les faire. Reconsultez la liste après 12 mois : quels jugements se sont réalisés, quels ont été réalisés par d'autres, quels n'ont pas progressé. En accumulant constamment des échantillons de prédiction, une personne affine progressivement son jugement.
Le goût n'est pas entièrement un talent inné. Il peut aussi être entraîné par la réflexion.
IX. Une bonne expérience de pensée commence par retirer la prémisse la plus solide du secteur
Dans la seconde moitié de l'interview, Jeff Dean partage une expérience de pensée assez folle.
Depuis 60 ans, l'industrie des semi-conducteurs recherche des transistors plus petits, plus stables, avec un taux d'erreur plus faible. Il est admis que les puces fabriquées selon la même conception doivent être aussi identiques que possible, et que les retournements de bits (bit flips) doivent être minimisés.
Mais dans les grands systèmes distribués, les ingénieurs ont depuis longtemps accepté que des composants individuels puissent tomber en panne. Les disques durs tombent en panne, les machines plantent, les commutateurs ont des problèmes. La fiabilité du système ne provient pas de l'infaillibilité de chaque composant, mais de la réplication, de la vérification, de la redondance et de la récupération.
Alors Jeff Dean demande : Et si les transistors faisaient 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éaliste. Il essaie simplement de retirer une prémisse considérée comme acquise. Peut-être que des transistors extrêmement peu fiables pourraient être fabriqués d'une manière totalement différente, et 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 pas en produits. De nombreuses pratiques sectorielles perdurent pendant des décennies pour de bonnes raisons. Mais Jeff Dean pense qu'il faut périodiquement revérifier ces raisons.
MapReduce est né d'un processus similaire.
Les premiers systèmes de crawl et d'index de Google contenaient beaucoup de code parallèle manuel, de points de contrôle et de logique de récupération après panne. Le véritable calcul métier était souvent simple, comme lire toutes les pages web pour déterminer la langue. Mais beaucoup de code système noyait cette intention simple.
Jeff Dean et Sanjay Ghemawat trouvèrent l'inspiration dans la programmation fonctionnelle. Ils abstrairent de nombreuses tâches en Map et Reduce, et firent descendre le parallélisme, l'ordonnancement, la tolérance aux pannes et les nouvelles tentatives dans un cadre unifié. Les développeurs métier n'avaient plus qu'à exprimer le calcul lui-même.
Cette conception n'a pas rendu les machines infaillibles. Elle a rendu les erreurs absorbables par le système.
L'ingénierie des agents d'aujourd'hui est peut-être dans une phase similaire. De nombreuses équipes orchestrent encore manuellement les invites, la logique de nouvelle tentative et les appels d'outils pour chaque tâche. À l'avenir, y aura-t-il une abstraction aussi simple que MapReduce, faisant de la décomposition, de la vérification, de la récupération et de l'exploration parallèle des agents de longue durée des capacités de base ?
C'est peut-être l'opportunité pour la prochaine génération d'entreprises d'infrastructure.
X. L'IA commence à construire de meilleures IA, la méthode scientifique est compressée en cycles à haute vitesse
La direction qui enthousiasme le plus Jeff Dean pour l'avenir est l'automatisation de la méthode scientifique elle-même.
Le processus de recherche traditionnel consiste à formuler une hypothèse, concevoir une expérience, l'exécuter, analyser les résultats, puis générer la prochaine série d'hypothèses. La vitesse de ce cycle a longtemps été limitée par le coût des expériences et le délai de validation.
L'IA peut changer deux aspects.
L'un est la proposition et l'exécution automatiques de plus d'expériences. L'autre est la transformation de validateurs coûteux en modèles approximatifs bon marché.
Jeff Dean prend l'exemple de la chimie quantique. Les chercheurs doivent déterminer les propriétés d'une configuration moléculaire ; ils peuvent exécuter une simulation de théorie de la fonctionnelle de la densité (DFT). Une simulation peut nécessiter une nuit entière. Les chercheurs de Google ont utilisé un grand nombre d'entrées et de sorties de simulation pour entraîner un réseau de neurones approximateur. Il approchait la précision du simulateur original, mais était environ 300 000 fois plus rapide.
Lorsque la vitesse de validation change, la forme des problèmes scientifiques change aussi.
Sélectionner 10 millions de candidats dans le passé pouvait être un projet nécessitant des mois de calcul. Maintenant, en une pause déjeuner, le système peut effectuer un premier tri. L'expérimentation n'est plus un pari unique précieux, mais devient une recherche à haute fréquence.
C'est aussi la logique commune derrière des systèmes comme AlphaEvolve, AlphaChip, etc. Le modèle propose des solutions, les outils les exécutent, l'évaluateur filtre les résultats, les meilleurs passent au tour suivant. Tant que la boucle est suffisamment rapide, le système peut continuer à explorer un immense espace de solutions.
L'apprentissage automatique lui-même deviendra également l'objet de cette science automatisée.
Aujourd'hui, les grandes équipes de recherche voient généralement des humains proposer de nouvelles architectures ou méthodes d'entraînement, exécuter d'abord des expériences à petite échelle, puis amplifier les solutions prometteuses. Jeff Dean estime qu'il n'y a pas d'obstacle fondamental empêchant les modèles de prendre en charge de plus en plus d'étapes de ce processus. Les humains donnent des orientations de haut niveau, 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 former de nouveaux modèles.
À l'avenir, l'indicateur mesurant l'efficacité de la recherche ne sera peut-être pas seulement les flops par seconde, mais « combien de découvertes efficaces sont générées par unité de puissance de calcul ».
La puissance de calcul est importante, bien sûr. La manière de la transformer en découvertes l'est encore plus.
XI. L'article sur la distillation rejeté par NeurIPS, et comment considérer l'échec
En 2014, Jeff Dean, Geoff Hinton et Oriol Vinyals soumirent un article sur la distillation des connaissances. Aujourd'hui, la distillation des connaissances est une méthode fondamentale pour la compression des modèles et le transfert de capacités. Un grand modèle sert de professeur pour transmettre ses capacités à des modèles étudiants plus petits, plus rapides et moins chers.
Cet article, qui a eu un impact profond par la suite, fut rejeté par NeurIPS cette année-là.
Un examinateur estima qu'il était « peu susceptible d'avoir un impact majeur ». Les lecteurs intéressés peuvent consulter l'article « Rejeté ≠ Échec ! Ces articles à fort impact ont été refusés par des conférences de premier plan » (lien non traduit).
Jeff Dean raconta cette expérience sans colère. Il dit que l'examinateur ne comprenait peut-être pas les problèmes pratiques auxquels sont confrontés les services d'IA à grande échelle. Pour Google, transformer un modèle large coûteux en un petit modèle pouvant servir des centaines de millions d'utilisateurs était clairement très important. Pour un examinateur se concentrant uniquement sur la nouveauté théorique, cela ne semblait pas nécessairement assez « fondamental ».
Après le rejet de l'article, l'équipe le publia sur arXiv. Le secteur le lut quand même et commença à l'utiliser.
Aujourd'hui, le modèle Flash de Gemini, capable de maintenir de solides capacités avec une taille réduite et une latence plus faible, utilise notamment la distillation comme méthode importante.
Cette histoire n'est pas seulement un récit motivant « la persévérance mène au succès ». Elle montre que les systèmes d'évaluation ont toujours des angles morts. La valeur d'une solution est parfois visible immédiatement uniquement par ceux qui ont réellement subi le goulot d'étranglement de ce système.
Pour les entrepreneurs, cela est également important.
Les rejets du marché, des investisseurs et des pairs peuvent signifier que la direction est erronée, ou simplement que l'autre partie ne se trouve pas sur le même terrain problématique. La différence réside dans le fait que l'équipe a ou non des preuves suffisamment concrètes pour savoir pourquoi ce problème est important, et pourquoi il peut être résolu maintenant.
Jeff Dean n'encourage pas à persévérer aveuglément. Il encourage à : comprendre le problème, valider continuellement, et ne pas considérer une évaluation comme le jugement définitif du monde.
XII. Que ferait le jeune Jeff Dean aujourd'hui
Lorsque l'interview touchait à sa fin, Diana posa une question imaginative.
Si l'on téléportait le jeune Jeff Dean de 1999, lorsqu'il rejoignit Google, en 2026, rejoindrait-il un laboratoire de pointe ou créerait-il une entreprise avec deux ou trois amis ?
Jeff Dean ne donna pas de réponse standard.
Les grandes organisations possèdent une structure, une plateforme et de nombreux collègues excellents. Une personne peut y accéder à des connaissances qu'elle ne possède pas, et influencer les utilisateurs mondiaux grâce à des produits matures. Les petites équipes sont plus libres, mais prennent plus de risques. Les fondateurs doivent vraiment croire en un problème, et être prêts à supporter l'incertitude pendant plusieurs années.
Le critère de jugement qu'il donne est plus fondamental que « rejoindre une grande entreprise ou créer une startup ».
« Si je résous ce problème, et que le meilleur résultat se produit réellement, le monde en deviendrait-il clairement meilleur ? Ou les gens diraient-ils simplement, hmm, c'est cool, et c'est tout ? »
Si la réponse n'est que « c'est cool », cela ne vaut peut-être pas la peine d'y consacrer son temps le plus précieux.
Il souligne aussi l'importance des compagnons. Il faut trouver des personnes aux capacités complémentaires, mais aussi des personnes peu égocentriques, enclines à collaborer et avec lesquelles il fait bon travailler. Les vrais problèmes difficiles nécessitent souvent un travail en commun de longue durée. Il est préférable que les membres de l'équipe possèdent chacun des outils que les autres n'ont pas, et continuent à enrichir leur « ceinture à outils » pendant le travail commun.
Ces propos ont une simplicité d'ingénieur à l'ancienne.
L'industrie de l'IA aime parler de croissance exponentielle, d'intelligence superieure et de financements colossaux. Jeff Dean finit par ramener le choix à trois petites choses : travailler sur un problème qui vous tient vraiment à cœur, travailler avec des personnes que vous aimez, et faire de son mieux pour rendre le monde meilleur.
Conclusion : À l'ère de l'IA, ce qui reste le plus rare, c'est encore de voir clairement le problème
Dans la carrière de Jeff Dean, il y a de nombreuses légendes souvent racontées.
Lui et Sanjay Ghemawat réécrivirent le système de recherche en quelques jours pour placer l'index en mémoire. Une estimation sur trois minutes de parole poussa Google à créer le TPU. MapReduce cacha le parallélisme massif et la tolérance aux pannes dans une abstraction unifiée. La distillation des connaissances passa d'un article rejeté à une technologie fondamentale de l'industrie.
Ces histoires peuvent facilement le faire passer pour un génie recevant constamment des inspirations.
Mais d'après cette interview, sa méthode est en fait très cohérente.
Calculer d'abord les ordres de grandeur. Trouver ensuite le véritable goulot d'étranglement. Puis remettre en question les hypothèses par défaut, établir une abstraction plus simple. Enfin, utiliser la mesure et la rétroaction pour faire évoluer le système en continu.
L'industrie de l'IA d'aujourd'hui traverse une transition similaire.
Les modèles sont déjà assez puissants pour assumer des tâches de niveau ingénieur junior. Ensuite, ce qui déterminera la productivité réelle n'est pas seulement le QI du modèle, mais le coût de l'inférence, l'organisation du contexte, la qualité des outils, la vitesse de validation et la fiabilité du fonctionnement de longue durée.
Les agents ressembleront de plus en plus à 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 capable d'accepter l'échec.
Les opportunités pour les startups ne disparaîtront pas non plus, elles deviendront simplement plus exigeantes. Il vaut mieux ne pas s'attaquer à des tâches que les modèles généraux accomplissent déjà à 20%, mais rechercher les problèmes dont le taux de réussite est encore proche de 0% ou 1%. Là peuvent se cacher des données propriétaires, des évaluateurs professionnels, des modèles sectoriels étroits, ou de nouvelles abstractions système.
Lorsque la génération de code devient moins chère, ce qui devient vraiment coûteux, c'est le problème lui-même.
Qu'est-ce qui mérite d'être fait ? Quelles contraintes sont dépassées ? Quel changement vient juste de franchir un point critique ? Quel système, s'il était 50 fois plus rapide, deviendrait un produit totalement différent ?
Jeff Dean n'a pas fourni une liste d'opportunités aux 6000 entrepreneurs. Il a donné une manière de penser plus durable.
Ne vous précipitez pas pour chasser les réponses les plus en vogue.
Calculez d'abord le problème.
Liens 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 officiel « Machine Heart » (ID:almosthuman2014), auteur : Panda
