RGPD et développement web : conformité et DevSecOps

Protection des données dès la conception, sécurité adaptée au risque, notification des fuites en 72 heures : voici ce que le RGPD change concrètement pour un site ou un logiciel. Et comment une démarche DevSecOps permet de s'y conformer sans freiner les développements.

Le RGPD (règlement général sur la protection des données) est le règlement européen 2016/679, applicable depuis le 25 mai 2018, qui encadre toute collecte et tout usage de données personnelles. Pour un site web ou un logiciel, il impose de protéger les données dès la conception et par défaut (article 25), de les sécuriser (article 32) et de ne collecter que le nécessaire. Une démarche DevSecOps, qui intègre la sécurité à chaque étape du développement, est l’un des moyens les plus efficaces d’y parvenir sans ralentir les mises en production.

Cet article, mis à jour en septembre 2026 à partir du texte du règlement et des ressources de la CNIL, s’adresse aux dirigeants et aux équipes qui font développer ou développent eux-mêmes un site, une application ou un logiciel. On y voit ce que le RGPD exige concrètement côté technique, comment DevSecOps aide à s’y conformer, et une liste de contrôle pour un site d’entreprise.

Qu’est-ce que le RGPD ?
Qu’impose le RGPD à un site web ou un logiciel ?
Pourquoi DevSecOps aide-t-il à respecter le RGPD ?
Quelles pratiques de développement mettre en place ?
Quelle liste de contrôle pour un site d’entreprise ?
Quelles erreurs éviter ?
Questions fréquentes
Sources

Qu’est-ce que le RGPD ?

Le RGPD est le règlement (UE) 2016/679 du Parlement européen et du Conseil du 27 avril 2016. Il remplace la directive de 1995 sur la protection des données et s’applique directement dans tous les États membres depuis le 25 mai 2018. En France, la CNIL est l’autorité chargée de le faire respecter.

Trois points à retenir :

Il concerne toutes les organisations, quelle que soit leur taille, dès qu’elles traitent des données personnelles : nom, e-mail, adresse IP, historique d’achat, identifiant de connexion. Il s’applique aussi aux entreprises hors de l’Union qui proposent des biens ou services à des personnes situées dans l’Union ou suivent leur comportement.
Il repose sur des principes (article 5) : licéité et transparence, limitation des finalités, minimisation des données, exactitude, limitation de la durée de conservation, intégrité et confidentialité, et responsabilité (vous devez pouvoir démontrer votre conformité).
Il prévoit des sanctions lourdes : jusqu’à 20 millions d’euros ou 4 % du chiffre d’affaires annuel mondial pour les manquements les plus graves (article 83), le montant le plus élevé étant retenu.

Il donne enfin des droits aux personnes : information, accès, rectification, effacement, opposition, limitation, portabilité, et droits face aux décisions automatisées. L’organisation doit répondre à une demande dans un délai d’un mois.

Qu’impose le RGPD à un site web ou un logiciel ?

Le règlement ne donne pas de liste technique, mais plusieurs articles ont des conséquences directes sur la façon de concevoir et de faire tourner un outil numérique.

Article	Ce qu’il exige	Traduction concrète
Art. 25	Protection des données dès la conception et par défaut	Ne traiter par défaut que les données nécessaires à chaque finalité, penser la vie privée avant d’écrire le code
Art. 32	Sécurité adaptée au risque	Chiffrement, pseudonymisation, contrôle des accès, sauvegardes restaurables, tests réguliers des mesures
Art. 33	Notification des violations	Prévenir la CNIL si possible dans les 72 heures après avoir eu connaissance d’une fuite présentant un risque
Art. 28	Encadrement des sous-traitants	Un contrat avec l’agence, l’hébergeur ou l’éditeur SaaS qui traite des données pour vous
Art. 30	Registre des traitements	Documenter chaque traitement ; l’exemption des structures de moins de 250 salariés ne joue pas si le traitement n’est pas occasionnel, ce qui est le cas de la plupart des fichiers clients

