RGPD et site web : comprendre les données que nous collectons avant de les protéger

Le RGPD est souvent perçu comme une obligation administrative assez floue : un texte à rédiger, quelques cases à cocher, puis une bannière cookies à afficher. Cette lecture est compréhensible, mais elle réduit le sujet à sa partie la plus visible, parfois la moins utile si elle n’est pas reliée au fonctionnement réel du projet.

Dans un projet web, une démarche RGPD peut pourtant devenir un repère beaucoup plus concret. Elle nous oblige à regarder ce que le service fait avec les données : à quel moment elles sont collectées, où elles circulent, qui peut y accéder, combien de temps elles sont conservées, et dans quelles conditions elles sont utilisées ou supprimées.

L’idée de cet article est donc d’explorer ces questions à partir de situations proches de nos pratiques : un site éditorial, une application en ligne, un espace membre, un extranet, une webapp, un outil interne ou une plateforme plus complexe. Les formes changent, mais les mêmes points reviennent souvent : formulaires, hébergement, accès, outils statistiques, prestataires, sauvegardes et services tiers.

L’objectif n’est pas de remplacer les ressources de référence, CNIL en tête, mais de les replacer dans le quotidien d’un projet web. Concevoir, maintenir ou refondre un site demande aussi de suivre le parcours des données : quelles sont-elles ? pourquoi les utilisons-nous ? où passent-elles ? quelles précautions demandent-elles ? C’est cette première cartographie que nous allons construire pas à pas.

Note de cadrage
Cet article est un débroussaillage pédagogique destiné à mieux comprendre les données qui circulent dans un projet web. Il ne constitue pas un avis juridique, ni un guide de conformité exhaustif. Les situations évoquées doivent toujours être adaptées au contexte réel du projet, de la structure, des données traitées et des personnes concernées. Pour toute décision engageante, il reste nécessaire de s’appuyer sur les ressources officielles de la CNIL, sur un DPO, un juriste ou un conseil spécialisé.

Déclaration CNIL ou RGPD : ce qui a changé

Pendant longtemps, beaucoup de sites, d’associations ou de petites structures ont connu la déclaration CNIL. On remplissait un formulaire, on déclarait certains traitements, puis on gardait parfois l’impression que cette démarche suffisait à être “en règle”. Cette habitude explique encore beaucoup de malentendus aujourd’hui.

Avec le RGPD, la logique a changé. Pour la plupart des traitements courants, il ne s’agit plus de déclarer systématiquement un fichier à la CNIL avant d’agir. La CNIL rappelle que la quasi-totalité des formalités déclaratives a été supprimée depuis l’entrée en application du règlement européen, dans sa ressource « Règlement européen : faut-il encore effectuer des déclarations à la CNIL ? ». Pour une lecture plus directe de ce basculement, l’article « Déclaration CNIL : abolie par le RGPD » résume aussi clairement le changement de logique.

Certaines situations particulières existent encore, notamment dans des domaines sensibles comme la santé ou pour certains traitements très encadrés. Mais pour la majorité des projets web, du site éditorial à l’application en ligne, de l’espace membre à la plateforme métier, l’enjeu principal n’est plus la déclaration préalable. Il s’agit plutôt de savoir décrire, sécuriser et justifier ce qui est réellement fait avec les données.

Quelle que soit la situation, cela ne signifie pas que nous n’avons plus rien à faire. Au contraire, le RGPD demande de pouvoir expliquer nos choix : pourquoi nous collectons une donnée, combien de temps nous la conservons, qui peut y accéder, comment elle est protégée et comment les personnes concernées sont informées. La conformité devient donc moins une formalité ponctuelle qu’une organisation à tenir dans le temps.

L’ancien réflexe pouvait se résumer à : “avons-nous déclaré quelque chose ?”. Le réflexe RGPD devrait plutôt devenir : savons-nous ce que nous faisons avec les données, et pouvons-nous le justifier ? C’est là que des outils comme le registre des activités de traitement deviennent utiles, non comme paperasse supplémentaire, mais comme support de compréhension et de suivi.

Alors avec RGPD, de quoi parlons-nous ?

Le RGPD, ou Règlement général sur la protection des données, est une réglementation de l’Union européenne entrée en application le 25 mai 2018. Son objectif est de protéger les données personnelles des personnes physiques et de renforcer leur contrôle sur l’utilisation qui en est faite. Il ne s’agit donc pas seulement d’un texte administratif : c’est un cadre qui demande aux structures de mieux expliquer, limiter, sécuriser et documenter leurs traitements de données.

Il s’applique dès qu’une structure collecte, stocke ou utilise des informations permettant d’identifier une personne, directement ou indirectement. Le non-respect de ces obligations peut exposer à des sanctions, mais l’enjeu quotidien, pour un projet web, commence souvent plus simplement : savoir quelles données sont collectées, pourquoi elles le sont, qui peut y accéder et comment les personnes sont informées.

Une donnée personnelle n’est pas forcément une information intime ou confidentielle. Une adresse e-mail, une adresse IP, un numéro de téléphone, un identifiant de compte ou un message envoyé via un formulaire peuvent déjà entrer dans ce cadre. La CNIL propose d’ailleurs une explication claire pour identifier les données personnelles.

Sur un site comme Pem’s Projects, cela peut commencer très simplement : une personne remplit un formulaire de contact pour poser une question. Son adresse e-mail sert à lui répondre. Son message peut être reçu par mail, enregistré dans une base de données ou conservé dans une sauvegarde. La donnée ne reste donc pas toujours là où nous l’imaginons au départ.

Plusieurs acteurs peuvent alors intervenir. Le responsable de traitement décide pourquoi et comment les données sont utilisées. Le sous-traitant les traite pour son compte : hébergeur, outil de newsletter, prestataire technique ou service de statistiques. La personne concernée, elle, est celle dont les données sont collectées ou utilisées. La CNIL propose une ressource utile pour bien identifier son rôle dans le cadre du RGPD.

Le RGPD ne doit donc pas être vu comme une contrainte ajoutée après coup. Il nous aide à concevoir plus proprement : collecter moins, protéger mieux, informer clairement et documenter nos choix. Autrement dit, il nous pousse à comprendre le fonctionnement réel du site avant de parler de conformité.

Quand un site commence déjà à collecter

Nous mettons en ligne un site, ou une application. Au départ, cela semble parfois presque simple : quelques pages, un formulaire de contact, peut-être des statistiques de visite, un espace d’administration et des sauvegardes côté hébergement. Pourtant, dès ce moment, des données circulent déjà. Certaines sont visibles, parce qu’une personne les saisit elle-même : une adresse e-mail, un nom, le contenu d’un message. D’autres sont plus discrètes : adresse IP, logs serveur, cookies, identifiants de session, sauvegardes ou accès administrateur. Elles ne sont pas toujours visibles dans l’interface, mais elles existent dans le fonctionnement réel du site ou de l’application web.

Le RGPD devient alors une grille de lecture utile. Il ne s’agit pas seulement d’ajouter une bannière cookies ou une page juridique à la fin du projet. Il s’agit d’abord de comprendre quelles données existent, pourquoi nous les collectons, où elles circulent et qui peut y accéder. Pour les repères généraux, la page de la CNIL sur la compréhension du RGPD reste une base fiable.

Dans cet article, nous partirons d’un cas concret : Puce & Média, un site éditorial avec des formulaires, un hébergement, des comptes administrateurs et des outils de maintenance. PEM’s Projects servira parfois de variante plus complexe, avec plusieurs sites, plusieurs outils et une chaîne de responsabilités plus étendue.

