Le RGPD n'est pas qu'une affaire de juristes et de cases à cocher. Pour les équipes techniques, c'est un ensemble de contraintes concrètes qui impactent l'architecture, le stockage des données, les formulaires et les processus de déploiement.
Trop de projets web traitent le RGPD après coup, comme une couche de conformité à ajouter sur un produit déjà construit. Résultat : des rustines coûteuses, des processus bricolés et un risque juridique qui persiste.
Cet article est une checklist technique actionnable pour intégrer le RGPD dès la conception de votre application web.
Les principes techniques du RGPD
Privacy by design : la conformité dès l'architecture
Le RGPD impose le principe de « protection des données dès la conception » (article 25). Concrètement, cela signifie que chaque choix d'architecture doit intégrer la protection des données personnelles, pas seulement les fonctionnalités métier.
En pratique, cela se traduit par :
- Minimisation des données — ne collecter que les données strictement nécessaires à la finalité déclarée. Pas de champs « au cas où »
- Limitation de la conservation — définir une durée de rétention pour chaque type de donnée et automatiser la purge
- Pseudonymisation — séparer les données identifiantes des données d'usage quand c'est possible
Les bases légales de traitement
Avant de collecter une donnée, l'application doit savoir sur quelle base légale elle s'appuie. Les plus courantes en développement web :
- Consentement — l'utilisateur a donné son accord explicite (cookies analytics, newsletter)
- Contrat — le traitement est nécessaire à l'exécution d'un contrat (livraison d'une commande)
- Intérêt légitime — le traitement est justifié par un intérêt raisonnable (sécurité, anti-fraude)
- Obligation légale — la loi impose la conservation (factures, données comptables)
Checklist technique : les formulaires
- Consentement granulaire — une case à cocher par finalité (newsletter, analytics, partenaires). Jamais de consentement groupé
- Opt-in explicite — les cases ne doivent pas être pré-cochées. L'inaction ne vaut pas consentement
- Preuve de consentement — stocker la date, l'heure, l'adresse IP et le texte exact auquel l'utilisateur a consenti
- Retrait du consentement — aussi simple que le donner. Un lien de désinscription dans chaque email, un bouton dans l'espace utilisateur
Checklist technique : le stockage des données
Chiffrement
- En transit — HTTPS obligatoire (TLS 1.2 minimum, 1.3 recommandé)
- Au repos — chiffrement des données sensibles en base (AES-256). Les mots de passe sont hashés, pas chiffrés
- Sauvegardes — les backups contiennent les mêmes données sensibles et doivent être chiffrés
Purge automatisée
Chaque type de donnée doit avoir une durée de rétention définie. Implémentez des tâches automatiques (CRON, Symfony Scheduler) qui purgent les données expirées :
- Logs de connexion : 6 à 12 mois
- Données de formulaire de contact : 3 ans (prescription civile)
- Données de compte inactif : 3 ans après la dernière activité
- Données de paiement : conserver uniquement les références, pas les numéros de carte
Hébergement et transferts
Les données personnelles doivent rester dans l'Espace Économique Européen sauf garanties adéquates (clauses contractuelles types, décision d'adéquation).
- Privilégiez un hébergeur français ou européen (OVH, Scaleway, Hetzner)
- Vérifiez que vos services tiers (analytics, emailing, CDN) sont conformes
- Attention aux hébergeurs américains soumis au Cloud Act
Checklist technique : les droits des utilisateurs
Le RGPD donne aux utilisateurs des droits que votre application doit pouvoir exercer techniquement :
En pratique, implémentez :
- Une commande d'export qui génère un fichier complet de toutes les données d'un utilisateur
- Une procédure d'anonymisation (pas seulement de suppression) pour préserver l'intégrité des données métier (historique de commandes, statistiques)
- Un journal des demandes RGPD traitées (date, type de demande, délai de traitement)
Cookies et trackers : la partie visible
Le bandeau cookies est la partie la plus visible du RGPD pour les utilisateurs. Les règles sont strictes :
- Pas de tracking avant consentement — aucun cookie analytics ou marketing ne doit être déposé avant que l'utilisateur ait cliqué « Accepter »
- Refuser doit être aussi simple qu'accepter — le bouton « Refuser » doit être aussi visible que le bouton « Accepter »
- Choix granulaire — l'utilisateur doit pouvoir accepter les cookies fonctionnels et refuser les cookies analytics
- Pas de cookie wall — refuser les cookies ne doit pas bloquer l'accès au contenu
Alternative respectueuse : utilisez des outils d'analytics exemptés de consentement (Matomo configuré en mode exempté, Plausible, Fathom) qui ne déposent pas de cookies et anonymisent les données.
Registre des traitements : l'outil technique oublié
L'article 30 du RGPD impose un registre des traitements. Pour les développeurs, c'est l'occasion de documenter :
- Quelles données sont collectées, où et pourquoi
- Qui y a accès (rôles applicatifs, sous-traitants)
- Combien de temps elles sont conservées
- Comment elles sont protégées (chiffrement, accès, sauvegardes)
Ce registre est votre meilleur allié en cas de contrôle CNIL. Il prouve que la conformité n'est pas un discours marketing mais une réalité technique.
Intégrer le RGPD dans votre workflow de développement
Le RGPD ne doit pas être un audit ponctuel mais une pratique intégrée dans votre cycle de développement :
- Revue RGPD à chaque nouvelle fonctionnalité qui traite des données personnelles
- Tests automatisés sur l'anonymisation et la purge
- Veille réglementaire trimestrielle (la CNIL publie régulièrement des guidelines)
- Audit technique annuel incluant un volet conformité données