"Pourquoi l'IA est inutile pour la compliance" -- Mon retour du Swiss Testing Day 2026

Le contexte

Le 26 mars 2026, j'étais au Swiss Testing Day à Zurich. Le thème de cette édition : "Guardians of Trust -- Defining Quality in a Dangerous Decade".

Parmi les sessions, celle de Nick Gushchin, AI Transformation Manager chez SFS Group. Son titre : "Why AI Is Useless for Compliance... and Why You Still Need It". Le genre de titre qui fait lever un sourcil dans une salle de QA.

La promesse était claire. On allait parler d'IA, de compliance, et de pourquoi les deux ne font pas bon ménage. Ce qui m'intéressait, c'était surtout le "and Why You Still Need It".

Le paradoxe

Le message central de Gushchin tient en une phrase. L'IA, aujourd'hui, ne peut pas garantir la compliance. Mais ne pas l'utiliser n'est pas une option non plus.

Son argument : les systèmes deviennent trop complexes, les volumes de données trop importants. Les processus manuels ne tiennent plus. L'IA devient un outil nécessaire, même dans un domaine où elle n'est pas fiable à 100%.

C'est un paradoxe inconfortable. On a besoin d'un outil en qui on ne peut pas avoir entièrement confiance. La question n'est pas "est-ce qu'on utilise l'IA", mais "comment on l'encadre pour qu'elle ne fasse pas plus de dégâts qu'elle n'en résout".

Pourquoi c'est compliqué de faire confiance à l'IA

Gushchin a posé le problème simplement. Un logiciel traditionnel, c'est déterministe. Une entrée donne toujours la même sortie. C'est prévisible, c'est testable, c'est vérifiable.

Un système IA, c'est l'inverse. Une entrée donne une distribution probabiliste de résultats. Souvent opaques. Souvent variables.

C'est un constat que j'avais déjà croisé plus tôt dans la journée, lors de la keynote de Bertrand Meyer. Meyer parlait du même problème sous l'angle du testing : comment tester un système dont le comportement est non-déterministe ? Gushchin, lui, pose la question sous l'angle de la compliance : comment faire confiance à un système qu'on ne peut pas auditer de manière traditionnelle ?

Deux angles différents, même problème de fond. Les questions deviennent fondamentales. Est-ce qu'on peut se fier aux décisions d'une IA ? Comment on teste un système qui ne donne pas deux fois la même réponse ? Qui est responsable quand ça se trompe ? Et comment on rend ça auditable pour un régulateur ?

Ce sont des questions ouvertes. Et c'est précisément là que la compliance coince.

Tester l'IA, ça existe

Gushchin n'a pas laissé la salle sans réponse. L'absence de déterminisme ne veut pas dire qu'on ne peut rien tester. Ça veut dire qu'on teste autrement.

Il a présenté plusieurs approches spécifiques au test de systèmes IA. Du prompt testing et behaviour testing pour valider les réponses et actions. Du red-teaming de sécurité, incluant des simulations d'injection de prompt et de fuite de données. De l'évaluation stochastique sur plusieurs exécutions pour mesurer la variabilité. Et de la comparaison de modèles avec du scoring qualité, en restant agnostique du LLM utilisé.

Côté outils, trois noms sont sortis. PyRIT, la librairie de red-teaming automatisé de Microsoft, qui simule des attaques pour identifier les vulnérabilités avant le déploiement. AgentEval, un framework .NET pour l'évaluation d'agents IA avec du scoring LLM-as-a-Judge. Et Promptfoo, une plateforme de test et sécurité utilisée par environ 25% du Fortune 500.

Le message était clair : les outils existent. La boîte à outils n'est pas vide. Ce qui manque, c'est la discipline pour les utiliser.

La checklist compliance de Gushchin

Gushchin a terminé avec une checklist en six points pour rendre un outil IA "compliance compliant".

Premier point : définir les frontières d'usage. Où l'IA a le droit d'intervenir, et où elle n'a pas le droit. Un périmètre non documenté, c'est un risque non documenté.

Deuxième point : la gouvernance des données. Classifier les inputs, contrôler ce qui entre dans le système, établir des obligations de rétention et de suppression.

