Conformité AI Act 2026 pour les PME : les étapes clés

L'AI Act ne distingue pas la taille de l'entreprise pour déterminer ses obligations. Une PME de 20 salariés qui déploie un outil d'IA pour trier des CV relève des mêmes règles qu'un grand groupe sur ce cas d'usage. Cet article décrit, étape par étape, la démarche à suivre d'ici août 2026 pour les dirigeants, DPO et IA Lead de PME françaises.

Le sujet est dense. Pour la cartographie générale du texte, le lecteur peut consulter notre guide AI Act pour les PME françaises. Pour comprendre l'exposition financière, voir notre article dédié aux sanctions et amendes.

1. Étape 1 : Inventaire des systèmes d'IA

L'inventaire est le socle de toute démarche de conformité. Sans cartographie exhaustive, aucune classification ni évaluation des risques ne tient. L'Article 3 du Règlement (UE) 2024/1689 définit un « système d'IA » comme un système automatisé conçu pour fonctionner avec différents niveaux d'autonomie et qui peut produire des prédictions, recommandations ou décisions influençant l'environnement physique ou virtuel.

Cette définition est large. Elle couvre les outils que la PME développe en interne, mais aussi ceux qu'elle achète sur étagère ou qu'elle intègre via une API.

Identifier l'ensemble du parc IA

Le travail d'inventaire couvre quatre familles de systèmes que les PME utilisent fréquemment :

