RGPD et AI Act en entreprise : guide opérationnel pour les dirigeants

Ce document a pour objectif d’expliquer, en termes clairs et juridiquement prudents, ce que le RGPD et le règlement européen sur l’intelligence artificielle (AI Act) changent concrètement pour une entreprise qui collecte, utilise, stocke, partage ou exploite des données et des outils d’intelligence artificielle dans le cadre de ses activités.

Il ne remplace ni un audit juridique, ni une analyse de conformité, ni les conseils d’un avocat ou d’un délégué à la protection des données. En revanche, il permet à un dirigeant de comprendre les enjeux, d’identifier les points d’alerte et de structurer ses priorités.

Avertissement : Chaque prise de décision, chaque orientation, chaque interprétation s'appliquant à un cas particulier et fondée sur les éléments fournis doit impérativement faire l'objet d'une validation effectuée par un professionnel du droit.

1. Ce qu’un dirigeant doit retenir avant tout

1.1. Le RGPD ne vise pas l’IA en tant que telle : il vise les données personnelles

Dès lors qu’un outil, y compris un outil d’IA, traite des données permettant d’identifier directement ou indirectement une personne physique, le RGPD peut s’appliquer. Cela concerne par exemple les données de clients, prospects, salariés, candidats, fournisseurs, patients, usagers, abonnés ou visiteurs d’un site web.

1.2. L’AI Act ne remplace pas le RGPD : il s’y ajoute

Le RGPD encadre les traitements de données personnelles. L’AI Act encadre, selon les cas, la mise sur le marché, la mise en service, le développement, le déploiement et l’utilisation de certains systèmes d’IA, avec un niveau d’exigence variable selon leur catégorie de risque.

1.3. Utiliser un outil d’IA n’efface pas la responsabilité de l’entreprise

Le fait d’utiliser un service tiers, un logiciel SaaS, un assistant conversationnel, un outil RH, un moteur de scoring, un système de reconnaissance ou un service de génération de contenu ne transfère pas automatiquement la responsabilité juridique de l’entreprise. Selon les cas, l’entreprise peut être responsable de traitement au sens du RGPD, déployeur au sens de l’AI Act, ou les deux.

1.4. Le risque principal n’est pas seulement l’amende

Le risque réel est plus large : atteinte à la réputation, désorganisation interne, contentieux prud’homaux, litiges clients, défaut de preuve, impossibilité d’expliquer une décision assistée par IA, dépendance à un fournisseur mal encadré, incident de sécurité, blocage d’un projet ou nécessité de retrait en urgence d’un usage non maîtrisé.

1.5. Pour la plupart des PME, la conformité commence par une gouvernance simple mais réelle

Dans la majorité des cas, les premières priorités sont les suivantes : inventorier les usages d’IA, cartographier les données traitées, vérifier les bases légales, encadrer les fournisseurs, fixer des règles internes d’usage, sécuriser les accès, préparer la gestion des droits des personnes et organiser la réaction en cas d’incident.

2. Ce qu’est une donnée personnelle au sens du RGPD

2.1. Définition utile pour l’entreprise

Une donnée personnelle est toute information se rapportant à une personne physique identifiée ou identifiable. Il ne s’agit pas seulement d’un nom ou d’un prénom. Une adresse e-mail nominative, un numéro de téléphone, une voix, une photo, une adresse IP, un identifiant client, un historique de navigation ou un ensemble d’éléments recoupés peuvent suffire.

2.2. Ce qui n’est pas couvert de la même manière

Le RGPD ne protège pas, en tant que telles, les données relatives aux personnes morales. En revanche, dès qu’une information permet de rattacher une donnée à une personne physique identifiable, le règlement redevient pertinent. En pratique, beaucoup de données dites “professionnelles” restent des données personnelles.

2.3. Conséquence pour les outils d’IA

Un dirigeant ne doit jamais raisonner ainsi : “ce n’est qu’un prompt” ou “ce n’est qu’un test”. Si le prompt, le document transmis, le ticket d’incident, le CV, l’entretien, l’enregistrement audio ou le tableau d’évaluation contient des données personnelles, l’usage de l’outil peut relever du RGPD.

3. Ce qu’est un traitement de données

3.1. Une notion très large

Le traitement comprend pratiquement toute opération sur des données : collecte, consultation, enregistrement, organisation, analyse, conservation, transmission, rapprochement, suppression, export, indexation, annotation, enrichissement, hébergement, synchronisation, partage ou génération d’une sortie à partir d’un ensemble de données.

3.2. Conséquence concrète

Utiliser un CRM, une messagerie, un logiciel RH, un outil de marketing automation, un assistant IA, un chatbot interne, une solution de transcription, un moteur de recommandation ou un service cloud peut constituer un traitement de données personnelles. La question n’est donc pas de savoir si l’outil est “intelligent”, mais ce qu’il fait avec quelles données et pour quelle finalité.

4. Rôles juridiques : ce que le dirigeant doit comprendre

4.1. Responsable de traitement et sous-traitant en RGPD

Le responsable de traitement est l’entité qui détermine les finalités et les moyens essentiels du traitement. Dans la pratique, il s’agit très souvent de l’entreprise. Le sous-traitant agit pour le compte du responsable de traitement. Un fournisseur de logiciel, d’hébergement, d’outil d’IA ou de service SaaS peut être sous-traitant, mais pas automatiquement : tout dépend de son rôle réel et de son autonomie dans le traitement.

4.2. Déployeur en AI Act

Dans l’AI Act, l’entreprise qui utilise un système d’IA dans un cadre professionnel peut être qualifiée de déployeur, même si elle n’a pas développé elle-même le système. Ce point est essentiel : l’entreprise utilisatrice n’est pas hors champ au seul motif qu’elle achète ou souscrit un service existant.

4.3. Le dirigeant n’est pas toujours personnellement le “responsable de traitement” au sens strict

Il est préférable, juridiquement, de distinguer l’entreprise en tant qu’organisation et le dirigeant en tant que personne physique. L’entreprise est souvent le responsable de traitement. En revanche, le dirigeant porte une responsabilité de gouvernance, d’organisation, de contrôle et de validation des choix structurants. Dans certains cas, sa responsabilité personnelle peut être recherchée, mais il ne faut pas confondre systématiquement les deux niveaux.

5. Les grands principes RGPD à respecter dans l’entreprise

5.1. Licéité, loyauté et transparence

Un traitement doit reposer sur une base légale, être mis en œuvre de manière loyale et être expliqué de façon compréhensible aux personnes concernées. Une collecte discrète, une réutilisation inattendue ou une notice d’information trop vague fragilise la conformité.

5.2. Finalité déterminée

Les données doivent être collectées pour un objectif précis, explicite et légitime. Une entreprise ne doit pas collecter de manière indifférenciée en pensant que “cela pourra servir plus tard”. Une donnée collectée pour gérer une commande n’est pas librement réutilisable pour entraîner un outil interne ou pour nourrir un usage RH ou commercial différent sans examen juridique.

5.3. Minimisation des données

L’entreprise doit se limiter aux données pertinentes et nécessaires. Ce principe est central pour les usages d’IA : il faut éviter d’injecter un document complet si quelques informations suffisent, d’envoyer des données identifiantes si une anonymisation ou une pseudonymisation est possible, ou de transmettre des pièces entières alors qu’un extrait neutre ferait l’affaire.

5.4. Exactitude

Les données inexactes doivent être corrigées ou supprimées. En environnement IA, ce point est sensible : une donnée erronée dans un dossier, un fichier RH ou un historique client peut produire une sortie trompeuse, un classement injustifié, une recommandation fautive ou une décision biaisée.

5.5. Limitation de la conservation

Les données ne doivent pas être conservées indéfiniment. L’entreprise doit fixer des durées de conservation ou des critères clairs, distinguer archivage et usage courant, et s’assurer que ses prestataires n’allongent pas de fait la conservation au-delà de ce qui est prévu.

5.6. Intégrité et confidentialité

Le responsable de traitement doit assurer un niveau de sécurité approprié : gestion des habilitations, authentification, journalisation, sauvegarde, chiffrement lorsque pertinent, cloisonnement, contrôle des accès, politiques de mot de passe, supervision, capacité de restauration et gestion des incidents.

5.7. Accountability

Il ne suffit pas d’être conforme ; il faut être capable de le démontrer. Cela suppose, selon la taille et la complexité de l’entreprise, une documentation adaptée : registre, politiques, clauses contractuelles, procédures internes, preuves de sensibilisation, fiches d’analyse, comptes rendus d’arbitrage, gestion des incidents, revue des fournisseurs et, si nécessaire, analyse d’impact.

6. Les bases légales : point critique souvent sous-estimé

6.1. Pas de traitement licite sans base légale

Le choix de la base légale doit être fait avant la mise en œuvre du traitement. Ce choix ne doit pas être opportuniste ou purement déclaratif. Il conditionne les droits des personnes, la documentation, les notices d’information et la solidité de la conformité.

6.2. Les principales bases légales en entreprise

Les bases les plus fréquentes sont l’exécution d’un contrat, le respect d’une obligation légale, l’intérêt légitime, le consentement, la sauvegarde des intérêts vitaux et l’exécution d’une mission d’intérêt public. En pratique, les entreprises privées recourent surtout aux quatre premières selon les cas.

6.3. Le consentement n’est pas la base légale universelle

Le consentement doit être libre, spécifique, éclairé et univoque, et pouvoir être retiré. En environnement salarié, il est souvent délicat car le lien de subordination peut faire douter de la liberté réelle du consentement. Il ne faut donc pas le brandir comme réflexe automatique.

6.4. L’intérêt légitime exige une vraie mise en balance

Invoquer un intérêt économique, organisationnel ou sécuritaire ne suffit pas. Il faut démontrer que le traitement est nécessaire, proportionné et que les droits et libertés des personnes ne prévalent pas. Une entreprise qui utilise l’IA pour classer, profiler, surveiller ou prédire des comportements doit être particulièrement prudente.

6.5. Le contrat n’autorise pas tout

Le fait de mentionner un traitement dans des conditions générales ou dans une clause contractuelle ne suffit pas à le rendre licite. Le traitement doit être objectivement nécessaire à l’exécution du contrat. Une réutilisation secondaire pour enrichissement algorithmique, prospection ou évaluation n’entre pas automatiquement dans cette base légale.

7. Données sensibles et catégories particulières de données

7.1. Ce qui est concerné

Le RGPD protège de façon renforcée certaines catégories de données, notamment les données de santé, les données biométriques lorsqu’elles servent à identifier une personne de manière unique, les données révélant l’origine raciale ou ethnique, les opinions politiques, les convictions religieuses ou philosophiques, l’appartenance syndicale, la vie sexuelle ou l’orientation sexuelle.

7.2. Conséquence pratique

Le principe est l’interdiction de traitement, sauf exception prévue par le texte. En entreprise, les risques apparaissent vite : médecine du travail, absences, handicap, dispositifs biométriques, outils RH, analyses comportementales, messageries contenant des informations sensibles, documents scannés ou pièces jointes versées dans des outils d’IA.

7.3. Message de prudence pour les dirigeants

Il faut éviter d’exposer des données sensibles à des outils d’IA sans analyse juridique préalable. Le risque n’est pas seulement théorique : il combine atteinte aux droits fondamentaux, incident de sécurité, défaut de base légale, défaut d’information et usage potentiellement disproportionné.

8. Information des personnes : une obligation de clarté, pas de jargon

8.1. Ce que l’entreprise doit expliquer

