Comprendre l'IA, une leçon à la fois

Il y a quelques années, on passait tous nos textes dans Google Translate, et ça se voyait à trois kilomètres. Aujourd'hui, Claude ou ChatGPT traduisent si bien qu'on ne remarque souvent même plus la traduction. Mais alors, qu'est-ce qui s'est passé entre les deux ?

Faisons l'expérience. Prenez une expression bien de chez nous : "Il pleut des cordes". Donnez-la à un traducteur qui remplace chaque mot par son équivalent, et vous obtenez "It's raining ropes". Tous les mots sont justes... et pourtant votre collègue anglais regarde le ciel en cherchant d'où tombe le matériel d'escalade.

Le problème, ce n'est pas le vocabulaire. C'est que le traducteur n'a pas compris la phrase.

Alors comment font les modèles actuels ? Leur secret, c'est qu'ils ne manipulent pas vraiment des mots. Ils manipulent des vecteurs.

Imaginez une immense carte. Pas une carte routière, une carte du sens. Sur cette carte, chaque mot a une position, et les mots qui parlent de choses proches se retrouvent voisins : "pluie", "orage", "averse" et "parapluie" habitent le même quartier. Petit détail : cette carte n'a pas deux dimensions, mais plusieurs milliers. Pas pratique à déplier dans la voiture, mais parfait pour un ordinateur.

Deuxième ingrédient : le contexte. Regardez ces deux phrases. "J'ai mangé un avocat." "J'ai appelé mon avocat." Même mot, deux sens complètement différents, et vaut mieux ne pas se tromper, surtout pour l'avocat. Pour s'en sortir, le modèle utilise un mécanisme qu'on appelle l'attention : chaque mot regarde ses voisins pour savoir ce qu'il veut dire ici. Avec "mangé", avocat file vers le rayon fruits et légumes. Avec "appelé", direction le cabinet juridique.

Revenons à nos cordes. Le modèle ne cherche pas corde = rope. Il construit une représentation de toute la phrase, qui atterrit sur la carte tout près de "il pleut très fort". Et de là, il n'a plus qu'à trouver l'équivalent anglais : "It's pouring", ou "It's raining cats and dogs". On ne traduit plus des mots, on traduit du sens.

Et cette mécanique-là, vous la retrouvez partout dans l'IA moderne : embeddings, similarité sémantique, RAG, recherche par intention. Une fois qu'on a compris la carte, beaucoup de choses deviennent moins magiques.

Mais il reste une grande question : qui place les mots sur la carte ? Parce que non, personne ne passe ses journées à positionner "pluie" et "parapluie" à la main. Ça, on le découvre dans le prochain post.

Dans le dernier post, je vous ai laissés avec une carte du sens où "pluie" et "parapluie" habitent le même quartier. Mais une question est restée en suspens : comment un ordinateur, qui ne connaît que des nombres, fait-il pour placer un mot sur cette carte ?

Commençons par une évidence. Quand vous lisez "chat", vous voyez peut-être un matou roulé en boule sur un canapé. L'ordinateur, lui, ne voit rien du tout. Pour lui, "chat" n'est qu'une suite de caractères, pas plus proche de "chien" que de "chaussette". Il faut donc lui donner autre chose à manipuler.

Cette autre chose, c'est un embedding : une liste de nombres qui sert de coordonnées sur la carte. Concrètement, ça ressemble à ça :

chat → [0.12, -0.47, 0.81, ...]
chien → [0.10, -0.42, 0.79, ...]
voiture → [-0.71, 0.20, 0.06, ...]

(En vrai, il y a quelques centaines à quelques milliers de nombres par liste. Je vous épargne la suite.)

Regardez bien les deux premières lignes : les nombres de "chat" et de "chien" se ressemblent, ceux de "voiture" partent complètement ailleurs. C'est exactement ce qu'on veut. Deux animaux domestiques à quatre pattes se retrouvent voisins, et la voiture est garée à l'autre bout de la carte.

Attention au piège : aucun de ces nombres ne veut dire "a des poils" ou "fait miaou". Un embedding n'est pas une définition, et personne n'a décidé que la troisième case mesurait le côté "animal". Ces valeurs sont apprises : on montre au modèle des quantités énormes de texte, et il ajuste les coordonnées jusqu'à ce que les mots qui apparaissent dans des contextes similaires finissent proches les uns des autres. "Chat" et "chien" se croisent tout le temps dans les mêmes phrases ("nourrir le ...", "emmener le ... chez le vétérinaire"), alors ils se rapprochent.

Et ça ne s'arrête pas aux mots. Selon le modèle utilisé, on peut calculer l'embedding d'une phrase, d'un paragraphe ou d'un document entier. Une annonce immobilière, un ticket de support ou une page de documentation peuvent eux aussi devenir un point sur la carte, et c'est là que ça devient vraiment intéressant : si deux textes sont des points, on peut mesurer la distance entre eux.

Alors comment une IA décide-t-elle que deux phrases qui n'ont presque aucun mot en commun parlent pourtant de la même chose ? On sort le mètre ruban dans le prochain post.

Faisons une petite expérience de recherche. Vous tapez sur un site immobilier : "appartement avec extérieur pour une famille près de Genève". Et quelque part dans la base dort cette annonce : "T4 lumineux avec grande terrasse, trois chambres, à Annemasse."

Pour un humain, c'est un match évident. La terrasse, c'est l'extérieur. Trois chambres, c'est pour une famille. Et Annemasse, c'est à dix minutes de Genève (quand les bouchons le permettent). Mais comptez les mots en commun entre les deux phrases : il n'y en a quasiment aucun.

Une recherche classique, par mots-clés, cherche justement des mots identiques. Elle passe donc complètement à côté de l'annonce, pendant que la famille continue à chercher.

C'est là que la carte du sens entre en jeu. On calcule l'embedding de la recherche, celui de l'annonce, et on obtient deux points. Si les deux phrases parlent de la même chose, les deux points sont proches, même sans aucun mot commun.