Une fois encore, l’objectif n’est pas de remplacer les ressources comme celles de la CNIL avec Comprendre le RGPD, ou avec l’excellent article 5 points pour être conforme au RGPD de Solidatech ou encore Vie privée, données personnelles et RGPG de Framasoft. Nous allons plutôt essayer de les relier à des situations réelles de conception, de maintenance ou de refonte d’un site ou d’une application web, pour mieux comprendre ce que ces principes changent dans la pratique d’un projet web.

Données visibles, données invisibles : ce que le site collecte vraiment

Quand nous regardons un site, nous pensons d’abord aux données que la personne saisit elle-même, comme nous évoquions précédemment : un nom, une adresse e-mail, un numéro de téléphone, un message, une préférence d’inscription ou des identifiants de connexion. Ce sont les données les plus faciles à repérer, parce qu’elles apparaissent directement dans l’interface.

Pour élargir le regard, ouvrons l’onglet Réseau des outils de développement du navigateur (F12). À chaque chargement de page, nous voyons apparaître des requêtes vers le site, mais aussi parfois vers des services externes : polices, scripts, statistiques ou CDN. Les en-têtes HTTP peuvent alors afficher la langue du navigateur, la page d’origine, des cookies, un identifiant de session ou des informations sur le navigateur utilisé. La CNIL rappelle qu’une donnée personnelle peut permettre d’identifier une personne directement ou indirectement : identifier les données personnelles.

Ces éléments semblent techniques, mais ils peuvent renseigner sur une visite, une action ou un contexte de navigation. Avec HTTPS, ils ne sont pas lisibles librement par n’importe qui sur le réseau. En revanche, ils restent visibles par les systèmes qui les reçoivent ou les traitent : serveur, application, journaux techniques, outils de statistiques, hébergeur ou prestataires concernés.

Derrière ces lignes techniques, nous pouvons retrouver des informations très concrètes : la page demandée, l’adresse du site, le navigateur utilisé, la langue préférée, la page depuis laquelle la personne arrive, un cookie de session ou parfois une adresse IP transmise par un serveur intermédiaire. Pris séparément, ces éléments semblent ordinaires. Mis bout à bout, ils peuvent aider à comprendre une visite, reconnaître une session ou reconstituer une partie du parcours de navigation.

Exemple d’en-tête HTTP volontairement simplifié : L’exemple ci-dessous ne doit donc pas être lu comme du code à apprendre, mais comme une fiche de passage : chaque ligne dit quelque chose sur la visite en cours.

GET /article-rgpd.html HTTP/1.1
Host: www.puce-et-media.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36
Accept-Language: fr-FR,fr;q=0.9,en;q=0.8
Referer: https://www.solidatech.fr/ressources-rgpd
Cookie: PHPSESSID=8f3a9c2d1e7; preference_contraste=eleve
X-Forwarded-For: 203.0.113.42

GET /article-rgpd.html HTTP/1.1
Host: www.puce-et-media.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36
Accept-Language: fr-FR,fr;q=0.9,en;q=0.8
Referer: https://www.solidatech.fr/ressources-rgpd
Cookie: PHPSESSID=8f3a9c2d1e7; preference_contraste=eleve
X-Forwarded-For: 203.0.113.42

Il faut enfin distinguer donnée personnelle et donnée sensible. Un numéro de téléphone permet de contacter ou d’identifier quelqu’un : c’est donc une donnée personnelle. Mais ce n’est pas automatiquement une donnée sensible au sens du RGPD, contrairement à certaines informations relatives à la santé, aux opinions politiques, à la religion ou à l’orientation sexuelle, comme l’explique la CNIL dans sa définition de la donnée sensible.

Le risque ne tient pas seulement à la nature d’une donnée, mais aussi à son contexte. Une information banale isolément peut devenir plus délicate si elle est croisée avec d’autres, diffusée trop largement, conservée trop longtemps ou accessible aux mauvaises personnes. C’est une raison de plus pour cartographier les données avant de prétendre les protéger.

Donnée personnelle ne veut pas dire donnée sensible
Une adresse e-mail, un numéro de téléphone ou une adresse IP sont des données personnelles. Elles ne sont pas forcément sensibles au sens juridique, mais elles doivent tout de même être justifiées, protégées et conservées pendant une durée limitée. Leur contexte peut toutefois changer notre niveau de vigilance : le numéro de téléphone d’un commerce, d’un bénévole, d’un parent, d’un mineur ou d’une personne exposée ne présente pas les mêmes risques en cas de diffusion ou d’usage détourné. Les conséquences peuvent être très concrètes : sollicitations non souhaitées, pression sur une personne, tentative d’usurpation, mise en relation non désirée, exposition d’un enfant ou perte de confidentialité dans une situation personnelle délicate.

Avant de collecter : finalité, utilité, durée de conservation

Avant d’ajouter un champ dans un formulaire, une question simple devrait nous arrêter : à quoi cette donnée va-t-elle servir ? Le RGPD nous demande de collecter des données pour une finalité claire, légitime et compréhensible. Autrement dit, nous devons pouvoir expliquer pourquoi nous demandons une information, et ce que nous allons en faire.

À cela s’ajoutent des zones que nous oublions facilement : les en-têtes d’e-mails, les métadonnées de fichiers, les sauvegardes, les exports de base de données ou les copies utilisées pendant une maintenance. Une donnée ne disparaît pas forcément parce qu’elle n’est plus affichée dans l’interface d’administration.

Dans un formulaire de contact, demander une adresse e-mail est cohérent : elle permet de répondre à la personne. Le nom peut aider à personnaliser l’échange. En revanche, rendre obligatoire un numéro de téléphone, une adresse postale ou une date de naissance demande une justification plus solide. Si nous n’en avons pas besoin, mieux vaut ne pas les collecter.

Le même raisonnement s’applique à une newsletter. L’adresse e-mail est nécessaire pour envoyer les messages. Le nom peut être utile, mais il n’est pas toujours indispensable. Le consentement doit être clair, et la désinscription simple. La page de la CNIL sur les grands principes du RGPD permet de retrouver ces repères sans entrer trop vite dans le détail juridique.

Pour les statistiques, la question devient : avons-nous besoin de suivre individuellement les visiteurs, ou une mesure d’audience globale suffit-elle ? Si nous voulons seulement comprendre quelles pages sont consultées, un outil sobre ou une configuration anonymisée peut parfois répondre au besoin. Le choix de l’outil devrait venir après la question, pas avant.

Collecter moins, c’est souvent protéger mieux. Chaque donnée doit avoir une finalité, une utilité réelle et une durée de conservation prévue. Garder des messages, des exports ou des statistiques indéfiniment “au cas où” crée un risque inutile. C’est précisément ce type d’information que l’on pourra ensuite reporter dans un registre des activités de traitement, non pour faire de la paperasse, mais pour garder une trace claire de nos choix.

Désigner un pilote RGPD : ne pas laisser le sujet sans responsable

Après la logique de déclaration CNIL, une autre idée doit évoluer : le RGPD ne se résume pas à un document rempli une fois pour toutes. Il demande un suivi dans le temps. Même dans une petite structure, il est donc utile de désigner une personne référente, c’est-à-dire une personne chargée de garder une vision claire des données, des outils utilisés et des actions à mener. Ce pilote n’est pas toujours un DPO, délégué à la protection des données. Le DPO est obligatoire dans certains cas précis, par exemple pour certains organismes publics ou pour des traitements réguliers et systématiques à grande échelle. La CNIL rappelle que sa désignation dépend du contexte, et qu’un DPO doit disposer de compétences, de moyens et d’un positionnement adapté.

