Robot conversationnel et intelligence artificielle #

Hum, d’accord, je suis enthousiaste 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, en licence, master, doctorat, et ainsi de suite, et que vous êtes sur le point d’entrer dans l’industrie. Je pense que c’est un moment extrêmement unique et très intéressant pour rejoindre 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 matériel pour créer de nouvelles conférences, et je pense que ce changement est assez fondamental. Grossièrement, le logiciel n’a pas beaucoup changé à un niveau aussi fondamental depuis 70 ans, puis il a changé, je pense, deux fois de manière assez rapide ces dernières années. Il y a donc une énorme quantité de travail à faire, une énorme quantité de logiciels à écrire et à réécrire.

Le paysage du logiciel

Examinons peut-être le domaine du logiciel. Si nous considérons cela comme une carte du logiciel, il existe un outil vraiment cool appelé « Map of GitHub ». C’est un peu comme tout le logiciel qui a été écrit, des instructions pour l’ordinateur afin d’exécuter des tâches dans l’espace numérique. Si vous zoomez, ce sont tous différents types de dépôts, et c’est tout le code qui a été écrit. Il y a quelques années, j’ai observé que le logiciel changeait, qu’il y avait un nouveau type de logiciel, et je l’ai appelé « logiciel 2.0 » à l’époque. L’idée était que le logiciel 1.0 est le code que vous écrivez pour l’ordinateur, tandis que le logiciel 2.0 concerne les réseaux neuronaux, en particulier les poids d’un réseau neuronal. Vous n’écrivez pas ce code directement, vous ajustez plutôt les ensembles de données, puis vous exécutez un optimiseur pour créer les paramètres de ce réseau neuronal. À l’époque, les réseaux neuronaux étaient perçus comme un simple classificateur différent, comme un arbre de décision ou quelque chose comme ça. Je pense que ce cadre était beaucoup plus approprié.

Maintenant, nous avons l’équivalent de GitHub dans le domaine du logiciel 2.0. Je pense que Hugging Face est fondamentalement l’équivalent de GitHub pour le logiciel 2.0. Il y a aussi Model Atlas, où vous pouvez visualiser tout le code écrit, si vous êtes curieux. D’ailleurs, le grand cercle au centre représente les paramètres de Flux, le générateur d’images. Chaque fois que quelqu’un ajuste un modèle au-dessus de Flux, vous créez en quelque sorte un « commit » dans cet espace, et vous obtenez un générateur d’images différent.

En résumé, le logiciel 1.0 est le code informatique qui programme un ordinateur, le logiciel 2.0 sont les poids qui programment les réseaux neuronaux. Voici un exemple avec AlexNet, un réseau neuronal de reconnaissance d’images. Jusqu’à récemment, tous les réseaux neuronaux que nous connaissions étaient des ordinateurs à fonction fixe, comme de l’image aux catégories. Ce qui a changé, et je pense que c’est un changement fondamental, c’est que les réseaux neuronaux sont devenus programmables avec les grands modèles de langage (LLM). Je vois cela comme quelque chose de nouveau et unique, un nouveau type d’ordinateur. À mon avis, cela mérite une nouvelle désignation : le logiciel 3.0. Vos invites (prompts) sont maintenant des programmes qui programment le LLM, et, chose remarquable, ces invites sont écrites en anglais, ce qui en fait un langage de programmation très intéressant.

Exemple : classification de sentiments

Pour illustrer la différence, si vous faites une classification de sentiments, vous pouvez imaginer écrire une certaine quantité de code Python pour effectuer cette classification, ou entraîner un réseau neuronal, ou encore utiliser une invite pour un grand modèle de langage. Voici une invite courte, et vous pouvez imaginer la modifier pour programmer l’ordinateur d’une manière légèrement différente. Nous avons donc le logiciel 1.0, le logiciel 2.0, et je pense que nous voyons maintenant que beaucoup de code sur GitHub n’est plus seulement du code, il y a aussi beaucoup de texte en anglais entrelacé avec le code. Une nouvelle catégorie de code émerge, non seulement un nouveau paradigme de programmation, mais aussi, ce qui est remarquable, dans notre langue native, l’anglais.