Reste à définir "proche". La méthode la plus répandue s'appelle la similarité cosinus, et le nom fait plus peur que l'idée. Imaginez que chaque embedding est une flèche qui part du centre de la carte. Deux flèches qui pointent quasiment dans la même direction : les textes parlent de la même chose. Deux flèches perpendiculaires : aucun rapport. On mesure donc l'angle entre les flèches, plutôt que la distance entre leurs pointes. Pour l'ordinateur, le calcul tient en quelques multiplications et additions, ce qui lui permet de comparer une recherche à des millions de textes en un clin d'oeil.

Le résultat est un score : proche de 1, les deux textes pointent dans la même direction ; proche de 0, ils n'ont rien à voir. (En théorie, le score peut descendre jusqu'à -1 pour des flèches opposées, mais avec les modèles d'embeddings courants, on voit surtout des valeurs positives.)

C'est ce qu'on appelle la recherche sémantique : on ne compare plus des mots, on compare des sens. Notre famille trouve son T4 à Annemasse, et le site n'a jamais eu besoin qu'on lui explique qu'une terrasse est un extérieur.

Mais cette mécanique permet bien plus que d'améliorer un moteur de recherche. Elle permet de demander à une IA d'aller fouiller dans vos propres documents avant de répondre. Et ça, c'est le fameux RAG, qu'on démonte dans le prochain post.

Posez à ChatGPT la question "Comment fonctionne notre authentification ?" et vous aurez droit à un joli cours général sur OAuth2, les tokens et les sessions. Très instructif, mais totalement inutile : il ne connaît pas votre système. Et il ne peut pas le connaître, puisque votre documentation interne n'a jamais fait partie de ce qu'il a lu pendant son entraînement.

Alors comment construit-on un assistant capable de répondre sur vos procédures, votre architecture ou vos incidents de l'an dernier ?

Première idée qui vient à l'esprit : réentraîner le modèle sur toute la documentation. C'est long, cher, et il faudrait recommencer à chaque modification d'une page. (On reviendra sur cette option dans quelques posts, elle a ses usages, mais pas celui-là.)

La solution qu'on retrouve presque partout s'appelle le RAG, pour Retrieval Augmented Generation. Derrière ce nom un peu pompeux se cache une idée toute simple : avant de répondre, on va chercher les bonnes pages, et on les donne au modèle avec la question.

Le trajet ressemble à ça :

Question
→ recherche dans vos documents
→ passages pertinents
→ question + passages envoyés au modèle
→ réponse

La recherche, c'est justement la similarité sémantique du post précédent : on compare la question aux documents, et on garde ceux qui pointent dans la même direction. Le modèle reçoit alors quelque chose comme "Voici trois extraits de la documentation interne. En t'appuyant dessus, réponds à : comment fonctionne notre authentification ?"

C'est un peu comme passer un examen à livre ouvert. L'étudiant n'a pas appris le manuel par coeur, mais il sait trouver la bonne page et la reformuler intelligemment.

Et c'est le point le plus souvent mal compris : avec un RAG, l'IA n'apprend pas vos documents. Rien n'est gravé dans le modèle. Elle les consulte au moment où elle en a besoin, puis les oublie. Conséquence très pratique : si vous mettez à jour une procédure, l'assistant utilisera la nouvelle version dès qu'elle aura été réindexée, sans toucher au modèle. Et on peut lui demander d'indiquer d'où vient chaque information.

Seulement voilà : si votre entreprise possède 100 000 documents, vous n'allez pas tous les coller dans la question. Alors comment choisit-on les quelques morceaux qui méritent d'être envoyés au modèle ? On découpe tout ça dans le prochain post.

Imaginez que vous cherchiez une recette de crêpes et qu'on vous tende toute la bibliothèque municipale en disant "c'est quelque part là-dedans". Techniquement, l'information est bien présente. En pratique, vous n'êtes pas plus avancé.

C'est exactement le problème qu'on rencontre avec un RAG sur 100 000 documents. On ne peut pas tout envoyer au modèle : ça ne rentrerait pas dans sa mémoire de travail, ça coûterait une fortune, et noyer la bonne information dans des milliers de pages inutiles dégrade la réponse.

Même à l'échelle d'un seul document, le problème reste entier. Un PDF de 80 pages qui parle d'architecture, de sécurité et de facturation, c'est un seul point sur la carte du sens, placé quelque part au milieu de tous ces sujets. Si la question porte sur la facturation, ce point "moyen" ne sera pas forcément le plus proche.

La solution : on découpe. Chaque document est coupé en morceaux, les fameux chunks, de quelques paragraphes chacun :

Document
├── chunk 1
├── chunk 2
├── chunk 3
└── ...

Chaque chunk reçoit son propre embedding, et tous ces vecteurs sont rangés dans une base vectorielle, une base de données spécialisée pour retrouver très vite les points les plus proches d'un point donné. Quand une question arrive, on calcule son embedding, on demande à la base les cinq ou dix chunks les plus proches, et seuls ceux-là partent vers le modèle.

Sur le papier, c'est simple. Dans la vraie vie, la façon de découper est l'un des réglages qui influencent le plus la qualité d'un RAG. Des chunks trop petits, et vous récupérez une phrase sans son contexte ("la valeur doit être inférieure à 30"... 30 quoi ? de quoi ?). Des chunks trop gros, et vous retombez sur le problème du PDF entier : beaucoup de bruit autour de l'information utile. Et un découpage aveugle, tous les 1 000 caractères par exemple, finira fatalement par couper un tableau en deux ou séparer un titre de son paragraphe.

C'est pour ça qu'on découpe de préférence en suivant la structure du document (titres, sections, paragraphes), souvent avec un léger chevauchement entre deux chunks. Et on ajoute des métadonnées à chaque morceau : document d'origine, date, auteur, projet, droits d'accès. Elles permettent de filtrer ("uniquement la doc du projet X, version actuelle") et de ne jamais montrer à quelqu'un un passage qu'il n'a pas le droit de lire.

Trouver les bons morceaux améliore énormément les réponses, mais ça ne garantit toujours pas que le modèle dira vrai. Pourquoi une IA peut-elle encore inventer quelque chose alors qu'on vient de lui donner les bons documents ? Pour répondre, il faut d'abord comprendre pourquoi elle hallucine, et c'est le sujet du prochain post.

Complétez cette phrase : "La capitale de la France est..." Vous avez répondu Paris sans réfléchir. Un modèle de langage aussi. Et pour comprendre pourquoi une IA hallucine, il faut regarder comment elle a trouvé cette réponse.

