Utiliser ChatGPT au travail sans exposer les données de l'entreprise

Utiliser ChatGPT au travail peut faire gagner du temps sur une synthèse, une reformulation, un plan de réunion ou une première analyse. Le risque commence quand l’outil reçoit des informations que l’entreprise ne mettrait jamais dans un e-mail externe : contrats, chiffres internes, fichiers clients, code propriétaire, incidents de sécurité ou documents RH.

La bonne question n’est donc pas “faut-il interdire ChatGPT ?”. Pour une PME, elle est plus concrète : quelles données peuvent sortir, avec quel compte, pour quel usage, sous quel contrôle et avec quelle validation humaine. Sans ce cadre, l’IA devient un raccourci pratique mais imprudent.

Un assistant IA n’est pas un collègue. C’est un service externe qui doit être traité comme tel.

Classer les données avant de parler d’outil

Tout commence par une question simple : que contient vraiment le document ? La réponse décide du niveau de prudence.

Le premier réflexe doit être la classification. Une demande générique comme “résume ce texte” ne dit rien du risque réel. Le texte peut contenir un nom de client, une stratégie commerciale, un identifiant technique, une clause contractuelle, une donnée de santé ou un élément RH. Ce n’est pas le prompt qui est dangereux en soi, c’est ce qu’il transporte, surtout quand le collaborateur ne voit plus le document comme un actif de l’entreprise mais comme une simple matière à reformuler.

Pour une PME, trois niveaux suffisent souvent au départ. Les informations publiques ou déjà validées peuvent être utilisées plus facilement. Les informations internes doivent être résumées ou anonymisées. Les informations sensibles, réglementées ou stratégiques doivent rester interdites sans validation spécifique. Cette simplicité aide les équipes à décider vite sans transformer chaque prompt en débat juridique, et elle évite surtout de mélanger dans la même règle une plaquette commerciale publique, un devis en cours et un dossier RH.

Cette grille simple évite les décisions au cas par cas dans l’urgence. Un collaborateur sait quoi faire avec une fiche produit publique, une note de réunion interne ou un contrat client. La zone grise devient plus petite, donc plus facile à escalader vers un responsable, sans bloquer les usages de rédaction, de synthèse ou de préparation qui ne manipulent aucune donnée sensible.

Le bon test consiste à imaginer que le prompt soit relu demain par un client, un auditeur ou un collaborateur non concerné. Si le contenu serait gênant, trop précis ou impossible à justifier, il ne doit pas partir tel quel. Cette règle de bon sens n’est pas parfaite, mais elle aide les équipes à ralentir avant les copier-coller les plus risqués, surtout dans les petites structures où une information apparemment anodine peut être reliée très vite à une personne ou à un dossier.

Compte personnel, Business ou Enterprise : la différence compte

Le compte utilisé est déjà une décision de sécurité : il détermine qui administre, qui contrôle l’usage et qui coupe l’accès en cas de départ. Un salarié connecté avec un compte personnel, depuis son navigateur, ne donne pas à l’entreprise les mêmes garanties qu’un espace administré. Même si certains réglages de confidentialité existent, ils restent attachés à un compte individuel et ne remplacent pas une politique d’entreprise, ni une revue des accès quand la personne change de poste ou quitte la société.

Les offres Business et Enterprise apportent surtout de la gouvernance : administration centralisée, conditions adaptées aux organisations, gestion des accès, contrôles de sécurité et promesse de non-entraînement par défaut sur les données métier selon la documentation OpenAI. C’est un point important, mais ce n’est pas un feu vert pour coller n’importe quel document dans l’outil. Le cadre interne doit rester plus strict que la possibilité technique, avec un espace approuvé, des règles écrites et une vérification régulière des paramètres réellement activés.

La nuance est essentielle : ne pas entraîner par défaut ne signifie pas “aucun risque opérationnel”. Il reste la confidentialité du document, l’accès des utilisateurs, la conservation selon l’offre, les erreurs de partage, les exports, les captures d’écran, la conformité RGPD et la validation des résultats produits. C’est pourquoi le choix d’une offre business doit s’accompagner d’une règle d’usage, pas la remplacer.

