La Boîte Noire Matérielle

ÉTUDE STRUCTURELLE · OPÉRATION DINDON · JUIN 2026

◆◆◆

LA BOÎTE NOIRE
MATÉRIELLE
Intel Management Engine · AMD Platform Security Processor
Le Lock-In au Niveau du Silicium

◆

◆ LA THÈSE

L'organisation qui pense s'être affranchie du cloud en achetant du bare-metal mais qui tourne sur du silicium Intel ou AMD avec des firmwares propriétaires non auditables a résolu un problème de dépendance logicielle pour tomber dans un problème de dépendance matérielle potentiellement plus profond. Le lock-in hyperscaler est au niveau logiciel. Le lock-in matériel est au niveau du silicium. Cette étude documente la deuxième dimension de la couche matérielle : les processeurs cachés dans chaque serveur, leur nature, et ce qu'ils signifient pour la souveraineté.

◆◆◆

INTEL ME

Depuis
2008

AMD PSP

Depuis
2013

WATERMARK

RATIO

Amine RAITI — Architecte Infrastructure & SRE
Ancien professeur en école d'ingénieurs · Formateur depuis 2006
Document public · CC BY-NC-SA 4.0 · Opération Dindon · Juin 2026

SECTION 1 · L'INTEL MANAGEMENT ENGINE — LE DEUXIÈME ORDINATEUR DANS LE SERVEUR

CHAQUE PROCESSEUR INTEL CONTIENT UN ORDINATEUR INDÉPENDANT QUE LINUX NE CONTRÔLE PAS

◆

Depuis 2008, chaque processeur Intel intègre un sous-système appelé Intel Management Engine (IME). Ce n'est pas une fonctionnalité optionnelle. Ce n'est pas un composant externe. C'est un processeur secondaire gravé dans le die du CPU principal, avec son propre firmware, son propre système d'exploitation (MINIX 3), et ses propres accès à la mémoire, au réseau et au stockage.

◆ CE QUE L'INTEL MANAGEMENT ENGINE FAIT

L'IME a été conçu pour la gestion à distance des serveurs d'entreprise — permettre à un administrateur système de redémarrer, reconfigurer ou diagnostiquer un serveur sans être physiquement présent. Cette fonctionnalité est légitime et utile. Ce qui est problématique, c'est son architecture :

Il s'exécute indépendamment de l'OS : Linux, Windows, BSD — aucun système d'exploitation ne contrôle l'IME. Il tourne en dessous du niveau kernel. Il est invisible aux outils d'audit standard.

Il fonctionne quand le serveur est "éteint" : tant que le serveur est alimenté (même en veille profonde), l'IME est actif. Il peut recevoir des instructions réseau et les exécuter sans que l'OS principal soit démarré.

Il a un accès réseau indépendant : l'IME peut communiquer sur le réseau via des canaux distincts de ceux utilisés par l'OS. Sur certaines cartes mères, il dispose de son propre port réseau dédié.

Son firmware est propriétaire : Intel ne publie pas le code source du firmware de l'IME. Il ne peut pas être audité, ni remplacé facilement. Des tentatives de désactivation partielle existent (me_cleaner) mais elles ne sont pas garanties complètes.

◆ L'AMD PLATFORM SECURITY PROCESSOR — LE MÊME PROBLÈME CÔTÉ AMD

Depuis 2013, les processeurs AMD intègrent le Platform Security Processor (PSP) — également appelé AMD Secure Technology. Il est basé sur une architecture ARM Cortex-A5, dispose d'un firmware propriétaire, et a des fonctions similaires à l'IME : exécution avant le démarrage de l'OS, accès à la mémoire, gestion de la sécurité au niveau hardware.

AMD a publié davantage de spécifications techniques que Intel sur ce composant, mais le firmware reste propriétaire et non auditable dans son intégralité. La communauté coreboot travaille sur des implémentations alternatives mais la couverture est partielle.

SECTION 2 · CE QUE LA BOÎTE NOIRE MATÉRIELLE SIGNIFIE POUR LA SOUVERAINETÉ

ACHETER DU BARE-METAL SANS MAÎTRISER L'IME/PSP — C'EST DÉPLACER LE LOCK-IN

◆

◆ LA CHAÎNE DE JURIDICTION DU FIRMWARE

Le firmware de l'Intel IME est développé et distribué par Intel Corporation, dont le siège est à Santa Clara, Californie. Les mises à jour de firmware sont signées cryptographiquement par Intel. Elles sont distribuées via les canaux de mise à jour du fabricant de la carte mère (Dell, HP, Lenovo, Supermicro) qui les incorpore dans ses propres mises à jour BIOS/UEFI.