Un LLM ne va pas chercher "capitale de la France" dans une encyclopédie interne. Il fait quelque chose de plus modeste et de plus étonnant à la fois : il prédit la suite du texte, un petit morceau à la fois (un token, on y reviendra). À chaque étape, il calcule quels morceaux sont les plus probables compte tenu de tout ce qui précède. Après "La capitale de la France est", "Paris" écrase toute la concurrence, parce qu'il a vu cette association des milliers de fois pendant son entraînement.

Maintenant, changeons de question : "Quel est le titre du troisième roman publié par le physicien qui a découvert l'effet Byanistic ?" (N'allez pas chercher, cet effet n'existe pas.)

Le modèle va faire exactement la même chose : prédire la suite la plus plausible. Or la forme d'une bonne réponse, il la connaît parfaitement : un nom de physicien crédible, un titre de roman qui sonne juste, peut-être une date. Il n'y a pas de voyant rouge interne qui s'allume au moment où il passe d'un fait appris à une pure invention. Le mécanisme est le même, du début à la fin.

C'est pour ça que je n'aime pas dire que l'IA "ment". Mentir suppose de connaître la vérité et de choisir de la cacher. Ici, le modèle produit ce qui ressemble le plus à une bonne réponse, et un modèle entraîné sur des milliards de textes est devenu extraordinairement doué pour produire des choses qui ressemblent à de bonnes réponses. Tout tient en une phrase : plausible ne veut pas dire vrai.

Les modèles récents ont fait de gros progrès. On les entraîne à repérer les fausses prémisses et à dire qu'ils ne savent pas, et sur l'effet Byanistic, un bon modèle actuel vous répondra probablement qu'il ne connaît pas cet effet. Mais sur une question obscure, une référence bibliographique précise ou un chiffre pointu, le risque reste bien réel.

C'est justement pour ça qu'on leur donne des documents, des sources, parfois des outils : pour que la réponse plausible ait de bonnes chances d'être aussi la réponse vraie. Mais même avec un RAG bien construit, les hallucinations ne disparaissent pas complètement. Pourquoi ? C'est ce qu'on verra dans le prochain post.

On a vu dans le dernier post qu'un LLM produit la réponse la plus plausible, pas forcément la plus vraie. Et on avait vu avant qu'un RAG lui fournit les bons documents. Problème réglé, donc ? Pas tout à fait, parce qu'entre la question et la réponse, il y a toute une chaîne, et chaque maillon peut lâcher.

Reprenons notre assistant interne et suivons une question : "Quel est le délai de préavis pour une démission ?"

Premier maillon, la recherche. Elle peut ramener le mauvais document, par exemple la procédure de résiliation des contrats fournisseurs, qui parle beaucoup de "préavis" et de "délai". Ou ne pas ramener le bon, parce qu'il est rédigé avec d'autres mots et qu'il arrive onzième alors qu'on n'en garde que dix.

Deuxième maillon, le découpage. Le bon chunk est là, mais il s'arrête juste avant la phrase "sauf pour les cadres, où le délai est de trois mois". Le modèle répond juste... pour une partie des salariés seulement.

Troisième maillon, les documents eux-mêmes. La version 2022 et la version 2025 de la procédure sont toutes les deux dans la base, et elles ne disent pas la même chose. Laquelle croire ?

Quatrième maillon, l'interprétation. Tous les bons passages sont là, mais le modèle les combine mal, ou tire une conclusion que le texte ne dit pas vraiment.

Et enfin, le cas le plus traître : la réponse n'existe tout simplement pas dans les documents. On retombe alors sur le comportement du post précédent : si on ne lui a pas appris à s'arrêter, le modèle complète avec ce qui lui semble plausible.

Un RAG réduit donc fortement les hallucinations, mais ne les supprime pas. Ce qu'on appelle le grounding, c'est justement l'effort pour ancrer chaque réponse dans les sources fournies, et un bon système se reconnaît à trois comportements.

Il sait dire "je ne sais pas". C'est peut-être la réponse la plus précieuse qu'un assistant puisse donner, et elle se prépare : dans les instructions, dans le choix du modèle et dans les tests.

Il cite ses sources. Chaque affirmation renvoie au passage d'où elle vient, ce qui permet à l'utilisateur de vérifier en deux clics.

Il distingue ce qui est écrit de ce qu'il déduit. "La procédure indique trois mois" et "j'en conclus que votre cas relève probablement de cette règle", ce ne sont pas deux phrases du même niveau de confiance.

Jusqu'ici, notre IA cherche, lit et répond. Mais on peut aller plus loin et lui permettre d'agir : consulter une API, récupérer une donnée en temps réel, créer un ticket, déclencher une action. C'est là qu'on commence à parler d'agents, et c'est le sujet du prochain post.

Demandez à un modèle de langage sans aucun accès extérieur : "Quel temps fait-il en ce moment à Genève ?" Dans le meilleur des cas, il vous répondra honnêtement qu'il n'en sait rien. Dans le pire, il vous décrira un joli ciel dégagé avec 18 degrés, parce que c'est plausible pour la saison (vous connaissez maintenant la chanson).

Normal : la météo de ce matin ne faisait pas partie de ses données d'entraînement, et aucun document interne, aucun RAG ne la contiendra non plus. Il faut aller la chercher, maintenant, à la source.

C'est toute la différence entre un chatbot et un agent. Un chatbot, c'est un modèle qui parle. Un agent, c'est un modèle qui parle et qui dispose d'outils qu'il peut décider d'utiliser.

Voyons ce qui se passe avec notre question. L'agent commence par comprendre qu'il lui manque une donnée en temps réel. Il regarde les outils à sa disposition et repère un outil météo. Il ne l'exécute pas lui-même : il produit une demande structurée, quelque chose comme "appelle l'outil météo avec ville = Genève". Le programme qui l'entoure fait réellement l'appel à l'API, récupère le résultat ("pluie, 11 °C") et le renvoie au modèle. Et c'est seulement là que le modèle rédige sa réponse : "Il pleut à Genève, 11 degrés, prenez un parapluie."

