Les tests : la première chose à déléguer à un agent

Si vous ne deviez déléguer qu’une seule chose à un agent IA pour commencer, choisissez les tests automatisés. C’est la réponse que nous donnons à chaque équipe qui démarre, et elle tient en trois arguments : la sortie est vérifiable, le périmètre est borné, le levier est considérable. Aucune autre tâche ne combine les trois aussi bien.

Beaucoup d’équipes commencent pourtant ailleurs, par une fonctionnalité, pour prouver la valeur. C’est se compliquer la vie : une fonctionnalité demande du jugement produit, des allers-retours, une intégration. Les tests, eux, portent leur propre vérification.

Pourquoi les tests automatisés sont la délégation idéale

Vérifiable, parce qu’un test s’exécute : il passe ou il échoue, il couvre ou il ne couvre pas, et la couverture se mesure ligne par ligne. Vous n’avez pas besoin de croire l’agent sur parole, vous lancez la suite.

Borné, parce qu’un mauvais test ne casse pas la production. Le pire scénario est une fausse confiance, et on verra plus bas qu’elle se contrôle. Comparez avec une migration de schéma ratée : le rayon d’impact n’a rien à voir. C’est le terrain d’entraînement parfait pour apprendre à déléguer.

Considérable, enfin, parce que la dette de tests est universelle. Chaque équipe a des pans entiers de code non couverts que personne ne testera jamais à la main, faute de temps. Un agent écrit en quelques jours les tests de caractérisation qu’une équipe repoussait depuis deux ans, et ce travail que personne n’avait budgété devient soudain abordable.

Le piège : des tests qui ne testent rien

Le test faux échoue et se voit ; le vrai risque de la délégation est le test creux. Un agent à qui l’on demande simplement "écris des tests" optimise pour la couverture apparente : assertions triviales, mocks qui vérifient le mock, tests qui photographient le comportement actuel du code, bugs compris. La couverture monte, la confiance monte, et rien n’est protégé.

La parade tient en deux pratiques. La première : relire les assertions, pas l’échafaudage. Ce que le test vérifie est la seule chose qui compte dans la revue ; le reste est de la plomberie. La seconde : casser volontairement. Introduisez un bug dans le code couvert ; si la suite reste verte, les tests ne testent rien. Cette vérification par mutation, faite à la main sur les chemins importants ou outillée quand l’équipe est mûre, est le contrôle qualité des tests eux-mêmes.

Pour les bugs remontés, ajoutez une règle : le test de reproduction avant le correctif. Un agent qui doit d’abord écrire un test rouge reproduisant le bug, puis le rendre vert, produit un correctif vérifiable par construction.

Les consignes qui font de bons tests

Un agent produit ce qu’on lui spécifie, rien de plus. Nos consignes standard : une exigence de couverture sur les lignes modifiées, jamais sur le total du repo, qui ne veut rien dire ; une structure lisible en trois temps (préparation, action, assertion) ; des noms de tests qui décrivent un comportement, pas une fonction ; les cas limites listés explicitement, valeurs vides, nulles, doublons, erreurs réseau ; une préférence pour les objets réels sur les mocks quand ils sont peu coûteux ; l’interdiction des tests fragiles qui dépendent de l’horloge, de l’ordre d’exécution ou du réseau.

Rien d’original : ce sont vos conventions de test. La différence est qu’un agent les applique à cent pour cent quand elles sont écrites, et pas du tout quand elles restent dans la tête d’un senior.

Une skill pour que ça tienne dans le temps

Écrites où ? Dans une skill versionnée dans vos repos : le document d’instructions que l’agent charge à chaque tâche de test. La skill transforme une bonne pratique individuelle en standard d’équipe, et elle s’améliore par itération : quand un test creux passe la revue, la parade correspondante rejoint la skill, et l’erreur ne se reproduit plus nulle part.

Le reste du dispositif suit naturellement. La CI exige la couverture sur les lignes modifiées, ce qui rend la règle non contournable. Et la suite qui en résulte devient votre premier relecteur, celui qui desserre le goulot de la revue en attrapant les régressions avant qu’un humain n’ouvre le diff.

Commencer par les tests a une dernière vertu : c’est une victoire rapide, mesurable, qui construit la confiance de l’équipe pour les délégations suivantes. C’est souvent la première semaine de nos programmes d’ingénierie agentique, et rarement la moins rentable.