Une entreprise peut utiliser un chatbot, automatiser un recrutement ou intégrer un modèle génératif dans son logiciel sans mesurer immédiatement les conséquences réglementaires. Le règlement européen sur l’intelligence artificielle, souvent appelé AI Act, impose désormais de distinguer les usages acceptables, les systèmes à haut risque et les pratiques interdites. Je vous propose ici une lecture pratique du texte, avec les échéances de 2026, les obligations pour les équipes IT et cybersécurité et une méthode concrète pour se mettre en conformité en France.
Les repères essentiels pour comprendre l’AI Act européen
- Une approche par niveaux de risque détermine les obligations applicables à chaque système d’IA.
- Les pratiques interdites sont déjà encadrées, tandis que les règles de transparence s’appliquent depuis le 2 août 2026.
- Les systèmes à haut risque devront respecter des exigences fortes en matière de données, de traçabilité, de supervision humaine et de cybersécurité.
- Le RGPD reste applicable dès qu’un système traite des données personnelles. L’AI Act ne le remplace pas.
- Un inventaire interne des usages d’IA constitue le meilleur point de départ pour réduire les risques.
Ce que change concrètement le règlement européen sur l’IA
L’AI Act est un règlement européen qui encadre la conception, la commercialisation et l’utilisation des systèmes d’intelligence artificielle. Il peut concerner une organisation située hors de l’Union européenne dès lors que son système produit des résultats utilisés dans l’UE ou affecte des personnes qui s’y trouvent.
Le texte ne traite donc pas uniquement les entreprises qui développent des modèles. Une société française qui achète un outil de recrutement, un assistant client ou une solution de détection des fraudes peut être considérée comme déployeur. Elle doit alors vérifier l’usage prévu, les limites du fournisseur et les mesures de contrôle mises en place.
Quatre niveaux de risque à ne pas confondre
| Niveau | Exemples | Conséquence principale |
|---|---|---|
| Risque inacceptable | Manipulation délibérée, notation sociale, certaines pratiques biométriques | Interdiction |
| Haut risque | Recrutement, éducation, infrastructures critiques, crédit, dispositifs médicaux | Obligations strictes avant et après la mise en service |
| Risque de transparence | Chatbots, deepfakes, contenus générés ou modifiés par IA | Information de l’utilisateur et marquage approprié |
| Risque minimal | Filtres anti-spam, jeux vidéo ou outils d’aide sans impact significatif | Pas d’obligation spécifique au titre de l’AI Act |
Cette classification dépend de la finalité réelle du système, et pas seulement de son nom commercial. Un même modèle peut relever d’un risque limité pour la rédaction d’un brouillon et devenir beaucoup plus sensible lorsqu’il influence une décision d’embauche ou l’accès à un service essentiel.
Le règlement complète le RGPD. La CNIL rappelle qu’un système d’IA qui utilise des données personnelles doit respecter les règles de licéité, de minimisation, d’information, de sécurité et d’exercice des droits. En pratique, une analyse AI Act sans analyse RGPD laisse une partie importante du risque de côté.
Le calendrier à retenir pour 2026 et les prochaines échéances
Le calendrier a été ajusté par le paquet de simplification adopté en juillet 2026. Pour les directions informatiques, cette évolution apporte un peu de temps sur certains systèmes à haut risque, mais elle ne justifie pas l’attentisme. Les obligations déjà applicables concernent notamment les pratiques interdites, les modèles d’IA à usage général et la transparence.
| Date | Ce qui s’applique | Ce que l’entreprise doit vérifier |
|---|---|---|
| 2 février 2025 | Interdictions principales et obligation de développer la culture IA | Usages interdits, sensibilisation des collaborateurs |
| 2 août 2025 | Règles de gouvernance et obligations pour les modèles d’IA à usage général | Fournisseurs, documentation, propriété intellectuelle, risques systémiques |
| 2 août 2026 | Règles de transparence et pouvoirs de contrôle renforcés | Chatbots, contenus synthétiques, deepfakes, information des personnes |
| 2 décembre 2026 | Dispositions spécifiques sur certains contenus sexuels non consentis et contenus pédocriminels | Filtres, blocages et contrôles des fonctionnalités génératives concernées |
| 2 décembre 2027 | Règles principales pour certains systèmes à haut risque de l’annexe III | Emploi, éducation, biométrie, infrastructures et services essentiels |
| 2 août 2028 | Systèmes d’IA intégrés à certains produits réglementés | Machines, jouets, dispositifs médicaux et autres produits concernés |
Depuis le 2 août 2026, un utilisateur doit généralement savoir lorsqu’il échange directement avec une IA. Les contenus générés ou manipulés par IA doivent aussi pouvoir être identifiés dans les cas prévus par le règlement. Pour les systèmes déjà commercialisés avant cette date, une période limitée allant jusqu’au 2 décembre 2026 concerne surtout certaines obligations de marquage technique.
La Commission européenne supervise notamment les modèles d’IA à usage général, tandis que les autorités nationales contrôlent une grande partie des systèmes déployés sur le marché. En France, la coordination s’appuie sur la DGCCRF et les autorités sectorielles compétentes, avec un rôle important de la CNIL pour les données personnelles et certains usages sensibles.
Les actions prioritaires pour les équipes IT et cybersécurité
La première erreur consiste à commencer par rédiger une longue politique interne sans savoir où l’IA est utilisée. Je recommande plutôt de partir des flux réels. Les équipes doivent identifier les outils achetés par les métiers, les API intégrées dans les applications, les modèles hébergés en interne et les usages non déclarés.
- Créer un registre des systèmes d’IA. Pour chaque outil, notez le fournisseur, la finalité, les données utilisées, les utilisateurs, le pays d’hébergement et le niveau de risque présumé.
- Identifier le rôle de l’entreprise. Elle peut être fournisseur, déployeur, importateur ou simple utilisateur. Ces rôles ne produisent pas les mêmes obligations.
- Évaluer les données. Vérifiez la présence de données personnelles, de données sensibles, de secrets commerciaux ou d’informations couvertes par le secret professionnel.
- Contrôler le fournisseur. Demandez la documentation du modèle, les garanties de sécurité, les conditions d’utilisation des données, les journaux disponibles et les procédures de notification d’incident.
- Organiser la supervision humaine. Une personne doit pouvoir comprendre le fonctionnement général du système, détecter une erreur et interrompre ou corriger le résultat.
- Tester la sécurité dans des conditions réalistes. Les tests doivent couvrir les fuites de données, les attaques par injection de prompt, les sorties dangereuses, la corruption des données et les accès excessifs.
Pour un système à haut risque, les exigences vont beaucoup plus loin. Il faut notamment prévoir une gestion des risques documentée, des jeux de données suffisamment pertinents, une documentation technique, des journaux d’activité, une surveillance après déploiement et un niveau élevé de robustesse, de précision et de cybersécurité.
La cybersécurité ne doit pas être traitée comme une simple clause contractuelle. Un modèle peut être techniquement performant tout en exposant l’entreprise à une fuite de données ou à une manipulation de ses résultats. Je conseille donc d’intégrer les systèmes d’IA aux processus habituels de gestion des vulnérabilités, de contrôle des accès, de sauvegarde et de réponse aux incidents.
IA générative et modèles à usage général
Les modèles à usage général, souvent appelés GPAI, sont conçus pour remplir de nombreuses tâches et peuvent être intégrés dans d’autres applications. Le fournisseur du modèle doit respecter des obligations de transparence, de documentation et de respect du droit d’auteur. Lorsqu’un modèle présente un risque systémique, des exigences supplémentaires peuvent s’appliquer à son évaluation et à sa sécurité.
L’entreprise qui intègre un tel modèle dans son propre service ne devient pas automatiquement responsable de toutes les obligations du fournisseur. Elle reste toutefois responsable de son système final et de son usage. C’est une distinction essentielle pour les éditeurs de logiciels qui ajoutent une fonction de génération de texte, d’image, de code ou de décision à leur produit.
Les règles de transparence à appliquer
- Un chatbot doit généralement signaler à l’utilisateur qu’il échange avec une IA.
- Les contenus générés ou modifiés par IA doivent être marqués de manière lisible ou techniquement détectable lorsque le règlement l’exige.
- Les deepfakes doivent être clairement signalés comme tels.
- Les textes générés pour informer le public sur des sujets d’intérêt général doivent faire l’objet d’une information appropriée lorsqu’ils n’ont pas été contrôlés par un humain.
- Les systèmes de reconnaissance des émotions ou de catégorisation biométrique peuvent être soumis à des obligations spécifiques d’information.
Un simple avertissement dans les conditions générales ne suffit pas toujours. L’information doit intervenir au bon moment, dans l’interface ou le contenu concerné, avec une formulation compréhensible. Pour un service client, par exemple, la mention doit apparaître dès le début de l’échange, pas au fond d’une page juridique que personne ne consulte.
Les erreurs qui fragilisent le plus souvent la conformité
Penser que le fournisseur porte toute la responsabilité
Un contrat SaaS ne transfère pas automatiquement les obligations liées à l’usage. L’entreprise reste responsable de la manière dont elle configure l’outil, des données qu’elle lui transmet et des décisions prises à partir de ses résultats. Il faut donc prévoir des clauses sur les incidents, les audits, la conservation des données et la réversibilité.
Confondre conformité RGPD et conformité AI Act
Le RGPD répond principalement aux questions liées aux données personnelles. L’AI Act ajoute des exigences sur le risque, la transparence, la supervision humaine, la documentation et la sécurité des systèmes. Un outil peut respecter une partie des règles de protection des données tout en restant inadapté à un usage à haut risque.
Oublier les usages internes
Les risques ne viennent pas uniquement des projets officiels. Un collaborateur peut copier des données clients dans un assistant public, utiliser une IA pour filtrer des CV ou générer un rapport contenant des informations confidentielles. Une politique interne claire, une formation courte et des solutions approuvées réduisent fortement ce type de dérive.
Lire aussi : Système d'information utile - Exemples concrets et cybersécurité
Se contenter de tester la qualité des réponses
Une réponse correcte ne prouve pas qu’un système est sûr. Il faut également tester sa résistance aux prompts malveillants, aux données empoisonnées, aux tentatives d’extraction d’informations et aux changements de comportement après une mise à jour. À mes yeux, la traçabilité des décisions et des versions est souvent plus utile qu’une simple démonstration marketing de performance.
Les sanctions peuvent atteindre 35 millions d’euros ou 7 % du chiffre d’affaires mondial annuel pour certaines pratiques interdites. Les autres manquements peuvent être sanctionnés jusqu’à 15 millions d’euros ou 3 % du chiffre d’affaires mondial annuel, selon le montant le plus élevé applicable. La gravité, la durée de l’infraction et la taille de l’entreprise sont prises en compte.
Une feuille de route réaliste pour une entreprise française
Une mise en conformité efficace peut commencer par un plan de 90 jours. L’objectif n’est pas de produire immédiatement une documentation parfaite, mais de réduire les risques les plus sérieux et de créer une base exploitable par la DSI, le RSSI, le juridique et les métiers.
- Jours 1 à 30 : recenser les outils et les projets d’IA, suspendre les usages manifestement sensibles et classer les données transmises aux fournisseurs.
- Jours 31 à 60 : qualifier les rôles et les niveaux de risque, revoir les contrats, définir les règles d’accès et mettre en place un processus de validation des nouveaux usages.
- Jours 61 à 90 : formaliser les procédures de supervision, d’incident et de retrait, former les équipes concernées et réaliser des tests de sécurité sur les applications prioritaires.
Pour les projets susceptibles de relever du haut risque, il faut associer très tôt la direction juridique, le RSSI, le délégué à la protection des données et le responsable métier. Cette gouvernance croisée évite qu’un projet soit évalué uniquement sous l’angle de la performance ou uniquement sous celui de la protection des données.
Les PME n’ont pas besoin de reproduire l’organisation documentaire d’un grand groupe. Elles doivent surtout conserver les preuves utiles, notamment l’analyse du risque, les choix de configuration, les contrôles réalisés, les formations suivies et les décisions prises en cas d’incident. Une documentation courte mais tenue à jour vaut mieux qu’un référentiel imposant que personne ne consulte.
Le meilleur réflexe consiste à traiter l’IA comme un actif critique
L’AI Act européen ne demande pas de renoncer à l’intelligence artificielle. Il oblige surtout les organisations à savoir où l’IA intervient, sur quelles données elle travaille et quelles conséquences elle peut produire. Cette visibilité devient un avantage de management IT autant qu’une protection juridique.
En 2026, la priorité est donc simple. Cartographiez les usages, classez les risques, sécurisez les flux de données, rendez les interactions transparentes et gardez un humain capable de reprendre la main. C’est cette discipline opérationnelle qui permettra d’accélérer les projets d’IA sans transformer chaque expérimentation en risque informatique ou réglementaire.
