Construire des systèmes d'IA : du RAG aux agents

La plupart des équipes commencent par le RAG, découvrent ses limites, puis greffent du fine-tuning. Les deux résolvent la recherche et le raisonnement. Aucun ne résout l’orchestration : décider quand agir, combien d’agents lancer, quand s’arrêter et ce que signifie le consensus. J’ai construit un système de délibération multi-agents (3 500 lignes de Python, 86 hooks, 141 tests) qui gère les trois.

En bref

Le RAG récupère des documents au moment de la requête. Le fine-tuning modifie les poids du modèle avec des données spécialisées. Les deux sont des outils de recherche et de raisonnement. Aucun ne gère l’orchestration : coordonner plusieurs agents, valider le consensus ou décider si une tâche nécessite un seul appel au modèle ou douze. J’ai atteint cette limite en construisant un système de qualité pour blog qui nécessitait du linting parallèle, un scoring de profondeur, une vérification des citations et une évaluation par LLM sur 33 articles. La solution était une couche d’orchestration d’agents avec une délibération déclenchée par la confiance, une gestion du budget de lancement et une validation du consensus en quatre étapes. Cet article couvre la décision RAG vs fine-tuning, puis va là où la plupart des guides s’arrêtent : ce qui se passe quand vous avez besoin d’agents.

Partie 1 : RAG vs Fine-Tuning

Une étude Databricks de 2024 a révélé que 78 % des équipes d’IA en entreprise ont choisi le RAG en premier, mais que 34 % ont ensuite découvert que le fine-tuning aurait été la meilleure approche, perdant en moyenne 3,2 mois de mise en œuvre.¹

La décision n’est pas l’un ou l’autre. Il s’agit de faire correspondre la technique au problème.

Quand le RAG l’emporte

Des connaissances qui changent fréquemment. Le RAG récupère les documents actuels au moment de la requête. Lorsque la base de connaissances est mise à jour quotidiennement (documentation produit, articles de support, déclarations réglementaires), le RAG fournit des informations à jour sans réentraînement.²

Exigences d’attribution des sources. Le RAG cite des documents spécifiques car la recherche produit une liste explicite de sources. Dans les secteurs réglementés (santé, finance, juridique), l’attribution des sources est souvent une exigence de conformité.³

Bases de connaissances volumineuses. Un système RAG portant sur 10 millions de documents performe de manière comparable à un système portant sur 1 million si la qualité de la recherche est constante. Les modèles fine-tunés atteignent des limites de capacité déterminées par la taille du modèle.⁴

Quand le fine-tuning l’emporte

Raisonnement spécifique à un domaine. Le RAG fournit de l’information. Le fine-tuning fournit une capacité. Un modèle fine-tuné sur des conversations de diagnostic médical apprend les schémas de diagnostic différentiel : comment pondérer les symptômes, quand envisager des pathologies rares, comment formuler des questions de suivi. Le RAG peut fournir les connaissances médicales, mais le schéma de raisonnement nécessite un ajustement des poids.⁵

Exigences strictes de format de sortie. Le fine-tuning impose des sorties structurées (JSON, XML, schémas spécifiques) de manière plus fiable que l’ingénierie de prompts. Pour les systèmes où les erreurs de format provoquent des défaillances en aval, le fine-tuning offre une meilleure fiabilité.⁶

Applications critiques en latence. Le RAG ajoute une latence de recherche : encoder la requête, interroger la base de données vectorielle, récupérer les documents, les injecter dans le prompt. Pour les applications avec des objectifs de réponse inférieurs à 200 ms, éliminer la recherche via le fine-tuning peut s’avérer nécessaire.⁷

La matrice de comparaison

L’approche combinée

La plupart des systèmes en production combinent les deux techniques. Fine-tunez le modèle sur les schémas de raisonnement du domaine et les formats de sortie. Utilisez le RAG pour fournir des connaissances actuelles et traçables au moment de la requête. Le modèle fine-tuné sait comment raisonner sur le domaine. Le système RAG fournit sur quoi raisonner.⁸

Partie 2 : Quand vous avez besoin d’agents

Le RAG et le fine-tuning gèrent la recherche et le raisonnement. Aucun ne gère l’orchestration : décider si une tâche nécessite un appel au modèle ou douze, quand lancer des travailleurs en parallèle, comment valider leurs résultats et quand faire remonter à un humain.