Troisième point : les workflows de vérification. Les outputs de l'IA sont des brouillons, pas des décisions finales. Chaque étape critique doit inclure une revue humaine structurée.

Quatrième point : les audit trails. Logger chaque interaction IA qui contribue à une décision régulée. La reproductibilité et la traçabilité ne sont pas optionnelles.

Cinquième point : le monitoring continu. Le comportement d'un modèle dérive dans le temps. Il faut tester en permanence, pas seulement au déploiement.

Sixième point : l'ownership de la responsabilité. Chaque processus assisté par IA doit avoir un propriétaire nommé, capable de l'expliquer et de le défendre. Une gouvernance sans propriétaire, c'est du théâtre.

C'est solide. C'est structuré. Mais c'est incomplet.

Ce qui manque

La checklist de Gushchin couvre bien le côté technique et organisationnel. Mais elle part d'un présupposé implicite : que les gens en face vont jouer le jeu.

Il n'y a rien sur le fallback humain. Que se passe-t-il quand l'IA se trompe et que personne ne vérifie ? On a des workflows de vérification sur le papier, mais si la personne en bout de chaîne fait confiance aveugle à l'output, le workflow ne sert à rien.

Il n'y a rien sur la culture qualité en amont. Si une équipe n'a pas de rigueur sans IA, elle n'en aura pas avec. Déployer un outil sur une fondation bancale, c'est automatiser le chaos.

Il n'y a rien sur la formation des utilisateurs. Les gens utilisent l'IA sans comprendre ses limites. Ils ne savent pas ce qu'un LLM peut et ne peut pas faire. Et on leur demande de valider des outputs qu'ils ne sont pas équipés pour évaluer.

Et il n'y a rien sur la gestion du changement. Introduire l'IA dans un processus de compliance, c'est un changement majeur. Sans accompagnement, sans communication, sans montée en compétence progressive, c'est le rejet ou le laxisme. Souvent les deux.

La checklist est technique. Le problème est humain.

Le vrai problème, c'est les gens

Le fond du sujet, ce n'est pas l'IA. C'est la compliance elle-même.

La plupart des gens ne comprennent pas ce que compliance veut dire. Ils la voient comme une contrainte administrative, une case à cocher, un truc que quelqu'un d'autre gère. Pas comme une responsabilité collective.

Et par défaut, les gens sont fainéants. Ce n'est pas un jugement. C'est un constat de design de systèmes. Quand un raccourci existe, il sera pris. Quand une étape peut être sautée, elle sera sautée. C'est le comportement humain de base.

L'IA ne crée pas ce problème. Elle l'amplifie. Elle donne une excuse parfaite pour ne plus réfléchir. Pourquoi relire un output quand "c'est l'IA qui l'a fait" ? Pourquoi vérifier une décision quand le système a l'air confiant ? Le laxisme qui existait déjà dans les processus manuels va exploser avec l'automatisation.

Les outils existent. Les checklists aussi. Mais il y a une priorité qui vient avant tout ça : traiter le facteur humain. Sans ça, on met des cadenas sur une porte ouverte.

Mon takeaway

Ma note de la session tient en une ligne : garder l'IA loin des éléments critiques.

Pas parce que la technologie n'est pas prête. Les outils de test existent, la checklist de Gushchin est un bon point de départ, et les approches de monitoring progressent. Le cadre technique avance.

Mais la fondation humaine n'est pas là. Tant que les équipes ne comprennent pas ce que compliance signifie réellement, tant que la culture qualité n'est pas en place sans IA, ajouter de l'automatisation intelligente par-dessus ne fera qu'accélérer les erreurs.

On fait confiance à l'IA quand on a d'abord appris à faire confiance à ses propres processus.

Le Swiss Testing Day est une conférence annuelle dédiée à la qualité logicielle, organisée à Zurich. L'édition 2026, "Guardians of Trust -- Defining Quality in a Dangerous Decade", s'est tenue le 26 mars.

Retrouvez mes autres retours de la conférence sur mon blog. Vous pouvez aussi me suivre sur LinkedIn pour des réflexions sur la QA, la gamification et la culture qualité.