Chiffrement interrogeable prêt pour la prod : le playbook du CTO pour la confidentialité au niveau des champs

Vous ne pouvez plus dire à votre board que « le chiffrement au repos » suffit. Vos juristes savent que non, vos clients s’y attendent, et tout ingénieur avec un accès psql peut encore SELECT les données les plus sensibles de votre système. Et vous devez quand même les interroger : retrouver un utilisateur par email, dédupliquer des numéros de téléphone, filtrer par plage de date de naissance. La crypto entièrement homomorphe ne vous sauvera pas en 2026. Un chiffrement interrogeable pragmatique, oui — à condition de choisir les bons patterns, d’accepter les bonnes fuites, et de l’opérationnaliser.

Ce qui a changé : le chiffrement interrogeable au niveau des champs est passé de la recherche à la feuille de route

Le buzz de la semaine dernière autour de Supabase ajoutant la recherche chiffrée au niveau champ via CipherStash est plus qu’une mise à jour produit — c’est le signal que le chiffrement interrogeable est enfin en train de franchir le gouffre. Vous n’avez plus besoin d’exécuter un service crypto sur mesure pour faire fonctionner des requêtes d’égalité et de plage sur des données chiffrées. Et vous n’avez plus à choisir entre « personne ne peut requêter quoi que ce soit » et « les DBA peuvent tout lire ».

La contrepartie : vous devez être explicite sur les requêtes que vous supporterez, ce que vous acceptez de laisser fuiter (ordre, fréquence, patterns d’accès) et où résident les clés. Faire comme si ces arbitrages n’existaient pas, c’est soit faire exploser les perfs, soit offrir aux attaquants un canal auxiliaire exploitable.

Commencez par un modèle de menace, pas par une bibliothèque

Si vous n’écrivez pas noir sur blanc qui vous cherchez à protéger, vous allez sur- ou sous-concevoir. Voici le cadre d’évaluation rapide que nous utilisons avec des CTO :

Adversaires que vous prenez probablement au sérieux

• Internes du cloud et instantanés (snapshots) de base de données : Sauvegardes Postgres managées, journaux de base, accès support. Le chiffrement au repos protège les disques, pas les opérateurs.
• Exfiltration via injection SQL ou réplique de lecture mal configurée : Des attaquants automatisés qui peuvent vider des tables mais ne peuvent pas exécuter votre code applicatif.
• Requêtes légales ou dérive de résidence des données : Vous devrez peut-être prouver que le personnel de production (voire votre cloud) ne peut pas déchiffrer certains champs.

Adversaires contre lesquels vous ne gagnerez probablement pas avec la crypto seule

• Couche applicative totalement compromise : Si un attaquant possède le process qui détient les clés, il peut déchiffrer. Compensez avec des limites de débit, une détection d’anomalies et des clés de courte durée, mais partez du principe que le déchiffrement est possible.
• Masquage parfait des patterns d’accès : Oblivious RAM n’est toujours pas praticable pour votre SaaS. Acceptez que les patterns d’accès fuient sans coût lourd.

Traduisez cela en politique : « Protéger les PII de la base de données et des opérateurs cloud ; tolérer la fuite des patterns de requêtes ; considérer qu’une compromission de l’app équivaut à du déchiffrement ; chiffrer champ par champ avec des clés que la base ne voit jamais. »

Le cadre de décision : choisissez les techniques par requête, pas par table

Le chiffrement interrogeable est un ensemble de techniques. Utilisez l’outil le plus léger qui satisfait vos exigences de requête et votre modèle de menace.

1) Cartographiez vos patterns de requêtes

• Égalité : Retrouver par email, téléphone, SSN/CPF/CNPJ, ID de facture.
• Préfixe : Rechercher un email par nom d’utilisateur ou un téléphone par indicatif pays + indicatif régional.
• Intervalles/Tri : Plages de dates de naissance, montants de commande entre X et Y, tri par last_activity_at.
• Flou/Texte : Recherche de noms, adresse contenant une sous-chaîne.

