Le code est-il vraiment sûr quand la chaîne qui le produit ne l’est plus ?

De Ken Thompson à la crise de la confiance logicielle

En 1984, Ken Thompson reçoit le prix Turing et profite de son discours pour publier un texte devenu canonique en sécurité informatique : « Reflections on Trusting Trust », dans les Communications of the ACM. Son idée maîtresse est d’une brutalité conceptuelle absolue : on peut auditer un code source ligne par ligne, le certifier impeccable… et malgré tout exécuter un binaire compromis, sans qu’aucune trace de la compromission n’apparaisse dans le texte visible.

La clé du raisonnement est un déplacement fondamental de la menace : la compromission ne réside pas dans le code de l’application, mais dans l’outil qui traduit ce code le compilateur. Thompson montre comment un compilateur C modifié peut reconnaître de manière autonome certains motifs de code spécifiques (par exemple le source du programme UNIX login ou du compilateur lui-même), et y injecter à la volée une charge malveillante au moment exact de la compilation.

Le code source audité reste propre, mais le binaire émis par ce compilateur contient une backdoor qui accepte par exemple un mot de passe secret pour n’importe quel compte, ou insère des comportements cachés dans des composants critiques du système.

L’attaque devient réellement redoutable quand Thompson combine cette idée avec la nature auto-référente des compilateurs. Un compilateur étant lui-même compilé par un compilateur antérieur, il hérite structurellement des « connaissances » et des biais inscrits dans le binaire qui le produit. En insérant non pas une seule backdoor mais deux trojans l’un visant le programme login, l’autre visant le compilateur lui-même Thompson construit un scénario où, même si l’on repart d’un code source du compilateur parfaitement nettoyé, le binaire déjà compromis réinjecte automatiquement la charge malveillante dans la nouvelle version au moment de la recompilation.

Le résultat prend la forme d'un virus de chaîne de compilation persistant :

• Le code source du compilateur paraît sain et passe les audits de conformité.
• Le code source des programmes audités paraît rigoureusement sain.
• Chaque recompilation recrée pourtant un binaire porteur de la même backdoor, sans que l’inspection textuelle des sources ne permette jamais de remonter à l’origine du comportement.

La morale formulée par Thompson est aussi radicale que dérangeante : « You can’t trust code that you did not totally create yourself. » En pratique, construire soi-même l’ensemble de la pile technique compilateur, assembleur, microcode, système d'exploitation, bibliothèques depuis le silicium jusqu’aux applications applicatives est impossible pour la quasi-totalité des organisations modernes.

Cette attaque historique fait office de preuve par l’absurde : elle démontre qu’un système de confiance uniquement fondé sur la lecture du code source est structurellement insuffisant, dès lors qu’on accepte de déléguer la moindre partie de la chaîne logicielle à des outils tiers.

De la chaîne de compilation à la supply chain moderne

En 2026, l’écosystème ne se limite plus à quelques scripts et terminaux isolés : nous orchestrons des architectures empilées noyaux complexes, couches d’abstraction successives, grappes de dépendances open source, conteneurs éphémères, firmwares signés, pipelines CI/CD auto-déclenchés, et désormais des modèles d’IA capables d’écrire, corriger, optimiser et parfois déployer du code sans intervention humaine directe.

Chaque binaire "moderne" est le produit d’une chaîne industrielle où se mêlent générateurs de code, systèmes de build, gestionnaires de paquets, registres d’images et plateformes de déploiement, souvent opérés par des tiers et des outils que l’on ne maîtrise que partiellement. Les attaques d’envergure sur la supply chain logicielle de ces dernières années ont transformé la démonstration de Thompson en scénarios de crise systémique, avec des impacts nationaux et sectoriels.

• SolarWinds Orion (2020) : Des groupes de type APT ont compromis l’environnement de build de l’éditeur, insérant le malware SUNBURST dans les mises à jour d’Orion. Le code source applicatif visible chez les clients ne montrait aucune anomalie ; la charge malveillante était introduite dans la chaîne de build, signée avec les certificats de l’éditeur, puis distribuée comme une mise à jour parfaitement légitime à près de 18 000 organisations administrations, entreprises, infrastructures critiques. Autrement dit : ce n’est pas l’application métier qui ment, c’est le pipeline de confiance système de build, signature, distribution qui a été détourné pour transformer une mise à jour de routine en cheval de Troie global.
• XZ Utils (2024) : La compromission de cette bibliothèque de compression, utilisée dans de nombreuses distributions Linux, a révélé une attaque patiente et sophistiquée sur l’open source lui-même. Un contributeur malveillant a progressivement gagné la confiance du projet, avant d’introduire un code ambigu et obfusqué dans les scripts de build et des fichiers de test, de sorte que la backdoor ne se manifestait pleinement que dans certaines configurations de build (notamment celles aboutissant à un liblzma utilisé par sshd). Les tarballs de releases 5.6.0 et 5.6.1 ont ainsi transporté un mécanisme permettant, dans des conditions spécifiques, de bypasser l’authentification SSH et d’exécuter du code à distance, alors même que les revues de code GitHub sur les sources principaux ne révélaient rien d’évidemment suspect.

