Un intranet conforme au RGPD : que surveiller sur les données des collaborateurs ?

Par nature, un intranet traite des données personnelles : nom, fonction, coordonnées, service, demandes de congés, parfois date de naissance et photographie. Ces données relèvent du RGPD — et du KVKK pour les entreprises actives en Turquie — ce qui fait du choix d'un intranet une décision autant juridique que technique.

Cet article est une information générale ; consultez votre conseil juridique pour les obligations propres à votre entreprise.

Commencez par la minimisation

La stratégie de conformité la plus solide, ce sont les données que vous ne traitez pas. La question à poser lors de la mise en place est simple : ce champ est-il vraiment nécessaire ? Si une date de naissance sert aux félicitations, le jour et le mois suffisent, sans l'année. Un numéro de mobile personnel ne devrait pas être collecté tant qu'une ligne professionnelle existe.

Le même principe vaut pour les canaux de notification : ceux qui exigent un numéro personnel doivent être désactivés par défaut et soumis au consentement, tandis que les canaux professionnels peuvent fonctionner sur un modèle d'opposition.

Mentions d'information et versionnage

Les collaborateurs doivent savoir quelles données sont traitées et pourquoi. Un intranet doit le soutenir de deux façons : le texte doit être accessible dans l'application et il doit être versionné. Lors d'une mise à jour, il faut conserver la trace de qui a vu quelle version ; sinon l'information délivrée ne peut pas être prouvée.

Demandes des personnes concernées

Les collaborateurs ont un droit d'accès et de rectification et, dans certains cas, d'effacement. Pour que ces demandes ne se perdent pas dans une boîte mail, un canal traçable dans l'intranet est une nécessité pratique : enregistrement de la demande, responsable, statut et délai de réponse doivent être visibles.

Habilitations : masquer ne suffit pas

L'erreur technique la plus fréquente consiste à masquer un champ dans la seule interface. La restriction réelle appartient à la couche de données ; sinon un utilisateur non habilité atteint l'information par une requête directe. Face à un prestataire, la question est précise : « Qui ne peut pas voir ce champ, et où cette restriction s'applique-t-elle ? » Si la réponse ne pointe que l'interface, elle est insuffisante. Nous décrivons notre approche sur la page sécurité.

La même logique vaut pour l'isolation des locataires : dans un produit mutualisé, l'impossibilité d'atteindre les données d'une autre entreprise doit être garantie au niveau de la base.

Les flux qui exigent l'anonymat

Sur des briques comme un dispositif d'alerte professionnelle, l'anonymat n'est pas une préférence mais une condition d'usage. Le détail critique : l'anonymat ne peut pas être laissé au client. Si la décision « ne pas envoyer l'identité » est prise dans le navigateur, l'enregistrement peut malgré tout arriver avec une identité. Dans une conception correcte, l'identité est retirée côté serveur, au moment de l'écriture.

Un seuil comparable s'applique aux prises de pouls : les résultats ne devraient être présentés qu'agrégés au-delà d'un nombre minimal de répondants, afin que les réponses individuelles ne soient pas déductibles dans les petites équipes.

Durées de conservation et départ

La durée de conservation doit être écrite. Quand le compte d'un partant est fermé, que reste-t-il — ses annonces, les reconnaissances reçues, le matériel qui lui était attribué ? Ces réponses appartiennent au processus de départ, et l'intranet doit pouvoir en suivre les étapes.

Hébergement et sous-traitants

L'emplacement des données, les sous-traitants impliqués et l'existence d'un transfert hors UE doivent être obtenus par écrit avant l'achat. Ces informations font partie intégrante des questions de sécurité de notre guide de sélection.

La preuve : le journal d'audit

La dimension de conformité la plus souvent négligée est que le travail doit être démontrable. Lors d'un contrôle, « nous avons publié la mention d'information » ne suffit pas ; il faut montrer qui a vu quelle version et quand, quand une demande est arrivée et en combien de jours elle a été traitée.

D'où l'importance du périmètre du journal : changements d'habilitation, accès aux données sensibles, exports contenant des données personnelles et suppressions doivent au minimum être consignés. Le journal lui-même doit rendre les altérations détectables ; un registre modifiable après coup n'a aucune valeur probante.

La fonction d'export mérite une attention distincte : un droit permettant de télécharger toute la liste des collaborateurs est en pratique un risque de fuite et ne devrait être ouvert qu'aux rôles qui en ont besoin.

Liste de contrôle

• Chaque champ collecté a-t-il une justification ?
• La mention d'information est-elle versionnée et accessible ?
• Existe-t-il un canal traçable pour les demandes des personnes concernées ?
• Les restrictions sont-elles appliquées dans la couche de données ?
• Dans les flux anonymes, l'identité est-elle retirée côté serveur ?
• Les durées de conservation et le processus de départ sont-ils définis ?

Écrivez-nous pour toute question de conformité.