Cadre réglementaire européen

Deux textes qui se cumulent

Un système d'IAintelligence artificielleIAEnsemble des techniques permettant à un programme d'accomplir une tâche qui demanderait de l'intelligence humaine. Le terme couvre aussi bien les systèmes à règles écrites que ceux qui apprennent de données.Voir dans le glossaire déployé en Europe relève de deux réglementations distinctes, qui ne se substituent pas l'une à l'autre.

Le RGPDRGPDConformitéRèglement européen sur la protection des données personnelles. Il s'applique dès qu'un système d'IA traite de telles données, et se cumule avec l'AI Act.Voir dans le glossaire s'applique dès qu'il y a traitement de donnéesdonnéesIAEnsemble d'informations structurées ou non utilisées pour entraîner, évaluer ou alimenter un modèle. La qualité, la quantité et la représentativité des données sont les facteurs décisifs pour les performances en apprentissage automatique.Voir dans le glossaire personnelles — donc à la quasi-totalité des projets, ne serait-ce qu'au stade de l'entraînement.

Le règlement européen sur l'intelligence artificielleAI ActConformitéRèglement européen sur l'intelligence artificielle, adopté en 2024. Il classe les systèmes en quatre niveaux de risque selon leur usage — jamais selon leur technologie.Voir dans le glossaire, dit AI Act, s'applique au système d'IA en tant que produit, indépendamment de la présence de données personnelles. Adopté en 2024, il entre en application par étapes échelonnées jusqu'en 2027.

Se conformer au RGPD ne dispense pas de l'AI Act, et réciproquement. Le premier protège les personnes concernées par les données ; le second encadre le système lui-même et ses usages.

Ce que le RGPD impose à un projet d'IA

Base légale — chaque traitement doit reposer sur un fondement juridique identifié. Réutiliser pour l'entraînement des données collectées à une autre fin suppose de vérifier la compatibilité de cette nouvelle finalité.

Minimisation — seules les données nécessaires à la finalité peuvent être traitées. L'argument « plus de données donnent un meilleur modèle » n'est pas un fondement juridique.

Information — les personnes doivent savoir que leurs données alimentent un système automatisé, et à quelle fin.

Décision automatisée (article 22) — une personne ne peut faire l'objet d'une décision produisant des effets juridiques ou l'affectant de manière significative, fondée exclusivement sur un traitement automatisé. Des exceptions existent, assorties de garanties : intervention humaine, possibilité de contester, droit d'obtenir une explication.

Analyse d'impactAIPDConformitéAnalyse d'impact relative à la protection des données, obligatoire dès qu'un traitement est susceptible d'engendrer un risque élevé — ce qui couvre la plupart des systèmes de profilage.Voir dans le glossaire (AIPD) — obligatoire dès qu'un traitement est susceptible d'engendrer un risque élevéhaut risqueConformitéCatégorie de l'AI Act regroupant les usages soumis à conditions strictes : recrutement, crédit, éducation, infrastructures critiques. Elle impose documentation, examen des biais et contrôle humain effectif.Voir dans le glossaire, ce qui couvre la plupart des systèmes de profilage.

L'intervention humaine invoquée pour échapper à l'article 22 doit être réelle. Un opérateur qui valide mécaniquement les propositions du système sans capacité ni marge d'appréciation ne constitue pas une intervention humaine au sens du texte. Le biaisbiaisIARégularité correctement apprise dans des données qui ne représentent pas la réalité visée, ou qui enregistrent des décisions passées avec leurs préjugés. Changer d'algorithme ne le corrige pas.Voir dans le glossaire d'automatisation est ici un risque de non-conformité autant qu'un risque opérationnel.

Les quatre niveaux de risque de l'AI Act

Le règlement classe les systèmes selon leur usage, et non selon leur technologie.

Les obligations du haut risque

Un système classé à haut risque doit satisfaire, avant sa mise sur le marché :

• un système de gestion des risques documenté et tenu à jour ;
• une gouvernance des données couvrant qualité, représentativité et examen des biais ;
• une documentation technique complète et une journalisation des événements ;
• une transparence suffisante pour que l'utilisateur professionnel comprenne les limites du système ;
• un contrôle humain effectif, conçu dès la phase de conception ;
• un niveau approprié d'exactitude, de robustesse et de cybersécurité.

La classification dépend de l'usage, jamais de la technologie employée. Un même modèle de langagegrand modèle de langageIAModèle entraîné à prédire le token suivant d'une séquence de texte. Toutes ses capacités apparentes — résumer, traduire, coder — découlent de cette unique tâche.Voir dans le glossaire relève du risque limité s'il alimente une aide à la rédaction interne, et du haut risque s'il participe au tri de candidatures. Qualifiez donc le cas d'usage avant d'évaluer l'outil.

Répartition des rôles

Le règlement distingue le fournisseur, qui développe et met sur le marché, et le déployeur, qui utilise le système sous sa propre autorité. Les obligations diffèrent.