Deux précisions pour corriger des idées reçues :

Le délégué à la protection des données (DPO) n’est pas toujours obligatoire. L’article 37 l’impose aux organismes publics et aux organisations dont l’activité de base implique un suivi régulier et systématique à grande échelle des personnes, ou le traitement à grande échelle de données sensibles. Une PME qui gère un site vitrine et un fichier clients n’est en général pas concernée, même si désigner un référent reste une bonne pratique.
Les cookies relèvent d’une règle complémentaire (la directive ePrivacy, transposée dans la loi Informatique et Libertés). La CNIL exige un consentement préalable pour les traceurs non essentiels, et refuser doit être aussi simple qu’accepter. Certains traceurs sont exemptés : authentification, panier, sécurité, et certaines mesures d’audience sous conditions.

Sur l’évolution du suivi publicitaire, voir notre article sur les cookies tiers.

Pourquoi DevSecOps aide-t-il à respecter le RGPD ?

DevSecOps est une façon d’organiser le développement dans laquelle la sécurité n’est plus un contrôle ajouté à la fin, mais une responsabilité partagée par les développeurs, les équipes d’exploitation et les responsables sécurité, à chaque étape : conception, code, tests, déploiement, exploitation. On en détaille les principes dans notre article qu’est-ce que le DevSecOps.

Le lien avec le RGPD est direct : l’article 25 demande une protection des données « dès la conception », et l’article 32 une sécurité « adaptée au risque » dont l’efficacité est testée régulièrement. Une démarche DevSecOps apporte précisément :

la prévention : les risques sur les données sont identifiés au moment où l’on conçoit une fonctionnalité, quand ils coûtent le moins cher à traiter ;
l’automatisation : analyses de code et de dépendances à chaque modification, ce qui évite qu’une faille connue parte en production ;
la traçabilité : chaque changement est versionné, relu et testé, ce qui aide à démontrer la conformité (principe de responsabilité) ;
la réactivité : des déploiements fréquents et maîtrisés permettent de corriger vite une faille, et une bonne journalisation aide à respecter le délai de notification de 72 heures.

DevSecOps ne rend pas conforme à lui seul : il faut aussi des décisions juridiques et organisationnelles (base légale, durées de conservation, information des personnes). Mais c’est lui qui fait passer ces décisions dans le code.

Quelles pratiques de développement mettre en place ?

La CNIL publie un guide RGPD du développeur, ouvert aux contributions, qui couvre en 15 fiches la préparation du projet, la gestion du code source, la sécurité, la minimisation, les bibliothèques et SDK, les tests, l’exercice des droits et la durée de conservation. Voici les pratiques qui reviennent le plus souvent, reliées à l’exigence qu’elles servent :

Pratique	Exigence RGPD servie
Lister les données collectées par fonctionnalité et supprimer les champs inutiles	Minimisation, protection par défaut
Ne jamais utiliser de données réelles dans les environnements de test (données fictives ou anonymisées)	Sécurité, limitation des finalités
Stocker les secrets (mots de passe, clés d’API) hors du code source	Sécurité
Analyser automatiquement les dépendances et appliquer les correctifs de sécurité	Sécurité
Chiffrer les échanges (HTTPS) et hacher les mots de passe avec un algorithme adapté	Sécurité, confidentialité
Restreindre les accès à la production et journaliser les accès aux données	Sécurité, responsabilité, notification des violations
Prévoir dès le départ l’export et la suppression des données d’un utilisateur	Droits d’accès, d’effacement et de portabilité
Programmer la purge automatique des données au-delà de leur durée de conservation	Limitation de la conservation
Tester la restauration des sauvegardes	Disponibilité et résilience

Pour aller plus loin sur la sécurité applicative, lisez notre article comment améliorer la sécurité des applications web. La CNIL propose aussi un guide de la sécurité des données personnelles, avec une liste de contrôle pour évaluer votre niveau.

