Avec un agent IA, écrire du code ne coûte presque plus rien. Ce qui coûte, c'est de savoir si ce code est juste. Les tests sont ce qui me permet de répondre vite et sans me raconter d'histoires : un agent peut produire en une heure ce qui me prenait une journée, mais sans tests, je ne fais que déplacer le travail vers la relecture, et les bugs vers mes clients.
La pyramide des tests, version IA
- À la base, les tests unitaires vérifient les règles métier, isolées du reste. Ils tournent en millisecondes : je peux les relancer après chaque modification de l'agent. C'est ici que l'architecture hexagonale paie, car le métier se teste sans base de données.
- Au milieu, les tests d'intégration vérifient que les briques se parlent : une route d'API, une requête en base, un appel à un service externe simulé.
- Au sommet, les tests end-to-end pilotent un vrai navigateur avec Playwright, comme le ferait un utilisateur. Peu nombreux, lents, mais ce sont les seuls qui voient ce que voit un client.
≈ 2 170
tests PHP sur Le Limier
38
scénarios end-to-end Playwright
1 893
tests PHP sur PostOwl
≈ 1 100
tests front sur PostOwl
Le contrat que je donne aux agents qui écrivent des tests
Un agent à qui l'on demande « fais passer les tests » a deux façons d'y arriver : corriger le code, ou affaiblir le test. Et un agent à qui l'on demande « augmente la couverture » peut être tenté de retoucher le code de production pour le rendre plus facile à tester. Ma méthode de maintenance pose donc une règle sans exception pour ces agents :
Hard constraint for every agent: NEVER modify app/. Only test files.
The agent's contract is "the production code is the source of truth".Même logique pour les tests end-to-end, avec des règles d'écriture non négociables, dont :
- Préparer par l'API, vérifier par l'interface. On crée les données de départ par un appel direct, puis on vérifie à l'écran. Plus fiable que de traverser six écrans pour arriver au bon état.
- Pas de test désactivé en silence. Un test ignoré doit dire pourquoi.
- Ne jamais contourner une protection pour faire passer un test. Si la limite de connexions bloque la suite, on corrige la cause, on ne désactive pas la limite.
PostOwl : de 123 tests rouges à zéro
En mai 2026, j'ai mené une session de maintenance sur PostOwl. Point de départ : 1 117 tests backend passants sur 1 240. Je l'ai découpée en phases (réparer, mesurer, couvrir, auditer, refactorer), avec jusqu'à dix agents en parallèle, chacun dans sa propre copie du dépôt.
| Avant | Après | |
|---|---|---|
| Tests backend passants | 1 117 / 1 240 | 1 755 / 1 755 |
| Tests frontend passants | 339 / 347 | 1 021 / 1 021 |
| Couverture du code backend | 82 % | 98 % |
Vingt-six commits, aucune régression. Les détails de l'organisation des agents sont dans l'article sur mes agents et skills.
« Tout est vert » ne veut pas dire « ça marche »
C'est la leçon qui m'a le plus marqué. Sur Le Limier, une session de maintenance s'était terminée sur un tableau parfait : suite verte, zéro erreur d'analyse statique. Un mois plus tard, en ouvrant l'application dans un navigateur, voici ce que j'ai trouvé :
Ce que mesuraient les outils
- Suite PHPUnit au vert
- PHPStan niveau 8 : zéro erreur
- Lint propre
Ce que voyait un utilisateur
- Chaque formulaire renvoie 419 après connexion
- Page blanche avec un bloqueur de pub
- L'inscription ne redirige nulle part
- Le mot de passe écrit en clair dans les logs
Aucun de ces défauts n'était visible pour les tests unitaires, l'analyse statique ou le linter : ils ne font jamais tourner le produit comme le fait un utilisateur. Depuis, ma méthode de maintenance commence par une règle écrite en toutes lettres, « Green is not working », et par un passage obligé dans un vrai navigateur.
Le Limier a aussi gagné un test particulier, que j'appelle le test « bus factor » : un parcours complet d'un nouvel utilisateur, dans un navigateur vierge, de l'inscription jusqu'au premier prospect enregistré. S'il passe, quelqu'un qui reprend le projet sait que la chaîne qui fait la valeur du produit tient debout. Les instructions du projet demandent à l'IA de le lancer en premier. Je détaille sa construction dans l'article sur les tests end-to-end.
npx playwright test parcours-nouvel-utilisateurLes bugs qu'aucun test n'attrape
Dernière humilité : sur Le Limier, neuf défauts réels ont été trouvés en production ou en préparation, et aucun n'était détectable par un test classique. Quelques exemples :
- un analyseur des annonces du BODACC qui corrompait 5,5 % des noms de dirigeants, sur des formats que les jeux de test ne contenaient pas ;
- une sonde de santé qui mettait 10,8 secondes à répondre, parce qu'elle comptait 2,6 millions de lignes à chaque appel ;
- une migration interrompue au bout de dix minutes, sur une table de 37,9 millions de lignes.
Tous venaient de la confrontation avec le volume et les données réelles. La conclusion que j'en tire : mesurer le réel (temps de réponse, échantillons de vraies données, surveillance) avant d'empiler des tests synthétiques supplémentaires.
Ce que ça change pour vous
Un logiciel livré avec ses tests, c'est un logiciel que l'on peut modifier dans six mois sans trembler, que ce soit moi, un autre développeur ou un agent IA. C'est aussi la condition pour que la spec que vous avez validée reste vraie dans la durée. Le détail de l'approche est sur la page méthode.
