Le RGPD 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 disent les chiffres
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.
Le formulaire comme révélateur
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 qualifier un engagement d'entreprise 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 : entre une et trois semaines de dev, plus les itérations recettes.
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 : écrire un script de purge, le tester, le valider, gérer les exceptions, prévenir les utilisateurs concernés, mettre à jour les CGU, archiver les preuves. Une à deux semaines de travail, sans valeur ajoutée perceptible côté métier.
L'hébergement. Décider en cadrage que les données restent sur des serveurs européens, voire français, voire chez tel hébergeur précis : un choix dans le devis d'infrastructure. En cours de route, parce qu'on découvre qu'un sous-traitant marketing utilisait un outil américain pour le suivi des visites : migration, ré-instrumentation, parfois renégociation du contrat client. Le mois de juin ne suffit pas toujours.
Les opt-ins par canal. Décider en cadrage que le consentement marketing email est distinct du consentement marketing SMS, et que les deux sont distincts du consentement de transmission à un partenaire : un schéma de base de données qui prévoit trois colonnes au lieu d'une. Rétroactif : redocumenter ce qu'on a recueilli implicitement, contacter les utilisateurs pour régulariser, gérer les opt-out massifs qui en découleront.
La suppression et la portabilité. Décider en cadrage qu'on expose dès le départ deux points d'accès pour les demandes utilisateur, un « supprimez-moi », un « envoyez-moi mes données » : deux développements à cadrer. Rétroactif : retrouver tous les emplacements où la donnée est dupliquée, écrire un traitement qui les vide sans casser les jointures, gérer les demandes pendant qu'on développe le système qui les traite.
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.
Sources
- Cisco Cisco 2025 Data Privacy Benchmark Study
- Baymard Institute Checkout Optimization: Minimize Form Fields