Retour aux publications
IA ACT

Audit de conformité IA : le guide complet (AI Act 2026)

Le guide complet de l'audit de conformité IA : le calendrier AI Act réellement en vigueur après le report de juillet 2026, ce qu'est l'auditabilité d'un système, et une méthode de cadrage en six étapes.

8 min
Couverture éditoriale sur l'audit IA Act avec dossier de conformité européen

Un audit de conformité IA vérifie qu'un système d'intelligence artificielle respecte les obligations qui lui sont applicables, au premier rang desquelles le règlement européen sur l'IA. Il classe chaque système par niveau de risque, contrôle la documentation, la qualité des données, la traçabilité des décisions et la supervision humaine, puis produit un plan de remédiation hiérarchisé. Il se distingue d'un audit technique : l'objet du contrôle est la capacité à prouver la maîtrise du système, pas la performance du modèle.

Ce guide décrit la méthode que Noolya applique en mission, le calendrier réglementaire réellement en vigueur après le report de juillet 2026, et les six étapes qui font passer une organisation de « nous utilisons de l'IA quelque part » à « voici nos systèmes, leur classification, nos preuves et notre dispositif de surveillance ».

Que dit exactement le calendrier de l'AI Act en 2026 ?

Le calendrier a changé cet été, et beaucoup de plans de conformité rédigés en 2025 sont désormais faux sur les dates.

Le règlement (UE) 2024/1689, dit AI Act, est entré en vigueur le 1er août 2024 avec une application progressive. Le règlement (UE) 2026/1744, dit « omnibus numérique IA », publié au Journal officiel le 24 juillet 2026 et entré en vigueur trois jours plus tard, a repoussé les échéances les plus lourdes.

ÉchéanceCe qui s'applique
2 février 2025Interdiction des pratiques d'IA inacceptables (article 5)
2 août 2025Obligations des modèles d'IA à usage général (GPAI)
2 août 2026Transparence de l'article 50, obligation de littératie IA de l'article 4, pouvoirs de sanction
2 décembre 2026Systèmes mis sur le marché avant août 2026 ; interdictions complémentaires
2 décembre 2027Systèmes à haut risque autonomes de l'annexe III — recrutement, crédit, éducation, biométrie (reporté du 2 août 2026)
2 août 2028Systèmes à haut risque intégrés à des produits réglementés de l'annexe I — dispositifs médicaux, jouets, machines

Deux conséquences pratiques. D'abord, une organisation dont les systèmes relèvent de l'annexe III gagne seize mois : c'est une respiration, pas une dispense. Ensuite, ce qui s'applique depuis le 2 août 2026 s'applique à tout le monde : un chatbot doit indiquer qu'il est une IA, un contenu généré doit être identifiable, et l'obligation de former les personnes qui manipulent ces systèmes est due maintenant.

L'erreur à ne pas commettre est de lire le report comme une raison d'arrêter. Les entreprises qui ont commencé leur inventaire en 2025 disposent aujourd'hui d'un actif — la connaissance de leur propre parc — que le report ne dévalue pas.

Qu'est-ce que l'auditabilité d'un système d'IA ?

L'auditabilité d'un système d'IA est sa capacité à être contrôlé par un tiers : reconstituer une décision, savoir sur quelles données le modèle a été entraîné, retrouver qui l'a validé et quand, et démontrer qu'un humain peut intervenir.

C'est la notion la plus mal comprise du sujet, parce qu'elle est contre-intuitive : un système peut fonctionner parfaitement et rester non conforme, si la preuve du contrôle fait défaut. L'inverse est vrai aussi — un système médiocre mais parfaitement documenté et surveillé est en meilleure posture réglementaire.

Concrètement, l'auditabilité repose sur quatre capacités :

  1. Rejouer. Retrouver, pour une décision donnée, la version du modèle, le prompt système, les documents mobilisés et les paramètres actifs à cet instant.
  2. Tracer. Disposer de journaux conservés assez longtemps et assez détaillés pour reconstituer une séquence, sans stocker plus de données personnelles que nécessaire.
  3. Attribuer. Savoir qui a validé la mise en production, qui a modifié le prompt, qui a ajouté une source à la base documentaire.
  4. Interrompre. Prouver qu'un opérateur humain peut passer outre, suspendre ou corriger la décision — et que cette possibilité est réelle, pas théorique.