Dans une PME, cette distinction doit être expliquée sans jargon. Les garanties contractuelles et techniques réduisent un risque, elles ne remplacent pas le tri des données. Un outil administré reste mal utilisé si tout le monde y colle des fichiers bruts, et un bon réglage de confidentialité ne corrige pas une réponse envoyée au client sans relecture. Le cadre doit donc parler à la fois d’outil, de comportement et de responsabilité métier.

Ce qu’il ne faut jamais coller tel quel

La liste noire doit être courte, connue et non négociable. Elle protège les cas où l’utilisateur hésite.

La liste noire doit être explicite. Les collaborateurs ne doivent pas deviner si un document est acceptable. Les données clients nominatives, les contrats, les factures, les salaires, les évaluations RH, les tickets d’incident, les mots de passe, les clés API, les exports CRM, les dumps de base de données et le code propriétaire doivent être exclus par défaut. Cette interdiction doit être visible dans l’onboarding, pas seulement dans un document oublié.

Le piège le plus courant est le document mixte. Une note apparemment banale peut contenir une annexe, un identifiant, un nom de prospect ou une clause confidentielle. Copier-coller le bloc complet pour gagner trente secondes crée un risque inutile. Il vaut mieux extraire le besoin : “reformule cette annonce publique”, “structure ce plan”, “propose une checklist générique”. Ce réflexe protège aussi les équipes pressées, car il donne une alternative concrète au partage brut.

Pour le code, la prudence doit être encore plus forte. Un extrait peut révéler une architecture, une vulnérabilité, une clé oubliée, un nom de serveur ou une logique métier. Si l’IA doit aider au développement, préparez un exemple minimal, retirez secrets et noms internes, puis validez la réponse avant toute intégration. La question n’est pas seulement la confidentialité : une suggestion de code non relue peut aussi créer une faille, modifier un comportement métier ou introduire une dépendance que personne ne maintiendra.

La même logique vaut pour les captures d’écran. Elles semblent pratiques, mais elles contiennent souvent beaucoup plus que l’erreur à résoudre : onglets ouverts, URL internes, noms d’utilisateurs, fichiers récents ou tickets en arrière-plan. Avant d’envoyer une image ou un export, il faut regarder les bords, les métadonnées visibles et les informations secondaires. C’est une petite habitude de sécurité, mais elle évite de divulguer l’environnement réel de travail.

Anonymiser ne veut pas dire masquer deux noms

Une donnée peut rester identifiable même sans nom propre. Le contexte suffit parfois à reconnaître le dossier.

L’anonymisation efficace consiste à retirer ce qui permet de reconnaître une personne, un client, un projet ou une stratégie. Remplacer “Dupont” par “Client A” ne suffit pas si le contexte, les montants, les dates et les détails rendent le dossier identifiable. Dans une petite entreprise, le contexte identifie parfois autant que le nom.

Pour approfondir ce point, consultez ChatGPT Desktop entreprise, qui traite plus précisément de chatgpt desktop en entreprise : windows, macos et linux sans faux raccourci.

Une méthode simple fonctionne mieux : réduire, généraliser, remplacer. Réduire le document à l’extrait utile. Généraliser les montants, les dates et les profils. Remplacer les noms, identifiants, adresses, numéros de dossier, références internes et captures d’écran par des placeholders neutres. Ensuite seulement, formuler la demande à l’assistant, avec assez de contexte pour travailler mais pas assez pour reconnaître le dossier réel.

Le bon prompt est souvent celui qui contient moins d’informations, mais une consigne plus claire. Demander “aide-moi à structurer une procédure de relance client B2B” est moins risqué que coller toute la chaîne d’e-mails d’un client réel.

Exemples de prompts plus sûrs

Un prompt sûr n’est pas forcément vague. Il peut donner le rôle, l’objectif, le format attendu et les contraintes, tout en retirant les éléments qui identifient l’entreprise ou ses clients. Cette précision est même souvent meilleure pour le résultat : l’IA comprend la tâche sans recevoir le dossier complet, et l’utilisateur garde la maîtrise du contexte sensible. C’est la différence entre demander une aide de méthode et déléguer un dossier réel.