Quand cela m’a frappé il y a quelques années, j’ai tweeté à ce sujet, et cela a capté l’attention de beaucoup de monde. C’est actuellement mon tweet épinglé : nous programmons maintenant les ordinateurs en anglais. Chez Tesla, nous travaillions sur le pilote automatique, et nous essayions de faire conduire la voiture. J’ai montré une diapositive à l’époque où les entrées de la voiture passaient par une pile logicielle pour produire la direction et l’accélération. J’avais observé qu’il y avait une tonne de code C++ dans le pilote automatique, qui était du logiciel 1.0, et qu’il y avait aussi des réseaux neuronaux pour la reconnaissance d’images. Au fil du temps, à mesure que nous améliorions le pilote automatique, le réseau neuronal gagnait en capacité et en taille, et tout le code C++ était supprimé. Beaucoup des capacités et fonctionnalités initialement écrites en 1.0 ont été migrées vers le 2.0. Par exemple, l’assemblage des informations entre les images des différentes caméras et dans le temps était effectué par un réseau neuronal, ce qui nous a permis de supprimer beaucoup de code. La pile logicielle 2.0 a littéralement dévoré la pile logicielle du pilote automatique.

Je trouvais cela vraiment remarquable à l’époque, et je pense que nous voyons la même chose aujourd’hui, où un nouveau type de logiciel dévore la pile. Nous avons trois paradigmes de programmation complètement différents, et si vous entrez dans l’industrie, il est très utile d’être à l’aise avec chacun d’eux, car ils ont tous leurs avantages et inconvénients. Vous devrez décider si une fonctionnalité doit être programmée en 1.0, 2.0 ou 3.0. Allez-vous entraîner un réseau neuronal, simplement utiliser une invite pour un LLM, ou écrire un code explicite ? Nous devons tous prendre ces décisions et potentiellement passer fluidement d’un paradigme à l’autre.

Les grands modèles de langage (LLM)

Passons maintenant à la première partie, où je veux parler des LLM, de la manière de penser à ce nouveau paradigme et à son écosystème. Qu’est-ce que cet nouvel ordinateur, à quoi ressemble-t-il, et à quoi ressemble l’écosystème ? J’ai été frappé par une citation d’Andrew Ng, il y a plusieurs années, qui disait que l’IA est la nouvelle électricité. Je pense que cela capture quelque chose de très intéressant, car les LLM ont actuellement des propriétés d’utilité publique. Les laboratoires de LLM, comme OpenAI, Gemini, Anthropic, etc., investissent des capitaux pour entraîner les LLM, ce qui équivaut à construire un réseau. Ensuite, il y a des dépenses opérationnelles pour fournir cette intelligence via des API à nous tous, à travers un accès mesuré où nous payons par million de jetons ou quelque chose comme ça. Nous avons beaucoup d’exigences similaires à celles d’une utilité publique : faible latence, haute disponibilité, qualité constante, etc.

Dans l’électricité, vous auriez un commutateur de transfert pour passer de la grille à l’énergie solaire, une batterie ou un générateur. Dans les LLM, nous avons peut-être OpenRouter, qui permet de basculer facilement entre différents types de LLM existants. Comme les LLM sont des logiciels, ils ne rivalisent pas pour l’espace physique, donc il est acceptable d’avoir, disons, six fournisseurs d’électricité, et vous pouvez passer de l’un à l’autre, car ils ne concurrencent pas de manière aussi directe. Ce qui est aussi fascinant, c’est que récemment, plusieurs LLM ont connu des pannes, et les gens se sont retrouvés bloqués, incapables de travailler. Quand les LLM de pointe tombent en panne, c’est comme une baisse d’intelligence dans le monde, un peu comme une tension instable dans le réseau, et la planète devient simplement moins intelligente. Plus nous dépendons de ces modèles, ce qui est déjà dramatique, plus cela va croître.

Mais les LLM n’ont pas seulement des propriétés d’utilité publique. Ils ont aussi des propriétés de fabriques (fabs), car les investissements nécessaires pour construire un LLM sont considérables, pas seulement comme construire une centrale électrique. La technologie évolue rapidement, avec des arbres technologiques complexes, de la recherche et du développement, et des secrets centralisés dans les laboratoires de LLM. Cependant, l’analogie devient un peu floue, car, comme je l’ai mentionné, il s’agit de logiciel, et le logiciel est moins défendable car il est très malléable.

Je pense que l’analogie qui a le plus de sens est que les LLM ont de fortes similitudes avec les systèmes d’exploitation. Ce n’est pas juste de l’électricité ou de l’eau qui sort d’un robinet comme une commodité. Ce sont des écosystèmes logiciels de plus en plus complexes, pas juste des commodités simples comme l’électricité. L’écosystème se forme de manière très similaire, avec quelques fournisseurs à source fermée, comme Windows ou Mac OS, et une alternative open source comme Linux. Pour les LLM, nous avons quelques fournisseurs à source fermée en compétition, et peut-être que l’écosystème LLaMA est actuellement une approximation 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, avec l’utilisation d’outils, la multimodalité, et comment tout cela fonctionne.