Point d'attentionattentionIAMécanisme par lequel un modèle pondère l'importance de chaque token du contexte lorsqu'il en traite un autre, quelle que soit la distance qui les sépare.Voir dans le glossaire : modifier substantiellement un système existant, ou le commercialiser sous sa propre marque, peut faire basculer un déployeur dans le statut de fournisseur — avec l'ensemble des obligations correspondantes.

Une démarche praticable

1. Recenser les systèmes d'IA en service ou en projet.
2. Qualifier chaque cas d'usage au regard des quatre niveaux de risque.
3. Vérifier la base légale et la conformité RGPD du traitement.
4. Documenter données, limites connues et modalités de contrôle humain.
5. Informer les personnes concernées, et signaler les contenus générés.
6. Réexaminer à chaque évolution significative du système ou de son usage.

Le calendrier d'application est échelonné : les interdictions sont entrées en vigueur les premières, les obligations relatives au haut risque s'appliquent plus tardivement. Vérifiez l'échéance applicable à votre catégorie plutôt que de considérer le règlement comme un bloc unique.

Au-delà de la conformité

Les exigences du règlement — documenter les données, mesurer les biais, prévoir un contrôle humain, tracer les décisions — recouvrent largement ce qui fait la qualité d'un projet. Un système conforme est généralement un système mieux conçu : la conformité est moins une contrainte ajoutée qu'une formalisation des bonnes pratiques d'ingénierie.

Constituer le dossier de conformité

Pour un système à haut risque, la documentation n'est pas une formalité postérieure : elle se construit pendant le projet. Six pièces en constituent le cœur.

La description du système — finalité, périmètre, utilisateurs prévus, usages explicitement exclus. Ce dernier point est souvent omis et se révèle décisif en cas de litige.

La documentation des données — origine, méthode de collecte, base légale, représentativité, traitements appliqués, examen des biais et mesures correctives.

Les performances mesurées — indicateurs, jeux d'évaluation, résultats par sous-population lorsque la donnée le permet. Un écart de performance selon l'âge, le sexe ou l'origine géographique doit être documenté, pas dissimulé.

Le dispositif de contrôle humain — qui intervient, à quel moment, avec quelle formation, quelles informations, et quelle capacité effective de s'écarter de la recommandation.

La gestion des risques — risques identifiés, mesures d'atténuation, risques résiduels acceptés et par qui.

La journalisation — nature des événements enregistrés, durée de conservation, modalités d'accès.

Consignez les usages exclus aussi précisément que les usages prévus. Écrire « ce système n'est pas conçu pour évaluer des candidatures » restreint le périmètre de responsabilité et, surtout, empêche une dérivedériveIADégradation progressive des performances d'un modèle après son déploiement, causée par l'évolution des comportements ou du contexte. Elle impose surveillance et réentraînement.Voir dans le glossaire d'usage interne — laquelle est la première cause de requalification en haut risque.

Articuler AIPD et documentation AI Act

Les deux exercices se recoupent largement, sans se confondre. Les mener ensemble évite de produire deux fois la même analyse.

Menez les deux analyses en un seul exercice, mais produisez deux documents distincts. Les destinataires diffèrent — l'autorité de protection des données d'un côté, les autorités de surveillance du marché de l'autre — et les attentes de forme ne sont pas les mêmes.

Quatre erreurs de conformité fréquentes

Qualifier l'outil au lieu de l'usage. La question n'est jamais « ce modèle est-il à haut risque », mais « cet usage l'est-il ». Le même outil peut relever de deux catégories selon le contextefenêtre de contexteIAQuantité de texte qu'un modèle peut prendre en compte simultanément : question, documents fournis et historique. Au-delà, les éléments les plus anciens sortent du champ.Voir dans le glossaire.

Considérer un système interne comme hors périmètre. Un système utilisé en interne sur des salariés — évaluation, affectation, surveillance — relève des mêmes obligations qu'un système commercialisé.

Confondre transparence et information générale. Mentionner l'usage d'IA dans une politique de confidentialité ne satisfait pas l'obligation de signaler qu'un contenu est généré ou qu'un interlocuteur est une machine.

Traiter la conformité comme un jalon. Une modification substantielle du système ou de son usage rouvre la qualification. La documentation doit vivre avec le produit.

Lire l'AI Act comme une grille de risque

Le règlement européen sur l'IA classe les usages selon le niveau de risque (interdit, élevé, limité, minimal). L'idée centrale n'est pas d'interdire l'innovation : c'est d'imposer transparence, documentation et contrôles proportionnés quand un système pèse sur des droits fondamentaux (embauche, crédit, accès à un service public, biométrie, etc.).

Commencez par qualifier l'usage réel, pas la techno marketing. Un même LLMLLMIAGrand modèle de langage (Large Language Model) entraîné sur d'énormes corpus pour prédire et générer du texte.Voir dans le glossaire peut être à risque limité en assistant interne et à risque élevé s'il tranche une décision individuelle sans recours.

Documentation utile (pas cosmétique)

