RGPD et IA en 2026 : ce que votre entreprise doit savoir et respecter

Vos équipes utilisent déjà l’IA, parfois sans vous le dire. Un commercial colle un échange client dans un assistant conversationnel. Un manager synthétise des entretiens RH avec un LLM. Un service client teste un agent IA sur des tickets. Un collaborateur branche Make, n8n ou Zapier à un outil métier pour automatiser une relance.

Le sujet n’est donc plus : « faut-il autoriser l’IA ? »

Le vrai sujet en 2026 est : comment utiliser l’IA sans exposer l’entreprise à des risques RGPD, contractuels, opérationnels ou réputationnels ?

Cet article vous donne une lecture claire des obligations RGPD et IA Act applicables à l’usage de l’IA en entreprise. Il ne remplace pas un avis juridique personnalisé. Les règles évoluent, les lignes directrices des autorités aussi. Pour un cas sensible, notamment RH, santé, scoring, surveillance ou données à grande échelle, faites valider votre approche par votre DPO, votre conseil juridique ou un expert conformité.

RGPD et IA en 2026 : pourquoi le sujet devient prioritaire

L’IA générative s’est installée dans les usages métiers avant que les processus de conformité ne suivent.

C’est logique : les outils sont faciles à tester, souvent accessibles en ligne, et les cas d’usage sont nombreux. Rédaction, synthèse, analyse documentaire, automatisation de workflows, agents IA, recherche augmentée par RAG, support client, qualification de leads, aide à la décision.

Mais dès qu’un outil IA traite des données personnelles, le RGPD s’applique.

Une donnée personnelle, ce n’est pas seulement un nom ou une adresse email. Cela peut être :

• un numéro de téléphone ;
• une adresse IP ;
• une donnée RH ;
• un historique client ;
• une conversation de support ;
• une voix retranscrite ;
• un document contenant des informations indirectement identifiantes ;
• une note interne permettant de reconnaître une personne.

En parallèle, l’IA Act européen ajoute une couche d’obligations spécifiques aux systèmes d’IA selon leur niveau de risque.

Le RGPD protège les personnes et encadre les données personnelles.
L’IA Act encadre les systèmes d’IA, leurs usages et leurs risques.

Les deux textes peuvent donc s’appliquer en même temps.

À retenir : si votre entreprise utilise un LLM, un agent IA ou une automatisation comprenant des données personnelles, le point de départ n’est pas l’outil. C’est le traitement de données, le niveau de risque et le rôle de votre entreprise dans la chaîne.

RGPD vs IA Act : deux textes, deux logiques

Le RGPD est applicable depuis 2018. Il encadre la collecte, l’usage, la conservation, la sécurité et le partage des données personnelles.

L’IA Act, entré en vigueur en 2024, s’applique progressivement. En 2026, il devient central pour de nombreux usages d’IA, notamment les systèmes dits « à haut risque ».

Le RGPD répond à une question

« Que faites-vous des données personnelles ? »

Il impose notamment :

• une finalité claire ;
• une base légale ;
• une information des personnes ;
• une minimisation des données ;
• une durée de conservation maîtrisée ;
• une sécurité adaptée ;
• un respect des droits des personnes ;
• une analyse d’impact si le risque est élevé ;
• un encadrement des sous-traitants.

L’IA Act répond à une autre question

« Quel type de système d’IA utilisez-vous, pour quel usage, avec quel niveau de risque ? »

Il distingue plusieurs niveaux :

• pratiques interdites ;
• systèmes à haut risque ;
• systèmes soumis à obligations de transparence ;
• modèles d’IA à usage général ;
• usages à risque limité ou faible.

Pour une PME ou une ETI, l’enjeu principal consiste à identifier si elle est simple utilisatrice, appelée « déployeur » dans l’IA Act, ou si elle modifie, intègre ou met à disposition un système d’IA d’une manière qui la rapproche du rôle de fournisseur.

Dans beaucoup de cas, une entreprise qui utilise un outil IA pour ses besoins internes sera déployeur. Mais ce n’est pas automatique. Si elle développe un agent IA pour des clients, personnalise fortement un modèle ou intègre l’IA dans un service commercialisé, l’analyse change.

Les dates clés de l’IA Act à avoir en tête en 2026

L’IA Act est entré en vigueur le 1er août 2024. Son application est progressive.

Les grandes étapes à connaître :

