Une nouvelle fonctionnalité est livrée ? Encore faut-il s’assurer que tout le reste continue de fonctionner et de répondre aux besoins des clients, car les fonctionnalités dépendent souvent les unes des autres. Pas d’inquiétude : quelqu’un veille au grain, ou plutôt une équipe, la QA (pour quality assurance, ou assurance qualité). Peu de gens savent nommer ce métier de la minutie, que l’intelligence artificielle a pourtant profondément transformé. Chez OVHcloud, il a suffi d’un an pour que l’IA redéfinisse le métier de QA, avec des tests bien plus nombreux et un travail humain recentré aujourd’hui sur l’analyse. Entrez dans les coulisses de ce changement, chiffres et limites à l’appui.
Avant l’IA, un contrôle surtout manuel
Le dernier contrôle avant la mise en ligne
Le rôle d’un QA consiste à s’assurer que la livraison d’une fonctionnalité apporte ce qui est prévu, sans compromettre les fonctionnalités existantes, avant sa mise à disposition des utilisateurs.
Concrètement, aucune modification de code n’est déployée directement en production. Elle transite d’abord par un environnement de test, puis par un environnement de préproduction qui reproduit les conditions réelles. À chacune de ces étapes, il faut vérifier que l’interface s’affiche correctement, que les formulaires se valident et que le parcours de commande aboutit toujours. Cette mission revient au QA, à la jonction entre les équipes produit qui livrent et les utilisateurs qui attendent un service fiable.
Environ 450 tests rejoués à la main
Il y a un an, ce travail reposait encore largement sur des vérifications manuelles. L’équipe disposait d’un référentiel d’environ 450 tests pour certaines applications, exécutés un à un sur chaque environnement (test, préproduction, production). Chaque test devait donc être rejoué trois fois à chaque livraison significative.
L’exercice était chronophage et limitait mécaniquement la couverture des tests. Faute de pouvoir tout contrôler, il était nécessaire de prioriser les scénarios les plus critiques et d’accepter de laisser certains angles morts. La qualité se trouvait ainsi indexée sur le temps disponible.
Le tournant de l’IA
Trois agents, trois rôles
Le changement majeur est venu d’agents IA spécialisés, mis en place par l’équipe et intégrés au quotidien à son environnement de développement.
Chacun des trois principaux agents assume une fonction unique. Le premier élabore un plan de test, qui précise les vérifications à mener, leur ordre et les cas limites à couvrir. Le deuxième rédige le test automatisé correspondant dans Playwright, un outil qui pilote un navigateur pour reproduire les actions d’un utilisateur. Enfin, le troisième corrige les tests existants qui échouent.
Chaque agent obéit à un ensemble de règles que l’équipe affine au fil des mois. Ce cadrage compte autant que la technologie. Un agent bien paramétré produit un résultat exploitable, alors qu’une consigne imprécise donne un plan ou un test qui paraît correct mais se révèle inutilisable en pratique.
Un skill pour les migrations
L’espace client OVHcloud évolue régulièrement et chaque nouvelle version peut modifier l’agencement de l’interface. Pour les tests, ces migrations représentent donc un chantier conséquent, qui impose de reprendre l’existant, d’écarter ce qui n’a plus lieu d’être et de réécrire le reste.
Pour structurer cet exercice, l’équipe a conçu un skill, c’est-à-dire un ensemble d’instructions réutilisables que l’IA applique dès qu’elle identifie une demande de migration. Le QA évalue d’abord la pertinence de chaque test au regard de la nouvelle version. Lorsque le test mérite d’être conservé, les agents prennent le relais pour produire le plan puis le test adapté. La dernière migration s’est ainsi déroulée bien plus sereinement que la précédente.
Des milliers de tests chaque jour
Aujourd’hui, près de 3 000 tests s’exécutent deux fois par jour sur le périmètre européen, rien que pour la nouvelle version de l’espace client (actuellement en bêta). À ces exécutions planifiées s’ajoutent celles que déclenche chaque modification de code proposée par un développeur, limitées aux tests associés au périmètre impacté. Au-delà de l’Europe, le dispositif couvre également le Canada et les États-Unis. Signe de cette montée en puissance, l’équipe a ajouté certains mois plus de 1 300 nouveaux tests.
Analyser l’erreur plutôt que la chercher
L’automatisation a inversé la logique du travail. Les tests s’exécutent de manière autonome et un rapport recense les échecs après chaque passage : les vérifications manuelles deviennent l’exception.
Désormais, l’essentiel consiste à trier les résultats. Face à un test en échec, le QA doit déterminer s’il s’agit d’un incident technique passager, d’un test devenu obsolète ou d’un véritable défaut à signaler à l’équipe produit. L’enjeu n’est plus de détecter l’erreur, mais d’en comprendre l’origine.
Prenons l’exemple d’un bouton gris. Si le test attend un code couleur exact et que la teinte du bouton évolue légèrement, le test échoue. Remplacer l’ancien code par le nouveau permettrait au test de réussir à nouveau, de « repasser au vert » dans le jargon des QA, mais seulement jusqu’au prochain ajustement de teinte. Vérifier plutôt que le bouton affiche une nuance de gris rend le test plus robuste dans le temps, tout en le laissant échouer si le bouton change réellement de couleur.
Derrière ce réglage se pose une question de fond en matière de stratégie de test. Jusqu’où un test doit-il être strict pour rester utile sans devenir fragile ? L’IA peut proposer une solution, mais l’arbitrage revient au QA.
La part de tests réussis avoisine désormais 95 %, contre 65 à 70 % plus tôt dans l’année durant la mise en place de la stratégie de test actuelle. Selon l’équipe, un test en échec signale aujourd’hui le plus souvent un problème réel plutôt qu’une erreur de conception du test.
Maîtriser l’outil ne suffit plus
Cette évolution a exigé l’acquisition de nouvelles compétences. Les QA administrent aujourd’hui un dépôt de code partagé, relisent et valident des propositions de modification (pull request). Ils travaillent avec les mêmes outils que les développeurs, sans pour autant endosser leur rôle.
L’IA a d’ailleurs elle-même accompagné cet apprentissage, chacun l’utilisant pour assimiler une notion ou une syntaxe à son rythme et selon ses besoins. Une règle s’est toutefois imposée : « Il ne faut pas juste maîtriser l’outil, il faut maîtriser l’IA, […] c’est un gain de temps sur une partie du travail, mais il faut prendre le temps de le challenger », résume Céline Chapalain, membre de l’équipe QA.
Un modèle d’IA est en effet non déterministe. Soumise deux fois, une même question peut aboutir à deux réponses différentes. Il convient donc d’exercer un regard critique, de vérifier chaque production et d’écarter les propositions mal construites. Les étudiants d’un récent hackathon ont appliqué ce même principe, puisque chaque correctif proposé par l’IA y faisait l’objet d’une relecture humaine systématique.
Cette montée en compétences ne s’est pas faite en solitaire. Face à des outils nouveaux et à une appréhension bien réelle, l’accompagnement collectif a joué un rôle décisif. Sébastien Debrauwere, responsable de l’équipe QA chez OVHcloud, l’illustre par une image empruntée au rugby : « Un joueur ne vaut rien sans les 14 autres. »
L’attention, une ressource à préserver
Ce bilan serait incomplet sans évoquer ses limites. L’équipe signale en effet un point de vigilance qui ne tient pas à la technologie elle-même, mais à l’organisation du travail qu’elle induit.
L’IA travaille en arrière-plan, ce qui incite à mener plusieurs chantiers de front. Pendant qu’une analyse s’exécute, le QA ouvre un deuxième sujet, puis un troisième, avant de revenir au premier. Le temps de travail se fragmente et certains membres de l’équipe évoquent des fins de journée particulièrement éprouvantes. Ce rythme sollicite fortement la concentration, quelle que soit l’expérience de chacun.
Le risque tient au temps consacré à la réflexion, qui tend à se réduire. C’est la critique souvent adressée au vibe coding, une pratique qui consiste à produire du code de façon intuitive en déléguant la conception à l’IA. Rapide et accessible, cette approche offre en revanche moins de garanties sur la qualité. Or c’est précisément ce temps de réflexion qui fait la valeur du QA, qu’il s’agisse d’envisager tous les cas possibles ou de privilégier une plage de valeurs plutôt qu’une valeur figée, comme pour l’exemple du bouton gris. Ce constat dépasse d’ailleurs le cadre de la QA, puisque d’autres acteurs, dans la cybersécurité notamment, s’interrogent sur les enjeux et limites de l’IA.
Le métier de QA évolue sans disparaître
En un an, le métier de QA chez OVHcloud a changé de visage. Le nombre de tests a fortement augmenté et leur exécution est automatisée. Le travail des QA s’est recentré sur ce que la machine ne peut trancher, qu’il s’agisse de la stratégie de test, de l’analyse des échecs ou du choix de ce qui mérite d’être vérifié. Leurs compétences techniques se sont élargies et la préservation de la concentration est devenue une préoccupation collective.
Et demain ? L’équipe QA confie une part croissante de son travail à des agents IA capables d’explorer l’application, de générer les tests, de les adapter quand l’interface évolue et de suivre les anomalies. Elle souhaite aussi intégrer les tests plus tôt dans le cycle de développement, pour qu’un développeur qui propose une modification de code voie s’afficher les résultats des tests simulant un parcours utilisateur complet. L’objectif est de lui fournir toujours plus d’outils pour repérer les problèmes avant que sa modification ne soit intégrée au code principal.
Si cette évolution vous intrigue, écoutez comment une Product Manager vit à son tour l’arrivée de l’IA.