Chiffrement homomorphe pour l’inférence privée : le guide 2026 du CTO

Tous les quelques trimestres, un gros titre sur la confidentialité promet monts et merveilles. La version de ce mois-ci : « Google rend l’IA privée pratique grâce au chiffrement homomorphe. » Si vous êtes un CTO avec des PII, des PHI ou des paiements dans les entrées de vos modèles, cette phrase ressemble à un code de triche pour la conformité. Chiffrez tout, calculez quand même, dormez mieux.

Vérification de la réalité : le chiffrement homomorphe (HE) passe enfin des échanges entre initiés en crypto aux backlogs d’ingénierie. Mais ce n’est pas une balle d’argent pour les chatbots ni pour l’inférence complexe. En 2026, HE est un outil de précision. Bien utilisé, il élimine une vilaine classe de scénarios de brèche et simplifie votre posture juridique. Utilisé de façon large, il enflamme votre facture d’infrastructure et fait exploser votre latence.

Ce qui vient de changer — et ce qui n’a pas changé

Les travaux de recherche des grands fournisseurs et de l’open source (par ex., les travaux de compilation de Google visant les runtimes HE, et les progrès réguliers dans OpenFHE, Microsoft SEAL et Zama’s Concrete) se traduisent pour vous par deux conséquences pratiques :

• L’ère des « jouets seulement » est terminée : De petits modèles réels (linéaire/logistique, minuscules MLP, CNN peu profondes) peuvent tourner sous HE avec une latence de la seconde à la minute si vous contraignez paramètres et opérations. Ce n’était pas vrai à ce niveau il y a cinq ans.
• L’écart de vitesse reste brutal : Attendez-vous à 10^2 à 10^4 de surcharge par rapport au calcul en clair, selon le schéma et la profondeur du circuit. Les transformers restent au stade de la « démo académique », pas des SLA de production.

Traduction : vous pouvez livrer HE pour des cas d’usage étroits et à forte valeur où votre avantage vient de rendre le serveur aveugle. Vous ne pouvez pas greffer HE sur votre copilote RAG tout en gardant un TTI de 300–500 ms.

Commencez par le modèle de menace, pas par le benchmark

HE concerne qui vous cachez pendant le calcul, pas juste « la vie privée, c’est bien ». Voici l’échelle courte.

Qui essayez-vous d’« aveugler » ?

• Admin cloud curieux / SRE malveillant : HE aide. Les données restent chiffrées au repos, en transit et pendant le calcul sur vos serveurs.
• Divulgation forcée / accès transfrontalier : HE aide si vous gardez les clés côté client ou hors du périmètre de calcul. Faites valider cela par vos juristes.
• Fournisseur malveillant / nœud d’hyperscaler compromis : HE aide par défaut, mais les canaux auxiliaires et les métadonnées demeurent.
• Terminal client compromis : HE n’aide pas. Le clair naît en périphérie.
• Interne ayant accès aux clés : Si vos ops peuvent atteindre les clés, HE peut relever du théâtre. Rendez la frontière des clés explicite.

Si vous ne ciblez pas au moins les deux premières catégories, les enclaves ou un durcissement standard constituent sans doute un meilleur 80/20.

Ce qui est livrable en 2026 (et ce qui ne l’est pas)

Bonnes pistes (pilotes sur 90 jours réalistes)

• Scoring chiffré sur des vecteurs de caractéristiques numériques : risque de fraude, drapeaux AML, scores d’acceptation, offres/éligibilité, scores de similarité PII, modèles d’ad-lift. Visez 20–200 caractéristiques ; forme polynomiale/logistique.
• Opérations ensemblistes privées via arithmétique approchée supportée par HE : déduplication, vérification de chevauchement avec des partenaires sans révéler les identifiants bruts (lorsque vous pouvez encoder en embeddings et opérer de façon additive).
• Décisions à seuil : Renvoyez un score ou un oui/non. Évitez les argmax lourds sur de grandes classes ; gardez le post-traitement en local.

Peut-être, avec des compromis

• Toutes petites CNN pour la classification : Vous remplacerez les opérations non polynomiales (ReLU, max-pool) par des polynômes compatibles HE. Attendez-vous à des baisses de précision et à des latences de quelques secondes à quelques minutes.
• Arbres boostés par gradient : Possible si vous convertissez en circuits arithmétiques, mais la profondeur de circuit explose. Souvent plus simple de distiller vers un petit MLP et de l’utiliser sous HE.