Dans une petite structure éditoriale, il ne s’agit pas forcément de nommer un DPO. Le besoin immédiat est souvent plus simple : désigner une personne qui pilote le dossier RGPD, suit les points à vérifier et garde une vision claire de l’existant. Cette personne doit savoir où se trouvent les informations importantes. Quels formulaires existent ? Quels outils statistiques sont utilisés ? Où sont les sauvegardes ? Qui a accès à l’hébergement ? Où sont les mentions légales, la politique de confidentialité et les informations données aux visiteurs ?

Ce rôle demande rarement de travailler seul. Le pilote doit pouvoir s’appuyer sur les personnes qui connaissent le site : responsable éditorial, développeur, hébergeur, prestataire de maintenance, personne chargée de la newsletter ou des outils de statistiques. Le RGPD devient alors un travail d’organisation, pas seulement une affaire juridique.

Son premier socle peut rester très concret : commencer à tenir un registre des traitements, vérifier les pages d’information, recenser les sous-traitants, suivre les accès sensibles et garder une trace des décisions prises. La CNIL recommande justement de cartographier les traitements et de documenter la conformité pour pouvoir expliquer ce qui est fait et le mettre à jour dans le temps.

Le registre : mettre noir sur blanc ce que nous faisons des données

Le registre des activités de traitement peut sembler administratif au premier abord. Pourtant, pour un projet web, il joue un rôle très concret : il nous aide à rassembler au même endroit les informations essentielles sur les données collectées, leur usage, leur stockage, leur durée de conservation et les personnes qui peuvent y accéder.

Il faut toutefois garder à l’esprit une nuance importante : le registre ne décrit pas forcément chaque donnée isolément. Il fonctionne plutôt par traitement : formulaire de contact, newsletter, statistiques, gestion des comptes administrateurs, sauvegardes. Pour chaque traitement, nous indiquons les catégories de données concernées, leur finalité, les outils utilisés, les accès, les durées et les mesures de protection prévues.

Pour un formulaire de contact, par exemple, le registre permet de noter la finalité du traitement : recevoir une demande et y répondre. Il précise les données concernées, comme le nom, l’adresse e-mail ou le contenu du message, mais aussi les endroits où elles peuvent se retrouver : boîte mail, base de données, sauvegardes, hébergement ou outil de gestion. Ces questions rejoignent directement la ressource de la CNIL sur le registre des activités de traitement.

Pour préparer ce registre, nous pouvons aussi tenir une cartographie plus fine, donnée par donnée. Ce tableau n’est pas forcément le registre officiel, mais un outil de travail très utile pour comprendre le site : où apparaît une donnée, pourquoi elle est collectée, où elle est stockée, combien de temps elle est conservée et qui peut y accéder. Cette étape aide souvent à repérer des copies oubliées, des sauvegardes anciennes ou des outils tiers que nous n’avions pas vraiment intégrés au raisonnement.

Pour Puce & Média, le registre pourrait rester simple : formulaire de contact, éventuelles statistiques, comptes administrateurs, sauvegardes. Pour PEM’s Projects, il deviendrait plus utile encore, car plusieurs sites et/ou applications, services ou outils peuvent être impliqués. Plus le projet se disperse, plus la cartographie devient nécessaire.

Cookies et traceurs : comprendre avant d’installer une bannière

Les cookies et autres traceurs sont souvent résumés à une bannière à afficher. C’est trompeur. Une bannière ne rend pas un site conforme à elle seule : elle sert seulement à informer et, lorsque c’est nécessaire, à recueillir un choix. Avant de l’installer, nous devons surtout comprendre ce qui se déclenche lorsqu’une personne arrive sur une page. La CNIL rappelle dans sa ressource « Les règles à suivre pour les cookies » que certains traceurs peuvent exiger un consentement préalable, tandis que d’autres peuvent en être dispensés selon leur usage. Voir aussi « Cookies et traceurs : que dit la loi ? » qui permet de distinguer les traceurs qui demandent un consentement de ceux qui peuvent, dans certains cas, en être exemptés.

La première question est donc très concrète : le site dépose-t-il quelque chose dans le navigateur ? Un cookie de session peut permettre de maintenir une connexion. Un cookie de préférence peut mémoriser une langue ou un choix d’affichage. Certains traceurs sont strictement nécessaires au fonctionnement demandé par l’utilisateur ; d’autres servent à mesurer l’audience, à afficher des contenus externes ou à suivre la navigation à des fins publicitaires. Ils ne répondent pas tous au même besoin, et ne se traitent donc pas tous de la même manière.

Sur un site comme Pem’s Projects, le cas le plus courant serait la mesure d’audience : comprendre quelles pages sont lues, repérer des erreurs, améliorer la navigation. Mais avons-nous besoin d’identifier individuellement les visiteurs ? De transmettre des informations à un service tiers ? De suivre une personne d’un site à l’autre ? Dans « Cookies : solutions pour les outils de mesure d’audience », la CNIL précise que certains traceurs de mesure d’audience peuvent être exemptés de consentement seulement sous conditions, notamment lorsqu’ils servent à produire des statistiques anonymes pour le compte exclusif de l’éditeur. Pour ne pas rester dans l’abstrait, l’onglet Stockage > Cookies des outils de développement permet de vérifier quels cookies sont réellement présents sur une page. C’est une première étape utile avant de décider si une bannière, un paramétrage ou un consentement spécifique est nécessaire.

Les contenus embarqués méritent aussi notre attention. Une vidéo, une carte interactive ou un service de géolocalisation, une police de caractères externe, un bouton de partage social, un fil intégré depuis un réseau social ou même certains outils statistiques peuvent appeler des ressources depuis une plateforme tierce. Dans ce cas, la question n’est plus seulement “avons-nous des cookies ?”, mais aussi : quelles plateformes sont contactées, quelles informations reçoivent-elles et à quel moment ? C’est exactement le type de point que l’onglet Réseau du navigateur peut aider à repérer.

Avant de choisir une bannière, il faut donc faire l’inventaire : quels cookies existent ? à quoi servent-ils ? sont-ils nécessaires ? demandent-ils un consentement ? transmettent-ils des données à des tiers ? Une bannière mal configurée peut donner une impression de conformité sans rien résoudre. Mieux vaut d’abord cartographier les traceurs, puis vérifier, à partir des recommandations de la CNIL et du contexte réel du site, quelles informations fournir et quels mécanismes de consentement prévoir.

Une bannière cookies ne remplace pas une réflexion sur les données
Avant d’afficher une bannière, il faut savoir quels cookies existent, à quoi ils servent, s’ils sont nécessaires, et s’ils transmettent des informations à des tiers.

Sécuriser les accès : mots de passe, double authentification et comptes administrateurs

Protéger les données commence souvent par une question très simple : qui peut entrer dans le système ? Avant même de parler de chiffrement avancé ou d’architecture complexe, il faut vérifier les portes d’entrée du site : compte administrateur du site, du CMS, de l’application, espace client de l’hébergeur, accès FTP ou SFTP, SSH, phpMyAdmin, outil de newsletter, statistiques, stockage cloud et sauvegardes. Plusieurs de ces sujets sont abordés dans la rubrique Sécurité de Puce & Média, à compléter selon les outils réellement utilisés par le projet.

Un compte administrateur compromis peut donner accès à bien plus qu’une interface de publication. Selon les droits associés, il peut permettre de consulter des formulaires, modifier des extensions, exporter une base de données, récupérer des sauvegardes ou créer un nouvel utilisateur. Un simple mot de passe faible ou réutilisé peut donc devenir un point de bascule pour tout le site.

Le premier réflexe consiste à utiliser des comptes nominatifs plutôt qu’un compte partagé. Chaque personne doit disposer de son propre accès, avec les droits strictement nécessaires à son rôle. Un rédacteur n’a pas forcément besoin d’un accès administrateur complet, un prestataire ponctuel n’a pas vocation à conserver ses droits indéfiniment, et les anciens comptes doivent être désactivés dès qu’ils ne sont plus utiles.

