Assurance IA : prouver qu’un système d’IA tient ses promesses

L’essentiel

• L’assurance IA désigne le processus qui consiste à mesurer, évaluer et communiquer ce qu’un système d’IA fait réellement. Elle produit des preuves, pas des opinions.
• Le mot prête à confusion en français : il ne s’agit pas d’assurance au sens assurantiel, mais de garantie démontrable, au sens de l’assurance qualité.
• Sous le règlement IA, la majorité des fournisseurs de systèmes à haut risque s’auto-évaluent. Le dispositif interne d’assurance IA n’est donc pas la préparation à l’évaluation de la conformité : il en constitue le cœur.
• La norme ISO/IEC 42001 certifie le système de management. La norme ISO/IEC 42006:2025 encadre les organismes autorisés à délivrer ce certificat, ce que presque personne ne mentionne.
• Un certificat porte une date, un modèle porte une version. C’est pourquoi l’assurance doit être continue plutôt qu’annuelle.

Ce que recouvre vraiment l’assurance IA

Une précision de vocabulaire s’impose avant toute chose. En français, le terme « assurance » évoque spontanément le contrat et la police. Ici, il faut l’entendre au sens de l’assurance qualité : la démarche par laquelle une organisation établit, preuves à l’appui, qu’un système se comporte comme elle l’affirme. Les praticiens anglophones parlent d’AI assurance, et la traduction fidèle reste « assurance des systèmes d’IA ».

La définition de référence vient du gouvernement britannique, qui décrit l’assurance IA comme le processus consistant à mesurer, évaluer et communiquer la fiabilité d’un système. Chacun de ces trois verbes porte une exigence distincte.

Mesurer suppose de collecter des données sur le comportement effectif du système : justesse par sous-population, modes de défaillance, tenue en charge, réaction à des entrées jamais rencontrées à l’entraînement. Évaluer consiste à confronter ces mesures à un référentiel que quelqu’un d’autre reconnaît, qu’il s’agisse d’une norme, d’un seuil réglementaire ou d’un appétit au risque formalisé. Communiquer revient à porter le résultat devant ceux qui doivent en tirer des conséquences, sous une forme qu’ils peuvent contester.

La distinction décisive oppose l’assurance et la fiabilité elle-même. La fiabilité est une propriété que l’on affirme d’un système. L’assurance est le dispositif qui rend cette affirmation vérifiable. Une organisation peut disposer d’un modèle réellement bien conçu et d’aucune assurance, faute de pouvoir le démontrer à un tiers. La situation inverse existe aussi, plus dangereuse : une documentation abondante qu’aucune mesure ne soutient.

C’est la raison pour laquelle l’assurance IA s’inscrit à l’intérieur de la gouvernance de l’IA et non à côté d’elle. La gouvernance arbitre ce que l’organisation s’autorise, désigne les responsables et fixe les seuils. L’assurance est la machinerie probatoire qui indique si ces arbitrages tiennent en production.

Assurance, audit, certification et évaluation de la conformité ne sont pas synonymes

Ces termes circulent comme s’ils étaient interchangeables. Ils ne le sont pas, et la confusion se paie au moment de commander une prestation.

Terme	Nature	Qui l’exécute	Ce qui en sort	Obligatoire ?
Assurance	Le processus global de mesure, d’évaluation et de communication de la fiabilité	Équipes internes, clients, prestataires indépendants	Des preuves et une affirmation étayée	Non, mais c’est ainsi que l’on satisfait ce qui l’est
Audit	Un mécanisme parmi d’autres : un examen structuré au regard de critères définis	Audit interne ou cabinet externe	Un rapport assorti de constats	Parfois, selon les règles sectorielles
Évaluation de la conformité	La procédure réglementaire européenne établissant qu’un produit satisfait aux exigences légales avant sa mise sur le marché	Le fournisseur lui-même ou un organisme notifié	Une déclaration de conformité et un marquage CE	Oui, pour les systèmes à haut risque
Certification	L’attestation par un tiers qu’un système de management respecte une norme	Un organisme certificateur accrédité	Un certificat assorti d’une échéance	Non, démarche volontaire
Accréditation	La vérification qu’un organisme certificateur est compétent	Un organisme national d’accréditation, le COFRAC en France	L’accréditation du certificateur	Concerne le certificateur, pas vous

