Une stratégie de test logiciel n’est ni une liste d’outils, ni un objectif de couverture, ni une pyramide dessinée dans un document que personne ne rouvre. C’est une réponse écrite à trois questions : qui décide de livrer, quel niveau de risque l’organisation accepte, et qui paie la dette quand on livre quand même. Tant que ces trois questions ne sont pas tranchées, aucun taux d’automatisation ne rattrapera quoi que ce soit.
Voxalia démarre, et c’est l’un des constats qui nous a décidés. En vingt ans de conception et de livraison de projets, je n’ai jamais vu un problème de qualité qui soit d’abord un problème d’outillage. J’ai vu des problèmes de décision, déguisés en problèmes d’outillage.
Ce qu’on appelle stratégie de test, et ce que c’en est vraiment
Ouvrez le document intitulé « stratégie de test » de n’importe quelle direction informatique. Vous y trouverez presque toujours les mêmes rubriques : les niveaux de test, les types de test, les environnements, l’outillage, parfois un objectif chiffré de couverture de code.
Tout cela est utile et rien de tout cela n’est une stratégie. Une stratégie est un ensemble de choix qui engagent, c’est-à-dire de choix qui excluent quelque chose. Décider qu’on teste à tous les niveaux avec tous les types de test n’exclut rien : c’est une déclaration d’intention.
Le test de vérité est simple. Demandez, dans une organisation donnée, qui a le pouvoir de bloquer une mise en production. Si la réponse est floue, ou si c’est la même personne que celle qui porte la date de livraison, la stratégie de test n’existe pas, quel que soit le contenu du document. Elle sera arbitrée à chaque fois par la pression du calendrier, et elle le sera dans le même sens.
Moins d’une organisation sur deux automatise à l’échelle
Le constat n’est pas anecdotique, il est mesuré. Dans le World Quality Report 2024-25 publié par Capgemini et Sogeti en octobre 2024, auprès de 1 750 répondants dans 33 pays, 48 % des organisations déclarent avoir déployé une stratégie d’automatisation des tests à l’échelle de l’entreprise et 42 % disposent d’un référentiel d’entreprise assorti de formations structurées.
Autrement dit, une majorité d’organisations automatise des tests sans stratégie d’entreprise pour le faire. Chaque équipe choisit son outil, écrit ses tests à sa main, et construit un actif qui ne survivra pas à son départ. C’est exactement le scénario dans lequel une direction informatique se retrouve, trois ans plus tard, avec quatre outils, deux mille tests dont personne ne connaît la couverture réelle, et une suite d’intégration continue que plus personne n’ose faire échouer.
Ce n’est pas un problème de maturité technique. C’est un problème de gouvernance : personne n’a arbitré, donc tout le monde a arbitré.
Le test fonctionnel est le seul endroit où le métier est présent
Il faut ici distinguer deux choses que le vocabulaire courant mélange.
Les tests techniques, unitaires et d’intégration, vérifient que le logiciel fait ce que le développeur a voulu. Ils sont rapides, stables, peu coûteux à maintenir, et ils s’automatisent bien parce qu’ils portent sur des objets écrits.
Le test fonctionnel vérifie autre chose : que le logiciel fait ce dont le métier a besoin. C’est le seul point de la chaîne où quelqu’un qui connaît le métier regarde le produit. Et c’est, précisément pour cette raison, le plus difficile à automatiser : il porte sur des intentions, il change quand le métier change, et il se casse pour de mauvaises raisons dès que l’interface bouge.
D’où une erreur extrêmement répandue. Beaucoup d’organisations, sous pression, automatisent massivement le test fonctionnel de bout en bout parce que c’est celui qui rassure les directions. Elles obtiennent une suite lente, fragile, qui échoue une fois sur cinq sans raison, que les équipes finissent par relancer sans lire, puis par désactiver. Le coût a été payé deux fois : à l’écriture, et à l’abandon.
Ce qu’on automatise, et ce qu’on n’automatise pas
L’arbitrage utile ne se fait pas par niveau de test, il se fait par croisement de trois critères, et il tient en une phrase : on automatise ce qui est stable, fréquent et coûteux à rater.
Stable, parce qu’un test qui change à chaque sprint coûte plus cher à maintenir qu’il ne rapporte. Fréquent, parce que la valeur d’un test automatisé est proportionnelle au nombre de fois où il tourne. Coûteux à rater, parce que c’est le seul critère qui relie l’effort de test au risque réel de l’entreprise.
Ce que cela donne concrètement : le parcours de commande d’un site marchand est stable, fréquent et coûteux à rater, il s’automatise en priorité. L’écran d’administration utilisé deux fois par an par trois personnes est fréquent en apparence, rare en réalité et peu coûteux à rater, il reste en test manuel. La règle de calcul d’un tarif est stable, fréquente et très coûteuse à rater, elle se teste au niveau technique et pas au travers de l’interface.
Ce qui reste en manuel n’est pas un aveu d’échec. C’est un choix, et un choix assumé vaut mieux qu’une automatisation qu’on abandonnera dans dix-huit mois.
Il faut d’ailleurs réhabiliter une pratique que la mode a rendue honteuse : le test exploratoire, c’est-à-dire un humain compétent qui utilise le produit avec l’intention de le casser. Aucune suite automatisée ne trouve ce qu’un testeur expérimenté trouve en deux heures sur une fonctionnalité nouvelle, pour une raison simple : un test automatisé ne peut vérifier que ce que quelqu’un a déjà pensé à vérifier. Il protège contre la régression, jamais contre l’angle mort de conception.
La gouvernance de la qualité tient en trois décisions écrites
Voici la partie que je défends en priorité chez un client, avant tout sujet d’outillage.
Qui décide de livrer. Le pouvoir de bloquer une mise en production doit appartenir à quelqu’un qui ne porte pas la date. Peu importe le titre, ce qui compte est l’indépendance du critère. Sans cela, la décision est structurellement biaisée, et aucune quantité de tests n’y changera rien.
Quel niveau de risque est accepté. Écrire noir sur blanc ce qu’on accepte de livrer avec des anomalies connues, par criticité et par périmètre. Une organisation qui n’a pas écrit ce seuil le redéfinit implicitement à chaque livraison, en fonction de l’humeur du moment et de la proximité de la date.
Qui paie la dette. Une anomalie contournée en production est une dette contractée par le projet et remboursée par l’exploitation. Tant que ce transfert n’est pas visible dans un budget, le projet aura toujours intérêt à livrer et l’exploitation à souffrir en silence.
Ces trois décisions ne coûtent rien à prendre. Elles coûtent seulement du courage, parce qu’elles nomment des arbitrages que l’organisation préfère laisser implicites.
Les indicateurs qui disent la vérité
Une gouvernance sans mesure est une intention. Trois indicateurs suffisent, et aucun n’est un taux de couverture.
Le taux d’échec des changements, c’est-à-dire la proportion de mises en production qui provoquent une dégradation nécessitant une correction. C’est la mesure directe de la qualité de la décision de livrer.
Le délai de rétablissement, qui mesure la capacité à réparer plutôt que celle à ne jamais casser. Une organisation qui répare en une heure peut se permettre un niveau de risque qu’une organisation qui répare en trois jours ne peut pas se permettre.
Le taux de retravail, introduit par DORA dans son rapport 2024 sur l’état du DevOps : la part du travail consacrée à refaire ce qui a déjà été livré. C’est le plus inconfortable des trois, parce qu’il ne mesure pas un incident mais une usure, et parce qu’il révèle exactement ce qu’une pression sur la qualité produit six mois plus tard.
Le taux de couverture de code, lui, ne dit rien sur le risque. On peut couvrir 90 % d’un code sans tester une seule règle métier importante.
Ce que coûte l’absence de gouvernance
Le chiffre le plus large disponible vient du Consortium for Information and Software Quality, qui estimait dans son rapport publié le 6 décembre 2022 le coût de la mauvaise qualité logicielle aux États-Unis à 2 410 milliards de dollars, dont 1 520 milliards de dette technique accumulée. Cet ordre de grandeur est macroéconomique et il faut le prendre pour ce qu’il est, mais sa structure est parlante : la dette pèse davantage que les incidents.
À l’échelle d’un projet, les chiffres sont anciens et remarquablement stables. Le Standish Group mesurait en 2015 un taux de réussite de 61 % sur les petits projets, 12 % sur les projets moyens et 6 % sur les grands. McKinsey et l’université d’Oxford, sur plus de 5 400 projets étudiés en 2012, relevaient un dépassement moyen de 45 % du budget et une valeur livrée inférieure de 56 % à celle attendue. Le Project Management Institute situait en 2021 à 62 % la part des projets tenant leur budget.
Que ces chiffres n’aient pas fondamentalement bougé en dix ans, alors que l’outillage a été transformé, dit quelque chose de précis : le problème n’est pas là où l’on met l’argent.
Un dernier symptôme, et il est administratif. La Cour des comptes, dans son rapport de juillet 2023 sur le recours de l’État aux prestations intellectuelles, relève l’absence quasi systématique d’évaluation après la mission. Cette faiblesse se retrouve presque telle quelle dans le privé, et elle a un effet direct sur la qualité : une livraison qui n’est jamais évaluée après coup ne peut nourrir aucune décision suivante. On reconduit le prestataire, la méthode et le seuil de risque sur la base d’une relation commerciale plutôt que d’un résultat mesuré, et le cycle recommence à l’identique.
Il faut aussi voir la suite de tests pour ce qu’elle est : un actif, au même titre que le code. Un actif qui n’est ni documenté ni transférable disparaît avec l’équipe qui l’a écrit, et une direction informatique qui change de prestataire découvre alors que deux mille tests sont devenus illisibles. C’est le même problème que celui de la réversibilité d’une prestation, appliqué à la qualité.
Ce que nous en tirons
Nous créons Voxalia avec une position simple sur ce sujet : nous refusons les missions de qualité logicielle formulées comme des missions d’outillage.
Quand un client nous demande de mettre en place une automatisation, la première chose que nous cherchons à savoir est qui décide de livrer chez lui, et si ce quelqu’un porte la date. Si la réponse est mauvaise, l’automatisation produira des tests que personne ne regardera, et nous aurons facturé une prestation inutile. Le dire avant de signer nous coûte des affaires. Le découvrir au sixième mois coûterait bien plus cher au client.
Concrètement, cela veut dire commencer par écrire les trois décisions, poser trois indicateurs et pas quinze, automatiser d’abord ce qui est stable, fréquent et coûteux à rater, et assumer ce qui restera manuel. Cela veut dire aussi que le consultant qui installe ce dispositif reste sur son périmètre : une gouvernance de la qualité qui change de porteur tous les six mois n’est pas une gouvernance, et ce risque de rotation est un coût que le client supporte seul.
Nous démarrons, et nous n’avons donc aucune réalisation à mettre en face de ces principes. Je préfère l’écrire ainsi plutôt que d’illustrer un propos avec des cas que nous n’avons pas encore livrés. Vous pouvez lire qui nous sommes et d’où nous venons et ce que nous faisons en qualité logicielle avant de nous accorder le moindre crédit.
Reste une question que cet article ne tranche pas, et qui va devenir la plus difficile : que devient cette gouvernance quand les budgets se resserrent et que l’IA promet de tester à notre place ? C’est le sujet de l’article suivant.
Questions fréquentes
Qu’est-ce qu’une stratégie de test logiciel ?
Ce n’est pas la liste des niveaux, des types de test et des outils, qui relève du plan de test. Une stratégie de test répond à trois questions de gouvernance : qui a le pouvoir de bloquer une mise en production, quel niveau de risque l’organisation accepte de livrer par criticité et par périmètre, et sur quel budget est remboursée la dette créée quand on livre malgré des anomalies connues. Un document qui ne tranche pas ces trois points n’engage personne et sera arbitré à chaque livraison par la pression du calendrier.
Quels tests faut-il automatiser en priorité ?
Ceux qui réunissent trois critères : stable, fréquent et coûteux à rater. Stable, parce qu’un test qui change à chaque sprint coûte plus cher à maintenir qu’il ne rapporte. Fréquent, parce que la valeur d’un test automatisé est proportionnelle au nombre de ses exécutions. Coûteux à rater, parce que c’est le seul critère qui relie l’effort de test au risque réel de l’entreprise. Un écran utilisé deux fois par an ne remplit pas ces critères et gagne à rester en test manuel, ce qui est un choix et non un échec.
Le taux de couverture de code est-il un bon indicateur de qualité ?
Non, parce qu’il mesure la proportion de code exécutée par les tests et non le risque couvert. Il est possible de couvrir 90 % d’un code sans vérifier une seule règle métier importante. Trois indicateurs disent bien plus : le taux d’échec des changements, qui mesure la qualité de la décision de livrer ; le délai de rétablissement, qui mesure la capacité à réparer ; et le taux de retravail, introduit par DORA dans son rapport 2024, qui mesure la part du travail consacrée à refaire ce qui a déjà été livré.
Sources
- Capgemini, Sogeti et OpenText, World Quality Report 2024-25, octobre 2024, 1 750 répondants dans 33 pays, zoom sur le marché français par Sogeti (48 % de stratégies d’automatisation déployées à l’échelle de l’entreprise, 42 % de référentiels d’entreprise avec formations structurées).
- DORA, Accelerate State of DevOps Report 2024, octobre 2024 (introduction du taux de retravail parmi les indicateurs de performance, taux d’échec des changements, délai de rétablissement).
- Consortium for Information and Software Quality, The Cost of Poor Software Quality in the US: A 2022 Report, 6 décembre 2022, auteur Herb Krasner (2 410 milliards de dollars de coût total, dont 1 520 milliards de dette technique accumulée).
- Cour des comptes, Le recours par l’État aux prestations intellectuelles de cabinets de conseil, 10 juillet 2023 (absence quasi systématique d’évaluation après la mission).
- The Standish Group, CHAOS Report 2015, 2015 (taux de réussite et d’échec par taille de projet).
- McKinsey et université d’Oxford, Delivering large-scale IT projects on time, on budget, and on value, octobre 2012 (plus de 5 400 projets, dépassement de 45 % du budget, valeur inférieure de 56 %).
- Project Management Institute, Pulse of the Profession 2021, 2021 (62 % des projets dans le budget, 55 % dans les délais).
