RGPD et IA dans une PME belge : ce qu'il faut vraiment vérifier

Le RGPD n'interdit pas à une PME d'utiliser l'intelligence artificielle. Il lui demande de savoir quelles données elle traite, pourquoi, où elles partent, combien de temps elles restent et qui peut y accéder.

Le problème commence rarement avec le modèle lui-même. Il commence avec un contrat vague, un outil activé par un collaborateur ou des données envoyées quelque part sans que personne ne puisse expliquer le trajet complet.

Voici les vérifications à faire avant de déployer une IA, les six questions à poser au prestataire et les trois clauses à faire relire dans le contrat.

Important : cet article est une grille de préparation, pas un avis juridique. Les questions de base légale, d'analyse d'impact, de transferts internationaux, de droit du travail ou de décision automatisée doivent être validées selon votre situation par votre DPO, votre juriste ou votre conseil.

Ce que dit vraiment le RGPD

Le RGPD ne contient pas une catégorie générale appelée « intelligence artificielle ». Il encadre le traitement de données à caractère personnel, quelle que soit la technologie employée. Une adresse e-mail professionnelle nominative, un CV, l'historique d'un client, une note liée à un salarié ou le contenu d'une conversation peuvent entrer dans ce cadre.

Le texte impose notamment une finalité déterminée, une base juridique, la minimisation des données, une durée de conservation limitée, une sécurité adaptée et la capacité à démontrer ces choix. Ces principes figurent aux articles 5 et 6 du règlement général sur la protection des données, règlement (UE) 2016/679, applicable depuis le 25 mai 2018.

Cette différence est essentielle. « Notre outil est conforme au RGPD » ne répond à presque aucune question utile. Un outil ne rend pas un usage conforme par nature. La conformité dépend du traitement réel : les données utilisées, la finalité, les personnes concernées, les accès, les décisions prises et les garanties mises autour du système.

Une PME qui choisit pourquoi et comment les données sont traitées est en principe responsable du traitement. Un fournisseur qui traite ces données pour son compte est en principe sous-traitant. Les rôles se déterminent sur les faits, pas seulement sur les mots du contrat. L'article 28 du RGPD encadre la relation avec un sous-traitant, tandis que le guide PME du Comité européen de la protection des données rassemble les repères pratiques destinés aux petites organisations. Sources consultées pour cette synthèse le 8 septembre 2026.

Le bon réflexe n'est donc pas de demander « est-ce que l'IA est autorisée ? ». Il est de décrire le traitement assez précisément pour que la réponse puisse être vérifiée.

Les 3 cas où une PME est concernée

1. L'IA lit des données de clients, de prospects ou de salariés

Un agent qui trie une boîte info@, résume des comptes rendus, prépare une réponse commerciale, classe des candidatures ou extrait des informations de factures traite potentiellement des données personnelles.

La première vérification porte sur la finalité et la base juridique. La base retenue pour collecter une donnée ne couvre pas automatiquement tous les usages futurs. L'utiliser dans un nouveau système d'IA peut demander une analyse distincte, une information mise à jour ou une limitation du périmètre. Les articles 5, 6, 13 et 14 du RGPD encadrent respectivement les principes, la licéité et l'information des personnes. Références vérifiées dans le texte officiel au 8 septembre 2026.

En pratique, il faut écrire ce que le système voit et ce qu'il fait. « Assistant interne » est trop vague. « Lit les demandes reçues sur une boîte partagée, propose une catégorie et prépare un transfert sans envoyer de réponse » est exploitable.

Cette précision permet aussi de minimiser les données. Si l'agent doit seulement reconnaître le sujet d'un e-mail, a-t-il besoin de l'historique complet du client ? Si une démonstration peut fonctionner sur des exemples fictifs, pourquoi utiliser des dossiers réels ?

2. Les données passent par un fournisseur externe

Une interface simple peut masquer plusieurs acteurs : l'intégrateur, l'hébergeur, le fournisseur du modèle, un service de journalisation et parfois un outil de support. Chacun peut recevoir une partie des données.

Quand un prestataire agit comme sous-traitant, le contrat doit couvrir les éléments prévus à l'article 28 du RGPD, notamment l'objet et la durée du traitement, sa nature et sa finalité, les catégories de données, les obligations de confidentialité et de sécurité, le recours à d'autres sous-traitants, l'assistance et le sort des données en fin de service. Source officielle consultée le 8 septembre 2026.

Le mot « européen » ne suffit pas. Une société européenne peut utiliser un sous-traitant établi ailleurs. Un centre de données situé en Europe ne dit pas qui peut accéder aux données ni depuis quel pays. Si des données sont transférées hors de l'Espace économique européen, le chapitre V du RGPD prévoit des conditions spécifiques, dont une décision d'adéquation ou des garanties appropriées selon le cas.