Ce firmware est soumis au droit américain. Il est soumis aux National Security Letters. Il est soumis au CLOUD Act dans sa dimension de contrôle des systèmes d'information. Une organisation qui fait tourner ses données sensibles sur des serveurs Intel en croyant s'être affranchie du cloud américain fait en réalité tourner ces données sur un firmware américain non auditable.

Ce n'est pas une spéculation. C'est la conséquence logique de l'architecture IME et du droit américain tel que documenté dans CGV sous Microscope.

◆ CE QUE LE SRE NE PEUT PAS FAIRE AVEC L'IME

Un administrateur Linux expérimenté a accès à tout : kernel, drivers, logs, métriques hardware, appels système. Il peut auditer pratiquement n'importe quelle couche du système. L'IME est l'exception — la couche qui échappe à son autorité technique.

Il ne peut pas lire les logs de l'IME sans outils spéciaux (et partiels).
Il ne peut pas inspecter le trafic réseau de l'IME avec tcpdump — l'IME opère en dessous de l'interface réseau.
Il ne peut pas désactiver l'IME sans risquer de déstabiliser le serveur (certaines fonctions BIOS dépendent de l'IME).
Il ne peut pas vérifier l'intégrité du firmware IME avec les outils standard d'audit.

La Primauté Technique documentée dans le corpus s'arrête à la surface de l'IME. En dessous : terra incognita propriétaire.

◆ LES RÉPONSES PARTIELLES QUI EXISTENT

Coreboot : firmware open-source alternatif pour le BIOS/UEFI, supporté sur un nombre limité de cartes mères (principalement Chromebook, certains Lenovo ThinkPad, quelques serveurs). Il peut réduire la surface d'exposition de l'IME sans l'éliminer complètement.

me_cleaner : outil qui tente de neutraliser les modules non essentiels de l'IME. Résultats partiels, risques de déstabilisation, non supporté officiellement.

RISC-V + processeurs open : l'horizon à 10-15 ans. Des processeurs RISC-V sans IME existent mais ne sont pas encore disponibles en version datacenter haute performance.

IBM POWER + OpenPOWER : alternative existante avec un niveau d'auditabilité supérieur aux processeurs x86. Coût et écosystème logiciel différents.

SECTION 3 · LES TROIS COUCHES DU LOCK-IN — SYNTHÈSE COMPLÈTE

CONTRACTUEL · LOGICIEL · MATÉRIEL — LA DÉPENDANCE TOTALE CARTOGRAPHIÉE

◆

COUCHE 1 — CONTRACTUELLE

Ce qu'elle est : juridiction californienne (GCP §14.12), commits noncancellable, egress fees, modification unilatérale des tarifs, accès gouvernemental possible (CLOUD Act).
Comment en sortir : changer de fournisseur, renégocier les contrats, choisir un infogéreur souverain. Difficile mais possible — documenté dans L'Exodus Accompagné.
Étude corpus : CGV sous Microscope.

COUCHE 2 — LOGICIELLE

Ce qu'elle est : dialectes propriétaires (DynamoDB, BigQuery, Lambda), certifications propriétaires, novlangue qui détruit les compétences neutres, code applicatif qui parle le langage du fournisseur.
Comment en sortir : Interface Souveraine (Anti-Corruption Layer), migration progressive (Sortie Douce), reconstruction des compétences neutres (Socle du Fer). Lent mais faisable — documenté dans le corpus.
Études corpus : Interface Souveraine · La Novlangue qui Coûte Cher.

COUCHE 3 — MATÉRIELLE

Ce qu'elle est : dépendance à TSMC/ASML pour les nouveaux serveurs GPU (Le Goulot de Taïwan), firmware propriétaire Intel ME / AMD PSP non auditable (La Boîte Noire Matérielle), valeur stratégique du matériel existant en cas de crise d'approvisionnement (Le Refurbished Stratégique).
Comment en sortir : posséder son fer existant (horizon immédiat), coreboot/me_cleaner (horizon partiel, complexe), RISC-V + fonderies souveraines (horizon 10-15 ans). Pas de solution simple aujourd'hui.
Études corpus : Le Fer Numérique · Le Goulot de Taïwan · La Boîte Noire Matérielle · Le Refurbished Stratégique.

◆◆◆

La couche contractuelle est visible — elle est dans les CGV.
La couche logicielle est visible — elle est dans le code.
La couche matérielle est invisible — elle est dans le silicium.

Le corpus Opération Dindon a documenté les trois.
La troisième couche est la seule que les CGV ne mentionnent pas.
Elle existe quand même.

◆◆◆

NEMO SUPRA LEGEM EST