• février 2025 : application des interdictions concernant certaines pratiques d’IA ;
• août 2025 : premières obligations liées aux modèles d’IA à usage général ;
• août 2026 : application d’une grande partie des obligations, notamment pour de nombreux systèmes à haut risque ;
• août 2027 : certaines obligations supplémentaires, notamment pour des systèmes intégrés à des produits réglementés.

En 2026, une entreprise qui utilise l’IA doit donc arrêter de fonctionner en mode expérimentation informelle.

Elle doit documenter ses usages, classer ses risques et définir des règles internes.

Ce travail est proche d’une démarche de transformation structurée. Si vous n’avez pas encore cartographié vos usages, un audit IA de votre maturité permet souvent d’identifier les cas d’usage déjà en place, les données manipulées et les priorités de mise en conformité.

Les obligations RGPD à appliquer à vos usages IA

Le RGPD ne bloque pas l’usage de l’IA. Il impose de la méthode.

Voici les points à traiter avant de déployer un usage IA en entreprise.

1. Identifier les données traitées

Commencez par une question simple : quelles données entrent dans le système IA ?

Exemples :

• prompts saisis par les collaborateurs ;
• fichiers envoyés à un LLM ;
• comptes rendus de réunion ;
• tickets support ;
• emails clients ;
• données CRM ;
• CV ;
• entretiens annuels ;
• contrats ;
• factures ;
• logs applicatifs.

Il faut aussi regarder les données produites par l’IA.

Une synthèse générée à partir de données personnelles peut elle-même devenir une donnée personnelle. Par exemple, un résumé RH ou une évaluation de risque client.

Le risque fréquent consiste à sécuriser la base de données source, mais à oublier les exports, les prompts, les conversations, les embeddings, les logs et les historiques générés autour du workflow IA.

2. Définir une finalité claire

Le RGPD exige une finalité déterminée, explicite et légitime.

Autrement dit, vous devez savoir pourquoi vous utilisez l’IA.

« Améliorer la productivité » est souvent trop vague.
« Résumer automatiquement les tickets support pour aider les conseillers à préparer une réponse » est plus concret.
« Classer les demandes entrantes par catégorie pour réduire le tri manuel » est également plus clair.

La finalité doit guider la configuration du système.

Si votre objectif est de synthétiser des tickets, il n’est pas forcément nécessaire d’envoyer tout l’historique client, les pièces jointes complètes ou les données de facturation.

Bonne pratique : formulez chaque cas d’usage IA en une phrase métier. Exemple : « Utiliser un LLM pour synthétiser les demandes clients entrantes, sans décision automatique, avec validation humaine avant réponse. »

3. Choisir une base légale

Chaque traitement de données personnelles doit reposer sur une base légale.

Selon les cas, il peut s’agir notamment :

• de l’exécution d’un contrat ;
• de l’intérêt légitime ;
• d’une obligation légale ;
• du consentement ;
• de la gestion de la relation de travail, dans un cadre strict.

Le choix dépend du contexte. Il ne se déduit pas automatiquement du fait que l’outil est utile ou performant.

Pour des usages sensibles, comme l’IA appliquée aux ressources humaines, à l’évaluation de personnes, à la santé, à la détection de fraude ou à la surveillance, l’analyse doit être renforcée.

Processia peut aider à cadrer les flux, les workflows et les risques opérationnels, mais la base légale doit être validée avec vos interlocuteurs conformité ou juridiques.

4. Informer les personnes concernées

Si vous utilisez l’IA sur des données personnelles, les personnes concernées doivent être informées de manière claire.

Cela peut concerner :

• vos clients ;
• vos prospects ;
• vos salariés ;
• vos candidats ;
• vos fournisseurs ;
• les utilisateurs d’un service.

L’information doit expliquer, selon le cas :

• les finalités du traitement ;
• les catégories de données utilisées ;
• les destinataires ;
• la durée de conservation ;
• les droits des personnes ;
• l’existence d’un traitement automatisé lorsqu’il y en a un ;
• les grandes logiques de traitement si une décision automatisée produit des effets significatifs.

Un point d’attention : l’IA générative donne parfois l’impression d’être un simple outil bureautique. Mais si elle traite des données personnelles dans un processus métier, elle doit être intégrée à votre documentation RGPD.

5. Minimiser les données envoyées à l’IA

La minimisation est l’un des principes importants pour l’IA.

