RAG, boucles, graphes : quatre décisions, pas quatre produits

Publié le 22 juillet 2026 · mis à jour le 16 août 2026

Un fournisseur propose « un assistant qui répond à partir de vos documents ». Un autre parle de RAG. Un troisième vend un « multi-agent graph ». Un quatrième n’écrit plus de requêtes, mais des boucles. Tous décrivent un travail réel, et rien ne permet de les comparer : leurs mots ne situent pas les décisions au même niveau. Ils désignent quatre décisions prises l’une après l’autre. Les nommer suffit à rendre les offres comparables.

Quatre couches pratiques, pas une norme universelle

J’utilise cette grille pour comparer les offres. D’autres équipes rangent la mémoire, les outils ou la coordination des étapes sous d’autres étiquettes ; ce qui compte, c’est de rendre les responsabilités explicites.

Le contexte : ce que le modèle a devant lui pour répondre. RAG en fait partie, l’ingénierie de contexte aussi
La boucle : ce que le système fait après la réponse. Vérifier, corriger, réessayer, et recommencer jusqu’à ce qu’une condition annoncée arrête le cycle
Le graphe : qui a le droit d’exécuter ensuite. Séquence, parallèle, passage obligatoire par un humain
L’infrastructure : tout le reste. Outils, autorisations, mémoire, journaux, reprise après incident

Le reste de l’article examine ces quatre décisions une par une.

RAG : le terme le plus galvaudé, une difficulté encore réelle

Le principe tient en deux étapes : repérer les passages utiles dans vos documents, puis les transmettre au modèle avec la question. La démonstration sur la page IA appliquée fonctionne ainsi, et affiche les extraits lus avant la réponse.

La recherche documentaire a progressé, sans cesser d’être un problème : extraction, découpage, métadonnées, construction des requêtes, classement, autorisations et évaluation pèsent tous sur la qualité. Une fois cette base en place, la difficulté devient souvent administrative : vos documents vivent dans une boîte mail, dans un système de gestion documentaire, dans le logiciel de comptabilité, et chaque emplacement a ses propres autorisations. Qui voit quoi, quelle version prime, que devient une réponse si quelqu’un corrige la source le lendemain ? Un assistant qui répond à partir d’un document RH n’a pas un problème de modèle. Il a un problème d’autorisations.

La boucle : sur des preuves, jamais sur la confiance

L’auteur ne doit pas être le seul juge

Un modèle qui relit sa propre réponse l’améliore parfois, mais il hérite des angles morts de la première version. Pour les sorties critiques, séparez la production de l’évaluation quand vous le pouvez, puis ajoutez des vérifications déterministes ou un contrôle humain. Un second modèle ne garantit pas la vérité pour autant.

Le juge a besoin d’une référence incontestable

Pour du code, ce sont les tests. Pour un texte, c’est le document d’origine. Si personne ne sait désigner cette référence, le système n’a aucune vérification, quelle que soit l’assurance affichée.

La règle pratique est donc simple : ne bouclez pas sur la confiance, bouclez sur des preuves. « L’agent croit avoir terminé » n’est pas une condition d’arrêt ; « les montants correspondent au relevé » en est une. Et cette règle vit dans le code, pas dans la requête : un modèle qui a déjà échoué trois fois tient volontiers sa quatrième version pour suffisante.

Quand une exécution durable devient utile

Trois besoins justifient un outil qui mémorise et coordonne les étapes d’une tâche, que le métier appelle selon les cas moteur de workflow, machine à états ou graphe d’exécution :

Survivre à un arrêt : le serveur redémarre et le travail reprend là où il s’était interrompu, au lieu de repayer chaque appel
Attendre une approbation en cours de route : le moteur suspend l’exécution, attend trois jours une signature, puis reprend
Reconstituer une décision après coup : répondre à « pourquoi cette facture a-t-elle été rejetée le 12 mars ? » demande l’état du système à ce moment-là, pas seulement la réponse finale

L’inverse compte tout autant : cette coordination formelle ne mérite son coût que lorsque les étapes et leurs relations reviennent à l’identique. Tant que vous ne maîtrisez pas le processus, une simple boucle explorera mieux qu’un plan prématuré. Boucles, machines à états et graphes cohabitent d’ailleurs très bien dans un même système.

Le graphe : de la largeur, pas du jugement

Un graphe est le plan du travail, dessiné : les tâches, et qui attend quoi. Deux mots suffisent. Un nœud est une tâche bornée, avec quelque chose qui entre et quelque chose qui sort. Une flèche entre deux nœuds signifie que la seconde tâche a besoin de ce que la première a produit, donc qu’elle attend. Les nœuds font le travail, les flèches portent les résultats. La règle budgétaire tient en une phrase : un graphe vous donne de la largeur, pas du jugement. Quand chaque étape a besoin du résultat de la précédente, les lancer en parallèle n’ajoute que des appels. Quand le travail éclate en tâches qui ne lisent jamais les résultats les unes des autres, le parallèle paie tout de suite.