La double authentification devrait être activée dès que possible, en particulier sur les comptes sensibles : administration du CMS, de l’application, hébergement, base de données, newsletter, statistiques ou stockage des sauvegardes. La CNIL propose « Authentification multifacteur : les recommandations de la CNIL pour mieux protéger les données », utile pour comprendre pourquoi un second facteur peut limiter les conséquences d’un mot de passe compromis.

Pour certaines actions, une simple déclaration ne suffit pas toujours. Lorsqu’une personne crée un compte, modifie son adresse e-mail, demande l’accès à des données, récupère un mot de passe ou souhaite obtenir une information importante, le service devrait prévoir une vérification adaptée : lien envoyé par e-mail, confirmation depuis l’espace connecté, double authentification ou autre mécanisme proportionné au risque. L’objectif n’est pas de compliquer inutilement le parcours, mais d’éviter qu’une personne puisse accéder aux données d’une autre ou modifier une information sensible sans contrôle suffisant.

Il faut aussi éviter les mauvaises habitudes discrètes : mots de passe stockés dans un document non protégé, mêmes identifiants partagés entre plusieurs outils, accès FTP laissés ouverts, droits SQL trop larges, anciennes clés SSH oubliées. Le  « Guide de la sécurité des données personnelles : nouvelle édition 2024 » de la CNIL rappelle que la sécurité repose d’abord sur des mesures adaptées, suivies et réellement appliquées. Il faut aussi savoir quoi faire si un accès est compromis : identifier les données concernées, documenter l’incident, corriger la faille et vérifier si une notification est nécessaire.

La double authentification n’est pas une option de confort
Sur un compte administrateur, elle peut éviter qu’un simple mot de passe compromis ouvre l’accès à tout le système, aux données, aux sauvegardes ou aux outils associés.

Hachage, chiffrement : protéger les données selon leur usage

Quand nous parlons de protéger des données, le mot “cryptage” revient souvent. Il est courant, mais le terme plus juste est chiffrement. La CNIL distingue clairement le chiffrement, le hachage et la signature : le chiffrement vise la confidentialité, tandis que le hachage produit une empreinte qui ne doit pas permettre de retrouver la donnée d’origine. La ressource Sécurité : chiffrement, hachage, signature permet de poser ce vocabulaire proprement voir aussi « Chiffrement vs Cryptage ».

Un mot de passe ne doit jamais être stocké en clair. Mais il ne doit pas non plus être chiffré pour être relu plus tard. Le bon principe consiste à le hacher avec une fonction adaptée : lors de la connexion, le site compare l’empreinte du mot de passe saisi avec celle qui est enregistrée. Le mot de passe original n’a donc pas besoin d’être connu par le système. La CNIL rappelle dans son  « Guide pratique RGPD  – Sécurité des données personnelles – Version 2024 » que les mots de passe doivent être stockés transformés par une fonction de hachage spécifiquement conçue pour cet usage.

Le chiffrement, lui, concerne plutôt les données que nous devons pouvoir relire dans un cadre contrôlé : une archive, une sauvegarde, un jeton d’accès, un export sensible ou certaines informations métier. Dans ce cas, la question ne porte pas seulement sur l’algorithme utilisé, mais aussi sur la clé : où est-elle stockée, qui peut l’utiliser, comment est-elle protégée, et que se passe-t-il si le compte administrateur est compromis ? France Num propose une introduction claire avec Le chiffrement des données : une protection indispensable pour les TPE PME.

Le bloc ci-dessous n’est pas un script à exécuter tel quel. Il sert uniquement à comparer plusieurs formes possibles d’une donnée : texte en clair, hachage faible, hachage adapté et donnée chiffrée.

<?php
/*

Pour un mot de passe, l’objectif n’est pas de pouvoir le relire plus tard, mais de vérifier qu’une saisie correspond bien à l’empreinte enregistrée. Le petit exemple ci-dessous compare plusieurs formes possibles : texte en clair, hachage faible, hachage adapté et donnée chiffrée.

*/
// Ne jamais stocker un mot de passe en clair.
$motDePasse = 'Myrt1lle!Ciel-2026#Atelier';

// 1. Mot de passe en clair
// Lisible directement : à ne jamais stocker en base de données.
Myrt1lle!Ciel-2026#Atelier

// 2. Hachage MD5
// Mauvais exemple : MD5 est trop rapide et trop faible pour stocker des mots de passe.
$hashMd5 = md5($motDePasse);
34b66639b11c65d92fdcc09a035ebc32

// 3. Hachage moderne avec PHP
// password_hash() utilise un algorithme adapté au stockage des mots de passe.
// Le résultat change à chaque génération grâce au sel intégré.
$hashRobuste = password_hash($motDePasse, PASSWORD_DEFAULT);
$2y$10$h3L4gXg6cK1mR9vY8bPzUe7OaQ7V9vGm3nX2eJkR5sA1cD0fT6p8W

// 4. Exemple de donnée chiffrée
// Ici, la donnée est rendue illisible.
// Elle peut être déchiffrée seulement si l’on possède la clé.
// Ce principe est différent du hachage, qui lui ne permet plus de retrouver la valeur d’origine.
$donneeAChiffrer = 'contact-prive@example.org';
u4G7nP9sQ2xL0aZ8cV1rT6bK3mE5yHhDqWfN==

/*



Ces exemples servent à comparer les formes que peut prendre une donnée. Le mot de passe en clair est lisible : il ne doit jamais être stocké ainsi. Le hachage MD5 produit une empreinte, mais il est trop faible pour les mots de passe. Avec password_hash(), PHP génère une empreinte plus adaptée, différente à chaque génération grâce au sel intégré. Enfin, la donnée chiffrée est illisible, mais elle peut être retrouvée si l’on possède la clé : c’est ce qui distingue le chiffrement du hachage.

*/
?>

<?php
/*

Pour un mot de passe, l’objectif n’est pas de pouvoir le relire plus tard, mais de vérifier qu’une saisie correspond bien à l’empreinte enregistrée. Le petit exemple ci-dessous compare plusieurs formes possibles : texte en clair, hachage faible, hachage adapté et donnée chiffrée.

*/
// Ne jamais stocker un mot de passe en clair.
$motDePasse = 'Myrt1lle!Ciel-2026#Atelier';

// 1. Mot de passe en clair
// Lisible directement : à ne jamais stocker en base de données.
Myrt1lle!Ciel-2026#Atelier

// 2. Hachage MD5
// Mauvais exemple : MD5 est trop rapide et trop faible pour stocker des mots de passe.
$hashMd5 = md5($motDePasse);
34b66639b11c65d92fdcc09a035ebc32

// 3. Hachage moderne avec PHP
// password_hash() utilise un algorithme adapté au stockage des mots de passe.
// Le résultat change à chaque génération grâce au sel intégré.
$hashRobuste = password_hash($motDePasse, PASSWORD_DEFAULT);
$2y$10$h3L4gXg6cK1mR9vY8bPzUe7OaQ7V9vGm3nX2eJkR5sA1cD0fT6p8W

// 4. Exemple de donnée chiffrée
// Ici, la donnée est rendue illisible.
// Elle peut être déchiffrée seulement si l’on possède la clé.
// Ce principe est différent du hachage, qui lui ne permet plus de retrouver la valeur d’origine.
$donneeAChiffrer = 'contact-prive@example.org';
u4G7nP9sQ2xL0aZ8cV1rT6bK3mE5yHhDqWfN==