Quand j’ai réalisé cela il y a un moment, j’ai essayé de le schématiser, et il m’a semblé que les LLM sont comme un nouveau système d’exploitation. Le LLM est une sorte d’équivalent du CPU, les fenêtres de contexte sont comme la mémoire, et le LLM orchestre la mémoire et le calcul pour résoudre des problèmes, en utilisant toutes ces capacités. Cela ressemble beaucoup à un système d’exploitation de ce point de vue.

Pour donner un exemple, si je veux télécharger une application, disons VS Code, je peux le télécharger et l’exécuter sur Windows, Linux ou Mac. De la même manière, je peux prendre une application LLM comme Cursor et l’exécuter sur GPT, Claude ou la série Gemini, juste en sélectionnant une option dans un menu déroulant. Nous sommes dans une ère, disons des années 1960, où le calcul des LLM est encore très coûteux pour ce nouveau type d’ordinateur, ce qui oblige les LLM à être centralisés dans le cloud. Nous sommes tous des clients qui interagissent avec eux via le réseau, et aucun de nous n’a une utilisation complète de ces ordinateurs. Cela rend logique d’utiliser le partage de temps, où nous sommes tous une dimension du lot quand ils exécutent l’ordinateur dans le cloud. C’est ainsi que les ordinateurs fonctionnaient à cette époque : 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, car ce n’est pas économique, ça n’a pas de sens. Mais certaines personnes essaient, et il s’avère que les Mac Minis, par exemple, sont très adaptés pour certains LLM, car si vous faites une inférence par lot, tout est très limité par la mémoire. Cela fonctionne, et ce sont peut-être des signes précoces de l’informatique personnelle, mais cela n’a pas vraiment eu lieu. Ce n’est pas clair à quoi cela ressemblera. Peut-être que certains d’entre vous inventeront ce que c’est, comment ça fonctionne, ou ce que ça devrait être.

Une autre analogie : chaque fois que je parle à ChatGPT ou à un LLM directement en 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. Est-ce que ChatGPT devrait avoir une GUI différente des simples bulles de texte ? Certaines applications ont des GUI, mais il n’y a pas de GUI générale pour toutes les tâches.

Les LLM diffèrent des systèmes d’exploitation de manière assez unique. J’ai écrit sur une propriété qui me semble très différente cette fois-ci : les LLM inversent la direction de la diffusion technologique, qui est généralement présente dans la technologie. Par exemple, avec l’électricité, la cryptographie, l’informatique, l’aviation, l’internet, le GPS, beaucoup de technologies transformatrices nouvelles et coûteuses étaient d’abord utilisées par les gouvernements et les entreprises, avant de se diffuser aux consommateurs. Mais avec les LLM, c’est l’inverse. Avec les premiers ordinateurs, il s’agissait de balistique et d’usage militaire, mais avec les LLM, il s’agit de savoir comment faire bouillir un œuf. C’est fascinant que nous ayons un nouvel ordinateur magique qui m’aide à faire bouillir un œuf, et non à aider le gouvernement à faire quelque chose de fou comme de la balistique militaire ou une technologie spéciale. Les entreprises et les gouvernements sont en retard sur l’adoption de ces technologies par rapport à nous tous. Cela informe peut-être certaines utilisations de la technologie, comme où se trouvent les premières applications.

Résumé

Les LLM sont des systèmes d’exploitation complexes, comparables à l’informatique des années 1960, et nous refaisons l’informatique à nouveau. Ils sont actuellement disponibles via le partage de temps et distribués comme une utilité publique. Ce qui est nouveau et sans précédent, c’est qu’ils ne sont pas entre les mains de quelques gouvernements et entreprises, mais entre les mains de nous tous, car nous avons tous un ordinateur, et c’est juste du logiciel. ChatGPT a été envoyé à nos ordinateurs, à des milliards de personnes, instantanément et du jour au lendemain, ce qui est insensé. Maintenant, c’est à nous d’entrer dans l’industrie et de programmer ces ordinateurs. C’est assez remarquable.

Psychologie des LLM

