IA agentique, RAG ou workflows : comment choisir

Quelle différence entre IA agentique, RAG et workflows ?

Ils répondent à trois questions différentes. Un workflow demande qui décide des étapes, et la réponse est : des personnes, à l’avance. Le RAG demande d’où viennent les connaissances, et la réponse est : d’une étape de recherche dans vos documents. Un agent demande quoi faire ensuite, et la réponse est : un modèle qui décide à l’exécution.

La confusion vient surtout de ce qu’on les lit comme les barreaux d’une échelle de maturité. Ce n’est pas le cas. Ce sont des outils avec des modes de défaillance différents, et le meilleur choix est généralement le moins autonome qui fonctionne.

Comment définir précisément chaque approche ?

Des définitions floues produisent des architectures floues. Voici celles que j’utilise avec les équipes. L’axe qui compte est l’autonomie : qui choisit le chemin.

• Workflow fixe : une suite d’étapes écrite par des personnes. Un modèle peut être appelé dans une étape, pour classer ou rédiger, mais il ne choisit jamais l’étape suivante. Le comportement est prévisible et testable étape par étape.
• Assistant RAG : un pipeline qui récupère des passages dans un corpus de documents et demande à un modèle de répondre à partir d’eux, idéalement avec des citations. Le chemin reste fixe. Ce qui varie, c’est la connaissance, d’où son intérêt pour les contenus qui changent.
• Agent unique : un modèle qui travaille en boucle, décide quel outil appeler, lit le résultat et décide à nouveau jusqu’à estimer la tâche terminée. Le chemin est choisi à l’exécution.
• Système multi-agents : plusieurs agents aux rôles spécialisés, coordonnés par un orchestrateur qui planifie, délègue et contrôle le travail. Il ajoute de la capacité, et il ajoute des défaillances de coordination.

Comment choisir entre workflow, RAG et agent ?

La recherche documentaire est souvent un composant plutôt qu’un concurrent : un agent peut appeler un outil de recherche, et un workflow peut contenir une étape RAG. Le tableau ci-dessous est ma règle empirique, pas une norme. Lisez chaque ligne comme une question à se poser avant de choisir une architecture.

Quelles règles appliquer pour bien démarrer ?

Ces règles découlent d’un principe : chaque palier d’autonomie apporte de la souplesse et coûte de la prévisibilité. Ne payez ce prix que si le problème l’exige.

• Commencez par un workflow si vous pouvez dessiner les étapes sur un tableau blanc. C’est le cas de la plupart des processus métier.
• Ajoutez du RAG quand l’ingrédient manquant est la connaissance, pas le raisonnement. Améliorez la qualité de la recherche avant de toucher au modèle.
• Passez à un agent unique seulement quand le nombre de branches rend le workflow impossible à maintenir, ou quand l’étape suivante dépend vraiment du résultat de la précédente.
• N’allez vers le multi-agents que lorsque le contexte ou les outils d’un seul agent deviennent trop vastes à gouverner, et que vous pouvez évaluer chaque spécialiste séparément.
• Placez une validation humaine avant toute étape qui écrit dans un système externe, quelle que soit l’approche.
• N’augmentez jamais l’autonomie sans une évaluation montrant que la nouvelle version fait mieux que la précédente sur les mêmes scénarios.

Que m’a appris la plateforme DILA sur le RAG et les workflows agentiques ?

Sur la plateforme d’IA souveraine à laquelle j’ai contribué pour la DILA, les services du Premier ministre, le problème de départ était la duplication. Chaque application d’IA devait reconstruire l’ingestion de documents, les embeddings, la recherche, l’orchestration, la sécurité, l’évaluation et l’observabilité. Nous sommes passés d’applications construites une à une à des applications RAG assemblées à partir de composants réutilisables et gouvernés.

Le prototypage de workflows agentiques s’est ensuite appuyé sur les mêmes fondations. Les applications agentiques pouvaient s’appuyer sur des schémas d’orchestration et des intégrations d’outils existants au lieu de repartir de zéro, et la page du cas client mentionne une réduction de 50 % du temps de mise en œuvre pour les prototyper.

La leçon que j’en tire est architecturale. L’agent n’était pas une pile séparée. Il reposait sur les mêmes composants gouvernés que les applications RAG, si bien que l’autonomie était un ajout sur une plateforme, et non un nouveau projet avec sa propre histoire de sécurité et d’évaluation.

Quand un système multi-agents se justifie-t-il ? L’exemple de NOVA

NOVA est un système multi-agents, et je l’ai conçu ainsi pour une raison. Sa mission est de transformer une intention en plan et en livrable modifiable, et le chemin diffère réellement d’une demande à l’autre. Un orchestrateur cadre la demande, délègue à des agents spécialisés en produit, projet, design et ingénierie, et un agent de validation contrôle chaque livrable. Le contexte vient d’ORBIT avec les droits de l’utilisateur, et FORGE évalue les exécutions.

Ma lecture personnelle est que l’autonomie se concentre là où le chemin varie. Les parties qui l’entourent, comme les compétences versionnées, la recherche gouvernée et les livrables structurés, ressemblent beaucoup plus à des workflows et à du RAG.

Un mot de prudence sur le statut. NOVA, ORBIT et FORGE sont des dépôts publics en bêta, et je décris leur conception, pas une garantie de production. Ce que je peux affirmer comme un fait, c’est que NOVA Suite est utilisé par 800 collaborateurs chez Devoteam.

Comment gagner de l’autonomie grâce à l’évaluation ?

L’évaluation est la porte entre les paliers. Avant de passer d’une approche à la suivante, définissez des scénarios, notez la version actuelle et exigez que le candidat plus autonome la batte sur les mêmes cas.

Pour le RAG, la DILA a utilisé quatre mesures : fidélité (faithfulness), pertinence des réponses, précision du contexte et rappel du contexte. Pour les agents, le README de FORGE décrit des scénarios, des règles déterministes, des juges LLM, une évaluation humaine et des expériences de référence contre candidat. Le principe est identique : un score doit remonter à un critère et à une étape.

Incluez les cas où le système doit refuser ou escalader, pas seulement ceux où il doit réussir. Et mesurez le coût, car l’autonomie tend à multiplier les appels au modèle. À la DILA, l’optimisation des pipelines et la réutilisation ont réduit de 30 % le coût par requête d’IA.

Qu’ai-je mesuré et observé ?

Ces chiffres viennent de l’étude de cas DILA et concernent l’approche de plateforme : composants réutilisables, évaluation et orchestration gouvernée. Ils ne comparent pas workflows, RAG et agents, et je n’ai pas de comparaison de ce type à proposer.