1. au lieu de coller un contrat, demander une grille de lecture générique des clauses à vérifier ;
2. au lieu de copier un ticket client, résumer le problème sans nom, référence ni identifiant ;
3. au lieu d’envoyer un tableau RH, demander un modèle de plan d’entretien anonyme ;
4. au lieu de publier un extrait de code interne, créer un exemple minimal sans secret ni nom de système ;
5. au lieu d’envoyer une stratégie commerciale, demander une structure de présentation neutre.

Cette méthode demande un petit effort au départ, mais elle crée une habitude saine : l’utilisateur formule d’abord le besoin, puis choisit ce qu’il est réellement nécessaire de partager. Dans beaucoup de cas, l’assistant n’a pas besoin des données exactes pour produire un plan, une trame, une checklist ou une reformulation exploitable. La qualité vient alors de la consigne, pas de l’exposition inutile du dossier source.

Mettre une politique interne utilisable

Une bonne règle doit pouvoir être appliquée entre deux réunions ; sinon, elle restera théorique au moment où un salarié aura déjà le document ouvert dans son navigateur. Une politique IA ne doit pas ressembler à un règlement de trente pages que personne ne lit. Elle doit répondre à quatre questions : qui peut utiliser l’outil, avec quel compte, pour quels usages, et quelles données sont interdites. La règle opérationnelle doit être assez claire pour être appliquée pendant une journée de travail normale.

Le plus efficace est de créer une matrice d’usages. Reformuler un texte public : autorisé. Résumer un contrat client : interdit sans validation. Préparer un plan de formation générique : autorisé. Analyser un fichier RH : interdit. Générer un bout de code isolé : possible si les secrets et noms internes sont retirés. Ce format parle mieux aux équipes qu’une longue liste de principes abstraits.

Cette politique doit aussi indiquer qui arbitre. Dans une PME, cela peut être le dirigeant, le responsable IT, le DPO, un référent sécurité ou un binôme métier/technique. Sans responsable identifié, les cas limites finissent traités par habitude, ce qui est exactement ce qu’il faut éviter. Une adresse de contact ou un canal interne dédié suffit souvent à réduire les décisions isolées, à condition que les équipes sachent qu’aucune question n’est “trop simple” lorsqu’elle touche à des données sensibles.

Contrôles techniques à prévoir

La confiance ne repose pas seulement sur la prudence des utilisateurs : les réglages doivent suivre, surtout quand l’usage devient quotidien. Pour les usages réguliers, l’entreprise doit regarder les contrôles disponibles : gestion des comptes, authentification forte, restrictions d’accès, journaux, conservation, exports, intégrations, connecteurs et processus de départ d’un collaborateur. Le cycle de vie du compte compte autant que la consigne de confidentialité.

Un bon cadre commence souvent par peu de choses : liste des outils autorisés, interdiction des comptes personnels pour les données internes, MFA obligatoire, responsables d’administration, procédure d’ajout d’utilisateur, revue périodique des accès, et canal de support pour les questions. Ce socle évite que chaque équipe choisisse son outil dans son coin, avec des réglages et des garanties que personne ne vérifie.

Il faut aussi surveiller les intégrations. Un connecteur vers un drive, une messagerie ou un outil projet peut exposer davantage qu’un simple prompt tapé à la main. Avant d’activer une connexion, demandez quelles données deviennent accessibles, qui peut les appeler, et comment révoquer l’accès. Cette décision doit être testée sur un périmètre limité avant d’ouvrir un espace documentaire complet.

Documents à préparer avant d’ouvrir l’usage

Avant de généraliser ChatGPT dans une PME, préparez un document d’une page qui liste les usages autorisés, les usages interdits et les contacts internes. Ce support doit être assez court pour être relu au moment de l’action. Un guide trop long finit souvent ignoré, alors qu’une page claire peut devenir le réflexe avant un prompt sensible, notamment pour les collaborateurs qui utilisent l’outil ponctuellement et n’ont pas encore d’automatismes.