Avant de programmer les LLM, nous devons réfléchir à ce qu’ils sont. J’aime parler de leur psychologie. Je vois les LLM comme des esprits humains, des simulations stochastiques de personnes, où le simulateur est un transformateur autorégressif. C’est un réseau neuronal qui avance token par token, avec presque la même quantité de calcul pour chaque token. Ce simulateur est ajusté à tout le texte que nous avons sur internet, et ainsi de suite, ce qui lui donne une psychologie émergente semblable à celle des humains.

La première chose que vous remarquez, c’est que les LLM ont une connaissance encyclopédique et une mémoire impressionnante. Ils peuvent se souvenir de beaucoup plus de choses qu’un individu humain, car ils ont lu énormément. Cela me rappelle le film Rain Man, que je recommande vivement. Dustin Hoffman y joue un savant autiste avec une mémoire presque parfaite, capable de lire un annuaire téléphonique et de se souvenir de tous les noms et numéros. Les LLM sont similaires : ils peuvent se souvenir de hachages SHA et de toutes sortes de choses très facilement. Ils ont donc des superpouvoirs à certains égards.

Mais ils ont aussi des déficits cognitifs. Ils hallucinent beaucoup, inventent des choses, et n’ont pas un très bon modèle interne de connaissance de soi, bien que cela s’améliore. Ils affichent une intelligence inégale : ils sont surhumains dans certains domaines de résolution de problèmes, mais font des erreurs qu’aucun humain ne ferait, comme insister que 9.11 est supérieur à 9.9 ou qu’il y a deux « r » dans « strawberry ». Ce sont des exemples célèbres, mais il y a des aspérités sur lesquelles on peut trébucher.

Ils souffrent aussi d’une sorte d’amnésie rétrograde. Si un collègue rejoint votre organisation, il apprendra au fil du temps à connaître l’organisation, gagnera du contexte, rentrera chez lui, dormira, consolidera ses connaissances et développera une expertise. Les LLM ne le font pas nativement, et ce n’est pas quelque chose qui a été résolu dans la recherche et développement des LLM. Les fenêtres de contexte sont comme une mémoire de travail, et vous devez programmer cette mémoire de travail assez directement, car ils ne deviennent pas plus intelligents par défaut. Beaucoup de gens se trompent sur ces analogies. Je recommande de regarder les films Memento et 50 First Dates, où les protagonistes ont leurs poids fixés et leurs fenêtres de contexte effacées chaque matin, ce qui rend le travail ou les relations problématiques.

Il y a aussi des limitations liées à la sécurité. Les LLM sont assez crédules, vulnérables aux risques d’injection de prompts, et peuvent divulguer vos données. Il y a donc de nombreuses considérations liées à la sécurité.

En résumé, vous devez considérer cette chose surhumaine avec des déficits cognitifs et des problèmes, tout en étant extrêmement utile. Comment les programmer et contourner leurs déficits tout en profitant de leurs superpouvoirs ?

Opportunités avec les LLM

Passons maintenant aux opportunités d’utilisation de ces modèles et à certaines des plus grandes opportunités. Ce n’est pas une liste exhaustive, juste quelques éléments que je trouve intéressants pour cette conférence.

Applications à autonomie partielle

Je suis enthousiaste à propos de ce que j’appelle les applications à autonomie partielle. Prenons l’exemple du codage. Vous pouvez aller directement sur ChatGPT, copier-coller du code, des rapports de bogues, obtenir du code et tout copier-coller. Pourquoi faire cela ? Pourquoi aller directement au système d’exploitation ? Il est beaucoup plus logique d’avoir une application dédiée. Beaucoup d’entre vous utilisent probablement Cursor, que j’utilise aussi. Cursor est un très bon exemple d’une application LLM précoce avec des propriétés utiles pour toutes les applications LLM.

Vous remarquerez que nous avons une interface traditionnelle qui permet à un humain de faire tout le travail manuellement comme avant, mais en plus, nous avons cette intégration LLM qui permet d’avancer par plus gros morceaux. Voici quelques propriétés des applications LLM que je trouve utiles à souligner :

Les LLM gèrent une grande partie de la gestion du contexte.

Ils orchestrent plusieurs appels aux LLM. Dans le cas de Cursor, il y a des modèles d’embedding pour tous vos fichiers, des modèles de chat, des modèles qui appliquent des différences au code, et tout cela est orchestré pour vous.

Une interface graphique spécifique à l’application est très importante. Vous ne voulez pas parler directement au système d’exploitation en texte. Le texte est difficile à lire, interpréter et comprendre, et vous ne voulez pas prendre certaines actions nativement en texte. Il est beaucoup plus facile de voir une différence en rouge et vert, de voir ce qui est ajouté ou soustrait, et d’utiliser des commandes comme Cmd+Y pour accepter ou Cmd+N pour rejeter, plutôt que de devoir l’écrire en texte. Une interface graphique permet à un humain d’auditer le travail de ces systèmes faillibles et d’aller plus vite.