/*



Ces exemples servent à comparer les formes que peut prendre une donnée. Le mot de passe en clair est lisible : il ne doit jamais être stocké ainsi. Le hachage MD5 produit une empreinte, mais il est trop faible pour les mots de passe. Avec password_hash(), PHP génère une empreinte plus adaptée, différente à chaque génération grâce au sel intégré. Enfin, la donnée chiffrée est illisible, mais elle peut être retrouvée si l’on possède la clé : c’est ce qui distingue le chiffrement du hachage.

*/
?>

Chiffrer ne suffit donc pas si les accès sont mal gérés. Une donnée chiffrée avec une clé stockée au même endroit, accessible au même compte compromis, reste fragile. Le chiffrement, le hachage et les bonnes pratiques d’accès doivent fonctionner ensemble. Pour un cadrage plus global, la CNIL propose aussi Sécurité des données : les mesures d’hygiène pour protéger votre système d’information. Pour une ressource plus technique côté développement, l’OWASP propose la fiche Password Storage Cheat Sheet, qui détaille les bonnes pratiques de stockage des mots de passe.

Base de données : limiter, protéger, chiffrer quand c’est nécessaire

La base de données ne doit pas être vue comme un coffre magique où l’on peut tout déposer sans se poser de questions. Une base trop bavarde, mal protégée, trop ouverte ou conservée trop longtemps devient vite un point de fragilité. Le premier réflexe reste donc simple : ne pas stocker ce qui n’est pas utile.

Pour un site comme Puce & Média, cela concerne les messages de contact, les comptes administrateurs, les éventuelles statistiques ou les préférences d’inscription. Avec PEM’s Projects, la question devient plus large : plusieurs bases, plusieurs accès, des sauvegardes, des exports et parfois des échanges transversaux entre sites. Avant d’ajouter une table, un champ ou une synchronisation, nous devons savoir pourquoi cette information est enregistrée, qui peut la consulter, où elle circule et combien de temps elle doit rester en base.

La protection passe aussi par l’organisation des environnements. Un site devrait distinguer le local, la préproduction et la production, afin d’éviter de manipuler des données réelles dans des espaces de test mal maîtrisés. Il faut aussi limiter les droits des comptes SQL : un même utilisateur ne devrait pas tout faire partout, et un compte prévu pour lire certaines données n’a pas toujours besoin de pouvoir modifier ou supprimer toute la base. Pour prolonger ce point côté pratique, nous pouvons revenir aux sections « Créer une base de données et définir ses accès » et « Accès et paramètres de connexion : structurer les utilisateurs et affiner leurs droits ».

Certaines erreurs très simples créent pourtant de vrais risques : afficher les erreurs SQL en production, laisser un export .sql dans un dossier public, conserver une sauvegarde non protégée, oublier une ancienne base de test ou partager un accès phpMyAdmin trop largement. Le guide de la CNIL sur la sécurité des données personnelles rappelle l’importance de mesures adaptées, suivies et documentées.

Il faut enfin distinguer plusieurs protections. Les mots de passe doivent être hachés, comme nous venons de le voir, et non chiffrés pour être relus. Certaines données peuvent, elles, être chiffrées si leur lecture doit rester exceptionnelle ou contrôlée. Les sauvegardes doivent être protégées, les échanges sécurisés avec HTTPS, SFTP ou SSH, et les données anciennes doivent faire l’objet d’une purge prévue. Pour prolonger ces réflexes, la CNIL propose aussi une ressource dédiée : Sécurité : protéger les données.

Une base protégée n’est pas seulement une base chiffrée
La sécurité repose aussi sur les droits d’accès, les sauvegardes, les exports, les environnements de test, les durées de conservation et la capacité à supprimer ce qui n’a plus de raison d’être conservé.

Client, développeur, hébergeur : comprendre la chaîne de responsabilités

Dans un projet web, les données ne sont pas seulement “dans le site”. Elles circulent entre plusieurs acteurs : la structure qui porte le projet, la personne qui développe ou maintient le site, l’hébergeur, parfois un outil de newsletter, de statistiques, de paiement, de support ou de stockage cloud. Pour avancer proprement, il faut donc clarifier qui décide, qui accède, qui héberge et qui maintient.

Le responsable de traitement est généralement celui qui décide pourquoi les données sont collectées et comment elles seront utilisées. Dans beaucoup de cas, il s’agit du client, de l’association, de l’entreprise ou de la structure éditrice du site. La CNIL propose une ressource utile pour bien identifier son rôle dans le cadre du RGPD, notamment lorsque plusieurs acteurs interviennent.

Le développeur, le freelance ou le prestataire technique peut devenir sous-traitant lorsqu’il traite des données pour le compte du responsable de traitement. C’est le cas s’il accède à la base, consulte des sauvegardes, réalise une migration, corrige un bug sur des données réelles ou intervient dans l’administration du site. Il ne manipule alors pas seulement du code : il peut aussi accéder à des données personnelles.

L’hébergeur est lui aussi généralement sous-traitant, puisqu’il héberge les fichiers, les bases, les sauvegardes et les journaux techniques pour le compte du responsable de traitement. Les outils tiers doivent être regardés avec la même attention : newsletter, statistiques, formulaires externes, CRM, paiement, support ou cloud. La page de la CNIL sur le rôle du sous-traitant permet de mieux comprendre ces obligations.

Dans un cas simple comme Puce & Média, cette chaîne peut rester assez lisible : un site, un hébergeur, quelques accès techniques, éventuellement un prestataire ponctuel. Avec PEM’s Projects, elle peut devenir plus dense : plusieurs sites, plusieurs outils, plusieurs bases, plusieurs accès et parfois des échanges entre services. Il devient alors nécessaire de prévoir des contrats, des clauses ou des accords de sous-traitance adaptés, sans forcément entrer ici dans leur rédaction juridique complète.

Informer les personnes : politique de confidentialité, mentions et droits

Informer les personnes ne consiste pas à publier une page juridique obscure que personne ne lit. Lorsqu’une personne utilise un site, elle doit pouvoir comprendre quelles données sont collectées, pourquoi elles le sont, qui peut les recevoir, combien de temps elles sont conservées et comment exercer ses droits. La CNIL propose des exemples de mentions d’information, mais rappelle qu’ils doivent être adaptés au contexte réel du traitement.

Cette information doit apparaître au bon moment. Dans un formulaire de contact, par exemple, il est préférable d’indiquer clairement à quoi sert l’adresse e-mail, combien de temps le message sera conservé et qui contacter pour une demande liée aux données personnelles. Une personne doit aussi savoir comment demander l’accès à ses données, leur rectification, leur suppression ou s’opposer à certains traitements lorsque le contexte le permet. La politique de confidentialité peut ensuite détailler l’ensemble, mais elle ne doit pas être le seul endroit où l’information existe.

Pour que les droits soient réellement exerçables, cette information devrait aussi indiquer un moyen de contact clair pour exercer ses droits : adresse e-mail dédiée, formulaire de contact, adresse postale ou autre canal réellement suivi. Il ne suffit pas d’écrire que les personnes disposent d’un droit d’accès, de rectification ou de suppression ; elles doivent comprendre à qui s’adresser, comment formuler leur demande et, si nécessaire, comment leur identité pourra être vérifiée avant de transmettre ou modifier des données importantes « Exemples de formulaire de collecte de données à caractère personnel ».

Cette clarté concerne aussi la forme. Une information sur les données personnelles ne devrait pas être noyée dans un long bloc juridique, écrite dans une police trop petite, masquée derrière un lien peu visible ou difficile à comprendre avec un lecteur d’écran. L’accessibilité participe donc directement à l’information des personnes : titres structurés, liens explicites, contrastes suffisants, langage compréhensible, formulaires correctement étiquetés et messages d’erreur lisibles. Sur Puce & Média, plusieurs articles de la rubrique Accessibilité permettent justement de prolonger ce point.