Lorsque des données sont collectées, l’entreprise doit informer la personne concernée sur l’identité du responsable de traitement, les finalités, la base légale, les destinataires, la durée de conservation ou les critères qui la déterminent, l’existence des droits, le droit d’introduire une réclamation, ainsi que certaines autres informations selon les cas, notamment en cas de transferts ou de prise de décision automatisée.

8.2. Ce qui rend l’information insuffisante

Une politique de confidentialité copiée-collée, trop générique, imprécise, contradictoire avec les usages réels ou silencieuse sur un outil d’IA réellement utilisé peut être problématique. Le droit exige une information intelligible, pas un habillage juridique déconnecté des pratiques.

8.3. Cas fréquent

Si une entreprise utilise un outil d’IA pour assister le tri des candidatures, l’analyse des demandes clients, la priorisation des tickets, la détection de fraude ou la génération de réponses, elle doit vérifier si l’information fournie aux personnes reflète réellement ces usages.

9. Droits des personnes : il faut pouvoir répondre concrètement

9.1. Les principaux droits

Les personnes concernées disposent notamment d’un droit d’accès, de rectification, d’effacement, d’opposition, de limitation du traitement et, dans certains cas, d’un droit à la portabilité. Ces droits ne sont pas purement théoriques : l’entreprise doit disposer d’un dispositif concret pour les traiter.

9.2. Délai de réponse

En principe, l’entreprise doit répondre dans un délai d’un mois, prolongeable dans certains cas prévus par le texte. Ce délai suppose une organisation réelle : identification du service compétent, procédure interne, traçabilité des demandes, capacité à localiser les données et à agir chez les sous-traitants si nécessaire.

9.3. Cas délicat avec l’IA

Une entreprise qui injecte des données dans plusieurs systèmes, y compris des outils d’IA, doit être capable d’expliquer où se trouvent les données, ce qui a été transmis, ce qui est conservé, ce qui peut être rectifié ou supprimé, et dans quelles limites techniques ou juridiques. Il ne faut pas promettre plus que ce qui est réellement maîtrisé.

10. Sous-traitants, prestataires et fournisseurs d’IA

10.1. Vérifier les garanties, pas seulement la notoriété

Le fait qu’un fournisseur soit connu, pratique, populaire ou ergonomique ne dispense pas de vérifier son cadre contractuel, ses engagements, ses mesures de sécurité, sa politique de conservation, sa gestion des sous-traitants ultérieurs, les lieux de traitement, les mécanismes de transfert, les possibilités de journalisation, les options de désactivation de certains usages secondaires et la répartition réelle des rôles.

10.2. Encadrement contractuel

Lorsqu’un prestataire agit en qualité de sous-traitant, un contrat conforme au RGPD est requis. Il doit notamment préciser l’objet, la durée, la nature des opérations, les catégories de données, les obligations du sous-traitant, les mesures de sécurité, les conditions de recours à d’autres sous-traitants et les modalités d’assistance.

10.3. Outils “gratuits”, “essai” ou “freemium”

Un dirigeant doit être très prudent. Ce n’est pas le caractère gratuit ou d’essai qui rend l’outil illicite en soi ; c’est l’absence éventuelle de garanties adaptées, l’usage de données personnelles sans encadrement suffisant, l’impossibilité de maîtriser les flux ou la réutilisation des contenus transmis. Il faut donc évaluer le service avant tout usage réel.

10.4. Transferts hors Union européenne

Tout usage d’un fournisseur situé hors de l’Union ou impliquant des flux internationaux doit être examiné. La question n’est pas seulement géographique ; elle porte aussi sur le cadre juridique applicable, les garanties offertes, la chaîne des sous-traitants et le niveau réel de protection.

11. Sécurité du traitement

11.1. La sécurité n’est pas une clause abstraite

L’obligation de sécurité exige des mesures techniques et organisationnelles appropriées. En fonction du contexte, cela peut inclure la segmentation des accès, l’authentification forte, la gestion des habilitations, la journalisation, le chiffrement, les sauvegardes testées, la revue des droits, la supervision, le durcissement des postes, la gestion des vulnérabilités, la sécurité des API, la maîtrise des exports et la formation des utilisateurs.

11.2. Les usages d’IA créent des surfaces de risque spécifiques

Les risques classiques demeurent, mais certains s’accentuent : divulgation involontaire dans un prompt, fuite d’informations via une intégration, récupération de contenus sensibles par un tiers, mauvaise configuration des accès, journalisation insuffisante, absence de cloisonnement entre environnements, automatisation non revue par l’humain, ou dépendance excessive à un fournisseur.

11.3. Ce qu’un dirigeant doit exiger

Il doit exiger une politique claire d’accès aux données, une doctrine d’usage des outils d’IA, une revue des prestataires, des procédures de remontée d’incident et, lorsque nécessaire, des restrictions simples mais fermes : interdiction de coller certains documents dans des outils non validés, séparation des environnements, suppression régulière des historiques et validation préalable des cas d’usage sensibles.

12. Violations de données : obligation d’anticiper, pas seulement de réagir

12.1. Ce qu’est une violation

Une violation de données n’est pas seulement un piratage spectaculaire. Il peut s’agir d’une perte de disponibilité, d’une altération, d’une destruction, d’un envoi au mauvais destinataire, d’un accès indu, d’une fuite via un outil, d’un partage mal paramétré, d’une exposition temporaire ou d’une erreur humaine.

12.2. Notification à l’autorité

Lorsqu’une violation de données personnelles est susceptible d’engendrer un risque pour les droits et libertés des personnes, elle doit en principe être notifiée à l’autorité compétente dans les 72 heures après en avoir pris connaissance. Ce délai est court ; il suppose une capacité d’analyse, d’escalade et de documentation immédiate.

12.3. Information des personnes

Lorsque la violation est susceptible d’engendrer un risque élevé pour les droits et libertés des personnes, celles-ci doivent également être informées, sauf exceptions prévues par le texte. Une entreprise doit donc préparer des scénarios de crise, pas improviser au moment de l’incident.

13. Analyse d’impact relative à la protection des données (AIPD)

13.1. Quand y penser

L’AIPD est requise lorsqu’un traitement est susceptible d’engendrer un risque élevé pour les droits et libertés des personnes. Le sujet apparaît fréquemment en cas de surveillance, de profilage, d’évaluation systématique, de traitement à grande échelle, de combinaison de données, d’usage de technologies nouvelles ou d’exploitation de données sensibles.

13.2. Pourquoi l’IA est souvent concernée

Un projet d’IA peut rendre l’AIPD nécessaire, notamment s’il sert à classer des personnes, prendre ou assister des décisions importantes, détecter des comportements, croiser des sources multiples, analyser des éléments sensibles ou produire des effets significatifs sur des individus.

13.3. Ce que l’AIPD apporte

Elle ne se résume pas à un document de plus. Elle sert à cartographier les risques, à vérifier la proportionnalité, à prévoir des mesures de réduction de risque et à démontrer que le projet a été examiné avant sa mise en œuvre.

14. Décisions automatisées et intervention humaine

14.1. Éviter les raccourcis

Il faut éviter d’affirmer de manière trop générale que toute décision automatisée serait interdite. En réalité, le sujet dépend du contexte, de la nature du traitement, de l’effet produit sur la personne, de la base légale retenue et des garanties prévues.

14.2. Ce que le dirigeant doit retenir

Plus un système influence de manière significative une décision concernant une personne, plus l’entreprise doit être en mesure de justifier son usage, d’expliquer le rôle du système, de prévoir une supervision humaine adaptée et de respecter les garanties prévues par le droit applicable.

14.3. Cas typiques

Recrutement, notation interne, évaluation de solvabilité, priorisation automatisée de demandes, détection de fraude, filtrage d’accès, analyses de comportement et décisions ayant un effet juridique ou significatif doivent être abordés avec une prudence renforcée.

15. L’AI Act : ce qu’il ajoute pour les dirigeants

15.1. Logique générale du règlement

L’AI Act repose sur une approche par niveaux de risque. Certaines pratiques sont interdites. D’autres usages sont soumis à des obligations fortes, notamment pour les systèmes à haut risque. D’autres enfin relèvent principalement d’obligations de transparence ou de règles plus limitées.

15.2. Calendrier d’application à connaître

Le règlement s’applique de manière générale à partir du 2 août 2026. Toutefois, certaines dispositions s’appliquent plus tôt : les définitions, les pratiques interdites et les obligations relatives à la maîtrise de l’IA sont applicables depuis le 2 février 2025 ; certaines règles relatives à la gouvernance, aux sanctions et aux modèles d’IA à usage général s’appliquent depuis le 2 août 2025.

15.3. Conséquence pratique

Une entreprise ne doit pas attendre août 2026 pour réfléchir à sa gouvernance IA. Les usages sont déjà juridiquement sensibles, et les attentes en matière de pilotage, de compétence, de documentation et de transparence sont déjà structurantes.

16. Les pratiques d’IA interdites

16.1. Principe

Certaines pratiques sont interdites en raison du niveau de risque qu’elles font peser sur les droits fondamentaux. Une entreprise doit donc vérifier qu’un outil ou un cas d’usage ne relève pas d’une catégorie prohibée, même s’il est techniquement disponible sur le marché.

16.2. Ce qu’un dirigeant doit surveiller

Sans entrer dans un catalogue technique intégral, il faut retenir qu’une vigilance particulière s’impose pour les usages susceptibles de manipuler les comportements de manière trompeuse ou coercitive, d’exploiter la vulnérabilité de certaines personnes, d’organiser des formes de notation sociale, ou de recourir à certaines catégorisations biométriques ou inférences particulièrement sensibles hors des cadres autorisés.

16.3. Message pratique

Si un outil promet de détecter des traits psychologiques, l’état émotionnel, la loyauté, la dangerosité, l’aptitude, la sincérité ou le “potentiel caché” d’une personne à partir de signaux faibles, d’images, de voix ou de comportements, il faut déclencher immédiatement un examen juridique et éthique avant tout déploiement.

17. La maîtrise de l’IA : obligation de compétence

17.1. Ce que cela signifie réellement

L’AI Act impose des obligations relatives à la maîtrise de l’IA. Pour un dirigeant, cela signifie qu’il doit veiller à ce que les personnes qui développent, déploient, pilotent, administrent ou utilisent des systèmes d’IA dans l’entreprise disposent d’un niveau de compréhension approprié à leurs missions, aux risques encourus et au contexte d’usage.

17.2. Ce que cela ne signifie pas

Il ne s’agit pas nécessairement d’imposer la même formation exhaustive à tout le monde. L’approche pertinente consiste à adapter la sensibilisation, la formation, les consignes et les contrôles selon les fonctions : direction, RH, support, commerce, métiers, sécurité, conformité, IT, management.

17.3. Ce qu’il faut documenter

Il est prudent de pouvoir démontrer l’existence de mesures de sensibilisation, de consignes d’usage, de points de vigilance, d’un dispositif de remontée d’alerte et, pour les usages sensibles, d’une validation plus formelle.

18. Transparence et information en matière d’IA

18.1. Éviter une formule trompeuse

Il ne faut pas affirmer de manière générale que tout contenu généré par IA devrait obligatoirement porter la mention “contenu généré par IA”. L’AI Act prévoit des obligations de transparence dans des cas précis, et d’autres obligations de transparence peuvent résulter d’autres textes ou du contexte d’usage.

18.2. Ce que le dirigeant doit retenir

Lorsqu’un système d’IA interagit avec des personnes, génère certains contenus, produit des sorties susceptibles d’induire en erreur ou intervient dans des cas sensibles, l’entreprise doit vérifier si une information explicite est due, à qui, sous quelle forme, à quel moment et avec quel niveau de détail.

