Surveillance des salariés : cadre légal et limites

Surveiller des salariés pour protéger le système d’information n’autorise pas à transformer les journaux techniques en machine à mesurer chaque minute de travail. Le compromis central est net : plus la télémétrie est fine, plus l’investigation gagne en précision, mais plus l’atteinte aux droits des personnes, le risque de détournement et la dette de conformité augmentent.

→ Lire l’explication complète de la marmotte

Légitimité de la surveillance et finalité de sécurité

En France, l’article L1121-1 du Code du travail impose que toute restriction aux droits et libertés soit justifiée par la nature de la tâche et proportionnée au but recherché. L’article L1222-4 interdit de collecter des informations personnelles par un dispositif qui n’a pas été porté préalablement à la connaissance du salarié. Ces deux règles écartent une idée tenace : un poste, une messagerie ou une connexion professionnelle ne deviennent pas juridiquement transparents parce qu’ils appartiennent à l’employeur.

Le Règlement général sur la protection des données (RGPD) ajoute une discipline technique. Une donnée permettant d’identifier directement ou indirectement une personne est une donnée personnelle : identifiant de connexion, adresse IP, adresse de messagerie, nom de machine associé à un utilisateur, historique web, horodatage de badge ou enregistrement d’écran. Chiffrer ces données ne les sort pas du RGPD. Un coffre fermé reste un coffre rempli de données personnelles.

La finalité doit être définie avant le choix de l’outil. « Sécurité du système d’information » peut justifier la journalisation des authentifications, des élévations de privilèges, des accès anormaux et des sorties de données. Elle ne justifie pas, par contamination sémantique, un classement permanent de productivité ou l’analyse comportementale détaillée de toute la population. Une finalité « sécurité et performance et qualité et innovation » ne décrit rien. C’est un brouillard administratif, très pratique jusqu’au premier contrôle.

La base légale ne doit pas être choisie au hasard. Le consentement du salarié est rarement valable, car le lien de subordination empêche généralement un consentement libre. L’intérêt légitime peut soutenir un dispositif de sécurité si une mise en balance documentée démontre la nécessité et la proportionnalité. L’exécution du contrat couvre certains traitements strictement nécessaires à la relation de travail. Une obligation légale peut aussi s’appliquer à des secteurs réglementés. La qualification dépend du traitement réel, pas du slogan posé dans le registre.

La recommandation est de séparer architecturalement trois objectifs :

la détection d’incidents et la réponse à incident ;
l’administration des accès et des équipements ;
l’évaluation managériale ou disciplinaire.

Mélanger ces flux dans un même entrepôt de données rend le détournement de finalité presque inévitable. Une équipe de sécurité doit pouvoir enquêter sur une compromission, pas produire sur demande un palmarès des pauses réseau. Vingt ans de gestion de journaux apprennent que la donnée collectée « au cas où » finit toujours par intéresser quelqu’un, souvent sans rapport avec le cas où.

Pour cadrer l’ensemble, la gouvernance de la cybersécurité doit tenir un registre des traitements, une matrice de finalités et une procédure d’habilitation. La politique de journalisation n’est pas une annexe technique : elle fixe ce qui peut être collecté, qui peut le consulter, combien de temps et pour quel incident.

Information des salariés, CSE et analyse d’impact

Avant activation, les personnes concernées doivent recevoir une information intelligible : responsable du traitement, finalités, catégories de données, destinataires, durée de conservation, droits d’accès, de rectification, d’effacement, de limitation et voie de réclamation. Une phrase enfouie dans une charte informatique de quarante pages ne remplit pas cette obligation. Elle remplit surtout un dossier d’archives.

Le Comité social et économique (CSE) doit être informé et consulté avant la mise en œuvre de moyens de contrôle de l’activité des salariés. Cette exigence concerne notamment les dispositifs de contrôle de l’activité, y compris lorsqu’ils reposent sur des outils de sécurité. Le fait qu’un agent soit déployé par l’équipe infrastructure plutôt que par les ressources humaines ne change pas l’effet observé sur les personnes.

Une Analyse d’impact relative à la protection des données (AIPD) est requise lorsque le traitement est susceptible d’engendrer un risque élevé pour les droits et libertés. La surveillance systématique, le croisement de sources, la géolocalisation, l’analyse de comportement, l’intelligence artificielle appliquée aux activités ou la surveillance à grande échelle sont des signaux forts. L’AIPD doit décrire les flux, évaluer nécessité et proportionnalité, recenser les risques, puis lister des mesures vérifiables. Elle n’est pas un formulaire décoratif destiné à rassurer un comité. Si le risque résiduel reste élevé, une consultation préalable de l’autorité compétente peut devenir nécessaire.