Il consiste à ne traiter que les données nécessaires.

Concrètement :

• éviter de coller des dossiers complets dans un chatbot ;
• supprimer les données inutiles avant envoi ;
• remplacer les noms par des identifiants lorsque c’est possible ;
• masquer les informations sensibles ;
• limiter le contexte transmis au modèle ;
• privilégier des extraits pertinents plutôt que des bases entières ;
• éviter d’utiliser des données réelles pour des tests sans nécessité.

Dans un système RAG, par exemple, le modèle ne doit pas accéder à toute la documentation de l’entreprise par défaut. Le moteur de recherche doit récupérer uniquement les passages utiles, avec des droits d’accès alignés sur ceux de l’utilisateur.

Un RAG mal conçu peut devenir une fuite de données interne : un collaborateur pourrait obtenir une réponse construite à partir d’un document auquel il n’aurait jamais dû accéder.

6. Encadrer les sous-traitants et fournisseurs IA

Dès que vous utilisez un outil externe qui traite des données personnelles pour votre compte, vous devez contrôler le cadre contractuel.

Points à vérifier :

• rôle du fournisseur : responsable de traitement, sous-traitant, coresponsable ;
• existence d’un accord de traitement des données ;
• localisation des données ;
• transferts hors Union européenne ;
• conditions d’utilisation des prompts et fichiers ;
• utilisation éventuelle des données pour entraîner ou améliorer les modèles ;
• durée de conservation des conversations et logs ;
• mesures de sécurité ;
• gestion des incidents ;
• possibilité de supprimer les données ;
• auditabilité et documentation disponible.

Attention aux comptes gratuits ou grand public utilisés pour des données d’entreprise. Les conditions peuvent être inadaptées pour des usages professionnels.

Le sujet n’est pas de bannir tous les outils externes. Il est de choisir le bon niveau de contrat, de paramétrage et de contrôle selon la sensibilité des données.

7. Réaliser une analyse d’impact si nécessaire

Une analyse d’impact relative à la protection des données, souvent appelée AIPD ou DPIA, peut être nécessaire lorsque le traitement présente un risque élevé pour les droits et libertés des personnes.

C’est souvent le cas pour des traitements à grande échelle, des données sensibles, de la surveillance, du scoring, de l’évaluation de personnes ou des décisions automatisées avec effets importants.

Exemples de cas à examiner sérieusement :

• tri automatisé de candidatures ;
• analyse d’entretiens RH ;
• scoring de clients ou prospects ;
• détection comportementale ;
• surveillance de salariés ;
• IA utilisée dans un contexte médical ;
• décision automatisée sur l’accès à un service.

L’AIPD permet d’identifier les risques, de définir des mesures de réduction et de documenter les arbitrages.

8. Garantir les droits des personnes

Les personnes concernées disposent de droits : accès, rectification, effacement, opposition, limitation, portabilité dans certains cas.

Avec l’IA, la difficulté est pratique.

Pouvez-vous retrouver les données d’une personne dans :

• les prompts ;
• les fichiers transmis ;
• les bases vectorielles ;
• les historiques de conversation ;
• les logs ;
• les exports ;
• les jeux de test ;
• les résultats générés ?

Si la réponse est non, le système est difficile à maîtriser.

Une bonne architecture IA doit prévoir dès le départ la traçabilité, la suppression et la limitation des données.

9. Sécuriser les accès et les workflows

La sécurité RGPD ne se limite pas au chiffrement.

Elle concerne aussi l’organisation des accès.

Pour un workflow IA, posez-vous les questions suivantes :

• qui peut envoyer des données au modèle ?
• qui peut consulter les réponses ?
• qui peut accéder aux historiques ?
• qui peut modifier les prompts système ?
• qui administre les connecteurs no-code ?
• qui valide les automatisations ?
• qui surveille les erreurs ?
• qui peut exporter les données ?

Les outils no-code comme Make, n8n ou Zapier sont puissants pour connecter les applications. Mais chaque scénario automatisé devient un flux de données à documenter et à sécuriser.

Un scénario mal paramétré peut envoyer une pièce jointe au mauvais service, conserver trop longtemps des données ou exposer un connecteur avec trop de droits.

IA Act : quelles obligations pour une entreprise utilisatrice ?

L’IA Act classe les systèmes d’IA selon leur niveau de risque.

Pour une PME ou une ETI, les obligations varient selon l’usage.

Les pratiques interdites

