RGPD et IA : garder les données de sa PME en Europe, concrètement

C’est la première objection dans à peu près chaque projet, et elle est saine. Le problème est qu’elle est rarement posée avec assez de précision pour trouver une réponse utile.

« Est-ce que mes données partent aux États-Unis ? » recouvre en réalité trois questions distinctes, dont les réponses sont indépendantes.

Le trajet réel de vos données

Prenons un cas concret : une facture fournisseur déposée dans une boîte mail, traitée automatiquement, écrite dans le logiciel comptable. Voici les endroits où les données passent.

1. Le stockage du document. Le PDF arrive quelque part et y reste. C’est un choix d’hébergement classique, sur lequel vous avez un contrôle total : votre serveur, un hébergeur européen, ou vos propres murs.

2. L’orchestration. Le moteur qui enchaîne les étapes — n8n ou équivalent — voit passer l’ensemble des données. Il peut être auto-hébergé sur un serveur européen que vous contrôlez. C’est le point le plus facile à verrouiller, et c’est aussi celui qu’on néglige quand on utilise une plateforme d’automatisation grand public : dans ce cas, vos données transitent par l’infrastructure du fournisseur.

3. L’appel au modèle. C’est le seul moment où une donnée sort vers un tiers spécialisé. C’est là que se concentre la vraie question — et la bonne nouvelle, c’est qu’on peut choisir précisément ce qu’on envoie.

4. L’écriture finale. Retour dans votre logiciel métier, avec sa propre politique d’hébergement.

Sur ces quatre étapes, trois dépendent entièrement de vos choix d’architecture. Seule la troisième dépend d’un fournisseur externe, et encore : plusieurs options existent.

Les trois points à verrouiller par écrit

La localisation du traitement

Les principaux fournisseurs de modèles proposent des points d’accès situés dans l’Union européenne. Ce n’est pas systématiquement le réglage par défaut, et c’est rarement le cas sur les offres d’entrée de gamme. À vérifier explicitement, offre par offre.

Pour l’orchestration et le stockage, des hébergeurs européens comme Scaleway, OVH ou Hetzner règlent la question sans discussion.

La non-réutilisation pour l’entraînement

C’est la clause la plus importante et la plus mal comprise. Les conditions d’utilisation des offres professionnelles prévoient généralement que les données transmises ne servent pas à entraîner les modèles. Les offres grand public prévoient souvent l’inverse, ou une conservation par défaut.

Ne supposez rien : demandez la clause, lisez-la, gardez-en une copie datée.

Le contrat de sous-traitance

Si un prestataire traite des données personnelles pour votre compte, il est sous-traitant au sens de l’article 28. Le contrat écrit est obligatoire. Il doit préciser les finalités, les catégories de données, les durées de conservation, les mesures de sécurité, le recours éventuel à des sous-traitants ultérieurs, et le sort des données à la fin du contrat.

Un prestataire qui n’a pas de DPA à vous proposer n’a pas structuré son activité. C’est un signal sur le reste.

La minimisation : le levier le plus efficace

Le RGPD impose de ne traiter que les données nécessaires à la finalité. Appliqué à l’IA, ce principe est aussi le meilleur outil de réduction du risque — et il est très largement sous-utilisé.

Concrètement, sur une facture : le modèle a besoin de lire les montants, les dates, les libellés et la raison sociale du fournisseur. Il n’a aucun besoin du numéro de compte bancaire, ni du nom de la personne physique signataire, ni de son adresse personnelle.

Masquer ces champs avant l’appel au modèle prend quelques lignes dans le workflow et change la nature du traitement. Le même raisonnement vaut pour les CV, les dossiers clients ou les tickets de support : on peut presque toujours retirer les identifiants directs sans dégrader le résultat.

La question à poser à votre prestataire n’est pas « où partent mes données », c’est « quelles données partent réellement ». La différence entre les deux, c’est du travail d’ingénierie que peu de gens font.

Ce qu’il faut documenter

Quatre documents suffisent pour un projet d’automatisation classique :

• Une entrée au registre des traitements. Quelle finalité, quelles catégories de données, quelle base légale, quelle durée de conservation, quels destinataires.
• Le DPA avec le prestataire, et le cas échéant la liste de ses propres sous-traitants.
• Une note d’architecture décrivant le trajet des données, étape par étape. C’est ce document qui vous sauve le jour où quelqu’un pose la question — un client, un assureur, une autorité.
• L’information des personnes concernées, si le traitement porte sur des salariés ou des clients identifiables.

Aucun de ces quatre documents ne demande un cabinet d’avocats pour un cas simple. Ils demandent une heure de rédaction et de la précision.

L’argument que personne n’utilise

Une automatisation bien construite est souvent plus conforme que la situation qu’elle remplace.

Comparez honnêtement. Avant : un tableur qui circule par mail entre quatre personnes, dupliqué sur trois postes, conservé indéfiniment, sans trace de qui a consulté quoi. Après : un traitement défini, avec une durée de conservation paramétrée, des accès nominatifs, et un journal de chaque opération.

Le second est incomparablement plus défendable devant la CNIL que le premier. Ce qui crée le risque, ce n’est pas la technologie : c’est l’absence de cadre. Beaucoup d’entreprises qui hésitent à automatiser « à cause du RGPD » ont aujourd’hui des pratiques bien moins conformes que ce qu’elles refusent de mettre en place.

Le cas particulier de la décision automatisée

L’article 22 du RGPD encadre les décisions entièrement automatisées produisant des effets juridiques ou significatifs sur une personne : refus d’un dossier, résiliation, sanction, scoring qui conditionne un accès.

C’est l’une des raisons — la plus solide — de garder une validation humaine réelle sur les étapes qui engagent. « Réelle » signifie que la personne dispose de l’information et du temps pour examiner, pas qu’elle clique sur un bouton par réflexe.

Cette contrainte rejoint d’ailleurs le bon sens d’ingénierie : les systèmes qui proposent et font valider sont plus robustes, plus faciles à corriger, et bien mieux acceptés par les équipes.

---

En pratique, pour une PME française, une architecture défendable tient en une phrase : orchestration auto-hébergée en Europe, minimisation avant tout appel externe, endpoints UE avec clause de non-réutilisation, validation humaine sur ce qui engage, et quatre documents à jour. Rien d’exotique — mais rien qui se fasse tout seul non plus.