Constituez un dossier vivant : finalité, données d'entraînement/sources, limites connues, métriques, procédures d'escalade humaine, journalisation, et durée de conservation. Ce n'est pas seulement « pour l'audit » : c'est le mode d'emploi qui évite les incidents en 3×8.

Articulation RGPD et IA

Une base légale, une minimisation des données, des durées de conservation, et des droits des personnes restent exigibles. L'entraînement ou le logging de prompts peut contenir des données personnelles : traitez-les comme telles. L'anonymisation réelle est plus difficile qu'un simple masquage de noms.

Coller un bandeau « généré par IA » ne remplace ni l'analyse d'impact, ni le contrôle humain lorsque la décision affecte une personne.

Gouvernance minimale pour une PME / ETI

1. Un responsable nommé (même à temps partiel) pour les usages IA.
2. Un inventaire des outilstool callingIACapacité d'un agent ou d'un LLM à invoquer des outils externes (API, calcul, recherche) pendant le raisonnement.Voir dans le glossaire (SaaS inclus) et des données qu'ils voient.
3. Une politique claire : quels usages sont encouragés, lesquels sont interdits.
4. Une revue trimestrielle des incidents et des faux positifs/negatifs critiques.

Ce que le régulateur (et vos clients) vous demanderont

D'où viennent les données ? Qui peut contourner le système ? Comment une personne conteste-t-elle une décision assistée ? Combien de temps gardez-vous les logs ? Si vous savez répondre en une page claire, vous êtes déjà au-dessus de la moyenne des déploiements improvisés.

Lire l’AI Act comme un gestionnaire de risques

L’AI Act européen classe les systèmes selon le risque. Les interdits, le haut risque, les obligations de transparence et les modèles à usage général n’imposent pas la même charge. Votre premier travail n’est pas de devenir juriste : c’est de classer correctement vos cas d’usage et d’identifier les obligations associées (data governance, logging, oversight humain, conformité post-marché).

Travaillez avec le juridique et la conformité dès le cadrage, pas après le POC médiatisé.

Articulation RGPD / AI Act / sectoriel

Le RGPD continue de s’appliquer aux données personnelles. L’AI Act ajoute des obligations produits. Les secteurs (finance, santé, emploi) empilent leurs règles. Une conformité « AI Act only » est insuffisante si la base légale du traitement est fragile.

Documentez finalité, base légale, DPIA quand requis, durée de conservation des logs de prompts, sous-traitants cloud.

La classification de risque guide le budget de conformité autant que le budget technique.

Preuves et traçabilité

Conservez les éléments qui démontrent la diligence : évaluations, datasets descriptions, mesures de mitigation, versions déployées, décisions humaines. En cas de contrôle ou de litige, l’absence de traces est elle-même un risque.

Fournisseurs et contrats

Exigez des clauses sur localisation, sous-traitance, assistance en cas d’incident, droit d’audit raisonnable, engagement sur les interdits. Un contrat vague sur un modèle opaque vous laisse seul face au régulateur.

Maintenez un registre des systèmes IA (même les copilotes « shadow ») : c’est le point de départ de toute conformité sérieuse.

Obligations de transparence et information des utilisateurs

Certains systèmes imposent d’informer que l’on interagit avec une IA, ou de marquage de contenus synthétiques. Intégrez ces exigences dans les maquettes UX tôt. Un bandeau juridique ajouté la veille du go-live est un symptôme de cadrage trop tardif. Tenez une matrice obligation × écran × owner.

Coordonnez avec le DPO pour les mentions d’information et les registres. La cohérence entre politique publique et comportement réel du produit est ce que regarderont auditeurs et journalistes.

Mise en conformité progressive

Classez d’abord le portefeuille IA existant (y compris shadow IT). Traitez le haut risque en priorité. Pour le reste, planifiez transparence et documentation. Formez product owners aux obligations. Budgétez audits et évaluations. La conformité « big bang » la veille d’une échéance produit des PDF creux ; la conformité continue produit des preuves.

Travaillez des contrôles communs : logging, accès, human oversight, data quality — réutilisables sur plusieurs systèmes pour réduire le coût marginal.

Preuves opérationnelles, pas de theatre documentaire

Les autorités et les clients B2B demanderont des preuves : évaluations, mesures de mitigation, logs d’incidents, versions déployées, formation des opérateurs. Organisez un dépôt « evidence pack » par système. Un PowerPoint de conformité sans artefacts techniques ne résiste pas à une revue sérieuse. Reliez chaque obligation à un contrôle testable et à un owner nommé, avec une date de prochaine revue.

Coordination juridique–produit–sécu

Installez un rituel mensuel court : nouveaux cas d’usage, reclassement de risque, incidents, échéances réglementaires. Trois rôles minimum à table. Sans rituel, la conformité redevient un sprint de panique. Produisez un compte-rendu d’une page archivé avec le registre IA. C’est peu coûteux et extrêmement rentable lors d’un audit ou d’une due diligence client.