Lis le sch\u00e9ma comme un aiguillage : le routeur choisit la voie, les retrievers font le travail, et la critique garde la sortie avant que la r\u00e9ponse n’atteigne l’utilisateur.<\/figcaption><\/figure>\n\n\nLe routeur : choisir le bon outil<\/h3>\n Des retrievers, il en existe de g\u00e9n\u00e9raux et de tr\u00e8s \u00e9troits. Un retriever vectoriel est adapt\u00e9 aux sources non structur\u00e9es. Un text2cypher, qui traduit la question en requ\u00eate sur un graphe, convient aux donn\u00e9es structur\u00e9es. Mais en production, aucun des deux ne suffit toujours sur des donn\u00e9es complexes : on construit donc au fil du temps des retrievers sp\u00e9cialis\u00e9s, comme un gabarit de requ\u00eate cod\u00e9e en dur qui prend des param\u00e8tres.<\/p>\n
Prends deux retrievers cod\u00e9s en dur, capital_by_country<\/code> et country_by_capital<\/code>. Pour \u00ab What is the capital of France ? \u00bb, le routeur (un LLM) choisit le premier avec \u00ab France \u00bb comme argument : capital_by_country(\"France\")<\/code>.<\/p>\nUne pr\u00e9cision importante : le LLM n’appelle jamais directement les retrievers. Il d\u00e9cide lequel utiliser et avec quels arguments, et l’appel effectif reste \u00e0 la charge du syst\u00e8me qui l’entoure. C’est le principe du function calling<\/em>, et il faut que le mod\u00e8le le supporte nativement, ou qu’on s’y prenne avec l’approche ReAct.<\/p>\nLa critique : ne pas laisser passer une mauvaise r\u00e9ponse<\/h3>\n La critique est une fonction bloquante. Si la r\u00e9ponse est incorrecte ou incompl\u00e8te, elle l’emp\u00eache de continuer, g\u00e9n\u00e8re une nouvelle question qui permet de r\u00e9cup\u00e9rer l’information manquante et relance un tour de recherche.<\/p>\n
Il faut cependant pr\u00e9voir une sortie de boucle. La bonne r\u00e9ponse peut simplement ne pas exister dans les donn\u00e9es, et la critique doit alors pouvoir le signaler plut\u00f4t que de tourner ind\u00e9finiment.<\/p>\n
\n\ud83d\udca1 Intuition<\/strong> Le routeur r\u00e9pond \u00e0 \u00ab o\u00f9 chercher ? \u00bb, la critique \u00e0 \u00ab ai-je vraiment de quoi r\u00e9pondre ? \u00bb. Sans la seconde, l’agent invente ; sans le premier, il cherche partout et mal.<\/p>\n<\/blockquote>\nBoucler : it\u00e9ratif, r\u00e9cursif, adaptatif<\/h3>\n Quand une seule passe ne suffit pas, trois mani\u00e8res de r\u00e9p\u00e9ter la r\u00e9cup\u00e9ration existent. En mode it\u00e9ratif, on interroge plusieurs fois en affinant \u00e0 partir de ce qui est d\u00e9j\u00e0 obtenu. En mode r\u00e9cursif, on transforme la requ\u00eate \u00e0 chaque tour selon les fragments obtenus. En mode adaptatif, le LLM d\u00e9cide lui-m\u00eame quand et quoi r\u00e9cup\u00e9rer.<\/p>\n\n\n\n\t\t\t\n\t\t\t\tCompare la derni\u00e8re colonne aux deux autres : les boucles it\u00e9rative et r\u00e9cursive sont born\u00e9es par un seuil fixe, alors que l’adaptative confie le moment de la recherche \u00e0 un mod\u00e8le juge.<\/figcaption><\/figure>\n\n\nLe voir tourner<\/h2>\n Passons \u00e0 du code r\u00e9el : un syst\u00e8me agentique volontairement simple, qui choisit un retriever et d\u00e9cide si le contexte trouv\u00e9 r\u00e9pond \u00e0 la question. Il tourne sur un jeu de donn\u00e9es de films stock\u00e9 dans une base de graphe Neo4j, avec trois outils : un gabarit de requ\u00eate par titre de film, un gabarit par acteur, et un text2cypher de repli pour tout le reste.<\/p>\n
Un outil, sa description et son impl\u00e9mentation<\/h3>\n Chaque outil se compose de deux morceaux. Une description au format JSON schema, que le LLM lit pour comprendre \u00e0 quoi sert l’outil et quels param\u00e8tres passer. Et une fonction Python, qui ex\u00e9cute la requ\u00eate Cypher sur la base. Observe la requ\u00eate : elle retrouve un film par son titre, avec son casting et ses r\u00e9alisateurs.<\/p>\n
movie_info_by_title_description = {\n "type": "function",\n "function": {\n "name": "movie_info_by_title",\n "description": "Get information about a movie by providing the title",\n "parameters": {\n "type": "object",\n "properties": {\n "title": {\n "type": "string",\n "description": "The movie title",\n }\n },\n "required": ["title"],\n },\n },\n}\n\ndef movie_info_by_title(title: str):\n """Return movie information by title."""\n query = """\n MATCH (m:Movie)\n WHERE toLower(m.title) CONTAINS $title\n OPTIONAL MATCH (m)<-[:ACTED_IN]-(a:Person)\n OPTIONAL MATCH (m)<-[:DIRECTED]-(d:Person)\n RETURN m AS movie, collect(a.name) AS cast, collect(d.name) AS directors\n """\n records, _, _ = neo4j_driver.execute_query(query, title=title.lower())\n return [record.data() for record in records]\n<\/code><\/pre>\nneo4j_driver<\/code> est la connexion \u00e0 la base de films. La description compte autant que le code : c’est elle qui permet au mod\u00e8le de bien choisir l’outil et ses param\u00e8tres. Le troisi\u00e8me outil, answer_given<\/code>, sert quand la r\u00e9ponse est d\u00e9j\u00e0 dans la conversation, comme \u00ab What’s Dave Smith’s last name ? \u00bb : il \u00e9vite de relancer une recherche inutile.<\/p>\nEx\u00e9cuter l’appel d\u00e9cid\u00e9 par le LLM<\/h3>\n Le mod\u00e8le a choisi un outil. Il faut maintenant faire l’appel \u00e0 sa place. La fonction ci-dessous parcourt la liste des appels demand\u00e9s, retrouve la fonction r\u00e9elle dans le dictionnaire tools<\/code>, d\u00e9code les arguments JSON et ex\u00e9cute.<\/p>\ndef handle_tool_calls(tools: dict[str, any], llm_tool_calls: list[dict[str, any]]):\n output = []\n if llm_tool_calls:\n for tool_call in llm_tool_calls:\n function_to_call = tools[tool_call.function.name]["function"]\n function_args = json.loads(tool_call.function.arguments)\n res = function_to_call(**function_args)\n output.append(res)\n return output\n<\/code><\/pre>\nLe mod\u00e8le peut tout \u00e0 fait d\u00e9cider d’appeler plusieurs outils pour une seule question : d’o\u00f9 la boucle.<\/p>\n
Le routeur, en une fonction<\/h3>\n Pour les questions \u00ab \u00e0 tiroirs \u00bb comme celle des Oscars, on ajoute une \u00e9tape : query_update<\/code> reformule chaque question en s’appuyant sur les r\u00e9ponses d\u00e9j\u00e0 obtenues. La question devient \u00ab Who won the most Oscars ? \u00bb puis \u00ab Is that person alive ? \u00bb, la seconde d\u00e9pendant de la premi\u00e8re. Voici maintenant le routage : le dictionnaire des outils, l’invite qui explique au mod\u00e8le son r\u00f4le, et route_question<\/code> qui l’interroge.<\/p>\ntools = {\n "movie_info_by_title": {\n "description": movie_info_by_title_description,\n "function": movie_info_by_title\n },\n "movies_info_by_actor": {\n "description": movies_info_by_actor_description,\n "function": movies_info_by_actor\n },\n "text2cypher": {\n "description": text2cypher_description,\n "function": text2cypher\n },\n "answer_given": {\n "description": answer_given_description,\n "function": answer_given\n }\n}\n\ntool_picker_prompt = """\n Your job is to choose the right tool needed to respond to the user\nquestion.\n The available tools are provided to you in the request.\n Make sure to pass the right and complete arguments to the chosen tool.\n"""\n\ndef route_question(question: str, tools: dict[str, any], answers:\nlist[dict[str, str]]):\n llm_tool_calls = tool_choice(\n [\n {\n "role": "system",\n "content": tool_picker_prompt,\n },\n *answers,\n {\n "role": "user",\n "content": f"The user question to find a tool to answer: '{question}'",\n },\n ],\n model = "gpt-4o",\n tools=[tool["description"] for tool in tools.values()],\n )\n return handle_tool_calls(tools, llm_tool_calls)\n<\/code><\/pre>\nChaque entr\u00e9e associe un outil \u00e0 sa description et \u00e0 sa fonction. Celle du titre est le bloc vu plus haut ; les trois autres (gabarit par acteur, text2cypher, answer_given<\/code>) sont construites sur le m\u00eame mod\u00e8le : une description JSON puis une fonction. tool_choice<\/code> est la fonction qui envoie ces messages au mod\u00e8le en lui passant les descriptions d’outils. Ajouter un retriever revient \u00e0 ajouter une entr\u00e9e : le syst\u00e8me reste facilement extensible.<\/p>\nLa boucle principale et la critique<\/h3>\n On assemble ensuite ces briques en une fonction qui met \u00e0 jour la question, l’aiguille vers un outil et note le r\u00e9sultat dans l’historique.<\/p>\n
def handle_user_input(input: str, answers: list[dict[str, str]] = []):\n updated_question = query_update(input, answers)\n response = route_question(updated_question, tools, answers)\n answers.append({"role": "assistant", "content": f"For the question: '{updated_question}', we have the\n answer: '{json.dumps(response)}'"})\n return answers\n<\/code><\/pre>\nReste la derni\u00e8re pi\u00e8ce. critique_answers<\/code> est la critique de r\u00e9ponse : elle renvoie une liste de questions compl\u00e9mentaires si la r\u00e9ponse est incompl\u00e8te ou incorrecte. Le code ci-dessous l’appelle une seule fois, puis demande au LLM final de r\u00e9pondre en n’utilisant que ce qui a \u00e9t\u00e9 trouv\u00e9.<\/p>\nmain_prompt = """\n Your job is to help the user with their questions.\n You will receive user questions and information needed to answer the\nquestions\n If the information is missing to answer part of or the whole question,\nyou will say that the information\n is missing. You will only use the information provided to you in the\nprompt to answer the questions.\n You are not allowed to make anything up or use external information.\n"""\n\ndef main(input: str):\n answers = handle_user_input(input)\n critique = critique_answers(input, answers)\n if critique:\n answers = handle_user_input(" ".join(critique), answers)\n llm_response = chat(\n [\n {"role": "system", "content": main_prompt},\n *answers,\n {"role": "user", "content": f"The user question to answer: {input}"},\n ],\n model="gpt-4o",\n )\n return llm_response\n<\/code><\/pre>\nTrois choses \u00e0 retenir de ce code. La critique n’est appliqu\u00e9e qu’une fois : si les r\u00e9ponses restent incompl\u00e8tes apr\u00e8s la seconde passe, elles sont quand m\u00eame renvoy\u00e9es, et le LLM final signale explicitement ce qui manque. C’est ton crit\u00e8re de sortie de boucle. Ensuite, l’invite finale interdit d’inventer : le mod\u00e8le ne doit utiliser que les informations fournies. Enfin, chat<\/code> est la fonction qui appelle le mod\u00e8le de conversation.<\/p>\n\n\u26a0\ufe0f Pi\u00e8ge<\/strong> Si tu supprimes la borne sur la critique, la question sur les Oscars fera tourner ton syst\u00e8me en rond : la r\u00e9ponse n’existe pas dans le jeu de donn\u00e9es, et rien ne le lui dira. La sortie \u00ab l’information manque \u00bb est une fonctionnalit\u00e9, pas un \u00e9chec.<\/p>\n<\/blockquote>\nMesurer que \u00e7a marche<\/h2>\n Un pipeline sophistiqu\u00e9 peut se tromper de plusieurs fa\u00e7ons, alors on \u00e9value chaque \u00e9tape. Il y a le choix de l’outil, la pertinence du contexte r\u00e9cup\u00e9r\u00e9, la qualit\u00e9 de la r\u00e9ponse, puis l’efficacit\u00e9 de l’ensemble.<\/p>\n\n\n\n\t\t\t\n\t\t\t\tChaque case est un point de contr\u00f4le possible. Si la r\u00e9ponse est mauvaise, c’est en remontant les cases une \u00e0 une que tu sauras si le coupable est le routage, la recherche ou la g\u00e9n\u00e9ration.<\/figcaption><\/figure>\n\n\nIsoler ces \u00e9tapes a un avantage : tu peux v\u00e9rifier si le LLM produit la bonne r\u00e9ponse quand on lui donne le bon contexte. Cela s\u00e9pare ses capacit\u00e9s de raisonnement et de synth\u00e8se de celles de la r\u00e9cup\u00e9ration.<\/p>\n
\u00c9valuer les choix d’outils<\/h3>\n Pour v\u00e9rifier le routage, on ex\u00e9cute l’agent de bout en bout et on compare ses appels d’outils aux attentes. Trois m\u00e9triques : le rappel d’outils (a-t-il inclus tous les appels attendus ?), la pr\u00e9cision d’outils (a-t-il \u00e9vit\u00e9 les appels inutiles ?) et l’exactitude des param\u00e8tres (a-t-il pass\u00e9 le bon identifiant de commande ou le bon montant ?).<\/p>\n\n\n\n\t\t\t\n\t\t\t\tLe calcul est simple : un outil attendu, deux appel\u00e9s. Le bon outil est bien dans la liste (rappel 1\/1), mais un appel superflu a \u00e9t\u00e9 fait (pr\u00e9cision 1\/2).<\/figcaption><\/figure>\n\n\n\u00c9valuer le RAG lui-m\u00eame<\/h3>\n C\u00f4t\u00e9 RAG, trois qualit\u00e9s se d\u00e9gagent : la pertinence du contexte (l’information r\u00e9cup\u00e9r\u00e9e est-elle utile \u00e0 la requ\u00eate ?), la fid\u00e9lit\u00e9 de la r\u00e9ponse (s’appuie-t-elle vraiment sur ce qui a \u00e9t\u00e9 r\u00e9cup\u00e9r\u00e9 ?) et la pertinence de la r\u00e9ponse (r\u00e9pond-elle \u00e0 la question pos\u00e9e ?). La r\u00e9cup\u00e9ration et la g\u00e9n\u00e9ration sont \u00e0 \u00e9valuer en priorit\u00e9, car leurs effets sont directement mesurables.<\/p>\n
Il faut aussi un jeu de test. Celui de l’exemple compte 17 cas, et sa composition d\u00e9pend des fonctionnalit\u00e9s de ton agent. Diversifie-le : une salutation, une question hors sujet (la m\u00e9t\u00e9o pour un agent d\u00e9di\u00e9 aux films), des questions d’agr\u00e9gation qui exigent text2cypher, et des cas limites o\u00f9 la r\u00e9ponse manque dans les donn\u00e9es.<\/p>\n
\n\ud83d\udccc \u00c0 retenir<\/strong> Un juge LLM peut biaiser l’\u00e9valuation, surtout s’il est le m\u00eame mod\u00e8le que celui qui g\u00e9n\u00e8re. Utilise plusieurs juges diff\u00e9rents du mod\u00e8le de g\u00e9n\u00e9ration, \u00e9chantillonne leurs jugements et compl\u00e8te par un retour humain.<\/p>\n<\/blockquote>\nFaire grandir le syst\u00e8me, sans se pr\u00e9cipiter<\/h2>\nLa m\u00e9moire : connaissance et histoire<\/h3>\n Deux notions se confondent souvent. La connaissance, mise en \u0153uvre par le RAG, apporte des contenus factuels ou propres \u00e0 un domaine. La m\u00e9moire capture l’histoire de l’agent : \u00e9changes pass\u00e9s, sorties d’outils, mises \u00e0 jour d’\u00e9tat. Elle lui donne de la continuit\u00e9 entre les tours et les sessions.<\/p>\n
La m\u00e9moire de base est une fen\u00eatre de contexte glissante qui perd l’information ancienne. La recherche par mots-cl\u00e9s (BM25) retrouve des termes exacts mais pas les paraphrases. La m\u00e9moire s\u00e9mantique, elle, encode les interactions en vecteurs pour retrouver des contenus proches en sens.<\/p>\n
Ce dernier m\u00e9canisme est celui de la m\u00e9moire d’exp\u00e9rience s\u00e9mantique. \u00c0 chaque entr\u00e9e de l’utilisateur, on cherche dans les interactions pr\u00e9c\u00e9dentes stock\u00e9es. Une partie de la fen\u00eatre de contexte est r\u00e9serv\u00e9e aux meilleures correspondances ; le reste va au message syst\u00e8me, \u00e0 la derni\u00e8re entr\u00e9e et aux interactions r\u00e9centes.<\/p>\n
La r\u00e9flexion : apprendre de ses \u00e9checs<\/h3>\n Reflexion donne \u00e0 l’agent une habitude d’autocritique. Apr\u00e8s chaque tentative rat\u00e9e, il \u00e9crit une br\u00e8ve r\u00e9flexion sur ce qui n’a pas march\u00e9, la range dans une m\u00e9moire, puis la relit avant de r\u00e9essayer. Le mod\u00e8le n’est jamais r\u00e9entra\u00een\u00e9.<\/p>\n\n\n\n\t\t\t\n\t\t\t\tSuis la fl\u00e8che qui remonte : les r\u00e9flexions retournent dans l’invite du prochain essai, et c’est ce retour qui change le comportement.<\/figcaption><\/figure>\n\n\nCet apprentissage n’est pas obligatoire pour concevoir un agent : il exige davantage de conception, d’\u00e9valuation et de supervision, et l’investissement vaut ou non le coup selon l’application.<\/p>\n
Un agent ou plusieurs ?<\/h3>\n La plupart des cas d’usage d\u00e9marrent avec un seul agent, souvent plus rapide et moins cher, et on n’envisage plusieurs agents que quand la complexit\u00e9 d\u00e9passe ce qu’un seul sait faire. Le probl\u00e8me appara\u00eet avec le nombre d’outils : dans l’exemple de cha\u00eene logistique, un agent unique en a seize et sa performance se d\u00e9grade \u00e0 mesure qu’il doit choisir dans un grand ensemble.<\/p>\n
Avant de multiplier les agents, on peut d’abord regrouper les outils (s\u00e9lection hi\u00e9rarchique) ou utiliser une s\u00e9lection s\u00e9mantique via une base vectorielle. Si cela ne suffit pas, on scinde en agents sp\u00e9cialis\u00e9s, au prix d’une surcharge de coordination.<\/p>\n\n\n\n\t\t\t\n\t\t\t\tLes seize outils se r\u00e9partissent en trois sp\u00e9cialistes. Un superviseur route chaque requ\u00eate vers le bon : en resserrant l’ensemble d’outils et l’invite de chacun, on r\u00e9duit les erreurs de s\u00e9lection.<\/figcaption><\/figure>\n\n\nCinq principes guident chaque ajout d’agent : d\u00e9composition, sp\u00e9cialisation, parcimonie, coordination et robustesse. P\u00e8se toujours le co\u00fbt de l’agent suppl\u00e9mentaire : il ajoute de la communication, de la coordination et de la maintenance.<\/p>\n
Pi\u00e8ges et limites<\/h2>\n Le RAG agentique surpasse le RAG standard sur la r\u00e9cup\u00e9ration adaptative, les requ\u00eates complexes, l’int\u00e9gration d’outils et le passage \u00e0 l’\u00e9chelle. Mais trois limites reviennent. La pr\u00e9cision de s\u00e9lection d’outils d\u00e9cline quand un m\u00eame agent doit choisir parmi trop d’options. Aucun agent n’est fiable \u00e0 100 %, et les syst\u00e8mes multiagents cumulent les taux d’erreur. Enfin, une autonomie accrue peut produire des actions non d\u00e9sir\u00e9es si aucun garde-fou explicite n’existe.<\/p>\n
C\u00f4t\u00e9 co\u00fbt, les agents de recherche approfondie combinent plusieurs motifs et payent le prix : nombre d’appels \u00e9lev\u00e9, latence, fragilit\u00e9 vis-\u00e0-vis des sources externes. Les agents ReAct offrent une cha\u00eene de pens\u00e9e qui aide au d\u00e9bogage, mais peuvent augmenter les co\u00fbts d’API et le temps de r\u00e9ponse.<\/p>\n
\n\u26a0\ufe0f Pi\u00e8ge<\/strong> L’injection d’invite n’est pas th\u00e9orique. Le chatbot d’un concessionnaire Chevrolet a \u00e9t\u00e9 manipul\u00e9 pour proposer un v\u00e9hicule de 76 000 dollars pour un dollar. Dans les flux multiagents, l’empoisonnement de m\u00e9moire fait aussi persister des donn\u00e9es contamin\u00e9es d’un agent \u00e0 l’autre.<\/p>\n<\/blockquote>\nLes risques viennent aussi de l’int\u00e9rieur : un agent peut mal interpr\u00e9ter un objectif ambigu, et ses sorties, probabilistes par nature, peuvent inclure des hallucinations. Il faut des limites op\u00e9rationnelles claires, des r\u00e8gles qui valident ses d\u00e9cisions avant ex\u00e9cution, et des strat\u00e9gies de repli : si une API tombe, l’agent bascule sur des donn\u00e9es en cache ou pr\u00e9vient un op\u00e9rateur.<\/p>\n
Enfin, l’humain aussi a ses failles : le biais d’automatisation, o\u00f9 l’on se fie trop aux recommandations de l’agent, et la fatigue d’alerte qui fait rater les avertissements critiques.<\/p>\n
Doser l’autonomie<\/h3>\n Un outil de conception utile : le curseur d’autonomie, qui laisse l’utilisateur ajuster ce que l’agent peut faire seul, du mode manuel au mode assist\u00e9 puis au mode agent. Les pr\u00e9f\u00e9rences varient avec la confiance, la familiarit\u00e9 avec la t\u00e2che, l’enjeu et la charge de travail.<\/p>\n\n\n\n\t\t\t\n\t\t\t\tObserve l’\u00e9tape du milieu : l’agent propose, l’humain valide chaque action. C’est souvent le bon point de d\u00e9part pour un syst\u00e8me qui touche \u00e0 des donn\u00e9es sensibles.<\/figcaption><\/figure>\n\n\nMis en pratique, cela donne un support client \u00e0 trois vitesses : en mode assist\u00e9, l’agent r\u00e9dige des r\u00e9ponses que l’op\u00e9rateur relit avant envoi ; en mode agent, il traite seul les demandes courantes (mot de passe, suivi de commande, FAQ) et n’escalade que les cas sensibles.<\/p>\n
![\"Les](\"https:\/\/www.ranksignal.fr\/wp-content\/uploads\/2026\/09\/b1_ch02_pipeline_indexation-scaled.png\")