Cette faille dans les puces NPU inquiète la cybersécurité
L’idée était séduisante : confier à une puce dédiée, intégrée directement au cœur du processeur, l’exécution locale des modèles d’intelligence artificielle. Plus de cloud, plus de données qui transitent vers des serveurs distants, plus de risque d’interception réseau. Les NPU (Neural Processing Units) devaient incarner une promesse de confidentialité par construction, en traitant tout localement, sur l’appareil lui-même. Des chercheurs de l’université d’État de Caroline du Nord viennent de démontrer que cette promesse est incomplète. Leur travail, baptisé GATEBLEED et présenté en octobre 2025 au congrès IEEE/ACM MICRO à Séoul, révèle qu’un mécanisme pourtant conçu pour économiser de l’énergie transforme chaque accélérateur IA intégré en une source potentielle de fuites d’informations. Pour les entreprises qui ont misé sur l’IA locale comme réponse à leurs obligations de confidentialité, l’alerte change la donne.
Quand l’optimisation énergétique devient une porte dérobée involontaire
Faille dans les NPU : alerte en cybersécurité. Pour comprendre la nature de la faille, il faut saisir un principe fondamental du fonctionnement des processeurs modernes : le « power gating ». Cette technique consiste à couper l’alimentation des composants inutilisés afin de réduire la consommation électrique. Quand un bloc de calcul reprend du service après une période de repos, il lui faut quelques cycles supplémentaires pour se « réveiller ». Ce délai de réveil, d’apparence anodine, constitue le cœur de la vulnérabilité.
L’équipe de Caroline du Nord a découvert que dans les Intel Advanced Matrix Extensions (AMX), l’accélérateur matriciel introduit dans les processeurs Xeon Scalable de 4e génération, ce délai varie en fonction des données traitées précédemment. Un attaquant qui peut exécuter ses propres instructions AMX en parallèle d’une victime sur le même matériel peut donc mesurer ces variations de temps et en déduire des informations sur ce que le modèle IA a calculé, et donc sur les données qui lui ont été soumises. Les chercheurs qualifient cette attaque de « canal caché par synchronisation » (timing side channel) : pas besoin d’accéder aux sorties du modèle ni aux scores de confiance, les seules mesures de temps suffisent.
Ce qui aggrave considérablement la portée de la découverte, c’est qu’Intel AMX est loin d’être un cas isolé. Les chercheurs précisent dans leur article que tout accélérateur de calcul géré par des mécanismes de mise en veille énergétique, des cœurs IA des laptops aux GPU dotés de tensor cores, présente potentiellement la même surface d’attaque. Autrement dit, l’architecture même qui rend les AI PC efficaces et silencieux les rend vulnérables à une catégorie d’attaques jusqu’alors négligée. Pour une entreprise dont les commerciaux utilisent un modèle local pour rédiger des offres ou analyser des données clients, la question de qui peut lire ces calculs en silence prend une toute autre dimension.
L’IA sur ordinateur, une surface d’attaque en expansion accélérée
Les implications pratiques de GATEBLEED dépassent le laboratoire parce que le déploiement des NPU dans le parc informatique mondial est devenu massif en l’espace de deux ans. Selon les projections de Gartner, les « AI PC » représentaient 31 % des ventes mondiales de PC à la fin 2025 et devraient atteindre 55 % en 2026. Concrètement, cela signifie que la majorité des ordinateurs achetés cette année sont équipés d’une puce NPU capable d’exécuter des modèles localement : 45 TOPS pour le Snapdragon X Elite de Qualcomm, 48 TOPS pour l’Intel Lunar Lake, 50 TOPS pour l’AMD Ryzen AI 300.
Ces chiffres s’expliquent notamment par la certification « Copilot+ » de Microsoft, qui impose un minimum de 40 TOPS d’inférence NPU pour les PC vendus sous ce label. Le marché a répondu à cette injonction : chez Intel, AMD et Qualcomm, toute la gamme principale embarque désormais un accélérateur IA. Les utilisateurs finaux, dans les entreprises comme dans les PME, manipulent donc un matériel doté de capacités d’inférence locale sans que les équipes de sécurité aient nécessairement pris la mesure de ce changement.
L’enjeu IoT et M2M n’est pas moins préoccupant. Les plateformes connectées déployées pour la gestion de flottes ou l’automatisation industrielle intègrent de plus en plus des accélérateurs IA embarqués pour traiter des données en temps réel, sans remontée vers le cloud. Ces dispositifs, conçus pour opérer dans des environnements isolés, héritent par construction des mêmes catégories de vulnérabilités matérielles. Pour les revendeurs de solutions IoT en marque blanche ou les opérateurs gérant des flottes de SIM embarquées, la couche matérielle représente désormais un périmètre de risque à part entière.
Le modèle local, nouvel angle mort du responsable de la sécurité
La vulnérabilité matérielle n’est que la face visible d’un problème plus profond. Un article de VentureBeat publié en avril 2026 décrivait avec une certaine acuité le nouveau « point aveugle » des RSSI (responsables de la sécurité des systèmes d’information) : les développeurs et les équipes techniques utilisent massivement des modèles de langage en local sur leurs postes, avec des outils comme Ollama ou llama.cpp, et cette utilisation est largement invisible aux outils de protection réseau traditionnels.
Les DLP réseau (Data Loss Prevention) et les CASB (Cloud Access Security Broker) surveillent les flux sortants vers des API cloud. Ils sont aveugles au moment où un collaborateur charge un fichier de 15 gigaoctets contenant un modèle de langage et l’interroge localement sur des contrats sensibles, des données de clients ou des documents stratégiques. Cette pratique, désignée par l’expression BYOM (Bring Your Own Model), est devenue courante sans que les politiques de sécurité l’aient anticipée. La faille GATEBLEED ajoute une dimension nouvelle à ce risque : là où l’on croyait que l’inférence locale protégeait les données en les maintenant hors des réseaux, un attaquant disposant d’un accès au même matériel peut reconstituer une partie de ce qui a été traité par le NPU, sans même avoir accès aux fichiers ou aux sorties du modèle.
Les chercheurs de Caroline du Nord ont d’ailleurs validé que leur attaque fonctionne même lorsque l’exécution IA est hébergée dans un environnement d’exécution de confiance Intel SGX, supposé étanche à ce type d’observation. Ce résultat est particulièrement préoccupant pour les secteurs qui ont investi dans des enclaves sécurisées comme réponse à leurs obligations réglementaires.
Ce que la démonstration scientifique établit concrètement
L’équipe de l’Université d’État de Caroline du Nord ne s’est pas limitée à décrire un vecteur théorique. Elle a conduit une attaque complète de bout en bout sur un modèle Transformer optimisé avec Intel AMX, obtenant une précision d’inférence de membre de 81 % et une précision de 0,89 sur les prédictions positives. Sur les modèles à mélange d’experts (Mixture of Experts, ou MoE), architecture utilisée notamment dans des modèles comme Mixtral ou les dernières générations de GPT, l’attaque parvient à identifier le choix d’expert avec une précision de 100 %.
La portée de ce résultat est considérable. Les MoE sont justement les architectures qui permettent de faire tourner des modèles puissants sur du matériel grand public, en n’activant qu’une fraction des paramètres à chaque inférence. Savoir quel expert a été sollicité revient à obtenir une information précieuse sur la nature de la requête soumise au modèle, et donc potentiellement sur les données d’entrée. Les chercheurs ont également recensé plus d’une dizaine de « gadgets » exploitables dans les bibliothèques les plus populaires, notamment HuggingFace, PyTorch et TensorFlow, c’est-à-dire les briques sur lesquelles repose l’essentiel du déploiement IA d’entreprise.
Une seconde recherche, distincte, publiée en mai 2025 sous le titre « I Know What You Said » sur arXiv, a montré de son côté qu’un attaquant peut reconstruire les mots traités par un LLM local en exploitant les canaux latéraux du cache mémoire du processeur, sans aucune instrumentation matérielle particulière. Ces deux recherches convergent vers une conclusion identique : l’inférence locale sur un matériel partagé ou insuffisamment isolé ne constitue pas, en soi, une protection des données.
NIS2, RGPD et EU AI Act : la conformité sous pression
Les implications réglementaires de ces découvertes sont immédiates pour les entreprises françaises et européennes. La directive NIS2, transposée dans le droit français depuis fin 2024, impose à son article 21 une gestion rigoureuse des vulnérabilités et des risques liés aux chaînes d’approvisionnement, y compris matérielles. Une organisation qui déploie des modèles IA sur des PC embarquant des NPU potentiellement vulnérables sans avoir évalué ce risque se place dans une situation délicate au regard de ces obligations.
Le RGPD est tout aussi concerné. Lorsqu’un collaborateur utilise un modèle local pour traiter des données à caractère personnel (enregistrements de clients, courriels, données RH), les données ne quittent pas le réseau mais elles transitent par un matériel potentiellement exposé à des canaux latéraux. L’article 32, qui impose des mesures techniques appropriées pour garantir la confidentialité des traitements, ne fait pas de distinction entre les risques réseau et les risques matériels. L’EU AI Act ajoute une couche supplémentaire pour les systèmes IA qualifiés de « haut risque » : les exigences de documentation et de traçabilité des données d’inférence deviennent difficiles à satisfaire si le périmètre de confidentialité du matériel n’est pas maîtrisé.
Ces textes, pris ensemble, tracent une ligne claire : la conformité ne peut plus s’arrêter à la couche logicielle ou réseau. Elle doit désormais descendre jusqu’au silicium.
Les mesures concrètes à déployer sans attendre
Face à cette nouvelle catégorie de menaces, les équipes de sécurité disposent d’un ensemble de réponses graduées. La première priorité est l’inventaire : recenser les postes équipés de NPU et d’accélérateurs IA dans le parc, identifier les bibliothèques installées (présence de fichiers .gguf, processus Ollama ou llama.cpp actifs, serveurs d’inférence locaux en écoute) et cartographier les usages réels, qui s’avèrent souvent très éloignés des politiques officielles.
La deuxième priorité est la supervision. Les plateformes EDR (Endpoint Detection and Response) et MDM (Mobile Device Management) permettent de détecter des pics inhabituels d’utilisation du NPU ou du GPU depuis des processus non référencés. La surveillance de cette activité, encore absente des tableaux de bord de la plupart des RSSI, doit être ajoutée aux règles de détection existantes.
La troisième priorité est l’isolation. Sur les postes traitant des données sensibles, les politiques de sécurité doivent interdire l’exécution de runtimes d’inférence non autorisés et limiter les bibliothèques IA à des versions auditées. Sur les flottes mobiles et les dispositifs IoT, la segmentation réseau et les règles de contrôle d’accès doivent être revues à l’aune de la menace matérielle. Un opérateur proposant des SIM ou des eSIM en marque blanche pour les objets connectés a tout intérêt à documenter les capacités d’inférence embarquées dans les terminaux et à inclure cette dimension dans ses engagements contractuels de sécurité, notamment dans les secteurs bancaire ou industriel.
Les chercheurs de Caroline du Nord ont proposé des mitigations, notamment une désactivation sélective du power gating sur les accélérateurs IA, mais cette mesure se fait au prix d’une dégradation de la performance et d’une consommation électrique accrue. L’arbitrage entre performance, efficacité énergétique et sécurité est au cœur de la nouvelle réalité du matériel IA : il appartient désormais aux entreprises de l’assumer explicitement, dans leurs politiques de sécurité comme dans leurs audits de conformité.
La promesse de l’IA locale reste fondée, mais elle impose une discipline nouvelle : celle de traiter le silicium comme ce qu’il est, à savoir un composant de la surface d’attaque, au même titre que le réseau ou le système d’exploitation.
