Retour aux articles
29 JUILLET 2026

La cryptographie homomorphique, ou calculer sur des secrets qu'un LLM ne lira jamais

La cryptographie homomorphique, ou calculer sur des secrets qu'un LLM ne lira jamais
Intention utilisateur

Ce que vous allez apprendre

## Peut-on faire tourner un LLM sans qu'il lise vos données ? Oui, en principe — mais le coût reste prohibitif en 2026. La cryptographie homomorphique (FHE) permet de calculer sur des données chiffrées, sans jamais les déchiffrer. Pour un LLM complet, la latence est encore 10 000 à 60 000 fois supérieure au calcul en clair. En pratique : TEE pour le cloud sensible, anonymisation en amont pour le quotidien, FHE uniquement pour des briques étroites (classification, recherche vectorielle).

Envoyer un contrat en négociation, des dossiers RH ou des données de santé dans un modèle de langage tiers : l'objection revient dans chaque mission de conseil, toujours formulée de la même façon. « On ne peut pas envoyer *ça* dans un modèle tiers. » La cryptographie homomorphique promet de lever ce blocage en permettant de calculer sur des données sans jamais les déchiffrer — pas même pendant l'exécution. Selon dac.consulting, cette promesse est mathématiquement irréprochable, mais son application à un LLM complet reste, en 2026, plusieurs ordres de grandeur trop lente pour la production. Cet article distingue les trois régimes de confidentialité (chiffrement au repos, enclave TEE, FHE), explique pourquoi la FHE ressemble à de la magie sans en être, et donne la grille de décision concrète appliquée chez les clients : quand la FHE est un mirage marketing, quand un TEE suffit largement, et dans quel cas unique la FHE se justifie vraiment.

Deux millionnaires, un secret, aucune confiance

En 1982, l'informaticien Andrew Yao pose une énigme d'apparence anodine. Deux millionnaires veulent savoir lequel est le plus riche — sans révéler à l'autre le montant de sa fortune.

Le problème semble insoluble. Comparer deux nombres exige, croit-on, de les connaître. Yao démontre le contraire : il existe un protocole où chacun apprend qui gagne, et rien d'autre.

Ce résultat fonde une discipline entière, le calcul multipartite sécurisé. Il porte une intuition vertigineuse : on peut manipuler une information sans jamais la voir. C'est exactement la promesse que la cryptographie homomorphique fait aujourd'hui aux dirigeants qui redoutent de confier leurs secrets à un modèle de langage.

Le vrai blocage n'est pas technique, il est nominatif

Quand j'accompagne une ETI ou une PME sur l'IA générative, la première objection n'est presque jamais le coût ni la performance. C'est une phrase, toujours la même.

« On ne peut pas envoyer ça dans un modèle tiers. » Ça, ce sont les dossiers RH, les contrats en négociation, les données de santé, les plans industriels. La matière sensible de l'entreprise.

La réponse réflexe — « on héberge en local » — soulage la conscience sans toujours résoudre le problème. Elle confond trois régimes de confidentialité qu'il faut absolument distinguer avant d'aller plus loin.

Trois murs, trois menaces différentes

Le premier régime protège la donnée au repos et en transit. Disque chiffré, connexion TLS : la donnée est illisible tant qu'elle dort ou qu'elle voyage. Mais au moment du calcul, elle redevient claire dans la mémoire du serveur.

Le deuxième régime protège la donnée pendant l'exécution, via une enclave matérielle. C'est le confidential computing ou TEE (Trusted Execution Environment) : le code et les données tournent dans une bulle isolée du processeur, attestable, invisible même à l'administrateur de la machine.

Le troisième régime est le plus radical. La donnée reste chiffrée en permanence, y compris pendant le calcul, y compris dans la RAM. Le serveur ne voit jamais que du bruit. C'est la Fully Homomorphic Encryption, ou FHE.

Chacun répond à une peur distincte. Le chiffrement au repos couvre le vol de disque. Le TEE couvre un opérateur curieux ou une infrastructure partagée. La FHE couvre le cas extrême : je ne fais confiance à personne, ni au logiciel, ni au matériel, ni à l'exploitant.

Pourquoi calculer à l'aveugle n'est pas de la magie

L'idée de la FHE tient dans un mot : homomorphisme. Certaines opérations sur les données chiffrées correspondent exactement à des opérations sur les données claires.