Ajoutez ensuite une fiche de classification. Elle n’a pas besoin d’être parfaite : public, interne, sensible, réglementé. Pour chaque niveau, donnez deux exemples métiers. Cette fiche transforme une notion abstraite en décision concrète, et elle aide les équipes à repérer rapidement quand une demande doit être anonymisée ou remontée à un responsable, sans attendre qu’un incident serve de formation improvisée.

Préparez aussi un modèle de prompt anonymisé. Il peut contenir des placeholders comme “Client A”, “montant arrondi”, “secteur B2B” ou “incident réseau générique”. Ce modèle montre que l’on peut être précis sans transmettre le dossier réel. Il est particulièrement utile pour le support, le commerce, les RH et les équipes techniques, car il donne une alternative prête à l’emploi au copier-coller risqué.

Enfin, gardez une trace de validation pour les usages nouveaux. Elle peut être très simple : demandeur, outil, type de données, objectif, décision, responsable. Cette trace évite de rediscuter le même cas tous les mois et donne une base si l’entreprise doit expliquer sa gouvernance à un client, un assureur ou un auditeur, ce qui devient fréquent dans les questionnaires sécurité B2B.

Ces documents ne remplacent pas les réglages techniques, mais ils donnent une mémoire commune. Quand une PME grandit, les usages se dispersent vite entre services. Un cadre écrit, court et maintenu évite que chaque équipe invente sa propre règle selon son niveau de prudence ou son urgence du moment.

RGPD et données personnelles : garder une logique de minimisation

Moins une donnée circule, plus elle reste maîtrisable. C’est le réflexe RGPD le plus utile.

Le RGPD ne disparaît pas parce qu’une donnée passe par un assistant IA. Si une PME traite des données personnelles, elle doit rester capable d’expliquer pourquoi ces données sont utilisées, sur quelle base, pendant combien de temps, avec quel niveau de protection et par quel sous-traitant éventuel. Le principe clé reste la minimisation : ne transmettre que ce qui est nécessaire.

Dans la pratique, cela signifie qu’un prompt doit être réduit au besoin métier. Pour préparer une réponse type à un client, il n’est pas nécessaire d’envoyer son nom, son adresse, son numéro de contrat et toute la conversation. Pour rédiger une procédure RH, il n’est pas nécessaire de copier un dossier nominatif. On peut travailler sur un cas générique, puis appliquer le résultat en interne avec les données réelles dans l’outil autorisé.

Les entreprises qui disposent d’un DPO ou d’un référent conformité doivent l’associer aux usages réguliers. Pas pour bloquer chaque test, mais pour distinguer les usages simples des traitements à risque. Cette discussion évite de découvrir trop tard qu’un usage devenu quotidien aurait dû être cadré dès le départ. Elle permet aussi d’écrire des consignes réalistes pour les équipes terrain.

Cas métiers : ce qui passe, ce qui doit être validé

Le niveau de risque change selon le service qui utilise l’outil, donc la règle doit parler métier plutôt que rester générale. Le marketing peut demander une reformulation de page publique ou un plan éditorial générique. Le support peut préparer une trame de réponse, à condition de retirer les informations client. Les RH, la finance, le juridique et la sécurité manipulent des informations plus sensibles : leurs usages doivent avoir un circuit de validation.

Pour les équipes commerciales, le bon compromis consiste à demander une structure, un angle ou une reformulation à partir d’informations non sensibles. Les montants exacts, conditions négociées, noms de décideurs, objections client et documents contractuels doivent rester hors prompt brut. L’IA peut aider à mieux écrire, pas devenir une copie du CRM dans un service externe, ni un espace parallèle où circulent des informations de négociation.

Côté technique, le support et les développeurs doivent être formés aux secrets. Une trace d’erreur peut contenir une URL interne, un jeton, une clé, une adresse IP ou une architecture. Avant de demander de l’aide, on nettoie l’extrait. Cette étape est courte, mais elle protège le patrimoine technique et évite de documenter involontairement une faiblesse exploitable.

Pour approfondir ce point, consultez cybersécurité pme, qui traite plus précisément de guide de la cybersécurité pme pour réduire les vrais risques.

Six scénarios à trancher dans une PME