Puis qualifiez la sensibilité. Email, téléphone, SSN/CPF sont très sensibles. Code postal, ville ou état le sont moins (mais restent des PII dans beaucoup de régimes). Ne gaspillez pas de complexité cryptographique sur des agrégats non sensibles.

2) Choisissez la bonne primitive par champ

Voici les briques qui se déploient réellement en 2026 :

• Chiffrement déterministe (DE) pour l’égalité : Canonicalisez l’entrée (email en minuscules, E.164 pour le téléphone), puis chiffrez avec un mode déterministe (par ex., AES-SIV). Même clair → même chiffré, ce qui permet des comparaisons d’égalité et des index hachés. Fuites : fréquence (les mêmes valeurs produisent les mêmes chiffrés), motifs d’égalité entre lignes.
• Index aveugles pour l’égalité et le préfixe : Calculez un HMAC avec un sel secret sur la valeur canonique (ou ses n-grammes pour la recherche par préfixe) et indexez ces jetons. Ne stockez que les jetons dans la base, pas le clair ni les sels. Fuites : égalité des jetons et comptages de jetons ; atténuées par des sels par tenant et un pepper dans un KMS.
• Révélation d’ordre ou plages bucketisées : Le vrai chiffrement révélateur d’ordre existe, mais les fuites peuvent être violentes. Un schéma pragmatique est la bucketisation : mapper un champ numérique/temporel à des tranches (p. ex., mois, tranches de 10 $) et indexer les jetons de tranche. Plus la granularité est grossière → moins de fuites et des index plus petits, mais davantage de faux positifs à filtrer dans l’app.
• Recherche chiffrée côté client ou côté service pour le texte : Si vous avez besoin de recherche plein texte sur des champs sensibles, admettez que vous pousserez l’indexation à un client ou à un service de recherche chiffrée qui détient les clés côté application (CipherStash est une option). Essayer de greffer une recherche texte floue sur Postgres avec des garanties cryptographiques est la meilleure manière de tuer un projet.

Retour à la réalité : 80 % des requêtes sur champs sensibles dans le B2B SaaS sont des égalités ou des plages grossières. Vous pouvez sécuriser cela aujourd’hui sans mathématiques lunaires.

3) Gestion des clés qui ne torpille pas la latence

• Clés enveloppes par tenant : Générez une Data Encryption Key (DEK) par tenant ou dataset. Chiffrez les DEK avec une Key Encryption Key (KEK) dans un KMS managé (AWS KMS, GCP KMS). Stockez la DEK chiffrée à côté des métadonnées du tenant.
• Chauffez le cache : Au démarrage de l’app ou à l’accès d’un tenant, déchiffrez la DEK via KMS une fois et gardez-la en mémoire avec un TTL court (par ex., 10–15 minutes). Attendez-vous à ~1–3 ms par déchiffrement KMS à chaud ; ne le faites pas par ligne.
• Faites tourner sans interruption : Versionnez les DEK. En écriture, utilisez la DEK v2 ; en lecture, essayez v2 puis retombez sur v1. Rattrapez en lots.
• Scinder la confiance : Gardez les sels/peppers pour les index aveugles dans un KMS ou un service adossé à un HSM ; ne les stockez jamais dans la base.

4) Maths de performance et stockage (pour éviter les suppositions)

• Égalité avec DE ou index aveugle : Surcoût de stockage ~1,1–1,3x par champ (chiffré + jeton). La latence de requête est dominée par le réseau/IO ; comptez +5–15 ms p95 par rapport à une recherche indexée classique, dû à la tokenisation côté app et au post-filtrage.
• Préfixe avec n-grammes : Si vous indexez des 3-grammes pour les parties locales d’email, vous stockerez ~L-2 jetons par valeur (L = nombre de caractères dans le segment préfixable). Un gonflement d’index de 2–4x est courant ; limitez les champs à préfixe et normalisez-les.
• Plages bucketisées : Avec des tranches mensuelles pour les dates, une fenêtre de 10 ans représente 120 tranches. La plupart des requêtes touchent 1–3 tranches. Attendez-vous à une amplification de faux positifs de 1,2–1,5x que vous filtrerez dans l’app. Le surcoût de bout-en-bout de +10–30 ms p95 est typique.
• Recherche texte chiffrée via service : Les index peuvent représenter 2–5x le texte brut, et l’ingestion ajoute +20–80 ms par écriture selon le batching. Les lectures ajoutent un saut réseau ; budgétez +25–60 ms p95.

