Un ingénieur cherche à résoudre un bug dans le code d’un produit que son employeur n’a pas encore lancé. Il est neuf heures du soir, son onglet ChatGPT personnel est déjà ouvert et coller la fonction entière semble être le moyen le plus rapide d’obtenir une réponse. En mars 2023, environ trois semaines après que la division semi-conducteurs de Samsung a été autorisée à utiliser ChatGPT, l’entreprise a recensé trois cas de ce type : un salarié avait collé le code source d’un programme de base de données pour semi-conducteurs afin d’en faire repérer les erreurs, un deuxième avait soumis du code lié à des équipements en demandant de l’« optimiser », et un troisième avait téléversé l’enregistrement d’une réunion pour le faire convertir en compte rendu. Samsung a immédiatement limité chaque prompt à 1 024 octets en urgence (article de The Economist Korea résumé en anglais par Mashable). Au 1er mai 2023, l’entreprise était allée plus loin et avait temporairement interdit tous les outils d’IA générative sur ses appareils (TechCrunch, « Samsung bans use of generative AI tools like ChatGPT after April internal data leak », 2023).
Dans les incidents rapportés, aucune intention malveillante n’était nécessaire. Transmettre des informations confidentielles à un service tiers peut enfreindre une politique interne ou un contrat et affaiblir la maîtrise qu’en conserve leur détenteur, même si elles ne sont jamais publiées. Les conséquences juridiques précises et une éventuelle obligation de notification dépendent des faits et de la juridiction concernée.
Ce qui constitue réellement une « information professionnelle confidentielle »
Tout ce qui concerne votre travail n’est pas confidentiel au sens de cet article. Le contrôle porte sur un ensemble plus restreint et plus précis :
- Le code source d’un système propriétaire, inédit ou sensible sur le plan concurrentiel.
- Les chiffres financiers non publiés, comme les résultats trimestriels avant leur publication, les prévisions internes ou la stratégie tarifaire.
- Les projets de produit ou d’entreprise non annoncés, comme une feuille de route fonctionnelle, une cible d’acquisition ou un partenariat en préparation.
- Les informations de sécurité, notamment des vulnérabilités, identifiants, jetons, URL privées, schémas d’architecture ou configurations de production.
- Les contrats et conditions couverts par un NDA, comme les contrats clients, les accords fournisseurs et tout autre document qu’une signature oblige déjà à garder confidentiel.
- Les secrets d’affaires documentés que votre employeur a expressément désignés ou traités comme tels, par exemple une formule, un procédé ou une liste de clients constituée à grands frais.
- Les données personnelles ou réglementées concernant des clients, des salariés, des patients, des élèves ou d’autres personnes, même lorsqu’elles ne constituent pas un secret d’affaires.
Le premier brouillon d’une note interne ordinaire, une offre d’emploi publique ou une question générale sur un processus n’entrent pas dans cette catégorie. Il ne s’agit pas d’avoir peur de l’IA, mais de reconnaître le petit nombre d’informations qui exigent une autre solution.
Pourquoi ce n’est pas une simple règle de courtoisie informatique
La plupart des consignes sur l’IA au travail présentent ce sujet comme une question de respect des politiques internes. C’est exact, mais cela minimise les enjeux propres aux véritables secrets d’affaires. En droit américain, une information ne bénéficie de la protection applicable aux secrets d’affaires que si son détenteur « a pris des mesures raisonnables pour garder cette information secrète » (18 U.S.C. § 1839(3)(A), adopté dans le cadre de l’Economic Espionage Act puis modifié par le Defend Trade Secrets Act). Cette protection repose sur des mesures effectives et continues de contrôle de l’information, pas seulement sur sa valeur ou son caractère inédit. Le droit de l’UE fixe un critère comparable : un secret d’affaires doit avoir « fait l’objet, de la part de la personne qui en a le contrôle de façon licite, de dispositions raisonnables, compte tenu des circonstances, destinées à le garder secret » (directive (UE) 2016/943, article 2, paragraphe 1, point c)).
Les services grand public ont leurs propres conditions d’utilisation, mais celles-ci ne correspondent pas nécessairement aux engagements de confidentialité, de sécurité, de conservation, de localisation et de traitement des données négociés par l’employeur et requis pour les informations concernées. Envoyer un véritable secret d’affaires à un prestataire non approuvé peut aller à l’encontre des mesures raisonnables prises par son détenteur pour le protéger. Seuls les conditions applicables, les contrôles en place, les faits et la juridiction permettent de déterminer si un incident donné constitue une divulgation au sens juridique ou compromet cette protection. Un salarié ne devrait pas trancher cette question en se fiant à une simple appellation commerciale.
Supprimer la conversation visible n’annule pas la transmission et peut ne pas satisfaire aux obligations de gestion d’incident ou de conservation des preuves. Si vous collez accidentellement une information confidentielle, arrêtez-vous. Notez l’outil, le compte, l’heure et la catégorie de données sans recopier le secret, puis signalez rapidement l’incident par la voie prévue par votre employeur pour les questions de sécurité ou de confidentialité. Suivez ses instructions concernant la suppression, la rotation des identifiants, le contact avec le prestataire, les preuves et les notifications.
L’idée reçue à l’origine du problème
Le problème peut commencer lorsque vous évaluez le risque uniquement selon que le secret est devenu public ou non. Une transmission à un service tiers non autorisé peut avoir des conséquences même si les informations ne sont jamais publiées. Les offres, la configuration de l’environnement, les contrats et les contrôles du prestataire varient. Une marque ou l’étiquette « entreprise » ne suffit pas à établir qu’un outil est approuvé. La personne habilitée à appliquer la politique de votre employeur est la mieux placée pour évaluer le circuit précis. L’article Confidentialité et hygiène des données au travail explique comment vérifier les conditions réelles de traitement des données d’un outil une fois celui-ci identifié. Ici, la règle est plus étroite : tant que vous avez un doute, ne collez pas le secret.
Une deuxième idée reçue consiste à penser que « tout le monde dans mon équipe le fait » prouve que la pratique est acceptable. Dans le cas de Samsung, plusieurs ingénieurs ont fait indépendamment le même choix, qui pouvait sembler raisonnable, avant que l’entreprise ne s’en aperçoive. La pratique de vos collègues ne constitue pas une vérification.
Une troisième idée reçue consiste à croire que cette règle ne concerne que les ingénieurs et le code source. Des chiffres financiers, le premier brouillon d’une note sur une acquisition ou une feuille de calcul contenant des tarifs inédits sont tout aussi exposés dès qu’ils sont collés dans un compte personnel. Or, ces informations sont souvent manipulées par des personnes travaillant dans la finance, les ventes ou les opérations, plutôt que dans l’ingénierie. Le contrôle en six catégories ci-dessous s’applique donc de la même manière, quels que soient votre poste et votre service.
Le contrôle en six catégories
Avant de coller quoi que ce soit dans un outil d’IA qui ne correspond pas précisément au compte professionnel configuré et approuvé par votre employeur, vérifiez si le contenu entre dans l’une des catégories suivantes :
- Du code source provenant d’un système inédit ou propriétaire.
- Des chiffres financiers qui n’ont pas encore été rendus publics.
- Un projet de produit, de fonctionnalité ou d’activité qui n’a pas été annoncé.
- Une information de sécurité, comme une vulnérabilité, un identifiant ou une architecture de production.
- Tout élément couvert par un NDA signé ou une clause de confidentialité.
- Tout élément que votre employeur a classé comme confidentiel, ainsi que les données personnelles ou réglementées couvertes par une politique interne ou par la loi.
Si vous répondez oui dans un seul cas, arrêtez-vous. Commencez par trouver et lire la véritable politique de votre employeur sur l’IA afin de savoir si un outil approuvé existe pour ce type de contenu. Certaines entreprises en ont un, d’autres pas encore. Supposer l’un ou l’autre est précisément l’erreur que cet article cherche à prévenir.
Que faire à la place
- Utilisez uniquement l’outil, l’environnement, le compte et la catégorie de données que votre employeur a expressément approuvés. Une adresse électronique professionnelle ou une appellation commerciale « entreprise » ne suffisent pas à elles seules.
- Si aucun outil n’est approuvé pour ce type de contenu, n’utilisez pas encore l’IA pour le traiter. Demandez à votre responsable ou à l’équipe informatique ou de sécurité s’il existe une procédure d’exception, au lieu de décider seul que le gain de temps justifie le risque.
- Si la politique interne permet de poser une question abstraite sur un schéma général, utilisez des données synthétiques ou limitées au strict nécessaire. Vérifiez de nouveau les risques de réidentification, la logique métier, les secrets et les données personnelles. La désidentification relève d’une évaluation du risque, pas d’un simple remplacement de termes.
Passez en revue votre dernière conversation avec une IA
Examinez vos échanges professionnels récents avec des outils d’IA sans recopier d’informations sensibles ailleurs. Si certaines ont pu être transmises à un outil non approuvé, utilisez rapidement la procédure de signalement des incidents de votre employeur. Ne supprimez et ne modifiez aucune preuve de votre propre initiative, sauf instruction contraire. Faites remplacer les identifiants exposés selon la procédure d’urgence approuvée. La fiche de contrôle avant de coller des informations professionnelles confidentielles reprend les vérifications à effectuer.
La politique interne de l’ICO sur l’usage de l’IA, les recommandations du NCSC sur le développement sécurisé de systèmes d’IA et les orientations de l’ICO sur la minimisation des données étayent les contrôles relatifs aux systèmes approuvés, à la gestion des incidents, à la sécurité et au strict nécessaire. Ces textes ne déterminent pas les conséquences juridiques d’une divulgation précise.