Certaines pratiques sont interdites dans l’Union européenne depuis 2025.

L’objectif est d’empêcher des usages considérés comme incompatibles avec les droits fondamentaux. Cela peut notamment viser certaines formes de manipulation, d’exploitation de vulnérabilités, de scoring social ou d’identification biométrique dans des conditions strictement encadrées.

Pour une entreprise classique, le risque principal est rarement de tomber volontairement dans ces pratiques. Le risque réel est plutôt de lancer un projet mal cadré dans un domaine sensible : surveillance, comportement, notation de personnes, contrôle des salariés, évaluation automatisée.

Avant tout projet de ce type, l’analyse juridique est indispensable.

Les systèmes à haut risque

L’IA Act impose des obligations renforcées pour les systèmes à haut risque.

Des usages peuvent être concernés dans des domaines comme :

• emploi et gestion des travailleurs ;
• éducation et formation professionnelle ;
• accès à certains services essentiels ;
• évaluation de solvabilité ;
• application de la loi ;
• migration et contrôle des frontières ;
• justice ;
• infrastructures critiques ;
• certains produits réglementés.

Pour une entreprise, les cas RH sont particulièrement sensibles.

Exemples :

• filtrer des CV avec un système IA ;
• classer automatiquement des candidats ;
• évaluer la performance de salariés ;
• recommander des promotions ou sanctions ;
• analyser des comportements au travail.

Même si l’IA ne prend pas officiellement la décision finale, son influence peut être significative. Une validation humaine symbolique ne suffit pas toujours si, en pratique, les équipes suivent systématiquement la recommandation de l’outil.

Point de vigilance : « l’humain dans la boucle » n’est pas une formule magique. Il faut que la personne puisse comprendre, contester, corriger et réellement s’écarter de la recommandation IA.

Les obligations de transparence

Certains systèmes doivent respecter des obligations de transparence.

Par exemple, lorsqu’une personne interagit avec un chatbot, elle doit généralement être informée qu’elle parle à un système d’IA, sauf si le contexte est évident.

Pour les contenus générés ou modifiés artificiellement, il peut aussi exister des obligations d’information, notamment dans les cas de deepfakes ou de contenus susceptibles de tromper.

En entreprise, cela concerne :

• chatbots clients ;
• assistants RH ;
• agents IA de support ;
• messages générés automatiquement ;
• synthèses utilisées dans des échanges externes ;
• contenus marketing générés ou modifiés par IA.

La règle opérationnelle est simple : ne pas faire passer une interaction automatisée pour une interaction humaine lorsque cela peut induire en erreur.

La compétence IA des équipes

L’IA Act introduit aussi une exigence de littératie IA, souvent traduite par compétence ou culture IA.

Les entreprises doivent veiller à ce que les personnes utilisant ou supervisant des systèmes d’IA aient un niveau de compétence adapté.

Cela ne signifie pas transformer tous les collaborateurs en data scientists.

Cela signifie former les équipes à :

• comprendre les limites des modèles ;
• éviter de saisir des données sensibles ;
• vérifier les résultats ;
• repérer les hallucinations ;
• respecter les règles internes ;
• savoir quand demander validation ;
• documenter un incident ou une anomalie.

C’est un sujet très concret de conduite du changement. Pour structurer cette montée en compétences, vous pouvez vous appuyer sur une démarche comme former ses équipes à l’IA par étapes, en adaptant les contenus aux métiers et aux risques.

Les risques fréquents à éviter en PME et ETI

La plupart des incidents IA ne viennent pas d’un modèle sophistiqué. Ils viennent d’usages simples, mal encadrés.

Voici les erreurs courantes.

Copier-coller des données sensibles dans un LLM externe

C’est un risque fréquent.

Un collaborateur veut gagner du temps. Il colle :

• un contrat ;
• un fichier client ;
• une réclamation ;
• un compte rendu RH ;
• un tableau financier ;
• un email contenant des données personnelles.

Sans politique claire, chacun improvise.

La bonne réponse n’est pas seulement d’interdire. Il faut fournir des alternatives : outils validés, règles de pseudonymisation, exemples de prompts acceptables, circuits de validation.

Lancer un agent IA sans garde-fous

Un agent IA ne se contente pas de répondre. Il peut agir : envoyer un email, créer une tâche, modifier une fiche CRM, déclencher un workflow, produire un compte rendu, interroger une base de données.

