La plupart des équipes que nous rencontrons n’ont pas un problème d’outillage. Elles ont un problème de point de départ. Elles savent qu’il faudrait automatiser les tests, elles ont lu les mêmes articles que tout le monde sur la pyramide et l’intégration continue, et elles ne commencent jamais, parce que « tout est à faire » et qu’un sprint n’y suffira pas.
Je veux leur dire une chose simple : on ne rattrape pas dix ans de dette de tests en trois mois, et ce n’est pas le but. Le but d’une démarche de qualité logicielle est d’arrêter d’avoir peur de livrer. Cela se construit en quelques semaines, à condition de commencer au bon endroit.
Le symptôme : la mise en production fait peur
On reconnaît une équipe sans filet à un détail : le vendredi, personne ne déploie. Les mises en production sont regroupées, planifiées le soir, précédées de trois jours de recette manuelle et suivies d’une astreinte tendue. Chaque livraison est un événement, donc chaque livraison est rare, donc chaque livraison est grosse, donc chaque livraison est risquée. Le cercle est complet.
Les données confirment ce que le terrain montre. Le rapport DORA 2024, l’étude de référence sur la performance des équipes de livraison logicielle, décrit les équipes les plus performantes comme celles qui déploient à la demande, avec un délai de mise en production inférieur à une journée, un taux d’échec des changements autour de 5 % et une restauration en moins d’une heure. Surtout, il rappelle un résultat stable depuis dix ans : la fréquence de déploiement ne se paie pas en stabilité. Les équipes qui livrent souvent échouent moins souvent et se rétablissent plus vite.
Le même rapport apporte une nouvelle moins agréable : entre 2023 et 2024, la part des équipes dans le groupe le plus performant est passée de 31 % à 22 %, et celle du groupe le moins performant de 17 % à 25 %. Le milieu du peloton recule. Ne rien faire, ce n’est pas rester sur place.
Commencer par ce qui fait mal
Notre premier geste n’est jamais d’écrire un plan de tests. C’est de sortir la liste des cinq derniers incidents de production et d’écrire, pour chacun, le test qui l’aurait détecté. Ce travail prend quelques jours et il a trois vertus : il produit des tests utiles, il rend la démarche concrète pour une direction qui doute, et il montre à l’équipe qu’un test n’est pas une corvée théorique mais une réponse à une douleur qu’elle a vécue.
Le deuxième geste consiste à automatiser un seul parcours critique de bout en bout. Un seul, mais fiable. Sur un site marchand, c’est la commande. Sur un outil de gestion, c’est la saisie et la validation d’un dossier. Un test de bout en bout instable est pire que pas de test, parce qu’il apprend à l’équipe à ignorer le rouge.
Le troisième geste, souvent oublié, est de brancher ces quelques tests dans l’intégration continue avant d’en écrire d’autres. Un test qui ne tourne pas à chaque changement finit par ne plus tourner du tout.
Élargir sans dogme
La pyramide de tests est une boussole, pas une obligation. Sur un logiciel ancien sans tests unitaires, écrire des tests d’API rapporte plus vite que de tenter de découpler du code qui n’a jamais été conçu pour l’être. On y viendra, mais plus tard, à mesure que le code se transforme.
Ce qui compte, c’est la cadence : chaque semaine, un peu plus de couverture là où le risque est le plus élevé. Le rapport DORA 2024 a d’ailleurs ajouté une cinquième mesure à ses quatre indicateurs historiques, le taux de retravail, c’est-à-dire la part des déploiements non planifiés effectués pour corriger un bug vu par les utilisateurs. C’est, à mon avis, le meilleur indicateur pour piloter une démarche qualité naissante : s’il baisse, la démarche fonctionne, quel que soit le pourcentage de couverture affiché. Nous en parlons plus largement dans les KPI de projet qui dérangent.
Et l’IA dans tout ça ?
Le World Quality Report 2024-25, enquête menée par Capgemini, Sogeti et OpenText auprès de plus de 1 750 dirigeants dans 33 pays, indique que 68 % des organisations utilisent déjà l’IA générative dans leurs activités de qualité ou ont une feuille de route pour le faire, et que l’automatisation des tests est le domaine où son apport est le plus cité, avec 72 % de répondants qui constatent une accélération.
Je partage ce constat avec une réserve. L’IA écrit vite des tests. Elle ne sait pas lesquels comptent. Générer deux mille tests unitaires sur du code qui n’a jamais provoqué d’incident donne une couverture flatteuse et une confiance trompeuse. La valeur d’un test tient à la question qu’il pose, et cette question vient de quelqu’un qui connaît le métier, l’historique des pannes et les zones où l’équipe hésite. L’IA est un excellent stagiaire pour la qualité. Elle n’est pas le responsable qualité, et elle révèle surtout le niveau de ceux qui l’utilisent.
Le facteur humain
Une démarche qualité échoue rarement pour des raisons techniques. Elle échoue quand elle est vécue comme un contrôle imposé de l’extérieur. Nous insistons donc sur deux points. D’abord, les tests appartiennent à l’équipe qui développe, pas à une cellule à part qui valide en bout de chaîne. Ensuite, le rôle de testeur change : il ne s’agit plus de cliquer selon un cahier de recette mais de concevoir la stratégie, d’outiller, de former et d’analyser les échecs. C’est un métier d’ingénieur, et il mérite d’être reconnu comme tel.
Un test n’est pas une preuve que le logiciel marche. C’est une permission de le changer sans trembler.
Cédric Gérard, Directeur Associé
Trois mois, pas plus, pour la première marche
Notre pôle Qualité logicielle structure ces trois mois ainsi : quatre semaines pour les incidents passés et le parcours critique, quatre semaines pour l’intégration continue et le taux de retravail, quatre semaines pour élargir vers les tests d’API et former l’équipe à écrire ses propres tests. Au bout, l’équipe déploie le vendredi. Ce n’est pas une fin, c’est le moment où la démarche commence à s’auto-alimenter. Si vos mises en production font peur, parlons-en.
Questions fréquentes
Quels tests automatiser en premier ?
Ceux qui auraient détecté vos derniers incidents de production, puis un seul parcours critique de bout en bout, fiable et branché dans l’intégration continue. La couverture globale vient ensuite, là où le risque est le plus élevé.
Quel outil de tests automatisés choisir ?
Le choix de l’outil compte moins que la stratégie. Pour les parcours web de bout en bout, Playwright s’est imposé face à Selenium sur les nouveaux projets ; pour les API et les tests unitaires, l’outillage natif de votre langage suffit. Un outil bien intégré à l’intégration continue vaut mieux qu’un outil brillant que personne ne lance.
Combien de temps pour mettre en place des tests automatisés ?
Trois mois suffisent pour la première marche : incidents passés et parcours critique, intégration continue et taux de retravail, puis élargissement et formation de l’équipe. La démarche s’auto-alimente ensuite.
Sources
- DORA, Accelerate State of DevOps Report 2024 (profils de performance, taux de retravail).
- Capgemini, Sogeti et OpenText, World Quality Report 2024-25 (1 750 répondants, 33 pays, usage de l’IA générative en qualité).
