La phase de découverte nous a convaincus qu'il était possible de doubler la vitesse dans le cadre du projet pilote, et nous avons pu identifier clairement les points critiques.

Responsable de l'assurance qualité

Le client est une grande entreprise du secteur agroalimentaire et de la grande distribution qui gère l'ensemble de l'expérience client sur une plateforme de commerce électronique unique et vend via plusieurs canaux. Son équipe interne d'assurance qualité était chargée d'une suite de tests de régression comprenant environ 5 000 tests répartis entre plusieurs régions et différents rôles. L'entreprise cherchait à accroître sa part de marché et avait besoin de déployer des fonctionnalités plus rapidement ; l'ingénierie qualité devait donc évoluer plutôt que de constituer un frein.

La qualité n’a jamais été le problème. C’était la rapidité. Le client ne cherchait pas à mener un énième test pilote d’outils. Il avait besoin d’un programme par étapes, fondé sur des données concrètes et doté de critères de validation clairs. a1qa a été mandatée pour identifier les véritables pertes de temps au sein du cycle, mettre en œuvre un mécanisme plus rapide dans un périmètre restreint et ne l’étendre qu’aux domaines où les données le justifiaient.

Le défi

En l'absence d'un responsable clairement désigné, la prise de décision concernant le lancement prenait près de deux semaines, et la suite de tests était devenue si volumineuse que l'ajout d'un seul test ralentissait le cycle de régression suivant. Les solutions habituelles avaient déjà atteint leurs limites. Automatiser davantage, faire appel à plus de personnel ou exécuter la suite de tests pendant la nuit ne changeait plus rien.

Le goulot d'étranglement ne résidait pas dans le nombre de tests. Il tenait à la structure du cycle. Avant chaque vérification, des configurations complexes de l'interface utilisateur étaient exécutées. Les mêmes cas, équivalents du point de vue de la configuration, se répétaient sans cesse. Le triage impliquait que les ingénieurs devaient réexaminer manuellement les défaillances, sans responsable clairement identifié. Et chaque décision de mise en production reposait sur des estimations plutôt que sur des données.

L'IA transforme l'économie de ces quatre facteurs, mais uniquement lorsqu'elle est intégrée au cycle lui-même, plutôt que d'être ajoutée en tant qu'élément externe. Le programme a abordé simultanément ces quatre coûts : la configuration initiale, les exécutions redondantes, l'analyse manuelle des défaillances et l'absence de signal clair pour la prise de décision concernant les lancements.

Le projet a été mené selon un modèle à prix fixe et par phases, avec des points de validation, de sorte que le client pouvait y mettre fin à n’importe quel moment : chaque phase se terminait par un point de validation, et la phase suivante n’était financée que si les données étayaient les résultats obtenus. L'investissement n'était jamais engagé avant la validation, et l'équipe partageait la responsabilité de chaque outil d'appui, indicateur et processus de tri dès le premier jour, garantissant ainsi que le savoir-faire resterait au sein de l'organisation une fois la collaboration avec a1qa terminée. Le travail s’est déroulé selon un modèle Agile avec des livraisons itératives et a été mené par une équipe pluridisciplinaire composée d’un responsable de l’assurance qualité, de deux ingénieurs en automatisation, d’un concepteur de tests et d’un ingénieur DevOps chargé de l’exécution dans le cloud.

Discovery

Diagnostic des points critiques. Une phase de « Discovery » à périmètre défini a permis de valider les hypothèses à l’aide du code et du pipeline propres au client. Par la suite, elle a décomposé le processus décisionnel relatif aux lancements en neuf points critiques spécifiques liés à la définition du périmètre, à l’exécution automatisée, au triage, à la réexécution et à la décision finale. Au lieu de tenter de tout aborder en même temps, a1qa a délibérément défini, en collaboration avec le responsable de l’assurance qualité, un périmètre limité à une combinaison spécifique de rôle et de région. Cette approche est plus facile à évaluer, moins coûteuse en cas d’erreur et fournit au client des données concrètes avant qu’il ne prenne des engagements de plus grande envergure.

Pilote

Conception de tests assistée par l'IA. Un modèle de langage à grande échelle (LLM) a contribué à la conception des tests. Il a généré des cas de test potentiels à partir des récits d’utilisateurs et des spécifications existantes, identifié les lacunes de couverture face aux modifications apportées au code et généré des données de test réalistes pour des scénarios impliquant plusieurs régions et plusieurs rôles. Un ingénieur en assurance qualité a vérifié chaque élément généré par l’IA avant de l’intégrer à la suite de tests, garantissant ainsi que la couverture soit renforcée là où le risque était réel.

Automatisation des tests basée sur l'IA. Les longues étapes de configuration de l’interface utilisateur ont été remplacées par des préconditions basées sur des API préparées par l’IA, capables de mettre le système dans l’état requis en quelques millisecondes au lieu de plusieurs minutes. La configuration initiale nécessaire avant chaque exécution était partagée entre les groupes de tests, les exécutions étaient effectuées en parallèle pour différentes combinaisons de région, de rôle et de mode, et les localisateurs auto-réparateurs absorbaient les changements habituels de l’interface, évitant ainsi les échecs des tests. Il en a résulté une couche d’automatisation plus légère, plus rapide et plus facile à maintenir par l’équipe du client elle-même.

Triage assisté par IA et classification des défaillances. Le triage représentait l’un des coûts cachés les plus importants. a1qa a attribué un responsable identifié à chaque défaillance à chaque étape du processus et a entraîné des mécanismes de classification basés sur des modèles de défaillance afin de les classer en problèmes liés à l’environnement, aux tests ou au produit. La détection des tests instables a permis de réduire les faux positifs, tandis que les réexécutions automatiques ont permis de gérer les défaillances liées à l’environnement. En conséquence, les ingénieurs ont cessé de vérifier manuellement les journaux et ont pu se recentrer sur la résolution des problèmes liés au produit.

Phase 2

Des informations utiles pour prendre des décisions éclairées. Chaque décision de lancement était associée à une version spécifique et était archivée à des fins de traçabilité et d'audit. Plutôt que de se fier à des estimations, les équipes s'appuyaient sur des données réelles issues des tests et du contrôle qualité. Pour chaque version, les responsables pouvaient voir ce qui avait été validé, ce qui avait été reporté et pourquoi.

Phase 3

Exécution dans le cloud à grande échelle. La suite a été exécutée sur une infrastructure cloud élastique couvrant les flux Web et mobiles, y compris les processus de livraison et de paiement. a1qa a éliminé les réexécutions équivalentes du point de vue de la configuration, a segmenté la suite critique pour l’entreprise afin qu’elle ne s’exécute qu’en réponse à des événements pertinents liés aux versions client, et a fait évoluer la capacité à la demande pour permettre des exécutions parallèles. Une fenêtre d’exécution nocturne fixe s’est transformée en une capacité flexible que l’équipe pouvait étendre lorsqu’une version l’exigeait.