Il en découle une conséquence pratique : un certificat ISO/IEC 42001 ne libère d’aucune obligation issue du règlement IA, et une évaluation de la conformité ne rend pas pour autant une gouvernance mature. Ces dispositifs répondent à des questions différentes, devant des interlocuteurs différents. L’audit IA est l’un des instruments qui alimentent l’assurance IA, et la qualité des preuves obtenues dépend étroitement du degré d’auditabilité prévu dès la conception. Rattraper ce retard après la mise en service coûte cher et laisse toujours des trous.

Les sept mécanismes d’assurance et ce que chacun démontre

Le guide britannique dresse une boîte à outils de mécanismes d’assurance IA. La lecture la plus utile ne consiste pas à y voir un catalogue d’activités, mais une liste de preuves, car c’est la preuve qui survit à la réunion.

1. L’analyse de risques identifie ce qui peut mal tourner et avec quelle gravité. Preuve produite : une cartographie assortie de propriétaires, de cotations et de décisions de traitement.
2. L’analyse d’impact regarde vers l’extérieur, du côté des personnes, des droits et de l’égalité de traitement. Preuve produite : une évaluation nommant les populations concernées et les mesures d’atténuation.
3. L’audit de biais examine entrées et sorties à la recherche d’écarts injustifiés. Preuve produite : des métriques par sous-population, avec la définition d’équité retenue explicitée. Le sujet est développé dans notre article sur les biais algorithmiques.
4. L’audit de conformité vérifie le respect des politiques internes, des textes et des engagements contractuels. Preuve produite : un relevé de constats contrôle par contrôle.
5. L’évaluation de la conformité démontre qu’un produit satisfait aux exigences légales avant sa commercialisation. Preuve produite : la documentation technique et la déclaration de conformité.
6. La vérification formelle recourt aux méthodes mathématiques pour prouver qu’un système satisfait une spécification. Preuve produite : une démonstration, dont les hypothèses doivent être écrites. Rare hors des domaines critiques, et jamais plus solide que ses hypothèses.
7. Les tests de performance confrontent le système à des jeux de référence et à des seuils. Preuve produite : des résultats datés, rattachés à une version précise du modèle. C’est le terrain de l’évaluation comparative des modèles.

Six de ces sept mécanismes produisent un document dont la valeur se dégrade avec le temps. Cette péremption constitue le vrai problème opérationnel de l’assurance IA, bien traité dans un dispositif mature de gestion des risques liés à l’IA, négligé partout ailleurs.

Qui réalise l’assurance IA : première, deuxième et tierce partie

L’assurance IA se classe selon celui qui l’exécute, et le degré d’indépendance change radicalement la valeur de l’affirmation obtenue.

L’assurance de première partie est une auto-évaluation : l’équipe qui a conçu le système l’évalue elle-même. Rapide, économique, parfaitement informée, structurellement en conflit d’intérêts. L’assurance de deuxième partie émane d’un acteur qui a un intérêt commercial dans le résultat, typiquement un client évaluant son fournisseur au moment de l’achat. L’assurance de tierce partie est conduite par un prestataire indépendant, sans intérêt dans l’issue : c’est la seule qui pèse devant un régulateur ou un acheteur méfiant.

Pourquoi le marché de la tierce partie reste immature

La feuille de route britannique sur l’assurance IA de tierce partie, publiée en septembre 2025, a chiffré le phénomène. Le marché britannique comptait environ 524 entreprises pour près de 1,01 milliard de livres de valeur en 2024, avec une projection à 18,8 milliards à l’horizon 2035 si les obstacles se lèvent.

Ces obstacles méritent d’être nommés, car ils expliquent la difficulté actuelle à acheter de l’assurance IA. La feuille de route relève un déficit de référentiels de qualité (les certifications IA existantes sont rarement accréditées), une pénurie de compétences croisant apprentissage automatique, droit, éthique et normalisation, un accès restreint à l’information (les fournisseurs ne communiquent ni données d’entraînement ni internes de modèle), et trop peu d’espaces de recherche sur les techniques d’assurance continue.

