Chaque framework DevOps cite le Continuous Testing comme un must-have. Chaque conférence en fait un objectif de maturité. Et pourtant, quand on regarde les chiffres réels, on est loin du compte.
Voici ce que la World Quality Report 2025-26 nous dit : 71% des organisations déclarent avoir une stratégie de “Continuous Testing” dans leurs pipelines. Mais quand on creuse, seulement 14% testent réellement à chaque commit, sur tous leurs pipelines.
Le reste ? Des tests qui tournent une fois par jour. Des suites réservées au sprint de release. Des pipelines “continuous” qui s’exécutent deux fois par semaine.
Ce n’est pas du Continuous Testing. C’est du testing avec des bonnes intentions.
Je travaille depuis cinq ans avec des équipes QA et Engineering en France, en Europe et au-delà. La question “est-ce qu’on fait du Continuous Testing ?” revient constamment dans les conversations de direction. Et la réponse est presque toujours la même : “oui, on est en train de le mettre en place.”
Ce “en train de” peut durer trois ans.
Pas parce que les équipes manquent de volonté. Mais parce que le Continuous Testing tel qu’il est vendu — chaque commit déclenche chaque test, la qualité est validée en temps réel, personne ne déploie en production sans gate complet — est un état idéal qui nécessite une maturité organisationnelle, technique et culturelle que la plupart des équipes n’ont pas encore.
Et c’est correct.
Le problème n’est pas de vouloir atteindre le Continuous Testing. Le problème est de le présenter comme un état binaire : soit vous le faites, soit vous ne le faites pas.
Cette vision binaire génère deux comportements contre-productifs.
Le premier : l’équipe déclare faire du Continuous Testing alors qu’elle fait du periodic testing parce que c’est ce que le management veut entendre. Les vrais problèmes restent invisibles.
Le second : l’équipe sait qu’elle n’y est pas, se sent en échec par rapport à un standard mal défini, et n’ose pas mesurer sérieusement sa situation actuelle — parce que les chiffres seraient embarrassants.
Dans les deux cas, on perd les bénéfices de la mesure.
Ce que j’observe chez les équipes qui progressent réellement, c’est différent.
Elles ne partent pas de “comment faire du Continuous Testing”. Elles partent de “qu’est-ce qui nous empêche d’aller plus vite sans casser la production ?”. Et la réponse à cette question — quand on la mesure honnêtement — révèle des priorités très concrètes.
Suite trop lente à exécuter. Taux de flakiness trop élevé. Trop de temps passé à maintenir des tests qui ne testent rien d’utile. Absence de priorisation des tests selon le risque.
Ces problèmes se résolvent un par un. Et à chaque résolution, l’équipe se rapproche un peu plus d’un testing vraiment continu — pas parce qu’elle a déployé un framework de plus, mais parce qu’elle a éliminé les frictions qui rendaient la fréquence impossible.
Avec Automate Score©, on mesure précisément ce gap. La dimension Fréquence nous dit combien de fois par semaine vos tests s’exécutent réellement. La dimension Stabilité dit si ces tests sont fiables enough pour être utilisés comme gate. La dimension Durée dit si le feedback est assez rapide pour ne pas bloquer les développeurs.
Ces trois métriques combinées vous disent où vous en êtes sur le continuum du Continuous Testing — pas avec une étiquette, mais avec des chiffres.
Et les chiffres permettent d’agir.
Alors, le Continuous Testing est-il un graal ou une illusion ?
Ni l’un ni l’autre. C’est une direction.
Une direction qui ne demande pas de tout changer en même temps. Qui admet que faire tourner vos tests critiques 14 fois par semaine est déjà une amélioration majeure par rapport à une fois par sprint. Qui reconnaît que passer de 60% à 90% de stabilité sur votre suite est une victoire concrète, mesurable, et dont l’impact sur la confiance de l’équipe est immédiat.
Le problème des équipes qui n’avancent pas, ce n’est pas qu’elles manquent d’ambition. C’est qu’elles poursuivent un idéal sans mesurer leur progression réelle.
Mesurez d’abord. Vous verrez exactement où agir.
Et vous — votre suite tourne combien de fois par semaine en réalité ? Je suis curieux d’avoir vos retours en commentaires.
Je suis Reda Ennasr, CEO & Cofondateur d’In Value. Ces 5 dernières années, j’ai recruté et accompagné plus d’une centaine d’ingénieurs en Automatisation des tests. Ma mission : Transformer l’automatisation en avantage compétitif. Éditeur de la plateforme Automate Score© : l’IA qui mesure et optimise la performance de l’automatisation des tests.