Il ne faut pas en déduire qu'un transfert est automatiquement interdit. Il faut demander quel mécanisme est utilisé, pour quel destinataire et pour quelles données, puis faire valider cette réponse si le flux est sensible.

3. L'IA évalue une personne ou influence une décision importante

Le niveau d'attention change quand le système classe des candidats, évalue des salariés, détecte une fraude, fixe une priorité de traitement ou influence une décision qui produit des effets juridiques ou affecte significativement une personne.

L'article 22 du RGPD prévoit un cadre particulier pour certaines décisions fondées exclusivement sur un traitement automatisé. L'article 35 prévoit une analyse d'impact lorsque le traitement est susceptible d'engendrer un risque élevé pour les droits et libertés. L'Autorité de protection des données belge présente l'analyse d'impact comme un outil à réaliser avant le traitement lorsqu'elle est requise. Références consultées le 8 septembre 2026.

Une validation humaine affichée dans l'interface ne suffit pas forcément. Il faut vérifier si la personne peut réellement comprendre la proposition, la contester et choisir autre chose. Si tous les dossiers marqués « à refuser » le sont sans examen, le bouton humain est décoratif.

Les données de santé, les opinions politiques, les convictions religieuses, les données biométriques ou les données relatives à des condamnations suivent en outre des règles renforcées aux articles 9 et 10 du RGPD. Dans ces cas, ne transformez pas une checklist générale en feu vert. Faites qualifier le traitement.

La checklist des 6 questions à poser au prestataire

Une réponse utile doit être écrite, précise et rattachée au service que vous achetez. Une page marketing générale ne remplace ni le contrat ni l'annexe de traitement des données.

1. Quelles données le système reçoit-il exactement ?

Demandez la liste par source : e-mails, pièces jointes, CRM, dossiers partagés, transcriptions, journaux techniques, instructions envoyées au modèle. Ajoutez les métadonnées, les sauvegardes et les données de support.

Puis demandez ce qui n'est pas nécessaire. Cette seconde partie force la minimisation prévue par l'article 5 du RGPD, au lieu de collecter tout ce qui est techniquement accessible.

2. Pour quelle finalité et sous quelle responsabilité chaque donnée est-elle traitée ?

Le prestataire traite-t-il tout uniquement sur vos instructions ? Réutilise-t-il certaines données pour sécuriser, évaluer ou améliorer son service ? Décide-t-il lui-même d'une finalité sur une partie des journaux ?

Cette question sert à répartir les rôles réels de responsable et de sous-traitant. Elle ne doit pas recevoir une réponse globale du type « nous sommes votre processor ». Demandez une réponse par traitement et faites-la rapprocher des articles 4 et 28 du RGPD.

3. Où les données sont-elles stockées, traitées et accessibles ?

Demandez les pays, pas seulement la région commerciale du cloud. Distinguez le stockage principal, les sauvegardes, le traitement par le modèle, la supervision humaine et le support technique.

Si un accès ou un transfert sort de l'Espace économique européen, demandez le mécanisme juridique utilisé et les garanties associées. Le chapitre V du RGPD est la source à faire examiner. « Hébergé en Europe » n'est qu'un morceau de la réponse.

4. Les données servent-elles à entraîner ou améliorer un modèle ?

Il faut distinguer trois choses : l'entraînement d'un modèle général, l'amélioration du service du fournisseur et la configuration de votre propre système. Les mots « nous n'entraînons pas sur vos données » peuvent laisser ouvertes l'évaluation humaine, la conservation d'extraits ou l'utilisation des retours.

Demandez quels contenus sont exclus, si l'exclusion est activée par défaut, ce que deviennent les journaux et si un humain peut voir les requêtes. La réponse attendue doit pouvoir entrer dans le registre et dans le contrat.

5. Quels sous-traitants interviennent et comment leurs changements sont-ils annoncés ?

Demandez la liste actuelle, la fonction de chacun, son pays et la manière dont vous serez informé d'un ajout ou d'un remplacement. Demandez aussi votre délai d'objection et la solution prévue si vous refusez un nouveau sous-traitant.

L'article 28, paragraphe 2, du RGPD prévoit une autorisation écrite spécifique ou générale pour le recours à un autre sous-traitant et, en cas d'autorisation générale, une information permettant au responsable d'émettre des objections. Source officielle consultée le 8 septembre 2026.

6. Comment peut-on contrôler, corriger et arrêter le système ?

Demandez les journaux disponibles, les droits de chaque utilisateur, les alertes, la procédure d'incident, les délais de notification, la suppression des données et la restitution en fin de contrat.

