AI-Evident
Beaucoup d'organisations s'arrêtent à la première question de l'AI Act (le Règlement européen sur l'intelligence artificielle, aussi désigné IA Act) :
C'est une étape nécessaire, mais elle ne dit rien de ce qui doit réellement changer dans la façon dont le système est conçu, documenté et exploité. Une fois la classification posée, sept obligations concrètes s'appliquent, et ce sont elles qui déterminent le vrai travail à mener. Ces obligations s'appliqueront à partir du 2 décembre 2027 pour les systèmes relevant de l'annexe III, et du 2 août 2028 pour ceux intégrés à des produits réglementés (annexe I), depuis le report prévu par le règlement (UE) 2026/1744.
Un système de gestion des risques qui vit dans le temps (article 9)
Il ne s'agit pas d'un document produit une fois et archivé. La loi exige un processus itératif : identifier les risques prévisibles, définir des mesures d'atténuation, puis revoir cette analyse à intervalles réguliers, tout au long de la vie du système. Un système mis en production sans révision depuis dix-huit mois ne serait plus, en pratique, dans les clous de cette exigence, même si le dossier initial était parfait.
Une gouvernance des données qui interroge la représentativité (article 10)
Les données d'entraînement, de validation et de test doivent être examinées pour leur qualité et leur représentativité par rapport à la population réellement concernée par le système. C'est un point souvent sous-estimé : auditer un jeu de données pour détecter un déséquilibre ou un biais prend du temps, et corriger ce qui est trouvé (rééquilibrer les données, ré-entraîner un modèle) en prend davantage encore. L'audit et la correction sont deux étapes distinctes, avec des acteurs différents : l'audit relève souvent d'une expertise de gouvernance, la correction reste un travail technique confié aux équipes data. Cette exigence recoupe d'ailleurs largement des obligations RGPD déjà connues des équipes data, mais l'AI Act y ajoute une dimension de performance et de robustesse statistique spécifique.
Une documentation technique qui tient l'épreuve d'un contrôle (article 11 et annexe IV)
Architecture, algorithmes, données utilisées, mesures de supervision, performances mesurées : la documentation technique doit être suffisamment précise pour qu'un tiers puisse comprendre comment le système fonctionne et vérifier sa conformité. Un dossier rédigé après coup, reconstitué de mémoire, se voit presque toujours, et c'est justement ce genre de dossier qui pose problème en cas de contrôle.
Une capacité de journalisation pensée dès la conception (article 12)
Le système doit pouvoir enregistrer automatiquement les événements pertinents sur toute sa durée de vie. C'est probablement l'exigence la plus technique des sept : elle suppose de définir précisément quoi logger, où, avec quelle durée de conservation, et de vérifier que ces journaux sont réellement exploitables en cas de besoin, pas seulement qu'ils existent.
Une notice d'utilisation qui dit aussi les limites (article 13)
Les utilisateurs du système (souvent une autre organisation, quand le système est vendu à un tiers) doivent recevoir une information claire sur ses capacités, ses limites, et le niveau de précision à en attendre. Une documentation commerciale qui ne parle que des points forts ne répond pas à cette exigence.
Une supervision humaine qui a un pouvoir réel (article 14)
Prévoir une supervision humaine ne veut pas dire ajouter un bouton de validation que personne ne regarde vraiment. La loi attend une supervision effective : la personne en charge doit comprendre les capacités et les limites du système, être en mesure de détecter une anomalie, et avoir un pouvoir réel d'interruption. C'est une différence de fond entre une supervision de façade et une supervision qui compte réellement en cas de dérive.
Une robustesse testée, pas supposée (article 15)
Exactitude, résistance aux erreurs, résilience face aux tentatives de manipulation : ces propriétés doivent être vérifiées, pas simplement présumées parce que le système fonctionne bien en conditions normales. Un système qui n'a jamais été testé dans des conditions dégradées ou face à des entrées volontairement trompeuses n'a, en réalité, pas encore démontré sa robustesse.
Ce que ça change en pratique
Ces sept exigences ont un point commun : chacune distingue implicitement un travail de diagnostic (identifier, auditer, documenter) et un travail d'exécution (corriger, implémenter, tester). Traiter uniquement le premier volet donne un dossier de conformité qui semble complet sur le papier, mais qui laisse le système lui-même inchangé. C'est précisément l'écart qui expose une organisation en cas de contrôle réel, et c'est le chantier qui demande le plus de méthode pour être mené correctement, système par système. Notre audit de conformité AI Act est le point de départ pour mesurer cet écart.
📎 Référence : règlement (UE) 2024/1689.
Calendrier de l'AI Act
-
Entrée en vigueur du règlement (UE) 2024/1689 (AI Act).
-
Pratiques interdites (article 5) et maîtrise de l'IA (article 4).
-
Obligations des fournisseurs de modèles d'IA à usage général.
-
Entrée en vigueur du règlement (UE) 2026/1744 (« Omnibus »), publié au Journal officiel le 24 juillet 2026. Il assouplit notamment l'article 4.
-
Application générale du règlement (hors obligations du haut risque), dont les obligations de transparence (article 50).
-
Deux nouvelles pratiques interdites ; fin du délai accordé aux fournisseurs pour le marquage des contenus générés par les systèmes mis sur le marché avant le 2 août 2026.
-
Obligations des systèmes à haut risque de l'annexe III.
-
Obligations des systèmes à haut risque intégrés à des produits réglementés (annexe I).
Machines : d'ici cette date, le règlement (UE) 2023/1230 passe de la section A à la section B de l'annexe I. Les exigences de l'AI Act y seront intégrées par actes délégués de la Commission.
Dernière vérification : 8 octobre 2026 — sources : règlement (UE) 2024/1689, règlement (UE) 2026/1744, règlement (UE) 2023/1230.