Veuillez accueillir l'ancien directeur de l'IA chez Tesla, Andrej Karpathy.

Je suis ravi d'être ici aujourd'hui pour vous parler du logiciel à l'ère de l'IA. On m'a dit que beaucoup d'entre vous sont étudiants — licence, master, doctorat, etc. — et que vous allez bientôt entrer dans l'industrie. C'est un moment extrêmement unique et très intéressant pour entrer dans l'industrie en ce moment. Fondamentalement, la raison en est que le logiciel change à nouveau. Je dis à nouveau parce que j'ai déjà donné cette conférence, mais le problème est que le logiciel ne cesse de changer, j'ai donc beaucoup de matière pour créer de nouvelles conférences. Il change de manière assez fondamentale. Le logiciel n'a pas beaucoup changé à un niveau aussi fondamental pendant 70 ans, puis il a changé deux fois assez rapidement au cours des dernières années. Il y a juste une quantité énorme de travail à faire, une quantité énorme de logiciels à écrire et à réécrire. Jetons un coup d'œil au domaine du logiciel. Si nous pensons à cela comme à la carte du logiciel, voici un outil cool appelé Map of GitHub. C'est tout le logiciel qui est écrit. Ce sont des instructions données à l'ordinateur pour effectuer des tâches dans l'espace numérique. Si vous zoomez ici, ce sont toutes sortes de dépôts différents, et c'est tout le code qui a été écrit. Il y a quelques années, j'ai observé que le logiciel changeait et qu'il y avait un nouveau type de logiciel, et j'ai appelé cela le Logiciel 2.0 à l'époque. L'idée ici était que le Logiciel 1.0 est le code que vous écrivez pour l'ordinateur. Le Logiciel 2.0, ce sont les réseaux de neurones, et en particulier, les poids d'un réseau de neurones. Vous n'écrivez pas ce code directement. Vous ajustez les jeux de données puis vous lancez un optimiseur pour créer les paramètres de ce réseau de neurones. À l'époque, les réseaux de neurones étaient vus comme juste un type différent de classifieur, comme un arbre de décision. Ce cadrage était beaucoup plus approprié. Maintenant, ce que nous avons est un équivalent de GitHub dans le domaine du Logiciel 2.0. Hugging Face est l'équivalent de GitHub pour le Logiciel 2.0. Il y a aussi Model Atlas, et vous pouvez visualiser tout le code qui y est écrit. Au cas où vous seriez curieux, le cercle géant, le point au milieu, ce sont les paramètres de Flux, le générateur d'images. Chaque fois que quelqu'un ajuste une LoRA sur un modèle Flux, vous créez un commit Git dans cet espace et vous créez un type différent de générateur d'images. Le Logiciel 1.0 est le code informatique qui programme un ordinateur. Le Logiciel 2.0, ce sont les poids qui programment les réseaux de neurones. Voici un exemple d'AlexNet, un réseau de neurones de reconnaissance d'images. Jusqu'à présent, tous les réseaux de neurones que nous connaissions étaient des ordinateurs à fonction fixe — image vers catégories ou quelque chose comme ça. Ce qui a changé, et c'est un changement assez fondamental, c'est que les réseaux de neurones sont devenus programmables avec les grands modèles de langage. Je vois cela comme nouveau et unique. C'est un nouveau genre d'ordinateur. Dans mon esprit, cela mérite une nouvelle désignation de Logiciel 3.0. Vos prompts sont maintenant des programmes qui programment le LLM. Remarquablement, ces prompts sont écrits en anglais. C'est un langage de programmation très intéressant. Pour résumer la différence, si vous faites de la classification de sentiments, par exemple, vous pouvez imaginer écrire une certaine quantité de Python pour faire la classification de sentiments, ou vous pouvez entraîner un réseau de neurones, ou vous pouvez prompter un grand modèle de langage. Ceci est un prompt few-shot, et vous pouvez imaginer le changer et programmer l'ordinateur d'une manière légèrement différente.

Nous avons le Logiciel 1.0, le Logiciel 2.0, et nous voyons — peut-être avez-vous vu que beaucoup de code GitHub n'est plus seulement du code, il y a un tas d'anglais intercalé avec le code. Il y a une catégorie croissante d'un nouveau type de code. Non seulement c'est un nouveau paradigme de programmation, mais il est aussi remarquable que ce soit dans notre langue maternelle, l'anglais. Quand cela m'a époustouflé il y a quelques années, j'ai tweeté ceci et cela a capté l'attention de beaucoup de gens. C'est mon tweet actuellement épinglé : remarquablement, nous programmons maintenant des ordinateurs en anglais. Quand j'étais chez Tesla, nous travaillions sur l'autopilote et nous essayions de faire conduire la voiture. J'ai montré cette diapositive à l'époque où vous pouvez imaginer que les entrées de la voiture sont en bas et qu'elles passent par une pile logicielle pour produire la direction et l'accélération. J'ai fait l'observation qu'il y avait une tonne de code C++ dans l'autopilote, qui était le code Logiciel 1.0, puis il y avait des réseaux de neurones faisant de la reconnaissance d'images. J'ai observé qu'au fil du temps, à mesure que nous améliorions l'autopilote, le réseau de neurones gagnait en capacité et en taille. En plus de cela, tout le code C++ était supprimé, et beaucoup des capacités et fonctionnalités qui étaient initialement écrites en 1.0 ont été migrées vers le 2.0. À titre d'exemple, une grande partie de l'assemblage des informations entre les images des différentes caméras et à travers le temps a été effectuée par un réseau de neurones et nous avons pu supprimer beaucoup de code. La pile Logiciel 2.0 a littéralement dévoré la pile logicielle de l'autopilote. J'ai trouvé cela remarquable à l'époque. Je pense que nous voyons la même chose se reproduire là où nous avons un nouveau type de logiciel et il dévore la pile. Nous avons trois paradigmes de programmation complètement différents. Si vous entrez dans l'industrie, c'est une bonne idée de maîtriser les trois car ils ont tous de légers avantages et inconvénients et vous pourriez vouloir programmer certaines fonctionnalités en 1.0, 2.0 ou 3.0. Allez-vous entraîner un réseau de neurones ? Allez-vous simplement prompter un LLM ? Est-ce que cela devrait être un morceau de code explicite ? Nous devons tous prendre ces décisions et potentiellement passer de manière fluide entre ces paradigmes.

