Le coût de la qualité logicielle a un défaut rédhibitoire en comité budgétaire : il est parfaitement visible, alors que le coût de la non-qualité ne l’est pas. C’est la raison pour laquelle la qualité est la première ligne coupée dès que les budgets se resserrent, et c’est la raison pour laquelle l’IA sert aujourd’hui d’argument commode à cette coupe. Les données disponibles disent pourtant l’inverse de ce que l’argument suppose.
Cet article prolonge le précédent, consacré à la gouvernance d’une stratégie de test. Celui-ci portait sur qui décide. Celui-ci porte sur ce qui se passe quand la décision est prise par le budget.
Une ligne visible en face d’un coût invisible
Un poste de qualité se chiffre sans difficulté : des jours de test, des licences, une plateforme d’intégration continue, du temps de recette métier. Il apparaît en clair dans un budget de projet, il est facilement isolable, et il ne produit aucune fonctionnalité que l’on puisse montrer en comité de pilotage.
En face, le coût de la non-qualité est diffus. Il se répartit entre l’exploitation qui absorbe des incidents, le support qui traite des tickets, les équipes projet qui refont ce qui a été livré, et le métier qui contourne. Aucune de ces lignes ne porte le nom de la décision qui les a produites. Personne, dans l’entreprise, n’est chargé de les additionner.
Une décision budgétaire se prend toujours sur ce qui est chiffrable, pas sur ce qui est important. C’est mécanique, ce n’est pas une faute de gestion, et c’est exactement pour cette raison qu’il faut construire le chiffre en face.
Le coût de la non-qualité est mesuré, et il est massif
Le Consortium for Information and Software Quality a produit l’estimation la plus large disponible. Dans son rapport publié le 6 décembre 2022, il évalue 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 manier avec précaution : il agrège des choses très différentes et repose sur des hypothèses discutables. Ce qui est instructif, c’est sa structure. La part la plus lourde n’est pas celle des incidents ni celle des projets échoués : c’est la dette, c’est-à-dire le coût permanent de travailler dans un système qu’on a dégradé.
Cette structure a une conséquence directe sur l’arbitrage budgétaire. Couper la qualité ne crée pas un incident visible le mois suivant, ce qui rend la coupe indolore à court terme et donne raison à celui qui l’a décidée. Elle crée une charge d’exploitation permanente qui apparaît douze à vingt-quatre mois plus tard, sur un autre budget, sous un autre nom, et souvent sous une autre direction.
C’est aussi ce qui rend la décision très difficile à corriger. Quand la charge finit par devenir visible, plus personne ne la relie à l’arbitrage qui l’a produite, et la réponse naturelle consiste à demander davantage de moyens d’exploitation. On finance donc la conséquence sans jamais rouvrir la cause, ce qui est la définition même d’une dette. Sortir de ce cercle suppose de chiffrer la dette technique pour obtenir son financement, avec un montant plutôt que des arguments techniques.
L’IA a remplacé l’externalisation comme argument de la coupe
Il y a dix ans, l’argument pour réduire le budget qualité était la délocalisation : le test étant réputé peu qualifié, il était le premier candidat au départ vers un plateau à bas coût. Le raisonnement était le même que celui que nous avons examiné à propos de l’infogérance offshore, avec les mêmes angles morts, et il a produit les mêmes effets différés. L’argument a changé, la coupe est la même. Aujourd’hui, on explique que l’outillage génératif va écrire les tests, détecter les anomalies et maintenir les suites, et qu’il n’est donc plus nécessaire d’y mettre autant de monde.
Cette promesse est plausible, elle est même partiellement en train de se réaliser. Le problème est qu’elle est utilisée pour justifier une réduction immédiate, alors que les gains, eux, sont différés et conditionnels.
Et surtout, elle repose sur un contresens : elle suppose que l’IA réduit le besoin de vérification, alors que tout indique qu’elle l’augmente.
Ce que les données disent de l’IA dans la chaîne de livraison
Le rapport le plus solide sur ce point est celui de DORA, publié en octobre 2024, auprès d’environ 3 000 professionnels du logiciel. Il mesure l’effet de l’adoption de l’IA sur la performance de livraison, et le résultat mérite d’être cité tel quel.
75,9 % des répondants utilisent l’IA pour au moins une partie de leur travail, et environ 75 % déclarent un gain de productivité individuelle. Jusque-là, la promesse tient.
Mais lorsque l’on mesure la performance du système de livraison plutôt que le ressenti individuel, une hausse de 25 % de l’adoption de l’IA est associée à une baisse estimée de 1,5 % du débit de livraison et surtout à une baisse estimée de 7,2 % de la stabilité de livraison. Elle est également associée à une réduction de 2,6 % du temps consacré à un travail jugé utile.
Ces chiffres sont modestes en valeur absolue et leur signe est ce qui compte. Ils décrivent une organisation qui produit plus vite du code dont elle est moins sûre. Le travail de vérification n’a pas disparu : il s’est déplacé en aval, vers la revue, la recette et l’exploitation, c’est-à-dire précisément vers les étapes que la coupe budgétaire vise.
Le paradoxe est complet. Chacun se sent plus productif, et le système livre moins bien. C’est une configuration classique en ingénierie, et c’est celle où les décisions de gestion se trompent le plus souvent, parce qu’elles s’appuient sur le ressenti des équipes plutôt que sur la mesure du flux.
En France, l’outillage n’est pas prêt à porter la promesse
Le World Quality Report 2024-25, publié par Capgemini et Sogeti en octobre 2024 auprès de 1 750 répondants dans 33 pays, donne la photographie française et elle est nette.
26 % des organisations françaises utilisent effectivement des solutions d’IA générative dans leurs processus de qualité. Les freins sont explicites : 60 % citent le risque de fuite de données comme préoccupation principale, et 58 % reconnaissent ne pas avoir de stratégie claire pour valider les solutions d’IA générative qu’elles mettent en place.
Ce dernier chiffre est le plus important de l’article, et il faut le lire lentement. Plus d’une organisation sur deux introduit dans sa chaîne de production un outil dont elle n’a pas défini comment elle vérifierait qu’il fait correctement son travail. Autrement dit, on demande à un outil non validé de valider le reste.
Rappelons par ailleurs que 48 % seulement des organisations ont déployé une stratégie d’automatisation des tests à l’échelle de l’entreprise. Une organisation qui n’a pas réussi à industrialiser une automatisation classique n’a aucune raison de réussir à industrialiser une automatisation générative, et beaucoup de raisons d’échouer plus vite.
Ce qui va réellement changer dans le métier du test
Rien de ce qui précède ne dit que l’IA ne changera pas le métier. Elle le change déjà, mais pas à l’endroit où les budgets l’anticipent.
Ce qu’elle absorbe bien : la production de premiers jets de tests unitaires, la génération de jeux de données, la rédaction de cas de test à partir d’une spécification, la maintenance de sélecteurs d’interface, la documentation. C’est-à-dire la partie laborieuse, celle qui occupait les profils les moins expérimentés.
Ce qu’elle n’absorbe pas : décider ce qui mérite d’être testé, arbitrer un risque métier, écrire le seuil d’acceptation d’une livraison, trouver l’angle mort de conception que personne n’a pensé à vérifier. Un test automatisé, généré ou non, ne vérifie que ce que quelqu’un a déjà pensé à vérifier.
La conséquence pour le métier est donc l’inverse d’une disparition : c’est une montée en exigence. Le besoin se déplace du testeur d’exécution vers l’ingénieur qualité capable de challenger un besoin métier et de tenir une position devant un comité qui veut livrer. C’est exactement le profil qu’une coupe budgétaire fait partir en premier, parce qu’il est le plus cher.
Il faut ajouter une difficulté que le secteur préfère ne pas regarder. Si l’outillage absorbe précisément le travail par lequel on formait les débutants, c’est-à-dire écrire des cas de test, exécuter des campagnes, éplucher des jeux de données, alors la question devient : d’où viendront les ingénieurs qualité expérimentés dans dix ans ? Un métier qui supprime ses postes d’entrée organise sa propre pénurie. Ce n’est pas un problème d’IA, c’est un problème de gestion des compétences, et il se traite en aménageant des parcours plutôt qu’en supprimant des lignes.
Et c’est là que se joue le vrai risque des trois prochaines années. Non pas que l’IA remplace les testeurs, mais que la promesse de l’IA serve à supprimer les postes qui rendaient l’IA utilisable.
Trois questions à poser à qui vous promet des gains par l’IA
La partie utile, et elle vaut aussi pour nous. Trois questions suffisent à séparer une promesse tenable d’un argumentaire, et aucune ne demande de compétence technique particulière.
Où se déplace le travail de vérification ? Un prestataire qui répond qu’il disparaît n’a pas lu les mesures disponibles. La bonne réponse décrit un déplacement : moins de temps à écrire des cas de test, plus de temps en revue et en validation, avec une estimation des deux.
Comment validez-vous ce que produit l’outil ? C’est la question qui trie le plus vite, puisque 58 % des organisations françaises reconnaissent ne pas avoir de réponse. Elle doit porter sur un dispositif écrit : qui relit, sur quel critère, et que fait-on d’un test généré qui passe alors qu’il ne devrait pas.
Sur quel indicateur mesure-t-on le gain, et à quelle échéance ? Si la réponse est un nombre de tests écrits ou un taux de couverture, le gain sera cosmétique. S’il s’agit du taux d’échec des changements et du délai de rétablissement mesurés à six et douze mois, la promesse est vérifiable, donc elle engage.
Ce que nous en tirons
Nous créons Voxalia avec une position qui nous fermera certaines portes : nous ne vendons pas de réduction d’effectif au titre de l’IA.
Ce que nous proposons à la place tient en trois choses.
Construire le chiffre manquant, d’abord. Mesurer chez le client le taux d’échec des changements, le délai de rétablissement et le taux de retravail, puis les convertir en jours-homme sur douze mois. L’exercice n’est ni long ni sophistiqué, et il suffit généralement à transformer un débat d’opinion en arbitrage documenté, parce qu’il pose enfin un montant en face de la ligne qu’on s’apprêtait à couper. Utiliser l’outillage génératif là où il travaille bien, sur les premiers jets et les jeux de données, en écrivant d’abord comment on valide ce qu’il produit, puisque plus d’une organisation sur deux ne l’a pas fait. Et concentrer l’humain sur la décision, l’arbitrage de risque et la recherche d’angles morts.
Nous démarrons, et nous n’avons donc aucun retour d’expérience à opposer à ces chiffres. 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. Ce que nous pouvons dire dès maintenant, c’est ce que nous refusons : promettre un gain de productivité par l’IA sans dire où le travail de vérification se déplace, et facturer une automatisation à une organisation qui n’a pas tranché qui décide de livrer chez elle.
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.
Questions fréquentes
Combien coûte la qualité logicielle, et combien coûte la non-qualité ?
Le coût de la qualité est directement chiffrable : jours de test, licences, plateforme d’intégration continue, temps de recette métier. Le coût de la non-qualité ne l’est pas, parce qu’il se répartit entre l’exploitation, le support, le retravail des équipes projet et les contournements du métier, sans qu’aucune de ces lignes ne porte le nom de la décision qui l’a produite. L’estimation la plus large disponible vient du Consortium for Information and Software Quality, qui évaluait en 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.
L’IA permet-elle de réduire le budget consacré aux tests ?
Les données disponibles invitent à la prudence. Le rapport DORA publié en octobre 2024, auprès d’environ 3 000 professionnels, associe une hausse de 25 % de l’adoption de l’IA à une baisse estimée de 1,5 % du débit de livraison et de 7,2 % de la stabilité de livraison, alors même que 75 % des répondants déclarent un gain de productivité individuelle. Le travail de vérification ne disparaît pas, il se déplace vers la revue, la recette et l’exploitation. Réduire le budget de test au moment où l’on introduit de l’IA revient donc à retirer des freins pendant que l’on accélère.
Quelles tâches de test l’IA prend-elle réellement en charge ?
Elle traite bien la partie laborieuse : premiers jets de tests unitaires, génération de jeux de données, rédaction de cas de test à partir d’une spécification, maintenance des sélecteurs d’interface, documentation. Elle ne prend pas en charge la décision de ce qui mérite d’être testé, l’arbitrage d’un risque métier, la définition du seuil d’acceptation d’une livraison, ni la recherche de l’angle mort de conception, puisqu’un test ne vérifie jamais que ce que quelqu’un a déjà pensé à vérifier. En France, selon le World Quality Report 2024-25, 26 % des organisations utilisent effectivement l’IA générative en qualité et 58 % reconnaissent ne pas avoir de stratégie claire pour valider ces solutions.
Sources
- DORA, Accelerate State of DevOps Report 2024, octobre 2024, environ 3 000 répondants, chiffres détaillés relayés par RedMonk le 26 novembre 2024 (75,9 % d’usage de l’IA, une hausse de 25 % de l’adoption associée à une baisse de 1,5 % du débit de livraison, de 7,2 % de la stabilité et de 2,6 % du temps consacré à un travail utile).
- 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, dont 1 520 milliards de dette technique).
- 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 (26 % d’usage effectif de l’IA générative en qualité en France, 60 % citant le risque de fuite de données, 58 % sans stratégie claire de validation, 48 % de stratégies d’automatisation déployées à l’échelle de l’entreprise).
