RAG, agent ou workflow : trois architectures, trois usages

Un cadre de décision concret pour ne pas confondre les outils.

Une confusion qui coûte cher

Trois patterns dominent aujourd'hui les discussions d'architecture IA en entreprise : le workflow déterministe, le RAG (Retrieval-Augmented Generation), et l'agent. Ils répondent à des problèmes différents. Mais comme les vocabulaires se chevauchent et que les frameworks marketing aiment les vendre ensemble, la confusion est fréquente.

Cette confusion coûte cher. Une équipe qui a besoin d'un workflow et part sur un agent paie en complexité opérationnelle, en latence, en coût LLM, et en variance de comportement. Une équipe qui a besoin d'un agent et part sur un RAG butte sur des cas que la simple recherche-puis-réponse ne sait pas résoudre. Une équipe qui a besoin d'un RAG et part sur un workflow se retrouve à coder en dur ce qu'elle aurait pu obtenir par recherche sémantique.

Cet article propose un cadre de décision. Il décrit ce que chaque pattern fait bien, ce qu'il ne fait pas, et donne un tableau d'arbitrage pour choisir entre les trois.

Trois patterns, trois objectifs

Workflow déterministe. Une suite d'étapes connues, avec une logique de transition explicite. Chaque étape produit un résultat reproductible à partir d'une entrée. Si l'étape échoue, la transition d'erreur est définie. Le workflow est lisible : une nouvelle personne qui rejoint l'équipe peut, en lisant le code, comprendre exactement ce qui se passe pour chaque cas. Pas de magie, pas de variabilité de comportement.

Exemple Synergix : le pipeline d'OCR sur des factures normalisées d'un fournisseur connu. Le format est stable, l'enchaînement est connu (capture, OCR PyMuPDF, extraction par regex sur les zones documentées, validation arithmétique, écriture). Le workflow tourne, on le surveille avec des métriques techniques classiques (latence par étape, taux d'échec service), on le calibre une fois, il fonctionne.

RAG (Retrieval-Augmented Generation). Un pattern en deux temps. Premier temps : récupérer des documents pertinents dans un corpus connu, à partir d'une question (recherche sémantique, recherche par mot-clé, ou hybride). Deuxième temps : passer ces documents à un LLM pour qu'il génère une réponse en s'appuyant explicitement dessus. Le LLM ne sait pas tout : il sait synthétiser ce qui lui est passé dans le prompt, à partir d'une base que l'application a sélectionnée.

Exemple Synergix : la recherche dans la base de connaissance interne. Un comptable demande « quelle est notre politique sur les frais de représentation pour les SA cotées ». Le RAG récupère les trois documents internes les plus pertinents, les passe au LLM avec la question, et obtient une réponse synthétique sourcée. Le LLM ne connaît pas la politique. La base de connaissance la connaît. Le LLM met en forme.

Agent. Un pattern où le système reçoit un objectif (pas une instruction) et dispose de capacités qu'il invoque selon son évaluation de la situation. Il observe les résultats, ajuste sa stratégie, et décide quand il a terminé ou quand il doit escalader. La trajectoire n'est pas connue à l'avance : c'est l'agent qui la construit.

Exemple Synergix : l'agent documentaire face à une facture inhabituelle. Le scan est de mauvaise qualité, le fournisseur est nouveau, le format ne correspond à aucun pattern connu. Un workflow se serait arrêté après l'OCR raté. Un RAG n'aurait pas su quoi faire de la question. L'agent, lui, observe le résultat de la première extraction, formule une hypothèse, croise avec une recherche dans Qdrant des documents similaires, calcule un score composite, et décide soit de proposer une extraction enrichie, soit d'escalader avec un dossier préparé.

Tableau d'arbitrage

Le tableau ci-dessous synthétise les conditions où chaque pattern est le bon choix.

Une lecture utile du tableau : si la variabilité d'entrée est faible et que les étapes sont connues, le workflow gagne sur tous les autres critères. Si les étapes sont connues mais que la question varie, c'est le territoire du RAG. Si même les étapes ne sont pas prédéterminées, l'agent devient nécessaire.

Coûts respectifs : l'arithmétique honnête

L'arbitrage ne peut pas se faire sans regarder les coûts opérationnels.

Workflow. Coût marginal : essentiellement le coût d'exécution des services internes (calcul, stockage, base de données). Pas de LLM dans le chemin critique. Latence cible : sous la seconde pour la majorité des étapes. Coût d'observabilité : standard (Prometheus, Loki). Coût d'évolution : faible si bien testé, élevé si la logique métier change radicalement (refonte du workflow).

RAG. Coût marginal : un appel LLM par requête, plus le coût de la recherche vectorielle (négligeable à notre échelle). Latence : entre une et trois secondes typiquement. Coût d'observabilité : il faut tracer les retrievals (quels documents ont été passés au LLM) en plus des appels LLM. Coût d'évolution : faible côté code, mais le corpus doit être maintenu (ingestion, chunking, mise à jour).