Ce que j’appelle le curseur d’autonomie. Dans Cursor, vous pouvez faire une complétion par tabulation, où vous êtes principalement en charge. Vous pouvez sélectionner un morceau de code et utiliser Cmd+K pour modifier juste ce morceau, Cmd+L pour modifier tout le fichier, ou Cmd+I pour laisser l’application faire ce qu’elle veut dans tout le dépôt, ce qui est la version agentique à pleine autonomie. Vous contrôlez ce curseur d’autonomie, et selon la complexité de la tâche, vous pouvez ajuster le niveau d’autonomie que vous êtes prêt à céder.

Un autre exemple d’application LLM réussie est Perplexity. Elle possède des fonctionnalités similaires à celles que j’ai mentionnées pour Cursor. Elle regroupe beaucoup d’informations, orchestre plusieurs LLM, et a une interface graphique qui permet d’auditer une partie de son travail, comme citer des sources que vous pouvez inspecter. Elle a aussi un curseur d’autonomie : vous pouvez faire une recherche rapide, une recherche approfondie, ou une recherche très approfondie et revenir 10 minutes plus tard. Ce sont différents niveaux d’autonomie que vous cédez à l’outil.

Je me demande à quoi cela ressemble si beaucoup de logiciels deviennent partiellement autonomes. Pour ceux d’entre vous qui maintiennent 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 dont un humain pourrait agir ? 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 une différence dans Photoshop, par exemple ? Beaucoup de logiciels traditionnels ont actuellement des interrupteurs et des éléments conçus pour les humains. Tout cela doit changer et devenir accessible aux LLM.

Un point que je veux souligner avec beaucoup de ces applications LLM, qui ne reçoit peut-être pas autant d’attention qu’il le devrait, est que nous coopérons maintenant avec des IA. Habituellement, elles génèrent, et nous, humains, vérifions. Il est dans notre intérêt de faire tourner cette boucle le plus rapidement possible pour accomplir beaucoup de travail. Il y a deux façons principales d’y parvenir :

Accélérer la vérification. Les interfaces graphiques sont extrêmement importantes pour cela, car elles exploitent le GPU de votre vision par ordinateur dans votre tête. Lire du texte est laborieux et pas amusant, mais regarder des choses est amusant et constitue une autoroute vers votre cerveau. Les interfaces graphiques sont donc très utiles pour auditer les systèmes et pour les représentations visuelles en général.

Garder l’IA en laisse. Beaucoup de gens s’emballent trop avec les agents IA. Ce n’est pas utile de recevoir une différence de 10 000 lignes de code dans mon dépôt. Je reste le goulot d’étranglement, même si ces 10 000 lignes sortent instantanément. Je dois m’assurer que cela n’introduit pas de bogues, que c’est correct, et qu’il n’y a pas de problèmes de sécurité. Il est dans notre intérêt de faire tourner ce flux très rapidement et de garder l’IA en laisse, car elle devient trop réactive.

Quand je fais du codage assisté par IA, si je code tranquillement, tout va bien, mais si j’essaie d’avancer dans mon travail, ce n’est pas génial d’avoir un agent trop réactif qui fait tout. Je travaille toujours sur de petits morceaux incrémentiels, je veux m’assurer que tout va bien, je veux faire tourner cette boucle très rapidement, et je travaille sur des choses concrètes et uniques. Beaucoup d’entre vous développent probablement des façons similaires de travailler avec les LLM. J’ai aussi vu plusieurs articles de blog qui tentent de développer ces meilleures pratiques pour travailler avec les LLM. J’en ai lu un récemment qui était assez bon, discutant de certaines techniques, notamment sur la manière de garder l’IA en laisse. Par exemple, si votre invite est vague, l’IA pourrait ne pas faire exactement ce que vous vouliez, et la vérification échouera. Vous demanderez autre chose, et si la vérification échoue, vous commencerez à tourner en rond. Il est donc plus logique de passer un peu plus de temps à être plus précis dans vos invites, ce qui augmente la probabilité d’une vérification réussie, et vous pouvez avancer.

