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.

  1. 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.
  2. Un workflow — la route est connue ? Câblez-la : chaînage, routage, parallélisation.
  3. Une boucle d’agent — seulement quand le chemin ne peut vraiment pas être scénarisé.
  4. 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.