Pédagogique · Par stade de projet · Sources EUR-Lex

Articles clés des obligations RGPD, AI Act, CRA et Data Act : votre porte d'entrée pédagogique

Le RGPD et l'AI Act, ce ne sont pas que l'Article 50 — et deux autres règlements vous concernent peut-être sans que vous le sachiez : le Cyber Resilience Act si vos utilisateurs installent votre logiciel, et le Data Act sur la portabilité. Voici la sélection des articles qui frappent réellement un solopreneur IA, organisée selon votre cycle de vie projet : avant de coder, au lancement, en opération. Pour chacun : pourquoi c'est votre problème, ce que dit l'article, une ou deux actions concrètes, et le lien vers le texte officiel.

EuTrustedIA documente la conformité, elle ne certifie jamais (RGPD Art. 42-43 / AI Act Art. 43). Ce contenu est pédagogique et factuel — ce n'est pas un conseil juridique. La revue et la signature relèvent d'un DPO ou d'un avocat tech. Cette page n'est pas exhaustive : c'est une porte d'entrée.

Étape 1

Avant de coder

Les arbitrages structurants se jouent ici. Une base légale mal choisie ou une pratique interdite ne se rattrape pas après le build.

RGPD Art. 25 — Protection des données dès la conception

Pourquoi c'est votre problème : Si vous attendez d'avoir codé pour penser conformité, vous reconstruisez. Anticiper la minimisation des données dès l'architecture vous évite un refactoring coûteux.

Ce que dit l'article : Vous devez intégrer la protection des données dans la conception même de votre système et par défaut (minimisation, paramètres protecteurs par défaut).

À faire : Cartographier les données collectées et supprimer tout ce qui n'est pas strictement nécessaire ; activer les réglages les plus protecteurs par défaut.

Lire l'Article 25 sur EUR-Lex

RGPD Art. 9 — Catégories particulières (données sensibles)

Pourquoi c'est votre problème : Si votre agent IA touche à la santé, aux opinions, à la biométrie ou à la vie privée intime, le traitement est quasi impossible sans consentement explicite — autant le savoir avant.

Ce que dit l'article : Le traitement des données sensibles (santé, opinions, biométrie, orientation, syndicat) est interdit par principe, sauf exceptions strictes dont le consentement explicite.

À faire : Vérifier si votre cas d'usage traite ces données ; si oui, sécuriser une base d'exception valable (souvent le consentement explicite) avant tout traitement.

Lire l'Article 9 sur EUR-Lex

RGPD Art. 35 — Analyse d'impact (AIPD)

Pourquoi c'est votre problème : L'article 35 ne fixe aucun seuil chiffré — ni nombre de personnes, ni volume, ni taille d'entreprise. Le critère est le risque élevé, apprécié au cas par cas. Le savoir vous évite les deux erreurs : croire qu'un chiffre vous met à l'abri, et croire qu'aucun ne vous concerne.

Ce que dit l'article : Une analyse d'impact est due avant le traitement lorsque celui-ci est susceptible d'engendrer un risque élevé pour les droits et libertés (§ 1). Le § 3 cite trois cas où elle est « en particulier » requise : ils illustrent ce critère, ils ne l'épuisent pas. S'y ajoutent les listes publiées par l'autorité de contrôle (§ 4 et § 5) — en France, celles de la CNIL.

À faire : Évaluer le risque de chaque traitement plutôt que de chercher un seuil ; si l'analyse est due, la rédiger avec les quatre éléments du § 7 (opérations et finalités, nécessité et proportionnalité, risques, mesures). POSITRONIA-CORE en pré-remplit la trame. Elle se réexamine quand le risque change (§ 11) : ce n'est pas un document qu'on classe.

Lire l'Article 35 sur EUR-Lex

AI Act Art. 5 — Pratiques interdites

Pourquoi c'est votre problème : Manipulation subliminale, notation sociale, reconnaissance d'émotion au travail : si votre produit tombe dedans, il est purement illégal. C'est éliminatoire, pas négociable.

Ce que dit l'article : Certaines pratiques d'IA sont totalement interdites dans l'UE (manipulation, exploitation de vulnérabilités, notation sociale, catégorisation biométrique sensible, etc.).

À faire : Confronter votre concept à la liste des interdictions avant de coder ; si une fonctionnalité s'en approche, la repenser ou l'abandonner.

Lire l'Article 5 sur EUR-Lex

AI Act Art. 6 + Annexe III — Classification à haut risque

