Ce que le RGPD demande à un workflow automatisé
Un workflow qui lit des e-mails, des factures ou des demandes clients traite presque toujours des données personnelles : un nom, une adresse, un numéro de dossier, parfois davantage. Le règlement s'applique donc pleinement, indépendamment de la technologie employée.
Trois obligations structurent le projet. Il faut une base légale identifiée pour chaque finalité, et non une base générale pour « le projet ». Il faut limiter les données à ce qui est nécessaire à cette finalité. Et il faut informer les personnes concernées d'une manière compréhensible.
Une quatrième obligation est souvent oubliée : la durée de conservation doit être définie par type de donnée et appliquée réellement, y compris dans les journaux techniques et dans ce qui a été transmis au modèle.
Décision automatisée et supervision humaine
L'article 22 du règlement encadre les décisions produisant des effets juridiques ou affectant significativement une personne, lorsqu'elles reposent exclusivement sur un traitement automatisé. Refuser une candidature, résilier un contrat ou rejeter une demande entrent typiquement dans ce champ.
La conséquence pratique est simple : dans ces cas, une personne doit intervenir de manière effective, avec le pouvoir et l'information nécessaires pour changer le résultat. Une validation de façade, où l'opérateur clique sans pouvoir examiner, ne satisfait pas l'exigence.
Cette contrainte détermine l'architecture, pas seulement la documentation. C'est la raison pour laquelle nous concevons les seuils de confiance et les points de validation dès le départ, et non comme une couche ajoutée après coup. Voir notre guide sur la validation humaine.
Faut-il une analyse d'impact ?
Une analyse d'impact relative à la protection des données devient obligatoire lorsque le traitement est susceptible d'engendrer un risque élevé pour les droits des personnes. L'évaluation systématique d'aspects personnels, le traitement à grande échelle et l'usage de technologies innovantes sont des critères qui, combinés, orientent vers cette obligation.
En pratique, un système qui trie des candidatures, qui note des personnes ou qui traite des données sensibles appelle une analyse. Un système qui classe des factures fournisseurs, en général non.
Le point à retenir : cette analyse se mène avant le déploiement, pas après un incident. Elle produit aussi un document utile au-delà de la conformité, parce qu'elle oblige à écrire ce que le système fait réellement.
Sous-traitants, modèles et hébergement
Un workflow IA fait généralement intervenir plusieurs prestataires : l'hébergeur, le fournisseur du modèle, l'outil d'automatisation, éventuellement un service de reconnaissance de caractères ou de transcription. Chacun est un sous-traitant au sens du règlement et doit être encadré contractuellement.
Trois questions doivent recevoir une réponse écrite pour chacun. Dans quelles régions les données sont-elles traitées ? Sont-elles conservées, et pendant combien de temps ? Servent-elles à entraîner des modèles ?
C'est précisément pourquoi nous n'affirmons pas de manière générale que les données sont traitées en Europe. Cette affirmation dépend des fournisseurs retenus pour votre projet, et la formuler à l'avance sur un site web serait une promesse que l'architecture ne soutient pas nécessairement.
Peut-on utiliser un assistant grand public avec des données clients ?
La question revient dans presque tous les projets, et la réponse honnête est : cela dépend de la version et du contrat, pas du produit.
Les offres grand public et les offres professionnelles des mêmes éditeurs diffèrent sur des points décisifs : la réutilisation des contenus pour l'entraînement, la durée de conservation, la localisation, et l'existence d'un accord de sous-traitance opposable. Un compte individuel souscrit par un collaborateur n'offre généralement aucune de ces garanties.
Le risque le plus fréquent que nous rencontrons n'est d'ailleurs pas le projet encadré, c'est l'usage informel : des collaborateurs qui collent des extraits de contrats ou de dossiers clients dans un outil personnel, sans que personne ne l'ait autorisé ni interdit. Une politique écrite et un outil interne acceptable traitent ce risque mieux qu'une interdiction que personne n'applique.
Ce que l'AI Act change pour une PME belge
Le règlement européen sur l'intelligence artificielle s'applique progressivement. Depuis le 2 août 2026, la majorité de ses dispositions sont en vigueur, dont les obligations de transparence de l'article 50 (source : règlement (UE) 2024/1689).
Trois conséquences concrètes pour une PME utilisatrice. Un système conversationnel doit indiquer clairement qu'il s'agit d'une intelligence artificielle, sauf lorsque cela ne fait aucun doute. Les contenus générés doivent être marqués de façon lisible par machine. Et l'entreprise doit pouvoir démontrer que ses équipes ont été sensibilisées aux possibilités, aux limites et aux risques de ces systèmes.
Les obligations les plus lourdes visent les systèmes à haut risque, dont l'application a été reportée : les systèmes relevant de l'annexe III, notamment en matière d'emploi, d'éducation ou de biométrie, sont concernés à partir du 2 décembre 2027 selon le calendrier révisé en 2026. Une automatisation documentaire ou commerciale ordinaire ne relève pas de cette catégorie, mais un outil de tri de candidatures peut y tomber.
Secteurs réglementés : comptabilité, finance, immobilier
Dans une fiduciaire ou un cabinet comptable, le secret professionnel s'ajoute au règlement. La question n'est pas seulement de savoir si le traitement est licite, mais qui accède aux pièces des clients et sous quelle responsabilité.
Dans la finance et l'assurance, les obligations de traçabilité et de conservation sont souvent plus strictes que le minimum légal en matière de protection des données, et elles s'imposent au système autant qu'aux personnes.
En immobilier, la sensibilité tient moins à la nature des données qu'à leur volume et à leur durée de vie : un portefeuille de baux contient des informations personnelles sur des locataires pendant des années, souvent sans que la durée de conservation ait été définie.
Liste de contrôle avant mise en production
Ces huit points se vérifient avant le déploiement, pas après. Ils constituent aussi une bonne grille pour évaluer une proposition de prestataire.
- La finalité et la base légale sont écrites pour chaque traitement, séparément.
- Les données transmises au système sont limitées à ce qui est nécessaire à cette finalité.
- Chaque sous-traitant est identifié, avec sa région de traitement, sa durée de conservation et le sort des données envoyées au modèle.
- Les durées de conservation s'appliquent réellement, journaux techniques compris.
- Les points de validation humaine sont définis, et la personne qui valide dispose de l'information nécessaire.
- Un journal d'audit permet de reconstituer qui a décidé quoi, et quand.
- Les personnes concernées sont informées, et l'exercice de leurs droits est possible en pratique.
- Les équipes ont été sensibilisées aux limites du système, et cette sensibilisation est documentée.
Ce que nous documentons dans chaque projet
Avant toute mise en production, nous produisons un document unique reprenant les régions de traitement, les fournisseurs, les journaux, les sauvegardes, les durées de conservation, les accès nominatifs et les points de validation humaine. Vous le validez, et il fait partie du projet au même titre que le workflow.
Ce document n'est pas un avis juridique et ne remplace pas votre conseil. Il rend en revanche vérifiable ce qui, autrement, resterait une affirmation commerciale.
Si vous voulez discuter d'un cas précis, décrivez-le sur notre page contact. Notre méthode de travail et les étapes qui précèdent la mise en production sont décrites sur la page méthode.
Statistique ou fait externe, cité avec sa source et sa date.