Plus un agent a d’autonomie, plus les contrôles doivent être stricts.

À vérifier :

• périmètre d’action ;
• droits applicatifs ;
• validation humaine ;
• logs ;
• seuils de confiance ;
• mécanisme d’arrêt ;
• gestion des erreurs ;
• tests sur données fictives ou minimisées ;
• suivi post-déploiement.

Un agent IA connecté à un CRM ou à une messagerie doit être traité comme un vrai composant métier, pas comme un gadget.

Utiliser le fine-tuning sans nécessité

Le fine-tuning consiste à réentraîner ou adapter un modèle sur des données spécifiques.

Il peut être utile dans certains cas. Mais beaucoup d’entreprises l’envisagent trop vite.

Pour des usages documentaires, un RAG bien conçu suffit souvent. Le RAG permet de connecter un modèle à une base documentaire sans intégrer directement toutes les données dans les poids du modèle.

Cela ne supprime pas les obligations RGPD, mais cela peut faciliter la maîtrise des sources, des accès et des mises à jour.

Avant un fine-tuning, demandez-vous :

• quelles données seront utilisées ?
• contiennent-elles des données personnelles ?
• les personnes ont-elles été informées ?
• quelle est la base légale ?
• les données peuvent-elles être supprimées ?
• le modèle peut-il restituer des informations sensibles ?
• un RAG ou des prompts structurés suffiraient-ils ?

Oublier les usages informels

Les projets officiels sont rarement les seuls usages IA de l’entreprise.

Les usages informels apparaissent souvent dans :

• les équipes commerciales ;
• le marketing ;
• les RH ;
• la finance ;
• le support ;
• les assistants de direction ;
• les fonctions juridiques ;
• les managers opérationnels.

Un audit interne léger permet souvent de découvrir plusieurs pratiques non documentées, parfois utiles, parfois risquées.

L’objectif n’est pas de sanctionner. Il est de transformer les usages sauvages en pratiques maîtrisées.

Croire que la conformité bloque le ROI

La conformité est parfois perçue comme un frein.

En réalité, elle permet souvent de mieux prioriser.

Un cas d’usage avec données sensibles, décision automatisée et fort risque juridique demandera plus de cadrage. Ce n’est pas forcément le meilleur premier projet.

À l’inverse, des cas simples peuvent créer rapidement de la valeur avec un risque limité :

• synthèse de documents internes non sensibles ;
• aide à la rédaction avec données anonymisées ;
• classification de demandes sans décision automatique ;
• génération de brouillons validés par un humain ;
• recherche documentaire sur une base maîtrisée ;
• automatisation de tâches administratives avec données minimisées.

Cette logique doit être intégrée à votre roadmap IA pour PME, afin de prioriser les projets selon la valeur métier, la faisabilité technique et le niveau de risque.

Une méthode simple pour cadrer vos usages IA en 2026

Voici une approche pragmatique en 7 étapes.

Étape 1 : cartographier les usages IA

Listez les usages existants et envisagés.

Pour chaque usage, documentez :

• métier concerné ;
• objectif ;
• outil utilisé ;
• données en entrée ;
• données produites ;
• utilisateurs ;
• fournisseurs ;
• automatisations connectées ;
• niveau d’autonomie ;
• exposition externe ou interne.

Incluez les usages non officiels. Ce sont souvent les plus importants à traiter.

Étape 2 : qualifier les données

Classez les données manipulées :

• données non personnelles ;
• données personnelles courantes ;
• données sensibles au sens RGPD ;
• données RH ;
• données clients ;
• données financières ;
• données confidentielles métier ;
• données couvertes par un secret contractuel.

Cette qualification aide à définir les règles d’usage.

Par exemple :

• autorisé sans restriction particulière ;
• autorisé avec anonymisation ;
• autorisé uniquement dans un outil validé ;
• interdit dans les outils externes ;
• soumis à validation DPO ou juridique ;
• soumis à AIPD.

Étape 3 : classer le risque IA Act

Pour chaque système IA, identifiez s’il peut relever :

• d’une pratique interdite ;
• d’un système à haut risque ;
• d’une obligation de transparence ;
• d’un usage à risque limité.

Si vous utilisez l’IA dans les RH, l’évaluation de personnes, l’accès à des services, la solvabilité ou des domaines réglementés, ne vous contentez pas d’une auto-évaluation rapide.

Faites valider l’analyse.

