Pour autoriser Claude en entreprise, le DPO et le RSSI doivent pouvoir rattacher leur décision à un usage, un compte et une configuration précis. Une réponse générale sur la conformité du fournisseur ne dit pas quelles pièces les salariés pourront joindre, qui accédera aux conversations ou ce qui restera après la suppression d’un projet. Le bon livrable est donc un dossier de validation limité à un scénario observable, avec les preuves disponibles et les questions encore ouvertes.
Cette méthode concerne une utilisation professionnelle de Claude Enterprise ou de l’API. Elle complète le cadre général du RGPD appliqué à l’intelligence artificielle par une revue d’exploitation. Les faits relatifs à Anthropic ci-dessous ont été vérifiés dans sa documentation publique le 5 septembre 2026. Ils doivent être rapprochés de l’offre effectivement souscrite : aucun accès à un compte client ni audit du fournisseur n’a été réalisé pour cet article.
Commencer par une décision suffisamment précise
« Autoriser Claude » donne une permission difficile à contrôler. « Permettre à six rédacteurs du support de reformuler des réponses préparées, à partir d’extraits expurgés et sans envoi automatique au client » permet de définir des limites vérifiables. La CNIL recommande de partir des besoins, d’encadrer les usages et d’associer les responsables métiers, sécurité et protection des données. Ces recommandations publiées le 18 juillet 2024 fournissent un point de départ pour la gouvernance du déploiement.
La première page du dossier précise l’équipe bénéficiaire, le résultat recherché, la catégorie de personnes concernées et la décision que le système pourra influencer. Indiquez aussi les usages exclus du scénario : recrutement, analyse médicale, évaluation des salariés ou traitement de dossiers contentieux, par exemple. Il s’agit des limites choisies pour cette autorisation, pas d’une affirmation selon laquelle ces activités seraient toutes interdites par le RGPD.
Attribuez un identifiant à la décision. Cet identifiant reliera ensuite la fiche application, le traitement concerné, les pièces fournisseur et les incidents éventuels. Le responsable métier décrit le besoin ; le RSSI vérifie les mesures techniques ; le DPO apporte son analyse ; la personne habilitée dans l’organisation décide du déploiement. Le dossier conserve leurs contributions distinctes.
Identifier le service et le chemin suivi par les données
La dénomination du modèle ne suffit pas. Un navigateur connecté à un espace Enterprise, un appel direct à l’API et un modèle accessible au travers d’un fournisseur cloud constituent des chemins différents. La documentation API d’Anthropic distingue elle-même ces circuits. Le dossier doit préciser celui que l’équipe utilise réellement, ainsi que les fonctions autorisées et le modèle ou la famille de modèles retenus.
| Élément à relever | Preuve à conserver | Question résolue |
|---|---|---|
| Offre et entité contractante | Commande, conditions applicables, identifiant d’organisation | Quel service est couvert par l’achat ? |
| Interface et authentification | Capture des paramètres, procédure de connexion | Les salariés entrent-ils dans le bon espace ? |
| Modèles et fonctions | Liste datée des options permises | Une nouvelle fonction dépasse-t-elle la revue ? |
| Sources de documents | Inventaire des dossiers et connecteurs autorisés | Que peut réellement lire le système ? |
| Destinations des résultats | Schéma du parcours, droits d’accès | Qui peut recevoir ou republier une réponse ? |
Dessinez le trajet d’un seul document : application métier, préparation de l’extrait, transmission, conversation ou appel API, réponse, stockage interne. Ajoutez les copies moins visibles, comme les journaux applicatifs, les pièces envoyées au support ou les exports réalisés par les utilisateurs. La minimisation des données se vérifie à chacune de ces étapes.
Un connecteur mérite une ligne propre. Son existence dans un catalogue ne démontre ni qu’il est activé dans votre compte, ni que les droits sont correctement repris. Vérifiez avec un document fictif inaccessible au compte de contrôle que ce document ne peut pas être récupéré. Conservez le résultat observé et les conditions de l’essai ; une capture de l’écran de configuration seule ne démontre pas cette séparation.
Rapprocher les engagements des données réellement envoyées
Le DPA public d’Anthropic, effectif au 24 février 2025, qualifie Anthropic de sous-traitant pour les données personnelles du client relevant de son périmètre. Il comporte des dispositions sur les instructions, la sécurité, la sous-traitance ultérieure et les transferts. Cette qualification ne décrit pas automatiquement tous les traitements associés à tout compte ou à toute intégration.
Rapprochez ce document des conditions incorporées à votre achat, puis du schéma de traitement. Pour chaque groupe de données, notez la finalité, le responsable, les destinataires et le document justificatif. Les vérifications de l’article 28 du RGPD s’effectuent sur cet ensemble. Une pièce présente mais applicable à une autre offre reste une question ouverte.
La localisation de l’hébergement constitue également une information de périmètre. Pour instruire les transferts de données hors de l’Union européenne, distinguez stockage, traitement, assistance et accès d’administration. Notez les pays, les entités concernées et le mécanisme invoqué pour chaque flux pertinent. Évitez de conclure « aucun transfert » à partir du seul nom d’une région cloud.
Vérifier la conservation par objet et par fonction
Selon la politique de conservation commerciale d’Anthropic, datée du 1er juillet 2026, les entrées et sorties API sont normalement supprimées du système du fournisseur sous trente jours, avec des exceptions, notamment pour certains services, accords particuliers, besoins de sécurité et obligations légales. Les conversations conservées dans les autres produits commerciaux suivent un fonctionnement différent.
La documentation des réglages Enterprise, datée du 16 mars 2026, décrit une conservation personnalisable, avec un minimum de trente jours et un point de départ lié à la dernière activité. Elle indique une conservation indéfinie par défaut si aucune durée personnalisée n’est fixée. Vérifiez ces paramètres dans l’espace concerné, y compris leur interaction entre projets et conversations.
Enfin, la documentation API sur la conservation précise les conditions du Zero Data Retention, son activation et l’éligibilité des fonctions et modèles. Elle annonce l’absence d’entraînement sur les données conservées sans permission expresse. Cette indication ne signifie pas qu’aucune donnée n’est conservée ; les exceptions et fonctions avec état doivent être examinées séparément.
Construisez une liste comprenant au minimum les prompts, réponses, fichiers, contenus de projets, journaux de votre application et copies exportées. Pour chaque objet, renseignez le déclencheur du délai, la durée choisie, le mécanisme de suppression et la preuve obtenue. Rattachez les choix à votre politique de conservation. Une durée courte chez le fournisseur ne corrige pas un export interne conservé sans justification.
Exemple fictif : assistance à la rédaction du support
Une entreprise fictive souhaite aider six personnes à reformuler les réponses de son support. Le besoin consiste à améliorer la clarté de textes déjà préparés. Il n’inclut ni la recherche dans l’ensemble des dossiers clients, ni l’évaluation de leur comportement. Le responsable choisit un premier périmètre sans connecteur : seuls des extraits préparés manuellement peuvent être saisis.
L’équipe découvre qu’un ticket contient souvent un nom, une adresse électronique, un numéro de commande et un historique inutile à la reformulation. Elle prépare alors un exercice avec des identités inventées. Un rédacteur remplace les références par des repères temporaires avant la saisie ; il rétablit les références nécessaires dans l’application support, après relecture. Le brouillon produit par Claude ne déclenche aucun envoi.
| Observation fictive | Décision du projet | Preuve attendue avant ouverture |
|---|---|---|
| Un ticket entier révèle l’historique d’achat | Ne transmettre que le passage à reformuler | Comparaison entre ticket fictif et extrait préparé |
| Une réponse invente un engagement commercial | Relecture par le rédacteur avant envoi | Exemple corrigé avec motif de correction |
| Un utilisateur rejoint un espace personnel | Réserver le parcours au compte professionnel validé | Contrôle du parcours de connexion |
| La conservation du projet n’est pas renseignée | Faire configurer puis relever le réglage retenu | Capture datée et référence de configuration |
| Une pièce sensible apparaît dans un ticket | Sortir ce ticket du scénario autorisé | Consigne et essai d’escalade interne |
Ces résultats ne constituent pas une mesure de performance de Claude. Ils illustrent les questions que ce projet doit résoudre. Une seconde équipe souhaitant analyser automatiquement tous les tickets aurait un autre périmètre de données et une autre revue. Elle ne pourrait pas réutiliser la décision comme une autorisation générale.
Examiner les risques qui demeurent après la configuration
L’expurgation manuelle peut échouer. Une réponse peut produire une information inexacte sur une personne. Un salarié peut exporter un résultat dans un espace plus ouvert. Décrivez chaque risque avec un scénario, une mesure et une manière de constater son fonctionnement. Le dossier sera plus utile avec trois risques expliqués qu’avec une longue liste de menaces sans lien avec l’usage.
L’analyse de la nécessité d’une AIPD porte sur le traitement envisagé et son risque pour les personnes ; la seule présence d’une IA ne tranche pas cette question. Notez les critères examinés et les raisons de la conclusion. Si les données, les destinataires ou les décisions influencées changent, reprenez cette analyse.
La PSSI doit aussi fournir les règles applicables aux comptes, aux postes et à l’assistance. Prévoyez un exercice de signalement : un utilisateur saisit fictivement une information exclue et doit retrouver le bon contact. Le responsable doit savoir identifier la conversation, limiter sa diffusion et instruire l’événement, sans recopier les données dans plusieurs tickets.
Clore le dossier sans masquer les réserves
La fiche de décision réunit un périmètre versionné, les pièces consultées, les réglages observés, les essais réalisés, les réserves et leurs responsables. Pour chaque réserve, indiquez son effet : empêche-t-elle l’ouverture, limite-t-elle un usage ou justifie-t-elle une vérification ultérieure ? Une absence de réponse sur un flux de données ne devient pas une preuve positive parce que la date de lancement approche.
Avant de proposer l’ouverture, vérifiez les points suivants :
- Le besoin et les usages exclus sont compris par les utilisateurs concernés.
- L’offre, l’organisation, les fonctions et les modèles autorisés sont identifiés.
- Chaque catégorie de données dispose d’une finalité et d’une analyse juridique documentées.
- Les pièces de sous-traitance et de transfert correspondent au circuit réel.
- Les durées des conversations, fichiers et copies internes sont expliquées.
- Les accès et la préparation des données ont fait l’objet d’essais fictifs documentés.
- Les sorties sont relues et leur destination est maîtrisée.
- Le parcours d’incident et les personnes habilitées à décider sont connus.
- Les réserves possèdent un responsable et une condition de résolution observable.
- La décision précise les événements qui imposent son réexamen.
Dans votre outil de conformité, reliez cette fiche au registre des traitements, à l’application et au dossier fournisseur. Conservez les références des pièces sensibles dans un emplacement dont l’accès est maîtrisé. L’objectif est qu’un changement de connecteur, de modèle ou de conservation permette de retrouver rapidement les décisions concernées, sans refaire l’ensemble de l’analyse ni perdre les limites initiales.