Premier scénario : le service commercial veut reformuler une proposition. C’est acceptable si la demande porte sur le ton, la structure ou la clarté, mais pas si elle inclut le nom du client, les tarifs négociés, les clauses particulières et l’historique complet de la relation. Le bon prompt décrit le contexte commercial de façon générique, puis le commercial réintègre les éléments confidentiels dans l’outil interne validé.

Deuxième scénario : le support veut résumer un ticket long. L’usage peut être utile pour gagner du temps, mais il faut retirer les noms, identifiants, captures, logs complets et références internes. Si le ticket touche un incident de sécurité ou une donnée personnelle, la validation doit passer par le responsable défini, pas par l’appréciation du technicien seul, même lorsque la demande client paraît urgente.

Troisième scénario : les RH veulent préparer une trame d’entretien ou une annonce interne. L’IA peut aider à structurer, reformuler ou simplifier. Elle ne doit pas recevoir de dossiers individuels, de remarques nominatives, de salaires ou d’éléments disciplinaires. Le résultat doit ensuite être adapté par une personne qui connaît le droit social et le contexte humain, car une formulation correcte n’est pas automatiquement une décision juste.

Quatrième scénario : un développeur cherche de l’aide sur une erreur. Il peut créer un exemple minimal, retirer les secrets, changer les noms de services et simplifier l’architecture. Il ne doit pas coller un dépôt complet, une clé API, une configuration de production ou un log contenant des jetons. La réponse doit être testée comme n’importe quel code externe, avec revue, tests et compréhension avant intégration.

Cinquième scénario : la direction veut analyser un document stratégique. C’est souvent le cas le plus risqué, parce que le document paraît “business” plutôt que technique. Roadmap, acquisition, marge, plan social, négociation ou incident majeur doivent rester dans un circuit validé. L’IA peut aider sur une structure de note, mais pas recevoir le contenu brut, surtout si l’information n’est connue que d’un comité restreint.

Sixième scénario : une équipe veut connecter l’outil à un espace documentaire. Cette décision change d’échelle. Le risque ne dépend plus seulement de ce qu’un utilisateur colle dans un prompt, mais de ce que l’outil peut consulter. Avant d’activer un connecteur, il faut vérifier droits, périmètre, journaux, révocation et catégories de documents accessibles, puis tester avec un périmètre limité avant tout déploiement large.

Que faire si une donnée sensible a déjà été envoyée ?

L’erreur doit être déclarable, sinon elle restera invisible. Si un salarié a collé un document sensible dans un outil non autorisé, il ne faut pas commencer par le blâme : il faut comprendre ce qui a été transmis, par quel compte, à quelle date, avec quel contenu et avec quelles conséquences possibles. Une déclaration rapide vaut mieux qu’une erreur cachée.

La première action consiste à prévenir le responsable désigné : IT, sécurité, DPO, direction ou manager selon l’organisation. Ensuite, il faut évaluer si la donnée contient des personnes identifiables, des secrets, du code, des accès, des éléments contractuels ou un incident de sécurité. Si des identifiants, mots de passe, clés ou jetons ont été transmis, la rotation des secrets doit être immédiate, documentée et vérifiée.

Après l’incident, la réponse utile est pédagogique. Ajouter un exemple interdit, préciser la procédure, renforcer les contrôles ou proposer un modèle de prompt anonymisé. Une entreprise qui traite ces erreurs comme des retours d’expérience améliore son cadre plus vite qu’une entreprise qui laisse les usages se déplacer dans l’ombre.

Former les équipes avec des exemples concrets

Une formation utile montre des prompts réels, pas seulement des principes, parce que ce sont les exemples qui changent les réflexes. Les collaborateurs n’ont pas besoin d’un cours complet sur les modèles de langage pour comprendre le risque. Ils ont besoin d’exemples : ce prompt est autorisé, celui-ci ne l’est pas, celui-ci doit être anonymisé. Les meilleurs supports tiennent souvent sur une page par métier, avec trois cas fréquents et une personne à contacter.

Montrez les mauvais réflexes. Coller un fichier client pour “résumer”. Demander à l’IA d’analyser un incident de sécurité avec les IP internes. Envoyer un tableau RH. Copier une clause confidentielle. Puis montrez la version acceptable : contexte générique, données masquées, consigne claire, résultat relu. La comparaison parle plus qu’une interdiction abstraite.

