Pinterest aurait licencié deux ingénieurs après qu'ils eurent créé des scripts permettant d'identifier les collègues exclus des outils internes lors d'une restructuration, puis diffusé cette liste. À première vue, il s'agit d'un simple drame interne. Mais en réalité, c'est une étude de cas particulièrement révélatrice du fonctionnement des entreprises modernes : les systèmes d'identité érigés en source de vérité, les plateformes de messagerie servant d'organigrammes de facto, et les « données internes » techniquement accessibles bien avant d'être socialement acceptables.
Cet incident dépasse le cadre de Pinterest car on retrouve les mêmes ingrédients dans presque toutes les entreprises technologiques : identité centralisée, Slack ou Teams, systèmes RH et une multitude de tableaux de bord internes et d’API. En temps normal, on ne s’interroge guère sur la frontière entre observabilité et surveillance. Mais en cas de licenciements, cette frontière devient de plus en plus évidente.
Dans cet article explicatif, nous examinerons ce qui s'est probablement passé, pourquoi il est tentant de procéder à ce type de suivi, où cela franchit les limites éthiques et politiques, et ce que les organisations peuvent faire pour réduire à la fois les atteintes à la vie privée et la tentation de collecter des informations clandestinement.
Que s'est-il passé (et que signifie probablement « un script » ici) ?
Selon la BBC, Pinterest a déclaré que « deux ingénieurs ont créé des scripts personnalisés accédant indûment à des informations confidentielles de l'entreprise afin d'identifier les lieux de travail et les noms de tous les employés licenciés, puis ont diffusé ces informations à plus grande échelle », qualifiant cela de violation du règlement intérieur et d'atteinte à la vie privée du personnel concerné. Le reportage décrit également le mécanisme utilisé pour surveiller la suppression ou la désactivation des noms d'employés dans un outil de communication interne « tel que Slack ».
Dans de nombreuses entreprises, Slack (ou un service similaire) est directement lié au fournisseur d'identité (Okta, Azure AD, Google Workspace, etc.). Lorsqu'un compte est désactivé, plusieurs conséquences s'ensuivent : les jetons d'accès expirent, les groupes changent et l'utilisateur disparaît de certains annuaires, canaux et intégrations. Si vous disposez d'un accès API (même en lecture seule), vous pouvez souvent identifier l'utilisateur dont le compte a été désactivé en détectant simplement les changements d'état.
- Un utilisateur disparaît de la liste des « utilisateurs actifs ».
- Le profil d'un utilisateur est désactivé.
- Un bot ne peut plus leur envoyer de messages privés.
- Leur appartenance varie selon les canaux ou les groupes d'utilisateurs.
Dans ce contexte, un « script » n'a pas besoin d'être complexe. Il peut s'agir de quelques dizaines de lignes de code interrogeant une API, comparant la liste des utilisateurs d'hier à celle d'aujourd'hui et déclenchant une alerte. D'un point de vue purement technique, c'est le même schéma que celui utilisé par les ingénieurs pour des tâches opérationnelles légitimes : comparer deux instantanés pour détecter les changements.
La différence réside dans ce qui est détecté (les personnes), pourquoi c'est détecté (les licenciements) et où vont les résultats (partagés à grande échelle).
Pourquoi les employés agissent-ils ainsi lors des licenciements ?
Il y a une vérité dérangeante concernant les licenciements : on apprend généralement les grandes lignes de la situation par des voies détournées avant même que la direction ne communique officiellement. Parfois, c’est parce que la direction ne peut pas encore partager de détails. Parfois, c’est parce que « nous sommes encore en train de régler les détails » est un euphémisme pour « nous préférons ne rien dire ».
Les employés s'appuient donc sur tous les signaux existants :
- Les amis se taisent soudainement.
- Les invitations du calendrier disparaissent.
- L'accès aux dépôts est révoqué.
- Le statut Slack change ou la personne disparaît de l'annuaire.
Suivre ces signaux peut s'apparenter à de l'autodéfense. Les gens veulent savoir :
- Mon équipe est-elle concernée ?
- Mon responsable a-t-il été licencié ?
- Mes plus proches collaborateurs sont-ils toujours là ?
- L'entreprise se porte-t-elle bien, ou s'agit-il d'une restructuration plus importante ?
Cette motivation est humaine et prévisible. Mais un comportement prévisible peut néanmoins être nuisible.
Le problème de confidentialité : le statut de licenciement est une information sensible.
Un événement lié à la cessation d'emploi ne se résume pas à de simples « détails insignifiants concernant le travail ». Il s'agit d'informations personnelles sensibles concernant le statut d'emploi d'une personne, souvent liées aux avantages sociaux, à l'immigration, à l'assurance maladie et aux perspectives d'emploi futures.
Même si une entreprise prévoit d'annoncer publiquement une réduction de ses effectifs, l'identité des personnes concernées et leur lieu de travail ne sont généralement divulgués qu'aux personnes qui ont besoin d'en connaître :
- Le service des ressources humaines et de la paie a besoin de détails.
- Le service informatique doit procéder au départ des employés.
- Les obligations légales garantissent la conformité.
- Les managers doivent communiquer directement avec leurs équipes.
Le partage interne à grande échelle d'une liste d'employés licenciés est différent. Il peut :
- Supprimer la capacité de la personne concernée à contrôler le récit.
- Révéler la localisation ou l'appartenance à une équipe d'une personne.
- Encouragez les ragots et les spéculations (« était-ce une question de performance ? » « était-ce politique ? »).
- Augmenter le risque de harcèlement ciblé ou de divulgation d'informations personnelles en dehors de l'entreprise.
La façon dont Pinterest présente les choses — en affirmant avoir violé la vie privée d'anciens collègues — n'est pas qu'une simple opération de relations publiques. Il s'agit d'un préjudice bien réel.
Problème de sécurité : le contrôle d’accès est différent de l’autorisation.
De nombreux systèmes internes fonctionnent avec des permissions générales : si vous êtes ingénieur, vous pouvez interroger un annuaire ou utiliser une API interne. Cela ne signifie pas pour autant que vous êtes autorisé à l’utiliser à toutes fins.
C’est là que beaucoup d’organisations rencontrent des difficultés. Elles développent des outils internes qui sont :
- Facile à utiliser,
- Puissant,
- Mal gouverné.
Ils s'appuient alors sur les politiques publiques (« ne faites pas ça ») comme principal garde-fou. Or, sous forte pression, ces garde-fous, fondés uniquement sur les politiques publiques, s'avèrent inefficaces.
La publication spéciale 800-53 du NIST est l'un des catalogues de référence utilisés par les organisations pour définir des familles de contrôles comme le contrôle d'accès et l'audit. Sans même s'attarder sur les identifiants de contrôle, l'idée de base s'applique parfaitement : l'accès aux données doit être restreint, surveillé et justifié par des finalités professionnelles légitimes, notamment pour les informations sensibles.
En d'autres termes : « techniquement, vous pouvez lire ceci » ne doit jamais être interprété comme « vous pouvez lire ceci sans problème ».
Le problème culturel : Slack est devenu l’organigramme
La plupart des entreprises vivent aujourd'hui dans deux réalités parallèles :
- La réalité formelle : systèmes RH, lignes hiérarchiques, annonces officielles.
- La réalité vécue : canaux Slack, messages privés de groupe, mentions GitHub, rotations d’astreinte.
Lorsqu'un changement survient dans le système formel (comme un départ d'employé), il produit immédiatement des manifestations visibles dans le système opérationnel. Les employés interprètent ces manifestations comme étant la vérité, parfois même plus fermement qu'ils ne font confiance aux communications de la direction.
Ce décalage crée une incitation perverse :
- Si les dirigeants ne vous disent pas ce qui se passe,
- Vous devrez le reconstituer à partir des fuites de données télémétriques.
Cet incident nous rappelle que la « transparence interne » n'est pas qu'une simple stratégie de communication ; c'est aussi une stratégie de sécurité de l'information. Si les gens ont le sentiment de devoir reconstituer la réalité à partir des fuites, ils le feront.
Là où les ingénieurs ont franchi la ligne
Même si l'on comprend pourquoi quelqu'un pourrait créer un tel script, il y a au moins trois limites claires qui sont franchies :
1) Limitation de l'objet
Si la source des données est constituée d’« informations confidentielles de l’entreprise », on s’attend à ce qu’elles soient utilisées pour une fonction commerciale légitime, et non à des fins de recherche en vue de licenciements.
Le cadre de protection de la vie privée du NIST met l'accent sur la gestion des risques liés à la protection de la vie privée et sur l'adoption de pratiques qui protègent les individus. Concrètement, cela signifie : « collecter et utiliser les données à des fins spécifiques et légitimes, et éviter toute utilisation secondaire susceptible d'engendrer de nouveaux préjudices ».
Un script permettant d'identifier les collègues licenciés est, par définition, une utilisation secondaire : les signaux de départ servent à protéger les systèmes et à exécuter les processus RH, et non à générer une liste interne de licenciements.
2) Amplification
Les gens remarquent les disparitions dans Slack de manière naturelle — c'est une fuite d'informations ambiante.
Un script transforme les fuites d'informations ambiantes en un ensemble de données structurées (noms, lieux, équipes probables, heure de la fin). C'est ce qu'on appelle l'amplification : le potentiel de nuisance augmente considérablement lorsque des signaux vagues deviennent une liste précise.
3) Redistribution
Le partage plus large des résultats rend difficile leur justification par la simple curiosité. Il crée un nouveau canal de diffusion pour des informations sensibles et responsabilise les auteurs en cas d'utilisation abusive ultérieure.
Ce que les entreprises peuvent faire : réduire les fuites, accroître la confiance et renforcer les contrôles.
On croit à tort que la solution consiste à « tout verrouiller ». En pratique, trois mesures complémentaires sont nécessaires : la gouvernance, les contrôles techniques et la communication.
1) Traitez les événements de départ comme des moments sensibles et concevez-les dans le respect de la vie privée.
Le départ des employés modifie inévitablement les systèmes, mais vous pouvez réduire la quantité d'informations rejetées :
- Limitez au maximum les modifications apportées à l'annuaire public jusqu'à ce que les communications aient lieu.
- Évitez les suppressions massives d'utilisateurs faciles à différencier.
- Envisagez de retarder de plusieurs heures certaines mises à jour non critiques pour la sécurité afin qu'elles ne servent pas de fil d'actualité en temps réel concernant les licenciements.
Le but n'est pas de dissimuler la réalité indéfiniment, mais d'éviter de transformer un événement douloureux en une chasse au trésor.
2) Ajouter des contrôles d'accès et une journalisation basés sur la finalité
Si les API internes peuvent révéler à grande échelle les changements de statut des employés, alors :
- L'accès devrait être limité aux rôles qui en ont besoin.
- L'exportation en vrac devrait être justifiée.
- Les requêtes doivent être enregistrées avec l'identité et l'intention.
- Les sondages automatisés doivent se démarquer.
C’est là que la mentalité « audit et responsabilité » prend toute son importance : si un script énumère les utilisateurs et émet des alertes, il doit déclencher une détection.
3) Élaborez un plan de communication humain en cas de licenciements.
Le principal facteur du suivi des ombres est l'incertitude.
Les entreprises peuvent réduire la tentation de piller leurs outils internes en étant explicites :
- Quand les employés concernés seront-ils informés ?
- Quand les équipes seront-elles informées ?
- Que peut-on partager, et quand ?
- Où les gens peuvent-ils trouver des informations vérifiées ?
Si les dirigeants fournissent des informations précises et opportunes, le « besoin » de listes à faire soi-même diminue.
4) Donnez aux employés un moyen officiel de contrôler leurs collaborateurs.
C'est subtil, mais important. Les gens ne sont pas seulement curieux ; ils essaient de coordonner leur travail et de prendre des nouvelles de leurs amis.
Un simple message d'état d'annuaire autorisé (« ce compte n'est plus actif ») sans horodatage, localisation ni liste pourrait satisfaire les besoins de base sans permettre une reconstruction massive.
Une tendance plus générale : les licenciements comme test de résistance à la sécurité de l’information
Les licenciements révèlent les faiblesses de la gouvernance car ils engendrent :
- une avalanche d'événements délicats,
- une température émotionnelle élevée,
- et une forte instabilité des accès.
C’est précisément dans ce genre de situation que l’on observe des cas limites : des employés qui extraient des données des systèmes, des gestionnaires qui improvisent et des outils utilisés de manière non prévue.
Des sites comme Layoffs.fyi existent car les gens recherchent une information indépendante sur l'ampleur des réductions d'effectifs dans le secteur. Au sein même d'une entreprise, ce besoin est présent, mais les signaux sont plus directs et les enjeux plus personnels.
En résumé
Le licenciement par Pinterest d'ingénieurs ayant développé un système de suivi des licenciements n'est pas simplement un avertissement : « ne soyez pas curieux ». C'est un signal d'alarme : l'observabilité interne peut se transformer en surveillance interne dès que la confiance au sein de l'organisation s'érode.
Si vos outils permettent de transformer facilement les changements d'identité en une liste de collègues licenciés, certains le feront, surtout en période de licenciements. La solution ne consiste pas seulement à sanctionner les responsables ; il faut mettre en place des systèmes et des pratiques de communication qui empêchent les départs d'employés de se transformer en fuites de données et qui traitent le statut d'emploi comme l'information sensible qu'il est.
Français
English
العربية
Čeština
Dansk
Nederlands
Eesti
Suomi
Deutsch
Ελληνικά
Magyar
Italiano
日本語
한국어
Latviešu valoda
Lietuvių kalba
Norsk bokmål
Polski
Português
Română
Русский
Slovenčina
Slovenščina
Español
Svenska
Türkçe