La plupart des organisations découvrent leur retard exactement ici. Le système existe, il fonctionne, les utilisateurs sont contents. Mais personne ne sait dire quelle version du prompt tournait il y a trois mois.

Audit de conformité ou audit de maturité IA : lequel faut-il ?

Les deux répondent à des questions différentes, et les confondre fait perdre du temps.

Un audit de maturité IA évalue la capacité d'une organisation à tirer de la valeur de l'IA : qualité et accessibilité des données, compétences internes, processus, gouvernance, portefeuille de cas d'usage. Il répond à « que pouvons-nous faire, et par quoi commencer ? ».

Un audit de conformité IA vérifie le respect d'obligations réglementaires. Il répond à « avons-nous le droit, et pouvons-nous le prouver ? ».

Audit de maturitéAudit de conformité
Question poséeQue pouvons-nous faire ?Avons-nous le droit ?
ObjetL'organisationLes systèmes
DéclencheurAmbition, budget, concurrenceRéglementation, client, appel d'offres
LivrableFeuille de route prioriséeRegistre, classification, plan de remédiation
ÉchéanceInterneRéglementaire

En pratique, les deux se conduisent souvent ensemble : un cas d'usage prometteur mais non conforme ne passe jamais en production, et un système parfaitement conforme sur un cas d'usage sans valeur est un coût pur.

Étape 1 : partir d'un inventaire, pas d'une liste d'outils

Le premier livrable d'un audit AI Act n'est pas un tableau de conformité, c'est un registre des systèmes d'IA réellement utilisés.

Ce registre couvre les produits internes, les modules intégrés dans un logiciel tiers, les assistants génératifs, les modèles de scoring, les outils RH, les systèmes de recommandation, les workflows RAG, les automatisations documentaires et les agents connectés aux données métier.

Un bon inventaire ne décrit pas seulement le nom de l'outil. Il précise le cas d'usage, les utilisateurs, les données traitées, les décisions influencées, le fournisseur, le modèle sous-jacent quand il est connu, les intégrations, les journaux disponibles et le responsable métier. Cette granularité évite deux erreurs fréquentes : sous-estimer un système parce qu'il est acheté comme simple SaaS, et surclasser une expérimentation interne sans effet significatif sur une personne.

La question centrale n'est pas « quel outil est-ce ? » mais « quel effet ce système produit-il dans le monde réel ? ». Un assistant qui reformule des emails marketing ne soulève pas les mêmes exigences qu'un outil qui priorise des dossiers de recrutement, attribue un niveau de risque client ou conditionne l'accès à un service essentiel.

Étape 2 : classer les risques avec une justification traçable

La classification est le cœur de l'audit, et sa valeur tient entièrement à la justification écrite qui l'accompagne.

L'AI Act repose sur quatre niveaux : les pratiques inacceptables sont interdites ; les systèmes à haut risque déclenchent les exigences les plus lourdes ; les systèmes à risque limité relèvent d'obligations de transparence ; les systèmes à risque minimal ne portent pas d'obligation spécifique. Les modèles d'IA à usage général ont leur propre régime, renforcé lorsqu'ils présentent un risque systémique.

Pour chaque système, l'audit documente la conclusion et le raisonnement. Écrire « non haut risque » ne suffit pas : il faut expliquer pourquoi — finalité, population concernée, niveau d'autonomie, rôle de l'humain, données utilisées, impact potentiel, contexte sectoriel, dépendance à un fournisseur externe. Cette justification doit rester révisable, car un même composant change de qualification si son usage évolue.

La bonne pratique consiste à séparer trois plans :

  • le risque réglementaire — la qualification au sens du texte ;
  • le risque opérationnel — erreurs, dérives, hallucinations, biais, sécurité, exposition de données ;
  • le risque contractuel et réputationnel — engagement client, fournisseur critique, difficulté à expliquer une décision.