Pas encore (à éviter)

• Chat LLM interactif : La latence et la profondeur multiplicative rendent cela irréaliste en production. Si quelqu’un vous dit « nous faisons tourner des transformers entièrement de manière homomorphe en temps réel », demandez un second avis.
• Plans d’agents multi-outils sous HE : Trop d’opérations à embranchements et non polynomiales. Utilisez des enclaves ou du sur-appareil pour les étapes sensibles à la place.

Choisir le bon schéma pour la tâche

Vous n’avez pas besoin de devenir cryptographe, mais vous devez connaître les trois familles dont on vous parlera.

• CKKS (arithmétique approchée) : Idéal pour des vecteurs réels et du scoring ML. Vous échangez de la précision contre des performances. La plupart des démos « régression/MLP chiffrées » utilisent CKKS.
• BFV/BGV (arithmétique entière exacte) : Utile quand la correction exige des mathématiques discrètes, mais les performances sont pires pour les charges ML typiques.
• TFHE/CGGI (booléen porte par porte) : Extrêmement flexible, pénible pour les réseaux profonds. Brille dans des circuits avec beaucoup de contrôle de flot mais une profondeur modeste.

Règle empirique : Si votre modèle en clair est linéaire ou un petit MLP sur des flottants, commencez avec CKKS. Gardez la profondeur de circuit minimale pour éviter des bootstraps fréquents (l’étape de « rafraîchissement » coûteuse).

Latence, débit et coût — les seuls chiffres qui comptent

Vous verrez des micro-benchmarks à faire tourner la tête. Ignorez-les. Modélisez votre propre charge avec des distributions de caractéristiques et des profondeurs de circuit représentatives.

Chiffres de planification « au dos de l’enveloppe »

• Surcharge : 100×–10 000× par rapport au clair est une fenêtre de planification raisonnable aujourd’hui. Commencez à modéliser à 1 000× ; fêtez si vous faites mieux.
• Latence par requête : Un petit modèle logistique sous CKKS atterrit souvent en quelques secondes à une dizaine de secondes sur un CPU haut de gamme, ou sous 5 s avec un chemin GPU optimisé. Tout ce qui est plus profond grimpe vite.
• Débit : Batcher agressivement. HE adore le packing de type SIMD de nombreuses caractéristiques dans un seul texte chiffré ; votre coût par requête baisse à mesure que vous remplissez les slots.

Exemple de modèle de coût

Supposez que vous scorez 100k utilisateurs/jour avec un modèle logistique à 64 caractéristiques. En clair : une seule instance CPU modeste peut faire cela en millisecondes par requête, disons quelques centaines par mois en infra. Sous CKKS avec une surcharge de 1 000×, vous envisagerez sans doute quelques nœuds CPU puissants ou un service adossé à GPU, ce qui pousse vers quelques dizaines de milliers par mois. Payer cinq chiffres pour rendre vos serveurs aveugles aux PII, est-ce que ça vaut le coup ? Si cela vous permet de conclure avec une banque qui dirait autrement non, la réponse est probablement oui.

Architectures qui fonctionnent sans faire dérailler votre feuille de route

Schéma 1 : HE pour le cœur sensible, clair pour le reste

Chiffrez les caractéristiques côté client, envoyez-les à un service de scoring HE dédié, récupérez un scalaire unique. Tout le reste (identité, journalisation, personnalisation) reste en clair. Vous avez réduit le rayon d’explosion de la compromission en gardant la jointure critique — attributs utilisateur vers décision — hors de portée du serveur.

• Détail clé : Gardez les clés privées hors du périmètre de calcul. Le service de scoring ne doit jamais voir les clés de déchiffrement.
• Où HE aide : Les équipes juridiques et de risques fournisseurs adorent. Même une exfiltration complète de la base ne livre que des caractéristiques chiffrées.

Schéma 2 : Confiance partagée — HE plus enclaves

Utilisez des enclaves (TDX/SEV-SNP) pour les étapes de pré/post-traitement lourdes et HE pour le calcul final. Par exemple, tokenisation et normalisation dans une enclave, puis scoring homomorphe, puis de nouveau enclave pour l’application du seuil ou l’audit.