La réponse s’articule en trois modèles successifs : certification des praticiens à titre individuel d’abord, certification des processus ensuite, accréditation des cabinets enfin. Un fonds d’innovation de 11 millions de livres et un consortium présidé par la BCS accompagnent la démarche. Pour un acheteur, le signal est clair : pendant quelques années encore, il faudra vérifier soi-même les références du prestataire retenu, faute de définition stabilisée de la compétence en assurance IA.

Comment l’assurance IA alimente la chaîne de preuve du règlement IA

C’est ici que la plupart des guides s’arrêtent, et c’est précisément ce qui détermine l’exposition juridique.

L’article 43 du règlement européen prévoit deux voies d’évaluation de la conformité pour les systèmes à haut risque. La première repose sur le contrôle interne au titre de l’annexe VI et n’implique aucun organisme notifié. La seconde, au titre de l’annexe VII, fait intervenir un organisme notifié qui examine à la fois le système de management de la qualité et la documentation technique.

Le choix de la voie n’appartient pas au fournisseur dans la plupart des cas. Pour les systèmes relevant du point 1 de l’annexe III, qui couvre la biométrie, le fournisseur peut opter pour l’une ou l’autre. Pour les points 2 à 8 de l’annexe III, qui couvrent les infrastructures critiques, l’éducation, l’emploi, les services essentiels, la répression, la migration et l’administration de la justice, c’est la voie du contrôle interne qui s’applique. Une exception étroite confie le rôle d’organisme notifié à l’autorité de surveillance du marché lorsque le système est mis en service par des autorités répressives, migratoires ou par des institutions de l’Union.

La conséquence mérite d’être énoncée sans détour. Pour la grande majorité des systèmes à haut risque, personne ne viendra inspecter le système avant sa mise sur le marché. C’est le fournisseur lui-même qui signe la déclaration. Autrement dit, le dispositif interne d’assurance IA ne prépare pas l’évaluation de la conformité : il la constitue, et seule la qualité des preuves internes sépare une déclaration sincère d’une déclaration mensongère.

Ces preuves irriguent ensuite une chaîne d’obligations : documentation technique de l’annexe IV, déclaration UE de conformité, marquage CE, enregistrement dans la base de données européenne et surveillance après commercialisation. Chaque maillon consomme des artefacts que le dispositif d’assurance IA était censé produire. Cadrer tôt les exigences de documentation rend la suite praticable, et le paysage réglementaire ajoute des obligations parallèles dans d’autres juridictions. En France, la CNIL et l’ANSSI publient par ailleurs des orientations qui recoupent utilement ces attentes en matière de protection des données et de sécurité.

Ce que le report du Digital Omnibus vous laisse comme marge

Le calendrier a changé. Le Digital Omnibus est entré en vigueur le 27 juillet 2026 et, selon la Commission européenne, les règles applicables aux systèmes autonomes à haut risque de l’annexe III s’appliquent désormais à compter du 2 décembre 2027, tandis que celles visant l’IA intégrée à des produits réglementés relevant de l’annexe I s’appliquent au 2 août 2028.

L’applicabilité générale et les obligations de transparence, elles, n’ont pas été reportées et sont entrées en vigueur le 2 août 2026. La lecture correcte n’est donc pas celle d’un abandon. Les fournisseurs ont obtenu du temps supplémentaire parce que les normes et les outils n’étaient pas prêts. Les organisations qui traiteront cet intervalle comme un temps de construction disposeront d’une chaîne de preuve fonctionnelle à l’échéance. Celles qui y verront un répit reconstitueront trois années de documentation a posteriori, ce que le report visait précisément à éviter.

Les normes transforment l’assurance IA en quelque chose qu’un régulateur accepte

Le guide britannique le formule sans ménagement : « sans normes, nous avons des conseils, pas de l’assurance ». Une mesure ne signifie quelque chose que si l’étalon est partagé.