Dans mon propre travail, je m’intéresse actuellement à ce que l’éducation pourrait être avec l’IA et les LLM. Beaucoup de mes réflexions portent sur la manière de garder l’IA en laisse. Je ne pense pas que cela fonctionne de dire à ChatGPT « Hey, enseigne-moi la physique ». L’IA se perd dans les bois. Pour moi, ce sont deux applications distinctes : une pour un enseignant qui crée des cours, et une qui prend ces cours et les sert aux étudiants. Dans les deux cas, nous avons cet artefact intermédiaire d’un cours qui est auditable, nous pouvons nous assurer qu’il est bon, cohérent, et l’IA est gardée en laisse par rapport à un certain programme, une certaine progression de projets, etc. C’est une façon de garder l’IA en laisse, et je pense que cela a beaucoup plus de chances de fonctionner.

Une autre analogie à laquelle je fais référence est mon expérience chez Tesla, où j’ai travaillé pendant cinq ans sur un produit à autonomie partielle, qui partage beaucoup de caractéristiques. Par exemple, dans le tableau de bord, il y a l’interface graphique du pilote automatique, qui montre ce que le réseau neuronal voit. Nous avions le curseur d’autonomie, et au fil de mon temps là-bas, nous faisions de plus en plus de tâches autonomes pour l’utilisateur. Une petite histoire : la première fois que j’ai conduit un véhicule autonome, c’était en 2013. Un ami qui travaillait chez Waymo m’a proposé de faire un tour à Palo Alto. J’ai pris une photo avec Google Glass à l’époque – beaucoup d’entre vous sont si jeunes que vous ne savez peut-être même pas ce que c’est. Nous sommes montés dans la voiture, avons fait un trajet d’environ 30 minutes sur les autoroutes et les rues de Palo Alto, et ce trajet était parfait, sans aucune intervention. C’était en 2013, il y a 12 ans, et cela m’a frappé, car à l’époque, après ce trajet parfait, j’ai pensé que la conduite autonome était imminente. Mais nous sommes en 2025, et nous travaillons toujours sur l’autonomie, sur les agents de conduite. Même maintenant, nous n’avons pas vraiment résolu le problème. Vous voyez peut-être des Waymo circuler sans conducteur, mais il y a encore beaucoup de téléopération et d’humains dans la boucle. Nous n’avons pas encore déclaré le succès, mais je pense que cela va réussir à ce stade, mais cela a pris beaucoup de temps.

Le logiciel est vraiment complexe, tout comme la conduite. Quand je vois des affirmations comme « 2025 est l’année des agents », je m’inquiète. Je pense que c’est la décennie des agents, et cela va prendre du temps. Nous avons besoin d’humains dans la boucle, nous devons le faire prudemment. Soyons sérieux, c’est du logiciel.

Une autre analogie que je considère toujours est l’armure d’Iron Man. J’adore Iron Man, je pense que c’est tellement juste à bien des égards concernant la technologie et comment elle va se déployer. Ce que j’aime dans l’armure d’Iron Man, c’est qu’elle est à la fois une augmentation – Tony Stark peut la piloter – et un agent. Dans certains films, l’armure est assez autonome, peut voler et trouver Tony, etc. C’est le curseur d’autonomie : nous pouvons construire des augmentations ou des agents, et nous voulons faire un peu des deux. Mais à ce stade, en travaillant avec des LLM faillibles, je dirais qu’il s’agit moins de robots Iron Man et plus de combinaisons Iron Man. Il s’agit moins de construire des démos flashy d’agents autonomes et plus de construire des produits à autonomie partielle. Ces produits ont des interfaces graphiques personnalisées et une expérience utilisateur, conçus pour que la boucle de génération-vérification humaine soit très rapide, tout en gardant à l’esprit qu’il est en principe possible d’automatiser ce travail. Il devrait y avoir un curseur d’autonomie dans votre produit, et vous devriez réfléchir à comment faire glisser ce curseur pour rendre votre produit plus autonome avec le temps.

Programmation en anglais

Passons à une autre dimension que je trouve très unique. Non seulement il y a un nouveau type de langage de programmation qui permet l’autonomie dans les logiciels, mais comme je l’ai mentionné, il est programmé en anglais, qui est une interface naturelle. Soudain, tout le monde est programmeur, car tout le monde parle une langue naturelle comme l’anglais. C’est extrêmement optimiste et très intéressant pour moi, et totalement sans précédent. Avant, il fallait passer cinq à dix ans à étudier pour pouvoir faire quelque chose en logiciel. Ce n’est plus le cas.