Ce que je voulais aborder maintenant, c'est d'abord parler des LLM et de la façon de penser à ce nouveau paradigme et à l'écosystème. Qu'est-ce que ce nouvel ordinateur ? À quoi ressemble-t-il et à quoi ressemble l'écosystème ? J'ai été frappé par cette citation d'Andrew Ng il y a plusieurs années. Andrew va parler juste après moi. Il a dit à l'époque que l'IA est la nouvelle électricité. Cela capture quelque chose de très intéressant dans le fait que les LLM ont certainement des propriétés de services publics en ce moment. Les laboratoires de LLM comme OpenAI, Gemini, Anthropic, etc., dépensent du CAPEX pour entraîner les LLM et cela équivaut à construire un réseau électrique. Ensuite, il y a l'OPEX pour servir cette intelligence via des API à nous tous. Cela se fait par un accès mesuré où nous payons par million de tokens. Nous avons beaucoup d'exigences qui ressemblent beaucoup à celles d'un service public. Nous exigeons une faible latence, une haute disponibilité, une qualité constante, et ainsi de suite. Dans l'électricité, vous auriez un commutateur de transfert pour pouvoir transférer votre source d'électricité du réseau au solaire, à la batterie ou à un générateur. Pour les LLM, nous avons OpenRouter et nous pouvons facilement basculer entre les différents types de LLM qui existent. Parce que les LLM sont des logiciels, ils ne sont pas en compétition pour l'espace physique. Il est possible d'avoir six fournisseurs d'électricité et vous pouvez basculer entre eux parce qu'ils ne sont pas en compétition d'une manière aussi directe. Ce qui est aussi fascinant — et nous l'avons vu ces derniers jours — beaucoup de LLM sont tombés en panne et les gens étaient bloqués et incapables de travailler. Il est fascinant que lorsque les LLM de pointe tombent en panne, c'est une baisse de tension de l'intelligence dans le monde. C'est comme lorsque la tension est instable sur le réseau et la planète devient simplement plus bête à mesure que nous dépendons de ces modèles, ce qui est déjà spectaculaire et continuera de croître. Mais les LLM n'ont pas seulement des propriétés de services publics. Ils ont certaines propriétés de fonderies (fabs). La raison est que le CAPEX requis pour construire des LLM est assez important. Il ne s'agit pas seulement de construire une centrale électrique. Vous investissez une somme d'argent énorme et l'arbre technologique de la technologie croît assez rapidement. Nous sommes dans un monde où nous avons des arbres technologiques profonds, de la recherche et du développement, et des secrets qui se centralisent à l'intérieur des laboratoires de LLM. Mais l'analogie se brouille aussi un peu parce qu'il s'agit de logiciel, et le logiciel est un peu moins défendable parce qu'il est si malléable. C'est juste une chose intéressante à laquelle réfléchir. Il y a beaucoup d'analogies que vous pouvez faire. Un nœud de processus de 4 nanomètres pourrait être quelque chose comme un cluster avec certains FLOPS max. Vous pouvez penser à quand vous utilisez des GPU NVIDIA et que vous ne faites que le logiciel et pas le matériel, c'est le modèle sans usine (fabless). Mais si vous construisez aussi votre propre matériel et que vous vous entraînez sur des TPU si vous êtes Google, c'est comme le modèle Intel où vous possédez votre fonderie. L'analogie qui a le plus de sens est que les LLM ont de très fortes analogies avec les systèmes d'exploitation. Ce n'est pas seulement de l'électricité ou de l'eau. Ce n'est pas quelque chose qui sort d'un robinet comme une commodité. Ce sont des écosystèmes logiciels de plus en plus complexes. Ce ne sont pas de simples commodités comme l'électricité. L'écosystème se façonne d'une manière très similaire où vous avez quelques fournisseurs de source fermée comme Windows ou macOS, puis vous avez une alternative open source comme Linux. Pour les LLM également, nous avons quelques fournisseurs propriétaires concurrents et ensuite l'écosystème Llama est une approximation proche de quelque chose qui pourrait devenir comme Linux. C'est encore très tôt car ce ne sont que des LLM simples, mais nous commençons à voir qu'ils vont devenir beaucoup plus compliqués. Il ne s'agit pas seulement du LLM lui-même ; il s'agit de toute l'utilisation d'outils et des multimodalités et de la façon dont tout cela fonctionne. Quand j'ai eu cette prise de conscience, j'ai essayé de l'esquisser et il m'a semblé que les LLM sont un nouveau système d'exploitation. Le LLM est un nouveau genre d'ordinateur. Il se situe comme l'équivalent du CPU. Les fenêtres de contexte sont comme la mémoire. Le LLM orchestre la mémoire et le calcul pour la résolution de problèmes en utilisant toutes ces capacités. Si vous le regardez, cela ressemble beaucoup à un système d'exploitation de ce point de vue. Quelques analogies de plus : si vous voulez télécharger une application, disons que je vais sur VS Code et que je vais sur télécharger, vous pouvez télécharger VS Code et l'exécuter sur Windows, Linux ou Mac. De la même manière, vous pouvez prendre une application LLM comme Cursor et l'exécuter sur GPT, Claude ou la série Gemini. C'est juste un menu déroulant. C'est similaire de cette façon aussi. Plus d'analogies qui me frappent : nous sommes dans cette ère des années 1960 où le calcul LLM est encore très cher pour ce nouveau genre d'ordinateur. Cela oblige les LLM à être centralisés dans le cloud et nous ne sommes que des clients légers qui interagissent avec lui via le réseau. Aucun d'entre nous n'a l'utilisation complète de ces ordinateurs, et par conséquent, il est logique d'utiliser le temps partagé où nous sommes tous une dimension du lot (batch) lorsqu'ils font tourner l'ordinateur dans le cloud. C'est tout à fait à quoi ressemblaient les ordinateurs pendant cette période. Les systèmes d'exploitation étaient dans le cloud, tout était diffusé, et il y avait du traitement par lots. La révolution de l'informatique personnelle n'a pas encore eu lieu parce que ce n'est tout simplement pas économique, mais certaines personnes essaient. Il s'avère que les Mac Minis conviennent très bien à certains LLM car si vous faites de l'inférence par lots de un, tout dépend de la mémoire, donc cela fonctionne. Ce sont quelques indications précoces de l'informatique personnelle, mais cela n'est pas encore vraiment arrivé. On ne sait pas à quoi cela ressemble. Peut-être que certains d'entre vous pourront inventer ce que c'est ou comment cela devrait être. Une autre analogie que je mentionnerai : chaque fois que je parle à ChatGPT ou à un LLM directement par texte, j'ai l'impression de parler à un système d'exploitation via le terminal. C'est du texte ; c'est un accès direct au système d'exploitation. Une interface graphique (GUI) n'a pas encore été inventée de manière générale. ChatGPT devrait-il avoir une GUI différente de simples bulles de texte ? Certainement, certaines des applications que nous allons aborder ont une GUI, mais il n'y a pas de GUI pour toutes les tâches.