Ce sont des ordres de grandeur que nous avons vus sur Postgres 14–16 et des KMS managés en régions us-east. Votre topologie VPC et le comportement de votre ORM les feront varier plus que la crypto.

Une architecture concrète qui passe en prod

PII Vault + index aveugles + service de recherche chiffrée (optionnel)

• Microservice PII Vault : Un service fin qui détient les DEK et les sels en mémoire, parle au KMS, et expose des fonctions encrypt/decrypt/index via un RPC strictement contrôlé. Seules vos couches application et workers peuvent l’appeler. Il journalise les événements de tokenisation, pas le clair.
• Canonicalisation côté application : Mettre en minuscules, trimmer et normaliser. Pour Brazil, supprimez les accents dans les noms pour les jetons de recherche, appliquez E.164 aux numéros de téléphone, et validez les formats CPF/CNPJ avant chiffrement. L’objectif de la canonicalisation est d’éviter plusieurs chiffrés pour « la même » valeur.
• Schéma Postgres : Pour chaque champ sensible, stockez le chiffré (bytea) et une ou plusieurs colonnes d’index aveugle (bytea ou bytea de longueur fixe). Créez des index B-tree ou hash sur les colonnes d’index aveugle ; n’indexez jamais le chiffré lui-même.
• Triggers ou écritures côté application : À l’insertion/mise à jour, appelez le vault : chiffrez le clair et calculez les jetons ; écrivez chiffré + jetons dans une seule transaction. Nous préférons côté application pour garder le vault et les sels hors de la base, mais des triggers sont acceptables s’ils appellent une extension sûre ou un RPC de type FDW.
• Pattern de requête : Convertissez l’entrée utilisateur en jetons dans l’app, requêtez par jetons, récupérez les lignes candidates, et ne déchiffrez que le sous-ensemble renvoyé. Ne tirez jamais les chiffrés côté client.
• Service de recherche chiffrée (optionnel) : Pour les 10–20 % de champs nécessitant du flou ou du classement, poussez les documents vers un service de recherche chiffrée couplé à votre vault (par ex., CipherStash ou un équivalent managé). Gardez votre base comme source de vérité et joignez sur des identifiants stables.

Avec cela, votre base et votre fournisseur cloud ne peuvent pas lire les PII, mais votre app peut toujours répondre à 95 % des requêtes produit avec une latence acceptable.

Construire vs acheter en 2026

Vous avez trois options crédibles :

• Le faire vous-même avec un vault et Postgres : Contrôle maximal, lock-in éditeur minimal, mais vous devez assumer la canonicalisation, la génération de jetons et la rotation. Comptez 4–6 semaines pour qu’une équipe senior livre égalité + préfixe + plages bucketisées sur 3–5 champs, puis 2–3 semaines de plus pour mettre en production la rotation des clés, les journaux d’audit et les dashboards.
• Utiliser une couche de recherche chiffrée managée (par ex., CipherStash) : Time-to-value plus rapide pour les requêtes délicates, APIs cohérentes et rotation intégrée. Vous aurez un saut réseau supplémentaire et un coût éditeur, mais un modèle de fuite plus clair et moins de pièges.
• Déporter une partie de la recherche côté client : Pour les apps grand public, déplacer la recherche nom/adresse sur le device (avec des index locaux) peut éliminer totalement les fuites côté serveur. C’est réel sur Android 17 et les iOS modernes, mais des contraintes UX et offline s’appliquent.

Notre heuristique : si vous avez besoin de plus que l’égalité + des tranches mensuelles sur 2–3 champs, achetez la couche. Si la plupart des requêtes sont des lookups par email/téléphone/ID, construisez le vault ; vous amortirez l’investissement en contrôle et en coût.