Additionnez deux chiffrés, déchiffrez le résultat : vous obtenez la somme des deux clairs. Multipliez deux chiffrés : vous obtenez le produit. Or un réseau de neurones n'est, au fond, qu'une longue succession d'additions et de multiplications — un immense circuit arithmétique.

Si l'on sait additionner et multiplier des chiffrés, on sait donc, en principe, faire tourner un modèle sur des entrées qu'il ne lira jamais. Le client chiffre sa requête, le serveur calcule sur le bruit, renvoie un résultat chiffré, et seul le client détient la clé pour le lire.

Le protocole des millionnaires de Yao était le brouillon manuscrit de cette idée. La FHE en est la version industrialisée, mathématiquement pure : elle ne repose sur aucune confiance envers un tiers, seulement sur la difficulté d'un problème mathématique.

Le prix du secret : un budget de bruit qui s'épuise

Mais il y a un piège, et il porte un nom : le noise budget, le budget de bruit. Chaque chiffré FHE contient une petite quantité de bruit aléatoire, indispensable à la sécurité.

Chaque opération augmente ce bruit. Passé un seuil, le bruit noie le signal et le déchiffrement devient impossible. On doit alors exécuter une opération de bootstrapping — une remise à zéro du bruit — d'un coût faramineux.

Les chiffres donnent le vertige. Selon la synthèse publiée par Optalysys sur les compromis entre TEE et FHE, une addition entière chiffrée est environ 50 fois plus lente, une multiplication 500 fois, un réseau de neurones à dix couches près de 60 000 fois.

L'exemple le plus parlant : une inférence du modèle BERT tourne en 50 millisecondes dans une enclave TEE, contre environ 30 minutes en FHE. Un facteur d'à peu près 36 000. Le TEE, lui, n'ajoute qu'un surcoût de 2 à 15 % — quasi négligeable.

État de l'art mi-2026 : des briques, pas un chatbot

Alors, peut-on faire tourner un vrai LLM chiffré aujourd'hui ? Les travaux existent. Le papier EncryptedLLM, présenté à ICML 2025, fait tourner une passe avant de GPT-2 entièrement chiffrée, accélérée sur GPU.

Le gain par rapport à une implémentation CPU dépasse 200×. C'est remarquable. Mais on reste toujours à plusieurs ordres de grandeur au-dessus du calcul en clair, et GPT-2 est un modèle minuscule au regard des modèles actuels.

Les fonctions non linéaires — softmax, ReLU, normalisations — sont le cauchemar de la FHE, car elles gonflent la profondeur du circuit et donc le bruit. On doit les approximer par des polynômes, au prix de la précision.

La synthèse française d'Unite.ai sur le paysage du calcul confidentiel est nette sur ce point. Les promesses de « vitesse proche du clair » pour des LLM en FHE restent peu auditées, sans benchmarks indépendants. Méfiance de rigueur.

Ce qui marche vraiment, ce sont les briques étroites : classification chiffrée, recherche vectorielle chiffrée pour un RAG, embeddings privés. Comparer deux vecteurs sans les révéler — l'écho direct des millionnaires de Yao — est à portée de production sur de petits volumes.

La grille de décision que j'applique chez mes clients

Voici la règle que j'utilise en cadrage, et je la donne sans détour car elle relève de l'honnêteté due au client.

Cas 1 — la FHE est un mirage marketing. Un chatbot généraliste, un assistant de rédaction, un agent RAG conversationnel : oubliez la FHE de bout en bout. La latence la rend inutilisable et vous paierez une prouesse dont vous n'avez pas besoin.

Cas 2 — le TEE suffit largement. Vous voulez traiter des données sensibles sur une infrastructure cloud sans qu'un opérateur puisse les lire ? Le confidential computing attestable est la réponse pragmatique de 2026. Surcoût marginal, écosystème mûr, compatible avec des modèles réels.

Cas 3 — anonymisation en amont plus hébergement souverain. C'est, dans les faits, la voie que je recommande le plus souvent. Pseudonymiser les données avant l'envoi, héberger le modèle dans une juridiction maîtrisée, tracer les accès. Simple, robuste, auditable.