Il y a certaines façons dont les LLM sont différents des systèmes d'exploitation et de l'informatique primitive. J'ai écrit sur cette propriété particulière qui me semble très différente cette fois-ci. Les LLM inversent la direction de la diffusion technologique qui est habituellement présente. Par exemple, avec l'électricité, la cryptographie, l'informatique, le vol, Internet, le GPS — beaucoup de nouvelles technologies transformatrices — typiquement le gouvernement et les entreprises sont les premiers utilisateurs car c'est nouveau et cher, et ce n'est que plus tard que cela se diffuse aux consommateurs. Mais pour les LLM, c'est inversé. Avec les premiers ordinateurs, tout tournait autour de la balistique et de l'usage militaire, mais avec les LLM, tout tourne autour de la façon de faire cuire un œuf. Il est fascinant que nous ayons un nouvel ordinateur magique et qu'il m'aide à faire cuire un œuf. Il n'aide pas le gouvernement à faire quelque chose comme de la balistique militaire. En effet, les entreprises et les gouvernements sont à la traîne dans l'adoption de ces technologies. C'est à l'envers, et je pense que cela informe certaines des utilisations de la façon dont nous voulons utiliser cette technologie ou de ce que sont certaines des premières applications. En résumé jusqu'à présent : les labos de LLM fabriquent des LLM. Je pense que c'est un langage précis à utiliser. Mais les LLM sont des systèmes d'exploitation compliqués. Nous sommes vers les années 1960 de l'informatique, et nous refaisons l'informatique à nouveau. Ils sont actuellement disponibles via le temps partagé et distribués comme un service public. Ce qui est nouveau et sans précédent, c'est qu'ils ne sont pas entre les mains de quelques gouvernements et entreprises ; ils sont entre les mains de nous tous car nous avons tous un ordinateur et c'est entièrement du logiciel. ChatGPT a été projeté sur nos ordinateurs, pour des milliards de personnes, instantanément et du jour au lendemain, et c'est insensé. C'est insensé que ce soit le cas et c'est maintenant à nous d'entrer dans l'industrie et de programmer ces ordinateurs. Je pense que c'est tout à fait remarquable. Avant de programmer des LLM, nous devons passer un peu de temps à réfléchir à ce que sont ces choses, et j'aime particulièrement parler de leur psychologie. La façon dont j'aime penser aux LLM, c'est qu'ils sont des esprits de personnes. Ce sont des simulations stochastiques de personnes. Le simulateur dans ce cas se trouve être un Transformer autorégressif. Un Transformer est un réseau de neurones et il fait bloc, bloc, bloc, bloc, bloc. Il y a une quantité de calcul presque égale pour chaque bloc. Ce simulateur est fondamentalement composé de poids et nous l'adaptons à tous les textes que nous avons sur Internet. Vous vous retrouvez avec ce genre de simulateur, et parce qu'il est entraîné sur des humains, il possède cette psychologie émergente qui ressemble à celle des humains. La première chose que vous remarquerez, c'est que les LLM ont des connaissances et une mémoire encyclopédiques. Ils peuvent se souvenir de beaucoup de choses, beaucoup plus que n'importe quel humain individuel car ils lisent tellement de choses. Cela me rappelle le film Rain Man, que je recommande de regarder. C'est un film incroyable. Dustin Hoffman est un savant autiste qui a une mémoire presque parfaite. Il peut lire un annuaire téléphonique et se souvenir de tous les noms et numéros de téléphone. Les LLM sont très similaires. Ils peuvent se souvenir des hachages SHA et de beaucoup de types de choses différentes très facilement. Ils ont certainement des super-pouvoirs à certains égards, mais ils ont aussi des déficits cognitifs. Ils hallucinent pas mal. Ils inventent des choses et n'ont pas un très bon modèle interne de connaissance de soi. Cela s'est amélioré mais n'est pas parfait. Ils affichent une intelligence en dents de scie. Ils vont être surhumains dans certains domaines de résolution de problèmes et puis ils vont faire des erreurs qu'aucun humain ne ferait. Ils vont insister sur le fait que 9.11 est plus grand que 9.9 ou qu'il y a deux R dans 'strawberry'. Ce sont des exemples célèbres. Il y a des aspérités sur lesquelles on peut trébucher. Ils souffrent aussi d'amnésie antérograde. Si vous avez un collègue qui rejoint votre organisation, ce collègue va apprendre au fil du temps votre organisation et acquérir une énorme quantité de contexte. Il rentre chez lui, dort, consolide ses connaissances et développe une expertise. Les LLM ne font pas cela nativement et ce n'est pas quelque chose qui a été résolu dans la R&D des LLM. Les fenêtres de contexte sont comme la mémoire de travail, et vous devez programmer la mémoire de travail assez directement car ils ne deviennent pas plus intelligents par défaut. Beaucoup de gens se laissent piéger par les analogies de cette façon. Dans la culture populaire, je recommande aux gens de regarder ces deux films : Memento et Amour et Amnésie (50 First Dates). Dans ces deux films, les poids des protagonistes sont fixés et leur fenêtre de contexte est effacée chaque matin. C'est problématique d'aller au travail ou d'avoir des relations quand cela arrive, et cela arrive aux LLM tout le temps. Une chose de plus que je signalerais concerne les limitations liées à la sécurité de l'utilisation des LLM. Les LLM sont assez crédules. Ils sont sensibles aux risques d'injection de prompt. Ils pourraient divulguer vos données, et il y a beaucoup d'autres considérations liées à la sécurité. Pour faire court, vous devez simultanément penser à cette chose surhumaine qui a des déficits cognitifs et des problèmes. Pourtant, ils sont extrêmement utiles. Comment les programmons-nous et comment contournons-nous leurs déficits tout en profitant de leurs pouvoirs surhumains ?