Trois strates comptent. La norme ISO/IEC 42001 spécifie le système de management de l’IA, c’est-à-dire l’appareillage organisationnel qui gouverne l’IA tout au long de son cycle de vie. En dessous, la norme ISO/IEC 42006:2025, publiée le 7 juillet 2025 par l’ISO/IEC JTC 1/SC 42, fixe les exigences applicables aux organismes qui auditent et certifient un système de management de l’IA, en s’appuyant sur ISO/IEC 17021-1. C’est la strate que presque tous les guides omettent, et elle répond à la question qu’un acheteur devrait toujours poser : qui a certifié le certificateur, et selon quels critères de compétence ?

Au-dessus se trouve le mécanisme des normes harmonisées. En vertu de l’article 40 du règlement, la conformité à une norme harmonisée publiée au Journal officiel confère une présomption de conformité à l’exigence légale correspondante. Les organismes européens de normalisation préparent des projets sous mandat M/593 ; ils ne sont pas encore publiés comme normes harmonisées, et tant qu’ils ne le sont pas, il revient au fournisseur de démontrer la suffisance de ses propres méthodes. Pour le vocabulaire de la mesure, le cadre NIST AI Risk Management Framework reste la langue commune la plus répandue, en particulier sa fonction Measure. Notre comparaison des référentiels aide à choisir celui sur lequel s’appuyer.

Certificat ponctuel ou assurance IA continue

Un certificat porte une date. Un modèle porte une version, et la version change.

Voilà la tension structurelle que la conformité classique n’avait jamais eu à affronter. Un contrôle financier testé en mars se comporte de la même manière en septembre. Un modèle réentraîné sur trois mois de données fraîches, pas nécessairement. Dérive des distributions, dérive de concept, modèle de fondation mis à jour sous votre application, invite modifiée, nouvelle source de données : chacun de ces événements peut invalider un résultat de test sans qu’aucune demande de changement ait été déposée.

La réponse du règlement s’appelle la surveillance après commercialisation, obligation permanente de suivre le comportement du système sur le terrain et d’agir sur ce qui remonte. La notion de modification substantielle joue un rôle voisin en définissant le seuil au-delà duquel une réévaluation s’impose. Les deux convergent : l’assurance est une fonction continue, et un audit annuel n’est qu’un instantané déjà périmé au moment de sa signature.

Concrètement, il faut instrumenter le système pour que la preuve se régénère selon une cadence et non au gré des projets. Métriques de performance périodiques, détection de dérive assortie de seuils, et un chemin défini entre l’anomalie détectée et la décision documentée. Le signalement des incidents referme la boucle en transformant les défaillances en événements tracés plutôt qu’en anecdotes de couloir.

Construire un modèle opérationnel d’assurance IA

L’unité de base de l’assurance IA est la preuve, et un modèle opérationnel tient pour l’essentiel à cinq champs attachés à chacune d’elles : l’affirmation qu’elle soutient, le contrôle qu’elle satisfait, la preuve elle-même, son propriétaire et sa date de production. Qu’un seul manque et l’artefact ne résistera pas à l’examen.

La répartition des rôles suit assez bien le modèle des trois lignes de maîtrise. La première ligne, les équipes qui conçoivent et exploitent les systèmes, produit la preuve. La deuxième, risques et conformité, définit la preuve attendue et vérifie son existence. La troisième, l’audit interne, teste en toute indépendance si les deux premières font leur travail. L’Institut des auditeurs internes positionne d’ailleurs explicitement l’audit interne comme fournisseur d’assurance sur l’IA, chargé de valider les contrôles internes qui encadrent le risque.

Un socle documentaire minimal couvre la cartographie des risques, les résultats de tests rattachés aux versions de modèle, la documentation des données incluant provenance et limites connues, les traces de supervision humaine attestant que les relecteurs ont effectivement relu, un journal des changements et un registre des incidents. Le modèle d’auto-évaluation de la sécurité publié par l’Alan Turing Institute, dans sa série sous licence ouverte consacrée à l’éthique et à la gouvernance de l’IA, constitue un point de départ gratuit et crédible. Il organise la sécurité autour de la performance, de la fiabilité, de la sécurité et de la robustesse, ce qui recoupe étroitement les exigences d’exactitude, de robustesse et de cybersécurité de l’article 15.

