Inventaire PII pour une base prototype : localiser et réduire les données

Pourquoi vous avez besoin d'un inventaire PII avant que votre prototype ne grossisse

Les prototypes collectent des données sensibles plus vite que vous ne le pensez. Un simple formulaire d'inscription ajoute des emails et des noms. Un flux d'invitation crée d'autres emails. La connexion ajoute des tokens. Les logs de debug les recopient encore. Avant longtemps, votre "app de test" contient des données de vraies personnes à des endroits où vous n'aviez pas l'intention de les garder.

Le risque n'est pas seulement une fuite. C'est aussi la confusion et le travail de remise en ordre. Si les emails et les tokens traînent sans propriétaire, vous ne pouvez pas répondre aux questions de base : qui peut voir ces données ? Combien de temps les conserver ? Pouvons-nous les supprimer sur demande ? Quand le prototype devient un vrai produit, vous vous retrouvez à faire un nettoyage d'urgence tout en essayant de livrer des fonctionnalités.

Un inventaire PII réduit ce risque rapidement. Ce n'est pas de la paperasse. C'est une carte des trajets des données personnelles, plus un plan pour collecter moins et supprimer à temps. Cette page unique change votre façon de construire : vous arrêtez d'ajouter des champs "au cas où", vous remarquez quand des tokens sont stockés en clair et vous définissez une règle de rétention avant que la base ne gonfle.

Au final, vous voulez deux résultats : une carte claire des données (où les emails, noms et tokens sont créés, stockés, copiés et envoyés) et un plan de rétention (ce qu'il faut garder, ce qu'il faut éviter de collecter et quand l'expirer ou le supprimer). En chemin, vous aurez aussi une courte liste des points à haut risque (logs, événements analytics, sauvegardes, vues admin, tables oubliées) et un responsable pour chaque magasin de données.

Si vous avez hérité d'un prototype généré par IA (d'outils comme Bolt, v0, Cursor, ou Replit), cela compte encore plus. Ces builds copient souvent des secrets dans des fichiers de config, stockent des tokens sans expiration ou dispersent les données utilisateur dans plusieurs tables.

Ce qui compte comme PII et données sensibles dans un prototype

La PII (informations personnellement identifiables) est toute donnée qui peut identifier une personne réelle, soit seule, soit combinée avec d'autres champs. C'est la partie "combinée" qui fait trébucher les équipes : un pseudo plus un nom d'entreprise, ou une IP plus un timestamp, peuvent pointer vers un utilisateur spécifique.

Commencez par les champs évidents du profil utilisateur, puis cherchez les copies fantômes en dehors de votre table users principale.

Les PII communes dans les prototypes incluent : emails, noms, numéros de téléphone, adresses, pseudonymes, date de naissance, localisation, photos de profil, métadonnées liées au paiement (même si vous ne stockez pas les numéros de carte), adresses IP et identifiants d'appareil.

Certaines données ne sont pas toujours des PII, mais restent sensibles car elles peuvent débloquer des comptes ou systèmes. Traitez-les comme à haut risque : tokens d'authentification, IDs de session, refresh tokens, liens de réinitialisation ou codes à usage unique, clés API, secrets client OAuth et secrets de signature de webhooks.

Incluez aussi les endroits qui collectent ou dupliquent discrètement des données. Les prototypes fuient souvent de la PII dans les logs (corps de requête, traces d'erreur), les événements analytics (par exemple, "invite_sent" avec un email), les tickets support (captures d'écran, tokens collés) et les CSV exportés partagés en chat.

Un exemple simple : votre flux d'invitation stocke l'email de l'invité dans une table invites, enregistre la requête complète en cas d'erreur et envoie un événement analytics avec le même email comme propriété. Ce sont trois emplacements à suivre, expirer et supprimer.

Lister chaque endroit où votre app peut stocker ou copier des données

Un inventaire PII commence par une idée simple : les données vivent rarement à un seul endroit. Les prototypes copient des valeurs par commodité, et ces copies deviennent les plus difficiles à retrouver ensuite.

Cartographiez le chemin complet d'une information utilisateur (comme un email) depuis le moment où elle entre dans l'app jusqu'à chaque endroit où elle peut atterrir. Incluez les endroits créés par votre framework, votre hébergement et vos outils tiers, pas seulement ce que vous avez codé volontairement.

La plupart des équipes trouvent des données personnelles dans quelques compartiments :