Étape 4 : définir des règles internes simples

Une politique IA efficace doit être compréhensible.

Évitez les documents trop longs que personne ne lit.

Commencez par des règles claires :

• quelles données ne jamais saisir dans un outil public ;
• quels outils sont autorisés ;
• quels usages nécessitent validation ;
• comment anonymiser un document ;
• qui contacter en cas de doute ;
• comment signaler une erreur ou une fuite ;
• quand une validation humaine est obligatoire ;
• comment utiliser les prompts partagés ;
• quels connecteurs no-code sont approuvés.

Ajoutez des exemples métiers.

Un commercial, une assistante RH et un responsable finance ne manipulent pas les mêmes données. Les règles doivent parler leur langage.

Étape 5 : sécuriser l’architecture

Pour un système IA plus avancé, vérifiez l’architecture.

Points clés :

• gestion des accès ;
• séparation des environnements test et production ;
• chiffrement si nécessaire ;
• journalisation ;
• suppression des données ;
• limitation des exports ;
• droits des connecteurs ;
• filtrage des documents dans un RAG ;
• validation humaine sur les actions sensibles ;
• supervision des agents IA ;
• plan de gestion des incidents.

Dans un workflow no-code, documentez chaque étape du scénario. Une automatisation peut paraître simple visuellement, mais faire circuler des données personnelles entre plusieurs services.

Étape 6 : former les utilisateurs

La conformité IA repose autant sur les comportements que sur la technologie.

Les utilisateurs doivent savoir :

• ce qu’ils peuvent faire ;
• ce qu’ils ne doivent pas faire ;
• comment vérifier une réponse IA ;
• comment rédiger un prompt sans exposer de données ;
• quand utiliser un outil validé ;
• quand demander une validation ;
• comment détecter une réponse inventée ;
• comment garder une trace des décisions importantes.

Les formations doivent être courtes, concrètes et adaptées aux métiers.

Un atelier de deux heures avec des cas réels anonymisés peut parfois être plus utile qu’un long module théorique.

Étape 7 : mettre en place une gouvernance légère

La gouvernance IA n’a pas besoin d’être lourde.

Pour une PME ou une ETI, un comité restreint peut suffire :

• direction ;
• métier ;
• DSI ou responsable outils ;
• DPO ou référent RGPD ;
• juridique si disponible ;
• responsable opérationnel du cas d’usage.

Son rôle :

• valider les usages sensibles ;
• prioriser les projets ;
• suivre les incidents ;
• maintenir la politique IA ;
• arbitrer les outils ;
• suivre les évolutions réglementaires ;
• mesurer les gains et les risques.

L’objectif est d’éviter deux extrêmes : le blocage total et le laisser-faire.

Exemples concrets de cadrage par cas d’usage

Voici comment raisonner sur quelques cas fréquents.

Cas 1 : synthèse de réunions internes

Usage : un outil transcrit et résume des réunions.

Risques :

• présence de données personnelles ;
• sujets RH ou confidentiels ;
• conservation des enregistrements ;
• accès aux comptes rendus ;
• information des participants.

Bonnes pratiques :

• informer les participants ;
• éviter l’enregistrement automatique par défaut ;
• limiter la conservation ;
• désactiver l’usage des données pour entraînement si applicable ;
• restreindre l’accès aux comptes rendus ;
• éviter les réunions sensibles sans validation préalable.

Cas 2 : chatbot interne sur documentation RH

Usage : un assistant répond aux questions des salariés sur les congés, notes de frais, procédures internes.

Risques :

• réponses erronées ;
• accès à des documents non publics ;
• confusion entre information générale et décision RH ;
• logs contenant des questions personnelles.

Bonnes pratiques :

• connecter uniquement les documents validés ;
• afficher que l’outil fournit une aide, pas une décision ;
• prévoir un contact RH ;
• limiter les logs ;
• tester les réponses ;
• gérer les droits d’accès ;
• mettre à jour les sources.

Cas 3 : aide à la réponse client

Usage : un LLM génère un brouillon de réponse à partir d’un ticket support.

Risques :

• transmission de données client ;
• réponse inexacte ;
• ton inadapté ;
• divulgation d’informations internes ;
• conservation de données dans l’outil.

Bonnes pratiques :

• minimiser le contenu transmis ;
• masquer les données inutiles ;
• imposer une validation humaine ;
• journaliser les actions ;
• utiliser des modèles de réponse contrôlés ;
• éviter l’envoi automatique sans garde-fou.