18.3. Cas des systèmes à haut risque visés par l’annexe III

Lorsqu’un déployeur utilise un système d’IA à haut risque relevant de l’annexe III pour prendre ou assister des décisions relatives à des personnes physiques, il doit, dans les conditions prévues par le règlement, informer ces personnes qu’elles sont soumises à l’utilisation de ce système.

19. Les systèmes d’IA à haut risque

19.1. Pourquoi cette catégorie est centrale

Le cœur opérationnel de l’AI Act, pour beaucoup d’entreprises, réside dans l’identification des systèmes à haut risque. Tous les outils d’IA ne sont pas à haut risque. En revanche, lorsque l’on y entre, les exigences montent fortement.

19.2. Domaines particulièrement sensibles

Parmi les cas emblématiques figurent certains systèmes utilisés dans l’emploi, la gestion des travailleurs, le recrutement, l’accès à l’éducation, certains services essentiels, certains usages de sécurité, certaines évaluations ou décisions affectant des personnes physiques, ainsi que d’autres catégories prévues par les annexes du règlement.

19.3. Réflexe dirigeant

Dès qu’un outil classe, sélectionne, note, filtre, écarte, priorise ou influence de manière structurée le sort d’une personne dans un contexte d’emploi, de service, d’accès, de sécurité ou de décision importante, il faut vérifier sérieusement si l’on se trouve en présence d’un système à haut risque.

20. Obligations du déployeur en cas d’IA à haut risque

20.1. Utiliser le système conformément à sa destination

L’entreprise utilisatrice ne peut pas détourner librement un système d’IA à haut risque de sa finalité prévue. Elle doit tenir compte de la documentation fournie, des instructions d’utilisation, des limites, des performances attendues et des conditions de déploiement.

20.2. Assurer une supervision humaine adaptée

La supervision humaine ne doit pas être purement décorative. Elle suppose que les personnes chargées du contrôle puissent réellement comprendre le rôle du système, détecter des anomalies, remettre en cause une sortie, suspendre un résultat ou corriger un usage inadapté.

20.3. Veiller à la qualité des données d’entrée

Dans la mesure où l’entreprise contrôle les données d’entrée, elle doit s’assurer qu’elles sont pertinentes et suffisamment représentatives au regard de la finalité du système. Une donnée d’entrée pauvre, inexacte, biaisée ou hors contexte peut dégrader profondément la fiabilité d’un système d’IA.

20.4. Surveiller le fonctionnement du système

Le déployeur doit surveiller l’usage réel du système, tenir compte des incidents, signaler les dysfonctionnements significatifs selon le cadre applicable et conserver certains journaux lorsque ceux-ci sont sous son contrôle. Il ne suffit pas d’activer l’outil puis de l’oublier.

20.5. Articulation avec le RGPD

Lorsque le système traite des données personnelles, l’entreprise doit articuler ses obligations AI Act avec celles du RGPD. Le règlement IA ne neutralise ni la base légale, ni l’information des personnes, ni la sécurité, ni l’AIPD, ni la gestion des droits.

21. Modèles d’IA à usage général : quand une entreprise est davantage qu’utilisatrice

21.1. Cas des entreprises qui développent, adaptent ou commercialisent

Une entreprise qui ne se contente pas d’utiliser des outils du marché mais développe, entraîne, ajuste, intègre profondément ou commercialise des modèles ou systèmes d’IA peut relever d’obligations supplémentaires, notamment au titre des règles concernant les fournisseurs ou les modèles d’IA à usage général.

21.2. Pourquoi ce point compte

Le dirigeant doit éviter l’angle mort suivant : “nous ne faisons que personnaliser une solution”. Selon le degré de maîtrise technique, de mise sur le marché, de reconditionnement, d’intégration et de présentation au client, l’entreprise peut sortir du simple rôle d’utilisateur.

22. Sanctions : ce qu’il faut comprendre sans dramatiser ni minimiser

22.1. RGPD

Le RGPD prévoit des plafonds d’amendes administratives élevés, pouvant atteindre, selon les manquements, jusqu’à 10 millions d’euros ou 2 % du chiffre d’affaires annuel mondial total, ou jusqu’à 20 millions d’euros ou 4 % du chiffre d’affaires annuel mondial total, le montant le plus élevé étant retenu selon les cas. Mais la sanction ne se résume pas à son plafond : mise en demeure, injonction, limitation du traitement, contrôle renforcé, publicité de la décision et contentieux annexes peuvent être au moins aussi pénalisants.

22.2. AI Act

L’AI Act prévoit lui aussi des sanctions administratives potentiellement très élevées, avec plusieurs niveaux selon la nature du manquement. Les plafonds les plus élevés visent notamment certaines violations des pratiques interdites. Pour les PME et start-up, le règlement prévoit une logique de proportionnalité, mais cela ne doit pas être compris comme une absence de risque.

22.3. Le vrai critère de pilotage

Un dirigeant ne doit pas piloter uniquement “par la peur de l’amende”. Le bon critère est la maîtrise du risque juridique, opérationnel, humain, réputationnel et commercial. Une petite non-conformité répétée, systémique ou portant sur des données ou usages sensibles peut coûter beaucoup plus qu’elle n’en a l’air.

23. Les erreurs les plus fréquentes en entreprise

23.1. Penser qu’un test n’est pas un traitement

Un essai, une démonstration ou un proof of concept avec de vraies données peut déjà constituer un traitement et donc exiger un cadre juridique adapté.

23.2. Penser qu’un outil populaire est nécessairement conforme

La réputation d’un fournisseur ne remplace ni l’analyse contractuelle, ni la vérification des usages autorisés, ni l’évaluation des flux, ni le contrôle des paramètres.

23.3. Copier des documents complets dans une IA sans tri préalable

C’est l’une des erreurs les plus fréquentes. Elle peut contrevenir à la minimisation, exposer des données sensibles ou confidentielles et compliquer ensuite la gestion des droits ou des incidents.

23.4. Penser que la DSI ou le prestataire “gère le juridique”

La technique ne remplace pas la gouvernance. La conformité repose sur une articulation entre direction, métiers, sécurité, RH, juridique, conformité et prestataires.

23.5. Oublier les usages métier diffus

Le risque ne vient pas seulement des grands projets. Il vient aussi des usages quotidiens : assistants bureautiques, résumés de réunions, aide à la rédaction, support client, tri des CV, tableaux de bord, outils de scoring, automatisation de réponses ou enrichissement de données.

24. Ce qu’un dirigeant devrait faire dans les 30 prochains jours

24.1. Recenser les usages réels d’IA

Identifier les outils officiellement déployés, mais aussi les usages spontanés des équipes. Il faut savoir qui utilise quoi, pour quoi faire, avec quelles données et avec quels effets.

24.2. Classer les cas d’usage par niveau de sensibilité

Créer une classification simple : faible risque, risque modéré, risque élevé, usage interdit ou à soumettre à validation préalable. Les usages RH, santé, sécurité, notation, biométrie, surveillance, décision individuelle ou données sensibles doivent remonter immédiatement.

24.3. Vérifier les bases légales et l’information

Contrôler que les traitements reposent sur une base légale cohérente et que les personnes concernées sont correctement informées.

24.4. Revoir les fournisseurs

Contrats, rôles, mesures de sécurité, sous-traitants ultérieurs, localisation des traitements, journalisation, conservation, options de configuration, conditions d’usage des données transmises, procédure d’incident.

24.5. Fixer une politique interne d’usage

Définir ce qui est autorisé, interdit, soumis à validation ou réservé à certains environnements. Préciser les types de données à ne jamais transmettre sans accord préalable.

24.6. Préparer le traitement des demandes de droits

Identifier qui reçoit la demande, qui qualifie, qui répond, où se trouvent les données et comment agir chez les prestataires.

24.7. Préparer l’incident

Définir le point d’alerte, la chaîne d’escalade, les interlocuteurs, la collecte de preuves et le schéma de décision pour une éventuelle notification.

24.8. Former de manière proportionnée

Mettre en place un socle commun de sensibilisation et des modules ciblés pour les populations les plus exposées.

25. Ce qu’il ne faut pas promettre dans une communication dirigeant

25.1. Éviter les affirmations trop absolues

Éviter des formules du type “toute IA doit…”, “tout contenu généré doit être étiqueté”, “le dirigeant est toujours personnellement responsable”, “un outil d’essai est interdit”, “toute décision automatisée est illégale”. Ces raccourcis sont souvent imprécis et fragilisent la crédibilité du document.

25.2. Préférer des formulations prudentes

Les formulations robustes sont celles qui précisent : “selon les cas”, “peut relever de”, “doit être vérifié”, “lorsque le système entre dans telle catégorie”, “dans les conditions prévues par le règlement”, “si des données personnelles sont traitées”, “si le risque pour les droits et libertés est élevé”, “lorsqu’une décision concerne des personnes physiques”.

26. Conclusion stratégique

26.1. Le vrai enjeu

Pour un dirigeant, la question n’est pas de savoir s’il faut renoncer à l’IA. La vraie question est de savoir comment l’utiliser de manière utile, proportionnée, documentée, sécurisée et juridiquement maîtrisée.

26.2. La bonne approche

La bonne approche n’est ni le blocage systématique, ni l’adoption enthousiaste sans garde-fous. C’est une gouvernance progressive : identifier, qualifier, décider, encadrer, former, contrôler et corriger.

26.3. La règle de pilotage à retenir

Plus un usage d’IA traite des données personnelles, influence des décisions concernant des personnes, touche aux RH, à la santé, à la sécurité, à l’accès à un service, à l’évaluation, au profilage ou à la surveillance, plus le niveau d’exigence doit augmenter.

En résumé, le RGPD impose de maîtriser les données. L’AI Act impose de maîtriser certains systèmes d’IA et leurs usages. Pour une entreprise, ces deux textes convergent vers une même exigence : ne pas déployer des outils puissants sans gouvernance, sans preuve et sans discernement.

Étude de cas : fourniture d'un courrier contenant des informations nominatives et des données d’entreprise potentiellement confidentielles à une IA en ligne

Dans le but d'automatiser la réponse à un courrier, une entreprise fournit à une IA en ligne un courrier qui contient les informations nominatives d’un dirigeant d’entreprise (rédacteur du courrier) et des données d’entreprise potentiellement confidentielles ou commercialement sensibles sur sa société (CA, nombre de salariés, numéro SIRET).

1. Qualification du cas

1.1. Ce qui relève du RGPD

Dans ce cas, l’entreprise transmet à une IA en ligne :

• un courrier ;

• comportant les informations nominatives d’un dirigeant ;

• ainsi que des informations sur la société : CA, nombre de salariés, numéro SIRET.

Le point décisif est le suivant : le nom du dirigeant est une donnée à caractère personnel dès lors qu’il identifie une personne physique. Plus largement, des coordonnées professionnelles nominatives ou un courrier signé par une personne physique entrent aussi dans le champ du RGPD. Le RGPD définit les données personnelles comme toute information se rapportant à une personne physique identifiée ou identifiable, et le traitement comme toute opération effectuée sur ces données.

Il faut toutefois corriger un point de vocabulaire : CA, nombre de salariés et SIRET ne sont pas, en eux-mêmes, des “données sensibles” au sens du RGPD. Les catégories particulières de données visées par l’article 9 concernent notamment la santé, la biométrie d’identification, les opinions politiques, la religion, l’appartenance syndicale ou la vie sexuelle. Des données économiques sur une société peuvent être confidentielles, stratégiques ou commercialement sensibles, mais cela n’en fait pas des données sensibles au sens de l’article 9.

