Tester à l'ère agentique

Presque chaque mois, un nouveau modèle sort, un harnais change ses règles, un outil impose sa façon de faire. Je veux opérer un projet avec ces agents pour de vrai : en production, sur des livrables qui comptent. Et tout se joue sur une question : sur quoi puis-je m'appuyer en confiance, à quel agent confier quelle tâche ? Aujourd'hui, nous travaillons à vue. Nous avons l'intuition que tel modèle « est bon pour le code » et tel autre « écrit mieux », mais l'intuition n'atteste rien. Elle ne se transmet pas, elle ne se re-vérifie pas quand la version d'après arrive, et elle ne dit jamais à quel prix.

Voici comment nous avons cessé de naviguer à vue : une façon de rendre objectif le comportement des agents qui font tourner un projet. Le point de départ tient en une idée : si vous avez écrit une doctrine pour vos agents, vous n'êtes qu'à un pas de vos tests. C'est l'approche que nous avons prise dans proj-ai, où un skill franchit ce pas : il dérive les tests de la doctrine et les fait tourner.

Cliquer pour tout voir ⤢

L'objet du test : une doctrine, pas un programme

Nous construisons proj-ai, un package doctrinal qui ne dépend d'aucun harnais en particulier, un operating model pour livrer un projet opéré par des agents IA. La pile se lit de bas en haut. D'abord un modèle ; il tourne dans un harnais : Claude Code, Codex, Antigravity, et les suivants. Autour, des outils : skills, hooks, MCP. Et par-dessus, une doctrine : les règles de comportement dans lesquelles on fait évoluer l'agent pour répondre à un besoin : coder, produire des livrables, animer la vie d'une équipe. Cette doctrine, c'est l'operating model ; le modèle, le harnais et les outils en forment la pile. L'ensemble des couples (harnais, modèle) qu'on décide de tester, lui, sera le périmètre. Nous avons posé les fondations de cette approche ailleurs ; ce qui m'occupe ici, c'est ce qui se passe une fois qu'elle existe et qu'il faut la tenir dans le temps.

Le propos déborde largement proj-ai. Dès que vous définissez un assistant, une chaîne d'agents, un pipeline de développement piloté par des modèles, vous écrivez des règles : réponds dans la langue de l'utilisateur, ne divulgue jamais un chemin de fichier à un lecteur non-technique, sauvegarde le travail sans qu'on le demande. Ces règles sont votre doctrine. Et une doctrine se laisse lire comme une spécification.

En génie logiciel, l'ordre n'a rien de figé : la voie classique écrit une spécification, puis du code, puis des tests qui vérifient que le code s'y conforme ; le TDD l'inverse et part des tests ; et le spec-driven development fait de la spécification le moteur de tout, et l'agentique le pousse à son terme. Dans un operating model agentique, justement, la spec existe déjà : c'est la doctrine. On n'invente donc pas une suite de tests à côté, on la dérive. Sauf que l'« implémentation » n'est pas du code que vous avez écrit : c'est le comportement d'un modèle que vous ne contrôlez pas, dans un environnement d'exécution non-déterministe et qui dérive d'une version à l'autre. D'où une grille simple :

la doctrine tient lieu de spécification ; l'agent, un modèle dans son harnais, en est l'implémentation.

Mais c'est une implémentation qu'on n'a pas écrite et qu'on ne peut pas figer. Les montées de version du modèle, au fond, sont la partie prévisible : elles s'annoncent, on peut les anticiper. Ce qui change en silence, c'est le harnais : il se met à jour sans cesse, et chacune de ses mises à jour — une instruction système retouchée, un skill interne ajouté, un prompt caché modifié — peut altérer le comportement du modèle sans que rien ne vous le signale. C'est ce qui rend ce test différent de tout ce qu'on connaît : l'implémentation peut dériver sous vos pieds alors que vous n'avez rien touché.

Chaque directive devient alors un scénario de comportement. Réponds dans la langue de l'utilisateur se teste : on envoie une question en français, on regarde la langue de la réponse. Recalcule la vue, ne l'édite pas à la main se teste : on demande un changement qui devrait déclencher un recalcul, et on vérifie que l'agent a bien appelé l'outil de recalcul plutôt que de bricoler le fichier. La directive n'est plus une bonne intention rangée dans un coin ; c'est une assertion qu'on exécute.

Deux couches : ce qui est binaire, ce qui demande un jugement

Tout ne se vérifie pas de la même façon. Certaines règles sont mécaniques : un fichier existe ou non, un contrat de structure est respecté ou non, l'en-tête d'un fichier est bien formé ou non. Celles-là, nous les traitons comme des tests « unitaires » : des contrôles déterministes, sans IA, qu'on fait passer avant d'intégrer quoi que ce soit. Pas de modèle dans la boucle, pas d'ambiguïté, pas de coût. C'est le socle.