• Tables et colonnes de la base : tables users, invites, tables d'audit, tables temporaires et tout ce qui stocke des payloads bruts de requête.
• Fournisseur d'auth et magasin de profil : les emails et noms peuvent exister dans votre base et aussi dans un système d'auth séparé, souvent avec des métadonnées supplémentaires (dernière connexion, IP, appareil).
• Uploads et stockage d'objets : images de profil, imports CSV, pièces jointes et exports générés. Les noms de fichiers et le contenu peuvent contenir de la PII.
• Jobs en arrière-plan, files et caches : les payloads de job incluent souvent l'objet utilisateur complet ; les caches peuvent les garder plus longtemps que prévu ; les retry dupliquent les données.
• Rapports de crash, logs de requête et dashboards admin : les erreurs peuvent capturer headers, cookies et corps de requête ; les écrans admin et les exports CSV deviennent une autre copie.

Pour chaque endroit, notez les champs stockés (email, nom, tokens), pourquoi ils sont nécessaires, qui peut y accéder et combien de temps ils restent par défaut. Si vous ne pouvez pas répondre à la question de rétention, supposez "pour toujours" jusqu'à ce que vous définissiez une expiration.

Un exemple rapide : un login par magic link peut stocker l'email dans users, stocker le token dans login_tokens, copier l'email dans une queue de job pour envoyer le message, puis fuir le token dans les logs de requête si vous l'incluez dans une URL.

Étape par étape : construisez votre inventaire PII en une après-midi

Commencez par des parcours réels que les gens empruntent dans votre app, pas par votre schéma. Choisissez 3 à 5 parcours utilisateurs qui ont lieu aujourd'hui (ou qui auront lieu la semaine prochaine). Les plus courants : inscription, connexion, réinitialisation de mot de passe, invitation d'un coéquipier et checkout. Si vous ne documentez que les tables, vous manquerez ce qui est copié dans les logs, analytics et outils de support.

Pour chaque parcours, notez chaque champ que vous collectez et la raison simple pour laquelle vous en avez besoin. Si vous ne pouvez pas expliquer la raison en une phrase, c'est un bon candidat à supprimer ou à retarder.

Tracez ensuite chaque champ de bout en bout : où il entre (formulaire ou API), où il est validé, où il est stocké (table et colonne) et où il peut être dupliqué (logs, jobs, trackers d'erreur, outils d'email).

Une feuille de travail simple (doc ou tableur) suffit. Utilisez une ligne par champ et capturez :

• Nom du champ et une valeur exemple (pour la clarté)
• Objectif (pourquoi vous en avez besoin maintenant)
• Tag type de données : PII, sensible ou non sensible
• Où il circule : requête, table/colonne BDD, logs, tiers
• Qui peut y accéder (écran admin, accès direct BDD, outils support)

Si votre prototype a été généré par un outil d'IA, ajoutez une vérification en plus : recherchez les logs de debug et les payloads de requête copiés. Ce sont des endroits courants où emails, noms et tokens sont stockés par accident.

Comment localiser emails et noms dans votre base

Commencez par une analyse du schéma. La plupart des champs email et nom ne sont pas cachés, ils sont juste éparpillés. Ouvrez la liste des tables et cherchez d'abord l'évident, puis les copies ajoutées pendant le prototypage rapide.

Vérifiez les noms de colonnes courants dans chaque table, pas seulement users. Cherchez les champs directs (email, first_name) et les champs auxiliaires (contact_email, displayName, invited_by).

Une approche rapide est de chercher des patterns dans votre schéma, puis de confirmer avec quelques lignes de données.

-- Postgres example: find likely PII columns
select table_name, column_name
from information_schema.columns
where column_name ilike '%email%'
   or column_name ilike '%name%'
   or column_name ilike '%contact%'
order by table_name, column_name;

Après les champs évidents, cherchez où emails et noms se cachent dans du texte libre ou des blobs. Les apps prototypes déversent souvent les entrées utilisateur dans une colonne metadata, notes, message ou json et l'oublient.

Endroits courants où cela se cache :

• Champs texte libre et JSON (notes, message, metadata, profile, payload)
• Migrations et scripts de seed qui ont créé des utilisateurs test avec de vrais emails
• Tables dupliquées (users plus billing/customers plus analytics/events)
• Queues et logs stockés dans la base (jobs d'email, logs d'invites)
• Backups et snapshots (données anciennes qui survivent à vos tables principales)

