Le RGPD1 a mauvaise presse en cadrage de projet. On l'attend en fin de chaîne, posé comme une couche juridique défensive sur du code déjà écrit, des écrans déjà validés, des bases déjà remplies. On le subit. On y voit un frein. On a tort.
Pensé au démarrage, le RGPD ne ralentit pas un projet. Il en dessine les fondations. Il fait gagner du temps, de l'argent, et bien souvent du taux de conversion. Démonstration en partant du plus concret : le formulaire d'inscription.
Pourquoi le RGPD passe pour un frein
On a entendu mille fois la même chose :
« Le RGPD, on s'en occupera en fin de projet. »
« On verra ça avec le DPO (Délégué à la Protection des Données) une fois le site recetté. »
« On va faire valider les CGU au dernier moment. »
Cette logique a un nom : le RGPD-rustine. Une couche de conformité posée tardivement sur un système qui n'a pas été conçu pour elle. Résultat : ça bloque, ça coûte, ou ça oblige à refaire.
Le problème n'est pas le RGPD. C'est le moment où on le découvre.
Quand le sujet arrive à 80 % d'avancement, il est déjà trop tard pour faire proprement : il faut retirer des champs, refondre des bases, réécrire des exports, modifier des interfaces, revoir des contrats. Le coût n'est plus juridique, il devient structurel.
Ce que rapporte (vraiment) un RGPD bien pensé
Les organisations qui traitent la donnée sérieusement en amont ne le vivent pas comme une contrainte.
Selon le Cisco 2025 Data Privacy Benchmark Study (2 600 répondants, 12 pays), 96 % des organisations estiment que les bénéfices de leurs investissements en protection des données dépassent les coûts. Le retour sur investissement médian est de 1,6x.
Les bénéfices cités sont concrets et convergents : confiance client (79 %), efficacité opérationnelle (78 %), innovation et agilité (78 %), attractivité de l'entreprise (78 %), réduction des pertes liées à la sécurité (76 %).
On ne parle pas ici de conformité. On parle de performance.
La règle de minimisation : demander juste
Pour voir comment le RGPD agit en architecte, il suffit de regarder ce qu'il y a de plus quotidien dans un site web : un formulaire d'inscription.
Chaque champ collecté est une décision qui engage l'organisation à cinq ans. On va le stocker quelque part. On va devoir le sécuriser. On va devoir documenter pourquoi on l'a demandé. On va devoir le supprimer à terme. On va devoir le retrouver si l'utilisateur le demande. Un champ, ce n'est pas uniquement un champ dans une page. C'est une chaîne (collecte, stockage, usage, rétention, accès, suppression) qu'on s'engage à tenir.
Deux formulaires illustrent bien ce que ça donne quand cette chaîne est pensée en amont. Ils ont l'avantage d'avoir le même éditeur, mais deux logiques différentes.
Le premier vit sur jesoutiensunathlete.fr. Huit champs, tous obligatoires : athlète soutenu, nom, prénom, fonction, organisation, email, téléphone, message. Une mention RGPD discrète, pas de case à cocher consentement, pas d'opt-in newsletter. La finalité tient en une phrase : permettre à un dirigeant d'entreprise de manifester son soutien nominatif à un athlète. Huit champs alignés sur cette finalité. Pas un de plus.
Le deuxième vit sur 1pacteclimat.fr/rejoignez-nous. Une quinzaine de champs visibles, plus des champs conditionnels révélés à la demande : raison sociale, prénom, nom, téléphone, email, fonction, secteur d'activité, rattachement à une fédération professionnelle, rattachement à une organisation patronale, présentation de l'entreprise et de sa stratégie de transition écologique, message. La finalité tient en une autre phrase : permettre à une entreprise de rejoindre un engagement climatique structuré, en qualifiant sa nature, son rattachement, et son apport. Quinze champs alignés sur cette finalité. Pas un de plus non plus.
Deux formulaires, deux logiques, même règle. Ce qui les rend conformes au principe de minimisation, ce n'est pas le nombre de champs. C'est l'alignement entre chaque champ et la finalité. Demander huit champs pour « soutenir un athlète » serait conforme ; demander vingt-cinq ne le serait plus. Demander quinze champs pour rejoindre une initiative climatique structurée est conforme ; en demander cinq ne suffirait pas.
On ne minimise pas en demandant moins. On minimise en demandant juste.
Et juste, ce n'est pas une opinion. C'est un calcul qui se pose au cadrage : qu'est-ce que je vais faire de cette information, pendant combien de temps, et pour qui ?
Ce qui coûte cher en fin de projet
Tout l'enjeu tient dans le moment où l'on pose ces questions. Au cadrage, elles tiennent dans un atelier de 90 minutes. En production, elles coûtent des sprints entiers.
Voici 5 décisions "data" qui coûtent trois fois plus cher rattrapées qu'anticipées :
Les champs collectés. Décider en cadrage qu'on demande l'email mais pas le téléphone, qu'on coche obligatoire le nom mais pas la fonction, qu'on ouvre un champ libre mais pas un champ structuré : trente minutes. Rattraper trois mois après livraison parce qu'un export RGPD oblige à reformater la base et à mettre à jour cinq écrans : un sprint entier, parfois plus, à reconstruire ce qui aurait tenu en trente minutes.
La durée de rétention. Décider en amont qu'on garde les inscriptions évènementielles trois ans après la dernière édition, et que tout est purgé après : un paragraphe dans la spec. Rétroactif : un script de purge à écrire, tester, valider, plus les CGU à mettre à jour et les utilisateurs à prévenir. Un détour sans valeur ajoutée perceptible.
L'hébergement. Acter en cadrage que les données restent sur des serveurs européens, c'est une ligne dans le devis d'infrastructure. Découvrir trois mois après qu'un sous-traitant marketing utilisait un outil américain pour le suivi des visites, c'est une migration, parfois une renégociation du contrat client.
Les opt-ins par canal. Prévoir en cadrage trois colonnes distinctes (email, SMS, transmission partenaire) au lieu d'une seule, c'est un schéma de base de données légèrement plus large. Le faire après coup, c'est documenter ce qu'on a recueilli implicitement, contacter les utilisateurs pour régulariser, et encaisser les opt-out massifs qui en découleront.
La suppression et la portabilité. Deux points d'accès à prévoir au cadrage, « supprimez-moi » et « envoyez-moi mes données ». Deux user stories. Faits après, deux chantiers d'archéologie dans la base, pour retrouver toutes les copies de la donnée et écrire un traitement qui les vide sans casser les jointures.
Moins de champs sur un formulaire, c'est aussi moins de friction. Selon le Baymard Institute (2024), 18 % des utilisateurs abandonnent une commande à cause de la complexité du tunnel. Un champ retiré n'est pas seulement un risque RGPD qui disparaît : c'est un taux de complétion qui monte.
Voilà comment le RGPD s'impose comme votre meilleur architecte. Il ne bloque pas le chantier, il le rationalise : avant de poser une brique, vérifiez qu'elle porte le toit.
5 questions avant de coller un champ dans un formulaire
Pour les décideurs et équipes techniques, voici la boussole de cadrage. Si la réponse à l'une de ces questions est floue, la donnée n'a probablement pas sa place dans le projet :
Pour quoi faire ?
Quelle est la finalité précise ? Si elle ne tient pas en une phrase, on coupe.
Pendant combien de temps ?
Un mois ? Cinq ans ? La durée se décide en cadrage, pas face à la CNIL.
Qui y accède ?
Marketing, compta, sous-traitant ? La matrice des accès se trace avant d'avoir des utilisateurs.
Que se passe-t-il si on l'oublie ?
Si on enlève cette donnée, la finalité tient-elle toujours ? Si oui, la donnée est superflue.
Qu'est-ce qui se passe quand l'utilisateur veut partir ?
Où chercher la donnée pour la supprimer ? Si la réponse exige une réunion, c'est un problème d'architecture.
Ces cinq questions ne remplacent pas le travail d'un DPO. Elles le préparent. Et elles permettent à un chef de projet, un directeur marketing ou un CTO de tenir une discussion structurée sur la donnée au moment où elle peut encore peser sur l'architecture.
Et si le cadrage de votre prochain projet commençait par là ?
Repensé en architecte plutôt qu'en avocat, le RGPD change de visage. Il n'est plus ce qu'on repousse, mais ce qu'on bâtit d'emblée. Il n'est plus un frein, mais un socle. Les études mondiales le prouvent. Le terrain le confirme au quotidien.
Prenez cet opérateur français de la collecte de dons, qu'on opère depuis plus de dix ans. 150 millions d'euros de dons traités, des données sensibles manipulées en continu : signatures électroniques, identité civile, IBAN, historique de don. Et un bilan sur la décennie : 0 don perdu, aucune fuite de données.
Dans ce secteur, l'historique n'est d'ailleurs pas qu'une donnée comptable. Savoir qu'un citoyen finance une ONG militante révèle une opinion politique ou philosophique. C'est une donnée parfois plus explosive à protéger qu'un simple compte bancaire.
Ce n'est pas le miracle d'un audit de rattrapage en fin d'année. C'est simplement l'effet de bonnes décisions data prises au démarrage et rigoureusement tenues depuis.
Ce qu'on en retire, après dix ans, est finalement moins technique que culturel. Quand l'équipe métier sait qu'au cadrage de chaque évolution on lui demandera inévitablement à quoi sert la donnée, combien de temps elle vit et qui l'utilise, le RGPD perd son statut de corvée de fin de course. Il devient un langage commun.
Le RGPD n'est pas une couche. C'est une fondation.
Glossaire
- RGPD
- Règlement Général sur la Protection des Données. Texte européen en vigueur depuis 2018 qui encadre la collecte et le traitement des données personnelles : finalité explicite, durée de conservation limitée, droits d'accès et de suppression, sécurité. Le RGPD est appliqué en France par la CNIL (cnil.fr).
Sources
- Cisco Cisco 2025 Data Privacy Benchmark Study
- Baymard Institute Checkout Optimization: Minimize Form Fields