Ce sur quoi je veux passer maintenant, ce sont les opportunités sur la façon dont nous utilisons ces modèles et quelles sont certaines des plus grandes opportunités. Ce n'est pas une liste exhaustive, juste quelques points que je trouvais intéressants. La première chose qui m'enthousiasme, c'est ce que j'appellerais les applications à autonomie partielle. Prenons l'exemple du code. Vous pouvez aller directement sur ChatGPT et copier-coller du code et des rapports de bugs pour obtenir du code. Pourquoi feriez-vous cela ? Pourquoi iriez-vous directement au système d'exploitation ? Il est beaucoup plus logique d'avoir une application dédiée à cela. Beaucoup d'entre vous utilisent Cursor ; moi aussi. Cursor est ce que vous voulez à la place. Vous ne voulez pas simplement aller directement sur ChatGPT. Cursor est un très bon exemple d'une application LLM précoce qui possède des propriétés utiles à toutes les applications LLM. En particulier, vous remarquerez que nous avons une interface traditionnelle qui permet à un humain d'entrer et de faire tout le travail manuellement. En plus de cela, nous avons maintenant cette intégration LLM qui nous permet de travailler par plus gros morceaux. Certaines des propriétés des applications LLM qui sont partagées et utiles à souligner : premièrement, les applications LLM font essentiellement une tonne de gestion de contexte. Deuxièmement, elles orchestrent de multiples appels aux LLM. Dans le cas de Cursor, il y a sous le capot des modèles d'encastrement (embeddings) pour tous vos fichiers, les modèles de chat réels, et des modèles qui appliquent des diffs au code, et tout cela est orchestré pour vous. Un point vraiment important qui n'est pas toujours pleinement apprécié est la GUI spécifique à l'application et son importance. Vous ne voulez pas simplement parler au système d'exploitation directement en texte. Le texte est difficile à lire, à interpréter et à comprendre, et vous ne voulez pas effectuer certaines de ces actions nativement en texte. Il est bien mieux de voir un diff avec des changements en rouge et vert afin de voir ce qui est ajouté ou soustrait. Il est beaucoup plus facile de faire Commande-Y pour accepter ou Commande-N pour rejeter. Je ne devrais pas avoir à le taper en texte. La GUI permet à un humain d'auditer le travail de ces systèmes faillibles et d'aller plus vite. Je reviendrai sur ce point plus tard également. La dernière fonctionnalité que je veux souligner est ce que j'appelle le curseur d'autonomie. Dans Cursor, vous pouvez simplement faire de l'auto-complétion par tabulation où vous êtes principalement aux commandes. Vous pouvez sélectionner un morceau de code et faire Commande-K pour changer juste ce morceau. Vous pouvez faire Commande-L pour changer tout le fichier, ou vous pouvez faire Commande-I, qui le laisse agir et faire ce qu'il veut dans tout le dépôt. C'est la version agentique en pleine autonomie. Vous contrôlez le curseur d'autonomie, et selon la complexité de la tâche à accomplir, vous pouvez régler le degré d'autonomie que vous êtes prêt à céder. Pour montrer un autre exemple d'application LLM réussie : Perplexity. Elle a aussi des caractéristiques très similaires à ce que j'ai souligné dans Cursor. Elle regroupe beaucoup d'informations, elle orchestre plusieurs LLM, elle a une GUI qui vous permet d'auditer une partie de son travail — par exemple, elle citera des sources et vous pouvez imaginer les inspecter — et elle a un curseur d'autonomie. Vous pouvez soit faire une recherche rapide, soit faire de la recherche, soit faire de la recherche approfondie et revenir 10 minutes plus tard. Tout cela n'est que des niveaux d'autonomie variables que vous cédez à l'outil. Ma question est : je sens que beaucoup de logiciels deviendront partiellement autonomes. J'essaie de réfléchir à ce à quoi cela ressemble. Pour beaucoup d'entre vous qui maintenez des produits et services, comment allez-vous rendre vos produits et services partiellement autonomes ? Un LLM peut-il voir tout ce qu'un humain peut voir ? Un LLM peut-il agir de toutes les manières qu'un humain pourrait agir ? Et les humains peuvent-ils superviser et rester dans la boucle de cette activité car ce sont des systèmes faillibles qui ne sont pas encore parfaits ? À quoi ressemble un diff dans Photoshop ? Beaucoup de logiciels traditionnels ont actuellement tous ces commutateurs conçus pour un humain. Tout cela doit changer et devenir accessible aux LLM. Une chose sur laquelle je veux insister avec beaucoup de ces applications LLM est que nous coopérons maintenant avec des IA, et généralement elles s'occupent de la génération et nous, en tant qu'humains, nous occupons de la vérification. Il est dans notre intérêt de faire en sorte que cette boucle aille aussi vite que possible afin d'avancer dans le travail. Il y a deux manières majeures de le faire. Numéro un : vous pouvez accélérer énormément la vérification. Les GUI sont extrêmement importantes pour cela car une GUI utilise le GPU de vision par ordinateur dans notre tête. Lire du texte demande un effort, mais regarder des choses est une autoroute vers votre cerveau. Les GUI sont très utiles pour auditer les systèmes et pour les représentations visuelles en général. Numéro deux : nous devons garder l'IA en laisse. Beaucoup de gens s'enthousiasment trop pour les agents IA, et il ne m'est pas utile de recevoir un diff de 1 000 lignes de code pour mon dépôt. Je suis toujours le goulot d'étranglement. Même si les 1 000 lignes sortent instantanément, je dois m'assurer que cette chose n'introduit pas de bugs, qu'elle fait la bonne chose et qu'il n'y a pas de problèmes de sécurité. Nous devons faire en sorte que le flux entre ces deux-là soit très rapide et nous devons garder l'IA en laisse car elle devient beaucoup trop réactive. C'est ce que je ressens quand je fais du code assisté par IA. Si je code juste au feeling (vibe coding), tout est sympa et génial, mais si j'essaie vraiment de faire du travail, ce n'est pas si génial d'avoir un agent sur-réactif qui fait tout ce genre de trucs. J'essaie de développer des façons d'utiliser ces agents dans mon flux de travail de programmation et de faire du code assisté par IA. Dans mon propre travail, j'ai toujours peur de recevoir des diffs bien trop gros. Je procède toujours par petits morceaux incrémentaux. Je veux m'assurer que tout est bon. Je veux faire tourner cette boucle très vite et je travaille sur de petits morceaux d'une seule chose concrète. Je pense que beaucoup d'entre vous développent probablement des façons similaires de travailler avec les LLM. J'ai aussi vu un certain nombre d'articles de blog qui essaient de développer ces meilleures pratiques pour travailler avec les LLM. En voici un que j'ai lu récemment qui discutait de certaines techniques, et certaines d'entre elles concernent la façon dont vous gardez l'IA en laisse. Par exemple, si votre prompt est vague, l'IA pourrait ne pas faire exactement ce que vous vouliez et dans ce cas la vérification échouera. Vous allez demander autre chose. Si la vérification échoue, vous allez commencer à tourner en rond. Il est beaucoup plus logique de passer plus de temps à être plus concret dans votre prompt, ce qui augmente la probabilité d'une vérification réussie et vous pouvez aller de l'avant. Beaucoup d'entre nous finiront par trouver des techniques comme celle-ci. Dans mon propre travail, je m'intéresse actuellement à ce à quoi ressemble l'éducation maintenant que nous avons l'IA et les LLM. Une grande partie de ma réflexion porte sur la façon dont nous gardons l'IA en laisse. Je ne pense pas que cela fonctionne d'aller sur ChatGPT et de dire : 'Hé, apprends-moi la physique'. L'IA se perd dans les bois. Pour moi, il s'agit de deux applications distinctes. Il y a une application pour un enseignant qui crée des cours et une application qui prend des cours et les sert aux étudiants. Dans les deux cas, nous avons maintenant cet artefact intermédiaire d'un cours qui est auditable et nous pouvons nous assurer qu'il est bon et cohérent. L'IA est tenue en laisse par rapport à un certain programme et à une progression de projets. C'est une façon de garder l'IA en laisse et cela a une probabilité beaucoup plus élevée de fonctionner sans que l'IA ne se perde dans les bois.

