Anonymiser sans rendre opaque

Une fondation nous a confié un problème qui paraissait insoluble.

Elle gère un programme de parrainage : un bienfaiteur prend en charge un enfant de femme détenue, sur ses besoins essentiels, sa procédure judiciaire et son insertion professionnelle.

Le parrain veut choisir qui il aide, et savoir où va son argent. L'enfant est une personne vulnérable, souvent mineure, dont l'identité doit rester strictement protégée.

Rendre transparent ce qui doit rester confidentiel. Voilà le cahier des charges.

Pourquoi les réponses habituelles ne marchent pas

Tout montrer est exclu. Publier l'identité d'un enfant de détenue, c'est l'exposer pour la vie.

Tout cacher ne marche pas non plus. Un parrainage anonyme est un don anonyme, et un don anonyme ne se renouvelle pas. Le lien est ce qui fait revenir le donateur.

Entre les deux, la tentation est de créer des comptes, des messageries, des espaces privés. Chaque fonctionnalité ajoute une surface où l'identité peut fuir.

L'objet qui a résolu le problème

Nous avons conçu une seule pièce, et tout le reste en découle : le tableau synoptique anonymisé.

Chaque bénéficiaire y figure sous un matricule, avec exactement quatre informations, pas une de plus :

• l'âge
• le lieu de résidence avant l'incarcération
• l'origine territoriale
• le dixième du coût estimatif de prise en charge

C'est assez pour choisir. Ce n'est pas assez pour identifier.

Ces quatre champs ont été discutés un par un. Chacun devait passer un test unique : est-ce que cette information, croisée avec les trois autres, permet de retrouver une personne ? Le prénom a été écarté. La photographie a été écartée. Le nom de l'établissement a été écarté.

Pourquoi le dixième du coût, et pas le coût

Ce détail paraît anodin. Il porte tout le mécanisme.

Le parrain ne s'engage pas d'abord sur la totalité. Il verse un fonds de manifestation d'intérêt, égal au dixième du coût estimé. Ce versement est l'acte qui déclenche tout le reste.

Trois effets, obtenus par un seul choix :

1. Le montant total ne circule pas sur la page publique. Un dixième ne dit rien de la situation réelle de la personne.
2. L'engagement est progressif. Le parrain teste le dispositif avant de s'engager pleinement.
3. Le déclencheur est un fait financier vérifiable, pas un clic. La banque notifie, et cette notification ouvre le dossier.

Ce que le parrain obtient après son versement

C'est là que la transparence arrive, et elle est totale, mais réservée.

Une fois le versement constaté, le système produit trois documents pour ce parrainage précis :

• le cadre logique de l'intervention : les activités, les ressources nécessaires, les indicateurs de résultat
• le calendrier des tâches, avec les intervenants à chaque étape
• le tableau de bord financier, alimenté en temps réel

Le parrain voit chaque mouvement d'argent. Il ne voit toujours pas l'identité.

L'accès est verrouillé à deux personnes : le parrain et le bénéficiaire. Personne d'autre, pas même les autres parrains.

Ce que cela impose techniquement

Une architecture pareille ne tient que si l'infrastructure suit. Ce qui a été mis en place :

Mesure	Raison
Chiffrement des données sensibles au repos	Une base volée ne doit rien révéler
Validation manuelle de chaque inscription	Aucun compte ne se crée tout seul
Pare-feu applicatif et protection contre les attaques	Le profil des données attire
Double confirmation à l'inscription	Empêche l'usurpation d'adresse
Cloisonnement strict des accès	Un parrain ne voit que son dossier
Conformité aux règles d'accessibilité	Un donateur âgé doit pouvoir lire
Serveur dédié, sauvegardes automatisées, supervision permanente	Une interruption est une rupture de confiance

Et une décision d'architecture : les documents de suivi sont générés, pas stockés en clair. Ce qui n'existe pas de façon permanente ne peut pas fuir.

Ce qu'il faut retenir

La confidentialité n'est presque jamais un problème de chiffrement. C'est un problème de choix des champs.

La question n'est pas « comment protéger ces données », mais « de quelles données ai-je réellement besoin pour que le service fonctionne ». Dans ce projet, la réponse tenait en quatre lignes.

Chaque champ que vous ne collectez pas est un champ que vous n'aurez jamais à protéger.