Il faut néanmoins ajouter une nuance importante : ces données d’entreprise peuvent parfois devenir aussi des données personnelles par recoupement, notamment dans le cas d’une entreprise individuelle, d’une structure très petite ou d’un courrier permettant d’identifier directement le dirigeant concerné. La CNIL rappelle d’ailleurs que beaucoup de données dites “professionnelles” restent des données personnelles si elles se rattachent à une personne physique identifiable.

1.2. Ce qui relève de l’AI Act

Le simple fait d’utiliser une IA en ligne de rédaction ou d’aide à la réponse peut faire de l’entreprise un déployeur au sens de l’AI Act, c’est-à-dire un utilisateur professionnel d’un système d’IA. En revanche, dans le cas décrit, on n’est pas automatiquement face à une IA à haut risque ni à une pratique interdite. Un outil de rédaction de réponses à des courriers n’entre pas, par nature, dans les catégories les plus sensibles de l’AI Act, sauf si son usage concret bascule vers un domaine réglementé ou une prise de décision significative sur des personnes.

En synthèse :

• RGPD : clairement applicable ;

• AI Act : à examiner au titre de la gouvernance de l’usage professionnel d’un système d’IA, sans qualification automatique en système à haut risque dans ce cas précis, mais pas nécessairement au régime “haut risque” dans ce cas précis.

---

2. Articles RGPD concernés

2.1. Article 4 RGPD — définitions

Cet article est concerné parce que :

• le nom du dirigeant est une donnée personnelle ;

• la transmission du courrier à l’outil IA constitue un traitement ;

• l’entreprise qui décide d’utiliser cet outil pour cette finalité est en principe responsable de traitement ;

• le fournisseur de l’outil peut être sous-traitant, mais pas automatiquement : cela dépend de son rôle réel et de son autonomie.

2.2. Article 5 RGPD — principes

C’est l’article le plus central ici. Plusieurs principes sont directement en jeu :

Licéité, loyauté, transparence

L’entreprise doit pouvoir expliquer pourquoi elle transmet ce courrier à une IA en ligne, sur quelle base, et dans quel cadre. Une utilisation non documentée ou cachée fragilise fortement la conformité.

Limitation des finalités

Le courrier ne peut pas être injecté dans l’outil pour n’importe quel usage. Il faut une finalité déterminée, explicite et légitime, par exemple : “assistance à la rédaction d’une réponse administrative ou commerciale”.

Minimisation des données

C’est probablement le point le plus sensible du cas. Si le nom du dirigeant, le CA, le nombre de salariés ou le SIRET ne sont pas nécessaires pour que l’outil propose une rédaction, leur transmission intégrale peut être excessive. La CNIL insiste sur la minimisation et recommande l’anonymisation ou la pseudonymisation quand c’est possible.

Intégrité et confidentialité

Transmettre un courrier nominatif à une IA en ligne soulève une question de sécurité : qui reçoit les données, où sont-elles traitées, combien de temps sont-elles conservées, sont-elles réutilisées, journalisées, accessibles à d’autres sous-traitants ? L’article 5 et l’article 32 se rejoignent ici.

2.3. Article 6 RGPD — base légale

Le traitement doit reposer sur une base légale. Les deux bases les plus plausibles ici sont :

• l’intérêt légitime de l’entreprise à accélérer ou fiabiliser la rédaction de ses réponses ;

• parfois l’exécution d’un contrat si la rédaction de cette réponse est objectivement nécessaire à l’exécution d’une relation contractuelle.

Mais il faut être précis : le fait qu’un outil soit pratique ou performant ne suffit pas. Il faut une base juridique réelle, documentée, et cohérente avec l’usage. La CNIL rappelle que seules les bases légales prévues par le RGPD permettent le traitement.

Dans beaucoup de cas, l’intérêt légitime sera la base la plus réaliste, mais seulement après une mise en balance entre l’intérêt de l’entreprise et les droits de la personne concernée.

2.4. Articles 13 et 14 RGPD — information des personnes

Si les données du dirigeant sont utilisées de cette manière, il faut vérifier si la personne concernée a été correctement informée de cette utilisation, directement ou via une politique d’information applicable. Une information trop générale ou silencieuse sur l’usage d’outils d’IA ou de prestataires tiers peut être insuffisante. La CNIL insiste sur le fait que l’information doit refléter les usages réels.

2.5. Article 28 RGPD — sous-traitant

Si le fournisseur de l’IA agit pour le compte de l’entreprise et traite les données dans ce cadre, il faut un encadrement contractuel conforme au RGPD. Cela implique de vérifier :

• l’objet et la durée du traitement ;

• les catégories de données ;

• les mesures de sécurité ;

• les sous-traitants ultérieurs ;

• l’assistance pour les droits des personnes ;

• la suppression ou restitution des données.

Beaucoup d’usages d’outils IA “en ligne” échouent précisément ici : absence de qualification claire du fournisseur, clauses trop vagues, paramétrage par défaut non maîtrisé.

2.6. Article 32 RGPD — sécurité

Si le courrier est envoyé à une IA en ligne sans contrôle préalable du fournisseur, sans politique interne, sans restriction des données transmissibles, sans revue des accès et de la conservation, l’entreprise s’expose à un problème de sécurité juridique et technique. Le RGPD impose des mesures adaptées au risque.

2.7. Articles 33 et 34 RGPD — violation de données

Ces articles ne sont pas automatiquement violés par le seul fait d’utiliser l’outil. En revanche, ils deviennent pertinents si :

• les données sont exposées à tort ;

• réutilisées de manière non autorisée ;

• accessibles à un tiers ;

• envoyées à un mauvais environnement ;

• ou compromises chez le fournisseur.

La CNIL rappelle qu’une violation de données est tout incident compromettant confidentialité, intégrité ou disponibilité. Si risque pour les droits et libertés, notification à la CNIL ; si risque élevé, information des personnes.

2.8. Article 35 RGPD — AIPD / DPIA

Une AIPD n’est pas automatiquement obligatoire dans le cas décrit. Mais elle peut le devenir si l’usage s’inscrit dans un dispositif plus large comportant :

• traitement à grande échelle ;

• croisement de sources ;

• profilage ;

• suivi systématique ;

• décisions ayant des effets significatifs ;

• données sensibles au sens de l’article 9 ;

• ou usage d’une technologie nouvelle avec risque élevé.

Dans ce cas isolé, pour un simple outil d’aide à la rédaction, il convient plutôt de parler de vérification de risque préalable que d’AIPD automatique.

---

3. Articles AI Act concernés

3.1. Article 3 — définitions

Il sert à qualifier l’entreprise comme déployeur si elle utilise l’outil dans un cadre professionnel.

3.2. Article 4 — IA literacy / maîtrise de l’IA

Cet article est probablement le plus pertinent dans ton cas au titre de l’AI Act. Les fournisseurs et déployeurs doivent prendre des mesures pour assurer un niveau suffisant de maîtrise de l’IA chez leur personnel. Donc, si les salariés collent des courriers nominatifs dans une IA en ligne, l’entreprise doit avoir :

• des consignes ;

• une formation proportionnée ;

• des règles sur les données transmissibles ;

• des validations pour les cas sensibles.

3.3. Article 26 — obligations du déployeur

Cet article concerne surtout les systèmes d’IA à haut risque. Dans le cas décrit, sauf élément supplémentaire, il ne paraît pas approprié de qualifier l’outil de rédaction de réponses de système à haut risque. Donc l’article 26 n’est pas nécessairement applicable ici. Il ne faut pas le surétendre.

3.4. Article 50 — transparence

A priori, pas le cœur du sujet ici. Un outil interne ou B2B de rédaction assistée n’entre pas automatiquement dans l’obligation de signaler un contenu généré par IA dans tous les cas. Il faut éviter ce raccourci. L’obligation dépend de cas précis prévus par le règlement.

---

4. Infractions éventuelles

4.1. Ce n’est pas automatiquement illégal

Le simple fait de transmettre un courrier nominatif à une IA en ligne n’est pas automatiquement une infraction. Cela dépend du cadre :

• base légale ;

• information ;

• minimisation ;

• sécurité ;

• contrat fournisseur ;

• transferts éventuels ;

• gouvernance interne.

4.2. Les infractions les plus plausibles dans ce scénario

A. Absence de base légale correctement identifiée

Si l’entreprise n’a jamais qualifié juridiquement cet usage, il y a un risque au regard de l’article 6.

B. Violation du principe de minimisation

Si l’outil pouvait travailler avec un texte anonymisé ou partiellement masqué, mais que l’entreprise transmet quand même le nom du dirigeant et les données économiques intégrales, il peut y avoir manquement à l’article 5.

C. Défaut d’information

Si la personne concernée n’a jamais été informée que ses données peuvent être traitées via ce type d’outil, les articles 13/14 peuvent être en cause.

D. Défaut d’encadrement du fournisseur

Si l’entreprise utilise une IA en ligne sans DPA, sans analyse des clauses, sans qualification des rôles, sans revue des flux ou des sous-traitants, l’article 28 est potentiellement en cause.

E. Défaut de sécurité

Si les données sont envoyées dans un environnement non validé, sans restriction, sans journalisation, sans gouvernance, l’article 32 peut être invoqué.

F. Violation de données si incident

Si le fournisseur réutilise, expose, divulgue ou compromet les données, les articles 33/34 peuvent s’ajouter.

---

5. Ce qu’il faut faire pour rendre cela légal

5.1. Définir précisément la finalité

La finalité doit être écrite et limitée, par exemple : “assistance à la rédaction de réponses à des courriers entrants”. Pas “amélioration générale”, pas « cela pourra être examiné plus tard ».

5.2. Choisir et documenter la base légale

Dans la plupart des cas :

• intérêt légitime de l’entreprise, avec mise en balance ;

• éventuellement contrat, si strictement nécessaire à l’exécution d’une relation contractuelle.

Il faut le documenter, pas seulement l’affirmer.

5.3. Appliquer la minimisation avant envoi

C’est ici que se joue souvent la conformité réelle.

En pratique :

• masquer le nom du dirigeant si inutile ;

• remplacer les éléments identifiants par des variables ;

• retirer le SIRET si non nécessaire ;

• remplacer le CA et le nombre de salariés par des indications génériques si cela suffit ;

• transmettre uniquement les extraits utiles au raisonnement rédactionnel.

La CNIL recommande le recours à l’anonymisation ou à la pseudonymisation quand cela est possible.

5.4. Vérifier le fournisseur IA

Il faut examiner :

• son rôle exact ;

• les clauses contractuelles ;

• la réutilisation éventuelle des contenus ;

• la conservation ;

• les sous-traitants ultérieurs ;

• les lieux de traitement ;

• les garanties de sécurité ;

• les mécanismes de transfert hors UE si applicables.

Sans cela, la légalité est très fragile.

5.5. Encadrer contractuellement le traitement

Si le fournisseur agit comme sous-traitant, un encadrement conforme à l’article 28 est requis.

5.6. Mettre à jour l’information fournie aux personnes

Les personnes concernées doivent pouvoir comprendre que certaines données peuvent être traitées via des outils tiers d’assistance rédactionnelle, avec indication des finalités et des droits pertinents. L’information doit refléter les usages réels.

5.7. Définir une politique interne d’usage de l’IA

Il faut au minimum :

• lister les outils autorisés ;

• interdire les outils non validés ;

• fixer les catégories de données qu’on peut ou non transmettre ;

• imposer l’anonymisation/pseudonymisation lorsque possible ;

• prévoir une validation pour les courriers sensibles ;

• tracer les usages à risque.

C’est aussi une réponse concrète à l’exigence de maîtrise de l’IA de l’AI Act.

