Il y a un moment très reconnaissable dans un projet d'agent IA. Ça marche sur les trois premiers cas, on ajoute un cas particulier dans la consigne, ça marche. On en ajoute un deuxième, ça marche encore. Au huitième, quelque chose se casse ailleurs, et personne ne sait où, parce que tout est dans le même bloc de texte de quatre pages.
C'est le mode d'échec le plus courant que je rencontre, et il n'a rien à voir avec le modèle. C'est un problème de découpage.
Pourquoi la consigne géante finit toujours par céder
Une consigne unique qui décrit tout le métier a un défaut structurel : chaque phrase peut influencer chaque comportement. Vous ajoutez une précision sur le traitement des pièces manquantes, et la mise en forme de la synthèse change. Rien ne vous prévient, parce qu'il n'y a rien qui sépare les deux.
Et surtout, vous ne pouvez plus rien tester. Un test qui dit « l'agent a bien traité le dossier » ne vous apprend rien le jour où il échoue : le dossier passe par douze décisions différentes, et vous ne savez pas laquelle a lâché. Vous relisez quatre pages de consigne en espérant repérer la ligne coupable. Ça, ce n'est plus de l'ingénierie, c'est de la divination.
Une compétence = une question à laquelle on peut répondre par oui ou non
Le critère de découpage que j'utilise est volontairement bête : une compétence doit correspondre à une chose qu'on peut vérifier seule, sans exécuter le reste. Si vous ne savez pas écrire le test, c'est que le découpage est encore trop gros.
Prenez un dossier à instruire. « Traiter le dossier » n'est pas testable. « Identifier le type de document », « extraire les dates clés », « repérer les pièces manquantes », « signaler ce qui dépasse un seuil » : chacune l'est. Vous pouvez lui donner vingt exemples et compter combien passent. Vous savez, chiffre en main, où vous en êtes.
Ce que ça change en pratique
Le découpage coûte plus cher à écrire au départ. C'est vrai, et c'est pour ça qu'on l'évite. Voilà ce qu'il vous rend :
- — Une régression devient localisable. Vous modifiez une compétence, vous relancez ses tests à elle, et vous savez immédiatement si vous avez cassé autre chose.
- — Vous pouvez changer de modèle sur une compétence seulement. Certaines demandent de la finesse, d'autres sont de la reconnaissance de forme et tourneraient sur n'importe quoi. Rien ne vous oblige à payer le tarif de la plus exigeante partout.
- — Vous pouvez placer l'humain là où il sert. Sur un bloc unique, la validation est tout ou rien. Découpé, vous laissez passer l'extraction et vous faites valider la seule étape qui engage vraiment.
- — Vous pouvez en réutiliser une ailleurs. « Extraire les dates clés d'un document » resservira dans le projet suivant. « Traiter un dossier » ne resservira jamais.
Le piège inverse
Il existe une version excessive de ce conseil, et je l'ai vue aussi : découper en trente micro-compétences qui s'appellent en cascade. Là, vous avez remplacé un problème de consigne par un problème d'orchestration, et vous passez vos journées à débuguer des enchaînements plutôt que du texte.
La bonne mesure tient à une question : est-ce que chaque compétence correspond à quelque chose qu'un humain du métier nommerait spontanément ? Si vous devez inventer un vocabulaire pour décrire une étape, c'est probablement qu'elle n'existe pas.
Pour finir
Le découpage n'est pas une élégance d'architecte, c'est ce qui décide si votre agent sera réparable dans six mois ou s'il faudra le refaire. Une consigne monolithique est parfaitement fonctionnelle le premier mois. C'est au dixième cas particulier qu'on paie la facture, et à ce moment-là il est trop tard pour découper.