Les modèles d’IA sont très bons pour produire du code qui a l’air correct. Il compile. Il est propre. Il arrive souvent avec des tests qui passent. Et parfois, il ne fait pas ce qui était demandé.
C’est autour de ce dernier point que nous concevons notre façon de travailler. Ce billet l’explique en cinq habitudes.
1. La définition de « terminé » est écrite avant le code
Chaque modification commence par une demande écrite : ce qui doit se passer, pour qui, et comment nous saurons que c’est fait. Avant que le moindre code existe, un agent distinct transforme cette demande en tests d’acceptation qui échouent.
Cet agent voit la demande et rien d’autre. Ni la conception, ni le code, ni le plan de l’agent qui va développer. Ses tests décrivent ce qui a été demandé, sous une forme qu’une machine peut vérifier.
2. Celui qui développe ne peut pas changer les règles en cours de partie
L’agent qui développe la modification ne peut pas modifier ces tests d’acceptation. Avant la fusion, le système vérifie qu’ils sont intacts. Si l’un d’eux a changé, la raison doit être écrite et acceptée en revue.
C’est encore plus important avec l’IA qu’avec des humains. Quelqu’un sous pression pourrait affaiblir un test et s’en sentir coupable. Un modèle qui cherche à faire passer les tests en affaiblira un sans le moindre état d’âme, et justifiera le changement de façon convaincante. La règle enlève la tentation du processus au lieu de compter sur la retenue.
3. Les tests passent par le vrai parcours
Un test unitaire qui appelle une fonction prouve que cette fonction marche toute seule. Il ne prouve pas que la page se charge, que la tâche en arrière-plan s’exécute ou que le bouton fait ce que son libellé annonce.
Donc tout ce qui est nouveau et qui s’exécute, comme une page, une tâche en arrière-plan, une nouvelle tentative ou une étape d’importation, a au moins un test qui passe par le vrai point d’entrée et vérifie ce qu’un utilisateur verrait vraiment. Un test unitaire réussi ne suffit pas pour dire « terminé ».
4. Les fonctions qui jugent sont notées, pas admirées
Certaines fonctions font plus que déplacer des données. Elles classent, choisissent ou rédigent. La commande par courriel d’UTX Freight en est une : elle décide dans quel champ va une valeur, et auquel de vos terminaux correspond un nom.
Notre règle pour ces fonctions : elles sont notées selon un seuil établi d’avance, sur des exemples réalistes, avant de sortir de la bêta. La commande par courriel doit passer ce test avant d’arriver chez nos clients. Les données de test sont séparées. Une partie sert pendant le développement. L’autre, mise de côté, ne sert qu’une fois, pour le résultat final, afin que la fonction ne puisse pas être ajustée pour réussir l’examen. Comme les évaluateurs d’IA varient d’une exécution à l’autre, les résultats sont comparés sur plusieurs exécutions.
Et le seuil est écrit avant de commencer. Si le résultat ne l’atteint pas, le rapport le dit. Nous préférons livrer une fonction plus modeste qui atteint son seuil qu’une plus ambitieuse accompagnée d’une excuse.
5. Les bogues échappés sont retracés
Aucun ensemble de tests n’attrape tout. Quand un bogue atteint un utilisateur, le corriger n’est que la moitié du travail. L’autre moitié, c’est de se demander quelle vérification aurait dû l’attraper.
Si une vérification existante aurait dû l’attraper et ne l’a pas fait, elle est corrigée. Si aucune ne l’aurait attrapé, une nouvelle est ajoutée, et elle reste dans la suite.
Avec le temps, c’est comme ça que la suite s’améliore : pas en écrivant plus de tests en général, mais en écrivant ceux dont les vrais bogues ont prouvé le besoin.
Ce que ça donne vu de l’extérieur
Nos clients ne voient rien de tout ça directement, et ils ne devraient pas avoir à le voir. Ce qu’ils voient est plus tranquille :
- Une mise à jour qui fait ce que son journal des changements annonce.
- Moins d’appels « ça marchait avant » après un changement.
- Une réponse franche quand ils demandent ce qui a changé et pourquoi.
Ce que ça coûte
Écrire les tests d’abord prend du temps au départ, et ça peut sembler lent quand la modification a l’air facile. Séparer les données et noter une fonction demande de la discipline, alors qu’il serait plus rapide de regarder quelques exemples et de dire que c’est correct.
Le compromis en vaut la peine. L’IA rend le code bon marché à écrire. Les tests sont ce qui permet de s’y fier. Quand écrire du code ne coûte presque rien, le vrai travail est dans les tests.
Notre billet sur l’usine logicielle montre où ces habitudes s’insèrent dans l’ensemble de la méthode.