La confidentialité by design signifie que le cloisonnement des données d'un outil communautaire IA est garanti par la structure de la base de données, pas par une consigne donnée au modèle d'IA. Une règle de base de données ne peut pas être contournée ; une instruction dans un prompt, si.
C'est la différence entre un coffre-fort et un post-it collé sur un tiroir. Le post-it dit « ne pas ouvrir ». Le coffre-fort rend l'ouverture physiquement impossible sans la bonne clé. Beaucoup d'outils communautaires qui utilisent l'IA fonctionnent au niveau du post-it : ils demandent au modèle de ne pas révéler certaines informations, et espèrent que la consigne tienne.
Pourquoi le prompt ne suffit pas
Une consigne donnée à un modèle d'IA reste une instruction en langage naturel, pas une barrière technique. Elle peut être contournée par une reformulation de question, ignorée en cas de mise à jour du modèle, ou tout simplement mal appliquée si le prompt est mal conçu.
Le problème ne vient pas de la mauvaise volonté d'un modèle. Il vient de la nature même du mécanisme : demander à un système probabiliste de respecter une règle absolue est structurellement fragile. Une architecture qui empêche l'accès à la donnée à la racine — avant même que le modèle ne la voie — élimine ce risque plutôt que de le gérer.
C'est pour cette raison que la confidentialité ne devrait jamais être présentée comme une fonctionnalité de l'IA, mais comme une propriété de l'infrastructure qui l'entoure : qui peut lire quoi, à quel niveau de la base de données, avant même que l'IA n'entre en jeu.
Les 4 garanties vérifiables
Un fournisseur sérieux doit pouvoir démontrer, pas seulement affirmer, quatre propriétés de son architecture.
| Garantie | Ce qu'elle signifie | Comment la vérifier |
|---|---|---|
| Cloisonnement au niveau base de données | Les règles d'accès (RLS — row-level security) sont écrites dans la base elle-même, pas dans le code applicatif ni dans un prompt | Demander si le fournisseur utilise du RLS ou équivalent, et si un audit de sécurité existe |
| Gradation de la confidence | Toute information n'a pas la même sensibilité ; un système doit distinguer ce qui est public dans la communauté, ce qui se dit en petit comité, et ce qui reste strictement privé | Demander combien de niveaux de partage existent et qui les définit (le membre ou le système) |
| Absence de profils publics et de compteurs | Rien n'incite un membre à afficher, comparer ou performer socialement ; le système sait des choses sur chacun sans les exposer | Vérifier s'il existe un feed, un classement, ou un nombre de connexions visible |
| Donnée matchable sans être restituable | Une information confidentielle peut servir de critère de calcul pour une mise en relation pertinente, sans jamais apparaître dans l'interface de l'autre membre | Demander un exemple concret : comment une information sensible influence une proposition sans être révélée |
Chez Majordome, cette dernière garantie prend une forme précise appelée le jardin secret : un niveau de confidence où un membre peut confier une information (un projet de reconversion, une difficulté financière, une recherche discrète) qui sera utilisée pour calculer de meilleures rencontres, sans jamais être écrite dans une présentation ni visible par qui que ce soit d'autre. La donnée travaille ; elle ne s'affiche pas.
Cette logique de gradation évite l'écueil que documente notre page sur les profils publics et la confiance : dès qu'un membre sait que ce qu'il déclare peut être vu par d'autres, il s'autocensure, et la donnée collectée perd sa valeur pour le matching.
Les questions à poser à un fournisseur
Avant de signer, cinq questions permettent de distinguer une architecture réelle d'une promesse marketing.
- « Le cloisonnement est-il imposé par la base de données ou par le code applicatif ? » Si la réponse évoque uniquement des « règles métier » ou des « permissions applicatives », le cloisonnement dépend de la qualité du code, pas d'une garantie structurelle.
- « Combien de niveaux de confidentialité existent, et qui les définit ? » Un seul niveau (tout est visible par l'équipe d'animation, par exemple) est insuffisant pour des communautés où circulent des informations sensibles (situation professionnelle, projets personnels).
- « Une information confidentielle peut-elle influencer une mise en relation sans être révélée ? » Demandez un exemple concret. Si le fournisseur ne peut pas l'illustrer, c'est probablement que son système ne fait pas cette distinction.
- « Où sont hébergées les données, et sous quel régime juridique ? » Un hébergement hors Union européenne complique la conformité RGPD, même si le produit lui-même est bien conçu.
- « Existe-t-il un audit de sécurité tiers, ou seulement une déclaration ? » Une architecture réelle se documente et s'audite ; une promesse se décrit en une phrase sur une page commerciale.
Ces questions recoupent celles qu'il faut poser plus largement sur la gestion des données de vos membres, détaillées dans notre page sur le RGPD et les données de membres.
RGPD et AI Act : ce que la loi impose réellement
Le RGPD impose un principe de minimisation des données et une protection « adaptée au risque », mais ne dicte aucune architecture technique précise. Il est possible d'être formellement conforme au RGPD avec un système qui cloisonne mal les données en interne, tant que le traitement global respecte les obligations de consentement, de finalité et de durée de conservation.
C'est l'AI Act européen, entré en application progressive à partir de 2024, qui pousse plus loin en exigeant de la transparence sur le fonctionnement des systèmes d'IA, en particulier sur la manière dont les données servent à produire une décision ou une recommandation. Le matching communautaire ne figure pas parmi les catégories à haut risque de l'annexe III du règlement (biométrie, emploi, services essentiels…) ; il relève du régime général, avec les obligations de transparence de l'article 50 — informer clairement les membres qu'ils interagissent avec un système d'IA. Un outil qui ne peut pas expliquer comment une donnée a influencé une proposition de rencontre reste en position fragile face à cet esprit de transparence.
Concrètement, la conformité réglementaire et la confidentialité by design ne se confondent pas : on peut cocher les cases légales sans avoir une architecture réellement protectrice. La confidentialité by design va au-delà de la loi ; elle relève d'un choix d'ingénierie, pas d'une obligation.
Ce que ça change concrètement pour une communauté
Une communauté qui gère des informations sensibles — situations professionnelles, projets de reconversion, difficultés personnelles, montants d'investissement — expose ses membres dès que l'architecture ne garantit pas le cloisonnement. Le risque n'est pas hypothétique : un simple bug applicatif peut suffire à afficher une donnée à la mauvaise personne si la protection ne repose que sur du code, pas sur des règles de base de données.
C'est pour cette raison que le matching IA pour communautés privées ne peut pas se juger uniquement sur la qualité de ses propositions de rencontre. Un système qui propose d'excellentes rencontres mais expose les données au passage résout un problème en créant un autre, plus grave. La discrétion est une propriété de l'architecture : vérifiable, ou absente. Aucune consigne écrite dans un prompt n'en tient lieu.
Questions fréquentes
Qu'est-ce que la confidentialité by design dans un outil communautaire IA ?
C'est une architecture où le cloisonnement des données est imposé par la base de données elle-même (via des règles comme le RLS), pas par une instruction donnée au modèle d'IA. Une instruction peut être contournée ou mal interprétée ; une règle de base de données non.
Le RLS est-il obligatoire pour un outil communautaire IA ?
Il n'est pas légalement obligatoire, mais c'est le mécanisme technique le plus sûr pour garantir qu'un membre A ne puisse jamais lire les données confidentielles d'un membre B, même en cas de bug applicatif. Sans RLS, la protection dépend entièrement de la qualité du code applicatif, ce qui est plus fragile.
Un outil basé sur ChatGPT ou un LLM générique peut-il garantir la confidentialité ?
Cela dépend de ce qui se passe autour du modèle, pas du modèle lui-même. Un LLM à qui on demande poliment de ne pas révéler une information peut la révéler si le prompt est mal formé ou contourné ; seule une architecture qui empêche physiquement l'accès à la donnée est fiable.
Que veut dire donnée matchable sans être restituable ?
Cela signifie qu'une information confidentielle (un salaire, un projet de reconversion) peut servir de critère de calcul pour proposer une rencontre pertinente, sans jamais être affichée ni communiquée à l'autre membre. Le système l'utilise, il ne la révèle pas.
Le RGPD impose-t-il ce niveau de cloisonnement ?
Le RGPD impose une protection adaptée au risque et le principe de minimisation des données, mais ne dicte pas d'architecture précise. C'est l'AI Act européen, en imposant de la transparence sur le fonctionnement des systèmes d'IA, qui pousse les fournisseurs à documenter précisément qui accède à quoi.