• Outils d'automatisation des processus métier (RPA enrichis d'apprentissage automatique)
• Agents conversationnels (chatbots clients, assistants internes)
• Outils d'analyse prédictive (prévision de ventes, scoring client, maintenance prédictive)
• Outils génératifs (rédaction, traduction, génération d'images, code)

Une PME oublie souvent les modèles intégrés dans des SaaS du quotidien : module de scoring d'un CRM, suggestions automatiques dans une suite bureautique, modèle de détection de fraude d'une plateforme de paiement. Ces composants entrent dans le champ de l'AI Act dès lors qu'ils répondent à la définition de l'Article 3.

Classer par domaine d'application

Le domaine d'application conditionne le risque. Un chatbot de support technique et un outil de tri de CV utilisent des briques similaires, mais leur exposition réglementaire diffère radicalement. L'Annexe III du Règlement liste les cas d'usage qualifiés de haut risque. Parmi eux : l'emploi, le crédit, l'éducation, l'accès aux services publics, l'application de la loi.

Une grille simple à tenir dans un tableur :

Champ	Contenu attendu
Nom du système	Désignation interne
Fournisseur	Éditeur ou « développé en interne »
Finalité	Cas d'usage principal
Domaine	Annexe III applicable ? Oui/Non
Données traitées	Catégories RGPD, données personnelles ou non
Utilisateurs	Internes, clients, candidats, public
Date mise en service	jj/mm/aaaa

Documenter les fournisseurs et les données

Pour chaque système, la PME identifie le fournisseur au sens de l'Article 3, point 3 du Règlement, c'est-à-dire l'entité qui développe le système et le met sur le marché. Le déployeur, défini à l'Article 3, point 4, est l'entité qui utilise le système sous sa propre autorité. Une même PME peut être à la fois fournisseur (système développé en interne) et déployeur (système acheté).

Cette distinction est centrale : les obligations diffèrent fortement entre les deux rôles. Pour un système à haut risque, le fournisseur supporte la grande majorité des obligations documentaires et techniques.

2. Étape 2 : Classification des systèmes

L'AI Act repose sur une approche par les risques. Quatre catégories existent :

Catégorie	Description	Articles AI Act	Obligation principale
Risque inacceptable	Pratiques interdites (notation sociale, manipulation subliminale, etc.)	Art. 5	Interdiction totale depuis le 2 février 2025
Risque élevé	Systèmes listés à l'Annexe III et systèmes de l'Annexe I	Art. 6 à 49	Conformité complète à compter du 2 août 2026
Risque limité	Chatbots, deepfakes, systèmes de reconnaissance d'émotions	Art. 50	Transparence vis-à-vis de l'utilisateur
Risque minimal	Tous les autres systèmes	—	Aucune obligation spécifique, codes de conduite recommandés

Identifier les systèmes à haut risque

L'Article 6 du Règlement (UE) 2024/1689 définit deux voies pour qualifier un système de haut risque. Première voie : le système est un composant de sécurité d'un produit couvert par la législation harmonisée listée à l'Annexe I (jouets, dispositifs médicaux, machines, etc.). Deuxième voie : le système relève d'un des huit domaines de l'Annexe III.

Les huit domaines de l'Annexe III qui concernent fréquemment les PME :

1. Biométrie (identification, catégorisation)
2. Infrastructures critiques
3. Éducation et formation professionnelle
4. Emploi, gestion des travailleurs, accès au travail indépendant
5. Accès aux services essentiels (crédit, prestations sociales, urgences)
6. Application de la loi
7. Migration, asile, contrôle aux frontières
8. Administration de la justice et processus démocratiques

Une PME qui exploite un outil de tri de CV ou d'évaluation de salariés tombe dans le domaine 4. Une PME qui propose un score de crédit pour ses clients tombe dans le domaine 5.

L'exception de l'Article 6, paragraphe 3

Le texte prévoit une nuance importante. Un système relevant de l'Annexe III peut être considéré comme non à haut risque s'il ne présente pas de risque significatif pour la santé, la sécurité ou les droits fondamentaux. Quatre conditions cumulatives existent : tâche procédurale étroite, amélioration d'une activité humaine déjà réalisée, détection de schémas décisionnels sans remplacement de l'évaluation humaine, ou tâche préparatoire. Le fournisseur doit documenter cette analyse.

Cette exception ne s'applique jamais aux systèmes de profilage de personnes physiques.

Évaluer l'impact sur les droits fondamentaux

L'Article 27 introduit une obligation spécifique pour les déployeurs publics et certains déployeurs privés de systèmes à haut risque : l'analyse d'impact sur les droits fondamentaux (FRIA). Elle complète sans remplacer l'analyse d'impact RGPD (AIPD) prévue à l'article 35 du RGPD.

Pour bien distinguer les deux exercices, consulter notre glossaire qui détaille les définitions normatives.

3. Étape 3 : Évaluation des risques

L'évaluation des risques est exigée par l'Article 9 du Règlement pour les systèmes à haut risque. Elle prend la forme d'un système de gestion des risques itératif, planifié et documenté tout au long du cycle de vie du système.

Identifier les risques connus et raisonnablement prévisibles

L'analyse couvre quatre familles de risques que la PME documente système par système :

• Biais discriminatoires liés aux données d'entraînement ou aux usages
• Failles de cybersécurité et atteintes à la robustesse du modèle
• Manque de transparence empêchant l'interprétation des décisions
• Impact sur les droits fondamentaux (vie privée, non-discrimination, dignité)

Évaluer l'impact sur les utilisateurs finaux

L'Article 9, paragraphe 5, exige que les mesures d'atténuation soient telles que le risque résiduel restant après leur application soit jugé acceptable. Le texte demande aussi de prendre en compte les personnes susceptibles d'être affectées dans une situation de vulnérabilité ou en raison de leur âge.

Une grille d'analyse minimale :

Risque identifié	Probabilité	Gravité	Mesure d'atténuation	Risque résiduel
Biais sur l'âge dans le tri de CV	Élevée	Forte	Audit statistique trimestriel	Faible
Perte de robustesse en cas de drift	Moyenne	Moyenne	Surveillance des métriques en production	Faible
Atteinte à la confidentialité	Faible	Forte	Chiffrement, pseudonymisation	Très faible

Documenter les mesures de sécurité existantes

Les mesures techniques et organisationnelles découlent directement des exigences de l'Article 15 du Règlement (UE) 2024/1689 sur l'exactitude, la robustesse et la cybersécurité. Le niveau requis dépend de l'usage prévu. Une PME peut s'appuyer sur la norme ISO/IEC 23894:2023 (gestion des risques liés à l'IA) et sur la norme ISO/IEC 27001:2022 (sécurité de l'information) pour structurer son dispositif.

4. Étape 4 : Mise en place de mesures

L'étape précédente identifie les risques. Cette étape les traite.

Contrôles techniques

Les contrôles techniques minimaux exigés par les Articles 14, 15 et 16 portent sur :

• La surveillance humaine effective (Art. 14) : interface, formation, capacité d'arrêt
• L'exactitude, la robustesse et la cybersécurité (Art. 15) : métriques, tests, journaux
• La gouvernance des données d'entraînement, de validation et de test (Art. 10) : pertinence, représentativité, absence d'erreurs

Formation des équipes

L'Article 4 du Règlement, applicable depuis le 2 février 2025, impose à tous les fournisseurs et déployeurs de garantir un niveau suffisant de maîtrise de l'IA chez leur personnel et chez les personnes utilisant les systèmes pour leur compte. Cette obligation s'applique à tous les niveaux de risque, pas seulement au haut risque.

Pour une PME, cela signifie au minimum :

• Sensibilisation générale de l'ensemble des collaborateurs concernés
• Formation approfondie des personnes qui interviennent dans la conception, le déploiement ou la supervision
• Traçabilité des actions de formation (registre, attestations)

Protocoles de réponse aux incidents

Les fournisseurs de systèmes à haut risque doivent notifier les incidents graves aux autorités de surveillance du marché en application de l'Article 73. Le délai standard est de 15 jours après prise de connaissance, réduit à 2 jours pour les incidents impliquant une atteinte généralisée. Le protocole interne doit prévoir une chaîne d'alerte claire entre l'opérationnel, le DPO, le RSSI et la direction.

5. Étape 5 : Documentation et conformité

La documentation est la preuve principale de la conformité. En cas de contrôle, elle conditionne l'issue.

Documentation technique (Annexe IV)

L'Article 11 et l'Annexe IV du Règlement listent neuf rubriques que la documentation technique d'un système à haut risque doit couvrir :

1. Description générale du système
2. Description détaillée des éléments du système et de son processus de développement
3. Informations sur la surveillance, le fonctionnement et le contrôle du système
4. Description du système de gestion des risques (Article 9)
5. Changements significatifs apportés au système pendant son cycle de vie
6. Liste des normes harmonisées appliquées
7. Copie de la déclaration UE de conformité (Article 47)
8. Description du système d'évaluation des performances post-commercialisation (Article 72)
9. Plan d'évaluation post-commercialisation

Registre des systèmes (Article 71)

L'Article 71 institue une base de données européenne dans laquelle les fournisseurs de systèmes à haut risque listés à l'Annexe III doivent enregistrer leurs systèmes. Cet enregistrement est public, à l'exception de quelques champs sensibles. Pour la PME fournisseur, il s'agit d'une obligation formelle qui s'ajoute à son registre interne.

À noter : les déployeurs publics doivent également s'enregistrer (Article 49, paragraphe 3). Les déployeurs privés n'ont pas d'obligation similaire dans la base européenne, mais ils tiennent un registre interne.

Politique de sécurité des données

L'AI Act s'articule étroitement avec le RGPD. Toute donnée personnelle utilisée pour entraîner, valider ou exploiter un système d'IA reste soumise au Règlement (UE) 2016/679. Les exigences se cumulent :

Sujet	RGPD	AI Act
Analyse d'impact	AIPD (art. 35 RGPD)	FRIA pour déployeurs concernés (Art. 27)
Documentation	Registre des traitements	Documentation technique Annexe IV
Transparence	Information des personnes	Notice d'utilisation (Art. 13)
Sécurité	Mesures techniques et organisationnelles	Robustesse et cybersécurité (Art. 15)
Sous-traitance	Contrat art. 28 RGPD	Obligations contractuelles Art. 25 et 26

Pour structurer la démarche selon la norme dédiée, voir notre dossier ISO/IEC 42001:2023 pour les PME.

6. Étape 6 : Suivi et maintenance

Le système de management de l'IA ne s'arrête pas à la mise en conformité initiale. L'Article 72 du Règlement impose un système de surveillance après commercialisation pour les systèmes à haut risque.

Plan de surveillance

Le plan de surveillance documente la collecte, l'analyse et l'utilisation des données de performance du système en conditions réelles. Il couvre la dérive du modèle, l'évolution des taux d'erreur, les incidents remontés, les retours utilisateurs.

Audits réguliers

La fréquence des audits internes dépend de la criticité. Une PME peut retenir une cadence semestrielle pour les systèmes à haut risque et annuelle pour les systèmes à risque limité. Chaque audit produit un compte rendu daté qui rejoint la documentation technique.

Adaptation aux évolutions législatives

Le Bureau de l'IA (AI Office) publie des lignes directrices, des actes d'exécution et des actes délégués. Les normes harmonisées de soutien sont en cours d'élaboration par le CEN-CENELEC. Le dispositif de veille de la PME doit identifier ces publications et déclencher la mise à jour des documents internes.

7. Étape 7 : Préparation à l'audit

L'audit peut être interne, mené par un organisme tiers (évaluation de conformité par tierce partie pour certaines catégories de l'Annexe I), ou conduit par une autorité de surveillance du marché. En France, plusieurs autorités sectorielles ont vocation à intervenir : ACPR pour la banque et l'assurance, ANSM pour les dispositifs médicaux, ARCOM pour les médias et plateformes, DGCCRF en transversal.

