VIGIE : automatiser l'assurance qualité sans jamais inonder l'équipe de développement.
01La question de départ
On sait faire écrire des tests par une IA. Ce qu'on ne sait pas faire, c'est empêcher le système de noyer l'équipe de développement sous des anomalies qui n'en sont pas. Un pipeline qui déclare cent bugs dont vingt sont réels ne fait pas gagner du temps : il en fait perdre, et il perd surtout la confiance de ceux qui devraient s'en servir.
D'où la question que je me suis posée : où placer exactement les décisions humaines dans une chaîne d'assurance qualité automatisée, assez haut pour que la machine reste utile, assez fermement pour qu'aucun bruit n'atteigne l'équipe ?
02Deux boucles, deux pivots
Le système s'organise en deux boucles à cadences différentes, reliées par deux pivots : le référentiel de cas de test, source de vérité des scénarios, et le référentiel de tests officiels, qui contient les suites promues.
- La boucle de conception part du choix d'un périmètre fonctionnel. Elle cartographie la couverture, analyse le code de ce périmètre, priorise, génère les tests, les fait valider visuellement, puis les promeut. Elle sert autant à créer qu'à maintenir : un besoin qui change redevient de la couverture incomplète.
- La boucle d'exécution tourne à sa propre cadence : de nuit, sur demande de fusion, ou à la demande. Elle déploie la version choisie, injecte les données de test, exécute le palier, publie les rapports, diagnostique les échecs et alimente la déclaration contrôlée des anomalies.
03Sept agents, une responsabilité chacun
Aucun agent ne fait deux métiers, et un seul agent écrit dans chaque système externe : sans quoi la traçabilité devient impossible et les écritures entrent en conflit.
Comprend le besoin et mesure l'état réel des essais : couvert-valide, couvert-obsolète, non couvert. Modélise les processus métier : séquences, déclencheurs, chemins nominaux et alternatifs. La couverture se calcule, elle ne se maintient jamais à la main.
Deux modes. En mode écart, il confronte le code au besoin sur le périmètre choisi, jamais en aveugle, toujours à partir de la carte. En mode impact, il propose les essais à rejouer après un changement, chaque proposition portant son motif et son niveau de confiance.
Priorise les scénarios : les nominaux d'abord, puis par le risque (impact métier × probabilité de défaillance), et rédige les cas de test. Seul rédacteur du référentiel de cas de test. Il ne code jamais d'essai.
Développe les essais de bout en bout multi-rôles, d'interface de programmation et unitaires, avec les jeux de données dans le même commit. Assertions dérivées des données injectées, jamais de valeur codée en dur, jamais de secret.
Diagnostique chaque échec : régression réelle, essai fragile, ou obsolescence parce que le besoin a changé. Propose une sévérité, jamais une priorité. Il ne détecte pas et ne déclare rien.
Pose à chaque essai généré la seule question qui compte : « si je casse la fonctionnalité, cet essai échoue-t-il ? » Il bloque les assertions creuses. Aucun essai n'atteint la suite candidate sans son approbation.
Rédige les anomalies retenues avec tout ce qu'il faut pour corriger : séquence de reproduction, obtenu contre attendu, preuves, version, lien vers le cas de test et vers le besoin racine. Seul rédacteur des anomalies, et jamais sans sélection humaine.
04Cinq points de validation humaine
Ce sont des critères d'entrée et de sortie au sens ISTQB. L'humain décide, les agents exécutent.
- Périmètre : quel domaine traiter maintenant ? On avance à petits pas, et les diagrammes de processus proposés par l'agent 1 sont validés ou corrigés ici avant de servir de référence : ce sont des inférences, pas des faits.
- Contenu : ces scénarios et ces cas de test sont-ils justes ? Rien n'est rédigé avant ce oui.
- Automatisation : lesquels automatiser ? Le reste reste manuel, et reste suivi.
- Validation visuelle : cet essai fait-il la bonne affaire ? On le regarde tourner, vidéo et trace à l'appui, une fois pour toutes. La promotion vaut fusion.
- Déclaration : quelles anomalies deviennent des tickets ? C'est la porte qui protège l'équipe. Les anomalies écartées repartent en boucle de retour vers l'agent 5, contre les faux positifs.
La composition d'une campagne est traitée à part : elle n'engage pas la qualité d'un livrable, elle organise l'effort d'essai, à savoir quoi rejouer, sur quelle version, quand, et par qui.
05Les décisions structurantes
- Un script quand c'est déterministe, un agent seulement quand il faut raisonner. La détection des échecs, les reprises, la mise en quarantaine des essais instables et le dédoublonnage par signature sont du code, pas de l'IA : moins cher, sans aléa, débogable.
- Les agents communiquent par artefacts versionnés, pas par conversation. Chaque agent produit un fichier structuré committé ; le suivant lit l'artefact. Une conversation perd la nuance à chaque passage de main et ne laisse aucune trace auditable.
- Le cockpit se calcule depuis les sources au lieu de dupliquer leurs données. Sa seule donnée propre est sa configuration. Dupliquer aurait créé un troisième système à synchroniser.
- Sévérité proposée, priorité toujours humaine. ISTQB sépare l'impact technique de l'urgence métier ; laisser une IA fixer la priorité, c'est usurper un jugement métier.
- Une seule notion d'exécution. Automatisée ou manuelle, un essai partage le même historique, le même flux d'anomalies et le même bilan, sinon on bâtit deux systèmes de suivi à réconcilier.
- Les données d'essai sont versionnées à côté des essais et mises à jour dans le même commit. Des données maintenues dans un environnement dérivent et se désynchronisent.
06L'alignement normatif
« Aligné » est le mot exact : ISTQB est un référentiel de connaissances, pas une norme de certification de processus. La documentation est étagée selon ISO/IEC/IEEE 29119-3 : politique de test, stratégie, plans vivants générés à chaque itération, avec un allègement agile assumé et documenté. Le périmètre de la première version est l'adéquation fonctionnelle au sens ISO/IEC 25010 ; performance, sécurité et accessibilité sont hors périmètre par décision documentée, extensibles ensuite.
Chaque activité du processus de test ISTQB trouve sa place : planification à la porte du périmètre, analyse par les agents 1 et 2, conception par l'agent 3 avec les techniques classiques (partitions d'équivalence, valeurs limites, transitions d'état, cas d'utilisation), sélection des essais de régression par l'analyse d'impact, clôture par un bilan de version.
07Ce qui est livré
Le moteur visé est un service pro-code bâti sur un cadriciel d'agents à graphe de tâches, avec validation humaine native, points de reprise et outillage par protocole, et un dimensionnement de modèle par agent : léger là où il faut lire et compter, complet là où il faut raisonner sur du code.
08Ce que ce projet m'apprend
Concevoir VIGIE, c'est répondre à une question qui dépasse l'outillage : quelle décision peut-on déléguer à une machine, et laquelle ne le peut pas ? La réponse ne se trouve pas en lisant sur les agents : elle se trouve en plaçant les portes, en les déplaçant, et en constatant ce qui casse. C'est exactement la question que pose aujourd'hui l'automatisation encadrée des processus d'affaires, avec ses points de validation humaine et sa traçabilité des décisions automatisées.