Vous avez lu le catalogue, et la tentation est réelle : construire dès le premier jour l’orchestrateur multi-agents avec mémoire et guardrails. Résistez. Chaque pattern de ce catalogue répond à un problème qu’on peut observer — et les systèmes qui tiennent en production y sont arrivés en grimpant une marche à la fois.
L’analogie
On n’achète pas le camion avant le vélo. Une entreprise de livraison démarre avec un vélo ; quand les commandes dépassent démontrablement le vélo, elle achète un scooter ; le camion arrive quand le scooter déborde. Chaque montée en gamme répond à une limite mesurée — jamais à la peur d’une limite.
Le principe
Commencez à la marche 1. Ne grimpez que quand la marche actuelle échoue de façon mesurable.
- Un seul appel de LLM augmenté — un bon prompt, vos données dans le contexte, les quelques outils qui comptent. Ça résout plus qu’on ne le croit.
- Un workflow — la route est connue ? Câblez-la : chaînage, routage, parallélisation.
- Une boucle d’agent — seulement quand le chemin ne peut vraiment pas être scénarisé.
- Le multi-agents — seulement quand un seul contexte ne peut prouvablement pas contenir la tâche.
Et quel pattern, quand on grimpe ? Trois questions :
flowchart TB
Q1{"les étapes sont-elles connues d'avance ?"} -->|oui| Q2{"dépendent-elles les unes des autres ?"}
Q1 -->|non| Q3{"existe-t-il un retour vérifiable — tests, compilateur, API ?"}
Q2 -->|"oui, en séquence"| A["chaînage de prompts"]
Q2 -->|"non, indépendantes"| B["parallélisation"]
Q2 -->|"ça dépend de l'entrée"| C["routage ou orchestrateur-ouvriers"]
Q3 -->|oui| D["boucle d'agent"]
Q3 -->|non| E["restez au workflow — un agent qui ne peut pas se vérifier dérive"]
Un exemple concret
Une équipe qui automatise les réponses aux tickets de support :
semaine 1 → un appel augmenté : prompt + RAG sur la doc
→ traite déjà 60 % des tickets. On livre.
semaine 4 → mesure : les tickets facturation échouent souvent
→ ajout du routage : la facturation a son parcours. 75 %.
semaine 9 → les tickets complexes exigent consultation de compte + actions
→ boucle d'agent, sous validation humaine. 85 %.
Trois marches, chacune justifiée par un chiffre — et à chaque étape, un système qui fonctionne en production.
La checklist de départ
- Choisissez le modèle en second. Définissez d’abord la tâche, les données et le critère de succès ; puis prenez le modèle le moins cher qui passe.
- Écrivez le prompt système comme des instructions : rôle, règles, ton, format de sortie — court et testable.
- Le moins d’outils possible. Chaque schéma d’outil coûte du contexte à chaque appel.
- Une vérification dès le premier jour : un contrôle de format, un test, une relecture d’échantillon — on n’améliore pas ce qu’on ne mesure pas (voir évaluer & observer).
Le piège classique
L’architecture comme procrastination. Des semaines à câbler des agents-qui-parlent-à-des-agents ressemblent à du progrès, mais un simple appel livré vous apprend plus qu’un diagramme. Le meilleur premier agent, c’est celui qui répond à de vrais utilisateurs cette semaine.