C'est ce qu'on appelle le tool calling, et le plus important se cache dans la boucle : le modèle agit, observe le résultat, puis décide de la suite. Il peut s'arrêter là, ou appeler un autre outil si la réponse en a besoin. Pour "Dois-je prendre un parapluie pour mon rendez-vous de 15 h ?", il ira peut-être d'abord consulter l'agenda pour savoir où a lieu le rendez-vous, puis la météo de cet endroit, avant de répondre.

On entend souvent qu'un agent, c'est juste un chatbot avec un très gros prompt. C'est faux : le prompt le plus long du monde ne fera jamais apparaître la météo de ce matin. Ce qui fait l'agent, ce sont les outils, et la capacité à décider quand s'en servir.

Et c'est justement là que tout se complique. Si l'agent a accès à une météo, un agenda, un CRM et une messagerie, comment sait-il quel outil utiliser, avec quels paramètres et à quel moment ? On ouvre la boîte à outils dans le prochain post.

Donnez à quelqu'un une boîte à outils sans étiquettes et demandez-lui de réparer une fuite. Il finira peut-être par y arriver, mais vous aurez eu le temps de sortir la serpillière. Pour une IA, c'est pareil : un outil ne sert à rien si elle ne sait pas à quoi il sert ni comment le tenir.

Prenons un agent qui a accès à quatre outils :

search_customer(email)
create_invoice(customerId, amount)
search_property(city, maxPrice)
send_email(to, subject, body)

Et donnons-lui cette consigne : "Trouve les biens à moins de 500 000 € à Annecy et envoie-les à Paul."

Comment fait-il son choix ? Le secret, c'est que chaque outil arrive avec sa fiche d'identité : un nom, une description en langage naturel ("recherche des biens immobiliers disponibles dans une ville, sous un prix maximum"), et un schéma qui décrit précisément ses paramètres (city est un texte, maxPrice est un nombre, les deux sont obligatoires). Tout ça est envoyé au modèle avec la consigne.

Le modèle lit la consigne, lit les fiches, et fait le rapprochement. "Biens à moins de 500 000 € à Annecy", ça ressemble furieusement à search_property, avec city = "Annecy" et maxPrice = 500000. Il produit une demande d'appel structurée, que le programme exécute. Les résultats reviennent, et le modèle enchaîne : il faut maintenant envoyer un email à Paul... mais quel Paul ? S'il n'a pas son adresse, il peut la chercher avec l'outil prévu, ou tout simplement vous la demander. Une fois qu'il l'a, direction send_email, avec un objet et un corps rédigés à partir des résultats.

Remarquez au passage que create_invoice n'a jamais été touché. La description compte énormément : un outil mal décrit sera mal utilisé, ou pas utilisé du tout. Écrire la fiche d'un outil, c'est un peu écrire la documentation pour un collègue très rapide qui n'a que cette fiche pour comprendre ce que vous attendez de lui.

Les outils sont en quelque sorte les mains du modèle. Mais retenez bien ceci : le modèle ne fait que demander, c'est le programme qui décide de ce qui s'exécute réellement. Il peut vérifier les paramètres, refuser un appel, exiger une confirmation humaine avant d'envoyer un email ou de créer une facture. Le LLM propose, le code dispose. Et quand on connecte une IA à de vrais systèmes, cette frontière est probablement la partie la plus importante de toute l'application.

Maintenant que notre agent sait enchaîner deux outils, pourquoi pas dix ? Dès qu'on arrive à des tâches en plusieurs étapes, une question se pose : est-ce qu'une IA sait réellement planifier ce qu'elle va faire ? On en parle dans le prochain post.

Confiez cette mission à un agent : "Prépare une synthèse des incidents de la semaine et propose les trois sujets les plus importants pour le prochain comité."

Un humain ne se lancerait pas tête baissée. Il découperait mentalement le travail : retrouver les incidents, regarder leur impact, les regrouper par thème, repérer ceux qui reviennent, rédiger la synthèse, et seulement ensuite choisir les trois sujets. Six étapes, dont chacune dépend de la précédente. Alors, une IA sait-elle faire ça ?

La réponse honnête, c'est oui, mais pas toutes de la même façon. Et surtout, on ne laisse pas toujours le modèle planifier seul.

Première approche, le plan explicite. On demande d'abord au modèle d'écrire son plan, étape par étape, puis on l'exécute. Avantage : on peut relire le plan, voire le valider, avant que quoi que ce soit ne se passe. Inconvénient : si l'étape 2 révèle une surprise (tiens, la moitié des incidents concernent la même API), le plan initial peut devenir obsolète.

Deuxième approche, le plan construit en avançant. L'agent fait une étape, regarde le résultat, décide de la suivante. C'est la boucle vue dans le post sur les agents : agir, observer, recommencer. Beaucoup plus souple, mais aussi plus difficile à prévoir, et il arrive que l'agent tourne en rond ou parte sur une piste secondaire.

Troisième approche, l'agent purement réactif. Pas de plan du tout, il répond à chaque situation au coup par coup. Parfait pour une tâche courte, beaucoup moins pour une mission en six étapes.

Et enfin, l'approche qu'on retrouve très souvent en production : le workflow déterministe. Les étapes sont écrites en dur dans le code (récupérer les incidents, puis les regrouper, puis rédiger), et on ne confie au LLM que les étapes où il excelle vraiment, comme regrouper par thème ou rédiger la synthèse. On perd de la flexibilité, mais on gagne énormément en fiabilité, en coût et en prévisibilité.

Dans tous les cas, un ingrédient est indispensable : l'état. L'agent doit savoir où il en est, ce qu'il a déjà fait et ce qu'il a trouvé. Sans ça, il oublie qu'il a déjà récupéré les incidents et recommence, ou perd le résultat de l'étape 3 au moment de rédiger.

Mon conseil : ne donnez au modèle que la liberté dont la tâche a réellement besoin. Si les étapes sont toujours les mêmes, écrivez-les. Si elles dépendent de ce qu'on découvre en chemin, laissez-le planifier, mais gardez un oeil sur lui.

Et puisqu'on peut spécialiser un agent pour une tâche, une idée vient vite : pourquoi ne pas en créer plusieurs qui travailleraient ensemble ? On forme l'équipe dans le prochain post.

Quand un cabinet d'avocats prépare un dossier complexe, une seule personne ne fait pas tout. Quelqu'un recherche les textes applicables, quelqu'un d'autre épluche la jurisprudence, un troisième analyse le cas, et un associé rédige la synthèse finale. Chacun son métier.