Agent. Coût marginal : plusieurs appels LLM par tâche (un par étape de raisonnement, plus chaque invocation de capacité qui en demande), parfois cinq à quinze appels pour une tâche complexe. Latence : plusieurs secondes à plusieurs dizaines selon la complexité. Coût d'observabilité : le plus exigeant des trois, parce que la trajectoire n'est pas reproductible et qu'il faut tracer chaque décision. Coût d'évolution : faible au sens du code (les capacités évoluent indépendamment), mais élevé au sens du tuning (on ajuste les prompts, les seuils, les politiques d'escalade en continu).

L'arithmétique conduit à un principe directeur : on ne met un agent que là où le besoin de jugement le justifie. Tout cas qu'on peut traiter par workflow se traite par workflow. Tout cas qui nécessite de la synthèse sur un corpus se traite par RAG. L'agent intervient pour ce que les deux premiers ne savent pas faire, et il y intervient parce que sa flexibilité justifie son coût.

Pièges typiques : trois confusions courantes

Piège 1 : l'agent qui aurait dû être un workflow. C'est le piège le plus fréquent dans les équipes qui découvrent les frameworks d'agents. Une tâche déterministe (extraction de données structurées d'un PDF normalisé) est confiée à un agent au prétexte que « c'est plus moderne ». Résultat : variance de comportement entre invocations, coût LLM multiplié, latence multipliée, complexité de débogage augmentée. Le test pour détecter le piège est simple : si la même entrée doit produire la même sortie, et que les étapes sont connues, ce n'est pas un agent qu'il faut. C'est un workflow.

Piège 2 : le RAG qui aurait dû être un agent. Inverse du précédent. Une tâche qui demande un raisonnement multi-étape (« est-ce que cette écriture est cohérente avec l'historique de ce client, et si non, qu'est-ce qui l'expliquerait ») est traitée par un RAG. Le RAG récupère des documents et passe au LLM, qui produit une réponse plausible mais sans la profondeur d'analyse que la question demande. Le test : si la réponse demande de combiner des sources hétérogènes, de formuler des hypothèses intermédiaires, ou d'invoquer des capacités spécifiques (calculs, vérifications croisées), le RAG seul ne suffit pas.

Piège 3 : le workflow rigide qui aurait dû être un agent. Cas plus rare mais coûteux. Une tâche qui ressemble à un pipeline (réception, extraction, validation, écriture) est codée en workflow rigide, et chaque cas atypique génère une exception qu'un humain doit traiter. À volume modéré, c'est tenable. À volume élevé, le coût humain explose. Le test : si plus de 15 % des invocations finissent en exception manuelle, et que les exceptions ont une variété qui dépasse la capacité d'un règle déterministe à les classifier, l'agent devient pertinent pour absorber ce flux.

Cohabitation : les trois patterns dans un même système

Dans la stack Synergix, les trois patterns coexistent. Aucun ne suffirait seul.

Le pipeline de traitement des factures repose sur un workflow déterministe pour la majorité du volume (factures normalisées de fournisseurs connus, scan de qualité). Sur ce volume, le workflow tourne à coût marginal très bas. Pour les cas atypiques (15 à 20 % du volume selon les périodes), un agent prend le relais. L'agent peut, au cours de sa trajectoire, invoquer un RAG pour interroger la base interne (« quelle est la politique de classement comptable pour ce type de prestation ? »).

Le moteur conversationnel des comptables est un RAG par construction. Il répond à des questions sur la base de connaissance interne. Mais quand la question dépasse ce qu'une simple récupération-puis-synthèse peut résoudre (par exemple, « est-ce qu'on a un précédent client similaire et qu'est-ce qu'on a fait à l'époque »), le RAG escalade vers un agent qui a la capacité de faire des recherches plus structurées et de croiser plusieurs sources.

Le pipeline d'évaluation continue des agents (article #9 dédié) est un workflow strict. Métriques calculées à intervalle régulier, alertes déclenchées par seuils, rien de variable. C'est une garantie d'auditabilité : les évaluations ne dépendent pas du jugement instantané d'un LLM.

Comment choisir, en pratique

La question pratique se pose souvent comme suit. « On a un nouveau cas d'usage, on veut le traiter par IA, on part sur quoi ? »

Trois questions à se poser dans l'ordre.

1. Est-ce que la trajectoire est connue à l'avance ? Si oui, et que les étapes sont stables, partir sur un workflow. Quitte à le rendre plus modulaire si les étapes changent souvent.

2. Si non, est-ce que le résultat attendu est une synthèse à partir d'un corpus identifiable ? Si oui, partir sur un RAG. Identifier les sources, les indexer, mesurer la qualité du retrieval indépendamment de la qualité de la génération.

3. Si non, est-ce qu'on a besoin de jugement, de combinaison de sources hétérogènes, ou d'invocation de capacités spécifiques selon le contexte ? Si oui, partir sur un agent. Mais avec discipline : architecture explicite des capacités, journalisation systématique, politique d'escalade humaine claire.

Cette séquence force à éprouver les hypothèses simples avant de complexifier. La majorité des cas d'usage en fiduciaire trouvent une réponse satisfaisante dans les deux premières questions.

L'erreur la plus chère : sur-architecter

Si nous devions retenir une seule erreur à éviter, ce serait celle-ci. L'engouement pour les frameworks d'agents pousse à transformer en agent ce qui n'avait pas besoin de l'être. Le coût ne se voit pas immédiatement (les agents marchent souvent en démo), mais il se révèle en production : variance de comportement, coût LLM, latence, dette opérationnelle.

La discipline contre cette erreur tient en une phrase : on ne paie pas la flexibilité d'un agent quand un workflow ferait l'affaire. Cette phrase, simple à formuler, demande une discipline d'équipe pour être tenue.

L'article suivant (#8) suit un document de bout en bout dans notre pipeline et montre comment workflow, RAG et agent y interviennent ensemble.