L’IA comme nouveau compilateur : du code visible au comportement émergent

C’est ici que les alertes des pères fondateurs du deep learning rejoignent frontalement la question de la confiance technique. Yoshua Bengio, Geoffrey Hinton et Yann LeCun, lauréats du prix Turing 2018 pour leurs contributions au deep learning, ne décrivent pas des scénarios de science-fiction, mais des trajectoires très concrètes de perte de contrôle sur des briques logicielles autonomes.

En 2024, Geoffrey Hinton reçoit avec John Hopfield le prix Nobel de physique pour des travaux sur les réseaux de neurones artificiels et les systèmes de mémoire associative, consacrant les réseaux de Hopfield et les architectures neuronales comme infrastructure scientifique des systèmes d’IA contemporains. Lors de ses interventions publiques récentes, Hinton insiste sur des vecteurs de menaces immédiats :

• L’industrialisation du phishing avancé : où des modèles génératifs produisent en masse des contenus hyper-personnalisés, difficiles à distinguer de messages authentiques.
• La surveillance de masse automatisée : avec des systèmes capables d’analyser en continu les flux vidéo, textuels et vocaux, au service d’États ou d’acteurs privés peu scrupuleux.
• L’apparition d'armes autonomes : et de systèmes plus intelligents que nous, capables de prendre seuls des décisions sur leurs cibles ou leurs stratégies de contournement, dans des contextes que nous ne maîtrisons plus.

En parallèle, Bengio et Hinton co-signent des travaux sur les risques extrêmes de l’IA avancée, où ils décrivent des modèles généralistes capables d’agir de manière autonome, de poursuivre des objectifs, d’exécuter des chaînes d’actions complexes, et de prendre en charge des tâches d’ingénierie logicielle que l’on considérait jusqu’ici comme réservées aux experts humains.

Leur inquiétude n’est pas simplement qu’un modèle écrive du "mauvais code", mais qu’il devienne un acteur décisionnel dans la chaîne de production logicielle : choisissant les patterns, les dépendances, les frameworks, les configurations d’infrastructure, avec un degré d’autonomie accru.

Autrement dit, l’IA n’est plus un simple assistant de productivité ou un outil de complétion de code. Elle s’impose comme un maillon décisionnel et comportemental de la chaîne logicielle. Hier, le compilateur classique modifiait silencieusement le binaire en appliquant une transformation déterministe sur un code source donné ; aujourd’hui, un agent autonome peut générer un système entier, introduire des dépendances tierces choisies sur la base de corrélations statistiques, réécrire des portions d’architecture, optimiser des déploiements et valider ses propres modifications dans un pipeline CI/CD.

Là où Thompson dénonçait un compilateur capable d’injecter une backdoor sans trace dans le texte, nous devons désormais considérer des agents capables de :

• Produire du code structurellement défaillant tout en le présentant comme optimisation ou refactorisation.
• Introduire des dépendances provenant d’écosystèmes partiellement compromis, simplement parce que ces paquets maximisent un score de "pertinence" appris sur des données.
• Valider leurs propres déploiements à travers des tests qu’ils contribuent eux-mêmes à générer, fermant la boucle de contrôle dans un circuit où l’humain ne touche plus directement ni le source, ni le binaire, ni l’infrastructure.

Pas seulement des backdoors : l’écosystème qui fabrique la confiance naïve

La faille majeure de l’industrie n’est pas uniquement l’action intentionnelle d’un groupe APT capable de placer une backdoor dans un compilateur ou une bibliothèque. Le danger vient aussi d’une culture de la facilité qui pousse à accorder une confiance réflexe à des mainteneurs isolés, à des labels "enterprise-ready", à des registres d’images et à des automatismes CI/CD dont plus personne ne lit vraiment les scripts.

Une compromission de confiance peut entrer par n’importe quel interstice :

• Un paquet npm ou une image Docker : ajoutés "par réflexe" parce qu’ils sont populaires ou bien référencés.
• Une mise à jour de firmware ou de microcode opaque : simplement acceptée parce qu’elle est signée par le constructeur.
• Un pipeline CI/CD dont on ne maîtrise plus l’orchestration : parce qu’il est géré par un tiers ou une plateforme SaaS.

Dans ce contexte, qualifier un système de "sûr" sur la base d’une promesse commerciale ou d’un slogan marketing n’a plus aucun sens.

De la sécurité déclarative à la sécurité démontrable