Une AIPD bien menée force les bonnes questions d’architecture :

quel événement de sécurité ne peut pas être détecté avec une donnée moins intrusive ;
quelle corrélation exige une identité nominative, et laquelle fonctionne avec un identifiant pseudonyme ;
quel accès d’investigation exige une levée d’identité sous double contrôle ;
quelle durée est nécessaire à la détection, à l’enquête et à la preuve ;
quelle mesure empêche qu’un responsable opérationnel consulte des données de sécurité pour gérer une absence.

Le droit du travail et le RGPD encadrent le traitement, mais ne garantissent ni la détection d’une attaque ni la qualité des preuves. Le reste doit venir de l’architecture cyber, de procédures d’enquête, de contrôles d’accès et d’une conservation techniquement démontrable.

Minimisation, pseudonymisation et conservation des journaux

La minimisation n’est pas un filtre appliqué après ingestion. Une fois qu’un collecteur a reçu des contenus de messagerie, des requêtes complètes, des frappes clavier ou des captures d’écran, la donnée existe déjà dans les sauvegardes, les index et les réplications. Il faut limiter à la source.

Pour la plupart des usages de sécurité, conserver l’événement, le type d’action, l’horodatage, la ressource et un identifiant pseudonymisé suffit à déclencher une détection. La pseudonymisation remplace l’identité par un identifiant dérivé, mais elle reste un traitement de données personnelles dès lors qu’une table ou une clé permet la réidentification. Elle réduit l’exposition, elle n’efface pas les obligations.

Une architecture défendable sépare donc :

un collecteur qui normalise et supprime les champs non nécessaires ;
un entrepôt de sécurité contenant des identifiants pseudonymes ;
un service de réidentification isolé, journalisé et soumis à une approbation ;
un stockage de preuves nominatives réservé à un incident qualifié.

Le Security Information and Event Management (SIEM), plateforme de centralisation et de corrélation des événements, doit appliquer des rôles distincts : opérateur de détection, enquêteur habilité, administrateur de plateforme et auditeur. L’administrateur du SIEM ne doit pas pouvoir lire librement toutes les données métier sous prétexte qu’il maintient les index. Le privilège technique omniscient est une tradition du secteur, pas une nécessité physique.

La conservation doit suivre des durées documentées par catégorie. Les événements bruts à forte granularité peuvent nécessiter une fenêtre courte, les alertes enrichies une fenêtre plus longue, et les éléments liés à un incident déclaré une conservation conforme aux exigences de preuve. Une durée fixe de douze mois plaquée sur chaque champ est commode, donc suspecte. La durée doit correspondre à la finalité, au délai réaliste de détection et aux contraintes applicables.

L’intégrité compte autant que la confidentialité. Synchroniser les horloges avec le Network Time Protocol (NTP), signer ou chaîner les événements sensibles, limiter les suppressions et tester la restauration sont nécessaires. Un journal dont l’horodatage dérive ou dont l’administrateur peut réécrire l’historique sert surtout à meubler un rapport d’incident.

Exemple de pseudonymisation avant indexation

L’exemple suivant transforme un identifiant de connexion avant son envoi vers un index de sécurité. La clé HMAC (Hash-based Message Authentication Code), mécanisme de dérivation fondé sur une clé secrète, doit être stockée dans un gestionnaire de secrets et tournée selon une procédure contrôlée. Une rotation casse les corrélations historiques si aucune période de recouvrement n’est prévue.

#!/usr/bin/env bash
# Prérequis : jq et openssl installés.
# La clé ne doit jamais être écrite dans le script ni dans un fichier de logs.
export PSEUDO_HMAC_KEY="$(cat /run/secrets/log_pseudonymization_key)"

# Entrée attendue : une ligne JSON avec un champ "user".
# Sortie : identifiant pseudonymisé, aucun identifiant nominatif conservé.
jq -c '.user as $user | del(.user) | .user_pseudo = $user' access.jsonl |
while IFS= read -r event; do
  pseudo="$(printf '%s' "$(jq -r '.user_pseudo' <<< "$event")" \
    | openssl dgst -sha256 -hmac "$PSEUDO_HMAC_KEY" -r \
    | awk '{print $1}')"

  jq --arg pseudo "$pseudo" '.user_pseudo = $pseudo' <<< "$event"
done

Ce mécanisme ne protège pas contre une réidentification par recoupement : un événement rare, une heure de connexion distinctive et une ressource sensible peuvent suffire. Il faut donc contrôler aussi les champs auxiliaires, les exports et les droits de recherche. La clé HMAC est un secret de sécurité : sa compromission permet de recalculer les pseudonymes à partir d’une liste d’identifiants connue.