L'idée du multi-agent, c'est de reproduire cette organisation avec des IA. Sur notre dossier juridique, on aurait un agent de recherche de textes, un agent de jurisprudence, un agent d'analyse et un agent de synthèse. Chacun avec ses propres instructions, ses propres outils, et parfois même son propre modèle : un modèle rapide et bon marché pour trier, un modèle plus puissant pour raisonner. Un agent orchestrateur distribue le travail et assemble les résultats.

Sur le papier, c'est séduisant. Chaque agent a une consigne courte et précise au lieu d'un prompt à rallonge qui essaie de tout couvrir. On peut tester, améliorer ou remplacer chaque agent séparément. Et quand les tâches sont indépendantes, comme chercher les textes et la jurisprudence, elles peuvent tourner en parallèle.

Mais (il y a toujours un mais) plus d'agents ne veut pas automatiquement dire meilleur résultat. Chaque agent supplémentaire ajoute des appels au modèle, donc du coût et de la latence. Il faut écrire et maintenir l'orchestration. Les informations doivent passer d'un agent à l'autre, et chaque passage est une occasion d'en perdre un morceau : l'agent de synthèse ne voit que ce que les autres ont bien voulu lui transmettre. Et quand le résultat final est faux, bon courage pour trouver lequel des quatre s'est trompé.

C'est un peu comme dans une vraie équipe. Mettre quatre personnes sur une tâche qu'une seule pouvait faire en une heure, c'est rarement quatre fois plus rapide, et c'est souvent une réunion de plus.

La bonne question n'est donc pas "combien d'agents ?", mais "est-ce que les responsabilités sont vraiment séparables ?". Si chaque agent a un rôle clair, des entrées et des sorties bien définies, et que le travail se découpe proprement, le multi-agent a tout son sens. Sinon, un seul agent bien conçu, avec les bons outils, fera souvent mieux, plus vite et moins cher.

Seulement, dès qu'on commence à connecter beaucoup d'outils et plusieurs agents, un autre problème apparaît : chaque connexion est une intégration spécifique à écrire. Comment standardiser tout ça ? C'est là qu'arrive MCP, le sujet du prochain post.

Vous vous souvenez de l'époque où chaque téléphone avait son propre chargeur ? Un pour le Nokia, un autre pour le Sony Ericsson, un troisième pour l'appareil photo, et un tiroir entier de câbles dont plus personne ne savait à quoi ils servaient. Puis l'USB-C est arrivé, et on peut désormais presque tout brancher avec le même câble.

Dans le monde des agents IA, on a longtemps vécu à l'époque du tiroir à câbles. Vous voulez que votre assistant accède à votre CRM ? Il faut écrire une intégration pour cet assistant-là. Vous voulez que le même CRM soit utilisable depuis un autre assistant ou un éditeur de code ? Nouvelle intégration, dans un autre format. Un troisième ? Rebelote.

Client A → intégration spécifique
Client B → intégration spécifique
Client C → intégration spécifique

MCP, pour Model Context Protocol, c'est la tentative de standardiser tout ça. Lancé par Anthropic fin 2024 et adopté depuis par une bonne partie de l'écosystème, c'est un protocole ouvert qui définit une manière commune d'exposer des outils et des ressources à des clients IA compatibles.

