Ma suite de tests était verte depuis des semaines. Le parcours principal du produit était cassé.
TL;DR : un test vert ne prouve que ce qu'il vérifie vraiment. J'ai vécu les deux pires cas. Un test de base de données vert sur un changement qui a cassé la prod. Le test tournait avec tous les droits, la prod non. Et une suite de tests d'interface verte sur un produit cassé, parce qu'elle vérifiait les réponses du serveur au lieu de l'écran. À l'heure où l'IA écrit 42 % du code, vérifier est devenu plus dur qu'écrire. Voici les règles que j'applique depuis.
Cet article est pour les devs et les leads qui font confiance à leur CI verte. La CI, c'est la machine qui rejoue tous les tests à chaque changement de code.
Le contexte
Un projet perso, mais de taille réelle. Des services en Go, une base Postgres, un hébergement Kubernetes.
Les tests y sont de deux familles. Les tests d'intégration vérifient un service contre une vraie base de données. Les tests E2E, de bout en bout, pilotent un vrai navigateur sur le vrai produit, comme le ferait un utilisateur.
Une partie du code est écrite avec des agents IA, puis relue. Deux incidents m'ont appris la même leçon, à deux étages différents. Un test vert est nécessaire. Il n'est pas suffisant.
Le test vert qui a cassé le déploiement
Une migration est un script qui modifie la structure de la base de données. Elle se joue toute seule, au déploiement.
La migration d'un nouveau service contenait une ligne de trop : une commande qui change les droits d'un compte de la base.
En production, la migration tourne avec un compte aux droits limités. C'est voulu, par sécurité. Postgres a donc refusé la commande : ce compte n'a pas le droit de changer des droits.
La suite est une cascade. L'outil de migration marque la base « en erreur ». Le service redémarre en boucle sans jamais démarrer. Réparation à la main, avec le compte administrateur.
Le pire n'est pas la panne. Le pire, c'est que le test était vert. Ce test lance une base jetable dans un conteneur, avec un outil nommé Testcontainers. Et dans cette base de test, le compte est administrateur. Tous les droits.
ALTER ROLE app_system BYPASSRLS;
-- la commande qui change les droits d'un compte
-- test : superuser → OK
-- prod : restricted role → permission denied
-- schema_migrations.dirty = true → CrashLoopBackOffLa commande interdite passait donc en test et cassait en prod. J'ai vérifié : le test était vert sur la version cassée et sur la version corrigée. Un test qui passe des deux côtés d'un bug ne teste rien.
La règle depuis. Le compte utilisé par le test a les mêmes droits que celui de la prod. Et une migration ne touche jamais aux comptes, seulement aux tables.
Une suite E2E verte sur un produit cassé
Deuxième incident, plus embarrassant. Pendant des semaines, un parcours entier était cassé. Un dossier créé, un document signé, et l'écran suivant n'affichait plus rien de bon.
La suite E2E ? Cent pour cent verte, tous les jours.
J'ai audité la suite pour comprendre. Presque la moitié des tests n'ouvraient jamais de navigateur. Ils appelaient l'API, l'interface du serveur, et vérifiaient sa réponse brute. Personne ne regardait l'écran.
Un raccourci de test sautait l'étape de signature. L'étape même que ces tests prétendaient couvrir. Et les tests du vrai parcours de signature étaient marqués « à corriger plus tard ». Tous.
Dit autrement : le front pouvait cesser d'afficher l'état du dossier, les montants, le bouton suivant. Cent pour cent des tests passaient quand même.
Vérifie ce que l'utilisateur voit, pas ce que le serveur répond
La réécriture de la suite tient en une règle. Vérifie ce qui s'affiche à l'écran. Jamais la réponse brute du serveur.
Pourquoi ? Entre le serveur et l'écran, il y a tout le front : le code qui transforme la réponse en pixels. C'est lui qui était cassé. Et aucun test ne le regardait.
Deux détails qui paient. Vérifier chaque écran dans les deux langues du produit attrape les textes manquants, affichés en codes bruts. Et si tu compares des captures d'écran, génère-les toujours sur la même machine : le rendu du texte change d'une machine à l'autre.
Un raccourci sur le chemin testé est un mensonge
Le raccourci de signature mérite sa propre section. Il existait pour une bonne raison : la vraie signature est lente et dépend d'un service externe.
Mais un test de signature qui saute la signature ne teste pas la signature. Il teste que le raccourci marche. C'est un mensonge, bien rangé dans le code.
Et il cachait plus grave. Dans ce produit, la fin de signature déclenche un événement. Cet événement met à jour les états, envoie les notifications, ouvre le fil de discussion. Le raccourci ne déclenchait jamais cet événement. L'état qu'il fabriquait ressemblait au vrai, sans l'être.
La règle de réécriture : prépare les données par l'API pour aller vite, d'accord. Mais la chose testée, elle, n'est jamais simulée. Le test de signature signe pour de vrai, dans le vrai module, jusqu'au bout.
2026 : le plus dur n'est plus d'écrire le code, c'est de le vérifier
Pourquoi en parler maintenant ? Parce que le volume a changé de camp.
D'après l'enquête State of Code de Sonar, 42 % du code commité aujourd'hui est généré ou assisté par IA. 96 % des devs disent ne pas lui faire entièrement confiance. Et pourtant, moins d'un sur deux vérifie systématiquement ce code avant de le valider.
Les tests encaissent le choc. New Relic rapporte que 78 % des organisations voient plus d'incidents en production depuis l'arrivée du code généré. CodeRabbit mesure 1,7 fois plus de problèmes dans ce code, et 75 % d'erreurs de logique en plus.
Mes deux incidents racontent la même chose que ces chiffres. Le code s'écrit vite maintenant, les tests aussi. Une suite verte n'a jamais été aussi facile à produire. Et n'a jamais prouvé aussi peu.
La checklist pour tester ta suite de tests
Pose ces questions à ta CI verte. Chacune vient d'un incident réel.
- Le compte base de données du test a les droits de la prod, pas tous les droits
- Un test doit échouer sur la version cassée : vérifie-le au moins une fois
- Les parcours critiques sont vérifiés sur l'écran, pas sur la réponse du serveur
- Aucun raccourci sur le chemin que le test prétend couvrir
- Les données préparées par l'API déclenchent les mêmes événements que le vrai parcours
- Les tests « à corriger plus tard » sont comptés et visibles, pas oubliés
- Chaque écran est vérifié dans toutes les langues du produit
- Le code généré par IA passe les mêmes barrières que le tien, sans exception
Ce qu'il faut retenir
Une CI verte est une condition, pas une preuve. La question utile n'est pas « les tests passent-ils ? » mais « qu'est-ce qui casserait sans qu'ils le voient ? ».
Audite ta suite comme tu auditerais du code : cherche ce qu'elle ne regarde pas. Chez moi, la réponse était : le produit.
Tu veux un audit honnête de ta suite de tests, ou des barrières plus dures sur le code généré ? Parlons-en.