En 1984, un homme a construit un piège que personne n’a jamais pu démonter complètement, même après qu’il en a détruit lui-même le code source. Ken Thompson, cocréateur d’Unix, venait de recevoir le prix Turing, la plus haute distinction en informatique. Dans son discours de réception, il n’a pas parlé d’Unix. Il a parlé d’un tour de passe-passe qu’il avait construit des années plus tôt, et qu’il jugeait assez important pour le révéler publiquement plutôt que de le laisser dormir.
Ce que Thompson a décrit ce jour-là n’était pas une faille technique. C’était une idée : et si, au lieu d’attaquer un programme, on attaquait la confiance qu’on lui accorde ? Cette bascule mérite qu’on s’y arrête, parce qu’elle a inauguré une catégorie d’attaque entièrement nouvelle, celle qui ne cible plus ce que le code dit, mais ce que le code est censé garantir.
Le tour de magie de 1984
Thompson a modifié le compilateur C d’Unix, le programme qui transforme le code source lisible par un humain en exécutable binaire que la machine comprend. Il lui a ajouté une règle simple : chaque fois que ce compilateur compilait la commande de connexion login, il glissait discrètement une porte dérobée permettant à Thompson de se connecter avec un mot de passe maître, sur n’importe quelle machine Unix.
Un audit du code source de login n’aurait rien trouvé, puisque ce code restait parfaitement propre. La porte dérobée n’existait nulle part dans les fichiers que les ingénieurs lisaient. Elle n’apparaissait qu’au moment de la compilation, injectée par le compilateur lui-même.
Le piège en deux étages
C’est là que l’idée de Thompson devient vraiment redoutable. Il a ajouté une seconde règle au compilateur : chaque fois que ce compilateur compilait son propre code source pour produire une nouvelle version de lui-même, il insérait automatiquement les deux règles malveillantes dans le nouveau binaire. La porte dérobée pour login, et la capacité de se reproduire.
Ensuite, Thompson a fait quelque chose de décisif : il a effacé toute trace de ces deux règles du code source du compilateur. Le fichier source, celui que n’importe quel ingénieur pouvait lire, auditer, comparer, ne contenait plus rien de suspect. Mais le compilateur binaire, celui déjà en circulation, restait infecté, et chaque nouvelle génération de compilateur qu’il produisait héritait du piège, indéfiniment, sans laisser la moindre trace lisible dans le code.
La conclusion de Thompson tient en une phrase qu’il a formulée lui-même dans son discours : on ne peut faire confiance qu’à du code qu’on a entièrement écrit soi-même. Autrement dit, si vous n’avez pas écrit votre compilateur, votre système d’exploitation et chaque outil qui les a construits, vous faites un acte de foi. Un acte de foi que personne, dans l’histoire de l’informatique moderne, n’a jamais pu totalement éviter.
Pourquoi c’est une innovation, pas un bug
Voilà ce qui distingue Trusting Trust de n’importe quelle faille de sécurité classique. Une faille se corrige : on trouve la ligne de code fautive, on la répare, le problème disparaît. Trusting Trust ne se corrige pas de cette façon, parce qu’il ne s’attaque pas à une ligne de code. Il s’attaque au principe même sur lequel repose l’audit de sécurité, à savoir que lire le code source suffit à savoir ce qu’un programme fait réellement.
C’est exactement le type de rupture que je documente (Mon livre, chapitre 3) : l’innovation la plus dangereuse, et la plus difficile à voir venir, n’est presque jamais une amélioration technique. C’est un déplacement du problème lui-même, un endroit où plus personne ne pensait à regarder. Thompson n’a pas inventé un virus plus intelligent. Il a déplacé l’endroit où l’attaque pouvait vivre, du code vers l’outil qui fabrique le code. Personne, avant lui, n’avait formulé aussi clairement ce niveau de vulnérabilité.
Ce livre s’adresse aux PDG, aux dirigeants et aux innovateurs prêts à tout remettre en question et à créer une croissance exponentielle.
La parade qui a mis vingt ans à arriver
Il a fallu attendre 2005 pour qu’une contre-mesure sérieuse soit publiée. L’informaticien David A. Wheeler a formalisé une technique appelée double compilation diversifiée, ou DDC (Diverse Double-Compiling). Le principe repose sur un constat simple : un attaquant ne peut pas raisonnablement corrompre tous les compilateurs existants à la fois.
La méthode fonctionne ainsi : on prend le code source propre du compilateur suspect, et on le compile avec un compilateur différent, jugé fiable. On obtient un premier binaire de confiance. On utilise ensuite ce binaire de confiance pour compiler une seconde fois le même code source. Si le résultat de cette seconde compilation est identique, bit pour bit, au binaire suspect d’origine, alors ce binaire ne contient aucune porte dérobée cachée. Si les résultats diffèrent, le binaire suspect dissimulait quelque chose.
Cette approche a nourri un mouvement plus large dans l’industrie du logiciel libre, celui des « reproducible builds », les compilations reproductibles : des équipes indépendantes compilent le même code source, dans des environnements différents, et vérifient qu’elles obtiennent exactement le même binaire. Des projets comme Debian ou Tor s’appuient sur ce principe pour renforcer la confiance dans leurs distributions.
Il faut néanmoins garder les pieds sur terre : ces techniques existent, elles sont documentées, elles sont utilisées par certains projets exigeants. Elles ne sont pas devenues la norme silencieuse de l’industrie du logiciel. La plupart des compilateurs que vous utilisez aujourd’hui n’ont jamais été soumis à une double compilation diversifiée par qui que ce soit. La solution existe sur le papier depuis vingt ans. Son adoption réelle reste une autre histoire.
2024, la même leçon avec un autre nom
En mars 2024, un ingénieur de Microsoft nommé Andres Freund a remarqué quelque chose d’anormal : les connexions SSH sur sa machine Debian prenaient un peu trop de temps de calcul. En creusant, il a découvert qu’une bibliothèque de compression extrêmement répandue, xz utils, présente dans la quasi-totalité des distributions Linux, avait été discrètement compromise.
Un contributeur du projet, actif depuis plusieurs années sous le pseudonyme « Jia Tan », avait patiemment gagné la confiance des mainteneurs historiques avant d’insérer un code malveillant, dissimulé dans les scripts de compilation plutôt que dans le code source lui-même. La faille, référencée CVE-2024-3094, aurait permis à un attaquant possédant une clé privée spécifique de prendre le contrôle à distance des machines infectées via SSH.
Ce n’est techniquement pas le même mécanisme que Trusting Trust. Thompson avait construit un binaire de compilateur auto-reproducteur. L’attaque xz utils est le fruit d’une ingénierie sociale patiente, des années à construire une réputation avant de la trahir. Mais la leçon de fond est identique : l’endroit où vous cherchez le danger, le code source lisible, n’est pas toujours l’endroit où le danger se cache. La confiance elle-même est la surface d’attaque.
La question qu’on n’a pas encore posée à l’IA
Voici où je m’arrête, honnêtement, parce que je n’ai pas de réponse toute faite, seulement une question qui me semble urgente. Des chercheurs du Georgia Institute of Technology suivent depuis 2025 ce qu’ils appellent le « Vibe Security Radar » : un décompte des failles de sécurité directement causées par du code généré par IA. Le nombre de failles répertoriées a été multiplié par près de six entre janvier et mars 2026 selon leurs relevés.
Ce chiffre concerne des vulnérabilités classiques, le genre d’erreur qu’un audit humain peut encore repérer. Mais la question que Thompson a posée en 1984 n’était pas « le code contient-il une erreur ? ». Elle était : « comment savoir si l’outil qui a produit ce code est lui-même digne de confiance ? »
Or les modèles d’IA écrivent aujourd’hui du code, relisent du code, et de plus en plus, participent à la construction d’autres outils logiciels, y compris d’autres modèles d’IA. Personne, à ma connaissance, n’a encore de méthode équivalente à la double compilation diversifiée pour vérifier qu’un modèle d’IA n’a pas appris, quelque part dans ses milliards de paramètres, un comportement caché qu’aucune lecture de son code d’entraînement ne permettrait de détecter. Je pose la question sans y répondre : si l’audit du code source ne suffisait déjà plus à garantir la confiance en 1984, sur quoi repose exactement notre confiance envers un système dont même les concepteurs ne peuvent pas lire ligne par ligne le raisonnement interne ?
Je n’ai pas de certitude sur ce point, et je me méfie de quiconque prétend en avoir une aujourd’hui. C’est précisément le genre de question que je pose dans mes travaux sur l’adoption de l’IA en entreprise (Mon livre, chapitre 14) : l’IA ne provoque pas seulement une nervosité liée à l’emploi. Elle réintroduit, à une échelle inédite, le problème exact que Thompson a formulé il y a quarante ans, celui de faire confiance à un système qu’aucun humain ne peut entièrement inspecter.
L’essentiel
Retenez trois choses :
- Trusting Trust n’était pas un bug, c’était un déplacement du terrain de jeu : de l’attaque du code vers l’attaque de la confiance dans l’outil qui produit le code.
- La double compilation diversifiée, formalisée par David A. Wheeler en 2005, offre une parade théorique solide, mais elle reste peu déployée en pratique à l’échelle de toute l’industrie.
- L’attaque xz utils de 2024 prouve que la leçon de 1984 reste vivante, sous une forme différente : l’ingénierie sociale patiente plutôt que le compilateur auto-reproducteur.
Le problème que Thompson a mis au jour en 1984 n’a jamais vraiment disparu. Il a changé de costume à chaque décennie, et rien n’indique qu’il s’arrêtera à celui de l’intelligence artificielle.
Références
- (Mon livre) https://philippeboulanger.com/fr/livre/
- (Communications of the ACM) doi.org/10.1145/358198.358210
- (arXiv, David A. Wheeler) arxiv.org/abs/1004.5548
- (Wikipedia, XZ Utils backdoor) en.wikipedia.org/wiki/XZ_Utils_backdoor
- (Wikipedia, Reproducible builds) en.wikipedia.org/wiki/Reproducible_builds
- (Georgia Tech SSLab, via InfoSecurity Magazine) scp.cc.gatech.edu
