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.