Jeux de régression
Chaque bogue corrigé devient un cas de test permanent — pour que la même panne ne puisse jamais revenir en douce avec un changement futur.
L'aviation est devenue sûre parce que chaque incident est devenu un élément de liste de vérification. Les jeux de régression amènent cette habitude aux workflows IA : chaque panne corrigée est notée comme un test que tout changement futur doit réussir. « On ne fera jamais cette erreur deux fois » cesse d'être un espoir et devient une règle que la machinerie fait respecter.
Le problème, en mots simples
Un client tombe sur un bogue. Votre équipe se démène, trouve la cause, corrige, s'excuse. Tout le monde passe à autre chose. Six mois plus tard, un changement sans aucun rapport réintroduit discrètement la même panne — et le même client la subit de nouveau. Rien n'était en place pour s'en apercevoir, parce que la correction vivait dans le code mais la leçon ne vivait nulle part. Une équipe qui n'écrit pas ses pannes prévoit, très littéralement, de les répéter.
Ce que nous mettons en place
Chaque panne que l'équipe trie devient un cas de régression candidat : l'entrée exacte qui l'a déclenchée, la mauvaise sortie produite, et la sortie corrigée qui aurait dû sortir. Une étape de curation retire les doublons et étiquette chaque cas, en notant d'où il vient et quand (sa provenance, versionnée comme tout le reste). Le résultat rejoint le jeu d'évaluation (la collection sauvegardée de cas de test) que le harnais fait passer sur chaque changement — de sorte qu'un changement qui ramènerait un vieux bogue échoue aux tests avant de partir, pas après.
Comment ça fonctionne, étape par étape
- Une panne survient et se fait corriger
La vie normale de n'importe quel système. La différence, c'est ce qui vient ensuite.
- La panne est notée comme un cas
L'entrée déclencheuse, la mauvaise sortie, la bonne sortie — l'incident au complet, capturé comme un test.
- La curation nettoie la pile
Doublons fusionnés, chaque cas étiqueté, son origine et sa date au dossier. Un jeu propre, pas un tiroir fourre-tout.
- Le cas rejoint le jeu permanent
À partir de maintenant, il fait partie de ce contre quoi chaque changement futur est testé, automatiquement.
- Les vieux bogues ne reviennent plus en douce
Un changement qui réintroduit une panne connue échoue aux tests et ne part jamais. La leçon tient.
Ce qui change pour vous
Avant, corriger un bogue vous protégeait jusqu'au prochain gros changement. Après, le jeu de tests grossit à chaque incident, et le système devient de plus en plus difficile à casser de toutes les façons dont il a déjà cassé — la dérive de qualité devient détectable, et les pannes répétées deviennent rares. Le jeu d'évaluation prend de la valeur à mesure que le système mûrit, comme un compte d'épargne de leçons durement gagnées. Ce qu'il ne fera pas : attraper les pannes d'un genre tout nouveau. Il vous protège contre les erreurs que vous avez déjà payées une fois — les nouvelles demandent encore de la vigilance.