Une autre analogie à laquelle je voulais faire allusion : je ne suis pas étranger à l'autonomie partielle et j'ai travaillé là-dessus pendant cinq ans chez Tesla. C'est aussi un produit à autonomie partielle et il partage beaucoup de caractéristiques, comme la GUI de l'autopilote dans le tableau de bord qui me montre ce que le réseau de neurones voit. Nous avons le curseur d'autonomie où au cours de mon mandat là-bas, nous avons fait des tâches de plus en plus autonomes pour l'utilisateur. L'histoire que je voulais raconter brièvement est la première fois que j'ai conduit un véhicule autonome en 2013. J'avais un ami qui travaillait chez Waymo et il m'a proposé de faire un tour autour de Palo Alto. J'ai pris cette photo en utilisant les Google Glass à l'époque. Beaucoup d'entre vous sont si jeunes que vous ne savez peut-être même pas ce que c'est, mais c'était la grande mode. Nous sommes montés dans cette voiture et avons fait environ 30 minutes de trajet autour de Palo Alto, sur des autoroutes, des rues, et ainsi de suite. Ce trajet était parfait. Il y a eu zéro intervention. C'était en 2013, il y a maintenant 12 ans. Cela m'a frappé parce que quand j'ai eu ce trajet parfait, cette démo parfaite, j'ai eu l'impression que la conduite autonome était imminente. Mais nous voici 12 ans plus tard et nous travaillons toujours sur l'autonomie. Nous travaillons toujours sur des agents de conduite. Même maintenant, nous n'avons pas encore totalement résolu le problème. Vous pouvez voir des Waymos circuler et elles semblent sans conducteur, mais il y a encore beaucoup de téléopération et beaucoup d'humains dans la boucle. Nous n'avons même pas encore déclaré victoire, mais cela va certainement réussir. Cela a juste pris beaucoup de temps. Ce logiciel est vraiment délicat de la même manière que la conduite est délicate. Quand Ie vois des choses comme '2025 est l'année des agents', je deviens très inquiet et j'ai l'impression que c'est la décennie des agents et que cela va prendre un certain temps. Nous avons besoin d'humains dans la boucle, nous devons faire cela avec précaution ; c'est du logiciel. Soyons sérieux ici. Une analogie de plus à laquelle je pense toujours est l'armure d'Iron Man. J'adore Iron Man ; je pense que c'est correct à bien des égards par rapport à la technologie et à la façon dont elle va évoluer. Ce que j'aime dans l'armure d'Iron Man, c'est que c'est à la fois une augmentation et que Tony Stark peut la piloter, et c'est aussi un agent. Dans certains films, l'armure d'Iron Man est assez autonome et peut voler et s'ajuster. Le curseur d'autonomie est l'endroit où nous pouvons construire des augmentations ou construire des agents. Nous voulons faire un peu des deux, mais à ce stade, en travaillant avec des LLM faillibles, ce sont moins des robots Iron Man et plus des armures Iron Man que vous voulez construire. Il s'agit moins de construire des démos tape-à-l'œil d'agents autonomes et plus de construire des produits à autonomie partielle. Ces produits ont des GUI et une UIUX personnalisées, et cela est fait pour que la boucle génération-vérification avec un humain soit très rapide. Nous ne perdons pas de vue le fait qu'il est en principe possible d'automatiser ce travail et qu'il devrait y avoir un curseur d'autonomie dans votre produit. Vous devriez réfléchir à la façon dont vous pouvez faire glisser ce curseur d'autonomie et rendre votre produit plus autonome au fil du temps. C'est ainsi que je pense qu'il y a beaucoup d'opportunités dans ce genre de produits.