Pour des idées de départ à risque modéré, vous pouvez consulter des cas d’usage concrets de ChatGPT et Claude en entreprise, puis les adapter avec vos contraintes RGPD.

Cas 4 : tri de candidatures

Usage : un système classe ou filtre des CV.

Risques :

• discrimination ;
• données sensibles ;
• décision automatisée ;
• usage RH potentiellement à haut risque ;
• manque d’explicabilité ;
• contestation par les candidats.

Bonnes pratiques :

• analyse juridique préalable ;
• AIPD si nécessaire ;
• validation humaine réelle ;
• critères documentés ;
• test des biais ;
• information des candidats ;
• limitation des données ;
• contrôle régulier des résultats.

Ce type de cas n’est pas un bon premier projet IA si l’entreprise n’a pas encore de gouvernance claire.

Cas 5 : agent IA connecté au CRM

Usage : un agent IA enrichit des fiches, prépare des relances et crée des tâches commerciales.

Risques :

• accès trop large aux données clients ;
• erreurs de qualification ;
• emails envoyés par erreur ;
• données obsolètes ;
• actions non traçables ;
• connecteurs mal sécurisés.

Bonnes pratiques :

• limiter les droits de l’agent ;
• commencer par des recommandations, pas des actions automatiques ;
• valider les emails avant envoi ;
• journaliser les modifications ;
• tester sur un périmètre réduit ;
• définir un responsable métier ;
• prévoir un mécanisme d’arrêt.

La checklist conformité IA pour dirigeants

Avant de déployer un usage IA, posez ces questions.

Données

• Quelles données sont utilisées ?
• Contiennent-elles des données personnelles ?
• Sont-elles sensibles ou confidentielles ?
• Peut-on les anonymiser ou les réduire ?
• Où sont-elles stockées ?
• Combien de temps sont-elles conservées ?

RGPD

• Quelle est la finalité du traitement ?
• Quelle est la base légale ?
• Les personnes sont-elles informées ?
• Le traitement est-il inscrit au registre ?
• Une AIPD est-elle nécessaire ?
• Les droits des personnes peuvent-ils être exercés ?
• Le fournisseur est-il encadré contractuellement ?

IA Act

• L’usage relève-t-il d’une pratique interdite ?
• Peut-il être qualifié de haut risque ?
• Y a-t-il une obligation de transparence ?
• Les utilisateurs sont-ils formés ?
• Une supervision humaine est-elle prévue ?
• Le système est-il documenté ?

Sécurité et opérationnel

• Qui a accès à quoi ?
• Les connecteurs sont-ils maîtrisés ?
• Les logs sont-ils utiles et proportionnés ?
• Les réponses sont-elles vérifiées ?
• Que se passe-t-il en cas d’erreur ?
• Qui est responsable du suivi ?
• Le cas d’usage est-il encore pertinent après quelques mois ?

Ce que Processia recommande pour avancer sans bloquer

La bonne approche n’est pas de rédiger une politique IA pendant six mois avant de tester quoi que ce soit.

La bonne approche consiste à avancer par niveaux.

Niveau 1 : autoriser des usages simples et encadrés

Exemples :

• reformulation de textes non sensibles ;
• synthèse de documents internes validés ;
• aide à la rédaction ;
• génération d’idées ;
• préparation de comptes rendus anonymisés.

Objectif : créer une culture IA sans exposer de données sensibles.

Niveau 2 : industrialiser des workflows à risque maîtrisé

Exemples :

• tri de demandes entrantes ;
• préparation de réponses support ;
• automatisation de reporting ;
• extraction de données sur documents standardisés ;
• RAG sur base documentaire contrôlée.

Objectif : connecter l’IA aux processus métiers avec supervision.

Niveau 3 : traiter les cas sensibles avec gouvernance renforcée

Exemples :

• RH ;
• scoring ;
• décision automatisée ;
• données sensibles ;
• agent IA autonome ;
• traitement à grande échelle.

Objectif : évaluer précisément les risques, impliquer les bons interlocuteurs et documenter les choix.

Cette progression permet d’associer transformation digitale, retour sur investissement attendu et conformité. Elle évite de mettre tous les cas d’usage dans le même panier.

