Déployer des tests automatisés dans une équipe existante

Déployer des tests automatisés dans une équipe projet existante non sensibilisée aux tests automatisés n’est pas qu'une question d’outillage. Si c’était le cas, les frameworks ne manquant pas, la documentation non plus et l’IA permettant désormais de produire des quantités considérables de tests rapidement : la problématique ne serait pas un sujet.

L’enjeu est avant tout méthodologique : comment introduire cette pratique de sorte à ce qu’elle fiabilise le produit sans pour autant ralentir une équipe qui livre déjà, avec son historique, ses urgences, ses zones de dette et ses contraintes de planning.

Lorsque l’on démarre un nouveau produit, la stratégie de tests est, si l’on fait les choses bien, posée dès le départ : types de tests, intégration dans la CI, cible quantitative de couverture, qui est responsable de la maintenance des tests. L'acculturation aux tests se fait en même temps que l'acculturation au projet en tant que tel. Dans une équipe existante, on arrive sur un système vivant. Le produit continue d’évoluer, les bugs continuent d’arriver, le cours du projet ne s’arrête pas pendant que l’on met en place “la bonne méthode”.

C’est pour cela que les approches théoriques échouent. Ce n'est pas en fixant un objectif de couverture, en demandant à tout le monde d’écrire plus de tests et en ajoutant une règle dans la "Definition of Done" que l'on créé culture de test. Si l'on procède de la sorte, en réalité, on a surtout ajouté une contrainte de plus à une équipe qui ne perçoit absolument pas ce qu’elle y gagne. La bonne approche consiste à mettre en place les tests automatisés de sorte à ce qu’ils créent immédiatement une valeur tangible pour l’équipe.

Partir des frictions plutôt que d’un objectif quantitatif

Le mauvais réflexe serait donc de fixer un objectif de couverture de code seul. Une base de code peut afficher une couverture correcte (ex. : 70 %) et rester fragile sur ses parcours critiques. À l’inverse, quelques tests bien placés peuvent apporter beaucoup de valeur si l’on protège les zones qui coûtent réellement cher quand elles cassent.

La première étape consiste donc à cartographier les risques concrets :

• les parcours métier dont la régression bloque une mise en production, c’est ce que nous appelons le sanity check ;
• les zones où les bugs reviennent régulièrement, les zones de fragilité ;
• les règles métier difficiles à vérifier manuellement qui font de bons candidats pour les tests unitaires et d’intégration ;

Cette cartographie n’a pas besoin d’être parfaite, elle doit surtout être partagée, notamment entre les développeurs qui savent pertinemment où le code est fragile et le produit qui sait quels parcours ne peuvent pas casser. L’objectif n’est donc pas quantitatif mais doit plutôt permettre de répondre à la question : de quelles régressions souhaitons-nous nous prémunir ?

Rédiger une stratégie de tests vivante

Une stratégie de test n’est pas un document que l’on écrit au kickoff puis que l’on archive ensuite. C’est un document vivant, qui peut être revisité et ajusté de la même manière qu’on ajuste une équipe. C’est un document qui doit être simple à rédiger et à comprendre. On peut se contenter de quelques décisions telles que : quels types de tests utilise-t-on, pour quels usages, à quel moment les lance-t-on, qui les maintient, et qu’est-ce qui bloque réellement un build. Par exemple, on peut décider que les tests unitaires servent à sécuriser les règles métier isolées, que les tests d’intégration protègent les contrats d’API, que les tests end-to-end ne couvrent que les parcours critiques et que les tests de régression visuels ne sont implémentés que lorsque la fonctionnalité est livrée en production.

La stratégie de test peut vivre dans un document Markdown embarqué dans le code source du projet, dans un document Confluence, dans une décision d’architecture (ADR) où l’on précisera au passage le tooling employé.

Automatiser ce qui est déjà livré pour fiabiliser

C’est sûrement l’une des manières les plus rentables d’introduire les tests automatisés dans une équipe existante. Comme indiqué précédemment, il faudra viser les zones les plus fragiles et critiques au quotidien.

L’objectif est ici de valider sur des inputs / outputs connus que la fonctionnalité se comporte comme attendu. Intégrer des tests de cette manière est souvent très simple et permet immédiatement de débloquer la capacité de l’équipe à faire évoluer le produit : soit pour corriger un bug, soit pour le refactorer de sorte à diminuer la dette technique, soit pour le faire évoluer.

Les tests n'ont pas besoin d'être exhaustifs : parfois un simple "smoke test" est suffisant : c'est à dire que la fonctionnalité, dans son état nominal, est OK.

Automatiser les corrections de bugs, grâce à l'IA

L’IA permet de produire des tests de non-régression de manière très rapide. Nous avons déployé à l’échelle de l’agence un skill très simple qui permet de corriger des bugs en suivant une approche TDD — Test Driven Development.

L’idée est simple : pour corriger un bug, on produit d’abord un test qui reproduit le bug. La résolution est actée par le test qui passe. On est alors d’une part capable de prouver la résolution et d’autre part capable de prévenir sa réapparition grâce à la non-régression mise en place. A l'usage ce skill se couple très naturellement avec des MCP capable d'interagir directement avec Sentry ou Jira.