Les managers doivent être formés aussi. Si la direction demande des gains de productivité sans cadrage, les équipes prendront des raccourcis. Le message doit être cohérent : oui aux usages utiles, non aux données sensibles non maîtrisées, et validation obligatoire pour les cas ambigus. Un manager qui comprend le cadre saura refuser un prompt risqué sans bloquer les usages réellement productifs.

Réponse produite par l’IA : vérifier avant d’utiliser

Le risque existe aussi après la réponse. La sortie doit être relue avant usage, même quand le prompt était propre.

Le risque ne s’arrête pas à l’entrée des données. La sortie doit être contrôlée. Une réponse peut inventer une règle, généraliser un point juridique, proposer un code vulnérable, transformer une nuance contractuelle ou donner une procédure incomplète. Pour une PME, la validation humaine reste la barrière principale.

Plus l’usage a un impact externe, plus la relecture doit être stricte. Un brouillon de mail commercial peut être corrigé rapidement. Une réponse client, un conseil RH, une note juridique, une analyse sécurité ou un script d’administration doivent passer par un expert compétent. L’IA accélère la préparation, elle ne remplace pas la responsabilité, ni la connaissance du contexte réel de l’entreprise.

Gardez aussi une trace des usages importants : objectif, données utilisées, outil, version finale validée. Cette discipline aide en cas d’audit, d’incident ou de contestation. Elle rend surtout le dispositif améliorable, parce qu’on sait où l’IA apporte réellement du temps gagné et où elle crée trop de risques.

Revoir le cadre tous les trimestres

Un cadre IA figé vieillit vite, car les usages changent plus vite que les documents internes. Nouveaux comptes, nouvelles intégrations, nouveaux réglages, nouveaux besoins métiers : une règle écrite une fois puis oubliée devient rapidement décorative. Prévoyez une revue trimestrielle courte : outils utilisés, incidents déclarés, demandes refusées, nouvelles fonctionnalités activées et retours des équipes.

Cette revue n’a pas besoin d’être lourde. Trente minutes suffisent souvent pour mettre à jour la liste des outils autorisés, ajouter un exemple de prompt, retirer un usage devenu risqué ou valider un nouveau besoin métier. L’important est de garder le cadre vivant, visible et applicable par des non-spécialistes, au lieu de laisser les pratiques réelles s’éloigner de la règle écrite.

C’est aussi le moment de relire les sources officielles des éditeurs. Les garanties, réglages et interfaces changent. Un responsable doit vérifier les paramètres de confidentialité avant de généraliser un nouvel usage, surtout si l’entreprise connecte l’outil à des documents, tickets ou espaces de travail internes.

La règle simple pour une PME

Commencez par ce qui réduit le plus de risque tout de suite, puis améliorez le reste par itérations. Si votre entreprise n’a pas encore de cadre, commencez petit : interdisez les données sensibles, autorisez quelques usages à faible risque, choisissez les comptes acceptés, désignez un responsable et donnez cinq exemples concrets aux équipes. Ce socle initial vaut mieux qu’une grande politique jamais appliquée.

Ensuite, élargissez progressivement. Ajoutez des modèles de prompts anonymisés, une liste d’outils validés, une procédure pour les cas sensibles, puis des contrôles administrateur si l’usage devient récurrent. Le bon objectif n’est pas d’utiliser ChatGPT partout : c’est d’obtenir des gains utiles sans perdre la maîtrise des données.

La priorité de départ : ne collez jamais un document brut sensible. Résumez, anonymisez, validez.

Pour approfondir ce point, consultez hyperconnexion travail, qui traite plus précisément de hyperconnexion au travail, reprendre la main sans tout couper.

1. désigner un responsable IA ou sécurité pour les arbitrages ;
2. bloquer les données sensibles tant que le cadre n’est pas validé ;
3. préparer des exemples de prompts autorisés par métier ;
4. choisir les comptes et espaces de travail approuvés ;
5. revoir les réglages et sources officielles à chaque évolution importante.