Traçabilité des décisions IA

L'Article 12 du Règlement impose la journalisation automatique des événements pendant toute la durée de vie du système. Les logs doivent permettre la traçabilité du fonctionnement du système, l'identification des situations à risque, et la surveillance après commercialisation. La durée de conservation par défaut est de six mois minimum, sauf disposition contraire.

Transparence des algorithmes

La transparence vis-à-vis du déployeur passe par la notice d'utilisation prévue à l'Article 13. Vis-à-vis de la personne concernée, l'Article 50 impose, pour les systèmes à risque limité, d'informer l'utilisateur qu'il interagit avec une IA, sauf cas évidents.

Dossier prêt pour les autorités

Le dossier type que la PME maintient à disposition contient :

• La documentation technique complète (Annexe IV)
• La déclaration UE de conformité signée (Article 47)
• Le marquage CE pour les systèmes physiques (Article 48)
• Les journaux de fonctionnement (Article 12)
• Les rapports d'évaluation post-commercialisation (Article 72)
• Les preuves de formation des équipes (Article 4)

8. Étape 8 : Suivi des évolutions

L'AI Act est un texte vivant. Au moins deux mécanismes feront évoluer le périmètre des obligations dans les années qui viennent.

Veille réglementaire

Les sources primaires à suivre :