Pourquoi c'est votre problème : RH, éducation, crédit, santé, justice : si votre IA y opère, vous basculez dans un régime d'obligations lourdes (qualité des données, traçabilité, surveillance humaine).

Ce que dit l'article : Les systèmes relevant de l'Annexe III sont présumés à haut risque et soumis aux obligations renforcées des Articles 9 à 15 (gouvernance, robustesse, surveillance humaine). L'Article 6 § 3 prévoit une exception lorsque le système ne présente pas de risque important — elle ne s'applique jamais s'il profile des personnes physiques.

À faire : Vérifier si votre domaine figure à l'Annexe III ; si oui, intégrer les obligations haut risque dès la conception et prévoir une revue par un expert.

Lire l'Article 6 sur EUR-Lex

Étape 2

Au lancement

Mise en service : contrats avec vos fournisseurs, registre, sécurité et transparence vis-à-vis de vos utilisateurs.

RGPD Art. 28 — Sous-traitants (DPA)

Pourquoi c'est votre problème : Pas de contrat de sous-traitance signé avec votre fournisseur LLM ou cloud = violation pure et simple. C'est l'oubli n°1 des solopreneurs IA.

Ce que dit l'article : Tout recours à un sous-traitant (LLM, hébergeur, outils) doit être encadré par un contrat de sous-traitance (DPA) définissant les garanties et instructions.

À faire : Lister vos fournisseurs traitant des données ; récupérer et signer un DPA avec chacun (Mistral, OpenAI, Anthropic, hébergeur…).

Lire l'Article 28 sur EUR-Lex

RGPD Art. 30 — Registre des traitements

Pourquoi c'est votre problème : La dispense « moins de 250 employés » existe (Art. 30 § 5), mais elle tombe dès qu'UNE seule de trois conditions est remplie : un risque pour les personnes, des données sensibles, ou — celle qui décide presque toujours — un traitement qui n'est pas occasionnel. Un service qui tourne en continu n'a rien d'occasionnel.

Ce que dit l'article : L'article 30 décrit deux registres, au contenu différent : celui du responsable du traitement (§ 1, sept rubriques — finalités, catégories de personnes et de données, destinataires, transferts hors UE, délais d'effacement, mesures de sécurité) et celui du sous-traitant (§ 2, quatre rubriques). Si vous éditez un produit IA, vous êtes souvent les deux à la fois.

À faire : Déterminer d'abord dans quel rôle vous agissez pour chaque traitement, puis tenir le registre correspondant (un tableau suffit) ; POSITRONIA-CORE en pré-remplit la base. Il se tient par écrit et se présente à l'autorité sur demande : il ne se dépose nulle part.

Lire l'Article 30 sur EUR-Lex

RGPD Art. 32 — Sécurité du traitement

Pourquoi c'est votre problème : Chiffrement, MFA, sauvegardes, gestion des incidents : si vous vendez de l'IA sans ces bases, la première fuite vous expose directement.

Ce que dit l'article : Vous devez mettre en place des mesures techniques et organisationnelles appropriées au risque (chiffrement, contrôle d'accès, résilience, tests réguliers).

À faire : Activer le chiffrement au repos et en transit, le MFA sur les accès admin et des sauvegardes testées ; documenter ces mesures.

Lire l'Article 32 sur EUR-Lex

AI Act Art. 50 — Transparence : tout dépend de votre rôle

Pourquoi c'est votre problème : C'est l'article le plus mal compris du marché. Non, il n'impose pas de marquer tout contenu produit avec une IA : il répartit ses obligations entre le fournisseur du système et celui qui le déploie. Savoir lequel vous êtes vous évitera du travail inutile — et vous dira ce qui vous vise vraiment.