J’ai atteint cette limite en construisant mon infrastructure de qualité pour blog. J’avais 33 articles de blog à évaluer, corriger et vérifier. Un seul appel au modèle par article ne suffisait pas. Chaque article nécessitait du linting (12 modules), un scoring de profondeur (5 signaux), une analyse de lisibilité, une vérification des citations et une évaluation par LLM. Les exécuter séquentiellement prenait trop de temps. Les exécuter en parallèle sans coordination produisait des conflits et des résultats incohérents.

La solution n’était ni plus de RAG ni un meilleur fine-tuning. C’était une couche d’orchestration d’agents.

Ce que l’orchestration d’agents exige

Le pipeline ML traditionnel suppose un flux linéaire : données, prétraitement, modèle, évaluation, déploiement.⁹ Les systèmes d’agents sont non linéaires. Un agent peut :

1. Évaluer sa propre confiance et décider qu’il a besoin d’aide
2. Lancer 5 sous-agents en parallèle avec différentes expertises
3. Collecter et classer leurs résultats
4. Détecter quand les agents convergent trop rapidement (pensée de groupe)
5. Valider le consensus par rapport à des seuils de qualité
6. Générer une recommandation finale

Chaque étape nécessite une infrastructure que le RAG et le fine-tuning ne fournissent pas.

Partie 3 : Ce que j’ai construit

L’architecture

Mon système de délibération s’étend sur 3 500 lignes de Python réparties en 12 modules :

Deliberation System
├── confidence.py       Triggers deliberation based on ambiguity/complexity/stakes
├── state_machine.py    Workflow: idle → research → ranking → consensus
├── agents.py           5+ persona templates (Architect, Security, Performance...)
├── context_isolation.py  RLM L0-L3 layers prevent context contamination
├── ranking.py          Stack ranking with weighted consensus calculation
├── spawner.py          Parallel agent spawning via Task API
├── conformity.py       Detects groupthink and premature convergence
├── mailbox.py          Multi-round debate protocol
├── memory.py           Cross-session learning and persona tracking
├── scaling.py          Dynamic agent count based on complexity
├── prd_generator.py    Converts decisions into product requirements
└── observability.py    Session metrics and audit replay

Le système repose sur 86 hooks qui interceptent les opérations à six points du cycle de vie (PreToolUse, PostToolUse, Stop, et trois autres). Chaque lancement d’agent, chaque écriture de fichier, chaque commande git passe par une validation.

Le déclencheur de confiance

Toutes les tâches n’ont pas besoin de cinq agents qui débattent. J’ai construit un algorithme de scoring de confiance qui évalue quatre dimensions :

1. Ambiguïté – La requête a-t-elle plusieurs interprétations valides ? (Correspondances de patterns : « best way », « should I », « compare vs », « pros and cons »)
2. Complexité du domaine – Nécessite-t-elle des connaissances spécialisées ? (Correspondances de patterns : « architecture », « security », « performance », « database schema »)
3. Enjeux – La décision est-elle réversible ? (Correspondances de patterns : « production », « breaking change », « delete », « security vulnerability »)
4. Dépendance au contexte – Nécessite-t-elle une compréhension du système dans son ensemble ?

Le score se décline en trois niveaux :

• ÉLEVÉ (0,85+) : Procéder sans délibération
• MOYEN (0,70-0,84) : Procéder avec une note de confiance enregistrée
• FAIBLE (inférieur à 0,70) : Déclencher une délibération multi-agents complète

Le seuil s’adapte au type de tâche. Les décisions de sécurité exigent un consensus de 85 %. Les modifications de documentation n’en nécessitent que 50 %. Cela évite la sur-ingénierie des tâches simples tout en garantissant que les décisions risquées reçoivent l’examen approprié.

Le problème du budget de lancement

Ma première implémentation utilisait des limites de récursion basées sur la profondeur : un agent à la profondeur 0 lance la profondeur 1, qui lance la profondeur 2, bloqué à la profondeur 3. Cela a échoué immédiatement. Les agents de délibération doivent s’exécuter en parallèle, pas en série. Cinq agents à la profondeur 1, ce n’est pas de la récursion profonde. C’est de la collaboration large.

La correction : un modèle de budget de lancement. L’agent racine reçoit un budget (12 agents maximum). Il dépense ce budget en lançant des travailleurs en parallèle. Les travailleurs héritent du budget restant mais ne peuvent pas le dépasser. Cela empêche les chaînes incontrôlées tout en permettant l’exécution parallèle que la délibération exige.

Le test en conditions réelles est survenu lorsque j’ai lancé 10 agents de relecture sur des articles de blog traduits. Le garde-fou de récursion a bloqué les agents 4 à 10 parce qu’il comptait les lancements comme des incréments de profondeur. Après le passage au modèle de budget, les 10 se sont exécutés avec succès. La profondeur n’a jamais dépassé 1. La largeur s’est étendue pour correspondre à la tâche.¹⁰