• Le Journal officiel de l'Union européenne via EUR-Lex pour les actes d'exécution et actes délégués
• Le site du Bureau de l'IA (Commission européenne) pour les lignes directrices
• Le site de la CNIL pour la doctrine française et les fiches pratiques
• Le portail artificialintelligenceact.eu pour les analyses consolidées

Le calendrier d'application principal à mémoriser :

Date	Obligations applicables
1er août 2024	Entrée en vigueur du Règlement
2 février 2025	Pratiques interdites (Art. 5) et maîtrise de l'IA (Art. 4)
2 août 2025	Modèles d'IA à usage général, gouvernance, sanctions (sauf Art. 101)
2 août 2026	Régime complet du haut risque (Annexe III)
2 août 2027	Régime du haut risque de l'Annexe I (produits réglementés)

Participation aux groupes de discussion

La CNIL anime des consultations publiques sur ses fiches pratiques IA. Les organisations professionnelles (Cigref pour les grands comptes, Numeum pour le numérique, MEDEF et CPME pour le tissu PME) relaient et synthétisent ces consultations. La PME y trouve une grille de lecture proche de ses contraintes.

Adaptation continue

Chaque nouvelle ligne directrice peut déplacer la qualification d'un système ou modifier la documentation attendue. La revue de cohérence interne, idéalement trimestrielle, examine les nouveaux usages déployés, les nouvelles versions des outils en place, et les nouvelles publications officielles. Pour un référentiel à jour, consulter notre page des sources officielles.

FAQ

Quelles sont les sanctions pour non-conformité ?