Il faut aussi éviter les promesses trop générales. Écrire que “nous ne collectons aucune donnée” alors que le site utilise des logs serveur, des cookies techniques, un outil de statistiques ou un service tiers crée un décalage entre le texte et la réalité. Une politique de confidentialité fiable doit correspondre au fonctionnement réel du site, pas à l’image que nous aimerions en donner.

Les mentions légales, la politique de confidentialité et les éventuelles informations sur les cookies n’ont pas exactement le même rôle. Les mentions légales permettent notamment d’identifier l’éditeur et l’hébergeur. La politique de confidentialité explique les traitements de données. L’information sur les cookies précise quels traceurs sont utilisés, pour quoi faire, et comment les accepter, les refuser ou les paramétrer. Pour éviter de tout mélanger, nous leur consacrerons le chapitre suivant : chacune de ces pages répond à un besoin différent, même si elles participent toutes à une information plus claire des personnes.

Un bon exemple d’approche accessible se trouve du côté de Framasoft. La page Vie privée, données personnelles et RGPD de Frama.space documente la démarche de manière compréhensible, et le site FramaRGPD montre comment une organisation peut rendre visible son travail de conformité, avec ses limites et ses choix. Ce n’est pas un modèle à copier, mais une source d’inspiration pour produire une information claire, honnête et vérifiable.

CGU, CGV, mentions légales, confidentialité : des pages différentes pour des besoins différents

Les pages “légales” d’un site sont souvent regroupées dans le pied de page, mais elles ne disent pas toutes la même chose. Dans ce chapitre, nous allons surtout les distinguer à partir de cas courants : les mentions légales, la politique de confidentialité, les CGU, les CGV, les informations sur les cookies et les règles de réutilisation des contenus. Certains exemples pourront s’appuyer sur Puce & Média ou PEM’s Projects, mais l’objectif n’est pas de reproduire leurs pages telles quelles : il s’agit plutôt de comprendre à quel besoin répond chaque document.

• Les mentions légales servent d’abord à identifier l’éditeur du site, le responsable de publication et l’hébergeur. Dès qu’un site, ou une application en ligne, est porté par une activité identifiée, entreprise, indépendant, association, collectivité ou projet éditorial structuré, ces informations doivent être facilement accessibles, comme le rappelle « Mentions obligatoires sur le site internet d’un entrepreneur individuel ».
• La politique de confidentialité, elle, répond à une autre question : que faisons-nous des données personnelles ? Elle doit expliquer les traitements, les finalités, les destinataires, les durées de conservation, les droits des personnes et le moyen de contact. Les exemples de la CNIL peuvent aider, mais ils doivent être adaptés au fonctionnement réel du projet web, et non copiés-collés comme des modèles universels « RGPD : exemples de mentions d’information ».
• Les CGU, ou conditions générales d’utilisation, encadrent l’usage d’un service : espace membre, compte utilisateur, outil en ligne, plateforme, commentaires, API ou application web. Elles ne remplacent pas les mentions légales ni la politique de confidentialité. France Num rappelle aussi qu’il ne faut pas les confondre avec les CGV, qui concernent la vente : commande, prix, paiement, livraison, rétractation, garanties ou service après-vente « Rédiger des conditions générales d’utilisation (CGU) pour son site internet ».
• Une case “J’ai lu et j’accepte les CGU” ne doit pas être confondue avec un consentement général au traitement des données. Les CGU encadrent l’usage du service ; la politique de confidentialité explique ce qui est fait avec les données personnelles. Lorsqu’un consentement spécifique est nécessaire, par exemple pour une newsletter, une prospection ou certains traceurs, il doit être demandé séparément, de manière claire et compréhensible. La ressource de la CNIL « Conformité RGPD : comment recueillir le consentement des personnes ? » permet d’approfondir ce cadre général. Dans un cas plus concret, comme la prospection par e-mail, SMS-MMS ou automate d’appel, la CNIL rappelle aussi que les cases pré-cochées ne permettent pas de recueillir un consentement valable.
• Les CGV, ou conditions générales de vente, concernent une autre situation : la vente d’un produit, d’un service, d’un abonnement, d’une formation, d’un téléchargement payant ou d’une prestation commandée en ligne. Les CGV doivent notamment préciser, selon l’activité et le public concerné, les conditions de commande, les prix, les modalités de paiement, la livraison ou l’exécution du service, la rétractation, les garanties et le traitement des litiges. Un site éditorial simple n’en a pas forcément besoin, mais dès qu’un paiement ou une commande est proposé, la question des CGV devient un point à vérifier sérieusement.
• Le copyright ou, plus largement, le droit d’auteur, concerne encore autre chose : les textes, images, codes, bases de données, ressources graphiques, licences et conditions de réutilisation. Sur Puce & Média, une mention de droit d’auteur peut indiquer que les contenus sont protégés, mais elle ne remplace pas une information sur l’éditeur, l’hébergeur ou les traitements de données. Explorez également « Code de la propriété intellectuelle » sur Légifrance.
• Une FAQ peut aussi jouer un rôle utile : la FAQ ne remplace pas les pages de référence, mais elle peut aider les personnes à s’orienter vers le bon endroit selon leur question, par exemple les mentions légales, la politique de confidentialité, les cookies, les CGU ou les règles de réutilisation des contenus.

Avec PEM’s Projects, nous voyons mieux l’intérêt de séparer ces pages : les mentions légales identifient les structures et l’hébergement, tandis que le pied de page renvoie aussi vers la politique de confidentialité, les conditions d’utilisation, la gestion des cookies et la FAQ. Cette dernière peut jouer un rôle d’orientation : elle ne remplace pas les pages de référence, mais elle aide à guider les personnes vers la bonne ressource selon leur question.

Ne pas tout mélanger
Les mentions légales ne remplacent pas une politique de confidentialité. Les CGU ne remplacent pas des CGV. Et aucune de ces pages ne dispense de réfléchir réellement aux données collectées, aux outils utilisés et aux droits des personnes.

Métadonnées, logs, fichiers : les données que l’on oublie facilement

Certaines données ne viennent pas d’un formulaire. Elles se cachent dans les fichiers, les journaux techniques, les exports ou les paramètres d’une URL. Une photo envoyée via un formulaire peut contenir des données EXIF. Un PDF peut garder un nom d’auteur, une organisation ou des informations de création. Pour prolonger ce point, on peut se reporter aux ressources sur la modification, la présentation et la gestion des métadonnées dans les documents « Modification des métadonnées de document », « Présentation des concepts des métadonnées » et « Métadonnées dans Assets Essentials ». Un e-mail transporte lui aussi des en-têtes techniques qui racontent une partie de son parcours.

Les logs serveur sont un autre exemple fréquent. Ils peuvent contenir une adresse IP, une date, une page appelée, un code d’erreur, un navigateur ou une URL complète. C’est utile pour diagnostiquer une panne, repérer une attaque ou comprendre un dysfonctionnement. Mais ces journaux ne doivent pas être oubliés dans un coin : ils font partie des éléments à regarder lorsque nous cartographions les données du site. Les fichiers de travail méritent la même attention. Un export CSV ou SQL peut rester dans un dossier temporaire. Une sauvegarde peut contenir d’anciens messages. Un fichier transmis pour une maintenance peut embarquer des données réelles. Une donnée ne pose pas seulement problème lorsqu’elle est volée : elle peut aussi poser problème lorsqu’elle est conservée trop longtemps, transmise sans attention ou réutilisée hors contexte.