Vérification réaliste : si votre app a des invites, vous stockez probablement des emails à au moins deux endroits (le record utilisateur et l'enregistrement d'invite). Notez où chaque copie vit et laquelle est la source de vérité.

Où vivent les tokens et quoi enregistrer à leur sujet

Les tokens sont souvent la première voie d'attaque dans un prototype. Ils agissent comme des clés : si quelqu'un en copie un, il peut le rejouer pour se connecter, appeler des APIs ou réinitialiser un mot de passe. Traitez les tokens comme des données sensibles même s'ils ne sont pas "personnels" en soi.

Types de tokens courants : IDs de session, refresh tokens, tokens magic link, tokens de réinitialisation et tokens API (pour des services tiers ou vos propres endpoints). Le risque augmente quand les tokens vivent longtemps, sont réutilisables ou fonctionnent depuis n'importe où sans vérifications supplémentaires.

Les tokens se retrouvent aussi à des endroits où personne ne s'y attend :

• Tables BDD (sessions, auth_tokens, password_resets)
• Cookies du navigateur (y compris "remember me")
• localStorage ou sessionStorage côté frontend
• Logs applicatifs et outils de suivi d'erreur (headers de requête, query strings)
• Templates d'email et logs d'envoi (magic links)

Pour chaque token, notez ce qu'il fait, où il est stocké et combien de temps il reste valide. Gardez les règles simples : stockez le minimum, expirez vite, faites une rotation à l'utilisation et hachez les tokens en stockage quand c'est possible pour qu'une fuite de la base ne donne pas un accès instantané.

Répondez à ces questions pour chaque token :

• Quelle action ce token permet-il (connexion, réinitialisation, accès API) ?
• Où est-il stocké et copié (BDD, cookie, logs, email) ?
• Quelle est sa durée de vie et peut-il être réutilisé ?
• Comment est-il protégé (haché, chiffré, scoped, lié à un appareil/IP) ?
• Que se passe-t-il à la déconnexion, au changement de mot de passe ou à l'annulation d'une invite ?

Minimiser la collecte : ne garder que ce dont le prototype a besoin

Une base de prototype se remplit vite parce qu'il est plus simple de tout sauvegarder que de décider ce qui compte. Cette habitude "tout sauver" conduit à de la PII inutile, des tokens longue durée et des données que vous ne pourrez plus expliquer.

Remettez chaque champ en question avec une seule interrogation : que casse-t-il si on ne stocke pas ça ? Si la réponse est "rien, ce serait juste agréable", ne le collectez pas encore. Vous pourrez ajouter des champs optionnels plus tard quand ils soutiendront une vraie fonctionnalité.

Le profiling progressif aide à garder les premiers inscrits simples. Collectez le minimum pour l'étape initiale (souvent juste un email), puis demandez plus seulement quand l'utilisateur atteint un point où c'est nécessaire (facturation, invitations, support).

Coupes à fort impact qui fonctionnent dans la plupart des prototypes :

• Utilisez des noms d'affichage plutôt que les noms légaux complets sauf besoin réel.
• Ne stockez pas les soumissions brutes de formulaires ou les payloads complets pour le debug. Logguez l'erreur et un request ID.
• Réduisez les champs texte libre. Si vous devez en avoir, ajoutez un avertissement clair (ne collez pas de secrets) et une limite de caractères.
• Rendez les champs "sympas à avoir" optionnels et poussez-les à une étape ultérieure.
• Préférez "pays" plutôt qu'une adresse complète jusqu'à ce que l'expédition l'exige.

Exemple : un flux d'invitation pousse souvent les équipes à stocker nom de l'invitant, nom de l'invité, note personnelle et historique complet des emails. Pour un prototype, il suffit souvent d'avoir l'ID de l'invitant, l'email de l'invité, le statut de l'invitation et un timestamp d'expiration.

Créer un plan d'expiration et de suppression que vous pouvez réellement suivre

Un inventaire PII n'est utile que s'il se termine par une règle simple : quand chaque chose expire et comment elle est supprimée.

Définissez des fenêtres de rétention par type de données et inscrivez-les à côté de chaque table ou champ dans votre inventaire, même si vous ne les appliquez pas encore :