5.8. Former les utilisateurs

Les salariés doivent savoir :

• ce qu’est une donnée personnelle ;

• ce qu’ils ne doivent pas coller dans un outil IA ;

• comment anonymiser ;

• quand demander validation ;

• que “test”, “copier-coller” ou “outil gratuit” ne neutralisent pas le RGPD.

5.9. Vérifier si un transfert international existe

Si le fournisseur traite hors UE ou via des sous-traitants internationaux, il faut vérifier le mécanisme juridique applicable et le niveau de protection.

5.10. Prévoir la gestion d’incident

Si des données ont été exposées, il faut pouvoir qualifier rapidement s’il y a violation de données et, le cas échéant, notifier dans les délais.

---

6. Verdict sur ce cas

Situation brute

Risque juridique réel si l’entreprise a simplement copié le courrier dans une IA en ligne sans analyse préalable.

Articles les plus directement concernés

Les plus importants sont :

• RGPD art. 4 : données personnelles et traitement ;

• RGPD art. 5 : licéité, finalité, minimisation, confidentialité ;

• RGPD art. 6 : base légale ;

• RGPD art. 13/14 : information ;

• RGPD art. 28 : sous-traitant/fournisseur ;

• RGPD art. 32 : sécurité ;

• RGPD art. 33/34 : seulement si incident ;

• RGPD art. 35 : selon le niveau de risque ;

• AI Act art. 3 : rôle de déployeur ;

• AI Act art. 4 : maîtrise de l’IA / formation / consignes.

Ce qui est probablement faux dans la pratique si rien n’a été préparé

• absence de base légale documentée ;

• absence de minimisation ;

• absence d’encadrement contractuel suffisant ;

• absence d’information claire ;

• absence de politique interne ;

• absence de revue de sécurité.

Ce qui rendrait l’usage défendable

• finalité définie ;

• intérêt légitime documenté ;

• anonymisation/pseudonymisation préalable ;

• outil validé contractuellement et techniquement ;

• information à jour ;

• consignes internes et formation ;

• contrôle des transferts et de la conservation.

Le point clé est le suivant : l’illégalité ne vient pas du mot “IA” en lui-même ; elle vient du fait de transmettre des données identifiantes à un service en ligne sans base légale solide, sans minimisation, sans encadrement du fournisseur et sans gouvernance.

Conséquences si aucune mesure n'est prise pour encadrer la fourniture du courrier à l'IA

Quelles sont les conséquences si le dirigeant qui utilise l’outil d’IA et le prestataire qui l’a fourni n’ont effectué aucune démarche, aucune étude, n’ont prévu aucune justification, et si le rédacteur du courrier traité, pour lequel une réponse est générée par l’IA, n’a pas été prévenu de l’usage qui va être fait de ses données ?

1. Conséquence immédiate : le traitement est juridiquement très fragilisé, et probablement illicite

Si :

• aucune analyse n’a été faite,

• aucune base légale n’a été identifiée,

• aucune justification n’a été documentée,

• aucune information n’a été donnée à la personne concernée,

• aucun encadrement du prestataire n’a été prévu,

alors l’entreprise ne peut pas démontrer qu’elle respecte les principes fondamentaux du RGPD, notamment la licéité, la loyauté, la transparence, la minimisation et l’accountability. Or le RGPD ne demande pas seulement d’être conforme : il impose aussi de pouvoir le prouver.

Autrement dit, en cas de contrôle, la ligne de défense “nous n’avons pas pensé à le formaliser” est juridiquement très faible.

2. Les manquements RGPD les plus probables sont déjà présents

Absence de base légale démontrable

Le traitement de données personnelles exige une base légale. Si aucune n’a été identifiée ni documentée, l’entreprise s’expose à un constat de traitement illicite au regard de l’article 6.

Défaut d’information de la personne concernée

Tu précises que le rédacteur du courrier n’a pas été prévenu de l’usage de ses données dans une IA en ligne. Cela expose directement l’entreprise à un manquement aux obligations d’information prévues par les articles 13 et 14. La CNIL rappelle que l’information doit être compréhensible, accessible et refléter les usages réels.

Défaut d’accountability

Le RGPD impose d’être en mesure de démontrer la conformité. L’absence totale d’étude, de justification, de procédure, de consigne ou de traçabilité est en elle-même un problème majeur.

Défaut d’encadrement du prestataire

Si le fournisseur de l’outil traite les données pour le compte de l’entreprise sans contrat RGPD adéquat ni répartition claire des rôles, il existe un risque sérieux au regard des règles sur les responsables de traitement et les sous-traitants. La CNIL rappelle que le sous-traitant doit être encadré, et que le responsable de traitement doit vérifier ses garanties.

Défaut de sécurité et d’évaluation du risque

Le fait d’envoyer des données nominatives à une IA en ligne sans étude préalable ni validation du cadre technique et contractuel affaiblit la conformité sur la sécurité du traitement. Le RGPD exige des mesures appropriées au risque.

3. Ce que cela peut entraîner concrètement

a) En cas de plainte ou de contrôle CNIL

La CNIL peut constater plusieurs manquements et ordonner, selon les cas :

• une mise en conformité sous délai ;

• une mise en demeure ;

• une limitation ou suspension du traitement ;

• l’interdiction d’utiliser l’outil pour ce cas d’usage ;

• la suppression des données transmises si cela est nécessaire ;

• une sanction administrative. Le RGPD prévoit des amendes pouvant aller, selon les manquements, jusqu’à 10 millions d’euros ou 2 % du CA mondial, ou jusqu’à 20 millions d’euros ou 4 % du CA mondial.

Dans une PME, la sanction ne sera pas mécaniquement au plafond maximal. Mais le vrai danger est souvent l’addition :

• injonction,

• urgence de remédiation,

• charge de preuve,

• atteinte réputationnelle,

• désorganisation,

• éventuelle publicité de la décision.

b) En cas de demande de la personne concernée

Le rédacteur du courrier, une fois informé ou s’il découvre l’usage, peut exercer ses droits :

• demander quelles données ont été utilisées ;

• demander la finalité ;

• demander les destinataires ;

• demander l’effacement si les conditions sont réunies ;

• contester la licéité du traitement ;

• introduire une réclamation auprès de la CNIL. Le RGPD prévoit explicitement ces droits et impose une réponse dans les délais.

c) En cas d’incident technique ou de fuite

Si, en plus, les données sont réutilisées, exposées, compromises ou transférées à tort, on bascule dans le régime des violations de données, avec :

• possible notification à la CNIL ;

• possible information des personnes ;

• aggravation du dossier, car l’entreprise n’avait déjà mis en place aucune précaution préalable.

4. La situation du prestataire qui “n’a rien prévu” n’est pas neutre

Il faut distinguer deux cas.

Si le prestataire agit comme sous-traitant

Alors lui aussi a des obligations propres. Il ne peut pas se contenter de traiter des données sans cadre suffisant. Les règles du RGPD sur les sous-traitants imposent un encadrement contractuel, des garanties et des obligations de sécurité.

Si le prestataire agit en réalité avec une autonomie forte

Il pourrait ne pas être un simple sous-traitant. Dans ce cas, la qualification peut devenir plus complexe, avec un risque de responsabilité propre, voire de responsabilité partagée selon l’organisation réelle du traitement. Là encore, l’absence de clarification des rôles devient elle-même un problème.

Le prestataire ne peut donc pas sérieusement opposer : “c’était au client de gérer”. Si son service a été conçu et fourni sans cadre contractuel clair, sans garanties, sans documentation utile, il s’expose lui aussi.

5. Sur l’AI Act : les conséquences sont plus limitées ici, mais réelles

Dans le cas décrit, on n’est pas automatiquement dans un système d’IA à haut risque. Donc il ne faut pas surjouer l’AI Act.

En revanche, il y a un point déjà pertinent : l’obligation de maîtrise de l’IA. L’AI Act impose aux fournisseurs et déployeurs de prendre des mesures pour assurer un niveau suffisant de compréhension de l’IA chez les personnes concernées. Si ni le dirigeant utilisateur ni le prestataire n’ont prévu de consignes, de formation, de garde-fous ou de règles d’usage, il existe un risque de non-conformité sur ce terrain.

Donc, dans ce cas précis :

• le RGPD est le socle principal des manquements ;

• l’AI Act renforce l’idée qu’un déploiement professionnel sans gouvernance, sans consignes et sans maîtrise est juridiquement faible.

6. Le point le plus important : ce n’est pas seulement “irrégulier”, c’est difficilement défendable

Le cumul des faits que est décrit produit un effet très défavorable :

• aucune base légale identifiée ;

• aucune information de la personne ;

• aucune minimisation démontrée ;

• aucun contrat ou contrôle du fournisseur ;

• aucune étude de risque ;

• aucune procédure ;

• aucune justification.

Dans cette configuration, l’entreprise est très mal placée pour soutenir que le traitement était licite, loyal, transparent, proportionné et sécurisé. Et le prestataire est très mal placé pour soutenir qu’il a fourni un cadre sérieux d’usage professionnel.

7. En pratique, quelles conséquences probables faut-il retenir

Le tableau réel peut être résumé ainsi :

Conséquence juridique immédiate Le traitement est très probablement non conforme au RGPD.

Conséquence administrative possible Mise en demeure, injonction de cesser, suspension de l’usage, exigence de mise en conformité, éventuellement sanction financière.

Conséquence probatoire L’entreprise n’a aucune preuve de conformité à produire.

Conséquence opérationnelle Obligation possible d’arrêter immédiatement cet usage, de revoir les outils, les contrats, les process et les mentions d’information.

Conséquence contentieuse Risque de réclamation de la personne concernée, plainte CNIL, voire demande d’indemnisation si un préjudice est invoqué.

Conséquence réputationnelle Très mauvaise si l’usage d’une IA en ligne apparaît comme opaque ou non maîtrisé.

8. Ce qu’il faudrait faire immédiatement

Dans une telle situation, les mesures urgentes seraient :

1. Suspendre l’usage pour ce cas d’usage, au moins temporairement.

2. Qualifier les rôles : entreprise, prestataire, éventuels sous-traitants ultérieurs.

3. Déterminer la base légale et documenter la finalité.

4. Vérifier si les données déjà transmises peuvent être supprimées ou isolées.

5. Mettre à jour l’information des personnes.

6. Évaluer le fournisseur : contrat, sécurité, conservation, réutilisation, transferts.

7. Mettre en place une politique interne d’usage de l’IA.

8. Former les utilisateurs.

9. Vérifier s’il y a eu violation de données ou risque de fuite.

Le point central est simple : dans la situation que est décrit, on ne peut plus parler d’un usage “informel mais défendable”. On est dans un usage professionnel non gouverné, et donc dans une exposition juridique sérieuse.

Quels manquements dans ce cas

1. Manquements certains ou quasi certains

Article 5 RGPD — principes de licéité, loyauté, transparence, minimisation, intégrité/confidentialité, accountability

Qualification : manquement très probable, avec plusieurs volets presque certains.

Pourquoi :

• aucune justification préalable n’a été faite ;

• aucune gouvernance n’a été prévue ;

• la personne concernée n’a pas été informée ;

• aucune démonstration de minimisation n’existe ;

• aucune preuve de conformité n’est disponible.

Le point le plus solide ici est l’accountability : le RGPD impose non seulement de respecter les règles, mais aussi de pouvoir le démontrer. En l’absence totale d’étude, de trace, de procédure ou de politique, ce point est pratiquement perdu d’avance en cas de contrôle. La CNIL insiste précisément sur la nécessité d’informer les personnes, d’organiser les droits et de documenter les traitements dans les environnements IA.