Au-dessus, il y a tout ce qui ne se réduit pas à un oui/non. La voix tient-elle le registre métier ? L'explication est-elle pédagogique ? L'agent a-t-il respecté une règle dans un cas ambigu ? Ces questions demandent un jugement, et c'est la seconde couche : une matrice de comportement. On lance réellement chaque couple harnais × modèle sur les scénarios dérivés de la doctrine : le vrai outil avec le vrai modèle, sans interface, en lot. Chaque réponse passe par deux filtres : des contrôles binaires (la réponse contient-elle un chemin de fichier interdit ? une langue erronée ?) et un modèle-juge qui note de 0 à 5 ce qui relève du subjectif.

⤢

La matrice est l'objet central. En lignes, les directives. En colonnes, les configurations : chaque (harnais, modèle) du périmètre. Dans les cellules, des notes. Lue d'un coup d'œil, elle dit ce qu'aucune intuition ne sait dire : cette directive tient partout sauf sur ce modèle ; celle-ci s'effondre sur tout le périmètre ; ce couple est solide partout sauf sur la sécurité. Nous avons quitté l'anecdote pour la mesure.

Mais une note seule ne sert à rien si on ne sait pas pourquoi elle est tombée. C'est là que le modèle-juge fait plus que noter : pour chaque cellule en échec, il rend le contexte — l'extrait de réponse fautif, la directive enfreinte, la raison du verdict en clair. On ne lit pas « 2/5 », on lit « le modèle a divulgué le chemin knowledge/decisions/adr-007.md en racontant son raisonnement, alors que la directive l'interdit en mode métier ». Puis le juge remonte d'un cran : il agrège les échecs en une lecture globale — quelles directives flanchent, sur quels paliers, selon quels motifs — et en tire des suggestions concrètes : reformuler telle consigne devenue ambiguë, ajouter telle clause manquante, et jusqu'à rédiger une instruction taillée pour un modèle précis afin de ramener un comportement dans le validable. La matrice ne dit pas seulement où ça casse ; elle propose par où commencer pour réparer.

Quand le test redéfinit la doctrine

La lecture la plus précieuse n'est pas cellule par cellule, mais ligne par ligne. Quand une directive tient partout sauf sur un modèle, le problème est le modèle. Mais quand elle échoue partout — tous les harnais, tous les modèles, sans exception — le verdict se retourne : ce n'est plus un modèle qui faiblit, c'est la règle qui est mal écrite. Aucun moteur, si capable soit-il, ne rattrape une consigne objectivement mal cadrée. Le banc d'essai cesse alors de juger les modèles pour révéler un défaut de notre propre doctrine — et c'est là qu'il devient un outil de conception.

Une fois la matrice produite, un agent la relit, à la recherche des motifs transverses. Ces motifs sont ce qu'on ne voit pas en lisant case par case.

Un exemple. La directive de voix métier (parler à un lecteur non-technique sans lui jeter un chemin de fichier, un identifiant interne ou un terme de jargon) échouait à peu près partout. Tous harnais, presque tous modèles. La tentation aurait été de durcir la règle, de l'écrire en majuscules, d'empiler les interdictions. En lisant les réponses fautives côte à côte, le diagnostic était ailleurs : les copies qui fuitaient étaient les plus verbeuses. Les modèles qui racontaient leur tuyauterie interne (« je vais maintenant recalculer la vue puis sauvegarder ») étaient ceux qui laissaient passer un chemin ou un terme technique au fil de la narration. La fuite n'était pas un problème de vocabulaire ; c'était un problème de débit.

⤢

Nous avons donc inscrit une clause de concision dans la directive : dire ce qui s'est passé en une ou deux phrases simples, puis s'arrêter. Sur plusieurs modèles, la conformité a bondi : opus est passé au sans-faute. Sur d'autres, non : un même correctif ne prend pas partout. C'est pourquoi nous re-mesurons, couple par couple. Le détail contre-intuitif : le palier de modèles qui raisonne le moins tenait la voix métier là où des modèles bien plus gros la rataient. Plus bref, plus propre. Un modèle qui réfléchit beaucoup à voix haute trouve mille occasions de laisser fuir ce qu'il ne devrait pas dire. L'intuition aurait routé cette tâche vers le meilleur modèle, et elle aurait eu tort. Nous ne l'avons pas trouvé en réfléchissant ; nous l'avons trouvé en mesurant, puis en laissant un agent lire la mesure.

Le test ne s'est pas contenté de noter la doctrine. Il l'a réécrite. C'est ça, « ne plus naviguer à vue » : la doctrine devient un objet qu'on observe, qu'on corrige, dont on vérifie que la correction a porté.

Ce que l'objectivation rend possible

Une fois la matrice fiable, trois usages s'ouvrent.

Garantir. La matrice atteste, par couple (harnais, modèle), quelles directives tiennent. Ce n'est pas une promesse, c'est une preuve datée et reproductible. Surtout, elle se re-prouve à chaque nouvelle version. La garantie n'est pas un tampon qu'on appose une fois ; c'est une vérification qu'on relance à chaque dérive. Un constat que nous avons fait et refait : plus récent ne veut pas dire plus conforme. Une mise à jour — du modèle, et plus souvent du harnais — peut casser une directive qui tenait la veille. Sans matrice, nous l'apprenons par un livrable raté chez un client ; avec, nous l'apprenons avant de déployer. Et la garantie sait dire non : quand un couple ne tient pas la doctrine — pas de façon ponctuelle, mais de façon répétée et vérifiée — il sort de la liste des configurations que nous nous autorisons à mettre en production. La matrice n'est pas qu'un tableau d'honneur ; c'est un droit d'admission, et certains modèles ou harnais en sont écartés tant qu'ils ne se comportent pas, de manière attestable, comme notre doctrine l'exige.