Surface d’attaque et limites du contrôle salarié

Les outils de surveillance créent une surface d’attaque particulière. Un agent installé sur tous les postes avec des privilèges élevés devient une cible de premier choix. Sa compromission peut offrir à un attaquant une visibilité transversale, une capacité de collecte ou un point de persistance. L’agent doit être signé, inventorié, mis à jour, limité aux permissions nécessaires et contrôlé par une chaîne de distribution authentifiée.

Les journaux centralisés concentrent des données exploitables pour l’ingénierie sociale, le mouvement latéral et le chantage. Chiffrer en transit avec Transport Layer Security (TLS) et chiffrer au repos ne suffit pas : il faut isoler les comptes de service, interdire les accès partagés, journaliser les consultations et déclencher une alerte sur les exports massifs. La gestion des identités doit imposer une authentification forte et une élévation temporaire des privilèges pour les accès de réidentification.

La surveillance ne garantit pas l’intention d’une personne. Une connexion tardive peut signaler une exfiltration, une astreinte, une erreur de fuseau horaire ou un café trop ambitieux. Un score de risque ne constitue pas un fait disciplinaire. Toute décision affectant significativement une personne exige une vérification humaine, des éléments contradictoires et une procédure appropriée.

Elle ne garantit pas non plus la couverture complète : les activités hors périmètre, les appareils non gérés, les canaux chiffrés de bout en bout et les attaques sans trace visible échappent partiellement aux capteurs. La réponse ne consiste pas à tout enregistrer. Elle consiste à combiner segmentation réseau, contrôle des accès, sauvegardes testées, détection ciblée et procédures de réponse à incident.

🐝 Ce qui arrive si on s’en passe

Sans ce cadrage, la première perte est judiciaire : un relevé obtenu par un dispositif non déclaré, non consulté ou disproportionné peut être écarté des débats, et la sanction fondée dessus tombe avec lui. Le coût suivant est opérationnel : faute de finalités séparées et de durées par catégorie, chaque demande interne (litige, absence, évaluation) devient recevable, et toute purge ultérieure se heurte aux sauvegardes et aux index déjà peuplés. Pour un attaquant, un entrepôt nominatif sans habilitation ni journalisation des consultations vaut un annuaire d’habitudes : heures de connexion, ressources fréquentées, comptes à privilèges à cibler. Enfin, sans horloges synchronisées ni chaînage, la chronologie d’un incident reste contestable, ce qui retire à la fois la valeur probante et la capacité à reconstituer une intrusion.

🦫 Explication de la marmotte 🍫

Une entreprise peut enregistrer certaines actions réalisées avec ses outils pour protéger ses systèmes : connexions inhabituelles, tentatives d’accès interdites, copie anormale de données ou installation d’un programme dangereux. Ces informations peuvent concerner des salariés, car elles contiennent parfois un nom, une adresse de connexion ou une heure précise.

Avant de mettre ce suivi en place, l’entreprise doit définir ce qu’elle cherche à protéger et pourquoi chaque information est nécessaire. Elle doit prévenir les salariés et consulter leurs représentants lorsque le dispositif contrôle l’activité. Si le suivi est très intrusif ou croise beaucoup d’informations, une étude des risques pour les personnes est nécessaire avant le déploiement.

Les informations collectées doivent être limitées. Au lieu de conserver immédiatement le nom d’une personne, le système peut conserver un identifiant transformé. Le nom ne doit être retrouvé que lors d’un incident justifié, par des personnes autorisées. Les accès à ces informations doivent être enregistrés, et les données supprimées quand leur durée de conservation est terminée.

Si le système collecte trop, conserve trop longtemps ou sert ensuite à juger le travail quotidien, il sort de son objectif de sécurité. Si ses accès sont mal protégés, un attaquant peut aussi exploiter les journaux pour connaître les habitudes et les comptes des salariés. La surveillance protège donc seulement si elle est limitée, contrôlée et vérifiée régulièrement.

Pages voisines

La citent

Surveillance des salariés : cadre légal et limites

Elle cite

: les deux pages se citent l’une l’autre.

Surveillance des salariés : cadre légal et limites

Surveillance des salariés : cadre légal et limites

Légitimité de la surveillance et finalité de sécurité

Information des salariés, CSE et analyse d’impact

Minimisation, pseudonymisation et conservation des journaux

Exemple de pseudonymisation avant indexation

Surface d’attaque et limites du contrôle salarié

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines