Une entreprise peut-elle vraiment contrôler les risques de son intelligence artificielle si le fournisseur décide lui-même de ce que l'auditeur a le droit de voir ? C'est la question posée par un accord volontaire signé avec la Maison-Blanche par six acteurs majeurs de l'IA : Nvidia, OpenAI, Anthropic, Google, Meta et xAI. Ils promettent de travailler avec des évaluateurs externes et de soumettre les rapports à des administrateurs indépendants.
L'intention est bonne. Mais un audit n'est pas indépendant juste parce qu'un tiers apparaît dans le processus. Si l'entreprise choisit l'évaluateur, fixe les tests et limite les informations disponibles, elle garde une bonne part de la main sur le résultat. Et ce n'est pas un débat abstrait : il en va de la sécurité, de la fiabilité et, aussi, des effets économiques d'outils déployés à grande échelle.
La question pratique devient alors simple : comment contrôler un modèle puissant sans demander au fournisseur de livrer tous ses secrets ? Les tests en environnement sécurisé offrent une piste intéressante. Ils ne règlent pas tout, mais ils permettent de clarifier le compromis entre confidentialité et contrôle. Voici donc ce qu'il faut pour qu'un audit de l'IA fasse plus que cocher une case.
Un audit n'est indépendant que si son périmètre l'est aussi
Un audit externe peut donner l'impression d'un contrôle, tout en laissant les décisions clés au fournisseur. Trois questions reviennent immédiatement : qui choisit l'évaluateur ? Qui définit les questions ? L'auditeur peut-il accéder aux informations utiles ? Et si ses conclusions pointent un problème, que se passe-t-il concrètement ? Sans réponses claires, la présence d'un tiers ne suffit pas à rendre l'audit vraiment indépendant.
Dans l'accord américain évoqué, les entreprises s'engagent à recourir à un évaluateur externe et à transmettre ses rapports à des membres indépendants de leur conseil d'administration. Mais le texte ne dit pas qui désigne l'auditeur, quels éléments il peut examiner, ni si les résultats seront rendus publics. Il ne prévoit pas non plus de sanction explicite en cas de non-respect des engagements. En pratique, on est donc d'abord sur une promesse volontaire, pas sur un dispositif de contrôle comparable à une obligation réglementaire.
Cette différence compte. Un audit utile doit pouvoir confronter le modèle à des tests que son développeur n'avait pas planifiés à l'avance. Sinon, l'évaluation risque de mesurer la performance sur un « examen connu », plutôt que la robustesse face à des usages imprévus. C'est un travers bien connu : quand l'équipe sait à l'avance ce qu'on va contrôler, elle peut optimiser ses procédures pour l'audit sans traiter les faiblesses qui comptent vraiment.
Trois décisions qui pèsent sur la valeur d'un audit
Pour juger un dispositif, il faut regarder au moins trois points :
- La désignation de l'auditeur. On peut choisir un cabinet compétent et, pourtant, rester dépendant. L'indépendance ne tient pas seulement à l'expertise : elle dépend aussi des conditions de rémunération, du renouvellement du mandat et de la publication (ou non) des résultats.
- Le choix des tests. L'évaluateur doit pouvoir concevoir des scénarios pertinents, y compris des cas que le fournisseur n'a pas soumis lui-même. C'est la seule façon de « tester les limites », pas seulement de confirmer ce qui fonctionne déjà.
- La portée de l'accès. L'auditeur doit savoir exactement à quoi il a accès, ce qui lui est refusé et ce qui l'empêche de conclure. Un examen restreint peut être acceptable, mais il ne doit pas être présenté comme une validation complète.
Cela ne veut pas dire qu'il faut tout publier. Les résultats peuvent contenir des informations sensibles pour la sécurité ou des éléments protégés commercialement. En revanche, l'identité de l'auditeur, la période couverte, les catégories de tests et les limites d'accès peuvent être communiquées sans exposer le fonctionnement interne du modèle.
La ligne de partage est simple : confidentialité des détails versus opacité du processus. La première peut se justifier. La seconde, elle, empêche clients, régulateurs et public de savoir ce qui a vraiment été contrôlé.
Ce que l'exemple Enron apprend sur les conflits d'intérêts
L'histoire de l'audit financier montre pourquoi les règles d'indépendance ne sont pas un détail bureaucratique. Enron payait Arthur Andersen pour l'audit de ses comptes, mais aussi pour des services fiscaux et du conseil. En 2000, les montants versés s'élevaient à 52 millions de dollars au total. Les deux organisations se sont ensuite effondrées.
L'analogie avec l'IA a ses limites : on ne parle pas de comptes financiers, et les risques ne sont pas identiques. Mais le mécanisme de fond reste pertinent. Un auditeur peut être compétent et, quand même, avoir des incitations à ne pas contester son client. Si le contrat, l'accès aux missions futures ou une part importante du chiffre d'affaires dépendent de l'entreprise auditée, le contrôle peut perdre de sa vigueur, parfois sans qu'aucune consigne explicite n'ait besoin d'être donnée.
Après le scandale Enron, les États-Unis ont adopté la loi Sarbanes-Oxley. Elle a renforcé l'indépendance des auditeurs, limité certains services vendus aux entreprises contrôlées et créé un organisme chargé d'inspecter les cabinets d'audit. La leçon n'est pas de copier-coller des règles comptables à l'IA. C'est qu'un dispositif de contrôle doit prévoir des règles sur les intérêts, les responsabilités et la supervision de ceux qui contrôlent.
Les engagements volontaires ne remplacent pas un vrai suivi
Les engagements volontaires peuvent aider au départ, surtout quand la technologie avance plus vite que les textes. Mais ils ont un défaut opérationnel : tout repose beaucoup sur la volonté des signataires. Si les critères sont vagues, si les résultats sont difficilement comparables et si aucune conséquence n'est prévue en cas d'écart, il devient dur de distinguer une entreprise qui progresse d'une entreprise qui « communique » seulement sur ses efforts.
Un précédent éclaire le sujet. Après des engagements volontaires pris auprès de la Maison-Blanche en 2023, des chercheurs de Stanford, Harvard et Brown ont évalué 16 entreprises sur leur mise en œuvre. Le score moyen était de 53 %. Sur l'engagement visant à aider des acteurs externes à repérer et signaler des problèmes, huit entreprises ont obtenu un score nul. Ce n'est pas une preuve que toutes les promesses étaient de mauvaise foi. C'est surtout une preuve que, sans mécanisme de vérification, une promesse ne s'auto-vérifie pas.
Pour l'IA, un audit crédible doit donc clarifier des responsabilités concrètes : qui commande l'évaluation, qui paie, qui fixe le périmètre, qui reçoit le rapport et qui s'assure que des corrections suivent. Il faut aussi documenter les conflits d'intérêts et permettre à l'auditeur de refuser une mission si les conditions rendent l'évaluation peu fiable.
Ce qu'une entreprise peut demander à son fournisseur
Les acheteurs ne devraient pas se contenter d'une formule du type « modèle testé par un tiers ». Dans un appel d'offres ou un contrat, ils peuvent exiger des éléments plus vérifiables :
- l'identité de l'organisme d'évaluation et ses liens commerciaux avec le fournisseur ;
- les grandes familles de tests réalisées et la période concernée ;
- les restrictions d'accès (données, versions du modèle, journaux) ;
- les limites connues de l'évaluation et ce qui n'est pas couvert ;
- le processus de correction, de suivi et de nouvelle évaluation.
Ces demandes restent utiles même si le rapport complet demeure confidentiel. Elles permettent de comparer des offres sur des points vérifiables, plutôt que sur une déclaration générale. Pour une entreprise qui intègre un modèle dans un service client, un outil de recrutement ou une chaîne de décision métier, la différence entre « promesse » et « éléments auditables » peut vraiment changer la donne.
Tester un modèle sans en prendre possession
L'accès à un modèle pose un problème particulier. Un modèle entraîné, c'est un ensemble très volumineux de paramètres, souvent issu d'investissements qui peuvent dépasser 100 millions de dollars. En transmettre une copie à un évaluateur externe peut augmenter les risques de fuite, de copie ou d'utilisation non autorisée. À l'inverse, si l'entreprise garde la main sur tous les tests, elle peut maîtriser l'accès aux questions à l'avance ou aux informations sensibles.
Ce dilemme se ramène trop souvent à un choix malheureux : soit les évaluateurs partagent leurs tests au fournisseur (qui connaît alors les questions avant l'examen), soit le fournisseur remet une copie du modèle (qu'il ne maîtrise plus entièrement). Dans les deux cas, protéger un intérêt légitime - la confidentialité du modèle ou l'indépendance des tests - finit par fragiliser l'autre.
Une piste consiste à réaliser les évaluations dans un environnement informatique sécurisé, parfois appelé environnement d'exécution de confiance. Le modèle y tourne sans être remis directement aux évaluateurs. Ces derniers peuvent soumettre leurs tests, tandis que le fournisseur n'accède pas nécessairement aux questions. L'idée est de séparer ce qui doit rester confidentiel, puis de vérifier que le traitement a bien été effectué.
Le principe du test en double aveugle
En août, Google DeepMind a présenté un test présenté comme le premier test en double aveugle d'un modèle d'IA. Le dispositif a été conçu avec l'Institut de sécurité de l'IA de Singapour et plusieurs organisations externes. Le principe s'inspire des essais en double aveugle : le fabricant ne connaît pas les questions de l'évaluateur, et l'évaluateur ne prend pas possession du modèle.
Le bénéfice est concret. Un organisme externe peut concevoir l'examen sans livrer son protocole au fournisseur. Le fabricant, de son côté, évite de diffuser une copie de son modèle. Selon Google, chaque partie peut vérifier mathématiquement que les éléments de l'autre sont restés privés. Cette approche ouvre une perspective importante : renforcer le contrôle externe sans exiger que l'auditeur reçoive le modèle en totalité.
Il faut néanmoins garder la tête froide. Une démonstration technique n'est pas une garantie absolue. Le niveau de confiance se déplace vers le matériel sécurisé et la façon dont il est administré. Des travaux ont déjà montré que ce type de matériel peut faire l'objet d'attaques avec des moyens relativement limités, à condition d'obtenir un accès physique au serveur. Le risque ne disparaît pas : il doit être traité dans l'analyse de sécurité.
En pratique, il faut donc regarder qui contrôle les machines, où elles sont hébergées, comment les clés sont gérées, quelles traces sont conservées et comment les mises à jour sont vérifiées. Dire « sécurisé » n'a de sens que si le modèle de menace est explicitement défini. Pour une entreprise européenne, cela implique aussi de vérifier les conditions d'hébergement, les transferts éventuels de données et les responsabilités prévues au contrat.
Ce que cette méthode ne résout pas
Un test à l'aveugle ne fait pas disparaître tous les problèmes de gouvernance. Il réduit le risque que le fournisseur connaisse les questions, mais il ne garantit pas que les scénarios choisis couvrent vraiment les risques importants. Il ne tranche pas non plus le niveau de risque acceptable, la qualité des données utilisées, ni la façon d'interpréter les résultats.
L'audit doit donc s'inscrire dans un cadre plus large : tests techniques, analyse des usages, suivi des incidents après déploiement et réévaluation quand le modèle change. Un modèle peut se comporter différemment selon son intégration, les instructions qu'on lui donne et les données auxquelles l'application le connecte. Tester un modèle « isolé » ne suffit pas toujours à évaluer le système tel qu'il est réellement utilisé.
Le bon arbitrage n'est pas « tout donner » ou « faire confiance à l'aveugle ». Il consiste à donner à l'évaluateur les moyens de tester ce qui compte, à protéger les secrets qui n'ont pas besoin d'être révélés et à rendre visibles les limites de l'examen. C'est plus exigeant, mais plus réaliste que l'opposition frontale entre confidentialité totale et transparence totale.
Quelles garanties mettre en place en Europe ?
Pour les entreprises françaises et européennes, un accord américain ne s'applique pas tel quel à tous les usages. Il n'en reste pas moins un signal : le marché reconnaît la nécessité d'une évaluation externe. Le défi en Europe est de transformer cette idée en pratiques vérifiables, cohérentes avec les obligations applicables et adaptées aux risques de chaque activité.
Le règlement européen sur l'intelligence artificielle propose un cadre fondé sur les risques : les obligations varient selon la catégorie du système et son usage. Il ne faut donc pas confondre conformité réglementaire et audit indépendant. Un audit peut contribuer à documenter la maîtrise des risques, mais il ne remplace pas les obligations légales de l'entreprise. Le cadre européen de l'IA doit être lu en fonction du rôle de l'organisation, du système concerné et de son contexte de déploiement.
Il faut aussi tenir compte des données et des personnes. Si le système traite des données personnelles, la conformité au RGPD et les mesures de sécurité associées restent des sujets à documenter séparément. Tester le modèle ne démontre pas, à lui seul, que les données ont été collectées et traitées correctement. Pour cadrer ces questions, les entreprises peuvent consulter les ressources de la CNIL sur l'intelligence artificielle.
Un socle d'audit pragmatique
Une organisation qui achète ou déploie un système d'IA peut organiser son contrôle autour de six points :
- Définir l'usage réel. Le risque change selon que le modèle sert à rédiger un document interne ou qu'il intervient dans une décision sensible.
- Choisir des critères liés au métier. Se limiter à la performance moyenne peut masquer des erreurs coûteuses, des effets sur certains groupes ou des comportements en situation dégradée.
- Préserver l'indépendance des tests. L'évaluateur doit pouvoir concevoir une partie des scénarios et signaler ses limites d'accès, sans pression commerciale.
- Protéger les secrets sans couper le contrôle. Les environnements sécurisés peuvent limiter les transferts, à condition que leurs protections et leurs limites soient documentées.
- Publier un résumé exploitable. Même si le rapport détaillé reste confidentiel, l'organisation peut rendre public l'essentiel : identité de l'auditeur, périmètre, date et limites majeures.
- Suivre les corrections. Un audit qui signale un problème sans responsable, échéance et nouvelle vérification a peu de chances de changer quoi que ce soit.
Cette approche ne demande pas le même niveau d'effort à une jeune pousse et à un grand groupe du CAC 40. Elle sert surtout à proportionner : plus les conséquences d'une erreur sont importantes, plus les tests doivent être indépendants, documentés et répétés. C'est aussi un moyen de comparer des fournisseurs sans se noyer dans des promesses vagues.
Pour les éditeurs, une transparence minimale peut être un atout commercial durable. Pour les acheteurs, elle réduit le risque de s'en remettre à un rapport difficile à comparer. Pour les pouvoirs publics, elle offre une base plus solide pour contrôler les pratiques sans exiger la publication de secrets industriels. L'objectif n'est pas de tout rendre public : c'est de rendre les conditions du contrôle assez claires pour qu'un tiers puisse juger la portée de l'évaluation.
Conclusion : faire de l'audit un mécanisme vérifiable
Un audit externe n'a de valeur que si le tiers peut réellement examiner ce qui compte. Cela suppose une marge de manœuvre sur les tests, un accès adapté aux informations, une déclaration claire des limites et un mécanisme de suivi en cas de problème. La confidentialité du modèle est légitime ; elle ne devrait pas servir d'excuse pour bloquer tout contrôle indépendant.
Les tests en environnement sécurisé offrent une voie intermédiaire : entre la remise d'une copie du modèle et une évaluation entièrement pilotée par son fabricant. Ils ne remplacent ni la gouvernance ni les exigences publiques, mais ils rendent le compromis moins bloquant. La suite logique consiste à préciser qui contrôle les auditeurs et comment les entreprises rendent compte de leurs évaluations.
Si vous achetez ou déployez une solution d'IA, demandez dès maintenant qui a réalisé les tests, ce qu'ils couvrent et quelles sont leurs limites. C'est une question simple, mais elle sépare un contrôle vérifiable d'une promesse difficile à juger.