Article 6 RGPD — base légale

Qualification : manquement très probable.

Pourquoi :

• aucun fondement juridique n’a été identifié ;

• rien ne montre que l’entreprise a choisi entre intérêt légitime, contrat ou autre base ;

• rien ne montre qu’une mise en balance a été faite.

Or un traitement de données personnelles ne peut pas être “rattrapé” après coup par une base légale improvisée. Si elle n’a pas été pensée ni documentée, la licéité est très fragilisée.

Articles 13 et 14 RGPD — information de la personne concernée

Qualification : manquement certain ou très proche du certain, selon l’origine exacte des données.

Pourquoi :

• il est précisé que le rédacteur du courrier n’a pas été averti de cet usage ;

• si ses données sont collectées directement, l’article 13 est en jeu ;

• si elles ont été obtenues autrement, l’article 14 peut entrer en jeu.

Dans les deux cas, l’absence d’information sur un usage réel via une IA en ligne est un point de non-conformité très fort. La CNIL insiste sur le fait que l’information doit refléter les usages réels et ne peut pas rester générique ou silencieuse sur des traitements effectivement mis en œuvre.

Article 28 RGPD — encadrement du sous-traitant

Qualification : manquement très probable si le fournisseur agit pour le compte de l’entreprise.

Pourquoi :

• aucun cadre contractuel n’a été prévu ;

• aucune vérification n’a été faite sur le prestataire ;

• aucune qualification des rôles n’a été établie.

Si le fournisseur d’IA traite les données pour le compte de l’entreprise, un encadrement conforme est requis. En l’absence de contrat et de garanties vérifiées, ce point est très exposé.

Article 32 RGPD — sécurité du traitement

Qualification : manquement probable à très probable.

Pourquoi :

• aucune étude de risque ;

• aucune mesure adaptée identifiée ;

• aucune preuve d’évaluation du service ;

• aucune maîtrise démontrée des flux, de la conservation, des accès ou de la réutilisation.

Le RGPD exige des mesures techniques et organisationnelles appropriées aux risques. Sans aucune démarche, l’entreprise et le prestataire sont mal placés pour soutenir que cette exigence est satisfaite.

2. Manquements probables mais dépendant encore de faits complémentaires

Article 4 RGPD — qualification des données et du traitement

Qualification : acquis sur le principe, pas une infraction en soi.

Pourquoi :

• il y a bien des données personnelles si le courrier contient le nom du dirigeant ou d’autres éléments identifiants ;

• la transmission à l’IA constitue un traitement.

Ce n’est pas un “manquement”, mais c’est la base juridique qui rend le RGPD pleinement applicable.

Article 35 RGPD — AIPD

Qualification : manquement conditionnel, pas automatique.

Pourquoi :

• une AIPD est exigée seulement si le traitement présente un risque élevé pour les droits et libertés ;

• dans ce scénario, pour un simple outil d’aide à la rédaction, ce n’est pas automatique ;

• cela peut le devenir si l’usage s’inscrit dans un système plus large, répétitif, à grande échelle, avec croisement de données, analyse de personnes ou effets significatifs.

En synthèse : on ne peut pas affirmer d’emblée que l’absence d’AIPD est une infraction certaine, mais on ne peut pas l’écarter sans analyse. Et précisément, aucune analyse n’a été faite.

Articles 33 et 34 RGPD — violation de données

Qualification : pas de manquement automatique à ce stade.

Pourquoi :

• ces articles s’appliquent si une violation de données s’est produite ;

• le simple usage non cadré d’une IA ne suffit pas à lui seul à caractériser une violation ;

• en revanche, si les données sont réutilisées, exposées, transférées à tort, rendues accessibles ou compromises, alors ces articles entrent immédiatement en jeu.

Donc ici, le manquement n’est pas encore certain, mais le risque d’aggravation est élevé si un incident survient.

3. AI Act : où se situe le problème dans ce cas

Article 3 AI Act — qualification comme déployeur

Qualification : pas une infraction, mais une qualification utile.

L’entreprise qui utilise l’outil en contexte professionnel peut relever du rôle de déployeur. Cela permet de rattacher certaines obligations à son usage de l’outil.

Article 4 AI Act — maîtrise de l’IA / IA literacy

Qualification : manquement probable.

Pourquoi :

• ni le dirigeant ni le prestataire n’ont prévu de règles d’usage ;

• aucune consigne, aucun garde-fou, aucune formation, aucune doctrine d’escalade ;

• aucune compréhension opérationnelle de ce qui peut ou non être injecté dans l’outil n’a été organisée.

Dans ce cas, l’entreprise et possiblement le fournisseur sont exposés sur l’exigence de maîtrise de l’IA. Ce n’est pas forcément le manquement le plus lourd du dossier, mais il renforce fortement l’idée d’un déploiement professionnel non gouverné.

Dispositions AI Act sur les systèmes à haut risque

Qualification : non caractérisé à ce stade.

Un outil de rédaction de réponses à des courriers n’est pas, par nature, un système d’IA à haut risque. Sans autre élément, il ne faut pas surqualifier ce point. Donc, ici, je ne retiendrais pas d’emblée un manquement aux obligations propres aux systèmes à haut risque.

4. Conséquences juridiques associées

Pour l’entreprise utilisatrice

Les conséquences les plus probables sont :

• constat de non-conformité RGPD ;

• injonction de mise en conformité ;

• possible suspension ou interdiction de ce cas d’usage ;

• exigence de revoir l’information, les contrats, la sécurité et les procédures ;

• éventuelle sanction administrative selon la gravité et la persistance des manquements. Le RGPD prévoit des plafonds pouvant aller jusqu’à 10 M€ ou 2 % du CA mondial, ou 20 M€ ou 4 % du CA mondial selon les manquements, même si en pratique l’autorité raisonne selon les faits, la gravité et la proportionnalité.

Pour le prestataire

S’il agit comme sous-traitant sans cadre contractuel ni garanties adaptées, il est lui aussi exposé. S’il a une autonomie plus forte dans le traitement, la qualification peut devenir plus lourde encore. En tout cas, il ne sort pas proprement du dossier en disant simplement : “le client devait gérer”.

Pour la personne concernée

Elle peut :

• demander l’accès aux données utilisées ;

• contester la licéité du traitement ;

• demander effacement ou limitation selon les cas ;

• saisir la CNIL ;

• et, si elle invoque un préjudice, rechercher réparation.

5. Synthèse par niveau

Manquements certains ou très probables

• absence de base légale démontrable ;

• défaut d’information de la personne ;

• défaut d’accountability ;

• défaut probable d’encadrement du fournisseur ;

• défaut probable de sécurité adaptée.

Manquements possibles mais à confirmer

• absence fautive d’AIPD ;

• violation de données notifiable, mais seulement s’il y a eu incident ou exposition effective.

AI Act

• qualification de déployeur : oui ;

• manquement probable à l’obligation de maîtrise de l’IA ;

• pas de qualification automatique en système à haut risque.

6. Verdict net

S’il fallait qualifier le dossier en une phrase :

RGPD : dossier déjà très probablement non conforme. AI Act : exposition complémentaire, surtout sur la gouvernance et la maîtrise de l’outil, mais pas forcément sur le régime haut risque.

Si l'entreprise a utilisé un outil d'IA acheté à un prestataire, quelle est la responsabilité de ce prestataire ?

1. Le prestataire n’a pas automatiquement la même responsabilité que l’entreprise cliente

Si l’entreprise cliente utilise l’outil pour traiter des données personnelles, elle est très souvent responsable de traitement au sens du RGPD, car c’est elle qui décide de la finalité : par exemple, “faire rédiger une réponse à un courrier”. Le simple fait d’avoir acheté l’outil ne transfère pas cette responsabilité au vendeur. La CNIL rappelle qu’il faut d’abord qualifier correctement les rôles : responsable de traitement, sous-traitant, ou parfois responsables conjoints.

En revanche, le prestataire peut être :

• un simple éditeur/vendeur ;

• un sous-traitant ;

• un responsable conjoint dans certains montages ;

• ou, au titre de l’AI Act, un fournisseur si le système est mis sur le marché sous son nom ou sa marque. L’AI Act définit le “provider / fournisseur” comme la personne qui développe ou fait développer un système d’IA et le met sur le marché ou en service sous son propre nom ou sa propre marque ; le “deployer / déployeur” est l’entité qui utilise le système sous sa propre autorité.

2. Quand le prestataire est vraiment exposé

2.1. S’il agit comme sous-traitant RGPD

S’il traite des données personnelles pour le compte du client, sur instruction de celui-ci, il entre dans le régime du sous-traitant. Dans ce cas, il a ses propres obligations : traiter uniquement sur instruction documentée, garantir la confidentialité, mettre en place des mesures de sécurité, encadrer les sous-traitants ultérieurs, assister le client pour les droits des personnes et la gestion des incidents, supprimer ou restituer les données en fin de prestation, et tenir une documentation adaptée. Le contrat prévu par l’article 28 est central.

Donc, si le prestataire a fourni un outil qui reçoit effectivement les courriers nominatifs, les stocke, les traite, les journalise ou les retransmet, et qu’il n’a prévu ni contrat adéquat, ni garanties, ni sécurité sérieuse, sa responsabilité propre peut être engagée.

2.2. S’il a une vraie autonomie sur les finalités ou moyens essentiels

S’il ne se contente pas d’exécuter les instructions du client, mais décide lui-même d’éléments structurants du traitement — par exemple réutiliser les contenus pour entraînement, analytics, enrichissement produit, profilage, ou organiser les usages de manière autonome — il peut sortir du simple rôle de sous-traitant. Là, le risque devient plus lourd, car il peut être qualifié de responsable de traitement ou de responsable conjoint pour tout ou partie des opérations. La jurisprudence européenne sur l’usage de services tiers va dans ce sens : celui qui provoque et organise une transmission de données vers un tiers ne s’exonère pas facilement.

2.3. S’il est “fournisseur” au sens de l’AI Act

S’il commercialise l’outil sous son nom, il peut être un fournisseur au sens de l’AI Act. Cela ne signifie pas automatiquement qu’il est en faute dans tous les cas, mais cela veut dire qu’il n’est pas juste un revendeur neutre. Sa position dans la chaîne de valeur de l’IA devient juridiquement importante. L’AI Act prévoit d’ailleurs des “responsabilités tout au long de la chaîne de valeur de l’IA”, ce qui empêche une stratégie consistant à dire : “c’est l’utilisateur final qui devait tout gérer”.

3. Dans ce scénario, quel risque concret pour le prestataire ?

Si le prestataire a vendu un outil IA permettant au client d’y injecter des courriers nominatifs, sans :

• qualification claire des rôles ;

• contrat article 28 si nécessaire ;

• information sur les flux de données ;

• garanties de sécurité ;

• documentation sur la conservation ;

• politique sur la réutilisation des prompts et contenus ;

• encadrement des sous-traitants ultérieurs ;

• garde-fous d’usage ;

alors il est sérieusement exposé.

Il ne portera pas forcément toute la responsabilité du traitement initial, parce que l’entreprise cliente reste souvent responsable de la finalité de l’usage. Mais il peut être recherché pour :

• défaut d’encadrement contractuel s’il est sous-traitant ;

• défaut de sécurité ;

• défaut de transparence sur son propre rôle et ses usages ;

• réutilisation non autorisée des données si elle existe ;

• mauvaise qualification juridique de la prestation ;

• manquement à ses obligations propres dans la chaîne AI Act, selon la nature exacte du système.

4. Ce que le prestataire doit faire pour se protéger