L'Article 99 du Règlement (UE) 2024/1689 prévoit trois plafonds d'amende selon la nature du manquement. Le plafond le plus élevé, 35 M€ ou 7 % du chiffre d'affaires mondial annuel selon le montant le plus élevé, s'applique aux violations des pratiques interdites de l'Article 5. Les manquements aux obligations sur les systèmes à haut risque sont sanctionnés jusqu'à 15 M€ ou 3 % du chiffre d'affaires. La fourniture d'informations inexactes aux autorités peut aller jusqu'à 7,5 M€ ou 1 %. Pour les PME et start-ups, le texte prévoit que le plus bas des deux montants s'applique (Art. 99, par. 6). Pour le détail, voir notre article sur les sanctions et amendes.

Dois-je engager un expert pour l'audit ?

Pour les systèmes à haut risque relevant de l'Annexe III, l'évaluation de conformité repose en règle générale sur un contrôle interne mené par le fournisseur (Annexe VI). L'intervention d'un organisme notifié n'est obligatoire que pour certains systèmes (Annexe VII) et pour les systèmes de biométrie sous conditions précises. Pour les systèmes physiques soumis à la législation harmonisée de l'Annexe I, l'évaluation tierce partie reste celle prévue par la législation sectorielle. Un appui externe reste recommandé pour la première mise en conformité, le temps d'internaliser la méthode.

Quel budget prévoir pour la conformité ?

Pour une PME de 50 salariés exploitant un système à haut risque, l'ordre de grandeur observé sur les premiers projets accompagnés se situe entre 15 000 € et 30 000 € pour la première mise en conformité [à vérifier selon le périmètre exact]. Ce budget couvre l'inventaire, la classification, la rédaction de la documentation technique, la formation initiale et l'évaluation des risques. Pour un système à risque limité, le coût se réduit à quelques milliers d'euros, essentiellement pour la mise à jour des notices et la formation.

Comment gérer les systèmes d'IA achetés en externalisation ?

La répartition des responsabilités dépend du rôle exact de chaque acteur (Article 25 du Règlement). Le fournisseur initial reste responsable des obligations attachées à la mise sur le marché. Le déployeur PME endosse les obligations spécifiques à l'utilisation : surveillance humaine, conformité de l'usage aux instructions, journalisation, FRIA le cas échéant. Si la PME modifie substantiellement le système ou le commercialise sous son propre nom, elle devient elle-même fournisseur et reprend l'intégralité des obligations correspondantes. La PME doit donc exiger contractuellement la documentation Annexe IV et la déclaration UE de conformité au fournisseur amont.

Quelles sont les différences avec le RGPD ?

Le RGPD encadre le traitement des données personnelles, quel que soit l'outil utilisé. L'AI Act encadre la mise sur le marché et l'utilisation des systèmes d'IA, qu'ils traitent ou non des données personnelles. Les deux textes s'appliquent en parallèle. Quand un système d'IA traite des données personnelles, les obligations se cumulent : registre RGPD et registre AI Act, AIPD et FRIA, information au titre de l'article 13 RGPD et information au titre de l'Article 50 AI Act. La CNIL est compétente pour le RGPD ; la désignation des autorités de surveillance du marché françaises pour l'AI Act est en cours de finalisation [à vérifier au moment de la publication finale].

Sources officielles

• Règlement (UE) 2024/1689 sur EUR-Lex — version officielle de l'Union européenne
• AI Act Service Desk de la Commission européenne — réponses gratuites aux questions des opérateurs
• artificialintelligenceact.eu — texte consolidé et analyses
• CNIL — fiches pratiques IA — 13 fiches d'application opérationnelle
• ISO/IEC 42001:2023 — système de management de l'intelligence artificielle
• ISO/IEC 23894:2023 — gestion des risques liés à l'IA
• ISO/IEC 27001:2022 — système de management de la sécurité de l'information

---

Cet article fournit des informations générales sur l'EU AI Act applicables aux PME françaises. Il ne constitue pas un conseil juridique. Pour toute décision opérationnelle, faites valider votre démarche par votre DPO ou conseil juridique. regulia décline toute responsabilité quant à l'usage qui peut être fait de ces informations.