Pour casser cette opacité systémique, l’ingénierie moderne doit basculer vers des protocoles de traçabilité et de reproductibilité qui visent la chaîne, pas seulement le code source. Parmi les briques structurantes :

• Compilations reproductibles (Reproducible Builds) : garantir qu’un même source, recompilé avec un environnement et des outils précis, produit un binaire identique bit-à-bit ; cela permet de détecter des altérations invisibles insérées dans le pipeline de build ou dans les outils intermédiaires.
• SBOM (Software Bill of Materials) exhaustifs : maintenir une cartographie en temps réel de tous les composants, sous-composants, bibliothèques et dépendances d’une application, avec des attestations cryptographiques de provenance ; après XZ Utils et SolarWinds, ces SBOM deviennent un prérequis de toute démarche sérieuse de sécurité de la supply chain.
• Diverse Double-Compiling (DDC) : formalisée par David A. Wheeler pour contrer l’attaque de type "Trusting Trust", la méthode consiste à recompiler un compilateur suspect avec un compilateur de confiance issu d’une chaîne indépendante, puis à utiliser ce nouveau binaire pour recompiler à nouveau le code source ; si les exécutables finaux concordent, on dispose d’une preuve robuste que le compilateur n’insère pas de trojan caché.

L’objectif stratégique est simple et radical : remonter la chaîne jusqu’au binaire. Aucun système critique ne devrait être déployé sans que la correspondance exacte entre dépôt de code, chaîne de compilation isolée et exécutable de production soit validée par une procédure formelle.

Une autre posture face à l’IA

Intégrer l’IA dans les audits de sécurité offre des gains réels : analyse de grands volumes de code, détection de patterns connus, corrélation rapide d’indices faibles, génération de scénarios de test. Mais cela introduit aussi un biais de validation statistique qu’il faut traiter comme un risque en soi.

Un modèle génératif ne "raisonne" pas comme un moteur de preuves ; il produit du code qui maximise une distribution de probabilité sur des tokens, même lorsque ce code introduit :

• des erreurs de logique majeures,
• des constructions obsolètes,
• ou des patterns de vulnérabilités pourtant bien documentés.

Sa confiance apparente (commentaires assurés, réponses fermes, style syntaxique propre) est un artefact rhétorique, pas une garantie de sûreté. Traiter l’IA de manière sécurisée implique donc une rétrogradation consciente de son statut :

• la considérer comme un outil sous supervision,
• exiger que chaque proposition de code passe par des analyses statiques strictes (linters, analyse de flux, vérification formelle lorsque possible) ;
• intégrer des tests adversariaux indépendants, conçus par des équipes humaines ou par des frameworks spécialisés, pour chercher activement les comportements non souhaités.

Souveraineté numérique : au-delà du logo et de l’hébergement local

La souveraineté numérique ne se décrète pas à coup de drapeaux sur des datacenters ou de labels "cloud souverain" collés sur des brochures. Si les compilateurs, hyperviseurs, microcodes, bibliothèques critiques ou modèles de génération de code restent des boîtes noires extraterritoriales, la souveraineté affichée n’est qu’une illusion de surface.

Être souverain signifie en pratique :

• disposer de la capacité technique d’auditer ses compilateurs et chaînes de build,
• maîtriser ses dépendances profondes (langages, runtimes, bibliothèques système, firmware),
• isoler ses chaînes de fabrication logicielle, du dépôt au binaire en production,
• et refuser les modèles de confiance déclarative qu’ils viennent de grands fournisseurs de cloud, d’éditeurs de solutions "sécurité" ou de plateformes IA.

Les alertes convergentes de Thompson sur la chaîne de compilation, de Bengio sur les risques extrêmes de l’IA généraliste, et de Hinton sur la perte de contrôle potentielle de systèmes plus intelligents que nous dessinent une ligne de conduite claire :

Conclusion : reposer la question de la confiance

Quarante ans après Thompson, nous ne sommes plus dans une simple problématique de compilateur piégé, mais dans un univers de chaînes logicielles industrialisées où chaque maillon dépendance open source, pipeline CI/CD, firmware, modèle IA peut devenir un vecteur de compromission silencieuse.

Les crises SolarWinds et XZ Utils ont montré que des systèmes entiers pouvaient être trahis non pas par leur code métier, mais par la chaîne qui les construit, signe et distribue, tandis que les modèles avancés d’IA deviennent eux-mêmes des acteurs décisionnels de ces chaînes.

Dans ce paysage, continuer à qualifier un système de "safe" sur la base d’un logo, d’une marque ou d’un dépôt de code propre revient à ignorer la structure réelle du risque. La seule réponse cohérente est de basculer vers une sécurité démontrable : reproductible, auditable, vérifiable, souveraine sur ses outils de build comme sur ses agents IA.