Cas 4 — la FHE se justifie. Uniquement quand vous ne pouvez absolument pas déchiffrer côté serveur, sur une brique étroite : une comparaison, une classification, une recherche vectorielle. Là, elle devient un outil légitime, pas une posture.

Cette discipline du bon outil pour le bon risque est le cœur de notre approche du conseil en IA : dire quand une technologie n'est pas la réponse vaut mieux que de la vendre.

Le paradoxe de l'auditabilité

Un dernier plateau de la balance, souvent oublié. Chiffrer la donnée pendant le calcul protège le secret — mais complique brutalement la traçabilité.

Si le serveur ne voit que du bruit, comment prouver qu'il a exécuté le bon calcul, sans erreur ni manipulation ? La question n'est pas rhétorique : Inria et d'autres travaillent précisément sur cette tension entre confidentialité et auditabilité.

Les preuves cryptographiques d'inférence — prouver qu'un modèle a bien produit tel résultat — restent aujourd'hui des milliers de fois plus lentes que l'inférence elle-même. Là encore, ce sont les petits modèles qui s'en approchent, pas les grands.

Il faut aussi rappeler que la FHE ne protège que la donnée en entrée et pendant le calcul. Elle ne défend en rien contre la manipulation du modèle lui-même — injection de prompt, exfiltration indirecte. C'est un chantier distinct, que j'ai abordé dans un guide sur les attaques contre les LLM.

Une famille de secrets, deux moments distincts

On confond souvent toutes ces technologies sous l'étiquette floue de « confidentialité ». Il faut les situer précisément dans le temps du cycle de vie d'un modèle.

La differential privacy et l'apprentissage fédéré protègent la phase d'entraînement — un sujet que j'ai relié aux cifristi de la Venise du XVe siècle. La FHE, le TEE et le calcul multipartite protègent, eux, la phase d'inférence, celle de la requête au quotidien.

Ce déplacement change tout. La peur du dirigeant ne porte pas sur des données d'entraînement passées, mais sur le contrat qu'il tapera dans un modèle demain matin. C'est bien l'inférence qu'il faut sécuriser.

Ce que je dirais à un dîner de famille

Revenons aux deux millionnaires de Yao. Leur protocole prouvait qu'on peut trancher une question sans dévoiler ses données — mais il ne comparait qu'un seul nombre.

La cryptographie homomorphique promet d'étendre ce miracle à un réseau de neurones entier. Le principe est solide, mathématiquement irréprochable, et bien réel. Ce n'est pas de la magie : c'est de l'arithmétique sur du bruit.

Mais faire tourner un LLM complet à l'aveugle coûte encore, en 2026, plusieurs ordres de grandeur de trop. La bonne réponse pour une entreprise n'est presque jamais la plus spectaculaire — c'est un TEE, une anonymisation soignée, un hébergement maîtrisé, et la FHE réservée aux quelques briques où l'on ne peut vraiment faire confiance à personne. Calculer sans voir existe. Calculer sans voir un LLM entier, en production, à coût raisonnable : pas pour demain, mais pas pour jamais.

Tableau de synthèse

SectionMessages clés
Le détour (Yao, 1982)Le protocole des millionnaires prouve qu'on peut comparer deux fortunes sans les révéler — ancêtre du calcul sur données chiffrées.
Trois régimes de confidentialitéAu repos/en transit (vol de disque), TEE pendant l'exécution (opérateur curieux), FHE en permanence même en RAM (confiance zéro).
Comment fonctionne la FHEAddition et multiplication sur les chiffrés correspondent aux opérations sur les clairs ; un réseau de neurones est un circuit arithmétique.
Le coût (noise budget)Facteur 100 à 60 000× de ralentissement ; BERT : 50 ms en TEE contre ~30 min en FHE ; TEE n'ajoute que 2-15 %.
État de l'art mi-2026LLM complet chiffré = prototype avancé (EncryptedLLM/GPT-2). Ce qui marche : classification, recherche vectorielle, embeddings chiffrés.
Grille de décision DACChatbot = mirage FHE ; cloud sensible = TEE ; cas courant = anonymisation + souverain ; FHE seulement si aucun déchiffrement serveur possible.
AuditabilitéChiffrer complique la preuve du bon calcul ; preuves d'inférence encore milliers de fois trop lentes ; FHE ne protège pas contre l'injection de prompt.