ATALAS LE BLOG
Documents clients et IA : le protocole à appliquer avant le premier test

Documents clients et IA : le protocole en huit étapes pour vérifier les droits, réduire les données et tester un usage sans transfert incontrôlé.
La mention « vos données ne servent pas à l’entraînement » ne suffit pas à autoriser l’envoi d’un document client à une IA. Elle ne dit pas, à elle seule, combien de temps le contenu est conservé, qui peut y accéder, où il est traité, quelles fonctions le recopient ni si votre contrat avec le client permet ce traitement.
La bonne décision ne consiste donc pas à choisir entre « tout interdire » et « tout envoyer ». Elle consiste à appliquer un protocole : définir la tâche, classer le document, vérifier les droits et le contrat, choisir un environnement approuvé, réduire les données, tester sur un échantillon contrôlé, puis conserver une preuve de la décision.
Peut-on transmettre un document client à une IA ?
Par défaut, non, tant que cinq questions n’ont pas reçu une réponse explicite :
- Quelle tâche précise doit être réalisée ? Résumer un contrat n’expose pas aux mêmes risques que décider si un client peut être accepté.
- Quelles informations contient le document ? Données personnelles, secret des affaires, prix négociés, architecture informatique, informations financières, santé, identifiants ou clés d’accès n’appellent pas le même traitement.
- Avez-vous le droit de confier ces informations à ce prestataire ? Le contrat client, les engagements de confidentialité, les règles sectorielles et le RGPD peuvent limiter le transfert ou imposer des garanties.
- Quel produit exact va traiter le document ? Un compte grand public, un espace professionnel administré et une API sous contrat ne présentent ni les mêmes réglages ni les mêmes engagements.
- Que devient le contenu après le traitement ? Il faut connaître la durée de conservation, les possibilités de suppression, les sous-traitants, les transferts, les journaux et les fonctions qui peuvent réutiliser le contenu.
La CNIL recommande de ne soumettre que des informations que l’utilisateur est autorisé à partager et de ne jamais envoyer d’informations confidentielles à un service grand public. L’ANSSI indique de son côté qu’envoyer un document à un service d’IA sur Internet revient à le déposer sur un espace contrôlé par le prestataire. Le point de départ raisonnable est donc l’absence d’autorisation, jusqu’à ce que le cadre soit vérifié.
La règle essentielle : « pas d’entraînement » ne signifie pas « pas de risque »
Les offres professionnelles d’OpenAI et d’Anthropic indiquent que les données de leurs clients commerciaux ne servent pas, par défaut, à entraîner leurs modèles. C’est une garantie importante, mais elle ne répond pas à toutes les questions.
Un contenu peut ne pas être utilisé pour l’entraînement tout en étant :
- conservé pour permettre l’historique d’une conversation ;
- stocké pendant une période définie par le produit ou le contrat ;
- accessible à des fonctions de sécurité, d’assistance ou de conformité ;
- copié dans un projet, un connecteur, un fichier ou une conversation partagée ;
- transmis avec un retour utilisateur ou un signalement de bug ;
- visible par une personne qui dispose d’un accès trop large à l’espace de travail.
Anthropic précise, par exemple, que les entrées et sorties de son API commerciale sont normalement supprimées de ses systèmes dans les trente jours, avec plusieurs exceptions, tandis que les conversations enregistrées dans ses produits de travail restent conservées pour fournir le service. OpenAI distingue également les contrôles de conservation selon les produits et les organisations éligibles.
La question de direction n’est donc pas seulement : « Le modèle apprend-il avec nos données ? » Elle est : « Quel parcours complet suit ce document, de l’envoi à la suppression ? »
Un protocole en huit étapes avant le premier test
1. Définir une tâche, pas une intention générale
Écrire « utiliser l’IA sur les contrats » ne permet aucune décision. La tâche doit être délimitée.
Exemples suffisamment précis :
- extraire les dates, montants et obligations d’un contrat fournisseur ;
- comparer un projet de contrat à un référentiel de clauses approuvé ;
- transformer des notes de réunion en une liste de décisions à faire relire ;
- regrouper des tickets de support par thème sans identifier les personnes.
Pour chaque tâche, indiquez la sortie attendue, le responsable, l’utilisateur et la décision qui restera humaine.
2. Classer le document avant de choisir l’outil
Une PME n’a pas besoin d’une taxonomie de quarante niveaux. Quatre catégories opérationnelles suffisent pour commencer :
| Catégorie interne | Exemple | Règle de départ |
|---|---|---|
| Public | brochure publiée, page du site, communiqué | test possible dans un outil approuvé |
| Interne courant | procédure non sensible, modèle de compte rendu | test limité aux utilisateurs autorisés |
| Confidentiel | contrat, prix, dossier client, prévision, code propriétaire | environnement professionnel validé et minimisation obligatoires |
| Très sensible | identifiants, secrets, données de santé, données bancaires détaillées, information classifiée | aucun test standard ; analyse spécifique de sécurité et de conformité |
Cette grille n’est pas une qualification juridique. Elle sert à empêcher qu’un collaborateur décide seul, au moment du copier-coller, de la sensibilité du document.
3. Vérifier les droits et les engagements pris envers le client
Avant tout test, retrouvez :
- la clause de confidentialité ;
- les éventuelles restrictions de sous-traitance ;
- le rôle de votre entreprise au regard des données personnelles ;
- les exigences de localisation ou de sécurité ;
- les règles propres au secteur ;
- la procédure d’autorisation interne.
Si le contrat interdit un nouveau sous-traitant, si le client impose un hébergement précis ou si le traitement change la finalité initiale des données, un abonnement professionnel ne crée pas l’autorisation manquante.
Le bon réflexe consiste à désigner une personne qui tranche : DPO, responsable juridique, DSI, RSSI ou dirigeant selon la taille de l’entreprise. L’utilisateur final ne doit pas interpréter seul le contrat client.
4. Vérifier le produit exact, pas seulement le nom du fournisseur
« Nous utilisons ChatGPT » ou « nous utilisons Claude » ne suffit pas. La fiche de validation doit préciser :
- le plan et le produit ;
- le titulaire du contrat ;
- le compte ou l’espace de travail utilisé ;
- l’état des réglages d’entraînement et de retour utilisateur ;
- la conservation standard et les options disponibles ;
- le lieu de stockage et de traitement lorsqu’il est contractuellement pertinent ;
- les droits d’administration et de partage ;
- les connecteurs activés ;
- le mécanisme de suppression ;
- le DPA et les sous-traitants applicables.
Un compte personnel utilisé au travail ne devient pas un environnement contrôlé parce que l’adresse email appartient à l’entreprise.
5. Réduire les données avant de les transmettre
L’objectif n’est pas de masquer quelques noms tout en laissant le reste du dossier reconnaissable. Il faut conserver uniquement ce qui est nécessaire à la tâche.
Pour une revue de contrat, on peut remplacer :
- le nom du client par « Client A » ;
- les personnes par leur fonction ;
- les adresses, signatures et coordonnées par des marqueurs ;
- les montants exacts par des fourchettes si la tâche ne dépend pas du prix ;
- les annexes techniques par les seuls extraits utiles ;
- les références internes par des identifiants temporaires.
La réduction doit être testée : une combinaison de secteur, ville, montant et date peut suffire à réidentifier un client même si son nom a disparu.
6. Préparer un jeu de test contrôlé
Le premier test ne doit pas utiliser le dossier le plus sensible ni un lot de centaines de documents. Préparez plutôt :
- un document synthétique qui reprend la structure réelle ;
- un ou deux documents historiques expurgés ;
- une liste des réponses attendues ;
- des pièges connus : clause absente, date contradictoire, information illisible ;
- une grille d’évaluation.
Mesurez la fidélité de l’extraction, les omissions, les affirmations sans source, le temps de relecture et la capacité à retrouver le passage d’origine. Une réponse élégante mais impossible à rattacher au document doit être rejetée.
7. Imposer une relecture et une traçabilité proportionnées
Le test doit conserver :
- la version du document ou son identifiant interne ;
- la version du protocole ;
- le produit et l’espace utilisés ;
- la consigne envoyée ;
- la sortie obtenue ;
- la personne qui a relu ;
- la décision prise ;
- la date de suppression prévue.
Pour une synthèse interne, une relecture métier peut suffire. Pour une clause contractuelle, une recommandation de conformité ou une décision concernant une personne, la validation doit rester entre les mains du responsable compétent.
8. Décider explicitement de la suite
À la fin du test, trois décisions sont possibles :
- arrêt : le risque, le coût de contrôle ou l’imprécision rendent l’usage inutile ;
- nouveau test : la valeur est plausible, mais les garanties ou les résultats doivent être améliorés ;
- mise en service limitée : le périmètre, les utilisateurs, les données autorisées, les contrôles et la condition d’arrêt sont formalisés.
Ne passez pas directement d’une démonstration réussie à une ouverture pour toute l’entreprise. Une mise en service ajoute des sujets d’accès, de volume, de surveillance et de formation qui n’existaient pas pendant le test.
Trois exemples de décision
Un commercial veut résumer un appel d’offres client
Le document contient des prix, des noms et des exigences techniques. Le commercial ne doit pas le déposer dans son compte personnel. L’entreprise peut préparer une copie expurgée, la traiter dans un espace professionnel validé et limiter la sortie à une extraction des exigences, avec lien vers les pages sources. La décision de répondre et les engagements proposés restent humains.
Le support veut analyser cent tickets
Les tickets contiennent des emails, numéros de commande et descriptions parfois personnelles. L’équipe doit retirer les identifiants directs, réduire les textes aux passages nécessaires et vérifier qu’un regroupement statistique suffit. Si le besoin porte seulement sur les thèmes récurrents, l’IA n’a pas besoin de connaître l’identité du client.
Le juridique veut comparer un contrat au modèle de l’entreprise
Le document est confidentiel et sa mauvaise interprétation peut créer un engagement. Le test peut être pertinent dans un environnement validé, avec un référentiel de clauses versionné et une sortie qui cite systématiquement le passage analysé. L’IA prépare un écart ; le juriste qualifie le risque et décide de la rédaction.
Les prérequis minimaux
Avant d’autoriser le premier document client, l’entreprise doit disposer de six éléments :
- un propriétaire du protocole ;
- une liste courte d’outils et d’espaces approuvés ;
- une classification simple des documents ;
- une fiche de validation du produit et du contrat ;
- une règle de minimisation et de suppression ;
- un responsable humain pour chaque type de sortie.
L’article 4 du règlement européen sur l’IA demande aux fournisseurs et aux déployeurs de soutenir le développement des connaissances de leurs équipes sur les systèmes qu’elles utilisent. La Commission européenne recommande une approche adaptée aux rôles, aux risques et au contexte. Une formation générique à l’art du prompt ne remplace donc pas l’apprentissage des données autorisées, des limites et des contrôles.
Les limites à reconnaître
Ce protocole ne remplace pas une analyse juridique, de sécurité ou sectorielle lorsque le document contient des données particulièrement sensibles.
Il ne garantit pas non plus qu’un contenu expurgé soit anonyme, qu’un fournisseur respecte une exigence propre à votre client ou qu’une sortie soit exacte. La CNIL rappelle que les modèles génératifs produisent des réponses probabilistes et peuvent formuler des erreurs plausibles.
Enfin, une architecture plus sécurisée ne corrige pas un mauvais usage. Si la tâche n’est pas définie, si personne ne relit ou si la décision est automatiquement déléguée, l’entreprise déplace le risque sans créer de valeur.
La décision du dirigeant
Le bon cadre tient en une phrase :
Aucun document client n’entre dans une IA tant que la tâche, l’autorisation, l’environnement, la réduction des données, la relecture et la suppression ne sont pas définis.
Cette règle ralentit le premier copier-coller. Elle accélère ensuite les bons usages, parce que les équipes savent ce qui est possible, où travailler et qui tranche.
Sources
- CNIL — Les questions-réponses sur l’utilisation d’un système d’IA générative, publiée le 18 juillet 2024, consultée le 2 novembre 2026.
- ANSSI — Recommandations de sécurité pour un système d’IA générative, version 1.0 du 29 avril 2024, consultée le 2 novembre 2026.
- Commission européenne — Alphabétisation à l’IA, questions et réponses, consultée le 2 novembre 2026.
- OpenAI — Business data privacy, security and compliance, consultée le 2 novembre 2026.
- Anthropic — Is my data used for model training?, publiée le 18 août 2026, consultée le 2 novembre 2026.
- Anthropic — How long do you store my organization’s data?, publiée le 1er juillet 2026, consultée le 2 novembre 2026.
- ClaudIn — Blog Claude Cowork : guides et actualités, veille éditoriale consultée le 2 novembre 2026. Les thèmes liés aux documents métier, à la conformité et aux guides pratiques ont éclairé le choix de la question ; les règles et faits de cet article sont vérifiés dans les sources primaires ci-dessus.