Google ouvre HEIR, le compilateur qui exécute l’inférence IA sur des données chiffrées

2023. Google annonce son intention d’élargir son offre de chiffrement homomorphe. 14 août 2026. Le billet de Jeremy Kun sur blog.google présente HEIR comme « le dernier outil puissant ajouté à notre Private Computing Toolkit ». Le même billet publie quatre applications d’inférence privée compilées avec HEIR, code source sur GitHub.

Le message tient en une phrase : exécuter un modèle sur des données chiffrées n’est plus une affaire d’équipe de cryptographes, c’est devenu un problème de compilateur. C’est exactement ce que HEIR — pour Homomorphic Encryption Intermediate Representation — prétend résoudre, et ce que Google démontre désormais avec des cas d’usage concrets.

Ce que HEIR change : le chiffrement homomorphe devient un problème de compilateur

Le chiffrement homomorphe (FHE) permet de calculer directement sur des ciphertexts : le serveur traite des données chiffrées et renvoie un résultat chiffré, sans jamais voir l’entrée en clair. La garantie est purement cryptographique — contrairement aux enclaves matérielles (TEE) dont la sécurité repose sur la confiance dans un fabricant de silicium, le FHE ne fait confiance à aucun matériel.

Le blocage historique n’était pas la cryptographie, mais l’ingénierie. Convertir un programme existant pour qu’il tourne en homomorphe exigeait, selon les termes de Google, « une équipe de cryptographes » : choix du schéma (BFV, BGV, CKKS…), gestion du bruit qui s’accumule à chaque opération, réglage des paramètres (degré du polynôme, module), et génération de code vers une bibliothèque. Chaque étape est un métier.

HEIR absorbe cette chaîne. Bâti sur MLIR, l’infrastructure de compilateurs modulaire issue du monde LLVM, HEIR décrit l’inférence comme une représentation intermédiaire que des passes transforment pour la rendre exécutable sur des backends comme OpenFHE ou Lattigo. Le développeur n’écrit plus la cryptographie : il annote quels arguments sont secrets, et le compilateur s’occupe du choix de schéma et de la génération de code. C’est le même mouvement qui a fait du GPU un problème de compilateur vingt ans plus tôt : on déplace la complexité du développeur vers l’outillage.

La trajectoire est longue, et Google le rappelle. L’intention remonte à 2023 ; depuis, l’éditeur a noué des partenariats avec des fabricants d’accélérateurs matériels dédiés au FHE — Belfort, Niobium, Cornami, Optalysys — et HEIR a servi de plateforme à quatre publications relues par les pairs, avec des collaborations académiques à Georgia Tech, Carnegie Mellon, UC Santa Barbara, Purdue, Édimbourg et Tsinghua. Le projet a mûri hors de la lumière avant d’être montré.

Quatre démos : ce qui tourne déjà en chiffré

Le billet de Google ne se contente pas de promettre : il publie quatre applications compilées avec HEIR, chacune avec ses latences sur un CPU mono-thread, et le code source dans le dépôt google/fully-homomorphic-encryption.

• Recommandation de contenu. Un Deep Learning Recommendation Model sert des recommandations privées — la démo exacte évoquée plus haut, où le fournisseur recommande sans jamais voir les caractéristiques de l’utilisateur. Travail conjoint avec Belfort Labs, LG et NYU.
• Détection de fraude bancaire. Un détecteur de fraude à la carte bancaire compilé avec Niobium et hardshell.ai, qui classe une transaction sans que le serveur ne lise ses attributs.
• Détection d’intrusion. Le système Kitsune d’analyse d’anomalies sur du trafic réseau, compilé pour détecter des anomalies sur des paquets chiffrés — le fournisseur voit une alerte, jamais le contenu des flux.
• Détection de mot-clé. Un hotword detector compilé avec Belfort Labs, qui permettrait à un agent déclenché à la voix de reconnaître un mot d’activation sans exposer l’enregistrement audio.

Le point commun des quatre cas est instructif : ce sont tous des modèles structurés et étroits — un recommendeur, un classifieur, un détecteur d’anomalie — pas des transformeurs à 27 milliards de paramètres. Le FHE d’aujourd’hui ne chiffre pas un LLM ; il chiffre la couche de triage autour du LLM.

# Le compilateur et les exemples officiels, tous deux sur GitHub
git clone https://github.com/google/heir
git clone https://github.com/google/fully-homomorphic-encryption

Pourquoi ça ne remplace ni le TEE ni le LLM en clair