Pièges classiques (et comment les éviter)

• Hachage au lieu de HMAC pour les index aveugles : SHA-256 sans clé est un cadeau pour des attaquants avec des tables arc-en-ciel. Utilisez un HMAC clé avec des sels par tenant et un pepper détenu dans un KMS.
• Chiffrer dans la base de données : Si votre base peut déchiffrer, votre DBA cloud le peut aussi. Gardez clés et tokenisation côté application ou côté vault uniquement.
• Sauter la canonicalisation : « John.Smith+promo@example.com » doit être égal à « johnsmith@example.com » dans vos sémantiques de recherche. Définissez, testez et figez la canonicalisation par champ.
• Index de préfixe non bornés : Les explosions de n-grammes arrivent vite. Cappez la longueur de préfixe que vous supportez (par ex., 5 premiers caractères de la partie locale) et faites-en une exigence produit.
• Rotation de DEK sans versioning : Écrivez toujours la version de clé utilisée pour chiffrer dans les métadonnées du chiffré. Les lectures doivent essayer la plus récente d’abord, puis les versions plus anciennes, puis échouer.
• Pas de budget pour les faux positifs : Les tranches d’intervalles et les n-grammes exigent un filtrage côté app. Rendez-le explicite dans vos SLO de latence et surveillez p95/p99 séparément des timings base.

Migration sans arrêt de service un week-end

30 jours : prouver le pattern

• Choisissez deux champs : email et date de naissance. Livrez un chiffrement déterministe + index aveugle d’égalité pour l’email ; des jetons de tranches mensuelles pour la date de naissance.
• Activez la double écriture : les colonnes en clair restent pour l’instant la référence ; écrivez chiffré + jetons en parallèle.
• Ajoutez un déchiffrement en lecture pour les systèmes aval qui ont encore besoin du clair ; journalisez les points d’appel.

60 jours : basculer les lectures et démarrer la rotation

• Basculez les requêtes vers des lookups par jetons ; ne déchiffrez que ce que vous retournez.
• Rattrapez les lignes existantes par lots (p. ex., 10k/minute) pendant les périodes creuses. Mesurez la croissance des index et la latence p95.
• Introduisez le versioning des DEK ; faites passer 10 % des tenants à v2 ; surveillez les régressions.

90 jours : déprécier le clair, étendre la couverture

• Gérez l’accès au clair via une courte allowlist et retirez-le des modèles d’ORM.
• Étendez à téléphone et CPF/CNPJ avec une canonicalisation dépendante du pays.
• Décidez construire vs acheter pour toute recherche floue restante. Si vous achetez, intégrez le service de recherche chiffrée maintenant et retirez les index ad hoc.

Conformité et résidence des données : ce qui intéresse réellement les régulateurs

HIPAA, GLBA, et la LGPD de Brazil ne prescriront pas d’algorithmes. Ils demanderont si des parties non autorisées (y compris votre cloud) peuvent lire des PII au repos. Le chiffrement au niveau champ avec des clés détenues côté application est une réponse solide. Si vous opérez aux US et au Brazil, gardez les DEK résidentes là où les régulateurs s’y attendent (souvent la même région que le data store) et documentez les flux. Quand la discovery arrive, vous voulez montrer que les snapshots de base de données de production sont cryptographiquement inertes sans votre couche applicative.

Ce qu’il faut dire à votre équipe Produit

La recherche chiffrée n’est pas gratuite. Rendez explicites trois contraintes dès le départ :

• Les correspondances exactes sont rapides ; le flou ne l’est pas : Préfixes limités à N caractères, noms normalisés et insensibles aux accents au moment de la tokenisation.
• Les intervalles sont bucketisés : Les recherches de date de naissance se font par mois ou trimestre, pas par filtres arbitraires de jour de semaine.
• Le coût se voit dans le stockage et un petit impôt de latence : Prévoyez 1,3–2,0x de croissance des index sur les champs chiffrés et +10–30 ms p95. C’est le prix de ne pas remettre les clés à votre cloud.