Les trois ne se recoupent pas. Un système hors périmètre réglementaire peut porter un risque réputationnel majeur.

Étape 3 : transformer les obligations en preuves vérifiables

Un audit utile associe chaque obligation à une preuve qui existe et qu'on peut montrer.

Pour un système à haut risque, les preuves attendues couvrent le système de gestion des risques, la gouvernance des données, la documentation technique, les journaux, la transparence envers les utilisateurs, le contrôle humain, l'exactitude, la robustesse et la cybersécurité.

Même hors haut risque, cette logique reste payante : c'est elle qui permet de répondre à un client grand compte, à un appel d'offres ou à une équipe sécurité sans repartir de zéro. Les preuves peuvent être simples — fiche d'architecture, procédure de validation, registre des prompts sensibles, plan de tests, matrice d'accès aux données, politique de conservation des logs, analyse d'impact, clause fournisseur, procédure d'escalade humaine.

Le point critique est la fraîcheur. Une preuve figée dans un dossier partagé devient décorative en trois mois. Elle doit être rattachée au cycle de vie du système : version du modèle, changement de fournisseur, ajout d'une source documentaire, modification du prompt système, nouvelle population d'utilisateurs, incident.

Étape 4 : auditer les fournisseurs et les modèles GPAI

La conformité ne s'arrête pas à la frontière de l'entreprise, parce que la plupart des systèmes reposent sur des modèles fournis par des tiers.

Les obligations dépendent de la chaîne : modèle de fondation, API, couche d'orchestration, outil SaaS, prestataire d'intégration. La Commission européenne a publié un Code de pratique pour les modèles d'IA à usage général, structuré autour de la transparence, du droit d'auteur et de la sûreté des modèles les plus avancés. Ce code ne remplace pas le règlement mais donne un repère opérationnel.

Pour une entreprise utilisatrice, l'audit fournisseur vérifie des points concrets : documentation disponible, conditions de traitement des données, conservation des prompts, possibilité d'exclure ses données de l'entraînement, localisation, sous-traitants, clauses de responsabilité, engagement sur les journaux, mécanisme de signalement d'incident, et capacité du fournisseur à produire des informations si une autorité en fait la demande.

Un contrat signé avant 2024 ne couvre presque jamais ces points. C'est souvent le chantier le plus long, parce qu'il dépend d'un tiers.

Étape 5 : installer un contrôle continu

Traiter l'AI Act comme un projet ponctuel ne fonctionne pas, parce que les systèmes d'IA changent plus vite que les applications classiques.

Modèle remplacé, prompt enrichi, base documentaire mise à jour, nouveau connecteur, nouveau pays, nouvelle équipe utilisatrice : un registre juste au moment de l'audit est faux six mois plus tard. Le dispositif de contrôle peut rester léger au départ — comité mensuel des nouveaux cas d'usage, formulaire de qualification, seuils d'escalade, revue fournisseur, registre des incidents, revue trimestrielle des systèmes sensibles.

L'objectif n'est pas de ralentir l'innovation mais de rendre les arbitrages explicites. Un système peu risqué doit pouvoir avancer vite. Un système qui touche à l'emploi, au crédit, à l'éducation, à la santé, aux services publics ou à l'accès à des droits doit être ralenti, documenté et testé avec plus d'exigence.

Étape 6 : un plan de cadrage en 30 jours

Un audit complet prend des mois. Un cadrage utile prend trente jours et sort l'organisation du flou.

  1. Jours 1 à 7 — inventorier. Recenser les usages IA existants et prévus, y compris l'IA embarquée dans les logiciels déjà achetés.
  2. Jours 8 à 14 — classifier. Attribuer un niveau de risque à chaque système, avec la justification écrite.
  3. Jours 15 à 21 — confronter aux preuves. Pour les systèmes sensibles, lister ce qui existe et ce qui manque.
  4. Jours 22 à 26 — prioriser. Retenir trois à cinq systèmes pour un audit approfondi, sur le critère impact × écart.
  5. Jours 27 à 30 — installer le rituel. Fixer qui met le registre à jour, à quelle fréquence, et par quel circuit un nouveau cas d'usage entre.