• Inscriptions non vérifiées : supprimer après 7 jours
• Comptes abandonnés (pas de connexion, pas d'activité) : supprimer après 30–90 jours
• Emails de support ou formulaires de contact : supprimer après 90 jours
• Logs d'audit (évitez la PII si possible) : garder 30–180 jours
• Backups : gardez la fenêtre la plus courte possible (pour les prototypes, 7–30 jours suffit souvent)

Les tokens méritent leur propre règle car ils sont faciles à abuser et difficiles à repérer plus tard. Expirez vite les tokens de session et de réinitialisation, et assurez-vous de pouvoir les invalider. Une base raisonnable : access tokens en minutes, refresh tokens en jours, et révoquez tous les tokens au changement de mot de passe.

La suppression automatique rend le plan concret. Ajoutez un job planifié qui s'exécute quotidiennement : supprimer les utilisateurs non vérifiés au-delà du cutoff, supprimer les enregistrements d'invitation après acceptation ou après une fenêtre courte, et effacer les anciens tokens.

Les demandes de suppression d'utilisateur doivent être prévisibles. Définissez l'étendue pour ne pas rater des copies cachées :

• Supprimer le profil utilisateur et les enregistrements d'authentification
• Supprimer ou anonymiser le contenu lié (commentaires, projets, fichiers)
• Supprimer tokens, sessions et clés API
• Retirer des exports et outils tiers pour l'avenir
• Conserver un journal minimal de suppression (sans PII supplémentaire)

Les backups et exports sont la partie difficile. Vous ne pourrez peut-être pas supprimer chirurgicalement des backups anciens aujourd'hui, mais vous pouvez agir pour l'avenir : raccourcir la rétention des backups, arrêter d'exporter la PII brute par défaut et faire tourner les anciens exports selon un calendrier.

Contrôles d'accès et journalisation sans complexifier

Vous n'avez pas besoin d'une configuration d'entreprise pour protéger un prototype. Il vous faut des rôles clairs, moins de clés qui traînent et suffisamment de logs pour répondre à une question plus tard : qui a regardé ou modifié des données sensibles ?

Notez les rôles que vous avez réellement aujourd'hui. La plupart des prototypes tiennent dans un petit ensemble : fondateur/admin (accès complet), support (lecture seule des enregistrements utilisateurs), prestataire (accès uniquement à la partie qu'il construit) et un compte admin de secours utilisé rarement. L'objectif : empêcher que "tout le monde voit tout" devienne permanent.

Un plan d'accès simple qui tient la route :

• Donnez à chaque personne son propre login. Pas d'utilisateurs BDD partagés ou de mots de passe admin partagés.
• Limitez l'accès direct à la BDD à 1–2 personnes. Les autres utilisent l'écran admin de l'app.
• Utilisez un accès lecture seule pour le support quand c'est possible, et limitez dans le temps l'accès des prestataires.
• Revue d'accès mensuelle et suppression des comptes inutiles.
• Gardez un compte admin d'urgence, stocké en sécurité et utilisé uniquement quand nécessaire.

La journalisation peut rester légère. Enregistrez les actions admin qui touchent la PII : consultation d'un profil utilisateur, export d'utilisateurs, réinitialisation de mot de passe, changement d'email, génération de liens d'invitation. Même un journal basique avec timestamp, utilisateur admin, action et enregistrement ciblé suffit pour repérer les erreurs et répondre aux questions.

Masquez la PII autant que possible. Dans les écrans admin, affichez uniquement ce qui est nécessaire (par exemple, un email partiel comme j***@domain.com). Dans les logs, évitez de stocker les emails complets, noms ou tokens. Logger des IDs à la place.

Enfin, gardez les secrets hors du code et hors de la base. Clés API, secrets de signature JWT et sels de tokens de réinitialisation devraient vivre dans un stockage de secrets approprié, pas dans un fichier de config ou une table de paramètres.

Exemple : inventaire PII rapide pour un prototype d'inscription et d'invitation

Imaginez un prototype généré par IA : les utilisateurs s'inscrivent par email, créent un workspace et invitent des coéquipiers par email. Ça fonctionne en test, mais personne n'a noté où les données personnelles sont stockées.

Parcourez tout le flux une fois (inscription, invitation, réinitialisation de mot de passe), puis recherchez où les données atterrissent et où elles sont copiées. Dans une configuration typique vous trouverez de la PII à plusieurs endroits :

