Politique de confidentialité : le minimum légal pour lancer ton app

Avant de lancer ton app, il te faut une page politique de confidentialité. Ce n'est pas une formalité qu'on coche, c'est une obligation d'information prévue par le RGPD (article 13). Dès que tu collectes des données, tu dois dire aux gens ce que tu en fais, avant qu'ils te les donnent.

Et c'est là que je vois deux pièges, tout le temps. Soit la page n'existe pas du tout. Soit elle existe mais c'est un copier-coller pris ailleurs, qui décrit une app qui n'est pas la tienne. Les deux te mettent en défaut. Voyons ce qu'une politique de confidentialité doit vraiment contenir, pourquoi le modèle générique est un traquenard, et le cas particulier des apps no-code avec leurs sous-traitants.

À quoi elle sert vraiment

La politique de confidentialité, c'est ta transparence écrite. Elle répond à une question simple, du point de vue de l'utilisateur : « qu'est-ce que tu fais de mes données ? ». La loi considère que les gens ont le droit de le savoir avant de s'inscrire, pas après.

Ce n'est donc pas un document défensif pour te couvrir. C'est un document d'information pour eux. La nuance change la façon de l'écrire : tu ne cherches pas à te protéger avec du jargon, tu cherches à être clair sur ce que tu collectes et pourquoi. Une bonne politique de confidentialité se lit et se comprend.

Elle a aussi un effet secondaire utile : c'est l'un des premiers signaux de sérieux que regardent tes visiteurs. Une page absente ou bâclée, et le doute s'installe avant même qu'ils testent le produit.

Ce qu'elle doit contenir (les sections obligatoires)

Le RGPD liste les informations que tu dois donner. Traduites en clair, ça fait une check-list de sept blocs.

1. Qui tu es. L'identité du responsable de traitement (toi ou ta structure) et un moyen de te contacter.
2. Quelles données tu collectes. Emails, nom, données de compte, données de paiement, adresses IP.
3. Pourquoi tu les collectes. La finalité : gérer les comptes, envoyer une newsletter, traiter les paiements. Une donnée sans finalité, tu ne devrais pas la collecter.
4. Sur quelle base légale. Le consentement, l'exécution d'un contrat, ton intérêt légitime. Pour une app classique, c'est souvent le contrat (fournir le service) et le consentement (la newsletter).
5. Combien de temps tu les gardes. La durée de conservation. Pas « pour toujours ».
6. Avec qui tu les partages. Tes sous-traitants, ceux qui hébergent ou traitent les données pour toi. C'est le bloc que les apps no-code oublient le plus.
7. Les droits des personnes et comment les exercer. Accès, rectification, suppression, opposition, et l'adresse où écrire pour ça.

Sept blocs. Ce n'est pas énorme, mais chacun doit refléter ta vraie app, pas un modèle. Et c'est justement là que le copier-coller déraille.

Puis-je copier une politique de confidentialité toute faite ?

Non, pas telle quelle, et c'est le piège numéro un. Une politique de confidentialité décrit un traitement réel : tes données, tes finalités, tes sous-traitants à toi. Si tu copies celle d'une autre app, tu déclares des choses fausses, et tu oublies les tiennes.

Le cas classique : tu prends un modèle qui parle de Google Analytics alors que tu utilises Plausible, qui ne mentionne pas Supabase alors que toute ta base est dessus, et qui promet une durée de conservation que tu ne respectes pas. Résultat, ta page ment sur ce que tu fais. En cas de contrôle, une politique fausse est parfois pire qu'une absence, parce qu'elle montre que tu as fait semblant.

Un générateur peut te donner une bonne base de structure, c'est utile pour ne rien oublier. Mais tu dois ensuite l'adapter à ta réalité : tes outils, tes données, tes durées. Le squelette peut venir d'ailleurs, le contenu doit venir de toi.

Le cas des apps no-code : tes vrais sous-traitants

C'est le point que les fondateurs vibe-codeurs ratent le plus, alors qu'il est spécifique à leur stack. Ton app ne stocke pas les données toute seule. Elle s'appuie sur une pile de services, et chacun est un sous-traitant que tu dois mentionner.

• Supabase héberge ta base. À citer, avec la région d'hébergement (certaines sont hors Union européenne, ce qui implique un transfert de données à signaler).
• Ton hébergeur de front (Vercel, Netlify, ou autre) sert ton app et logge des accès.
• Stripe, si tu encaisses, traite des données de paiement.
• Ton outil d'analytics (Plausible, ou autre) voit du trafic.
• Ton service d'emailing, si tu envoies des mails transactionnels ou une newsletter.

Chacun de ces services voit passer des données personnelles pour ton compte. Le RGPD te demande de les lister, et d'avoir avec chacun un cadre (la plupart fournissent un accord de sous-traitance, le DPA, que tu acceptes en t'inscrivant). Faire l'inventaire de ta pile, c'est aussi un bon exercice pour toi : tu réalises combien d'endroits voient tes données.

Avoir la page ne suffit pas

Voilà le lien que je vois trop peu de gens faire. Écrire « vos données sont protégées » dans une politique de confidentialité, ça n'est vrai que si elles le sont vraiment. Une belle page au-dessus d'une base Supabase grande ouverte, c'est une promesse écrite que tu ne tiens pas.

J'ai scanné une app qui affichait fièrement « vos données sont protégées », avec un fichier de configuration exposé en clair juste derrière. La page disait une chose, la technique en disait une autre. Le jour où quelqu'un le remarque, la page ne te protège pas, elle t'accuse : tu savais, tu l'as écrit, et tu ne l'as pas fait.

La politique de confidentialité, c'est la promesse. La sécurité de ton app, c'est la tenir. Les deux vont ensemble. Avant d'écrire que les données sont en sécurité, vérifie que ta base est bien fermée.

FAQ

Quelle différence entre mentions légales et politique de confidentialité ?

Deux pages, deux rôles. Les mentions légales disent qui édite le site : ton identité, ton hébergeur, tes coordonnées. Elles répondent à « qui est derrière ce site ». La politique de confidentialité, elle, dit ce que tu fais des données des visiteurs. On les confond souvent, mais la loi impose les deux, séparément.

Un générateur gratuit, ça suffit ?

Comme point de départ, oui. Comme produit fini, non. Un générateur te donne une structure complète, ce qui évite d'oublier un bloc obligatoire. Mais il ne connaît pas ton app : tu dois relire et corriger pour que ça colle à tes vrais outils, tes vraies données et tes vraies durées. Une page générée non relue décrit rarement ta réalité.

Où mettre le lien vers la politique de confidentialité ?

Dans le pied de page, accessible depuis toutes les pages, et au moment de la collecte (près du formulaire d'inscription, de la case de consentement newsletter). L'idée est que la personne puisse la consulter avant de donner ses données, pas seulement la retrouver après.

Écris la promesse, puis tiens-la

Une politique de confidentialité honnête, c'est une heure de travail bien fait. La sécurité qui la rend vraie, c'est ce que ton app expose en ce moment, et ça se vérifie tout de suite.

Colmate te montre en trente secondes ce que ton app laisse voir : clés dans le navigateur, code source servi en clair, en-têtes manquants, présence de pages légales, et si ta base Supabase présente le profil d'une exposition à vérifier. Depuis l'URL publique, en lecture seule, sans jamais toucher à tes données ni à ton code. Pour la vue d'ensemble de tes obligations, pars de le RGPD pour ton app no-code.

Lance un scan gratuit. Autant vérifier que « vos données sont protégées » est vrai avant de l'écrire noir sur blanc.