Un projet de site ou d'application qui manipule des données personnelles — un formulaire de contact, un espace client, une base de prospects — doit respecter le RGPD. Beaucoup d'entreprises pensent conformité en fin de projet, au moment de rédiger une politique de confidentialité. En réalité, la plupart des sujets se traitent dans les choix techniques, dès le cahier des charges. Voici ce qui mérite d'être posé sur la table avant d'écrire la première ligne de code.

Penser la protection des données dès la conception

Le RGPD demande d'intégrer la protection des données « dès la conception et par défaut ». Concrètement, pour chaque fonctionnalité, il s'agit de se demander quelles données sont réellement nécessaires, et à quel moment. Un formulaire de prise de rendez-vous n'a pas besoin d'une date de naissance si elle ne sert à rien dans le traitement. Une inscription à une newsletter n'a pas besoin d'un numéro de téléphone.

Le « par défaut » compte tout autant : les cases de consentement optionnel doivent rester décochées, les champs facultatifs doivent l'être vraiment, et les réglages les plus protecteurs doivent s'appliquer sans action de l'utilisateur. Ces choix se prennent à la conception des maquettes et de la base de données, pas en correction après un audit.

Ne collecter et ne garder que ce qui est utile

La minimisation des données est un principe simple à énoncer, plus exigeant à appliquer dans la durée. Un compte utilisateur, une commande, un ticket de support accumulent des informations au fil du temps. Sans règle claire, une base de données grossit indéfiniment, avec des données qui ne servent plus à rien mais restent stockées « au cas où ».

Chaque catégorie de données doit avoir une durée de conservation définie : un prospect qui ne répond pas peut être supprimé ou anonymisé après quelques mois, un client inactif après quelques années, des journaux de connexion après quelques semaines. Ces règles se traduisent techniquement par des tâches automatiques de purge ou d'anonymisation, pensées dès la construction de la base plutôt qu'ajoutées dans l'urgence plus tard.

Sécuriser les données à chaque étape

La sécurité technique est la face la plus concrète du RGPD : un principe qui semble abstrait dans un texte de loi devient très concret quand il s'agit de configurer un serveur. Quelques mesures reviennent systématiquement dans un projet bien construit :

  • Chiffrer les échanges avec le protocole HTTPS et les champs les plus sensibles en base de données
  • Limiter les accès selon le rôle de chaque utilisateur, sans compte partagé « administrateur » utilisé par toute une équipe
  • Garder une trace des connexions et des actions importantes, pour pouvoir répondre en cas d'incident
  • Tester régulièrement la restauration des sauvegardes, pas seulement leur création

Un mot de passe stocké en clair, une sauvegarde non chiffrée qui traîne sur un poste personnel, ou un accès administrateur non révoqué après le départ d'un salarié : ce sont ces détails, plus que la théorie juridique, qui provoquent la majorité des incidents.

Prévoir les droits des utilisateurs dans l'outil lui-même

Le RGPD accorde à toute personne un droit d'accès, de rectification, de suppression et de portabilité de ses données. Ces droits ne se limitent pas à une ligne dans les mentions légales : ils supposent qu'un outil existe, côté technique, pour les exercer dans un délai raisonnable. Une équipe support doit pouvoir retrouver toutes les données liées à une personne, les exporter dans un format lisible, ou les supprimer proprement — y compris dans les sauvegardes et les outils annexes (emailing, statistiques, facturation).

Ces fonctionnalités s'anticipent dès le cahier des charges d'une application web sur mesure, plutôt que d'être ajoutées dans l'urgence après une demande de suppression reçue par email. Un bouton de suppression de compte, une fonction d'export, un processus documenté pour l'équipe support : ces éléments simples évitent des semaines de recherche manuelle le jour où la demande arrive vraiment.

Encadrer les prestataires et les outils tiers

Un site ou une application s'appuie rarement sur un seul acteur : hébergeur, service d'envoi d'emails, outil de statistiques, solution de paiement. Chacun de ces sous-traitants traite des données pour le compte de l'entreprise, ce qui suppose un contrat encadrant cette relation, souvent appelé accord de sous-traitance, et une vérification de leur propre niveau de conformité.

Les cookies et scripts de mesure d'audience suivent la même logique : aucun script qui dépose un cookie non essentiel ne devrait se déclencher avant que la personne ait donné son consentement. Un bandeau de consentement qui affiche un choix, mais dont les scripts tournent déjà en arrière-plan, ne protège ni l'utilisateur ni l'entreprise qui l'a mis en ligne.

Le RGPD n'est pas un frein au développement, mais un ensemble de règles qui, bien anticipées, évitent des reprises coûteuses et des risques inutiles. Chez Planéo Dev, nous intégrons ces questions dès le cadrage de vos projets de site ou d'application. Parlons ensemble de votre besoin pour voir ce qu'il faut prévoir avant de démarrer.