🦉
Le Veilleur

AI Makes Software Quality A Board Conversation. Are You Ready For It?

Auteurs
vinvashishta.substack.com, Vin Vashishta
Thème
Leadership
Mots-clés
qualité logicielle, gouvernance, board, traduction business, testing continu
Ton
opinion

Résumé

La qualité logicielle devient une préoccupation de conseil d'administration, comme la cybersécurité avant elle. Le problème : les leaders techniques ne savent pas traduire cette valeur dans un langage que le board peut actionner, ce que prouve un écart de 23 points entre dirigeants (93 % confiants) et praticiens (70 %) sur la couverture des risques par la stratégie de test. Vin Vashishta décrit la structure de cette traduction — parler à la fois au "décideur opportunité" et au "décideur risque" — et illustre avec la plateforme Tricentis comment recadrer la qualité d'un coût d'outillage vers une couche de gouvernance que le board est tenu de financer.

💡 Pourquoi ça compte

C'est le maillon manquant entre technique et direction : la qualité IA n'obtiendra un budget que si les leaders techniques savent la recadrer comme gouvernance, pas comme outillage. Une compétence de traduction cruciale pour tout responsable engineering.

Analyse approfondie

Vous comprenez pourquoi la technologie crée de la valeur. Les gens qui contrôlent le budget ont besoin que vous reliiez cela à quelque chose qui les intéresse et qu'ils comprennent ; soit une opportunité, soit un risque assez grand pour capter leur attention. C'est cette traduction qui crée l'influence en comité de direction, mais peu de leaders techniques ont appris à la faire.

Dans cet article, je m'associe à Tricentis pour expliquer comment traduire un besoin émergent dans le langage et le cadrage qui ouvrent les portefeuilles et obtiennent l'adhésion du C-level.

La phrase la plus importante du Rapport Tricentis 2026 sur la transformation de la qualité est sa dernière : la qualité logicielle devient une préoccupation de conseil d'administration, comme la cybersécurité avant elle.

Mais votre C-suite et votre board le comprennent-ils ? Cela devrait être évident. L'outillage IA fait du développement un processus continu. Les outils IA créent de nouveaux risques qualité et amplifient les risques existants. Les entreprises ont besoin d'une nouvelle approche de la qualité qui leur permette de s'adapter et de récolter les bénéfices des outils de code IA sans en subir les risques.

Plus de changements sont intégrés plus souvent. Plus de code est généré par IA, et des processus de validation purement humains menacent d'annuler les gains de productivité. La solution : tests automatisés continus, détection d'anomalies et escalade.

L'obstacle à cette conclusion pourtant évidente, c'est que ceux qui devraient porter la qualité jusqu'au board ne savent pas encore la décrire dans un langage sur lequel le board peut agir. Il y a un chiffre dans les données qui le prouve.

93 % des répondants C-level sont convaincus que leur stratégie de test couvre les risques les plus critiques pour l'entreprise. Seuls 70 % des praticiens sont d'accord. Cet écart de 23 points, c'est une population de dirigeants confiants dans une stratégie, alors que ceux qui en sont le plus proches ne le sont pas. Ils valident quelque chose qui met leurs propres experts mal à l'aise.

42 % des dirigeants C-level croient que leurs développeurs et cadres sont pleinement alignés sur ce qu'est un bon logiciel. Parmi les leaders QA et DevOps, seuls 22 % sont d'accord. La plupart des dirigeants confiants ont un écart qu'ils ne voient pas. Ils sont rassurés par un alignement qui n'existe pas.

Il est facile d'obtenir de la visibilité et l'approbation d'outils IA. Ils sont en tête des préoccupations, et les éditeurs ont fait un excellent travail pour relier adoption et création de valeur. Mais les outils de développement IA changent fondamentalement le cycle de vie du développement. Ces changements en amont exigent de nouveaux outils pour soutenir un nouveau type de cycle d'assurance qualité.

Ceux-là sont bien plus difficiles à budgéter, et la cause racine est la même que celle de l'écart de 23 points.

Les leaders techniques comprennent comment la technologie crée de la valeur. Cette fluidité est ce qui nous rend tous mauvais pour l'expliquer. Nous voyons toute la chaîne causale, de la meilleure sélection de tests aux moindres défauts échappés et au taux d'échec réduit. Alors nous supposons que la valeur est évidente, mais hors de la bulle tech, elle ne l'est pas.

Chacun qui contrôle un budget a besoin que vous reliiez cette chaîne à quelque chose qui l'intéresse déjà, et "la suite de régression est plus résiliente" n'est pas sur la liste. La grande révélation, c'est que toute technologie ne se vend pas d'elle-même. Soit nous la traduisons, soit elle meurt en comité.

Il y a une structure à la traduction, parce qu'il y a une structure à la pièce. Dans toute vraie conversation de financement, il y a deux types de décideurs, souvent à la même table.

Le décideur opportunité mène avec le potentiel de hausse : croissance, vitesse, position de marché. C'est le CEO, le CRO, souvent le head of product.

Le décideur risque mène avec le potentiel de baisse : perte, exposition, conformité, ou ce qui finit sur le pont d'incident ou devant un régulateur. C'est votre CFO, votre CISO, vos gens de l'audit et du risque board.

Une capacité n'est financée que lorsque vous savez parler aux deux. Menez avec l'opportunité face à un décideur risque, et vous paraissez imprudent. Menez avec le risque face à un décideur opportunité, et vous paraissez être un frein. Chaque traduction a 3 parties : (1) ce que fait la technologie ; (2) la conséquence ou l'impact business ; (3) comment expliquer cette conséquence à chaque décideur.

Faisons passer la plateforme Tricentis dans cette grille, parce que c'est un bon exemple d'investissement qualité conçu pour survivre à cette conversation.