Quelqu’un a-t-il entendu parler du « vibe coding » ? C’est un tweet qui a introduit ce concept, et on m’a dit que c’est maintenant un mème majeur. Une anecdote amusante : je suis sur Twitter depuis environ 15 ans, et je n’ai toujours aucune idée de quel tweet va devenir viral et lequel va passer inaperçu. Je pensais que ce tweet allait être dans la deuxième catégorie, juste une pensée spontanée, mais il est devenu un mème total. Je ne peux pas vraiment prévoir, mais je suppose qu’il a touché une corde sensible et donné un nom à quelque chose que tout le monde ressentait mais ne pouvait pas exprimer en mots. Maintenant, il y a même une page Wikipédia pour ça.

Tom Wolf de Hugging Face a partagé une vidéo magnifique que j’adore, montrant des enfants en train de faire du vibe coding. Je trouve cette vidéo tellement saine. Comment peut-on regarder cette vidéo et se sentir mal à propos de l’avenir ? L’avenir est prometteur. Je pense que cela deviendra une porte d’entrée vers le développement logiciel. Je ne suis pas pessimiste quant à l’avenir de cette génération.

J’ai aussi essayé le vibe coding, car c’est tellement amusant. C’est génial quand vous voulez construire quelque chose de super personnalisé qui n’existe pas et que vous voulez juste tenter le coup un samedi. J’ai construit une application iOS, et je ne sais pas programmer en Swift, mais j’ai été choqué de pouvoir construire une application super basique. Je ne vais pas l’expliquer, c’est vraiment idiot, mais c’était juste une journée de travail, et ça fonctionnait sur mon téléphone le même jour. J’étais comme « Wow, c’est incroyable ». Je n’ai pas eu à lire des manuels sur Swift pendant cinq jours pour commencer.

J’ai aussi fait du vibe coding pour une application appelée MenuGen, qui est en ligne sur menu.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. Ça n’existait pas, alors je me suis dit « Je vais le coder en mode vibe ». Vous allez sur menu.app, prenez une photo d’un menu, et MenuGen génère les images. Tout le monde reçoit 5 $ de crédits gratuits en s’inscrivant, ce qui est un centre de coûts majeur dans ma vie. Cette application me fait perdre beaucoup d’argent.

Ce qui est fascinant avec MenuGen, c’est que coder la partie vibe coding était la partie facile. La plupart des difficultés sont survenues quand j’ai essayé de la rendre réelle, avec l’authentification, les paiements, le nom de domaine, et le déploiement sur Vercel. Tout cela n’était pas du code, c’était du DevOps, cliquer sur des choses dans le navigateur, et c’était extrêmement lent, ça a pris une autre semaine. J’avais une démo de MenuGen fonctionnant sur mon ordinateur portable en quelques heures, mais il m’a fallu une semaine pour la rendre réelle, car c’était vraiment agaçant. Par exemple, ajouter une connexion Google à votre page web implique une énorme quantité d’instructions d’une bibliothèque comme Clerk, me disant d’aller à telle URL, de cliquer sur tel menu déroulant, de choisir ceci, d’aller là et de cliquer sur ça. C’est comme si un ordinateur me disait quoi faire. Pourquoi est-ce que je fais ça ? Fais-le toi-même !

Construire pour les agents

La dernière partie de ma conférence se concentre sur la possibilité de construire pour les agents. Je ne veux pas faire ce travail, les agents peuvent-ils le faire ? Grossièrement, je pense qu’il y a une nouvelle catégorie de consommateurs et de manipulateurs d’informations numériques. Avant, c’étaient juste les humains via les interfaces graphiques ou les ordinateurs via les API. Maintenant, nous avons une chose complètement nouvelle : les agents. Ce sont des ordinateurs, mais ils sont un peu comme des humains, des esprits humains sur internet, et ils doivent interagir avec notre infrastructure logicielle. Pouvons-nous construire pour eux ? C’est une nouveauté.

Par exemple, vous pouvez avoir un fichier robots.txt sur votre domaine pour indiquer aux robots d’indexation comment se comporter sur votre site. De la même manière, vous pourriez avoir un fichier llm.txt, un simple fichier Markdown expliquant à un LLM de quoi parle ce domaine. C’est très lisible pour un LLM. S’il devait récupérer le HTML de votre page web et essayer de le parser, ce serait très sujet aux erreurs et difficile. Nous pouvons parler directement aux LLM, ça vaut le coup.