Pour un agent qui agit, ajoutez une matrice simple : ce qu'il peut lire, proposer, exécuter seul et ne jamais faire. C'est le prolongement opérationnel de la sécurité prévue à l'article 32 du RGPD. La sécurité appropriée dépend du risque : une suggestion de classement et un e-mail envoyé au client n'appellent pas les mêmes contrôles.

Cette logique rejoint la distinction expliquée dans notre article chatbot, agent IA et automatisation : plus le système agit, plus ses permissions, ses journaux et son arrêt doivent être explicites.

Les 3 clauses à exiger au contrat

Il ne s'agit pas de copier trois phrases trouvées en ligne. Il s'agit de vérifier que trois blocs existent, qu'ils correspondent à l'architecture réelle et qu'un conseil peut les relire sans devoir deviner le service acheté.

Clause 1 : finalité, instructions et limites d'utilisation

Le contrat ou l'annexe de traitement devrait identifier les catégories de données, les personnes concernées, les opérations effectuées, la durée et les instructions documentées. Il devrait préciser les usages interdits, notamment toute réutilisation non convenue pour entraîner ou améliorer un modèle général.

Demandez aussi ce qui arrive aux requêtes, aux réponses et aux journaux. Une promesse limitée au fichier envoyé ne couvre pas forcément les traces produites autour de ce fichier.

Ce bloc traduit les exigences de l'article 28, paragraphe 3, du RGPD. Faites-en vérifier la rédaction selon le rôle réel de chaque partie.

Clause 2 : sous-traitants, lieux et transferts

La clause devrait annexer la liste des sous-traitants, leur fonction et leur localisation, puis organiser l'information préalable en cas de changement. Elle devrait indiquer le mécanisme applicable à chaque transfert hors Espace économique européen et ce qui se passe si vous vous opposez à un nouveau destinataire.

Les fondements se trouvent à l'article 28, paragraphe 2, et au chapitre V du RGPD. Ne validez pas cette clause sur la seule présence des mots « clauses contractuelles types ». Demandez à quel flux, à quelle entité et à quel pays elles correspondent.

Clause 3 : sécurité, incident, audit et sortie

Le contrat devrait fixer les mesures de sécurité pertinentes, l'assistance en cas de demande d'une personne ou d'analyse d'impact, la notification des incidents, l'accès aux éléments de preuve et les conditions de restitution ou de suppression en fin de service.

L'article 28, paragraphe 3, et les articles 32 à 36 du RGPD donnent le cadre de ces obligations. Le délai contractuel de notification au client doit permettre à celui-ci d'évaluer ses propres obligations. Le RGPD fixe notamment, à l'article 33, un délai de 72 heures pour la notification par le responsable à l'autorité lorsque les conditions sont réunies. Cela ne signifie pas que toute PME doit notifier tout incident, ni que le prestataire peut attendre 72 heures avant de l'informer. Faites calibrer la clause au risque réel.

Hébergement européen, entraînement et sous-traitance : les trois faux raccourcis

« C'est hébergé en Europe, donc c'est conforme »

La localisation est une donnée importante, pas une conclusion. Il reste à connaître les entités qui accèdent au service, les transferts, les sauvegardes, le support et les mesures de sécurité.

Un projet d'automatisation du traitement des e-mails peut par exemple limiter fortement le risque en restant dans l'environnement Microsoft 365 de l'entreprise, mais cette architecture doit encore être décrite et contrôlée. La page gestion de boîte mail montre le cas d'usage opérationnel, pas une qualification juridique universelle.

« Les données ne servent pas à l'entraînement, donc il n'y a pas de traitement »

Lire une donnée pour produire une réponse est déjà un traitement au sens large de l'article 4 du RGPD. L'absence d'entraînement réduit un risque de réutilisation. Elle ne supprime ni la question de la base juridique, ni celle de la sécurité, ni celle de l'information des personnes.

« Le fournisseur est conforme, donc nous le sommes »

Les garanties du fournisseur comptent, mais la PME reste responsable de ses propres choix lorsqu'elle détermine la finalité et les moyens du traitement. Une certification, un hébergement européen ou une annexe contractuelle ne remplacent pas la description du cas d'usage et la limitation des accès.

L'AI Act : ce qui s'applique à une PME utilisatrice au 8 septembre 2026

Le règlement européen sur l'intelligence artificielle, ou AI Act, ne remplace pas le RGPD. Les deux textes peuvent s'appliquer au même système pour des raisons différentes : le RGPD protège les données personnelles, tandis que l'AI Act organise des obligations selon le rôle de l'acteur et le niveau de risque du système.

Le règlement (UE) 2024/1689 est entré en vigueur le 1er août 2024. Son article 113 prévoit une application progressive :