Si votre entreprise ne sait pas par où commencer, une démarche structurée comme commencer sa transformation IA en 2026 aide à passer d’une liste d’idées à un plan d’action réaliste.

Le rôle de Processia dans un projet IA conforme

Processia accompagne les PME et ETI dans l’intégration concrète de l’IA et de l’automatisation dans les processus métiers.

L’objectif n’est pas de remplacer votre DPO, votre avocat ou votre responsable conformité.

L’objectif est de concevoir des usages IA techniquement maîtrisés, opérationnellement utiles et compatibles avec vos contraintes internes.

Concrètement, cela peut inclure :

• cartographie des cas d’usage IA ;
• analyse des flux de données ;
• priorisation selon valeur et risque ;
• conception de workflows no-code ou IA ;
• cadrage des agents IA ;
• mise en place de RAG documentaire ;
• définition de règles d’usage ;
• formation des équipes ;
• documentation opérationnelle ;
• coordination avec vos interlocuteurs RGPD et juridiques.

La conformité ne doit pas arriver à la fin du projet. Elle doit être intégrée dès le cadrage, au même titre que le budget, les outils, les utilisateurs et le retour sur investissement visé.

FAQ : RGPD et IA en 2026

Le RGPD interdit-il d’utiliser ChatGPT, Claude ou d’autres LLM en entreprise ?

Non, le RGPD n’interdit pas l’usage des LLM en entreprise.

Il impose de maîtriser les données personnelles traitées : finalité, base légale, information, sécurité, minimisation, sous-traitance, conservation et droits des personnes.

Le vrai sujet est donc le contexte d’usage. Utiliser un LLM pour reformuler un texte non sensible n’a pas le même niveau de risque que lui transmettre des données RH ou des dossiers clients.

Peut-on envoyer des données personnelles dans un outil IA ?

C’est possible dans certains cas, mais pas sans cadre.

Il faut vérifier la finalité, la base légale, le contrat avec le fournisseur, les paramètres de confidentialité, la localisation des données, la durée de conservation, les droits des personnes et les mesures de sécurité.

Pour des données sensibles ou des traitements à risque, demandez une validation DPO ou juridique.

L’anonymisation suffit-elle pour être conforme ?

Une vraie anonymisation peut réduire fortement les obligations RGPD, car les données ne permettent plus d’identifier une personne.

Mais en pratique, beaucoup d’entreprises font plutôt de la pseudonymisation : elles remplacent un nom par un identifiant, mais une réidentification reste possible.

La pseudonymisation est utile, mais le RGPD continue généralement de s’appliquer.

Un RAG est-il plus conforme qu’un fine-tuning ?

Pas automatiquement.

Un RAG peut faciliter le contrôle des sources, des accès et des mises à jour, car les documents restent dans une base maîtrisée. Mais il traite quand même des données, parfois personnelles.

Le fine-tuning peut poser des questions plus complexes sur les données d’entraînement, la suppression, la restitution potentielle d’informations et la base légale.

Le bon choix dépend du cas d’usage, des données et de l’architecture.

Faut-il une politique IA interne en 2026 ?

Oui, c’est fortement recommandé.

Une politique IA permet d’éviter les usages sauvages, de clarifier les outils autorisés, de protéger les données sensibles et de donner aux collaborateurs des règles simples.

Elle doit être courte, concrète et accompagnée d’exemples métiers.

Les PME sont-elles vraiment concernées par l’IA Act ?

Oui.

L’IA Act ne concerne pas seulement les grands groupes ou les éditeurs de modèles. Une PME qui utilise un système IA peut avoir des obligations, notamment si elle l’utilise dans un contexte à haut risque ou face à des clients, salariés ou candidats.

Le niveau d’obligation dépend du rôle de l’entreprise et de l’usage.

Une validation humaine suffit-elle à éviter les risques ?

Non.

La validation humaine doit être réelle. La personne doit comprendre la recommandation, disposer d’informations suffisantes, pouvoir corriger le résultat et avoir la possibilité effective de ne pas suivre l’IA.

Si l’humain valide mécaniquement toutes les propositions, le contrôle est faible.

Quelle est la première action à mener ?

Commencez par cartographier les usages IA existants.

Identifiez les outils utilisés, les données traitées, les métiers concernés et les risques évidents.

Ensuite, définissez trois niveaux : usages autorisés, usages encadrés, usages sensibles soumis à validation. C’est souvent un point de départ efficace pour avancer sans bloquer l’innovation.