Le RGPD n'a pas changé parce que l'IA est arrivée. Ce sont les mêmes principes qu'en 2018 : une finalité, une base légale, des données proportionnées, une durée de conservation, des personnes informées. Ce qui a changé, c'est la vitesse à laquelle on peut envoyer des données quelque part sans y penser. Voici les quatre questions que je pose systématiquement au cadrage d'un cas d'usage — et une mise au point sur un malentendu tenace.
Je précise d'emblée : je ne suis pas juriste. Cet article n'est pas un avis juridique. Il sert à préparer la conversation avec ton DPO ou ton avocat, pas à la remplacer.
Question 1 — Sur quelle base légale tu t'appuies ?
C'est la question qu'on saute le plus souvent, parce qu'elle a l'air théorique. Elle ne l'est pas : c'est elle qui détermine ce que tu peux faire et ce que tu dois dire.
Dans la plupart des cas d'usage internes, on est sur l'intérêt légitime de l'entreprise ou sur l'exécution d'un contrat. Pour un usage marketing plus intrusif, on bascule vers le consentement, avec tout ce que ça implique — recueil, preuve, retrait possible.
Le piège classique : un traitement existait déjà, avec une base légale documentée, et on ajoute une couche IA qui change la finalité. Analyser des enregistrements d'appels pour former les équipes, ce n'est pas la même finalité que les analyser pour évaluer individuellement les conseillers. Nouvelle finalité, nouvelle analyse.
Écris la finalité en une phrase, sans « et », avant d'aller plus loin. Si tu as besoin de deux phrases, tu as deux traitements.
Question 2 — Quelles données entrent réellement ?
Pas les données que le projet prévoit d'utiliser : celles qui vont effectivement passer par le système.
Cette nuance est décisive parce que les données personnelles arrivent presque toujours par la bande. Tu conçois un assistant qui répond aux questions sur les procédures internes, et les gens y collent des extraits de mails avec des noms de clients. Tu branches un outil sur une base documentaire « technique » qui contient, en pièce jointe, trois CV oubliés là en 2021.
Deux réflexes utiles :
- Regarder les entrées réelles, pas les entrées prévues. Sur un pilote, lis un échantillon de ce que les utilisateurs ont vraiment tapé. C'est toujours instructif.
- Minimiser à la source. Si la tâche n'a pas besoin du nom, retire le nom. Pseudonymiser avant l'envoi coûte peu et fait tomber une bonne partie du sujet.
Question 3 — Où sont-elles traitées, et par qui ?
Trois éléments à vérifier dans le contrat de l'outil, et ils sont rarement au même endroit :
- La localisation du traitement. Union européenne, ou hors UE avec un mécanisme de transfert. Beaucoup d'éditeurs proposent aujourd'hui une option de traitement en Europe, mais c'est souvent une option — pas le réglage par défaut.
- Le rôle du fournisseur. Sous-traitant qui traite pour ton compte, ou responsable de traitement pour ses propres finalités ? Ça change tout, et ça se lit dans les conditions.
- Ce que le fournisseur fait des données envoyées. C'est le point suivant.
Question 4 — Combien de temps sont-elles conservées ?
Trois durées différentes se cachent derrière cette question, et il faut les traiter séparément.
- La conservation chez le fournisseur : historique des conversations, journaux techniques, rétention pour la modération. Souvent quelques semaines par défaut, parfois configurable, parfois nulle sur les offres entreprise.
- La conservation dans ton propre système : les traces que tu gardes toi-même. Utile, y compris pour la traçabilité, mais ça se documente et ça se purge.
- La conservation dans le modèle, qui n'existe que si tes données servent à l'entraînement.
Le malentendu à lever : API n'est pas entraînement
C'est la confusion la plus répandue, et elle fausse beaucoup de discussions.
Quand tu appelles un modèle via une API ou une offre entreprise, tu envoies un texte, tu récupères une réponse. Sur les offres professionnelles des principaux fournisseurs, ces contenus ne servent pas par défaut à entraîner les modèles, et une durée de rétention technique courte est prévue. Le contenu transite, il est traité, il n'est pas absorbé.
Quand tu entraînes ou affines un modèle sur tes données, c'est autre chose : les données participent à la construction du modèle, et retirer une donnée après coup n'est pas une opération triviale. Le droit à l'effacement devient nettement plus délicat à honorer.
Entre les deux, il y a les offres grand public gratuites, où les contenus peuvent servir à l'amélioration du service selon les réglages. C'est précisément pour ça que le compte personnel d'un collaborateur n'a rien à faire dans un usage professionnel.
Conséquence pratique : la vraie ligne de partage n'est pas « IA ou pas IA », c'est quel contrat, quel réglage, quel compte. Et ça se vérifie une fois, au moment du choix de l'outil.
La séquence que je recommande
Au cadrage, avant tout développement, produis une demi-page qui répond aux quatre questions. Finalité, base légale, données réellement traitées, localisation et durées. Ajoute-y ce qu'on dit aux personnes concernées et par quel canal.
Cette demi-page a trois vertus : elle prend trente minutes, elle rend la conversation avec le DPO efficace au lieu d'anxieuse, et elle fait tomber d'elle-même une partie des cas d'usage mal posés. Si tu n'arrives pas à écrire la finalité en une phrase, le problème n'est pas réglementaire — il est produit.
Ensuite, fais relire par quelqu'un dont c'est le métier. Une analyse d'impact peut être nécessaire selon le traitement, et cette décision-là ne se prend pas au doigt mouillé.
Le réflexe à garder
Un cas d'usage IA se qualifie côté données au moment où on l'écrit sur une feuille, pas au moment où on le branche. Trente minutes au cadrage, ou trois semaines de reprise après. C'est le même arbitrage que sur la dette technique, avec un régulateur en plus.