Où s’inscrivent Supabase + CipherStash

Si vous êtes déjà sur Supabase ou Postgres managé, une intégration de recherche chiffrée (comme le récent travail Supabase + CipherStash) peut éliminer beaucoup de yak shaving : bibliothèques clientes pour la tokenisation, bons par défaut pour égalité/préfixe/plage, et rotation managée. Votre modèle de fuite ne sera pas nul — l’ordre et les patterns d’accès fuient toujours — mais vous aurez une équipe produit qui maintient ces modèles et un chemin de migration qui ne nécessite pas un PhD en crypto. Évaluez sur trois axes : couverture de requêtes (vos requêtes réelles rentrent-elles ?), SLO de latence avec votre forme de données, et contrôle des clés (pouvez-vous apporter votre propre KMS ?).

L’angle Brazil : ne laissez pas la localisation casser votre crypto

Pour des stacks US–Brazil, la normalisation compte plus que d’habitude :

• Noms : Supprimez les diacritiques pour les jetons de recherche mais préservez-les dans le chiffré ; construisez des comparateurs sensibles à la locale.
• Téléphones : Imposez E.164 avec gestion du DDD ; des données issues de WhatsApp arrivent souvent mal formées. Normalisez ou vous manquerez des correspondances.
• CPF/CNPJ : Validez et normalisez (supprimez la ponctuation) avant la tokenisation. Envisagez une mise en forme préservée uniquement à l’affichage après déchiffrement.

Si vous ratez la normalisation, vous multiplierez les chiffrés pour le même utilisateur, ferez exploser la taille des index et torpillerez les taux de correspondance.

Quand ne pas le faire

Si votre proposition de valeur centrale est la recherche floue sur du texte intrinsèquement sensible (par ex., un moteur de recherche de personnes), vous avez soit besoin d’une architecture très côté client, soit d’accepter que votre équipe ops puisse lire les données. Les demi-mesures vous donneront le coût sans la vraie confidentialité. Pour tous les autres — le SaaS mainstream qui gère dossiers utilisateurs, transactions et workflows de support — les techniques ci-dessus suffisent pour passer du « théâtre du chiffrement » à un contrôle substantiel.

L’essentiel

Le chiffrement interrogeable a cessé d’être un projet de recherche. Les requêtes d’égalité et de plage pragmatiques sur des champs chiffrés sont tout à fait à portée avec du chiffrement déterministe, des index aveugles et une gestion de clés disciplinée. Ajoutez un service de recherche chiffrée pour les 10–20 % de requêtes qui en ont besoin, et votre app pourra enfin répondre aux requêtes de support, fraude et facturation sans donner votre cloud provider ou votre DBA en clair. C’est une réduction de risque matérielle que vous pouvez expliquer à votre board — et une posture que vos clients remarqueront la prochaine fois qu’un concurrent fuira un snapshot.

Points clés

• Décidez d’abord contre quoi vous vous protégez : les insiders cloud/DB et les fuites via snapshots sont réalistes ; une couche applicative totalement compromise n’est pas résoluble par la crypto seule.
• Utilisez un chiffrement déterministe ou des index aveugles pour l’égalité ; bucketisez les plages ; poussez la recherche floue côté client ou vers un service de recherche chiffrée.
• Gardez les clés hors de la base : DEK par tenant, KEK adossée à un KMS, TTL mémoire court, et versioning explicite des clés.
• Budgez 1,3–2,0x de stockage d’index sur les champs chiffrés et +10–30 ms p95 de latence pour la plupart des requêtes.
• Normalisez agressivement (emails, téléphones, CPF/CNPJ, diacritiques) avant la tokenisation ou vous manquerez des correspondances et ferez gonfler les index.
• Construisez votre propre vault si vous ne faites que de l’égalité + des plages grossières ; achetez une couche de recherche chiffrée si vous avez besoin de texte flou ou classé.
• Migrez en 90 jours avec double écriture, bascule des lectures et rotation graduelle des clés ; n’essayez pas un cutover d’un seul week-end.