Cette approche évite deux extrêmes : le programme de conformité trop lourd pour démarrer, et l'attentisme qui repousse tout au prochain report. Elle fait aussi dialoguer les bons acteurs — juridique, sécurité, data, métiers, achats, DPO, architecture, direction produit — ce qui est souvent le vrai bénéfice de l'exercice.

Combien coûte la non-conformité ?

Les sanctions de l'AI Act sont calées sur le chiffre d'affaires mondial, ce qui les rend significatives pour un groupe comme pour une PME en croissance.

Le règlement prévoit jusqu'à 35 millions d'euros ou 7 % du chiffre d'affaires annuel mondial pour les pratiques interdites de l'article 5, le montant le plus élevé étant retenu. Les manquements aux autres obligations des opérateurs relèvent d'un plafond inférieur, et la fourniture d'informations incorrectes aux autorités d'un plafond inférieur encore. Les pouvoirs de sanction sont effectifs depuis le 2 août 2026.

Le coût réel est rarement l'amende. C'est l'appel d'offres perdu parce qu'on ne sait pas répondre au questionnaire IA du client, le déploiement suspendu parce que le juridique découvre le sujet trop tard, ou le fournisseur qu'il faut remplacer en urgence.

Questions fréquentes

Faut-il un audit de conformité IA si l'entreprise n'utilise que des outils achetés ? Oui. Une entreprise qui utilise un système d'IA fourni par un tiers est déployeur au sens du règlement et supporte ses propres obligations — notamment la supervision humaine, l'information des personnes concernées et l'usage conforme à la destination prévue. L'achat ne transfère pas la responsabilité au fournisseur.

Le report de décembre 2027 dispense-t-il de faire quelque chose maintenant ? Non. Le report concerne les obligations des systèmes à haut risque de l'annexe III. Les obligations de transparence de l'article 50, l'obligation de littératie IA de l'article 4 et les pouvoirs de sanction s'appliquent depuis le 2 août 2026. Par ailleurs, l'inventaire et la classification prennent plusieurs mois : les commencer maintenant, c'est arriver prêt.

Combien de temps dure un audit de conformité IA ? Un cadrage se conduit en trente jours. Un audit approfondi sur trois à cinq systèmes sensibles court sur quelques semaines supplémentaires, selon la disponibilité de la documentation et la coopération des fournisseurs. C'est presque toujours l'accès à l'information, pas l'analyse, qui fixe la durée.

Qui doit porter le sujet en interne ? Aucune fonction seule n'y arrive. Le juridique connaît le texte mais pas les systèmes ; la DSI connaît les systèmes mais pas les obligations ; les métiers connaissent les usages réels, souvent inconnus des deux autres. Le dispositif qui fonctionne rassemble ces trois angles autour d'un registre unique, avec un arbitre désigné.

Quelle est la première erreur à éviter ? Commencer par rédiger une politique. Une politique interne sans inventaire décrit une organisation qui n'existe pas. L'ordre qui marche est : inventaire, classification, preuves, puis politique — la politique documente ce qui est vrai, elle ne le crée pas.

Conclusion

L'audit de conformité IA n'est pas une formalité documentaire, c'est une discipline de maîtrise. Les organisations prêtes ne seront pas celles qui auront produit le plus de politiques internes, mais celles qui sauront répondre vite à quatre questions : quels systèmes utilisons-nous, pourquoi sont-ils classés ainsi, quelles preuves soutiennent cette classification, et comment détectons-nous les dérives après déploiement ?

Le report de juillet 2026 ne change pas la réponse. Il donne seize mois de plus pour la construire.

Pour situer ce sujet dans une démarche complète, Noolya détaille l'audit de conformité IA et l'AI Act.

Les cinq volets détaillés

Ce guide est le point d'entrée de la grappe conformité. Chaque étape est développée dans un article dédié.

Pour aller plus loin


Sources principales