Le bon raisonnement n’est pas “comment se défausser”, mais “comment rendre sa position défendable”.

4.1. Qualifier noir sur blanc son rôle

Il doit déterminer et documenter s’il agit comme :

• simple vendeur/licencieur ;

• sous-traitant ;

• responsable conjoint ;

• fournisseur AI Act ;

• ou combinaison de plusieurs rôles selon les opérations. C’est la première protection. Une relation non qualifiée est très dangereuse. La CNIL insiste précisément sur cette étape.

4.2. Mettre en place le bon contrat

S’il est sous-traitant, il lui faut un contrat conforme à l’article 28 RGPD, avec au minimum :

• objet, durée, nature des opérations ;

• catégories de données ;

• catégories de personnes ;

• sécurité ;

• sous-traitants ultérieurs ;

• assistance au client ;

• sort des données en fin de prestation. Sans cela, sa position est faible.

4.3. Définir explicitement ce qu’il fait des données

Il doit indiquer clairement :

• si les données sont seulement traitées pour fournir le service ;

• si elles sont journalisées ;

• si elles sont conservées ;

• si elles servent à l’amélioration produit ;

• si elles alimentent un modèle ;

• si elles sont partagées avec d’autres prestataires ;

• où elles sont hébergées ;

• combien de temps elles restent accessibles. C’est un point de protection juridique majeur, parce que beaucoup de contentieux naissent d’un flou sur les usages réels.

4.4. Mettre en place des mesures techniques de réduction de risque

Par exemple :

• options de non-conservation ;

• désactivation de la réutilisation pour entraînement ;

• cloisonnement par client ;

• journalisation ;

• chiffrement ;

• gestion fine des habilitations ;

• purge ;

• limitation des exports ;

• séparation test/production. Cela sert à la fois le RGPD et la crédibilité commerciale. La CNIL rappelle que le sous-traitant a aussi des obligations propres de sécurité.

4.5. Fournir une doctrine d’usage au client

Le prestataire doit remettre au client une documentation claire :

• types de données à ne pas injecter sans validation ;

• cas d’usage interdits ou sensibles ;

• précautions de minimisation ;

• alertes sur les données sensibles ;

• règles de pseudonymisation ;

• procédure en cas d’incident ;

• limites fonctionnelles de l’outil. Cela ne le protège pas totalement, mais c’est très important pour montrer qu’il n’a pas livré un produit “sans garde-fous”.

4.6. Vérifier sa chaîne de sous-traitance

S’il s’appuie lui-même sur un hébergeur, un fournisseur de modèle, une API tierce ou un autre prestataire, il doit encadrer cette chaîne, surtout en cas de transferts hors UE. Les clauses contractuelles types et les garanties de transfert peuvent devenir décisives.

4.7. Prévoir la gestion d’incident et l’assistance au client

Le prestataire doit pouvoir :

• détecter un incident ;

• alerter rapidement le client ;

• documenter ce qui s’est passé ;

• aider à qualifier une éventuelle violation de données ;

• fournir les éléments nécessaires à la notification si besoin. Sans cela, il s’expose à aggraver très vite sa situation.

4.8. Au titre de l’AI Act, organiser la maîtrise de l’IA

L’AI Act impose des mesures de maîtrise de l’IA. Le prestataire a donc intérêt à documenter :

• les usages prévus ;

• les limites du système ;

• les erreurs connues ;

• les précautions d’usage ;

• les consignes de supervision humaine ;

• le niveau de compétence attendu des utilisateurs professionnels.

5. Ce que le prestataire ne doit surtout pas faire

Il ne doit pas compter sur ces lignes de défense :

• “je ne suis qu’un vendeur” si, en réalité, son service traite les données ;

• “c’est le client qui a collé les données” si lui-même a conçu un service sans encadrement minimal ;

• “les CGU suffisent” si les clauses sont vagues ou incomplètes ;

• “le client devait savoir” s’il n’a fourni ni doctrine d’usage ni contrat adapté.

Ces arguments sont faibles si le prestataire est techniquement et juridiquement dans la chaîne du traitement.

6. Réponse nette

Responsabilité du prestataire :

• limitée s’il est réellement simple vendeur d’un logiciel installé et administré par le client, sans accès aux données ni rôle dans le traitement ;

• réelle et directe s’il traite les données pour le compte du client comme sous-traitant ;

• potentiellement plus lourde s’il décide lui-même d’usages secondaires, de réutilisations, ou s’il commercialise le système sous son nom avec un vrai rôle de fournisseur dans la chaîne IA.

Pour se protéger, il doit :

• qualifier son rôle ;

• contractualiser proprement ;

• documenter ses traitements ;

• sécuriser techniquement le service ;

• informer clairement sur les usages des données ;

• encadrer sa sous-traitance ;

• fournir des garde-fous d’usage au client ;

• organiser la gestion d’incident et la maîtrise de l’IA.

Cas où le prestataire a fait figurer en tête de l'outil, de façon très claire, qu'il était interdit de fournir des données nominatives ou sensibles à une IA et que toute donnée de ce type devait être anonymisée et remplacée par un marqueur [nom], [siret], etc.

Un avertissement clair du type :

“Il est interdit de fournir des données nominatives ou sensibles à l’IA. Toute donnée de ce type doit être anonymisée et remplacée par des placeholders [nom], [siret], etc.”

est un élément de protection utile pour le prestataire, parce qu’il montre :

• qu’il a identifié le risque ;

• qu’il a donné une instruction explicite au client ;

• qu’il a tenté de faire respecter la minimisation et la confidentialité ;

• et qu’il a mis en place au moins un premier niveau de gouvernance d’usage.

Mais juridiquement, cela ne vaut ni contrat, ni qualification des rôles, ni preuve suffisante de sécurité, ni preuve que le service ne traite pas quand même des données personnelles. En RGPD, la qualification dépend des faits réels, pas seulement du texte affiché à l’écran. La CNIL le rappelle : la qualification des acteurs ne dépend pas d’un simple choix contractuel ou déclaratif, mais de ce que chacun décide et exécute réellement.

1. Ce que cet avertissement apporte réellement au prestataire

1.1. Il montre une démarche de prévention

Cet affichage va dans le bon sens parce qu’il matérialise une instruction et une mise en garde. Si le client passe outre et colle quand même des données nominatives, le prestataire pourra soutenir qu’il n’a pas encouragé cet usage et qu’il l’a même explicitement déconseillé. Cela peut peser favorablement dans l’analyse des responsabilités. La CNIL souligne qu’un sous-traitant doit participer à la conformité par des obligations de transparence, de traçabilité et d’assistance.

1.2. Il renforce l’argument selon lequel le client a mal utilisé l’outil

Si le client avait une consigne claire d’anonymiser et ne l’a pas fait, sa propre faute devient plus visible. Cela aide le prestataire à dire :

• “j’avais posé une règle claire” ;

• “l’usage fautif vient du client” ;

• “le service était conçu pour un usage anonymisé ou pseudonymisé”.

Cet argument peut être utile, surtout si le prestataire peut prouver que cette consigne était visible, stable, non ambiguë, et non un simple micro-texte noyé dans l’interface. La logique du RGPD et des guides CNIL sur les sous-traitants va dans le sens d’une documentation explicite des obligations de chacun.

1.3. C’est aussi cohérent avec l’AI Act

Au regard de l’AI Act, ce type d’avertissement aide à démontrer un début de maîtrise de l’IA et de documentation d’usage. L’AI Act impose une logique de compétence et d’information des acteurs qui utilisent ou déploient des systèmes d’IA. Un bandeau clair n’est pas une conformité complète, mais c’est un élément cohérent avec cette exigence.

2. Pourquoi cela ne suffit pas juridiquement

2.1. Parce que l’affichage ne change pas, à lui seul, le rôle réel du prestataire

Si, en pratique, le prestataire :

• héberge les prompts ;

• les enregistre ;

• les journalise ;

• les transmet à un modèle tiers ;

• les conserve ;

• ou les réutilise,

alors il reste dans la chaîne du traitement. Le fait d’avoir écrit “ne mettez pas de données personnelles” ne suffit pas à l’en sortir. La CNIL insiste : on qualifie les rôles au cas par cas, selon les faits, c’est-à-dire qui décide quoi et qui exécute quoi.

2.2. Parce que l’article 28 RGPD ne se remplace pas par un avertissement

Si le prestataire agit comme sous-traitant, il faut un contrat ou un acte juridique conforme à l’article 28. Le guide CNIL pour les sous-traitants rappelle explicitement qu’il faut établir avec le client un contrat précisant les obligations de chaque partie et reprenant les dispositions de l’article 28. Un bandeau d’interface, même très clair, ne remplace pas cela.

2.3. Parce que l’article 32 RGPD impose des mesures techniques et organisationnelles adaptées

Si le prestataire sait que des clients peuvent malgré tout coller des données personnelles, il ne peut pas se contenter d’un avertissement si le risque est prévisible. Le RGPD impose des mesures techniques et organisationnelles appropriées, et la CNIL rappelle aussi une logique de “privacy by default”, c’est-à-dire ne traiter par défaut que les données nécessaires. Un simple message n’est pas forcément suffisant si des mesures techniques de réduction du risque étaient possibles.

Concrètement, si le prestataire pouvait raisonnablement mettre en place :

• un filtre ou détecteur de données nominatives ;

• des alertes bloquantes ;

• un masquage automatique ;

• une purge immédiate ;

• la désactivation de la conservation ;

• ou un cloisonnement strict,

et ne l’a pas fait, son avertissement perd de sa force.

2.4. Parce qu’un avertissement n’efface pas une éventuelle réutilisation des données

Si le prestataire ou ses sous-traitants réutilisent les prompts pour améliorer le service, entraîner un modèle, faire des analyses internes ou alimenter une journalisation étendue, le bandeau ne suffira pas à le protéger. Il faut alors une base juridique, une transparence réelle, une qualification correcte des rôles, et souvent un cadre contractuel beaucoup plus solide.

3. Dans quels cas le prestataire est vraiment mieux protégé

Le prestataire est beaucoup mieux protégé si l’avertissement n’est qu’un élément parmi un ensemble cohérent.

Sa position devient bien plus défendable s’il peut montrer en plus que :

• le contrat précise que le client ne doit transmettre que des données anonymisées ou pseudonymisées ;

• les CGU/DPA décrivent clairement les rôles et les usages interdits ;

• les prompts ne sont pas réutilisés à d’autres fins sans base adéquate ;

• le système dispose de garde-fous techniques ;

• les données sont soit non conservées, soit rapidement purgées ;

• il existe une journalisation de conformité ;

• il peut prouver qu’il a informé le client de manière répétée et non équivoque.

Dans ce cas, l’argument devient solide :

le prestataire a conçu un service pour usage anonymisé, a documenté la règle, a encadré contractuellement le client, a mis des protections raisonnables, et le client a délibérément contrevenu aux consignes.

Là, la responsabilité du client devient beaucoup plus centrale.

4. Dans quels cas le prestataire reste malgré tout exposé

Il reste exposé si l’un des points suivants existe :

4.1. Le message est clair, mais rien d’autre n’existe

Pas de contrat, pas de DPA, pas de politique de conservation, pas de sécurité documentée, pas de qualification des rôles. Dans ce cas, le message ressemble à une précaution utile, mais insuffisante.

4.2. Le service est techniquement conçu pour avaler n’importe quelles données sans frein

Si l’outil invite de fait à copier-coller des courriers complets, sans détection, sans alerte, sans cloisonnement, l’avertissement peut apparaître comme purement formel. Le droit regarde la réalité du service, pas seulement la consigne affichée.