Ce que dit l'article : Fournisseur (vous construisez et mettez en service un système IA) : informer que l'on parle à une IA (§ 1, sauf si évident), et marquer les contenus synthétiques en format lisible par machine (§ 2). Déployeur (vous utilisez un outil conçu par d'autres) : uniquement les deepfakes et les textes publiés pour informer le public sur des sujets d'intérêt public (§ 4) — sauf relecture humaine assumée — et la reconnaissance d'émotions ou la catégorisation biométrique (§ 3).

À faire : Commencez par vous situer. Si vous êtes fournisseur, POSITRONIA génère la fiche Article 50 depuis votre carte. Si vous êtes simple déployeur et que vous relisez vos contenus, il n'y a rien à faire — et nous vous le dirons.

Lire l'Article 50 sur EUR-Lex

Étape 3

En opération & passage à l'échelle

Le run continu et la croissance ouvrent de nouvelles obligations : décisions automatisées, incidents, et la discipline des principes de base.

RGPD Art. 22 — Décision automatisée et profilage

Pourquoi c'est votre problème : Si votre IA décide seule d'un effet juridique (RH, crédit, accès à un service), la personne a droit à une intervention humaine. Critique pour tout produit IA décisionnel.

Ce que dit l'article : Une personne a le droit de ne pas faire l'objet d'une décision fondée exclusivement sur un traitement automatisé produisant des effets juridiques ou significatifs.

À faire : Identifier vos décisions 100 % automatisées à effet juridique ; prévoir un recours humain et l'information de la personne (humain dans la boucle).

Lire l'Article 22 sur EUR-Lex

RGPD Art. 33-34 — Notification de violation sous 72 h

Pourquoi c'est votre problème : En cas de fuite, le chronomètre démarre : 72 heures pour notifier la CNIL. Sans procédure prête, vous découvrez le délai au pire moment.

Ce que dit l'article : Une violation de données doit être notifiée à l'autorité de contrôle sous 72 heures, et aux personnes concernées si le risque est élevé.

À faire : Préparer à l'avance une fiche de procédure violation (qui contacter, quoi documenter, modèle de notification) avant d'en avoir besoin.

Lire l'Article 33 sur EUR-Lex

Cyber Resilience Act — si vos utilisateurs installent quelque chose, vous êtes fabricant

Pourquoi c'est votre problème : C'est le régime que presque personne n'attend, et il ne parle pas d'IA. Dès que votre utilisateur installe quelque chose — application de bureau ou mobile, extension, ligne de commande, paquet, image de conteneur — vous ne faites plus qu'exploiter un service : vous mettez un produit sur le marché. La gratuité n'y change rien : la définition vise la mise à disposition « contre paiement, monétisation ou gratuitement ».

Ce que dit l'article : Le CRA (règlement (UE) 2024/2847) impose au fabricant deux séries d'obligations, à deux dates distinctes. Au 11 septembre 2026 : signaler les vulnérabilités activement exploitées et les incidents graves (24 h / 72 h / 14 j). Au 11 décembre 2027 : marquage CE, documentation technique et période de support annoncée à l'achat. Le service dont votre logiciel dépend pour fonctionner (licence en ligne, synchronisation, authentification) entre dans le périmètre avec lui — pouvoir travailler hors ligne ne l'exclut pas.

À faire : Posez-vous d'abord la question qui tranche : mes utilisateurs installent-ils quelque chose ? Si non, vous êtes hors périmètre, et c'est une bonne nouvelle qui mérite d'être dite. Si oui, écrivez votre procédure de signalement avant d'en avoir besoin — et sachez que le même incident peut relever à la fois du CRA et du RGPD, avec des destinataires différents mais un déclencheur commun : le moment où vous en prenez connaissance. Qui sait déjà notifier une violation de données a fait la moitié du chemin.

Lire le Cyber Resilience Act sur EUR-Lex

RGPD Art. 5 — Principes (minimisation, conservation, exactitude)

Pourquoi c'est votre problème : C'est la base de toute défense : ces principes s'appliquent toujours, et l'oubli de la limitation de conservation est l'erreur silencieuse la plus fréquente.

Ce que dit l'article : Le traitement doit respecter licéité, minimisation, exactitude, limitation de conservation, intégrité et responsabilité (accountability).

À faire : Définir des durées de conservation et purger automatiquement les données obsolètes ; ne collecter que le strictement nécessaire.

Lire l'Article 5 sur EUR-Lex

Data Act — Portabilité & anti-lock-in (mention déclarative)

Pourquoi c'est votre problème : Le Data Act vous donne des droits de portabilité et facilite le changement de fournisseur cloud. Vous êtes plutôt bénéficiaire de droits que débiteur d'obligations.

Ce que dit l'article : Le Data Act (Règlement UE 2023/2854) encadre l'accès aux données et le changement de prestataire cloud (portabilité, clauses, juridiction).

À faire : Vérifier les clauses de sortie et de portabilité de vos contrats cloud ; privilégier des formats et fournisseurs qui évitent l'enfermement.

Lire le Data Act sur EUR-Lex

Passer de la liste d'articles à l'action

Cette page est une porte d'entrée. Pour aller plus loin : le Livre Blanc EUDAI documente les 5 piliers en profondeur, la checklist 36 points vous donne un diagnostic rapide, et les plans EuTrustedIA outillent concrètement votre conformité à un prix solopreneur.

Lire le Livre Blanc EUDAI Faire la checklist 36 points Voir les plans EuTrustedIA