Validation du consensus

Une fois les agents terminés, un hook post-délibération exécute quatre vérifications :

1. Maturité de phase – La délibération a-t-elle progressé au-delà de la recherche jusqu’au classement ?
2. Quorum d’agents – Au moins 2 agents ont-ils terminé ? (Configurable par type de tâche)
3. Seuil de consensus – L’accord atteint-il le niveau requis ? (70 % de base, 85 % pour la sécurité)
4. Documentation des dissidences – Si les agents sont en désaccord, les préoccupations sont-elles enregistrées ?

La vérification 4 a été l’insight que je n’attendais pas. Les premières exécutions produisaient un « consensus » où les agents se contentaient d’approuver la première réponse. Le détecteur de conformité signale désormais la convergence prématurée : si tous les agents sont d’accord dès le premier tour avec des scores de similarité élevés, le système force un second tour d’analyse contradictoire.

Ce que j’ai appris à mes dépens

Les écritures de fichiers atomiques comptent. Plusieurs agents écrivant simultanément dans le même fichier d’état corrompaient le JSON. La correction : écrire dans des fichiers .tmp, puis déplacer avec mv de manière atomique. Le système d’exploitation garantit que mv est atomique sur le même système de fichiers. Ce changement d’une seule ligne a éliminé toute une catégorie de conditions de concurrence.

L’isolation du contexte prévient la pensée de groupe. Chaque agent reçoit un contexte indépendant via quatre couches (L0 : connaissances de base, L1 : spécifiques à la tâche, L2 : spécifiques au persona, L3 : spécifiques au tour). Sans isolation, les agents convergent vers la première réponse plausible au lieu d’explorer l’espace des solutions. Avec isolation, l’agent Sécurité et l’agent Performance arrivent à des conclusions véritablement différentes parce qu’ils partent d’hypothèses différentes.

Tester l’infrastructure d’agents est plus difficile que tester le code applicatif. Le système comporte 141 tests : 48 tests d’intégration bash pour le comportement des hooks, 81 tests unitaires Python pour les modules de bibliothèque et 12 simulations de pipeline de bout en bout. Chaque histoire d’échec dans ma mémoire de projet (blocage du budget de lancement, faux positifs de détection de guillemets, fichiers de plan de blog accidentellement servis comme articles) est devenue un cas de test après la correction. Les bugs d’agents sont plus difficiles à reproduire que les bugs applicatifs car ils dépendent du timing, de l’ordonnancement et de l’état concurrent.

La répartition humain-agent

Le schéma : les humains prennent en charge les décisions qui nécessitent un contexte organisationnel, un jugement éthique ou une orientation stratégique. Les agents prennent en charge les décisions qui nécessitent une recherche computationnelle dans de vastes espaces de possibilités.¹¹ J’ai approfondi cette répartition dans mon analyse d’architecture d’agents.

L’ingénieur ML agentique ne code pas les pipelines à la main. L’ingénieur ML agentique définit les objectifs, les contraintes et les critères d’évaluation. Les agents gèrent la boucle d’implémentation : proposer, exécuter, évaluer, itérer. Le rôle humain passe de constructeur à architecte : définir les garde-fous, examiner les résultats et prendre les décisions de jugement qui nécessitent le contexte métier dont les agents manquent.¹²

Points clés à retenir

Pour les ingénieurs qui débutent avec les systèmes d’IA : - Commencez par le RAG pour tout cas d’usage impliquant des connaissances qui changent fréquemment ou des exigences d’attribution des sources ; le RAG fournit une base fonctionnelle en quelques jours, tandis que le fine-tuning nécessite des semaines de préparation des données - Combinez RAG et fine-tuning quand l’application a besoin à la fois de raisonnement spécialisé ET de connaissances actuelles - Si vous avez besoin de plus d’un appel au modèle par tâche, vous avez besoin d’orchestration d’agents, et c’est un problème d’ingénierie différent du RAG ou du fine-tuning

Pour les équipes qui construisent des systèmes d’agents : - Construisez le scoring de confiance avant de construire les agents ; la plupart des tâches n’ont pas besoin de délibération, et le système qui sait quand utiliser les agents a plus de valeur que les agents eux-mêmes - Utilisez des budgets de lancement, pas des limites de profondeur, pour les architectures d’agents parallèles ; les limites de profondeur bloquent les schémas de collaboration large que la délibération d’agents exige - Testez la qualité du consensus, pas seulement son existence ; un accord prématuré est pire que l’absence d’accord car il crée une fausse confiance

Références