Une grande quantité de documentation est actuellement écrite pour les humains, avec des listes, du texte en gras, des images, ce qui n’est pas directement accessible aux LLM. Certains services commencent à transformer leurs documentations pour qu’elles soient spécifiquement destinées aux LLM. Vercel et Stripe, par exemple, sont des pionniers ici, mais j’en ai vu d’autres. Ils proposent leur documentation en Markdown, qui est super facile à comprendre pour les LLM. C’est génial.

Un exemple simple de mon expérience : certains d’entre vous connaissent peut-être 3Blue1Brown, qui fait de magnifiques vidéos d’animation sur YouTube. Il a écrit une bibliothèque appelée Manim, et je voulais faire mes propres animations. Il y a une documentation extensive sur l’utilisation de Manim, mais je ne voulais pas la lire. J’ai donc copié-collé tout le contenu dans un LLM, décrit ce que je voulais, et ça a fonctionné directement. Le LLM m’a créé une animation exactement comme je le voulais, et j’étais comme « Wow, c’est incroyable ». Si nous rendons les documentations lisibles pour les LLM, cela va débloquer une énorme quantité d’utilisations, et je pense que c’est merveilleux et que ça devrait se faire plus souvent.

Malheureusement, il ne s’agit pas seulement de prendre vos documentations et de les mettre en Markdown, ce qui est la partie facile. Il faut aussi modifier les documentations, car chaque fois qu’elles disent « cliquez ici », c’est mauvais. Un LLM ne peut pas nativement prendre cette action pour le moment. Vercel, par exemple, remplace chaque occurrence de « cliquez » par une commande curl équivalente que votre agent LLM pourrait exécuter à votre place. Je trouve cela très intéressant. Il y a aussi le protocole de contexte de modèle d’Anthropic, une autre façon de parler directement aux agents en tant que nouveaux consommateurs et manipulateurs d’informations numériques. Je suis très optimiste sur ces idées.

J’aime aussi plusieurs petits outils ici et là qui aident à ingérer des données dans des formats très adaptés aux LLM. Par exemple, quand je vais sur un dépôt GitHub comme mon dépôt nanoGPT, je ne peux pas le donner à un LLM et poser des questions, car c’est une interface humaine sur GitHub. Mais si vous changez l’URL de GitHub à GetIngest, cela concatène tous les fichiers en un seul texte géant, crée une structure de répertoire, etc., et c’est prêt à être copié-collé dans votre LLM préféré. Un exemple encore plus frappant est DeepWiki, où ce n’est pas juste le contenu brut des fichiers. Devon, par exemple, analyse le dépôt GitHub et construit toute une page de documentation pour votre dépôt, ce qui est encore plus utile à copier-coller dans votre LLM.

J’adore tous ces petits outils où vous changez simplement l’URL, et ça rend quelque chose accessible à un LLM. C’est très bien, et il devrait y en avoir beaucoup plus. Une note supplémentaire : il est tout à fait possible que dans le futur – et même aujourd’hui – les LLM puissent naviguer et cliquer sur des choses. Mais je pense toujours qu’il vaut la peine de rencontrer les LLM à mi-chemin et de faciliter leur accès à toutes ces informations, car c’est encore assez coûteux et beaucoup plus difficile. Il y aura une longue traîne de logiciels qui ne s’adapteront pas, car ce ne sont pas des dépôts ou des infrastructures numériques très actifs. Nous aurons besoin de ces outils, mais pour tous les autres, je pense qu’il vaut la peine de trouver un point de rencontre.

Conclusion

Quel moment incroyable pour entrer dans l’industrie ! Nous devons réécrire une tonne de code, qui sera écrit par des professionnels et des codeurs. Les LLM sont un peu comme des utilités publiques, un peu comme des fabriques, mais surtout comme des systèmes d’exploitation. C’est tellement tôt, c’est comme les années 1960 des systèmes d’exploitation, et beaucoup d’analogies se croisent. Ces LLM sont comme des esprits humains faillibles avec lesquels nous devons apprendre à travailler. Pour le faire correctement, nous devons ajuster notre infrastructure en conséquence.

Quand vous construisez des applications LLM, j’ai décrit certaines façons de travailler efficacement avec ces LLM et certains outils qui rendent cela possible, ainsi que comment faire tourner cette boucle très rapidement pour créer des produits à autonomie partielle. Beaucoup de code devra aussi être écrit plus directement pour les agents. En revenant à l’analogie de l’armure d’Iron Man, je pense que sur la prochaine décennie, nous allons faire glisser le curseur d’autonomie de gauche à droite, et il sera très intéressant de voir à quoi cela ressemble. J’ai hâte de le construire avec vous tous. Merci.