Corriger les bugs de la sorte est une manière très efficace de prouver la plus-value générée par l'automatisation.

Éviter l’automatisation sur les parcours en cours de développement

Il pourrait être tentant de vouloir déployer les tests automatisés en les appliquant sur tous les nouveaux développements. C’est potentiellement piègeux et nous en parlons dans un article dédié : tests automatisés : ce qu’ils apportent vraiment et leurs limites.

En quelques mots : il faut éviter d’automatiser une fonctionnalité encore instable, par exemple une interface encore en cours d’élaboration, ou un parcours qui n’a pas encore été éprouvé par l’équipe produit. L’automatisation protège de la non-régression en forçant un comportement. Autrement dit : l’automatisation est un garde-fou contre l’évolution non désirée. Ce n’est pas ce que l’on souhaite sur quelque chose encore en cours de développement.

Le séquencement le plus sain pour une fonctionnalité en cours de développement ressemble à cela :

• on développe la fonctionnalité ;
• on valide manuellement ;
• on corrige les écarts remontés ;
• on automatise les critères importants ;
• on déploie éventuellement des tests de régression visuels si l’interface est stable.

Cette approche permet aux tests de rester utiles et de ne pas ralentir l’équipe.

La pyramide de tests n’est pas forcément la meilleure approche

En matière de tests, on recommande souvent d’élaborer sa stratégie en respectant ce que l’on appelle la pyramide de tests.

La pyramide de tests a le mérite de conceptualiser la stratégie de tests idéale mais ce n’est en rien une règle absolue. Il vaut mieux commencer par les zones qui cassent vraiment, qui ne sont d’ailleurs pas forcément les plus faciles à tester. En pratique, cela veut dire que les premiers tests seront souvent des tests d’intégration ou des tests de parcours, parce qu’ils protègent directement un usage observable. Les tests unitaires restent indispensables mais sur un existant cela peut prendre du temps avant d’apporter une valeur visible, car il ne sera pas simple de viser les zones qui unitairement sont les plus fragiles, les bugs les irritants provenant souvent d'interactions de modules entre eux.

L’IA sera un accélérateur à condition de ne pas prendre trop de raccourcis

Une suite de tests est du code. Elle a donc besoin d’une responsabilité claire et l'équipe technique doit absolument avoir de l'ownership dessus.

Si personne ne sait qui maintient les tests, ils se dégradent. L’objectif n’est certainement pas d’atteindre le millier de tests le plus rapidement possible, au risque d’avoir une intégration continue qui met plus de dizaines de minutes, voire des heures, à s'exécuter ! Avec des tests générés par IA sans relecture, on accumule vite des scénarios fragiles, des sélecteurs imprécis et des assertions qui ne protègent pas l’intention métier.

Lorsque je développe des fonctionnalités, j’aime faire itérer mes agents sur un plan pour qu’ils développent la fonctionnalité. Je les force à découper le travail en tâches et, pour chaque tâche, je leur demande comment sera testé automatiquement ce qui a été développé. C'est ce que je relis avec le plus d'attention. Je recommande donc de préciser dans les règles de votre IA (ex. : AGENTS.md) d’accompagner systématiquement les développements de tests, tout en préciser que l'agent doit toujours vérifier si des tests exisant doivent être mis à jour plutôt que d’en créer de nouveaux.

L’exécution des tests doit être rapide

Pour que les tests soient adoptés par une équipe technique, ils ne doivent pas être un frein. Nous avons comme principe chez Dernier Cri que nos batteries de tests doivent viser moins de 5 minutes d’exécution. Cela implique d’avoir une intégration continue correctement dimensionnée. Cela implique aussi d’avoir mis en place l’infrastructure nécessaire à la parallélisation des tests. Enfin, cela veut dire de faire attention à la quantité de tests embarqués, en particulier sur les parcours end-to-end qui peuvent, par nature, être très longs à éxécuter. La formule « Less is more » est tout à propos concernant les tests end-to-end.

Une adoption par la preuve

Déployer des tests automatisés dans une équipe existante, ce n’est pas imposer une culture de la qualité. C’est montrer, cas par cas, qu’ils débloquent le quotidien.

On commence par les frictions réelles — parcours bloquants, zones qui cassent sans cesse, règles métier difficiles à vérifier à la main — plutôt que par un pourcentage de couverture. On formalise une stratégie vivante : quels types de tests, pour quoi, à quel moment, qui les maintient. On automatise d’abord ce qui est déjà livré et stable, on sécurise chaque correction de bug par un test de non-régression, et on laisse de côté ce qui est encore en mouvement. La théorie du testing est un guide (i.e. la pyramide de tests) mais elle n’impose pas : sur un existant, les premiers gains viennent souvent des parcours critiques, pas des milliers de tests unitaires. L’IA, quant à elle, accélère, à condition de ne pas empiler du code de test sans propriétaire ni intention métier. Et la CI doit rester rapide — sinon les tests deviennent un frein, et l’équipe les contourne.

Une équipe n’adopte pas les tests parce qu’on lui explique qu’ils sont vertueux : elle les adopte quand elle constate qu’elle peut refactorer sans paniquer, corriger un bug sans le revoir trois sprints plus tard et faire évoluer le produit sans craindre de tout casser.