Tests de code généré
Quand l'IA écrit du code qui tourne à l'intérieur d'un workflow, ce code reçoit ses propres tests — pour qu'un changement ne puisse pas briser en douce un morceau que personne n'a pensé vérifier.
Si un élève fabrique son propre instrument de mesure pour un projet de science, un bon professeur vérifie l'instrument, pas seulement les résultats. Même idée ici : quand un agent écrit du code — de petits gestionnaires, des convertisseurs, des vérificateurs — ce code est testé directement, pas seulement les instructions qui l'ont produit.
Le problème, en mots simples
Vous retouchez un prompt. Les tests du prompt passent, tout est au vert, le changement part. Une semaine plus tard, un petit convertisseur de données que l'agent avait généré il y a des mois se met à massacrer les dates — et personne ne le remarque pendant des jours, parce que les tests de personne ne le couvraient. Tout le monde testait les réponses du modèle ; personne ne testait le code que le modèle avait écrit. C'est dans cet écart que « le prompt est correct » et « le workflow est brisé » peuvent être vrais en même temps.
Ce que nous mettons en place
Chaque morceau de code que l'agent génère — gestionnaires (de petits programmes qui réagissent à des événements), transformateurs (du code qui convertit des données d'une forme à une autre), validateurs (du code qui vérifie que les données sont bien formées) — arrive accompagné de cas de test bâtis à partir d'entrées réelles que votre workflow a vraiment vues, pas d'exemples jouets. Le harnais d'évaluation (le banc d'essai qui note chaque changement) exécute ces tests de code en plus des tests de prompt, sur chaque variante. Là où la couverture est mince, le trou est signalé comme une demande de nouveaux cas de test au lieu de rester invisible, et les pannes de production s'ajoutent au jeu de régression (la collection des bogues passés que tout changement futur doit franchir).
Comment ça fonctionne, étape par étape
- L'agent génère du code
Un gestionnaire, un convertisseur, un vérificateur — un morceau de code qui tournera dans le workflow, chaque jour, sur de vraies données.
- Des tests arrivent avec
Bâtis à partir d'entrées réelles que le workflow a vues, pour que les tests exercent les cas qui arrivent vraiment.
- Chaque changement exécute les tests
Changez un prompt, échangez un modèle, restructurez une étape — les tests de code tournent aussi, chaque fois, pas seulement quand quelqu'un y pense.
- Les trous sont signalés
Les parties du code qu'aucun test ne touche apparaissent comme du travail à faire maintenant, au lieu de surprises plus tard.
- Les vraies pannes deviennent des tests permanents
Quand quelque chose casse en production, ce cas rejoint le jeu de tests — pour ne plus jamais pouvoir casser en silence.
Ce qui change pour vous
Avant, le code généré était l'angle mort du workflow : le morceau qui échouait en silence pendant que toutes les vérifications visibles restaient au vert. Après, il casse bruyamment, en test, avant que les clients ne le voient — et un changement de prompt « sans danger » ne peut plus livrer un gestionnaire brisé par effet de bord. Ce qu'il ne fera pas : garantir que le code est élégant ou rapide. Les tests vérifient qu'il fait ce dont le workflow a besoin — la partie qui fait mal quand elle est fausse.