Quelle liste de contrôle pour un site d’entreprise ?

Pour un site vitrine ou une boutique en ligne, les points à vérifier sont souvent les mêmes :

Formulaires : ne demander que les champs utiles, informer à côté du formulaire de l’usage des données et du lien vers la politique de confidentialité, pas de case précochée pour la prospection.
Politique de confidentialité : finalités, bases légales, destinataires, durées de conservation, droits et contact pour les exercer.
Cookies : bannière qui bloque les traceurs non essentiels avant le choix, bouton « Refuser » aussi visible que « Accepter », possibilité de changer d’avis à tout moment.
Sécurité : HTTPS partout, CMS et extensions à jour, comptes administrateurs nominatifs avec mots de passe robustes et double authentification si possible.
Sous-traitants : contrats avec l’hébergeur, l’agence, l’outil d’e-mailing ; vérifier où sont stockées les données et, en cas de transfert hors de l’Union, sur quelle garantie il repose.
Durées de conservation : supprimer régulièrement les demandes de contact, comptes inactifs et paniers abandonnés au-delà de la durée prévue.
Sauvegardes et incidents : sauvegardes testées, et une procédure écrite pour réagir à une fuite dans les 72 heures.

Beaucoup de ces points se jouent au moment de la création du site, les autres dans la durée : mises à jour, sauvegardes et surveillance font partie de nos offres d’hébergement et maintenance (le budget dépend du niveau de service, voir nos tarifs indicatifs).

Quelles erreurs éviter ?

Traiter le RGPD comme un dossier juridique uniquement : une politique de confidentialité parfaite ne sert à rien si la base de données n’est pas protégée.
Copier la base de production sur un poste de développeur pour « tester avec de vraies données ».
Collecter « au cas où » : date de naissance, téléphone ou adresse sans usage défini.
Oublier les outils tiers : chat, vidéo intégrée, pixels publicitaires et polices chargées depuis des serveurs externes peuvent transmettre des données de vos visiteurs.
Ne jamais supprimer : les données gardées indéfiniment augmentent le risque en cas de fuite.
Laisser un site sans mises à jour : une extension ou un thème non mis à jour peut suffire à ouvrir une faille exploitée pour dérober des données. Nos conseils pour sécuriser un site web vous aideront à démarrer.

Questions fréquentes

Que signifie RGPD ?

Règlement général sur la protection des données. En anglais, on parle de GDPR (General Data Protection Regulation).

Le RGPD s’applique-t-il aux petites entreprises ?

Oui. Il n’y a pas de seuil de taille : une TPE qui collecte des e-mails via un formulaire de contact est concernée. Seules quelques obligations sont allégées, comme le registre, et dans des cas limités.

Faut-il obligatoirement un DPO ?

Non, seulement pour les organismes publics et les organisations dont l’activité principale implique un suivi à grande échelle des personnes ou le traitement à grande échelle de données sensibles (article 37).

Qui est responsable, l’entreprise ou l’agence qui a fait le site ?

En général, l’entreprise est responsable du traitement : c’est elle qui décide pourquoi les données sont collectées. L’agence ou l’hébergeur qui traite ces données pour son compte est sous-traitant, avec ses propres obligations de sécurité et un contrat qui les encadre (article 28).

DevSecOps est-il obligatoire pour être conforme ?

Non, le RGPD n’impose aucune méthode. Il impose un résultat : une protection dès la conception et une sécurité adaptée au risque, régulièrement testée. DevSecOps est une manière efficace d’y arriver quand on développe et déploie souvent.

Comment faire vérifier mon site ?

Écrivez-nous à contact@osmova.com ou via le formulaire de contact : on regarde les formulaires, les cookies, les mises à jour et l’hébergement de votre site. Pour les questions juridiques, un juriste ou un DPO reste l’interlocuteur adapté.