4.3. Le prestataire savait que les clients mettaient quand même des données personnelles

S’il connaissait l’usage réel et n’a rien fait au-delà d’un bandeau, sa position se dégrade. À partir du moment où le risque est connu, l’exigence de mesures adaptées devient plus forte.

4.4. Le prestataire réutilise ou conserve les contenus

Là, le message d’avertissement ne le protège pas sérieusement. Il devient lui-même acteur du traitement, avec les obligations correspondantes.

5. Effet probable sur le partage de responsabilité

Côté entreprise cliente

Si elle voit un avertissement très clair et colle quand même des données nominatives, sa faute devient plus nette. Elle reste très exposée :

• pour défaut de minimisation ;

• pour défaut de base légale correctement mise en œuvre ;

• pour défaut d’information de la personne concernée ;

• et pour usage contraire aux consignes du prestataire. Le fait que le prestataire ait mis en garde ne la protège pas.

Côté prestataire

L’avertissement :

• réduit son exposition ;

• renforce sa défense ;

• mais ne l’annule pas automatiquement.

En pratique, il peut faire baisser le risque de voir toute la faute lui être imputée, mais il ne le met pas hors du champ du RGPD si son service traite réellement les données.

6. Réponse nette

Dans ce cas, on peut formuler la conclusion suivante :

Le prestataire est mieux protégé, parfois nettement mieux protégé, mais pas automatiquement exonéré.

S’il n’a fait que ce bandeau

Protection partielle seulement.

S’il a aussi :

• contractualisé ;

• qualifié les rôles ;

• limité techniquement les usages fautifs ;

• encadré la conservation et les sous-traitants ;

• documenté la sécurité ;

• prévu une doctrine d’usage et une assistance incident ;

alors sa position devient beaucoup plus solide.

7. Formule de synthèse

Le bandeau ne vaut pas “immunité”. Il vaut surtout :

• preuve de mise en garde ;

• indice de diligence ;

• élément de partage de responsabilité ;

• mais pas substitution aux obligations RGPD et, selon le cas, aux obligations AI Act.

Annexe — Grille de vigilance opérationnelle RGPD / AI Act pour les dirigeants

Objet de l’annexe

Cette annexe ne remplace pas l’analyse juridique du cas d’usage. Elle a pour fonction de fournir au dirigeant, au responsable métier ou au prestataire une méthode de tri rapide : identifier le bon niveau d’alerte, repérer le texte prioritaire à examiner et déclencher la bonne action interne. Les notions de responsable de traitement, sous-traitant, obligations de sécurité, information des personnes, rôle de déployeur et obligations de maîtrise de l’IA s’appuient directement sur le RGPD et l’AI Act.

1. Quand le RGPD se déclenche immédiatement

Le RGPD doit être regardé en priorité dès qu’un usage implique, même indirectement, une personne physique identifiable : nom, adresse e-mail nominative, voix, image, identifiant, dossier RH, ticket support, courrier signé, CV, enregistrement, historique d’échanges ou ensemble d’éléments permettant un recoupement. Le point déterminant n’est pas la sophistication de l’outil, mais l’existence d’un traitement de données personnelles.

Signaux d’alerte immédiats

Le réflexe RGPD doit être automatique si l’entreprise :

• colle un document réel dans une IA en ligne ;

• transmet un courrier, un CV, un compte rendu ou un ticket nominatif ;

• utilise un outil RH, commercial ou support alimenté par des données identifiantes ;

• fait traiter des données par un fournisseur SaaS, cloud ou IA ;

• ne sait pas précisément où les données sont envoyées, stockées ou réutilisées.

Dans ces situations, il faut au minimum vérifier la finalité, la base légale, l’information des personnes, la minimisation, la sécurité et le rôle du fournisseur. Ces exigences découlent des principes généraux, de la responsabilité du responsable de traitement et des obligations relatives aux sous-traitants et à la sécurité.

2. Quand l’AI Act devient un sujet concret pour l’entreprise

L’AI Act ne vise pas seulement les concepteurs techniques. Une entreprise qui utilise un système d’IA dans un cadre professionnel peut relever du rôle de déployeur. Cela impose au minimum une logique de gouvernance, et dans certains cas des obligations plus lourdes selon la catégorie du système utilisé. L’AI Act impose aussi des mesures relatives à la maîtrise de l’IA par les personnes qui utilisent ou pilotent ces systèmes.

Signaux d’alerte AI Act

Le réflexe AI Act doit être activé si l’outil :

• influence une décision concernant une personne ;

• classe, note, filtre, sélectionne ou priorise des individus ;

• est utilisé en recrutement, gestion RH, accès à un service, contrôle, sécurité ou évaluation ;

• interagit avec des personnes ou produit des contenus susceptibles d’induire en erreur ;

• est déployé sans consignes, sans formation, sans supervision humaine claire.

Dans ces cas, il faut vérifier si l’on se trouve seulement dans un usage professionnel ordinaire, dans un régime de transparence, ou dans un système susceptible d’entrer dans une catégorie à risque plus élevé.

3. Les cinq questions à poser avant tout déploiement

3.1. Quelles données entrent réellement dans l’outil ?

Il faut identifier ce qui est effectivement transmis, et non ce que l’on croit transmettre. Un usage apparemment banal peut embarquer des noms, fonctions, signatures, commentaires, métadonnées, pièces jointes ou historiques cachés. Si l’entreprise ne sait pas précisément quelles données passent dans l’outil, le niveau de maîtrise est déjà insuffisant au regard des exigences de responsabilité, de sécurité et de démonstration de conformité.

3.2. Pourquoi ces données sont-elles transmises ?

Un usage professionnel doit reposer sur une finalité précise. L’entreprise doit pouvoir expliquer ce que l’outil fait, pour quel objectif, et pourquoi ces données sont nécessaires à cet objectif. Cette logique renvoie directement aux principes de finalité, de minimisation et de licéité.

3.3. Qui décide réellement du traitement ?

Il faut distinguer l’entreprise utilisatrice, le prestataire, l’hébergeur éventuel, le fournisseur de modèle et les sous-traitants ultérieurs. Le RGPD impose une qualification réelle des rôles ; elle ne dépend pas uniquement de ce qui est écrit dans le marketing ou dans l’interface.

3.4. L’outil est-il encadré ou simplement toléré ?

Un outil utilisé sans validation, sans politique interne, sans DPA ou sans règle d’usage ne constitue pas un usage gouverné. C’est souvent là que naissent les non-conformités les plus graves : absence de base légale documentée, défaut d’information, défaut de minimisation, défaut de sécurité, absence de preuve.

3.5. Une personne humaine peut-elle encore comprendre, contester et corriger ?

Dès que l’outil influence une décision, la question de la supervision humaine devient centrale. En AI Act, cette logique monte fortement pour les systèmes à haut risque ; en RGPD, elle recoupe les exigences de loyauté, de transparence, de justification et, selon les cas, les règles sur les décisions produisant des effets juridiques ou significatifs.

4. Les quatre niveaux de vigilance à utiliser en interne

Niveau 1 — Usage courant encadré

L’outil est validé, les données transmises sont limitées, le fournisseur est encadré, les utilisateurs sont informés des règles, et aucune décision importante concernant une personne n’est influencée de manière significative. Dans ce cas, la priorité est la discipline opérationnelle : respecter les consignes, maintenir les paramètres de sécurité et garder la documentation à jour. Le RGPD reste applicable si des données personnelles sont traitées.

Niveau 2 — Usage sensible à encadrer

L’outil traite des données personnelles réelles, mais sans entrer clairement dans un cas de risque élevé. Exemples typiques : aide à la rédaction, résumé de documents, tri de tickets, assistance commerciale, transcription, support interne. Ici, il faut vérifier sérieusement la base légale, la minimisation, le contrat fournisseur, l’information et les mesures de sécurité.

Niveau 3 — Usage à validation préalable

L’usage touche aux RH, à la santé, à la sécurité, à des données sensibles, à l’évaluation de personnes, à l’accès à un service ou à une décision importante. Dans ce cas, la validation juridique, sécurité et gouvernance ne doit plus être facultative. Il faut envisager, selon les cas, une analyse plus poussée, une revue de proportionnalité, une AIPD si le risque est élevé, et une vérification spécifique au regard de l’AI Act.

Niveau 4 — Usage à bloquer ou suspendre

L’usage doit être stoppé ou suspendu lorsque l’entreprise n’est pas capable d’identifier les flux, le fournisseur, la finalité, la base légale, les données réellement transmises ou le cadre contractuel ; ou lorsqu’un outil promet des fonctions manifestement problématiques comme certaines manipulations comportementales, catégorisations ou inférences particulièrement sensibles. L’AI Act interdit certaines pratiques ; le RGPD, lui, ne permet pas de traiter n’importe comment sous prétexte d’innovation.

5. Ce qu’un prestataire doit pouvoir remettre à un client sérieux

Pour qu’un usage professionnel soit défendable, le prestataire doit pouvoir fournir au minimum une documentation exploitable : rôle juridique revendiqué, cadre contractuel adapté, règles de conservation, informations sur les sous-traitants ultérieurs, garanties de sécurité, politique de gestion d’incident, doctrine d’usage et consignes sur les données à ne pas injecter. Le RGPD impose un encadrement des sous-traitants ; l’AI Act, lui, renforce la logique de documentation, de gouvernance et de maîtrise des usages.

Un simple bandeau du type « n’entrez pas de données personnelles » peut être utile comme mise en garde, mais il ne remplace ni la qualification réelle des rôles, ni les mesures techniques et organisationnelles adaptées, ni le contrat requis lorsque le fournisseur agit comme sous-traitant.

6. Ce qu’un dirigeant doit exiger avant d’autoriser un usage

Avant d’autoriser un cas d’usage IA ou un outil SaaS traitant des données, le dirigeant devrait être en mesure d’obtenir une réponse claire aux questions suivantes :

L’outil est-il autorisé ? Le fournisseur est-il identifié ? Le rôle juridique de chacun est-il clair ? Les données transmises sont-elles strictement nécessaires ? Une information adéquate des personnes existe-t-elle ? Les accès, l’hébergement, la conservation et les transferts sont-ils connus ? Les utilisateurs ont-ils reçu des consignes adaptées ? Un incident peut-il être détecté, documenté et escaladé rapidement ?

Si plusieurs de ces réponses sont absentes, l’entreprise n’est pas dans un usage maîtrisé mais dans un usage toléré. Or le RGPD exige d’être capable de démontrer la conformité, et l’AI Act renforce l’exigence de compétence et de pilotage des usages professionnels de l’IA.

7. Le réflexe incident : ce qu’il faut faire sans attendre

Lorsqu’un doute existe sur une fuite, un envoi indu, une exposition non autorisée, une réutilisation imprévue ou un accès irrégulier, il faut immédiatement qualifier s’il s’agit d’une violation de données personnelles. En cas de risque pour les droits et libertés, la notification à la CNIL doit intervenir au plus tard dans les 72 heures ; en cas de risque élevé, les personnes concernées doivent aussi être informées, sauf exception prévue par le RGPD. La CNIL insiste également sur la nécessité de documenter la violation en interne.

8. Conclusion de l’annexe

Le bon usage de cette annexe est simple : dès qu’un outil traite des données réelles ou influence une décision, il faut sortir de la logique « test », « essai », « simple assistance » ou « outil pratique ». Le RGPD oblige l’entreprise à maîtriser les données, les rôles, les droits, la sécurité et la preuve. L’AI Act ajoute une couche de gouvernance sur l’usage professionnel des systèmes d’IA, en particulier lorsque ces systèmes influencent des personnes, des décisions ou des processus sensibles.