Le test prend une soirée : dessinez votre chaîne, et à chaque « et ensuite », demandez-vous si l’étape suivante a vraiment besoin du résultat de la précédente. Beaucoup de chaînes révèlent alors des flèches inutiles.

Ce qui rend une tâche utilisable comme nœud, c’est un contrat : une seule tâche bornée, une entrée définie, une forme de sortie définie. Un nœud dont la sortie est de la prose libre reste un nœud que seul un humain peut lire, et la tâche suivante en est réduite à deviner où commence la réponse. Une forme de sortie fixée permet à un nœud d’en consommer un autre sans personne au milieu.

La largeur a un prix, et le chiffre public le plus clair vient de Bun. Son créateur a porté 535 496 lignes de Zig vers Rust en onze jours avec une cinquantaine de flux coordonnés, jusqu’à soixante-quatre agents simultanés, pour environ 165 000 dollars d’usage de modèle, chaque modification passant deux relectures indépendantes avant d’être conservée. L’objection est arrivée avec le résultat : le créateur de Zig a dénoncé du code produit à la chaîne et jamais relu. Les deux moitiés appartiennent à la même phrase. Une flotte atteint une échelle qu’aucun contexte unique ne tient, et elle dépense le budget en arrière-plan, que la tâche le mérite ou non.

Les ancrages dont un graphe a besoin

Un graphe achevé est l’endroit où l’échec de la boucle revient, mieux habillé. Des vérificateurs appariés, des nœuds d’audit, des méta-nœuds qui règlent les autres nœuds, et chacun lit un rapport produit par le système qui a produit les chiffres. L’audit confirme les chiffres de la finance, les deux sortant du même endroit. Tout concorde, et rien n’est vérifié.

Cette version échoue plus tard qu’une boucle unique, coûte davantage en chemin, et affiche plus de voyants verts pendant la descente.

La forme du graphe n’apporte aucune vérité par elle-même. Un graphe réclame des ancrages, c’est-à-dire des nœuds que personne ne peut discuter : un test qui a réellement tourné plutôt qu’un test censé passer, de l’argent arrivé sur le compte, un client qui a renouvelé.

Certaines règles doivent aussi rester gelées, en particulier celles qu’un optimiseur serait tenté d’affaiblir, celles-là mêmes qu’il pliera pour gagner. Un graphe n’est honnête que par les parties qui refusent de bouger.

Deux graphes différents sous le même mot

Le graphe d’exécution ci-dessus décrit le travail. Le graphe de connaissances décrit vos données : chaque information devient une relation explicite entre deux entités, « ce contrat lie ce fournisseur à cette commune ». GraphRAG désigne cette famille, et l’implémentation de Microsoft en est la référence ouverte.

La différence apparaît dans la forme des questions. La recherche vectorielle excelle à trouver ce qui a été écrit sur un sujet. La recherche hybride, les métadonnées et l’agrégation répondent elles aussi à certaines questions qui traversent plusieurs documents.

Le graphe devient pertinent quand les relations doivent rester explicites et récurrentes, donc interrogeables : quels contrats un fournisseur a-t-il remportés en cinq ans, et qui siégeait à la commission à chaque fois ? La réponse traverse plusieurs sources. Un graphe de connaissances la matérialise, au prix de l’extraction, de la normalisation et de la conception du schéma, sans compter la traçabilité et la maintenance.

L’article LLM-assisted Knowledge Graph Engineering relate des expériences qui ont utilisé ChatGPT pour aider à construire des graphes de connaissances ; il n’établit pas le coût permanent de chaque système de graphe. Comparez le coût total et la qualité des réponses sur vos vraies questions. Il n’existe aucun ratio universel de cent à un entre la recherche vectorielle et un graphe.

Où va votre signature

Reste la seule décision que vous ne pouvez pas déléguer. L’approbation humaine précède l’irréversible : un envoi, un paiement, une écriture comptable. Placez-la partout et vous devenez le goulot d’étranglement ; ne la placez nulle part et plus personne ne surveille. Pour une commune, la formule existe déjà : c’est l’étape de la méthode HERMES, le moment où l’autorité qui paie autorise ou non la suite.

Le vocabulaire changera encore avant la fin de l’année ; les quatre décisions resteront. Les pièces qui font vraiment le travail sont les moins spectaculaires, et elles ne tombent jamais en panne bruyamment. Elles échouent le jour où une erreur passe en silence, quarante fois de suite.

Une grille de décision minimale

Pour chaque cas d’usage, notez la forme de la question, les preuves qu’il vous faut, le coût d’une erreur, la fréquence des relations, la latence, le volume, les autorisations, la reprise après incident et l’observabilité. Partez de l’architecture la plus simple qui atteint le seuil mesuré. N’ajoutez une boucle, un état durable ou un graphe que lorsque le test montre ce qu’ils apportent.

Le statut de cette taxonomie

J’ai revu les quatre couches le 14 août 2026 et ajouté les chiffres de Bun le 26 août 2026. Ces couches forment une grille de lecture, pas une norme. Mesurez le coût et les performances sur le corpus réel, les vraies questions et les vraies autorisations.