Concrètement, vous écrivez une seule fois un serveur MCP pour votre CRM. Il décrit les outils disponibles (avec les fameuses fiches d'identité du post sur le function calling : nom, description, paramètres), et n'importe quel client compatible peut les découvrir et les utiliser :

Serveur MCP → Client IA A
Serveur MCP → Client IA B
Serveur MCP → Client IA C

On passe d'une intégration par couple outil-assistant à une intégration par outil. Avec dix outils et trois assistants, ça fait dix serveurs au lieu de trente intégrations.

Mais l'intérêt principal, à mon avis, n'est pas seulement technique. MCP découple vos outils métier des modèles et des assistants qui les utilisent. Votre serveur ne sait pas, et n'a pas besoin de savoir, si c'est Claude, ChatGPT ou un agent maison qui l'appelle. Vous pouvez changer de modèle demain sans réécrire vos intégrations. Et pour un éditeur de logiciel, exposer un serveur MCP devient une façon de rendre son produit directement utilisable par les assistants IA de ses clients.

Ça ne règle pas tout, évidemment. Il faut toujours gérer l'authentification, les droits (un serveur MCP qui peut tout faire est un serveur MCP dangereux) et soigner les descriptions d'outils. Mais le tiroir à câbles, lui, commence enfin à se vider.

Et si l'IA peut désormais accéder à nos outils et à nos documents, une autre question arrive naturellement : comment fait-elle pour se souvenir d'une information d'une conversation à l'autre ? On en parle dans le prochain post.

Vous avez sûrement déjà vécu ça : vous expliquez longuement votre projet à une IA, vous revenez le lendemain dans une nouvelle conversation, et elle vous regarde avec des yeux ronds. Et pourtant, d'autres fois, elle se souvient que vous travaillez en Java ou que vous préférez les réponses courtes. Alors, une IA a-t-elle une mémoire, oui ou non ?

Tout dépend de ce qu'on appelle mémoire. Et c'est justement là que tout le monde s'emmêle, parce que quatre mécanismes très différents se cachent derrière ce même mot.

Le premier, c'est le contexte. Un modèle de langage, en lui-même, ne se souvient de rien entre deux requêtes. À chaque message, l'application lui renvoie toute la conversation depuis le début, et c'est ce texte-là qu'il lit. Si vous avez l'impression qu'il se souvient de ce que vous avez dit il y a dix messages, c'est simplement que ces dix messages lui ont été renvoyés. Nouvelle conversation, contexte vide.

Le deuxième, c'est la mémoire applicative. L'application (pas le modèle) sauvegarde certaines informations quelque part, "l'utilisateur travaille en Java", "préfère les réponses courtes", et les réinjecte discrètement dans le contexte des conversations suivantes. Le modèle n'a rien retenu : on lui a glissé un pense-bête en haut de la page.

Le troisième, c'est le RAG, qu'on a vu il y a quelques posts : une recherche dynamique dans une base documentaire, pour aller chercher les passages utiles à la question du moment. Là encore, le modèle ne retient rien, il consulte.

Le quatrième, enfin, c'est le fine-tuning : un entraînement supplémentaire qui modifie réellement les paramètres du modèle. C'est le seul des quatre où quelque chose change "dans la tête" du modèle, mais on s'en sert surtout pour ajuster un comportement, pas pour stocker des faits à retrouver.

Si on veut une image : le contexte, c'est ce que vous avez sous les yeux sur le bureau. La mémoire applicative, ce sont les post-it collés sur l'écran. Le RAG, c'est l'armoire de dossiers dans laquelle vous allez fouiller. Et le fine-tuning, c'est une formation que vous avez suivie et qui a changé votre façon de travailler.

Pourquoi c'est important de les distinguer ? Parce qu'ils répondent à des besoins complètement différents. Si votre assistant doit retenir les préférences d'un utilisateur, c'est de la mémoire applicative. S'il doit répondre à partir de la documentation de l'entreprise, c'est du RAG. Se tromper de mécanisme, c'est se lancer dans un projet de trois mois pour résoudre un problème qui se réglait en une semaine.

Et justement, si on peut ajouter une mémoire et un RAG sans toucher au modèle, à quoi sert encore le fine-tuning ? On compare les deux dans le prochain post.

C'est une question qui revient très souvent dans les projets IA : "On voudrait que l'IA connaisse toute notre documentation. On fait du fine-tuning ?" Et dans la grande majorité des cas, la réponse est non. Pas parce que le fine-tuning est inutile, mais parce qu'il ne fait pas ce qu'on imagine.

Reprenons l'image du post précédent. Le RAG, c'est l'armoire à dossiers dans laquelle on va chercher la bonne page au moment où on en a besoin. Le fine-tuning, c'est une formation qui change la façon de travailler. Et toute la différence est là.

Le fine-tuning consiste à continuer l'entraînement d'un modèle existant sur vos propres exemples : des centaines ou des milliers de paires "voici une entrée, voici la réponse attendue". Le modèle ajuste ses paramètres pour reproduire ce qu'il a vu. Ce qu'il apprend très bien, c'est une manière de faire : un style de réponse, un ton, un format de sortie précis, une façon de traiter une tâche répétitive. Par exemple, transformer un email client en fiche structurée avec toujours les mêmes champs, ou répondre dans le ton exact de votre service client.

Ce qu'il apprend beaucoup moins bien, ce sont des faits précis et vérifiables. Fine-tunez un modèle sur votre documentation, il en retiendra une impression générale et un vocabulaire, mais pas de quoi citer la bonne version de la procédure au bon paragraphe. Pire, il pourra répondre avec beaucoup d'assurance en mélangeant l'ancienne et la nouvelle version (vous vous souvenez : plausible ne veut pas dire vrai). Et le jour où la documentation change, il faut refaire l'entraînement.

Le RAG, lui, est taillé pour les connaissances qui bougent : documents, données métier, procédures mises à jour. On modifie la base, et la réponse suit dès la réindexation, sans toucher au modèle. En bonus, on sait d'où vient chaque information, ce qui permet de citer ses sources.

Si je devais résumer : le RAG, c'est pour ce que le modèle doit savoir, le fine-tuning, pour la façon dont il doit se comporter.

Et les deux ne s'opposent pas. On peut très bien fine-tuner un modèle pour qu'il réponde dans le bon format et le bon ton, et l'alimenter avec un RAG pour qu'il réponde sur les bons faits. Mais dans la plupart des projets, je commencerais par un bon prompt et un RAG, et je n'envisagerais le fine-tuning qu'une fois ces deux leviers épuisés. Le fine-tuning n'est pas une base documentaire magique.

Que ce soit pour le RAG, le fine-tuning, les limites de contexte ou la facture de l'API, il y a une unité qu'on croise partout depuis le début de cette série sans l'avoir vraiment expliquée : le token. Un token, c'est quoi exactement ? Réponse dans le prochain post.

Depuis le début de cette série, j'ai parlé de tokens à plusieurs reprises en promettant d'y revenir. Le moment est venu de payer ma dette.

Premier réflexe : se dire qu'un token, c'est un mot. C'est presque ça, mais pas tout à fait. Un token, c'est l'unité de texte que le modèle manipule réellement. Ça peut être un mot entier, un morceau de mot, un signe de ponctuation, un espace suivi de quelques lettres.

Prenons un mot bien long : "internationalisation". Plutôt que de le traiter d'un bloc, un modèle pourrait le découper en quelque chose comme "international" + "isation". (Exemple volontairement simplifié : la découpe exacte dépend du tokenizer de chaque modèle, et deux modèles ne découperont pas forcément le même mot de la même façon.)

Pourquoi ne pas simplement travailler mot par mot ? Parce qu'il faudrait un dictionnaire de tous les mots de toutes les langues, avec leurs conjugaisons, leurs pluriels, les fautes de frappe, les noms propres, le code informatique... Mission impossible. À l'inverse, travailler lettre par lettre rendrait les textes interminables à traiter. Les tokens sont un compromis malin : un vocabulaire de quelques dizaines à quelques centaines de milliers de morceaux, construit automatiquement à partir des séquences les plus fréquentes. Les mots courants ont souvent leur propre token, les mots rares sont reconstitués à partir de plusieurs morceaux, un peu comme des Lego.

Et ce n'est pas qu'une curiosité technique, parce que tout se compte en tokens. La fenêtre de contexte d'un modèle, c'est-à-dire la quantité de texte qu'il peut lire d'un coup, se mesure en tokens. La facture de l'API aussi : on paie les tokens envoyés et les tokens générés. Même la vitesse de réponse s'exprime souvent en tokens par seconde.

Petite subtilité qui nous concerne directement : les tokenizers ont souvent été construits sur des corpus majoritairement anglophones. Résultat, un même texte demande généralement un peu plus de tokens en français qu'en anglais, pour une facture légèrement plus salée à contenu égal. En ordre de grandeur, un token représente environ trois quarts d'un mot en anglais, un peu moins en français, mais ça varie selon le modèle.

C'est aussi pour ça qu'on disait, dans le post sur les hallucinations, qu'un LLM prédit la suite un token à la fois. À chaque étape, il calcule une probabilité pour chacun des tokens de son vocabulaire, puis en choisit un. Mais quand plusieurs tokens sont plausibles, comment choisit-il lequel prendre ? Toujours le plus probable ? Pas forcément. On parlera probabilités, sampling et température dans le prochain post.

Dans le dernier post, on a laissé le modèle devant une liste de candidats. Après "Le ciel est", il a calculé quelque chose comme : "bleu" 42 %, "gris" 21 %, "nuageux" 16 %, "clair" 12 %, "rose" 4 %. Reste à trancher. Doit-il toujours prendre celui qui est en tête ? C'est exactement le rôle de la température.

Imaginez un curseur. Tout à gauche, à température 0, le modèle prend systématiquement le token le mieux noté. Vous obtenez "Le ciel est bleu", et vous l'obtiendrez encore demain. Poussez le curseur vers la droite, et les options moins bien classées commencent à avoir leur chance : "gris", "nuageux", et si vous poussez vraiment loin, "rose".

Ce qui se passe mathématiquement est plus simple qu'il n'y paraît. La température ne change aucune connaissance du modèle : elle écrase ou accentue les écarts entre les probabilités qu'il vient de calculer. Une température basse rend la distribution plus pointue, le favori écrase encore davantage ses concurrents. Une température élevée l'aplatit, les candidats se rapprochent et le tirage s'ouvre. On règle la façon de piocher, pas le contenu du sac.

C'est le point que je tiens à faire passer, parce qu'on lit souvent l'inverse : monter la température ne rend pas le modèle plus intelligent, et pas non plus plus créatif au sens où il aurait de meilleures idées. Elle lui fait simplement accepter des suites qu'il jugeait moins probables. On y gagne de la variété, on y perd de la fiabilité, et trop haut, le texte part en vrille en gardant exactement le même aplomb.

En pratique, le réglage suit la tâche. Extraction de données, classification, génération de JSON, réponse appuyée sur une documentation : température basse, on veut de la stabilité. Brainstorming, titres, reformulations, variantes d'un texte : on monte un peu, parce que la variété est précisément ce qu'on cherche.

Un détail qui surprend beaucoup de monde : même à température 0, vous n'êtes pas certain d'obtenir deux fois exactement le même texte. Pourquoi la même question peut-elle donner deux réponses différentes ? C'est le sujet du prochain post.

Posez deux fois la même question à un modèle, dans deux conversations neuves, et vous obtiendrez souvent deux réponses différentes. Demandez un titre pour un article sur l'IA dans l'immobilier : la première fois "L'IA transforme l'immobilier", la seconde "Quand l'IA rencontre l'immobilier". Pour qui vient du développement classique, c'est déroutant. Une fonction, ça rend toujours la même sortie pour la même entrée.

Sauf qu'un LLM n'est pas une fonction de ce genre. À chaque étape, il produit une distribution de probabilités sur les tokens possibles, puis quelque chose choisit dans cette distribution. Ce choix, c'est le sampling, et c'est lui qui introduit la variabilité. Dès que plusieurs suites sont plausibles, et pour un titre elles le sont toutes, le tirage peut tomber différemment.

Plusieurs réglages pilotent ce tirage. La température, vue au post précédent, ouvre ou resserre l'éventail. Le top-p, souvent appelé nucleus sampling, ne garde que les candidats les plus probables jusqu'à atteindre une masse de probabilité donnée, 0,9 par exemple, et ignore la longue traîne. Certaines API acceptent une seed, une graine qui rend le tirage reproductible.

Et là, une mauvaise nouvelle pour les amateurs de reproductibilité parfaite : même à température 0, deux appels identiques peuvent diverger. Les calculs se font en virgule flottante sur des GPU, l'ordre des opérations dépend de la façon dont les requêtes sont regroupées sur le serveur, et de minuscules écarts d'arrondi suffisent à faire basculer un choix entre deux candidats presque à égalité. Ajoutez à cela les mises à jour de modèle côté fournisseur, et vous comprenez pourquoi "même prompt, même réponse" n'est jamais une garantie contractuelle.

Ce n'est pas forcément un défaut. Pour du brainstorming, des titres ou de la reformulation, c'est même l'intérêt. Pour de l'extraction, de la classification ou une sortie structurée qui part dans un autre système, c'est un problème, et on le traite par une température basse, un format imposé et surtout des vérifications sur la sortie.

Tout ça se joue dans une même limite : le modèle ne peut pas ingérer une quantité infinie de texte. Qu'est-ce qu'une fenêtre de contexte, au juste ? Réponse dans le prochain post.

Vous collez un gros document dans un assistant, et il vous répond que c'est trop long. Pourtant, vous n'avez rien écrit de compliqué. Ce qui vient de saturer, c'est la fenêtre de contexte.

La fenêtre de contexte, c'est la quantité de texte, comptée en tokens, que le modèle peut prendre en compte en une seule requête. Voyez-la comme un plan de travail : tout ce sur quoi le modèle va travailler doit y tenir en même temps.

Et le plan de travail se remplit plus vite qu'on ne le croit, parce qu'il ne contient pas que votre question. Il y a d'abord le prompt système, ces instructions invisibles qui définissent le comportement de l'assistant. Puis l'historique de la conversation, renvoyé en entier à chaque message. Puis votre question. Puis, s'il y a un RAG, les passages récupérés dans vos documents. Puis les résultats des outils appelés. Et enfin la réponse en cours de génération, qui consomme elle aussi des tokens.

Attention au malentendu le plus fréquent : cette fenêtre n'est ni une mémoire permanente, ni une base documentaire. Rien n'y reste. C'est une table qu'on débarrasse entièrement à la fin de chaque requête, et qu'on redresse en repartant de zéro à la suivante.

Les conséquences sont très concrètes. Une application qui empile cent pages de documentation, deux cents messages d'historique et trente résultats d'outils va remplir la table de choses inutiles, payer chaque token au passage, et répondre plus lentement. Quand la fenêtre déborde, il faut couper quelque part : les systèmes tronquent l'historique, le résument, ou renoncent à des documents. Mal fait, c'est précisément l'information utile qui saute.

On se dit alors qu'il suffit de prendre un modèle à très grande fenêtre et de tout y mettre. C'est tentant, et ça ne suffit pas : une information peut être présente dans le contexte et pourtant mal utilisée. Pourquoi ? C'est le sujet du prochain post.

Prenez un dossier de 500 pages. L'information décisive se trouve page 247, au milieu d'un paragraphe. Vous donnez tout au modèle, qui a une fenêtre de contexte assez grande pour l'avaler entièrement, et vous posez votre question. Et il passe à côté.

C'est un cas très courant, et c'est contre-intuitif. Présent dans le contexte ne veut pas dire correctement utilisé.

Deux raisons à ça. La première est une histoire de bruit. Votre phrase utile est noyée au milieu de dizaines de milliers d'autres, dont beaucoup parlent de sujets voisins avec un vocabulaire similaire. Plus il y a de candidats plausibles autour, plus la bonne information est difficile à isoler. La seconde tient à la position : plusieurs travaux ont montré que les modèles exploitent mieux ce qui se trouve au début et à la fin d'un long contexte que ce qui est enfoui au milieu. Le phénomène a même un nom, "lost in the middle".

À cela s'ajoutent deux effets très prosaïques. Le coût, puisqu'on paie tous les tokens envoyés, y compris les 499 pages inutiles. Et la latence, parce qu'un contexte énorme met plus de temps à être traité. Un assistant qui répond en trente secondes au lieu de trois, c'est un assistant qu'on n'utilise plus.

C'est exactement pour ça qu'un bon RAG ne consiste pas à envoyer le maximum de texte possible. Son travail, c'est de fournir le bon contexte, pas le plus gros. Quelques passages bien choisis battent presque toujours cinquante pages "au cas où". D'où l'attention portée au découpage, au filtrage par métadonnées, et au reranking, cette seconde passe qui reclasse les passages récupérés avant de les envoyer au modèle.

Reste une question de fond qu'on a contournée depuis le début de cette série : par quel mécanisme le modèle relie-t-il un mot à un autre, et décide-t-il de ce qui compte dans une phrase ? C'est l'attention, le coeur des Transformers, et c'est le sujet du prochain post.

Lisez cette phrase : "Le chat que ma soeur a adopté hier dort sur le canapé." Qui dort ? Le chat, évidemment. Pourtant, entre "chat" et "dort", il y a sept mots, dont une soeur et une adoption. Votre cerveau a fait le lien sans effort. Le modèle, lui, a besoin d'un mécanisme pour ça, et ce mécanisme s'appelle l'attention.

Voici l'idée. Chaque token de la phrase produit trois choses à partir de sa représentation : une requête (query), une clé (key) et une valeur (value). Si on caricature un peu, la requête est la question que le token pose au reste de la phrase, la clé est l'étiquette qu'il présente aux autres, et la valeur est l'information qu'il apporte quand on s'intéresse à lui.

Le modèle compare alors la requête de chaque token aux clés de tous les autres. Plus ça correspond, plus le poids d'attention est élevé. Le token "dort" pose en substance la question "qui fait cette action ?", et c'est la clé de "chat" qui y répond le mieux, pas celle de "soeur" ni celle de "canapé". Chaque token construit ensuite sa nouvelle représentation en mélangeant les valeurs des autres, pondérées par ces poids. Autrement dit, chaque mot se réécrit en tenant compte de ceux qui comptent pour lui.

C'est aussi la réponse à une énigme du tout premier post de la série. "J'ai mangé un avocat" et "J'ai appelé mon avocat" contiennent le même mot, mais dans le premier cas l'attention le rapproche de "mangé", dans le second de "appelé". La représentation finale n'est plus la même.

Un point important, parce que le mot induit en erreur : le modèle ne regarde rien consciemment. Il n'y a pas de projecteur intérieur qui se braque sur un mot. Ce sont des produits de matrices et des pondérations, rien de plus. Le mécanisme se répète en parallèle sur plusieurs "têtes" d'attention, qui capturent des relations différentes, puis d'une couche à l'autre, ce qui permet de construire des dépendances de plus en plus abstraites.

Tout ceci est magnifiquement parallélisable, et c'est une chance, parce que le volume de calcul est colossal. Pourquoi les modèles réclament-ils autant de GPU ? On ouvre le capot dans le prochain post.

Pour comprendre pourquoi l'IA tourne sur des GPU, la meilleure image reste celle de la cuisine. Un CPU, c'est une brigade de quelques chefs étoilés : peu nombreux, très rapides, capables de réaliser n'importe quel plat, y compris les plus techniques. Un GPU, c'est une salle avec des milliers de commis : chacun ne sait faire qu'un geste simple, mais ils le font tous en même temps.

Pour éplucher dix mille carottes, vous voulez les commis.

Et un Transformer, c'est exactement ça : un épluchage gigantesque. Derrière l'attention et les couches du réseau, il n'y a que des multiplications de matrices, c'est-à-dire des millions d'opérations identiques sur des nombres, sans dépendance entre elles. Pile ce qu'un GPU sait faire, avec ses milliers d'unités de calcul en parallèle.

Le détail savoureux, c'est que les GPU n'ont pas été conçus pour ça. Ils ont été créés pour le jeu vidéo et le calcul graphique, où il faut calculer la couleur de millions de pixels par image, chacun indépendamment. Il se trouve que les réseaux de neurones réclament le même genre d'effort. L'IA moderne roule en grande partie sur une architecture pensée pour afficher des explosions à 60 images par seconde.

Autre point rarement mentionné : la mémoire compte autant que la puissance de calcul. Les paramètres du modèle doivent tenir dans la mémoire de la carte, et c'est souvent elle qui décide si un modèle donné peut tourner sur votre machine. C'est aussi la raison pour laquelle on quantise les modèles, c'est-à-dire qu'on réduit la précision des nombres, pour les faire entrer dans des cartes plus modestes.

Aujourd'hui, le paysage s'est élargi : GPU, TPU chez Google, puces dédiées à l'inférence, accélérateurs maison chez les gros fournisseurs. Le principe ne change pas, il s'agit toujours d'exécuter d'énormes volumes d'opérations numériques en parallèle.

Avec assez de données et assez de calcul, on peut entraîner un modèle. Mais concrètement, comment entraîne-t-on un LLM ? C'est le sujet du prochain post.