Il faut lire l’annonce sans survente, car le billet lui-même pose les bornes. Le FHE a « un surcoût non trivial » : l’inférence chiffrée reste plusieurs ordres de grandeur plus lente que l’inférence en clair, et les chiffres publiés le sont sur un seul thread CPU, la configuration la plus lente possible, en attendant de démontrer le gain des accélérateurs.

La comparaison avec les enclaves est elle aussi nuancée. Un TEE offre de bonnes performances mais sa sécurité est matérielle — elle dépend d’un fabricant et a déjà été contournée. Le FHE offre une garantie mathématique mais à un coût de performance prohibitif pour beaucoup de workloads. Les deux techniques ne sont pas concurrentes : elles se positionnent sur des segments différents du même spectre de confidentialité.

Et il y a l’angle d’attaque que ce type d’outillage ouvre. Le FHE promet de traiter des données sans les voir — ce qui, pour un RSSI, veut dire que la donnée ne quitte plus le périmètre en clair. C’est précisément la réponse au risque que le shadow AI a rendu visible en 2026 : des employés qui collent des données sensibles dans des modèles SaaS sans autorisation, comme documenté ici cet été. Le FHE ne supprime pas le problème de gouvernance — il offre une voie où l’inférence et la confidentialité cessent d’être un arbitrage.

Un enjeu de conformité avant d’être un enjeu de performance

Pour les équipes qui traitent des données de santé ou financières, le FHE répond d’abord à une question réglementaire : comment exécuter une inférence utile sans que la donnée ne change de mains ? Le RGPD, les réglementations sectorielles et les clauses de souveraineté imposent souvent que certaines données ne quittent jamais le périmètre de l’organisation — ce qui exclut de fait leur envoi vers un modèle SaaS externe.

C’est là que HEIR change la nature du problème. Jusqu’ici, l’alternative était binaire : traiter en local (et renoncer à la puissance d’un modèle servi dans le cloud) ou anonymiser (et perdre en précision). Le FHE ouvre une troisième voie : la donnée reste chiffrée de bout en bout, le modèle tourne où vous voulez, et seul le détenteur de la clé peut lire le résultat.

La garantie est aussi plus forte que celle des enclaves sur un point précis : elle ne dépend d’aucun fabricant de matériel. Pour un RSSI qui doit justifier ses choix devant une autorité de contrôle, « la sécurité est mathématique, pas contractuelle » est un argument qui pèse — à condition d’en accepter le prix en latence.

Le vrai verrou : la latence, pas la cryptographie

La conclusion opérationnelle tient en une question : quel est le coût d’une garantie mathématique de confidentialité sur vos modèles de triage ? La réponse dépend entièrement du workload.

Pour un classifieur de fraude ou un recommendeur, la latence en homomorphe se compte encore en secondes là où le clair se compte en millisecondes — inacceptable pour du temps réel, tolérable pour du traitement par lots ou du pré-filtrage. Pour un LLM, la question ne se pose même pas : le volume de calcul rend le FHE inenvisageable à court terme.

C’est pourtant la bonne nouvelle que Google veut faire passer : le coût du FHE décroît rapidement, et il a été transformé en problème d’ingénierie — donc industrialisable, optimisable par les accélérateurs matériels déjà en partenariat, et mesurable. Un problème que l’on peut compiler est un problème dont on peut tracer la courbe de coût.

Verdict

Si vous opérez dans un secteur réglementé — santé, finance, données souveraines — qui ne peut aujourd’hui pas du tout envoyer certaines données à un modèle, HEIR lève un verrou réel : l’inférence sur données chiffrées cesse d’exiger une équipe de cryptographes. Suivez le projet, et testez les démos officielles pour jauger la latence sur vos propres données.

Si votre besoin est un LLM ou du temps réel, ne fondez rien sur le FHE aujourd’hui : la latence reste rédhibitoire. Votre confidentialité passe par d’autres briques — enclaves, rétention maîtrisée, self-hosting — que HEIR ne remplace pas.

Le signal de fond est que la confidentialité de l’inférence devient un problème de compilateur plutôt que de cryptographie. C’est le signe qu’une technologie de niche se prépare à une industrialisation — et c’est maintenant qu’il faut en cartographier les cas d’usage, pas quand les accélérateurs auront fait tomber la latence.

Références

• Google — How Google is Making Private AI Practical with Homomorphic Encryption, Jeremy Kun, 14 août 2026
• HEIR — Homomorphic Encryption Intermediate Representation
• GitHub — google/heir : A compiler for homomorphic encryption
• GitHub — google/fully-homomorphic-encryption
• arXiv — HEIR: A Universal Compiler for Homomorphic Encryption