Les auditeurs IA n'existent pas encore

Le detail parait administratif : l’AI Office cherche des experts pour discuter des exigences de qualification et d’independance des evaluateurs externes de modeles d’IA a usage general presentant un risque systemique. Pas un nouveau modele. Pas une interdiction spectaculaire. Pas une annonce de milliards. Juste une question de metier : qui aura le droit de dire qu’un modele tres puissant a ete correctement evalue ?

C’est precisement pour cela que le sujet compte.

La regulation de l’IA entre dans sa phase la moins photogenique. Les grands principes sont connus. Les calendriers sont publics. Les codes de pratique existent. Mais un regime de controle ne vaut pas par ses verbes juridiques. Il vaut par les personnes capables de regarder les preuves, de comprendre les limites d’un test, de resister a la pression du fournisseur, et d’ecrire un avis qui ne soit ni un communique de presse, ni une fiction de conformite.

L’Europe ne manque plus seulement de regles. Elle risque de manquer d’auditeurs capables de les rendre reelles.

Le risque systemique ne se coche pas en fin de projet

L’article 55 de l’AI Act impose des obligations supplementaires aux fournisseurs de modeles d’IA a usage general avec risque systemique. Il faut evaluer les modeles avec des protocoles et outils appropries, identifier et attenuer les risques, suivre les incidents graves, documenter la securite et maintenir un niveau de cybersecurite adapte.

Sur le papier, la logique est simple : plus le modele est capable, diffuse et potentiellement destabilisant, plus le fournisseur doit prouver qu’il sait ce qu’il met en circulation.

Dans la pratique, cette preuve est difficile. Un modele generaliste n’est pas un logiciel metier classique. Il peut etre integre dans des milliers de contextes, detourne vers des usages que le fournisseur n’a pas prevus, ajuste par des couches applicatives, combine avec des outils, des donnees, des agents et des decisions humaines. Le risque ne se trouve pas dans une seule fonction. Il circule dans l’ecosysteme.

Evaluer ce type de modele demande donc autre chose qu’une batterie de tests executee a la fin. Il faut comprendre les capacites, les seuils de declenchement, les comportements rares, les possibilites d’abus, les mesures de mitigation, les incidents passes et les conditions de deploiement. Il faut aussi accepter que certaines reponses restent probabilistes. Le controle n’est pas une photographie. C’est une enquete methodique sur une machine qui change.

L’evaluateur externe est une piece fragile du systeme

Le Code de pratique GPAI donne aux fournisseurs une voie volontaire pour demontrer leur conformite, notamment sur la transparence, le droit d’auteur, la surete et la securite. Pour les modeles a risque systemique, les evaluations externes deviennent un instrument central de credibilite.

Mais le mot “externe” ne suffit pas. Un cabinet peut etre externe juridiquement et dependant economiquement. Un laboratoire peut etre brillant scientifiquement et trop eloigne des contraintes de production. Un expert peut savoir tester un modele ouvert, mais pas auditer une chaine industrielle fermee. Une organisation peut etre competente sur la cybersecurite et faible sur les risques de manipulation, de biologie, de modeles agents ou d’usages a grande echelle.

L’independance n’est donc pas seulement l’absence de lien capitalistique. C’est une architecture de contraintes : qui paie, qui choisit le perimetre, qui voit les donnees, qui peut publier les limites, qui peut refuser une conclusion, qui garde les traces, qui protege l’evaluateur quand son avis derange.

Sans cette architecture, l’evaluation externe devient une ceremonie. Elle produit un document, pas une garantie. Elle donne au fournisseur une preuve presentable, mais pas forcement une contradiction robuste.

Les competences seront rares parce qu’elles sont hybrides

Le futur evaluateur de modeles systemiques devra tenir ensemble des competences qui vivent rarement au meme endroit.

Il lui faudra une culture technique assez solide pour comprendre les evaluations de modeles, les benchmarks, les attaques, les limites des protocoles, les questions d’acces aux poids ou aux journaux, et les effets d’une mise a jour. Il lui faudra une culture de risque pour distinguer un incident plausible d’une hypothese theatrale. Il lui faudra une culture juridique pour traduire une obligation en preuve recevable. Il lui faudra enfin une culture operationnelle pour savoir comment un modele devient un produit, puis une dependance dans une entreprise.

C’est beaucoup demander a un marche qui, pour l’instant, vend souvent de la conformite IA comme il vendrait un atelier RGPD, une certification ISO ou une cartographie des cas d’usage.

Le probleme n’est pas que ces metiers seraient inutiles. Au contraire. Mais l’audit des modeles systemiques ne peut pas etre une extension cosmetique de l’audit logiciel habituel. Un modele peut passer un test et echouer ailleurs. Il peut etre raisonnable dans une langue et fragile dans une autre. Il peut etre plus dangereux une fois branche a des outils. Il peut devenir plus capable apres une mise a jour. Il peut produire un risque par agregation de millions d’usages faibles.

Un bon evaluateur devra donc savoir dire : ce test prouve quelque chose, mais pas tout. Cette mitigation reduit un risque, mais en laisse un autre. Cette documentation est propre, mais elle ne donne pas acces au mecanisme qui permettrait de verifier l’affirmation.

Le vrai conflit portera sur l’acces aux preuves

La question la plus sensible ne sera pas le titre professionnel de l’auditeur. Ce sera son acces.

