En informatique, une plaisanterie court depuis longtemps : DOOM finira par tourner sur tout. Non pas comme un compliment adressé au jeu, mais comme un défi. On a déjà fait tourner le FPS de 1993 sur des distributeurs de billets, des imprimantes, des tests de grossesse, des calculatrices, une seule brique LEGO et la Touch Bar d’un MacBook.
En janvier 2025, un lycéen a ajouté une entrée à la liste. Il a fait tourner DOOM à l’intérieur d’un fichier PDF.
En bref
Un lycéen a compilé DOOM en asm.js avec une version d’Emscripten datant de 2020, puis l’a fait tourner dans un PDF en utilisant un champ de formulaire par ligne d’écran : 320×200, six nuances de gris, environ 80 millisecondes par image. Aucune faille n’est en cause. Chaque fonction utilisée est un élément documenté de la spécification PDF, qui fait exactement ce pour quoi elle a été prévue. C’est là tout l’intérêt — et la raison d’accorder dix minutes, une fois, à la question.
C’est un très beau travail et une excellente blague. C’est aussi la démonstration la plus claire de ce que ce site répète, et que l’on a toutes les raisons de trouver difficile à croire : un PDF n’est pas la photo d’une page. C’est un conteneur capable d’exécuter du code.
Comment cela fonctionne réellement
Le projet s’appelle doompdf, signé par un développeur qui se fait appeler ading2210. Le mécanisme est plus intéressant que l’exploit, et il tient en quatre points.
Le PDF prend en charge JavaScript. Pas comme extension ni comme greffon : c’est une partie du format, dotée de sa propre bibliothèque standard, que les navigateurs implémentent dans leurs moteurs PDF intégrés. Elle existe pour que les formulaires vérifient ce qu’on y saisit et que les documents interactifs réagissent aux clics. Personne ne l’a ajoutée pour les jeux.
Le code source de DOOM est public — mais l’histoire est plus précise que le raccourci ne le laisse croire. id Software a publié le code le 23 décembre 1997, sous une licence n’autorisant qu’un usage éducatif, et il s’agissait du code du portage Linux, pas de l’original DOS, à cause de la licence distincte de la bibliothèque sonore DMX. Le passage à la GPL n’est intervenu que près de deux ans plus tard, le 3 octobre 1999. C’est cette seconde date qui compte : elle a transformé DOOM en quelque chose qu’on pouvait non seulement lire, mais légalement reconstruire. D’où ses réapparitions dans des endroits improbables.
Un compilateur délibérément obsolète a fait le pont. ading2210 a utilisé Emscripten 1.39.20 — une version de 2020 — parce qu’elle produit de l’asm.js et non du WebAssembly. Emscripten moderne génère du WebAssembly, et un PDF n’a pas d’environnement d’exécution WebAssembly. asm.js est un dialecte restreint de JavaScript ordinaire : il tourne donc partout où JavaScript tourne. Reprendre l’ancienne chaîne d’outils n’était pas de la nostalgie, c’était la seule porte d’entrée.
Reste l’affichage, la partie qui fait rire aux éclats. Un PDF n’a ni canevas, ni tampon d’image, rien sur quoi peindre des pixels. Ce qu’il a, ce sont des champs de formulaire. La sortie 320×200 du jeu est donc rendue en caractères ASCII — un champ de texte par ligne d’écran, en six nuances de gris — et rafraîchie aussi vite que ce texte peut être réécrit, soit environ 80 millisecondes par image. Les commandes passent par le même chemin : des champs et des boutons que le moteur PDF sait déjà gérer. On joue à DOOM, littéralement, dans un formulaire à remplir.
C’est lent. C’est monochrome. C’est parfaitement jouable, publié sous GPL v2 comme le code dont il dérive, et on peut l’essayer soi-même dans un navigateur fondé sur Chromium. La version compilée permet même d’y glisser son propre fichier WAD.
Puis il y a fait démarrer Linux
Quelques semaines plus tard, le même développeur publiait linuxpdf : un noyau Linux complet démarrant à l’intérieur d’un fichier PDF, en compilant l’émulateur RISC-V TinyEMU avec la même astuce asm.js. Le noyau met 30 à 60 secondes à démarrer — l’auteur parle de plus de cent fois plus lent que du matériel réel — et se pilote au moyen d’un clavier virtuel fait de boutons PDF.
DOOM dans un document, c’est une blague. Un processeur émulé qui démarre un système d’exploitation dans un document, c’est un argument. Quelque part entre les deux, il ne s’agit plus de DOOM.
La partie qui ne fait pas rire
Voici l’idée sur laquelle il vaut la peine de s’arrêter. Rien dans doompdf n’est un exploit. Aucune vulnérabilité n’a été trouvée, rien n’a été cassé, aucune faille de sécurité n’est en cause. Chacun des éléments utilisés est une fonctionnalité documentée et voulue de la spécification PDF, qui fonctionne exactement comme prévu.
Ce qui signifie que la capacité permettant à un PDF de faire tourner un FPS de 1993 se trouve aussi dans la facture que vous ouvrirez demain. Elle ne rôde pas, elle n’est pas cachée : elle est simplement là, inutilisée, parce que la plupart des documents n’ont aucune raison de s’en servir.
C’est la version honnête de l’histoire, et elle coupe des deux côtés. Le raisonnement qui dit « un document peut exécuter du code, donc prudence » doit aussi admettre à quel point le monde de ce code est étroit.
Ce qu’un script dans un PDF peut et ne peut pas faire
C’est là que la plupart des articles sur doompdf deviennent vagues, alors soyons précis. La réponse dépend entièrement de ce avec quoi vous avez ouvert le fichier — et les deux cas courants diffèrent beaucoup.
| Capacité | Visionneuse du navigateur (Chrome, Edge, Firefox) | Adobe Acrobat Reader |
|---|---|---|
| Exécuter un script à l’ouverture | Oui | Oui, sauf si c’est désactivé |
| Lire et écrire les champs de formulaire | Oui | Oui |
| Lire vos cookies ou le stockage du navigateur | Non | Sans objet |
| Atteindre la page HTML environnante (le DOM) | Non | Sans objet |
| Émettre des requêtes réseau | Très limité | Plus large — c’est là qu’ont vécu les pixels espions et les fuites NTLM |
| Toucher aux fichiers locaux | Non | Restreint, mais avec une API bien plus vaste |
| Lancer des programmes externes ou des pièces jointes | Non | Sur confirmation — historiquement la voie des documents malveillants |
Lisez ce tableau dans le bon sens. Dans un navigateur, un PDF scripté tourne dans une petite boîte sans intérêt : pas de cookies, pas de stockage, aucun accès à la page qui l’entoure. C’est précisément pour cela que doompdf est une curiosité et non un incident, et que « DOOM tourne dans un PDF » n’est pas une raison d’avoir peur des PDF.
La colonne intéressante est celle du lecteur de bureau. Il dispose de l’API JavaScript complète décrite par la spécification, parce qu’il est fait pour traiter de vrais documents d’entreprise. C’est l’environnement où l’on peut demander à un document de signaler son ouverture, de se comporter différemment selon le lecteur, ou de proposer d’ouvrir quelque chose qu’il transportait.
Trois choses restent donc vraies quel que soit le logiciel, et ce sont celles qu’il faut retenir.
- Un PDF peut transporter des instructions exécutées dès l’ouverture, avant que vous n’ayez rien lu.
- Un PDF peut se comporter différemment selon le logiciel qui l’ouvre : le fichier que vous voyez n’est pas forcément celui que voit votre collègue.
- Un PDF transporte plus qu’il ne montre : pièces jointes, calques cachés, historique des révisions et métadonnées que vous n’aviez pas l’intention d’envoyer.
Rien de tout cela ne rend les PDF dangereux au quotidien. Vous en ouvrirez des dizaines ce mois-ci et tout ira bien à chaque fois. Mais cela veut dire que le modèle mental que nous portons presque tous — « ce n’est qu’un document » — est faux d’une manière qui compte parfois.
Le réglage que presque personne ne connaît
Le conseil habituel est « désactivez JavaScript dans votre lecteur PDF », et c’est un bon conseil. Il est aussi, à lui seul, incomplet : la plupart des gens n’ouvrent plus les PDF dans un lecteur PDF. Ils les ouvrent dans un onglet de navigateur, et le navigateur a son propre interrupteur, distinct.
Firefox est livré avec le script PDF activé. La préférence s’appelle pdfjs.enableScripting dans about:config ; elle valait false jusqu’à Firefox 87 et vaut true depuis Firefox 88. L’interrupteur général javascript.enabled ne la touche pas : la visionneuse PDF est un monde à part, avec un réglage à part.
Chrome et Edge n’exposent aucun interrupteur dédié au script dans les PDF. Le script d’un PDF relève de l’autorisation JavaScript du site d’où vient le fichier — désactivable site par site depuis les contrôles de la barre d’adresse, ou globalement dans chrome://settings/content/javascript, un instrument nettement plus grossier.
Adobe Acrobat Reader possède l’interrupteur auquel tout le monde pense : Préférences → JavaScript → Activer JavaScript pour Acrobat. C’est celui qu’il vaut la peine de décocher, car Acrobat est le lecteur à la grande API et presque personne n’utilise sciemment un PDF scripté dans son travail ordinaire.
Concrètement : le désactiver dans Acrobat et laisser le navigateur tranquille est un choix raisonnable et proportionné. Croire qu’on l’a désactivé partout alors qu’on ne l’a fait que dans Acrobat ne l’est pas.
Que faire de cette information
La réponse pratique est modeste et vaut ces dix minutes.
Désactivez JavaScript dans votre lecteur de bureau. Dans Acrobat Reader : Préférences → JavaScript. Cela supprime toute une catégorie de risque et ne coûte rien, sinon — il faut le reconnaître — la possibilité de jouer à DOOM dans un champ de formulaire.
Gardez le lecteur à jour. Le script est une voie d’entrée. Les failles dans le code qui décode les polices et les images en sont une autre, et ce sont elles que les mises à jour corrigent — historiquement, c’est même la voie la plus fréquente.
Traitez les documents inattendus comme inattendus. Une facture d’une entreprise chez qui vous n’avez jamais rien acheté mérite un instant de réflexion, quel que soit son format. Cela vaut plus que n’importe quel réglage.
Remarquez ce que ces trois points ont en commun : aucun n’exige de renoncer aux PDF ni de se méfier des documents en général. Ils équivalent à fermer sa porte à clé — bon marché, ennuyeux, et sensé précisément parce que le risque est faible mais non nul.
Pourquoi ce projet mérite l’attention qu’il a reçue
Il serait facile de classer doompdf dans « curiosité d’internet » et de passer à autre chose. Je le crois plus utile que cela, pour une raison qui n’a rien à voir avec le théâtre sécuritaire.
La compréhension qu’ont la plupart des gens des formats de fichiers repose entièrement sur l’usage qu’on en fait. Les documents servent à lire. Les tableurs, aux chiffres. Les images, à être regardées. Ce modèle fonctionne presque toujours, et c’est bien pour cela qu’il est si difficile à déloger — et que l’explication « un PDF peut contenir du contenu actif » se heurte généralement à un scepticisme poli.
Un jeu jouable dans un document accomplit en dix secondes ce qu’un article peine à faire en mille mots. Il remplace une affirmation abstraite par quelque chose sur quoi on peut cliquer.
Et le fond de l’affaire dépasse largement le PDF. Les formats accumulent des fonctionnalités pendant des décennies. Chaque ajout avait du sens pour quelqu’un qui résolvait un vrai problème : la validation d’un formulaire est réellement utile, et un document capable de vérifier ses propres calculs aussi. Résultat : les choses ordinaires que nous échangeons chaque jour sont considérablement plus capables que leur nom ne le suggère. Et une capacité, une fois inscrite dans une spécification, est à la disposition de quiconque lit cette spécification.
Ce qu’il en reste pour le quotidien
Rien de tout cela ne plaide contre le PDF. Il reste le meilleur format pour envoyer un document qui aura la même apparence partout, sur n’importe quelle machine, dans plusieurs années. C’est un problème réellement difficile, et le PDF l’a résolu. Les fonctionnalités qui rendent doompdf possible sont celles qui rendent possible un formulaire fiscal à remplir.
C’est un plaidoyer pour savoir ce que l’on manipule. La même polyvalence qui permet à un document de transporter un jeu lui permet aussi de transporter des scripts, des pièces jointes, des calques cachés et des métadonnées que vous n’aviez pas prévu d’envoyer. Cela mérite d’être compris, et rien de tout cela n’est un motif d’alarme.
C’est aussi une partie de la raison pour laquelle PDF Manipulator fonctionne entièrement sur votre propre ordinateur. Pour fusionner, découper ou convertir des fichiers, moins il y a d’intervenants, mieux c’est — non parce que les services en ligne seraient sinistres, mais parce qu’un document qui n’a jamais quitté votre machine est bien plus simple à appréhender qu’un document passé par le serveur de quelqu’un d’autre.
Travaillez sur vos PDF entièrement hors ligne — PDF Manipulator est gratuit →
Sources
- ading2210, doompdf sur GitHub — code source et description technique ; Emscripten 1.39.20, sortie 320×200 en six teintes, ~80 ms par image, GPL v2
- ading2210, linuxpdf sur GitHub — Linux sur un émulateur RISC-V TinyEMU dans un PDF, démarrage en 30–60 secondes
- Version jouable (navigateurs fondés sur Chromium)
- Eric Lawrence, Browser Security Bugs that Aren’t: JavaScript in PDF — ce que les moteurs PDF des navigateurs autorisent ou non
- Adobe, Restrict JavaScript API access in Acrobat
- DoomWiki, Licences — publication du code le 23 décembre 1997, passage à la GPL le 3 octobre 1999
- The Register, It’s Doom … running in a PDF file
- Ars Technica, This PDF contains a playable copy of Doom
