Près d’un tiers des salariés interrogés ont transmis à l’IA des identifiants, des clés et des accès professionnels

Un développeur copie un journal d’erreur dans un chat d’IA et demande de trouver la cause du dysfonctionnement. Le journal contient une clé active utilisée au travail. La tâche est courante, l’opération ne prend que quelques secondes, mais l’accès au système a déjà été transmis à un service externe. Ce sont précisément ces situations qu’il faut examiner avec l’équipe avant la prochaine correction urgente.

Selon RB.RU, près d’un salarié sur trois parmi les personnes interrogées dans des entreprises russes a transmis à des outils d’IA des identifiants professionnels, des clés et des accès à des dossiers au cours des six derniers mois. Le média cite une étude de Kiberdom. Seuls 5% des répondants ont signalé l’existence de règles écrites sur l’utilisation de l’IA dans leur entreprise, et près d’un sur cinq ignore quelles données professionnelles peuvent être transmises à ces outils.

Ce que disent les chiffres — et ce qu’ils ne prouvent pas

Pour un fondateur ou un responsable du développement, une question concrète se pose : les salariés comprennent-ils exactement ce qu’ils envoient à l’IA avec leur demande ? Une personne peut se souvenir qu’il ne faut pas transmettre de mot de passe, mais laisser passer un jeton dans un long extrait de code ou un lien donnant accès à des ressources au milieu d’une conversation.

Il faut toutefois rester prudent face à un titre affirmant que « seules 5% des entreprises » disposent de règles. La description fournie porte sur la proportion de salariés interrogés ayant signalé l’existence de telles règles. Elle ne permet pas de calculer directement la proportion d’entreprises concernées : plusieurs répondants pouvaient travailler dans la même organisation, et certains salariés pouvaient simplement ignorer l’existence d’un document.

Le texte disponible ne précise pas non plus la taille ni la composition de l’échantillon, la formulation des questions ou les détails de la méthodologie. Il est donc impossible de généraliser les résultats à l’ensemble des salariés des entreprises russes. Par ailleurs, transmettre un identifiant, une clé secrète active ou un lien vers un dossier présente des risques différents. L’enquête les regroupe dans un même tableau, mais n’indique pas combien de cas ont entraîné un accès par un tiers ou une fuite de données.

Comment un secret se glisse dans une demande ordinaire

Imaginons une équipe qui intègre un service de paiement. L’intégration renvoie une erreur ; le développeur envoie à l’assistant un exemple de requête, les en-têtes et la réponse du serveur. Un véritable jeton figure encore dans l’en-tête d’autorisation. Il n’est pas nécessaire pour analyser la structure de la requête : on peut le remplacer par une valeur fictive, tout en conservant les noms des champs et le code d’erreur.

Un responsable produit rencontre une situation similaire lorsqu’il demande à l’IA d’analyser les demandes des clients. Le fichier exporté peut contenir des coordonnées, des liens internes et des informations sur les commandes. Il est alors utile de commencer par réunir quelques exemples anonymisés et de vérifier s’ils suffisent à l’analyse souhaitée. Envoyer tout le tableau simplement parce qu’il est facile à joindre augmente inutilement le volume de données transmises.

Le seul fait d’envoyer des informations à un service d’IA ne prouve pas qu’elles sont publiées ou utilisées pour entraîner un modèle. Les conditions dépendent du produit, de la formule choisie, des paramètres et du contrat. Elles doivent être vérifiées séparément. Le nom du service ne suffit pas, à lui seul, à déterminer quelles données l’équipe est autorisée à lui confier.

Ce que l’équipe peut mettre en place

Il convient de commencer par des règles courtes, illustrées par des exemples clairs. Quels services sont autorisés ? Peut-on téléverser du code source ? Comment traiter les documents des clients ? Qui contacter si une clé a déjà été envoyée dans un chat ? Les réponses doivent être accessibles là où les salariés travaillent et applicables à leurs tâches réelles.

L’étape suivante consiste à préparer des exemples sûrs : un journal sans secrets, une requête de test avec une valeur fictive à la place du jeton, une demande client anonymisée. Il est plus simple pour un développeur de reprendre un exemple prêt à l’emploi que de déterminer lui-même, à chaque fois, la limite de ce qui est permis. Une détection automatique des secrets peut compléter ce processus, mais ses résultats doivent eux aussi être examinés avec attention.

Si une clé active a déjà été transmise à un service externe, la réponse pratique consiste à la révoquer, à en générer une nouvelle et à examiner les journaux d’utilisation disponibles. Supprimer le message ne remplace pas le renouvellement de la clé.

Pour un responsable, le principal intérêt de cette enquête est d’inciter à examiner un processus de travail concret. Prenez une tâche courante que l’équipe accomplit avec l’IA et regardez quelles données sont envoyées avec elle. Cet examen montrera où il faut une règle claire, un modèle prêt à l’emploi ou une restriction technique.