• Pourquoi : Les enclaves sont rapides mais élargissent la base de confiance aux constructeurs matériels et aux services d’attestation. HE minimise cette confiance sans payer le coût HE partout.

Schéma 3 : Edge hybride

Générez des embeddings sur l’appareil, chiffrez-les, et n’envoyez que le vecteur. Le scoring homomorphe s’exécute côté serveur ; le client interprète le score localement. Vous évitez les PII brutes tout en gardant le contrôle du modèle centralisé.

La gestion des clés fait la réussite ou l’échec du projet

HE permet de calculer sans déchiffrer, mais quelqu’un détient toujours les clés de déchiffrement. Traitez cette frontière comme une exigence produit, pas comme une note de bas de page.

• Clés détenues côté client : Meilleure posture de confidentialité. Les clés vivent dans des enclaves sécurisées mobiles ou le stockage du navigateur protégé par un keystore de plateforme. Prévoyez des issues de secours pour la récupération et la rotation.
• Clés détenues par le partenaire : En intégrations B2B, chaque partenaire chiffre avec sa clé publique et déchiffre les résultats localement. Vous ne touchez jamais le clair.
• Clés détenues côté serveur : Défait généralement l’objectif, sauf si les clés sont étagées et physiquement séparées du calcul avec des politiques strictes et des HSM.

Quel que soit votre choix, consignez-le comme une politique. Les auditeurs demanderont, et vos SRE auront besoin du runbook quand une rotation tourne mal.

Qu’est-ce que la conformité y gagne vraiment ?

Les juristes se soucient des définitions. Si vous pouvez soutenir de manière crédible « aucun texte en clair n’a jamais existé côté serveur pour la jointure sensible », les obligations de notification de brèche peuvent changer de façon matérielle. C’est spécifique à la juridiction. Votre conseil peut traiter des données traitées homomorphiquement comme étant hors de certains périmètres si les clés ne franchissent jamais la frontière de calcul et si vous journalisez des preuves (p. ex., attestation de chiffrement avant l’ingestion, paramètres cryptographiques, et absence de chemins de déchiffrement en production).

N’en promettez pas trop. Les métadonnées (IP, horodatages, tailles de charge utile) fuient toujours. Vous aurez toujours besoin de clauses DPA, de DPIA et d’une rétention saine. Mais votre position de négociation avec des partenaires réglementés sera meilleure.

Outils réellement exploitables

• OpenFHE : Successeur moderne de la lignée PALISADE/HElib, supporte CKKS/BFV/BGV et des voies d’accélération GPU via des projets communautaires. C++ cœur avec bindings Python.
• Microsoft SEAL : Bibliothèque éprouvée (CKKS/BFV). Pas de voie GPU officielle, mais mûre et bien documentée. Bien pour des premiers pilotes.
• Zama Concrete : Axé TFHE avec une ergonomie Rust. Excellent pour les circuits booléens ; attendez-vous à du travail si votre modèle est riche en flottants.
• Compiler/tooling : Surveillez les projets de type MLIR/HEIR qui abaissent des graphes ML vers des circuits compatibles HE. Utile pour estimer la profondeur de circuit et le nombre de bootstraps même si vous ne les déployez pas encore.

Pour le navigateur, associez les bibliothèques serveur à une fine couche de chiffrement côté client. Vous expédierez probablement un module WebAssembly pour empaqueter les caractéristiques en textes chiffrés. Allouez du vrai temps au durcissement, y compris l’isolation d’origine et l’anti-altération des clés.

Pièges récurrents dans les pilotes

• Choisir la mauvaise activation : Votre non-linéarité favorite n’est pas compatible HE. Utilisez des polynômes de faible degré (p. ex., approximations de Chebyshev) et acceptez la perte de précision.
• Épuisement du budget de bruit : Les circuits profonds meurent en vol. Les circuits peu profonds gagnent. Budgétez vos bootstraps explicitement.
• Canaux auxiliaires via les embranchements : Si le serveur peut inférer des secrets du fait que vous avez pris le chemin A ou B, c’est perdu. Gardez le calcul aussi uniforme que possible.
• Journaliser du clair : Ça paraît idiot jusqu’à ce qu’un log de « debug temporaire » soit expédié. Enveloppez votre surface HE dans une API minimale et verrouillez-la.
• Pas de discipline de batch : Packez les vecteurs de caractéristiques. Les slots vides sont de l’argent jeté par les fenêtres.