Ces éléments peuvent sembler secondaires, mais ils méritent notre attention. Un fichier oublié dans un dossier public, un export transmis par e-mail, une sauvegarde conservée trop longtemps ou une métadonnée laissée dans un document peuvent révéler des informations qui n’étaient pas destinées à être diffusées. Ce sujet rejoint la question plus large des métadonnées. Elles ne sont pas toujours visibles au premier regard, mais elles peuvent donner du contexte : qui a créé un fichier, avec quel outil, à quelle date, parfois depuis quel appareil. Pour prolonger cette réflexion sans dévier du RGPD, nous pouvons revenir à l’article « Métadonnées : parler aux humains et aux intelligences artificielles », qui montre comment ces informations accompagnent les contenus.

Le bon réflexe consiste donc à élargir notre vérification : formulaires, bases de données, mais aussi fichiers, logs, exports, sauvegardes, pièces jointes et outils de maintenance. Des ressources critiques comme celles de La Quadrature du Net sur le RGPD peuvent aussi aider à prendre du recul sur les usages contestés des données, le profilage ou la surveillance. Dans la même veine, l’entretien « Métadonnées, l’arme invisible, Sommes-nous déjà tous fichés ? » avec Alexis Roussel, diffusé par Thinkerview, ouvre une réflexion utile sur ce que les traces techniques peuvent révéler lorsqu’elles sont croisées, conservées ou exploitées à grande échelle. Ici encore, l’objectif reste concret : savoir ce que nous conservons, pourquoi, où, et pendant combien de temps.

Images, audio et vidéo : des données parfois plus sensibles qu’on ne le pense

Quand nous parlons de données personnelles, nous pensons souvent aux champs d’un formulaire : nom, e-mail, téléphone, message. Pourtant, une image, une voix ou une vidéo peuvent aussi permettre d’identifier une personne. Une photo de profil, une captation d’événement, un témoignage audio ou une vidéo intégrée dans une page ne sont donc pas de simples contenus médias.

Une photo peut montrer un visage, un lieu, une situation, parfois même des éléments très contextuels : badge, plaque, écran, document en arrière-plan. Une vidéo peut aller plus loin encore : elle montre une personne dans une activité, un environnement, un moment précis. Une voix enregistrée peut aussi reconnaître quelqu’un, surtout lorsqu’elle est associée à un nom, un rôle ou un témoignage publié.

Le sujet apparaît aussi dans les formulaires avec dépôt de fichiers. Une personne peut envoyer un CV, une photo, un PDF, une capture d’écran ou un document contenant des informations personnelles. Le fichier lui-même peut contenir des données visibles, mais aussi des métadonnées : auteur, date, logiciel utilisé, appareil, parfois localisation selon le format et le contexte.

Il faut également regarder où ces médias sont stockés et diffusés. Une vidéo peut être hébergée localement, placée dans une médiathèque WordPress, envoyée dans un stockage cloud ou intégrée depuis une plateforme tierce Youtube, Dailymotion, Viméo…. Dans ce dernier cas, la question ne concerne pas seulement le fichier : des ressources externes, des traceurs ou des statistiques de lecture peuvent aussi être déclenchés, mais sur des serveurs qui nous échappent.

Le RGPD traite ici la donnée personnelle, mais d’autres sujets peuvent s’ajouter, notamment le droit à l’image ou l’autorisation d’enregistrer et de diffuser une voix. Pour les dispositifs plus encadrés, comme la vidéosurveillance ou la vidéoprotection, les règles deviennent encore plus précises : la CNIL propose une page dédiée à la vidéoprotection, précise les règles à suivre pour les caméras touristiques, et les lignes directrices du CEPD sur les dispositifs vidéo permettent d’aller plus loin. Le bon réflexe reste donc très concret : qui apparaît ou parle ? pourquoi ce média est-il collecté ? où est-il stocké ? qui peut y accéder ? combien de temps le conservons-nous ? Et si une webcam, une visioconférence ou une captation est enregistrée, il faut le dire clairement avant l’enregistrement. Pour les dispositifs soumis à autorisation, le ministère de l’Intérieur propose également une ressource sur la demande d’autorisation d’un système de vidéosurveillance.

Une image n’est pas toujours un simple décor
Une photo, une voix ou une vidéo peuvent identifier une personne, révéler un contexte ou contenir des métadonnées. Avant de les publier, les conserver ou les transmettre, nous devrions vérifier leur utilité, leur durée de conservation, les accès et, selon le contexte, les autorisations nécessaires.

Applications, capteurs et géolocalisation : quand le service demande l’accès à l’appareil

Avec une application en ligne, une webapp ou une PWA, nous ne sommes plus toujours dans le cas d’un site qui reçoit seulement ce que la personne saisit. Le service peut demander l’accès à certaines fonctions de l’appareil : géolocalisation, webcam, microphone, partage d’écran, notifications, stockage local, parfois Bluetooth ou lecture de QR Code. Les recommandations de la CNIL sur les applications mobiles et les permissions sont utiles ici, car elles montrent que ces accès doivent être limités, compréhensibles et liés à une fonction réelle.

La question principale reste la même : pourquoi cet accès est-il demandé ? Une carte peut avoir besoin d’une position approximative. Une visioconférence a besoin du micro et de la caméra pendant l’appel. Un outil de support peut demander un partage d’écran. Mais si la fonction peut fonctionner sans cet accès, ou avec une donnée moins précise, nous devons nous demander si la collecte est vraiment nécessaire.

Il faut aussi distinguer l’usage ponctuel de l’usage permanent. Une webcam activée pendant un échange en direct ne pose pas les mêmes questions qu’un flux enregistré. Une géolocalisation utilisée une seule fois pour trouver un service proche n’a pas le même impact qu’un suivi continu. La CNIL propose d’ailleurs plusieurs ressources autour de la géolocalisation, avec des cas plus spécifiques comme les véhicules de salariés ou certains usages professionnels. Le service ne collecte plus seulement ce que la personne écrit : il peut accéder à ce que son appareil voit, entend, localise ou partage.

Pour les projets plus riches, comme certains services de PEM’s Projects, il faut aussi regarder les bibliothèques et outils intégrés. Un SDK de carte, de statistiques, de notification ou de paiement peut recevoir certaines informations. La CNIL consacre d’ailleurs une ressource spécifique à l’intégration des SDK dans les applications mobiles.

Le bon réflexe consiste à traiter chaque permission comme une donnée à part entière. Elle devrait avoir une finalité claire, être limitée au besoin réel, être expliquée au moment où elle est demandée, puis documentée dans la cartographie ou le registre si elle entraîne une collecte ou un traitement. En ouverture critique, les travaux de La Quadrature du Net sur la surveillance rappellent que ces accès techniques ne sont jamais neutres lorsqu’ils permettent de suivre des déplacements, des usages ou des comportements dans le temps.

Quand les données sont saisies par quelqu’un d’autre

Jusqu’ici, nous avons surtout évoqués des situations où la personne remplit elle-même un formulaire. Mais, dans beaucoup de projets, les données peuvent être recueillies autrement : échange oral, formulaire papier, appel téléphonique, fiche d’inscription, dossier transmis par un parent, un salarié, un bénévole ou un agent d’accueil. La donnée est ensuite saisie dans un logiciel, un site ou une application par une autre personne.

Ce cas change un peu notre manière de regarder le traitement. La personne concernée n’a pas forcément vu l’interface dans laquelle ses informations seront enregistrées. Elle doit pourtant être informée de façon claire : qui collecte les données, pourquoi, où elles seront utilisées, combien de temps elles seront conservées et comment exercer ses droits. La CNIL rappelle que les personnes doivent être informées même lorsque les données ne sont pas collectées directement auprès d’elles, avec des informations sur les catégories de données et leur source « Règlement européen : de quoi les personnes doivent-elles être informées ? ».