• Tables BDD : users (email, name), invites (invitee email, inviter id), audit_logs (parfois stocke des payloads bruts)
• Logs applicatifs : corps de requête, logs d'erreur, logs de jobs en arrière-plan
• Fournisseur d'email : templates, webhooks d'événements, logs de livraison qui incluent les adresses des destinataires
• Analytics/monitoring : identifiants utilisateurs, parfois des emails complets si quelqu'un les a loggés par erreur
• Caches et queues : payloads d'invite ou événements d'auth gardés plus longtemps que prévu

Une découverte risquée courante concerne la gestion des tokens. Par exemple, le prototype peut stocker un token de réinitialisation en clair dans une table password_resets, sans expiration (ou avec une valeur par défaut de 30 jours). Si quelqu'un a un accès en lecture à la BDD, il peut utiliser ce token pour prendre le contrôle des comptes. Notez si les tokens sont hachés, leur durée de vie et s'ils sont réutilisables.

Décidez ensuite ce qu'il faut arrêter de collecter maintenant versus plus tard. Beaucoup de prototypes n'ont pas besoin du nom complet à l'inscription, et les invites n'ont généralement pas besoin de conserver l'email de l'invité après acceptation ou expiration.

Voici une table de rétention simple à coller dans un doc et à assigner à un responsable :

Erreurs courantes qui font traîner la PII et les tokens

La plupart des prototypes ne fuient pas à cause d'un seul gros problème. Ils fuient parce que de petits choix s'accumulent et que personne ne revient pour nettoyer.

Un piège courant est de traiter les données de test comme inoffensives. Les équipes collent de vrais emails, noms et téléphones dans des fichiers de seed, écrans admin et imports CSV. Une semaine plus tard, cette base est copiée sur l'ordi d'un collègue ou sur un serveur staging. Maintenant la vraie PII est en trois endroits et personne ne se souvient d'où elle vient.

Une fuite discrète est de logger trop d'information. Les logs debug qui stockent les corps de requête ou les headers capturent souvent des tokens de session, des tokens de réinitialisation, des liens d'invitation ou des clés API. Ces logs vivent plus longtemps que prévu et sont partagés dans des tickets et du chat.

Les tokens deviennent aussi des « données pour toujours » si vous gardez des refresh tokens, des magic links ou des tokens d'invitation sans expiry (ou sans job de nettoyage). Vous vous retrouvez avec une longue liste d'identifiants toujours valides.

La duplication de la PII par commodité aggrave tout : recopier un email dans plusieurs tables, le mettre dans des événements analytics ou le stocker à nouveau dans une table de recherche. Votre inventaire doit signaler chaque copie pour que vous puissiez supprimer et expirer les données de manière cohérente.

Enfin, notez vos décisions. Sans une courte remarque comme "nous ne loggons jamais les headers Authorization", une future correction rapide ramènera le problème.

Checklist rapide et prochaines étapes

Faites ce passage avant de partager le prototype avec plus d'utilisateurs. L'objectif : trouver les copies et s'assurer que les données ne restent pas pour toujours.

Contrôles rapides qui attrapent la plupart des problèmes :

• Emails et noms : recherchez dans les tables, colonnes JSON, événements analytics et dumps de debug des champs comme email, name, firstName, lastName, profile, invitee.
• Tokens : notez où apparaissent tokens de session, clés API et liens de réinitialisation (BDD, cookies, localStorage, logs serveur, outils tiers).
• Secrets : scannez variables d'environnement, fichiers .env, artefacts de build et pages admin temporaires pour des clés codées en dur.
• Expiration : notez ce qui doit expirer (invites, resets, sessions), la durée exacte et quel job ou code le supprime.
• Accès : listez qui peut voir les données de production aujourd'hui (fondateurs, prestataires, agence, inbox support, dashboards BDD).

Quand vous avez les réponses, transformez-les en un petit jeu de corrections réalisables cette semaine. Limitez-vous à 3–5 items pour que ça soit faisable.

Si votre prototype a été généré par IA et commence à flancher sous de vrais utilisateurs, un diagnostic ciblé du code peut aider à trouver où PII, tokens et secrets fuient. FixMyMess (fixmymess.ai) se concentre sur la prise en charge des prototypes générés par IA pour les rendre prêts pour la production, et leur audit de code gratuit est un moyen pratique d'obtenir une liste claire des problèmes avant d'engager une reconstruction plus importante.