Votre plan sur 90 jours

Semaines 0–2 : choisissez une décision

• Choisissez un seul résultat scalaire : score de risque, éligibilité ou similarité.
• Définissez un budget de latence : p95 ≤ 5 s. Si vous avez besoin de la sous-seconde, ne commencez pas par HE.
• Figez un jeu de caractéristiques : 32–128 caractéristiques numériques est une bonne cible.

Semaines 2–6 : installez les garde-fous

• Mettez en place un microservice de scoring distinct avec une API minimale : encrypt(features) → ciphertext, score(ciphertext) → ciphertext, decrypt(ciphertext) → score.
• Prototypage dans SEAL ou OpenFHE avec CKKS. Validez par rapport à une base en clair dans votre tolérance.
• Expédiez un module de chiffrement client (mobile et/ou web) avec une conception de stockage des clés revue par la sécurité.
• Faites des benchs avec des charges réalistes : tailles de batch, latences p50/p95/p99, et saturation du débit.

Semaines 6–10 : prouvez que ce n’est pas du théâtre

• Éloignez les clés de la zone de calcul. Si les clés restent côté serveur, écrivez pourquoi et quelles mesures compensatoires existent.
• Ajoutez des SLO opérationnels : limites de taux, backpressure et modes de défaillance clairs.
• Faites un exercice sur table de brèche : supposez une exfiltration complète de la base des caractéristiques chiffrées ; vérifiez que vous pouvez soutenir « aucun clair n’a existé » de façon crédible.
• Impliquez le juridique et un client partenaire design. C’est un argument commercial ; utilisez-le.

Construire vs. acheter vs. nearshore

Deux vérités. D’abord, il n’y a pas beaucoup d’ingénieurs HE expérimentés disponibles dans la Bay Area, et ceux qui existent sont extrêmement chers. Ensuite, vous n’avez pas besoin d’un PhD pour livrer un pilote cadré, mais vous avez besoin d’ingénieurs qui pensent comme des cryptographes : discipline des paramètres, conscience des canaux auxiliaires et aisance avec des profils de performance atypiques.

L’approche pragmatique que nous voyons fonctionner : constituez un pod de 4–6 avec un ingénieur crypto appliquée senior, deux profils ML/DS, un plateforme/back-end et un SRE. Comptez 6–10 semaines pour atteindre un pilote de production si vous gardez le périmètre serré. Si vous manquez de profondeur crypto en interne, des partenaires nearshore avec des compétences en crypto appliquée et en Rust/C++ peuvent être productifs rapidement et vous offrir le chevauchement horaire dont vous avez besoin (Brazil vous donne 6–8 heures avec des équipes US) sans le choc tarifaire des talents rares onshore.

À quoi ressemble la réussite

La réussite, ce n’est pas « nous avons chiffré toute l’inférence ». La réussite, c’est pouvoir regarder votre board, votre plus grand prospect entreprise et un régulateur dans les yeux et dire : « Pour cette décision qui touche des PII sensibles, nos serveurs ne voient jamais le clair. En cas de compromission, l’attaquant récupère du chiffré. Voici notre SLO de latence, notre frontière de clés et nos éléments d’audit. »

C’est livrable en 2026. Et cela vaut de l’argent, du vrai.

À retenir

• HE est viable en production aujourd’hui pour des décisions étroites et scalaires sur des caractéristiques numériques ; ce n’est pas prêt pour du chat à faible latence ni des boucles d’agent complexes.
• Commencez avec CKKS pour de petits modèles linéaires/MLP ; gardez la profondeur de circuit et la non‑linéarité faibles.
• Budgétez une surcharge de 1 000× et concevez pour le batching ; célébrez toute victoire en dessous.
• Architectez pour une séparation des clés : des clés côté client ou partenaire changent votre posture légale.
• Combinez HE avec des enclaves pour des performances pratiques tout en minimisant la confiance.
• Mettez en place une surface de scoring séparée, prouvez la justesse vs. le clair, et faites un exercice de brèche sur table.
• Constituez un pod de 4–6 personnes ; un pilote focalisé est un effort de 6–10 semaines, pas une réécriture de plateforme.