Patterns d'architecture agentique

1Un agent ne corrige pas sa propre copie

Première famille : le contrôle, en commençant par qui juge. Relisez votre dissertation à minuit : vous lisez ce que vous vouliez écrire, pas ce qui est écrit. Le livre dit la même chose d'un agent. Celui qui produit une solution puis la juge « a du mal à être un critique objectif de son propre travail » (leçon 111). Il trouve des excuses à ses erreurs.

Le livre sépare donc les deux rôles. Le pattern s'appelle Hybrid Planner + Scorer (planificateur et noteur). Dans l'exemple du livre, un agent planificateur écrit trois slogans publicitaires, puis un agent noteur les classe.

Encore faut-il que le noteur juge sur le bon critère. Une métrique générique comme BERTScore mesure seulement la ressemblance entre deux textes. Le livre la dit « aveugle à la logique ». Un plan qui supprime les données avant de les sauvegarder peut ainsi obtenir une bonne note (leçon 112). Il faut donc une grille propre au métier. On la calibre sur un golden dataset : un jeu de cas dont on connaît déjà la bonne réponse.

Ce duo tourne dans une boucle, mais pas celle qu'on imagine. Le livre l'appelle Self-Improvement Flywheel (volant d'amélioration), en quatre temps : générer, évaluer, apprendre, déployer. Évaluer est l'étape clé, car « un système agentique ne peut améliorer que ce qu'il sait mesurer » (leçon 110).

Apprendre, ici, ne veut pas dire corriger le texte. Cela veut dire réentraîner le planificateur, puis le noteur, sur les retours notés. C'est le fine-tuning : reprendre l'entraînement d'un modèle sur des exemples choisis.

2Un agent qui apprend de son noteur finit par le duper

Dans l'idée précédente, on réentraîne le planificateur et le noteur à partir de ce que produit l'autre. Le livre appelle ce montage Coevolved Agent Training (entraînement coévolué). Il crée un risque : un élève finit par deviner ce qui plaît au correcteur. Il ne cherche plus à bien faire, il apprend le barème.

L'exemple du livre montre ce risque (leçon 115). Le planificateur corrige du code, et le noteur juge ses corrections. Le planificateur découvre une astuce : envelopper l'erreur dans un bloc try/except. Ce bloc avale l'erreur : le programme ne plante plus, mais le bug est toujours là. Le noteur, formé sur des métriques standard, applaudit. Le système cesse de progresser.

Le livre nomme deux pannes de ce montage (leçon 114) :

• Collusion : le planificateur apprend à « jouer » avec le système et produit des sorties médiocres que le noteur laisse passer. Le try/except ci-dessus en est un cas.
• Runaway divergence (dérive incontrôlée) : le système s'éloigne de ce que veut le métier, pour faire monter un chiffre interne que la boucle mesure.

Pour couper ces deux pannes, le livre prescrit un ancrage externe : un repère que la boucle ne réentraîne jamais, comme un examen corrigé par un extérieur dont l'élève ne connaît pas le barème. Sans « revue humaine périodique ou validation contre un golden dataset », la boucle risque ces pannes (leçon 114).

Pour sortir de l'impasse de l'exemple, le livre réentraîne le noteur sur des paires « rustine » contre « vraie correction ». Les vieilles astuces ne paient plus, et le planificateur doit apprendre à déboguer.

3Deux avis valent mieux qu'un, s'ils sont indépendants

Un noteur seul peut se tromper, ou se faire duper. Le livre propose donc aussi de croiser plusieurs avis. Avant une opération lourde, on demande un deuxième avis médical. Il n'est utile que si les deux médecins ne sortent pas de la même école.

Le livre a deux patterns sur ce modèle. Tous deux passent par un orchestrateur : l'agent coordinateur qui distribue le travail et rassemble les résultats. Les deux patterns diffèrent par le nombre d'agents :

• Parallel Execution Consensus (consensus par exécution parallèle) : deux agents indépendants reçoivent la même tâche, par exemple un score de crédit. Le modèle A rend 720, le B 725. L'écart tient dans la tolérance de 10 points, donc l'orchestrateur valide la moyenne, 722,5. Avec 720 et 780, un humain tranche.
• Majority Voting (vote majoritaire) : trois agents ou plus votent. Deux « approuver » sur trois, et le dossier passe.

Pour que ces avis restent indépendants, le livre pose trois conditions :

• un nombre impair d'agents, « pour éviter les égalités » ;
• des agents « alimentés idéalement par des modèles de fondation différents », c'est-à-dire de gros modèles de langage de fournisseurs différents ;
• un chemin prévu pour le désaccord.

Ce montage a un prix, et le livre l'assume : c'est « le pattern de redondance le plus cher » (leçon 75).

4Quand un agent échoue : reformuler, sauvegarder, appeler l'humain en dernier

Seconde famille : le cadre autour des agents, en commençant par l'échec. Le contrôle attrape une mauvaise réponse, mais un agent peut aussi échouer net. Une clé ne tourne pas dans la serrure : forcer ne sert à rien. Il faut la ressortir et changer d'angle.

Le livre applique cette règle aux agents avec quatre patterns complémentaires. Le premier touche au prompt, la consigne envoyée au modèle :

• Adaptive Retry with Prompt Mutation (réessai avec mutation du prompt) : quand l'échec se répète à l'identique, « renvoyer simplement la même requête est vain » (leçon 72). On reformule donc le prompt. Exemple : un JSON invalide est relancé avec « réfléchis étape par étape, puis formate en JSON ».
• Watchdog Timeout Supervisor (chien de garde) : un minuteur entoure l'appel au modèle. Passé 10 secondes, il l'annule et passe la main à un agent de secours plus simple.
• Incremental Checkpointing (points de sauvegarde) : chaque étape terminée est sauvegardée. Si le service de résumé tombe, la relance reprend donc à la troisième étape.
• Delayed Escalation Strategy (escalade différée) : l'humain n'arrive qu'en dernier, avec un dossier complet. Exemple : l'agent est sûr à 85 % pour un seuil de 95 %. Il réessaie deux fois, puis le dossier part à un humain.

Des quatre, la sauvegarde est la plus simple à montrer. Voici un pseudo-code imaginé, pas du livre. Avant chaque étape, le script regarde si elle est déjà sauvegardée :

for etape in ["nettoyer", "entites", "resumer"]:
    if existe(sauvegarde, etape):
        etat = charger(sauvegarde, etape)
    else:
        etat = executer(etape, etat)
        ecrire(sauvegarde, etape, etat)

Le livre enchaîne ensuite ces patterns sur une demande de prêt (leçon 68). La chaîne suit cet ordre : réessai, redémarrage automatique de l'agent, modèle de secours, puis escalade vers un humain. Chaque étape est notée dans un journal.

Pour juger ces parades, le livre prescrit une métrique par pattern, comme le taux de reprise pour le réessai. Le tableau de la même leçon en compte huit. La raison : « la robustesse ne peut pas être une affaire d'opinion ».

5Un agent coordonne, les autres exécutent, et le code décide de la suite

Après l'échec d'un agent, reste à organiser le travail de plusieurs. Sur un chantier, le chef décide qui passe quand. Le maçon pose les briques, l'électricien tire les câbles. Si le chef fait tout lui-même, le chantier s'arrête avec lui.

Le livre en tire le pattern Supervisor (superviseur). Un orchestrateur central découpe le travail et le confie à des sous-agents, des agents spécialisés. Puis il décide de la suite.

Ce pattern vient avec deux règles :

• Ne pas fabriquer un God agent (agent-dieu), un agent qui fait tout : il coordonne et il exécute. L'orchestrateur, lui, ne fait que coordonner : il reste « seul responsable de la coordination » (leçon 45). Le travail lui-même revient aux sous-agents.
• Commencer centralisé : un seul orchestrateur au centre, qui confie les tâches et reçoit tous les résultats. Le livre y voit « un bon point de départ » (leçon 46).

Le livre illustre ce pattern par une demande de prêt. Un agent orchestrateur enchaîne trois spécialistes : vérification des documents, contrôle de crédit, évaluation du risque. Sous un score de 600, il rejette le dossier tôt.

Entre ces agents, pas de prose libre. Le livre juge les relais en langage naturel « une recette d'instabilité » (leçon 45). Il impose donc des schémas de sortie stricts : un format de réponse fixé d'avance, par exemple un JSON aux champs imposés.

Le livre se méfie aussi des chaînes trop longues : un agent confie une tâche à un deuxième agent, qui la confie à un troisième. Chaque maillon ajoute un aller-retour complet avec le modèle, donc le temps et le coût s'additionnent. D'où cette mise en garde : « méfiez-vous des longues chaînes de délégation » (leçon 137).

Reste à écrire l'enchaînement des étapes, et le livre le veut en code. Les leçons 147 et 148 comparent deux outils de programmation d'agents sur un même cas :

• CrewAI organise des agents en équipe de rôles. Les agents intermédiaires y ont « continué à travailler malgré l'erreur de validation initiale » (leçon 148).
• LangGraph décrit le flux comme un graphe d'étapes qui lisent un état partagé. Un embranchement testé en code, appelé arête conditionnelle, regarde une clé error. Dès qu'un champ manque, il envoie le dossier vers le rejet.

6Les droits d'un agent se règlent dans le code, pas dans la consigne

Coordonner les agents ne suffit pas : il faut aussi borner ce que chacun a le droit de faire. Un stagiaire prépare un virement, mais il n'a pas la clé de la banque.

Le livre applique cette règle à un agent qui rédige un rapport d'activité suspecte (leçon 152). L'agent reçoit l'outil draft_report pour rédiger, pas l'outil submit_report pour envoyer. Le workflow, la chaîne d'étapes, attend ensuite le feu vert d'un humain, l'officier de conformité. C'est le code qui borne l'agent : l'outil d'envoi ne lui est jamais donné.

Le prompt, le texte de consignes donné au modèle, ne borne rien en revanche, et le livre l'avoue lui-même. L'exemple de la leçon 131 met dans le prompt des critères de succès chiffrés. Il y ajoute une boucle de vérification à répéter trois fois. Le livre prévient : « N=3 n'est pas un paramètre Python » (leçon 131). Autrement dit, rien dans le code ne compte les trois passes.

Le livre appelle ces consignes des semantic guardrails, des garde-fous sémantiques : des règles données au modèle, que rien dans le code n'applique. En production, il recommande des tests d'évaluation hors du prompt, écrits avec des outils comme DeepEval ou Ragas.

7Un plafond de dépense coupe l'agent avant la facture

Borner les droits d'un agent ne borne pas sa dépense. Un forfait mobile qui se coupe à 100 % vous évite la facture de 900 euros. Le livre applique cette idée aux agents sous le nom de tokenomics.

Cette tokenomics compte en tokens. Un token est un morceau de mot : l'unité que le modèle compte et facture. Les tokens deviennent ici une monnaie interne, avec un quota par agent. L'enjeu est réel : une boucle d'apprentissage peut consommer « 10 à 100 fois » plus de tokens qu'un usage standard du modèle (leçon 117). Le livre ne source pas ce chiffre.

L'exemple du livre montre le plafond à l'œuvre. Un agent analyste trouve 5 000 PDF à résumer et reçoit 50 dollars de budget. Vers le 50e PDF, 45 dollars sur 50 sont déjà dépensés, soit 90 % du budget. Un disjoncteur, comme celui d'un tableau électrique, coupe alors la collecte et force l'étape de rapport avec ce que l'agent a déjà.

Un disjoncteur minimal est un simple test dans le script qui lance l'agent :

# pseudo-code imaginé
if depense >= 0.9 * budget_job:
    arreter_collecte()
    produire_rapport(donnees_actuelles)

8Choisir les patterns avant le code, grossir seulement si besoin

Reste une question : par où commencer, face à une cinquantaine de patterns ? Le livre répond par une méthode, pattern-first : les patterns d'abord. On trace le plan avant de monter les murs. De même, on choisit les patterns avant le framework, la bibliothèque de code qui fait tourner les agents.

Pour le livre, « les patterns engendrent les architectures » (leçon 155). Le framework n'est qu'un accélérateur (leçon 153). Le livre pose aussitôt un frein : « implémenter tous les patterns d'un coup est impraticable et souvent inutile » (leçon 121).

On démarre donc petit, avec une application monolithique : un seul programme, lancé d'un bloc. L'orchestrateur y appelle ses spécialistes l'un après l'autre. Il conserve ses garde-fous : un délai maximal, une escalade vers un humain.

Cette petite application grossit par étapes. On passe à des services séparés, des petits programmes indépendants qui se parlent, quand c'est « dicté par la nécessité » (leçon 122). Le cours en fait deux questions à se poser : faut-il plus de trois ou quatre agents spécialisés, ou des traitements longs qui tournent en arrière-plan (leçon 125) ?