Chaque discipline qui grimpe jusqu'au board arrive en portant un objet reconnaissable. La cybersécurité n'a pas été élevée sur un message de "plus d'outils de sécurité". Elle a été élevée autour d'un control plane ou d'un "single pane of glass", de l'audit trail, et du monitoring continu. Ce sont les choses qu'un CISO pouvait mettre sur une slide en disant "voilà comment nous savons". La qualité a besoin du même genre d'objets, et c'est le centre du design de Tricentis.

Ce que ça fait. La plateforme est organisée autour d'un AI Workspace que Tricentis appelle un control plane et un système d'enregistrement pour l'ingénierie qualité agentique. Il coordonne les agents IA qui font le vrai travail de qualité, détient un contexte partagé à travers environ 200 systèmes d'entreprise, se connecte aux outils déjà utilisés (Jira, GitHub, Tosca, qTest), et intègre gouvernance, approbations et une piste de décision auditable directement dans la façon dont les releases se font, avec des humains gardés dans la boucle pour les jugements.

La conséquence business. C'est, pour la première fois, un système d'enregistrement des décisions de release. On peut prouver après coup pourquoi quelque chose a été expédié, et arrêter quelque chose avant. La qualité cesse d'être un point de contrôle bricolé à la fin pour devenir une couche gouvernée et continue.

Comment le dire. Au décideur opportunité : "Voilà comment nous releasons à la vitesse de l'IA sans grossir l'équipe QA au même rythme." Au décideur risque : "Voilà notre control plane auditable pour les releases autonomes. Quand le board ou un régulateur demande comment nous gouvernons le code généré par IA, voici la réponse documentée et prouvable."

Ce que ça fait (suite). L'Agentic Quality Intelligence lit en continu les signaux de changement et de risque à travers le cycle de vie, décide ce qui mérite vraiment d'être testé, juge la maturité de la release et n'escalade vers un humain que lorsque le jugement est réellement requis. C'est le moteur qui bloque les changements non testés et ne lance que les tests que le changement exige. On passe de la force brute à une sélection basée sur le risque.

La conséquence business. On arrête de tout tester pour tester ce qui compte, le levier rare qui rend plus rapide et plus sûr dans le même mouvement. C'est la forme opérationnelle de ce que défend le CEO de Tricentis, Kevin Thompson : vous n'avez pas besoin de tout tester, vous avez besoin de comprendre les changements, leur impact et où se situe vraiment le risque.

Autres capacités. L'Agentic Test Creation, dans qTest, transforme des exigences en langage naturel en cas de test réutilisables, si bien que générer de la couverture ne dépend plus d'une expertise spécialiste rare. L'Agentic Test Automation exécute et maintient ces tests via les moteurs Tosca à travers SAP, web et applications custom. La conséquence : la couverture passe désormais à l'échelle avec le code généré par IA sans hausse correspondante des coûts ou des effectifs. Le goulot qui plafonnait le dividende de productivité de l'IA est levé. Enfin, l'Agentic Performance Testing place des agents autonomes sur l'analyse, la conception et l'exécution des tests de performance et de charge, accélérant le time-to-insight de 90 à 95 % par rapport au travail manuel d'experts, et trouvant le défaut de classe "panne" dans le pipeline plutôt qu'en production.

Enfilez ces quatre capacités à travers le control plane, et quelque chose change dans la catégorie où vit la dépense — et la catégorie, c'est tout pour celui qui signe le chèque.

Présentez cette pile comme "plus d'outillage" (une plateforme de test, de la couverture d'automatisation, de la gestion QA), et elle atterrit comme un coût. Là, elle concurrence tout autre outil, benchmarkée au prix par siège. Les frais généraux, c'est ce qu'un board cherche à couper.

Présentez la même pile comme la couche de gouvernance des décisions de release à l'échelle de l'IA et le système d'enregistrement qui permet à l'entreprise d'avancer à la vitesse machine sans devenir aveugle à son exposition au risque. Elle atterrit à côté de la pile sécurité, de la fonction audit et des contrôles qu'un board est tenu de financer. La gouvernance, c'est ce dont un board est responsable.

C'est le voyage que la cybersécurité a déjà fait. Il y a dix ans, c'était une ligne budgétaire IT qu'on finançait à contrecœur jusqu'à ce que les brèches soient chiffrées, que les régulateurs arrivent, que la confiance client ait un prix, et que la sécurité monte les marches jusqu'au board avec son propre comité et sa propre logique budgétaire.

Les données financières font maintenant la même chose à la qualité. 1 entreprise sur 5 perd jusqu'à 5 millions de dollars par an à cause d'une mauvaise qualité logicielle. 45 % perdent entre 500 000 et un million. 40 % des grandes entreprises se situent dans la tranche 1 à 5 millions. Ce sont les métriques partageables pour démarrer la conversation avec le C-level et le board.

Au moment où la mauvaise qualité a un chiffre en dollars et une ligne "confiance client", elle cesse d'être une métrique d'ingénierie et devient une catégorie de risque d'entreprise. C'est important parce que le risque d'entreprise a un propriétaire de plus haut niveau que les métriques d'ingénierie.

Et pour nommer la chose que les leaders techniques évitent à tout prix : rien de tout cela n'est de la manipulation. Vous ne gonflez pas la valeur de la plateforme. Vous traduisez sa valeur réelle dans le cadre que le dirigeant utilise effectivement pour allouer du capital. Persuader, c'est aider quelqu'un à voir ce qui est vrai à travers un prisme sur lequel il peut agir. Manipuler, c'est le pousser à agir contre son intérêt. Le risque est réellement de niveau board ; le dire à voix haute est simplement exact.