Un fournisseur de modele systemique ne voudra pas tout ouvrir. Il invoquera le secret industriel, la securite, la protection contre les abus, les donnees de tiers, les contrats et le risque concurrentiel. Certaines limites seront legitimes. D’autres serviront a reduire le controle a une visite guidee.

L’evaluateur, lui, ne peut pas se contenter d’une demonstration preparee. Il doit pouvoir verifier les protocoles, les resultats, les incidents, les processus de decision, les arbitrages de securite, les changements de version et les conditions dans lesquelles les tests ont ete realises. Il doit pouvoir poser des questions qui n’arrangent pas le recit du fournisseur.

C’est ici que la regulation devient concrete. Une obligation de conformite sans droit d’acces produit de beaux fichiers. Une evaluation avec acces insuffisant produit une confiance mal placee. Entre les deux, il faut inventer une pratique qui protege a la fois les secrets legitimes et le droit du public a une evaluation serieuse des risques.

Ce n’est pas un detail de procedure. C’est le coeur du sujet.

La certification ne remplacera pas le jugement

Le contrepoint est important : le risque systemique reste une categorie incertaine. La litterature critique sur l’AI Act rappelle que gouverner des modeles generalistes revient souvent a gouverner une incertitude en mouvement. Les seuils, les capacites, les usages et les impacts ne se laissent pas toujours enfermer dans une definition stable.

Cette incertitude ne condamne pas la regulation. Elle interdit seulement de la traiter comme un exercice de tampon.

Une certification peut attester qu’une procedure existe. Elle peut verifier que des documents sont presents, que des roles sont nommes, que des tests ont eu lieu, que des incidents sont suivis. Elle ne peut pas, seule, garantir que le modele sera inoffensif dans un monde ouvert. Le bon auditeur devra donc faire preuve de jugement, pas seulement de conformite.

Ce jugement sera inconfortable. Il devra parfois dire qu’un risque est mal compris. Qu’un test est trop etroit. Qu’une mitigation est plausible mais insuffisamment prouvee. Qu’une absence d’incident n’est pas une absence de danger. Qu’une revendication marketing excede ce que les evaluations montrent.

Ce sera moins vendeur qu’un label. Ce sera beaucoup plus utile.

Les entreprises clientes devront apprendre a lire les preuves

La plupart des PME ne fourniront jamais un modele GPAI a risque systemique. Elles ne seront pas dans la salle ou se negocient les qualifications des evaluateurs. Pourtant, elles seront concernees par ricochet.

Leurs outils de bureautique, de service client, de code, de recherche, de generation documentaire ou d’automatisation pourront reposer sur ces modeles. Le fournisseur applicatif leur dira que le modele sous-jacent est conforme, audite, encadre, robuste. La tentation sera de prendre ces mots comme une assurance generale.

Il faudra apprendre a poser des questions plus modestes.

Quelle version du modele a ete evaluee ? Quel risque a ete teste ? Dans quelle langue ? Avec quel acces aux informations internes ? Par qui ? Selon quel protocole ? Les limites de l’evaluation sont-elles publiees ou seulement resumees ? Que se passe-t-il apres une mise a jour majeure ? L’evaluation porte-t-elle sur le modele seul, ou sur le produit final utilise par l’entreprise ?

Ces questions ne transformeront pas une PME en laboratoire d’evaluation. Elles l’empecheront seulement de confondre une preuve sectorielle avec une garantie universelle.

Le marche de la confiance arrive avant ses metiers

On voit deja se former un marche de la confiance IA : labels, attestations, audits, frameworks, politiques internes, codes de conduite, comites, registres, preuves documentaires. Ce marche est inevitable. Il repond a une vraie demande : les entreprises veulent utiliser l’IA sans porter seules toute l’incertitude.

Mais un marche de la confiance peut aussi devenir un marche du soulagement. On achete un document pour cesser de poser des questions. On affiche une conformite pour calmer un client. On transforme l’audit en couche narrative entre le risque et la decision.

La discussion ouverte par l’AI Office sur les evaluateurs externes est donc un signal discret mais majeur. Elle dit que la prochaine bataille ne portera pas seulement sur les modeles. Elle portera sur la qualite des tiers qui pretendent les regarder.

Si ces tiers sont faibles, dependants ou superficiels, le regime europeen produira de la paperasse de haut niveau. Si ces tiers deviennent exigeants, competents et suffisamment proteges, ils pourront ralentir certains lancements, contrarier certains fournisseurs, et donner plus de poids aux preuves qu’aux promesses.

C’est le prix normal d’un controle qui sert a quelque chose.

Le bon auditeur sera celui qui sait dechoir une preuve

Dans les prochaines annees, beaucoup d’acteurs sauront dire qu’ils evaluent l’IA. Le tri se fera ailleurs : dans leur capacite a dechoir une preuve.

Une preuve doit pouvoir perdre sa valeur quand le perimetre change, quand le modele change, quand le protocole est trop etroit, quand l’acces etait insuffisant, quand les incidents contredisent les tests, quand le deploiement reel n’a plus grand-chose a voir avec l’evaluation initiale.

Cette hygiene est rude. Elle frustre les directions, les fournisseurs et parfois les clients. Mais elle evite le pire malentendu : croire qu’une evaluation ancienne, partielle ou interessee continue de proteger tout le monde.

L’IA systemique pose des questions nouvelles, mais la lecon est ancienne. Un controle n’est credible que s’il peut dire non. Pas seulement non a un modele. Non a une preuve trop faible. Non a une conclusion trop rapide. Non a une independance de facade.

Le reste n’est que papier.