Je veux changer un peu de sujet et parler d'une autre dimension qui est très unique. Non seulement il existe un nouveau type de langage de programmation qui permet l'autonomie dans le logiciel, mais aussi, comme je l'ai mentionné, il est programmé en anglais, qui est cette interface naturelle. Soudain, tout le monde est programmeur parce que tout le monde parle une langue naturelle comme l'anglais. C'est extrêmement prometteur et très intéressant pour moi, et totalement sans précédent. Auparavant, il fallait passer cinq à dix ans à étudier quelque chose pour pouvoir faire quelque chose dans le logiciel. Ce n'est plus le cas aujourd'hui. Je ne sais pas si par hasard quelqu'un a entendu parler du 'vibe coding'. C'est le tweet qui a introduit cela, mais on me dit que c'est maintenant un mème majeur. Une histoire amusante à ce sujet est que je suis sur Twitter depuis 15 ans à ce stade et je n'ai toujours aucune idée de quel tweet deviendra viral et lequel tombera à plat sans que personne ne s'en soucie. Je pensais que ce tweet allait être de ce dernier type. C'était juste des pensées sous la douche, mais c'est devenu un mème total et je ne saurais vraiment pas dire, mais je suppose que cela a touché une corde sensible et a donné un nom à quelque chose que tout le monde ressentait mais ne pouvait pas tout à fait exprimer avec des mots. Maintenant, il y a une page Wikipédia et tout. C'est une contribution majeure maintenant. Tom Wolf de Hugging Face a partagé cette magnifique vidéo que j'adore. Ce sont des enfants qui font du vibe coding. Je trouve que c'est une vidéo tellement saine. Comment peut-on regarder cette vidéo et se sentir mal par rapport à l'avenir ? L'avenir est génial. Cela finira par être une drogue d'initiation au développement logiciel. Je ne suis pas pessimiste (doomer) quant à l'avenir de la génération et j'adore cette vidéo. J'ai aussi essayé un peu le vibe coding parce que c'est tellement amusant. Le vibe coding est génial quand vous voulez construire quelque chose de personnalisé qui ne semble pas exister et que vous voulez juste improviser parce que c'est un samedi. J'ai construit cette application iOS et je ne sais pas vraiment programmer en Swift, mais j'ai été choqué de pouvoir construire une application super basique. Je ne vais pas l'expliquer, mais c'était une journée de travail et elle tournait sur mon téléphone plus tard ce jour-là. Je n'ai pas eu à lire du Swift pendant cinq jours pour commencer. J'ai aussi 'vibe codé' cette application appelée MenuGen et elle est en ligne ; vous pouvez l'essayer sur menugen.app. J'avais ce problème où j'arrive dans un restaurant, je lis le menu et je n'ai aucune idée de ce que sont les plats et j'ai besoin d'images. Cela n'existe pas, alors je me suis dit : 'Hé, je vais le vibe coder'. Voilà à quoi ça ressemble. Vous allez sur menugen.app, vous prenez une photo d'un menu et MenuGen génère les images. Tout le monde reçoit 5 $ de crédits gratuitement à l'inscription et par conséquent, c'est un centre de coûts majeur dans ma vie ; c'est une application à revenus négatifs pour moi en ce moment. J'ai perdu une somme énorme d'argent sur MenuGen. Ce qui est fascinant avec MenuGen pour moi, c'est que le code — la partie vibe coding — était la partie facile. La majeure partie a été quand j'ai essayé de le rendre réel pour que vous puissiez avoir l'authentification, les paiements, le nom de domaine et un déploiement Vercel. C'était vraiment difficile et tout cela n'était pas du code. Tout ce truc de DevOps, c'était moi dans le navigateur en train de cliquer sur des trucs. C'était un véritable calvaire et cela a pris une semaine de plus. Il était fascinant de voir que j'avais la démo de MenuGen qui fonctionnait sur mon ordinateur portable en quelques heures, puis cela m'a pris une semaine parce que j'essayais de la rendre réelle. La raison pour cela était que c'était vraiment ennuyeux. Par exemple, si vous essayez d'ajouter une connexion Google à votre page web, il y a juste une quantité énorme d'instructions de cette bibliothèque Clerk qui me disent comment intégrer cela. C'est fou. Elle me dit d'aller à cette URL, de cliquer sur ce menu déroulant, de choisir ceci, d'aller là et de cliquer sur cela. C'est comme si on me disait quoi faire, comme si un ordinateur me dictait les actions que je devrais entreprendre. Pourquoi est-ce que je fais ça ? C'est quoi ce délire ? J'ai dû suivre toutes ces instructions. C'était fou.

