Conformité IA : cadre juridique, risques et étapes pratiques
Vous venez probablement de découvrir que l'IA n'est plus seulement un sujet d'outil ou de productivité, mais un sujet de preuve. Pour une PME, un cabinet ou un DPO externalisé, le vrai problème n'est pas de savoir si l'IA est utile. C'est de savoir ce qu'il faut cartographier, documenter, former et démontrer, sans transformer la conformité en usine à gaz.
En France, la conformité IA ne repose pas sur un seul texte. Elle s'appuie sur le AI Act, le RGPD et les recommandations de la CNIL, qui se complètent et se renforcent. Depuis février 2025, l’article 4 de l'AI Act impose aussi une logique d’alphabétisation IA, autrement dit une capacité à former les équipes et à conserver des preuves de cette montée en compétence.
Table des matières
- Les trois piliers réglementaires de la conformité IA en France
- Comprendre les quatre niveaux de risque de l'AI Act
- L'obligation d'alphabétisation IA expliquée clairement
- Articuler le RGPD et l'AI Act sur les données personnelles
- Construire une chaîne de preuve technique et organisationnelle
- Adapter la conformité IA aux PME sans DSI ni juriste interne
- Checklist opérationnelle pour démarrer votre mise en conformité
Les trois piliers réglementaires de la conformité IA en France
La première erreur consiste à traiter l'AI Act comme un monde à part. En pratique, une organisation française doit composer avec trois couches qui s'additionnent, le règlement européen sur l'IA, le RGPD et le cadre national rappelé par la CNIL. La conformité IA n'efface pas la conformité données, elle s'y superpose.
La CNIL a publié en 2023 des recommandations utiles pour les systèmes d'IA, en rappelant que les personnes concernées doivent être informées et que l'usage de données pour la recherche ou la statistique doit rester compatible avec la finalité initiale. Elle précise aussi que l'analyse du statut d'un modèle au regard du RGPD peut passer par des tests de réidentification fondés sur des moyens raisonnablement susceptibles d'être utilisés, ce qui ancre la conformité dans une logique de preuve technique. Vous pouvez retrouver ce point de départ dans les recommandations CNIL sur le développement des systèmes d'IA.
Règle pratique. Si un dossier IA ne dit pas qui utilise le système, sur quelles données, avec quelle base légale et avec quelles preuves de contrôle, le dossier est incomplet.
Pour une PME, le point le plus concret est le suivant. L'AI Act introduit des obligations nouvelles, notamment l’alphabétisation IA, tandis que le RGPD continue d'imposer une finalité précise, des bases légales documentées et des droits pour les personnes. Les deux cadres ne se concurrencent pas, ils se cumulent.
Une lecture utile consiste à garder en tête cette hiérarchie simple.
- AI Act, pour qualifier le niveau de risque et imposer des obligations adaptées.
- RGPD, pour sécuriser les traitements de données personnelles.
- CNIL, pour traduire le tout en exigences de terrain, surtout sur l'information, la compatibilité des usages et la démonstration de maîtrise.
Pour aller plus loin sur le versant données personnelles, consultez le guide RGPD et IA de IATOLL.
Comprendre les quatre niveaux de risque de l'AI Act
Le bon réflexe n'est pas de demander d'abord “est-ce que l'outil est conforme ?”, mais “dans quelle catégorie de risque tombe-t-il ?”. La Commission européenne classe les systèmes d'IA en quatre niveaux, risque inacceptable, haut risque, risque limité et risque minimal, et les obligations changent fortement selon le niveau. France Digitale résume bien la logique, avec des systèmes interdits au sommet du risque, des systèmes à haut risque soumis à marquage CE, et des systèmes plus modestes surtout encadrés par l'information des utilisateurs ou des codes de conduite volontaires, comme l'explique ce guide sur la conformité AI Act.
Le bon usage de cette grille, c'est la cartographie. Une entreprise peut avoir un chatbot interne, un outil de recrutement, un scoring commercial et un générateur de contenus, mais ces usages n'emportent pas la même charge réglementaire. Tant qu'on ne les a pas classés, on mélange tout. Et quand on mélange tout, on surinvestit au mauvais endroit.
| Niveau de risque AI Act | Exemples d'usages | Obligations principales |
|---|---|---|
| Risque inacceptable | Usages portant atteinte aux droits fondamentaux | Interdiction d'usage |
| Haut risque | Recrutement, notation, décisions ayant un impact important sur des personnes | Conformité renforcée, documentation, contrôle humain, marquage CE selon les cas |
| Risque limité | Chatbots orientés vers des personnes physiques, certains outils de génération ou d'assistance | Information de l'utilisateur sur le fait qu'il interagit avec une IA |
| Risque minimal | Usages de productivité ou d'aide sans impact significatif | Exigences allégées, avec gouvernance de bon sens |
La priorité opérationnelle est simple. Commencez par lister les usages réels, pas les outils achetés. Un même logiciel peut servir à des choses très différentes selon les équipes. Ensuite, posez deux questions à chaque fois, est-ce que l'outil touche des personnes physiques, et est-ce qu'il peut produire un effet important sur elles.
Un inventaire imparfait vaut mieux qu'aucun inventaire. En conformité IA, ce qui n'est pas cartographié finit souvent par être utilisé quand même.
Pour un panorama des obligations générales, la page dédiée à l'AI Act sur IATOLL peut servir de repère de base.
L'obligation d'alphabétisation IA expliquée clairement
L’alphabétisation IA de l’article 4 n'est pas une simple formation “une fois par an”. C'est la capacité d'une organisation à montrer que ses équipes comprennent les risques, les usages autorisés et les limites des systèmes qu'elles manipulent. Cette obligation s'applique depuis février 2025, et elle change la nature des preuves attendues, surtout pour les PME qui n'ont ni service conformité complet ni équipe RH outillée pour tout documenter.
Le sujet devient vite concret. Un contrôleur ou un auditeur ne cherchera pas seulement un support de formation. Il voudra voir qui a été formé, sur quoi, à quel niveau et pour quel usage métier. Cela suppose un registre de preuve d'alphabétisation, avec des parcours adaptés aux rôles réels, par exemple direction, RH, commercial, support ou consultant externe.
Ce qu'il faut pouvoir montrer
- Les personnes formées, avec une identité claire.
- Le contenu suivi, adapté à l'usage de l'IA dans l'entreprise.
- La date et le niveau de formation, pas seulement une présence.
- Le lien avec les usages concrets, par exemple rédaction, recrutement, assistance client ou analyse.
- La conservation des preuves, pour pouvoir répondre en cas de contrôle ou de litige.
La difficulté, pour un DPO externalisé ou un consultant, tient moins à la théorie qu'à la production du dossier. Il faut souvent intervenir chez plusieurs clients, avec des pratiques hétérogènes et des équipes qui utilisent déjà l'IA sans toujours l'avoir déclaré. C'est là que la preuve continue compte davantage qu'un PDF de formation laissé de côté.
Pour un rappel pratique sur ce point, le guide IATOLL sur l'AI literacy aide à structurer la documentation attendue. L'enjeu n'est pas de former “beaucoup”, mais de pouvoir prouver utilement la montée en compétence.
Articuler le RGPD et l'AI Act sur les données personnelles
Dès qu'un système d'IA traite des données personnelles, le RGPD reprend toute sa place. La CNIL rappelle qu'il faut une finalité précisément définie et l'une des six bases légales du RGPD, consentement, obligation légale, contrat, mission d'intérêt public, intérêts vitaux ou intérêt légitime. Sans cette base, la conformité IA reste incomplète, même si l'outil est bien classé au regard de l'AI Act.
La bonne lecture consiste à comparer les deux cadres. L’AI Act regarde le niveau de risque du système et les exigences associées. Le RGPD, lui, regarde la licéité du traitement, l'information des personnes, la sécurité et les droits individuels. Les deux se rencontrent dès qu'un système automatise une partie du traitement de données.
La CNIL ajoute un point très utile pour le terrain. Lorsqu'on s'appuie sur des données pour la recherche ou la statistique, il faut vérifier la compatibilité avec la finalité initiale. Elle indique aussi que l'analyse du statut d'un modèle peut nécessiter des tests de réidentification fondés sur des moyens raisonnablement susceptibles d'être utilisés. C'est une manière concrète de dire que la conformité ne se résume pas à un classeur, elle demande aussi une preuve technique.
Grille simple pour un audit de terrain
- Finalité claire, formulée avant le déploiement.
- Base légale documentée, et pas seulement supposée.
- Information des personnes, quand des données personnelles sont en jeu.
- Vérification de compatibilité, si les données sont réutilisées.
- Évaluation du risque de réidentification, quand un modèle ou un jeu de données est concerné.
Si la finalité change, le dossier doit changer aussi. C'est souvent là que les dossiers IA deviennent faux, parce que l'outil a continué d'évoluer alors que la documentation est restée figée.
Le point important pour les DPO est simple. Une même utilisation peut être acceptable au titre de l'AI Act et insuffisante au regard du RGPD, ou l'inverse. Il faut donc auditer les deux en parallèle, sans supposer qu'un texte couvre l'autre.
Construire une chaîne de preuve technique et organisationnelle
La conformité IA tient rarement dans une politique interne seule. Pour être défendable, elle doit laisser une chaîne d'évidence. Les guides de conformité recommandent de combiner identité authentifiée, contrôle d'accès de type ABAC et journaux d'audit infalsifiables alimentant un SIEM, c'est-à-dire un système qui centralise les événements de sécurité pour les exploiter en audit ou en incident. Ce trio réduit les usages non autorisés et rend la preuve exploitable.
Pour un système à haut risque, la documentation technique n'est pas optionnelle. L’article 11 de l'AI Act, avec son Annexe IV, impose une documentation avant la mise sur le marché et tenue à jour. Elle doit couvrir la finalité, l'architecture, les données d'entraînement et de préparation, les mesures de performance, la gestion des risques et les instructions d'utilisation. La conformité devient donc un problème de traçabilité prouvable.
Les trois contrôles à mettre en place en priorité
- Identité authentifiée, pour savoir qui fait quoi dans l'outil.
- ABAC, c'est-à-dire un contrôle d'accès fondé sur les attributs, pour limiter les usages aux bonnes personnes dans le bon contexte.
- Journaux d'audit infalsifiables, pour reconstruire les actions en cas de contrôle ou de contentieux.
La logique est très simple sur le terrain. Si plusieurs services utilisent la même IA sans identifiants individuels, vous perdez la traçabilité. Si les droits d'accès sont trop larges, vous perdez la maîtrise des usages. Si les journaux sont modifiables ou incomplets, vous perdez la preuve.
Quand un dossier est bien tenu, il raconte une histoire cohérente. Qui a utilisé l'outil, pourquoi, avec quelles données, avec quel niveau d'autorisation, et sur quelle base réglementaire. C'est ce récit que cherchent les auditeurs, pas seulement une déclaration d'intention.
Pour les organisations qui veulent structurer leurs usages, un outil comme IATOLL peut servir à produire des parcours d'alphabétisation IA et un registre de preuve associé, via des consultants ou DPO qui valident ensuite le cadre juridique et l'intègrent dans leur accompagnement.
Voici un rappel opérationnel utile avant de fermer le dossier technique.
- Définir les rôles, pour séparer l'usage, l'administration et la validation.
- Centraliser les preuves, pour éviter les fichiers dispersés.
- Tester la restitution, afin de vérifier qu'un audit peut être reconstruit sans bricolage.
Adapter la conformité IA aux PME sans DSI ni juriste interne
La plupart des contenus sur la conformité IA parlent comme si l'entreprise avait déjà une direction juridique, un RSSI et une équipe data. Ce n'est pas le cas de la majorité des PME. En pratique, les usages sont souvent diffus, portés par les managers, les RH, le marketing ou les commerciaux, avec une adoption qui échappe aux circuits officiels. C'est là que le sujet devient opérationnel.
La première étape, c'est l’inventaire réel. Il faut recenser les systèmes utilisés, mais aussi les usages non autorisés ou non déclarés, souvent appelés shadow IA. Un outil acheté par une équipe n'est pas toujours visible de la direction, et un usage ponctuel peut déjà créer un risque documentaire ou RGPD. La conformité commence donc par savoir ce qui existe vraiment.
Une méthode simple pour une petite structure
- Lister les outils et usages, même les usages gratuits ou ponctuels.
- Identifier les personnes qui les utilisent, par service et par rôle.
- Repérer les usages sensibles, recrutement, données clients, données de santé, documents confidentiels.
- Prioriser les actions, en traitant d'abord ce qui touche aux personnes ou aux données personnelles.
- Formaliser un minimum de preuves, même avec des moyens modestes.
Le piège classique consiste à vouloir tout traiter au même niveau. Une PME n'a pas besoin d'un dispositif de grande entreprise pour démarrer. Elle a besoin d'un inventaire fiable, d'une classification du risque, de règles d'usage simples et de preuves conservées proprement.
Pour une petite structure, la bonne question n'est pas “quels outils d'IA acheter ?”. La bonne question est “quels usages sont autorisés, par qui, et avec quelles preuves ?”
C'est aussi la bonne manière de parler à un dirigeant ou à un responsable RH. On ne lui vend pas une architecture abstraite. On lui demande d'arbitrer des usages concrets, d'identifier les zones sensibles et de faire valider un socle de conformité minimum. C'est plus modeste, mais beaucoup plus fiable.
Checklist opérationnelle pour démarrer votre mise en conformité
La conformité IA avance mieux avec une feuille de route courte qu'avec un grand plan théorique. Pour une PME, le bon ordre est souvent le plus simple, cartographier, qualifier, documenter, former, tracer et réviser. Le but n'est pas d'atteindre une perfection immédiate, mais de rendre le dispositif défendable.
- Nommer un responsable interne, même à temps partiel, pour centraliser les sujets IA.
- Réaliser une cartographie des systèmes IA, y compris les usages informels.
- Mettre à jour les procédures RGPD, quand des données personnelles sont utilisées.
- Définir un plan de formation IA, adapté aux métiers et aux niveaux de risque.
- Établir une documentation de conformité, avec les bases légales et les preuves utiles.
- Préparer un plan de réponse aux incidents, pour savoir qui fait quoi si un usage dérape.
Pour un consultant ou un DPO externalisé, les indicateurs de progression sont très concrets. Le nombre d'outils cartographiés, le nombre de rôles formés, la part des usages avec base légale documentée, et la présence d'un registre de preuve exploitable. Si ces éléments sont suivis dans le temps, le dossier gagne en crédibilité.
Le point de départ ne change pas. Savoir ce qui est utilisé, par qui, avec quelle finalité et avec quelles preuves. Une fois cette base en place, la conformité devient un travail régulier, pas une course de dernière minute.
Retrouvez le glossaire IA complet sur IATOLL, puis vérifiez vos usages dans l'annuaire d'outils IA classés par conformité RGPD et AI Act. Si vous accompagnez des PME ou si vous devez documenter l'alphabétisation IA de plusieurs clients, IATOLL permet de structurer des parcours de preuve sans partir de zéro et de garder un dossier exploitable dans la durée.
