Privacy by default

Privacy by default : Protection des données par défaut, qui impose des réglages initiaux protecteurs, options de partage et de suivi désactivées tant que l’utilisateur n’a pas exprimé de choix.

Ce terme appartient à la famille « Juridique et RGPD ». La page reprend l’essentiel : à quoi ça sert, comment l’écrire, ce qui se passe quand on l’oublie.

Où intervient Privacy by default dans un projet

Privacy by default engage l’éditeur de l’application, c’est-à-dire l’entreprise qui la publie, et non l’agence qui l’a développée. La distinction figure rarement dans les devis.

Sur un projet réel, la question ne se pose jamais en théorie : elle arrive dans un devis, dans une réunion de cadrage ou dans un rapport de recette.

De la définition à la ligne de cahier des charges

Le cahier des charges doit désigner qui répond de « Privacy by default ». L’éditeur de l’application en porte la responsabilité, le prestataire doit livrer ce qui la rend possible.

À écrire noir sur blanc, dans le chapitre qui correspond :

• Les sous-traitants utilisés, nommés, avec le pays où sont hébergées les données.
• Les documents publiés : mentions légales, politique de confidentialité, conditions d’utilisation.
• Le niveau d’accessibilité visé, et le texte qui l’impose à votre activité.
• Le sort des données et du code à la fin du contrat.

Cette formulation se rédige avant la consultation, pas après réception des propositions : c’est elle qui rend deux devis comparables entre eux.

Pour le cadre général, le guide des prix donne les fourchettes constatées en France et le modèle de cahier des charges la structure qui les rend opposables.

Les contrôles à prévoir

Privacy by default se vérifie sur les documents publiés et sur le comportement réel de l’application. Les deux doivent dire la même chose.

• Relire la politique de confidentialité en la comparant aux données réellement collectées.
• Vérifier la liste des sous-traitants et le pays où les données sont hébergées.
• Vérifier que le consentement se refuse aussi facilement qu’il s’accorde.

Ces vérifications s’inscrivent au cahier de recette, avec un nom en face de chacune. Une case sans responsable reste vide.

Erreurs fréquentes

Ces erreurs ne viennent presque jamais d’un manque de compétence, mais d’un point qui n’a été écrit nulle part.

• Copier la politique de confidentialité d’un autre service sans vérifier les traitements réels.
• Recueillir un consentement noyé dans les conditions d’utilisation, donc inopérant.
• Ignorer où sont hébergées les données chez les prestataires utilisés par l’application.
• Laisser la cession des droits sur le code hors du contrat de développement.
• Confier la décision au prestataire, puis la contester au moment de la recette.

Termes liés

Les entrées du glossaire déjà publiées sur des sujets voisins :

• Consentement
• DPA
• Suivi entre applications
• Registre des violations
• Vérification de l’âge

Questions fréquentes

Qu’est-ce que « Privacy by default » ?

Protection des données par défaut, qui impose des réglages initiaux protecteurs, options de partage et de suivi désactivées tant que l’utilisateur n’a pas exprimé de choix. La définition tient en une phrase, son application dépend du projet. C’est pour cette raison qu’elle doit figurer dans le cahier des charges plutôt que dans un échange de courriels.

Que risque-t-on concrètement ?

Un refus de publication par une boutique, une mise en demeure de l’autorité de contrôle, et la remise en cause des données déjà collectées. La régularisation coûte presque toujours plus que la conformité initiale.

Comment savoir si le budget annoncé est cohérent ?

En comparant le périmètre écrit aux fourchettes constatées en France, détaillées poste par poste sur le guide des prix. Un chiffre isolé ne veut rien dire sans le périmètre qui va avec.

Toutes les définitions publiées sont rassemblées dans l’index du glossaire, classées de A à Z et par famille.