La dernière partie de ma conférence se concentre donc sur : pouvons-nous simplement construire pour les agents ? Je ne veux pas faire ce travail. Les agents peuvent-ils le faire ? Grossièrement parlant, il y a une nouvelle catégorie de consommateur et de manipulateur d'informations numériques. Auparavant, il s'agissait uniquement d'humains via des GUI ou d'ordinateurs via des API, et maintenant nous avons une chose complètement nouvelle. Les agents sont des ordinateurs, mais ils ressemblent aux humains ; ce sont des esprits de personnes. Il y a des esprits de personnes sur Internet et ils doivent interagir avec notre infrastructure logicielle. Pouvons-nous construire pour eux ? C'est une nouvelle chose. À titre d'exemple, vous pouvez avoir un fichier robots.txt sur votre domaine et vous pouvez instruire ou conseiller les robots d'indexation sur la façon de se comporter sur votre site web. De la même manière, vous pouvez avoir peut-être un fichier llms.txt, qui est juste un simple fichier markdown indiquant aux LLM de quoi parle ce domaine. C'est très lisible pour un LLM. S'il devait à la place obtenir le HTML de votre page web et essayer de l'analyser, c'est très sujet aux erreurs et difficile, et il va se planter. Nous pouvons simplement parler directement au LLM ; cela en vaut la peine. Une quantité énorme de documentation est actuellement écrite pour les gens, vous verrez donc des choses comme des listes, du gras et des images, et ce n'est pas directement accessible par un LLM. Je vois que certains services sont en train de transitionner beaucoup de leurs docs pour qu'elles soient spécifiquement pour les LLM. Vercel et Stripe par exemple sont des précurseurs ici, mais j'en ai vu quelques autres déjà. Ils proposent leur documentation en markdown. Le markdown est super facile à comprendre pour les LLM. C'est génial. Un exemple simple tiré de mon expérience : peut-être que certains d'entre vous connaissent 3Blue1Brown, il fait de magnifiques vidéos d'animation sur YouTube. J'adore cette bibliothèque Manim qu'il a écrite. Je voulais faire la mienne. Il y a une documentation étendue sur la façon d'utiliser Manim et je ne voulais pas vraiment la lire. J'ai tout copié-collé dans un LLM, j'ai décrit ce que je voulais et ça a marché tout de suite. Le LLM m'a juste 'vibe codé' une animation exactement comme je la voulais. Si nous pouvons rendre les docs lisibles par les LLM, cela va débloquer une quantité énorme d'utilisations. C'est merveilleux et cela devrait arriver davantage. L'autre chose que je voulais souligner est que vous devez malheureusement — il ne s'agit pas seulement de prendre vos docs et de les faire apparaître en markdown, ça c'est la partie facile — nous devons réellement changer les docs parce que chaque fois que votre doc dit 'cliquez', c'est mauvais. Un LLM ne pourra pas nativement entreprendre cette action en ce moment. Vercel, par exemple, remplace chaque occurrence de 'cliquer' par la commande curl équivalente que votre agent LLM pourrait prendre en votre nom. C'est très intéressant. Ensuite, il y a bien sûr le Model Context Protocol d'Anthropic, et c'est aussi une autre façon — c'est un protocole pour parler directement aux agents en tant que nouveau consommateur et manipulateur d'informations numériques. Je suis très confiant dans ces idées. L'autre chose que j'aime vraiment, c'est un certain nombre de petits outils qui aident à ingérer des données dans des formats très conviviaux pour les LLM. Par exemple, quand je vais sur un dépôt GitHub comme mon dépôt nanoGPT, je ne peux pas donner cela à un LLM et poser des questions à son sujet parce que c'est une interface humaine sur GitHub. Lorsque vous changez l'URL de GitHub en git-ingest, alors cela concatènera tous les fichiers en un seul texte géant et cela créera une structure de répertoires. C'est prêt à être copié-collé dans votre LLM préféré et vous pouvez faire des trucs. Un exemple peut-être encore plus spectaculaire de cela est DeepWiki de Devin. Ils font en sorte que Devin fasse essentiellement l'analyse du dépôt GitHub et Devin construit une page de doc entière juste pour votre dépôt, et vous pouvez imaginer que c'est encore plus utile à copier-coller dans votre LLM. J'adore tous les petits outils où vous changez simplement l'URL et cela rend quelque chose accessible à un LLM. C'est bel et bien génial et je pense qu'il devrait y en avoir beaucoup plus. Une note de plus que je voulais faire : il est possible que dans le futur les LLM soient capables de — ce n'est même pas le futur, c'est aujourd'hui — ils seront capables de se balader et de cliquer sur des trucs. Mais je pense toujours qu'il est très utile d'aller à la rencontre des LLM à mi-chemin et de leur faciliter l'accès à toutes ces informations car c'est encore coûteux à utiliser et beaucoup plus difficile. Je pense en effet que pour beaucoup de logiciels, il y aura une longue traîne où ils ne s'adapteront pas car ce ne sont pas des dépôts de joueurs actifs ou des infrastructures numériques et nous aurons besoin de ces outils. Mais pour tous les autres, je pense qu'il est très utile de se rencontrer en un point intermédiaire. Je suis donc optimiste pour les deux. En résumé : quel moment incroyable pour entrer dans l'industrie. Nous devons réécrire une tonne de code ; une tonne de code sera écrite par des professionnels et des vibe coders. Ces LLM sont un peu comme des services publics, un peu comme des fonderies, mais ils ressemblent surtout à des systèmes d'exploitation. Mais c'est si tôt ; c'est comme les années 1960 des systèmes d'exploitation et je pense que beaucoup d'analogies se recoupent. Ces LLM sont un peu comme ces esprits de personnes faillibles avec lesquels nous devons apprendre à travailler. Pour ce faire correctement, nous devons ajuster notre infrastructure en conséquence. En construisant ces applications LLM, j'ai décrit certaines des façons de travailler efficacement avec ces LLM et certains des outils qui rendent cela possible et comment vous pouvez faire tourner cette boucle très rapidement et créer des produits à autonomie partielle. Beaucoup de code doit aussi être écrit pour les agents plus directement. En tout cas, pour en revenir à l'analogie de l'armure d'Iron Man, ce que nous verrons au cours de la prochaine décennie, c'est que nous allons déplacer le curseur de la gauche vers la droite et il sera très intéressant de voir à quoi cela ressemble. J'ai hâte de construire cela avec vous tous. Merci.