Affiner. Quand un modèle précis flanche sur une règle précise, nous lui adressons une instruction ciblée : pas une refonte de la doctrine pour tout le monde, un correctif chirurgical adossé à la preuve qui l'a motivé. Et nous le tenons pour ce qu'il est : une dette, pas un acquis. Une instruction par modèle est périssable : elle vaut tant que la mesure qui la justifie tient. La version suivante la rendra peut-être inutile, ou nuisible. Elle porte donc sa provenance et sa date de péremption probable. Nous ne l'oublions pas dans un coin.

Router. Le gain que je trouve le plus fort. Sachant quel modèle tient quelle directive, et à quel coût, on peut donner à chaque tâche le modèle qui convient : pas le plus puissant par réflexe, le moins cher qui reste fiable pour cette tâche-là. Le travail mécanique, répétitif, à faible enjeu va vers un modèle rapide et bon marché dont on a mesuré qu'il tient ; le jugement, la sécurité, les arbitrages délicats restent sur un modèle fort. Ce n'est pas un choix au doigt mouillé entre « cher et bon » et « bon marché et risqué » : c'est une décision adossée à une mesure par couple. Sur notre périmètre, cinq des sept directives se confient à un modèle moins cher ; deux seulement exigent un modèle fort : le recalcul et la sécurité.

⤢

C'est ce que proj-ai studio est conçu pour exploiter : ventiler les actions, au fil d'un même échange, vers le bon modèle, avec l'instruction réglée pour lui. La conversation reste une, mais en dessous, chaque geste part à l'agent qui le servira au meilleur ratio coût / qualité / rapidité. Une mise en garde, ici : une mesure ne se transpose pas. Ce que nous avons vérifié sur un couple ne dit rien d'un autre. Le routage repose sur des mesures par couple, jamais sur une généralisation.

La boucle, et pourquoi elle est à vous

Tout cela tient dans quatre gestes, séparables, que n'importe quel projet peut s'approprier — et le mot approprier est à prendre au pied de la lettre : la boucle ne livre pas un classement de modèles à recopier, elle outille votre projet à mesurer vos règles sur votre matériel. Définir : dériver ses scénarios de sa doctrine — pas de notre catalogue, du vôtre ; vos règles à vous deviennent vos tests à vous. Exécuter : les lancer sur votre périmètre, indépendamment, sur les harnais et modèles que vous utilisez vraiment. Comprendre : lire la matrice, chercher les motifs transverses, laisser un agent la relire. Régler : corriger votre doctrine, affiner une instruction, ajuster le routage — puis recommencer.

Les trois premiers gestes sont indépendants du quatrième : on peut tester sa doctrine sans rien régler, juste pour savoir où l'on en est. C'est ce qui rend la démarche adoptable. Vous n'avez pas besoin de notre operating model pour en tirer parti : il vous faut une doctrine écrite, un périmètre nommé, et la discipline de mesurer avant de croire. Une doctrine qu'on ne peut pas tester est une doctrine qu'on n'a pas vraiment écrite.

Cette boucle, nous ne nous sommes pas contentés de la décrire : nous l'avons outillée. Dans notre operating model agentique, les quatre gestes sont devenus des commandes — définir ses scénarios à partir de sa propre doctrine, les exécuter sur son périmètre, lire la matrice, régler — puis nous les avons généralisés. Quiconque adapte cet operating model à son type de projet, avec ses propres règles d'usage, est guidé pas à pas pour écrire ces règles, puis pour les tester sur ses harnais et ses modèles. La doctrine et son banc d'essai naissent du même geste. Effet de bord inattendu, et précieux : en déroulant ses propres tests, l'agent se corrige lui-même — il découvre où il a fauté avant que vous ne le lui disiez.

Cinq garde-fous que l'expérience a gravés, si vous tentez la démarche :

Reste à le tenir

Votre projet IA n'est pas terminé quand les tests passent. Il est terminé quand vos agents tiennent votre doctrine sur votre périmètre : sur les modèles que vous utilisez, aux endroits qui comptent, à un coût que vous assumez. Et il ne le reste qu'aussi longtemps que vous pouvez le re-vérifier, parce que le prochain modèle sortira le mois prochain sans vous demander la permission de changer. J'ignore si cette course s'arrête un jour. Mais la seule façon de courir sans se perdre, c'est de garder à portée de main l'instrument qui transforme une intuition en preuve, et de le relancer à chaque fois que le terrain bouge. L'objectivation ne remplace pas le jugement ; elle lui donne de quoi s'appuyer.

Objectiver, ce n'est pas une case à cocher en fin de projet. C'est une habitude qu'on tient, et qu'on relance à chaque nouveau modèle, chaque mise à jour de harnais, chaque révision de la doctrine.