Le test du dispositif est simple. Choisissez une affirmation que votre organisation formule sur un système d’IA, puis tentez de la relier à un artefact daté doté d’un propriétaire. La plupart des organisations constatent que la chaîne se rompt dès la deuxième étape, et c’est exactement l’écart qu’un programme de conformité IA a vocation à combler.

Questions fréquentes

Qu’est-ce que l’assurance IA ?

L’assurance IA est le processus qui consiste à mesurer, évaluer et communiquer la fiabilité d’un système d’IA. Mesurer collecte des données sur son comportement réel, évaluer confronte ces données à un référentiel reconnu, communiquer porte le résultat devant ceux qui doivent décider. Le produit final est une preuve permettant à quelqu’un d’autre que l’équipe conceptrice de vérifier une affirmation.

L’assurance IA et l’audit IA, est-ce la même chose ?

Non. L’audit est un mécanisme parmi ceux de l’assurance IA : un examen structuré au regard de critères définis, qui débouche sur un rapport de constats. L’assurance IA est le processus englobant, qui comprend aussi l’analyse de risques et d’impact, les tests de performance, la surveillance et la restitution des résultats. Un audit isolé reste un instantané, pas une capacité d’assurance IA.

Le règlement IA impose-t-il une assurance de tierce partie ?

Le plus souvent non. L’article 43 oriente les systèmes à haut risque des points 2 à 8 de l’annexe III vers le contrôle interne de l’annexe VI, sans organisme notifié. Seuls les systèmes du point 1 de l’annexe III, relatifs à la biométrie, ouvrent un choix, avec une exception étroite confiant ce rôle à l’autorité de surveillance du marché. L’auto-évaluation est donc la règle, ce qui relève d’autant le niveau d’exigence sur les preuves internes.

Quelles normes soutiennent l’assurance IA ?

La norme ISO/IEC 42001 définit le système de management de l’IA. La norme ISO/IEC 42006:2025 fixe les exigences applicables aux organismes qui auditent et certifient au regard de la première. Le cadre NIST AI RMF fournit un vocabulaire de mesure largement partagé. En vertu de l’article 40 du règlement, les normes harmonisées publiées au Journal officiel conféreront une présomption de conformité, mais les projets européens concernés ne sont pas encore publiés à ce titre.

Qui peut réaliser une assurance IA ?

Les équipes internes, les clients et les prestataires indépendants le peuvent, et l’étiquette compte. L’assurance de première partie est une auto-évaluation, informée mais en conflit d’intérêts. La deuxième partie émane d’un acteur commercialement intéressé, souvent un client acheteur. La tierce partie est indépendante et pèse davantage à l’extérieur. Le marché n’étant pas stabilisé, vérifiez directement les références et la méthodologie plutôt que de vous fier à un logo.

À quelle fréquence renouveler l’assurance IA ?

Aussi souvent que le système change, ce qui pour la plupart des systèmes d’apprentissage automatique signifie en continu plutôt qu’une fois l’an. Rattachez la régénération des preuves à des déclencheurs : réentraînement, changement du modèle de fondation sous-jacent, nouvelle source de données, franchissement d’un seuil de dérive, incident signalé. Une réévaluation purement calendaire vous laissera défendre un certificat décrivant une version qui n’est plus en production.

Conclusion

L’assurance IA relève moins du projet que de l’habitude : produire de la preuve en continu pour qu’une affirmation puisse être étayée le jour où quelqu’un la conteste. Les organisations qui traverseront les prochaines années sans encombre ne sont pas celles dont les politiques sont les plus épaisses. Ce sont celles qui savent relier une affirmation à un artefact daté, en nommer le propriétaire et indiquer la date de sa dernière revalidation.

Les échéances européennes reportées, décembre 2027 pour les systèmes autonomes à haut risque et août 2028 pour les produits intégrés, constituent du temps de construction. Les obligations n’ont pas diminué, et la voie de l’auto-évaluation fait de la qualité de vos preuves internes le seul véritable garde-fou. Commencez par un système à haut risque et remontez une seule affirmation de bout en bout. Les trous que vous trouverez diront ce dont votre dispositif a réellement besoin.