Prenons un exemple courant : une structure d’accueil inscrit des enfants à une activité. Les parents remplissent une fiche papier, l’équipe saisit ensuite les informations dans un outil interne, puis des photos souvenirs sont prises pendant l’événement. Nous ne sommes plus seulement dans un formulaire web : il faut aussi penser aux autorisations, aux supports de diffusion, à la durée de conservation, aux accès internes et aux éventuelles publications, qu’elles restent dans un espace privé de la structure ou qu’elles soient diffusées plus largement sur les réseaux sociaux.

Avec les mineurs, la vigilance doit être renforcée. Dans sa ressource « Les droits numériques des mineurs », la CNIL rappelle que les enfants disposent de droits numériques, avec un accompagnement des parents et des professionnels, et que la publication de photos d’élèves sur un site ou un autre support fait partie des situations où un accord écrit des parents ou représentants légaux est généralement attendu..

Le bon réflexe consiste donc à ne pas regarder seulement l’écran final. Il faut suivre toute la chaîne : qui recueille l’information ? sur quel support ? qui la saisit ? dans quel outil ? qui peut la consulter ? quelles autorisations existent ? où les photos ou documents sont-ils publiés ? Dès qu’un tiers saisit ou transmet des données pour une autre personne, la cartographie doit intégrer cette étape intermédiaire.

Une première grille de vérification avant mise en ligne

Avant de mettre un site, ou une application, en ligne, nous n’avons pas besoin de prétendre que tout est parfait. En revanche, nous pouvons vérifier que les principaux points ont été regardés sérieusement. Cette grille ne remplace pas un accompagnement juridique ou les ressources de référence, mais elle aide à repérer les oublis les plus fréquents avant publication.

La première étape consiste à revenir aux données elles-mêmes. Avons-nous listé les données collectées ? Savons-nous pourquoi chaque donnée est demandée ? Les champs inutiles ont-ils été supprimés ? Une durée de conservation est-elle prévue ? Ces questions rejoignent la logique du registre des activités de traitement, que la CNIL présente comme un outil central pour documenter les traitements : registre des activités de traitement.

Il faut ensuite vérifier l’information donnée aux personnes. Les formulaires expliquent-ils clairement ce qui sera fait des données ? La politique de confidentialité correspond-elle à la réalité technique du site ? Les cookies et traceurs ont-ils été identifiés avant d’installer une bannière ? Les personnes savent-elles comment exercer leurs droits d’accès, de rectification ou de suppression ?

La partie technique mérite la même attention. Les comptes administrateurs sont-ils protégés ? La double authentification est-elle activée lorsque c’est possible ? Les anciens comptes ont-ils été supprimés ? Les droits SQL sont-ils limités ? Les sauvegardes sont-elles protégées ? Les exports temporaires ont-ils été effacés ? Le guide de la sécurité des données personnelles de la CNIL permet de prolonger ces vérifications côté sécurité.

Enfin, il faut regarder la chaîne complète : hébergeur, prestataires, outils tiers, newsletter, statistiques, cloud, support ou formulaires externes. Qui reçoit des données ? Qui peut y accéder ? Dans quel cadre ? Des ressources comme l’infographie de Solidatech sur les points clés du RGPD peuvent aider à garder une vue d’ensemble. Le sérieux ne vient pas d’un document unique, mais de gestes simples, répétés et vérifiables : limiter, informer, protéger, documenter et mettre à jour.

Ressources pour aller plus loin

Pour revenir aux bases, une ressource de base reste la page de la CNIL Comprendre le RGPD. Elle permet de retrouver les grands principes sans passer directement par le texte complet du règlement. Pour une approche plus opérationnelle, la CNIL propose aussi une page dédiée au registre des activités de traitement et un guide de sécurité des données personnelles.

Pour les associations, petites structures ou projets accompagnés, les ressources de Solidatech sont intéressantes parce qu’elles traduisent le RGPD en étapes plus accessibles. L’infographie “5 points pour être conforme au RGPD” peut servir de mémo, tandis que le webinaire “RGPD pour mon association” permet d’entrer dans une démarche plus progressive.

Framasoft apporte un autre type de ressource : un exemple de mise en pratique rendu public. La page Vie privée, données personnelles et RGPD de Frama.space montre comment expliquer une démarche à des utilisateurs, tandis que FramaRGPD permet de voir comment une organisation peut documenter son travail de conformité et ses choix.

Enfin, pour ouvrir la réflexion au-delà du seul cadre opérationnel, les publications de La Quadrature du Net autour du RGPD permettent d’aborder les questions de surveillance, de fichiers, de profilage et d’usages contestés des données. Cette ouverture ne remplace pas les ressources institutionnelles, mais elle aide à comprendre pourquoi la protection des données dépasse largement la simple mise en conformité d’un site web.

Deux ouvrages pour approfondir

• Pour passer d’un premier débroussaillage à une lecture plus structurée, deux ouvrages peuvent compléter les ressources en ligne. RGPD simple et pratique – Comprendre et appliquer le Règlement général sur la protection des données, de Frédéric Manzano, semble particulièrement adapté à une approche progressive et opérationnelle. Il peut aider les petites structures, associations ou indépendants à mieux comprendre les étapes concrètes d’une mise en conformité.
• Dans une approche plus large, La protection des données personnelles, de Guillaume Desgens-Pasanau, permet d’approfondir le cadre général de la protection des données. Ce type de lecture aide à relier les situations très concrètes rencontrées dans un site ou une application web, formulaires, comptes, prestataires, cookies, fichiers ou accès techniques, aux responsabilités des acteurs, aux droits des personnes, aux obligations de documentation et à l’évolution du cadre juridique.

Ces livres ne remplacent pas les ressources officielles de la CNIL, mais ils peuvent aider à prendre du recul, à structurer la démarche et à mieux relier les obligations juridiques aux situations rencontrées dans la conception, la mise en ligne et la maintenance d’un site ou d’une application web.

Conclusion : comprendre avant de protéger

Le RGPD peut sembler difficile à aborder parce qu’il touche à la fois au droit, à la technique et à l’organisation. Pourtant, dans un projet web, le point de départ reste concret : savoir quelles données circulent, pourquoi elles sont collectées, où elles sont stockées, qui peut y accéder et combien de temps elles sont conservées.

Une bannière cookies, une politique de confidentialité ou une mention de copyright ne suffisent pas si nous ne savons pas ce que fait réellement le site. À l’inverse, une cartographie claire, des accès protégés, des données limitées et des choix documentés posent déjà une base plus sérieuse.

Cet article reste volontairement un débroussaillage. Plusieurs sujets méritent maintenant d’être approfondis séparément : “Mentions légales, CGU, CGV, confidentialité : quelles pages prévoir pour un site web ?”, “Métadonnées et données personnelles : ce que nos fichiers disent sans nous le demander”, ou encore “Quand la donnée déborde : failles, surveillance et usages détournés”.

Cette vigilance ne se limite pas au jour de la mise en ligne. Le RGPD fonctionne plutôt comme un processus qui accompagne la vie du projet : chaque nouveau formulaire, chaque extension, chaque outil statistique, chaque newsletter, chaque fonctionnalité interactive, chaque prestataire ou chaque nouveau lieu de stockage peut modifier la manière dont les données circulent. Il faut donc revenir régulièrement à la même question : savons-nous encore ce que nous faisons des données, et pouvons-nous l’expliquer ?

L’objectif n’est pas d’avoir peur des données, ni de renoncer à construire des services utiles. Il est plutôt d’apprendre à les regarder avec attention. Derrière un champ de formulaire, un cookie, une sauvegarde ou un compte administrateur, il y a souvent une personne qui nous confie une information. C’est cette relation de confiance que le RGPD nous invite à prendre au sérieux.