Auditer ses algorithmes : se préparer aux exigences de l'IA Act en pratique
Une méthode opérationnelle pour transformer l'IA Act en registre, preuves, contrôles et suivi continu, sans attendre l'audit réglementaire.
L'IA Act ne se prépare pas avec une note juridique isolée. Il se prépare avec un inventaire vivant des systèmes, une classification argumentée des risques, des preuves techniques et une capacité à surveiller les usages après mise en production. Pour beaucoup d'organisations, le sujet n'est donc pas seulement la conformité. C'est la capacité à expliquer comment une décision algorithmique est conçue, testée, déployée, contrôlée et corrigée.
Le règlement européen sur l'intelligence artificielle, publié comme règlement (UE) 2024/1689, installe une logique graduée: pratiques interdites, obligations de transparence, systèmes à haut risque, modèles d'IA à usage général et responsabilités des acteurs qui fournissent ou déploient ces systèmes. La Commission européenne rappelle que le texte est entré en vigueur le 1er août 2024, avec une applicabilité progressive: interdictions dès 2025, obligations GPAI depuis le 2 août 2025, puis obligations larges à partir du 2 août 2026. L'enjeu immédiat pour une entreprise est simple: ne pas découvrir son périmètre au moment où une autorité, un client ou un auditeur demandera des preuves.
1. Partir d'un inventaire, pas d'une liste d'outils
Le premier livrable d'un audit IA Act n'est pas un tableau de conformité. C'est un registre des systèmes d'IA réellement utilisés: produits internes, modules intégrés dans un logiciel tiers, assistants génératifs, modèles de scoring, outils RH, systèmes de recommandation, workflows RAG, automatisations documentaires ou agents connectés à des 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 les responsables métier. Cette granularité évite deux erreurs fréquentes: sous-estimer un système parce qu'il est acheté comme simple SaaS, ou surclasser une expérimentation interne qui n'a pas d'effet significatif sur une personne.
La question centrale devient: quel effet le 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 influence l'accès à un service essentiel.
2. Classer les risques avec une justification traçable
La classification est le coeur de l'audit. Elle doit être compréhensible par un juriste, mais assez précise pour un architecte ou un responsable produit. L'IA Act repose sur une approche par risques: certaines pratiques sont interdites; d'autres relèvent d'obligations de transparence; les systèmes à haut risque déclenchent des exigences beaucoup plus lourdes; les modèles d'IA à usage général ont leur propre régime, renforcé lorsque le modèle présente un risque systémique.
Pour chaque système, l'audit doit documenter la conclusion et le raisonnement. Dire "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 peut changer de qualification si son usage évolue.
La bonne pratique consiste à séparer trois niveaux. D'abord, la classification réglementaire. Ensuite, le risque opérationnel: erreurs, dérives, hallucinations, biais, sécurité, exposition de données. Enfin, le risque contractuel et réputationnel: engagement client, fournisseur critique, dépendance à un modèle externe, difficulté à expliquer une décision.
3. Transformer les obligations en preuves vérifiables
Un audit efficace ne se contente pas de cocher des exigences. Il associe chaque obligation pertinente à une preuve. Pour un système à haut risque, les preuves attendues peuvent couvrir 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 lorsqu'un système n'est pas à haut risque, cette logique de preuve reste utile. Elle donne une méthode pour répondre aux clients grands comptes, aux appels d'offres, aux audits internes et aux équipes sécurité. 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 vite décorative. Elle doit être liée au cycle de vie du système: version du modèle, changement de fournisseur, ajout d'une source RAG, modification de prompt système, nouvelle population d'utilisateurs, incident ou retour terrain.
4. Auditer les fournisseurs et les modèles GPAI
Beaucoup de systèmes d'entreprise reposent sur des modèles d'IA à usage général. Les obligations ne portent donc pas uniquement sur l'application interne. Elles dépendent aussi de la chaîne fournisseur: 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é/sécurité pour les modèles les plus avancés. Ce code ne remplace pas le règlement, mais il donne un repère opérationnel utile: documentation modèle, politiques copyright, gestion des risques systémiques, mécanismes d'évaluation et gouvernance de sécurité.
Pour une entreprise utilisatrice, l'audit fournisseur doit vérifier des points concrets: documentation disponible, conditions de traitement des données, conservation des prompts, possibilité d'exclure les données d'entraînement, localisation, sous-traitants, clauses de responsabilité, engagement sur les logs, mécanismes de signalement d'incident et capacité à fournir des informations si une autorité le demande.
5. Mettre en place un contrôle continu
La tentation est de traiter l'IA Act comme un projet ponctuel. C'est rarement suffisant. 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 audit robuste doit donc installer un contrôle continu.
Ce 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.
6. Plan d'action en 30 jours
Pour sortir du flou, Noolya recommande un cadrage court en cinq étapes. D'abord, inventorier les usages IA existants et prévus. Ensuite, classifier les risques avec une justification écrite. Troisièmement, identifier les preuves disponibles et les manques. Quatrièmement, prioriser trois à cinq systèmes sensibles pour un audit approfondi. Enfin, installer un rituel de mise à jour du registre et de revue des nouveaux cas d'usage.
Cette approche évite deux extrêmes: le grand programme de conformité trop lourd pour démarrer, et l'attentisme qui repousse tout à 2026. Elle permet aussi de faire dialoguer les bons acteurs: juridique, sécurité, data, métiers, achats, DPO, architecture et direction produit.
Conclusion
L'audit IA Act ne doit pas être vu comme une formalité documentaire. C'est une discipline de maîtrise des systèmes d'IA. Les organisations qui seront prêtes ne seront pas forcément celles qui auront produit le plus de politiques internes, mais celles qui sauront répondre rapidement à 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 ?