• depuis le 2 février 2025, les chapitres I et II s'appliquent, dont les pratiques interdites et l'obligation de prendre des mesures pour assurer un niveau suffisant de maîtrise de l'IA prévue à l'article 4 ;
• depuis le 2 août 2025, s'appliquent notamment les règles relatives aux modèles d'IA à usage général et plusieurs dispositions de gouvernance et de sanctions précisées par l'article 113 ;
• depuis le 2 août 2026, la majeure partie du règlement est applicable ;
• le 2 août 2027 reste l'échéance prévue pour l'article 6, paragraphe 1, et les obligations correspondantes concernant certains systèmes à haut risque liés à des produits réglementés.

Ces dates proviennent de l'article 113 du texte officiel de l'AI Act et de la présentation du cadre réglementaire par la Commission européenne, consultés le 8 septembre 2026. Une proposition de modification ou un calendrier annoncé ne remplace pas le texte applicable : vérifiez la version en vigueur au moment de votre projet.

Pour une PME qui utilise un outil fourni par un tiers, le rôle courant au sens de l'AI Act est celui de déployeur, défini à l'article 3 du règlement. Cela ne signifie pas que toutes les PME ni tous leurs outils deviennent « à haut risque ».

Si le système relève de la catégorie à haut risque, l'article 26 du règlement (UE) 2024/1689 prévoit des obligations pour le déployeur, notamment suivre les instructions, organiser une supervision humaine, surveiller le fonctionnement et conserver certains journaux placés sous son contrôle. D'autres obligations peuvent dépendre du contexte, notamment pour l'employeur ou l'organisme public. Cette qualification doit être vérifiée sur le cas concret.

Même hors haut risque, des obligations de transparence de l'article 50 peuvent concerner certains systèmes, par exemple lorsqu'une personne interagit directement avec une IA ou lorsqu'un contenu artificiel doit être signalé, sous les conditions et exceptions du texte. Là encore, la bonne question est précise : quel système, quel contenu, quel destinataire et quelle exception éventuelle ?

La première action raisonnable pour une PME n'est donc pas de construire un dossier AI Act de cinquante pages. C'est de dresser la liste des systèmes utilisés, du fournisseur, de la fonction, des personnes touchées et du niveau d'autonomie. Cette liste permet ensuite de vérifier le rôle et le risque avec le bon conseil.

Le registre de traitement, en pratique

Le registre n'est pas un inventaire de logiciels. C'est un inventaire de traitements. « ChatGPT » ou « agent IA » est une ligne trop pauvre pour comprendre quoi que ce soit.

Pour chaque usage, notez au minimum :

• la finalité exacte ;
• les catégories de personnes et de données ;
• les sources de données ;
• les destinataires et sous-traitants ;
• les pays de stockage, de traitement et d'accès ;
• la durée de conservation ;
• les mesures de sécurité principales ;
• le niveau d'autonomie et la validation humaine ;
• le propriétaire interne du traitement ;
• la date de la dernière vérification.

L'article 30 du RGPD organise le registre des activités de traitement. Il prévoit une dérogation limitée pour certaines organisations de moins de 250 personnes, mais cette dérogation ne vaut notamment pas lorsque le traitement n'est pas occasionnel, comporte un risque ou concerne certaines catégories de données. Une IA utilisée chaque jour dans les opérations ne doit donc pas être écartée du registre sur le seul argument « nous sommes une PME ». L'Autorité de protection des données belge fournit ses indications et modèles sur ce registre. Sources consultées le 8 septembre 2026.

Une fiche utile peut tenir sur une page. Prenons un agent de tri d'e-mails :

• finalité : classer les messages entrants et proposer leur routage ;
• données : identité, coordonnées, contenu du message et pièces jointes ;
• action : préparation d'une catégorie et d'un destinataire, sans réponse automatique ;
• accès : équipe autorisée, intégrateur pendant le support et fournisseurs listés au contrat ;
• conservation : durée définie pour les journaux, distincte de celle de la boîte mail ;
• contrôle : journal des décisions, correction humaine et arrêt du système.

Ce document ne prouve pas à lui seul que le traitement est conforme. Il force l'entreprise à voir les zones encore floues. C'est exactement son utilité.

La vérification qui tient sur une réunion

Avant de signer, réunissez le responsable métier, la personne qui gère l'informatique et, selon le risque, le DPO ou le conseil. Prenez un exemple réel et suivez-le du début à la fin : collecte, envoi, traitement, journal, sauvegarde, suppression.

Si personne ne peut répondre à l'une des six questions, ne compensez pas par une promesse générale. Réduisez le périmètre, retirez les données inutiles ou gardez l'action en validation humaine jusqu'à obtenir la réponse.

Le RGPD et l'AI Act ne demandent pas de réciter des textes. Ils obligent surtout à rendre le système explicable, gouvernable et vérifiable. Pour une PME, c'est aussi la meilleure manière d'éviter qu'un outil acheté en quelques clics devienne un processus critique que personne ne maîtrise.