Un clone de DOOM en COBOL : l'incroyable défi réussi

Certaines questions ne mériteraient même pas d'être posées. Puis vient un développeur, connu sous le pseudonyme icitry, qui décide de répondre à l'une d'entre elles avec une démonstration technique éblouissante. Peut-on coder un jeu de tir à la première personne en COBOL, ce langage de programmation conçu en 1959 pour le traitement de données commerciales ? La réponse, contre toute attente, est oui. Et le résultat n'est pas une simple preuve de concept : c'est un clone de DOOM parfaitement jouable.

Pourquoi le COBOL et le jeu vidéo n'avaient rien à voir

Avant de comprendre l'exploit d'icitry, il faut remonter le fil de l'histoire informatique. Le COBOL, acronyme de Common Business-Oriented Language, a été créé par un comité dirigé par l'amiral Grace Hopper. Son objectif était clair : standardiser le traitement des données dans les administrations et les grandes entreprises. Penser aux salaires, aux inventaires, aux transactions bancaires — tout sauf aux démons infernaux déferlant dans un couloir en trois dimensions.

La syntaxe COBOL elle-même évoque des formulaires administratifs plutôt que des boucles de rendu graphique. Des mots comme DIVISION, SECTION, PERFORM, ou EVALUATE structurent un code verbeux où chaque ligne raconte son intention avec une clarté bureaucratique. Imaginez un développeur moderne habitué à Python ou JavaScript qui découvre qu'une simple addition s'écrit : ADD A TO B GIVING C. C'est peu dire que l'écart culturel avec le C optimisé de John Carmack, créateur du DOOM original en 1993, ressemble à un fossé.

Le véritable génie du projet d'icitry ne réside pas dans la performance brute, mais dans la démonstration qu'un paradigme figé peut, par la créativité, devenir un vecteur d'innovation inattendu.

Les contraintes techniques d'un langage antédiluvien

Le COBOL ne possède aucune bibliothèque graphique native. Pas de SDL, pas d'OpenGL, pas même de gestion directe de la mémoire vidéo. Pour afficher un labyrinthe en pseudo-3D, icitry a dû contourner chaque limitation avec des solutions qui témoignent d'une maîtrise profonde des systèmes hérités. Le rendu s'apparente à de l'ASCII art poussé à l'extrême, ou à des appels système vers des terminaux capables d'interpréter des séquences d'échappement pour positionner le curseur.

Un environnement de développement comme GnuCOBOL, qui compile vers du C intermédiaire, a probablement facilité certaines interactions de bas niveau. Pourtant, l'essentiel du moteur reste fidèle au paradigme procédural COBOL : des fichiers de données décrivant les cartes, des tables indexées pour les textures, des parcours séquentiels pour le raycasting. Cette approche, que développement sur mesure Genève maîtrise pour des architectures complexes, montre que la contrainte nourrit l'ingéniosité.

Comment fonctionne un moteur de raycasting en COBOL

Le raycasting, technique de rendu popularisée par Wolfenstein 3D et perfectionnée dans DOOM, simule une perspective 3D en projetant des rayons depuis la position du joueur jusqu'à rencontrer un mur. Chaque colonne d'écran correspond à un angle de vision, et la distance du mur détermine la hauteur affichée. C'est mathématiquement élégant, intensif en calculs, et absolument pas prévu pour des structures de données COBOL.

L'architecture des données : le cœur du défi

Dans COBOL, tout passe par des fichiers séquentiels ou indexés. Icitry a dû modéliser la carte du niveau comme un enregistrement de tableau, chaque cellule stockant un identifiant de texture. Les coordonnées du joueur — position X, position Y, angle de rotation — résident dans des WORKING-STORAGE SECTION, l'équivalent des variables globales. La boucle de rendu devient un PERFORM VARYING qui itère sur chaque colonne de l'écran, calcule l'intersection rayon-mur, et écrit le résultat dans un buffer texte.

• La carte du niveau : fichier plat structuré en grille 24x24, chaque case codée sur un octet
• La table des textures : définition ASCII de 64 caractères représentant un motif de brique ou de métal
• Le Z-buffer simplifié : distance stockée dans une variable comp-1 (virgule flottante COBOL)
• Le buffer d'écran : chaîne alphanumérique reconstruite à chaque frame avant affichage terminal

La gestion des entrées utilisateur ajoute une couche de complexité. Sans événements clavier asynchrones natifs, le programme doit lire l'état des touches via des appels système bloquants, ou configurer le terminal en mode raw pour capturer chaque frappe. C'est à ce niveau que l'expertise des outils MCP IA pour site web croise curieusement celle du rétrocomputing : transformer des interfaces primitives en expériences fluides demande abstraction et ingénierie.

Les optimisations qui sauvent la jouabilité

Un moteur de raycasting pur en COBOL brut serait injouablement lent. Icitry a dû implémenter des astuces de calcul numérique propres au langage : pré-calcul des cosinus et sinus dans des tables de consultation, élimination des divisions coûteuses par des décalages arithmétiques, et surtout exploitation du PIC (Picture Clause) pour stocker des nombres fixes avec précision contrôlée. Le résultat atteint une dizaine de frames par secondes sur matériel moderne — modeste, mais honnêtement stupéfiant pour cette pile technologique.

Un clone de DOOM en COBOL ça vous dit ? Les leçons pour l'industrie actuelle

Au-delà de la prouesse technique, ce projet interroge nos présupposés sur l'obsolescence. Le COBOL alimente encore aujourd'hui 43% des systèmes bancaires mondiaux, selon diverses estimations industrielles. Des milliards de transactions quotidiennes transitent par du code écrit il y a parfois quarante ans, maintenu par une génération de programmeurs qui partent progressivement à la retraite. Le défi d'icitry n'est pas qu'un divertissement : c'est une démonstration vivante que ces systèmes peuvent encore surprendre.

La modernisation des systèmes hérités ne signifie pas toujours remplacement brutal. Elle demande parfois de comprendre leur logique profonde pour en extraire une nouvelle valeur.

Pour les entreprises genevoises, particulièrement dans le secteur bancaire et la fiduciaire, cette réflexion est cruciale. Lorsqu'un système COBOL hérité gère des comptes ou des flux financiers, la migration vers une architecture moderne comme Payload CMS Suisse nécessite de préserver l'intégrité transactionnelle tout en offrant des interfaces contemporaines. Le projet d'icitry prouve que l'interopérabilité entre ancien et nouveau est non seulement possible, mais créativement fructueuse.

L'esprit hacker dans un monde de frameworks

L'industrie du développement web et mobile a tendance à s'enfermer dans des écosystèmes préconstruits. React, Vue, Flutter, SwiftUI : des outils merveilleux qui accélèrent la production, mais qui peuvent aussi atrophier la compréhension fondamentale. Le projet COBOL-DOOM rappelle que la programmation, à sa source, est un acte de traduction entre intention humaine et exécution machine — et que cette traduction peut emprunter des voies inattendues.

Un développeur qui maîtrise les principes sous-jacents — la gestion de mémoire, les structures de données, les algorithmes de rendu — peut transposer son expertise à n'importe quel langage. C'est pourquoi notre agence web à Genève valorise cette polyvalence technique dans chaque projet, qu'il s'agisse d'une application mobile inclusive ou d'un site vitrine performant.

Peut-on vraiment jouer ? L'expérience utilisateur décryptée

La question légitime demeure : au-delà de la curiosité intellectuelle, que vaut l'expérience de jeu ? Les retours des early adopters sur les forums spécialisés révèlent un consensus nuancé. Le mouvement est fluide, la collision avec les murs fonctionnelle, les textures reconnaissables malgré leur résolution extrêmement basse. L'absence de son et de musique compense l'atmosphère oppressante par la pure nostalgie du terminal clignotant.

Les limites qui deviennent des signatures artistiques

Ce que le projet perd en fidélité graphique, il le gagne en identité visuelle unique. Le rendu en caractères ASCII produit une esthétique rétro délibérée, un lo-fi gaming avant la lettre qui séduit les amateurs de demoscene et de coding minimaliste. Les ennemis, réduits à des arrangements de symboles, acquièrent une présence étrangement menaçante par l'effort d'imagination qu'ils exigent du joueur.

Cette économie des moyens rappelle les débuts du jeu vidéo, où la contrainte matérielle forçait l'invention narrative. Avant les moteurs 3D photoréalistes, avant les budgets de production cinématographique, un sprite de quelques pixels suffisait à suggérer un monde. Le clone COBOL restitue cette magie primitive, non par nécessité mais par choix délibéré — une distinction essentielle.

L'avenir des langages legacy et la culture technique

Le projet d'icitry s'inscrit dans une tendance plus large de réappropriation des technologies historiques. Des émulateurs de minicomputers fonctionnent dans des navigateurs, des compétitions de programmation en assembleur 6502 attirent des milliers de participants, et des langages comme Fortran ou Pascal connaissent des resurgences communautaires. Ce n'est pas l'archéologie morte : c'est une culture vivante qui interroge le présent à la lumière du passé.

Pour les équipes de développement contemporaines, cet engouement porte un enseignement pragmatique. La dette technique n'est pas toujours un fardeau à éliminer ; elle peut devenir un patrimoine à valoriser. Une base de code COBOL bien structurée, documentée et testée, représente des décennies de validation en production. La remplacer par un système neuf présente des risques de régression que seule une compréhension profonde permet d'évaluer.

Cette approche nuancée guide également nos stratégies de développement d'applications mobiles chez Studio Dahu. Chaque migration, chaque refonte technique, commence par un audit patient des forces et faiblesses du système existant — exactement comme icitry a dû cartographier les capacités cachées du COBOL avant d'y installer son moteur de jeu.

La technologie la plus durable n'est pas celle qui élimine le passé, mais celle qui établit un dialogue continu entre les générations de savoir-faire.

Conclusion : quand l'impossible devient invitation

Le clone de DOOM en COBOL d'icitry n'est pas qu'une curiosité de laboratoire. C'est un manifeste technique, une déclaration selon laquelle les limites du possible sont moins des barrières physiques que des conventions mentales. Transformer un langage de traitement de paie en moteur de jeu vidéo exige une double maîtrise : celle de l'ancien système, assez profonde pour en identifier les ressources insoupçonnées, et celle du domaine cible, assez solide pour reconstituer ses mécanismes fondamentaux.

Dans un écosystème technologique obsédé par le nouveau, cette démarche de réinvention créative offre un contrepoint salutaire. Elle rappelle que l'innovation véritable ne consiste pas toujours à inventer de zéro, mais souvent à recombiner l'existant de manière inédite. Pour les professionnels du développement, des architectes système aux créateurs de site internet pour artisan du bâtiment, cette leçon résonne avec une actualité permanente : chaque contrainte contient en puissance la solution qui la transcende.

Alors, un clone de DOOM en COBOL, ça vous dit ? Peut-être pas pour votre prochain projet client. Mais comme exercice d'humilité intellectuelle, comme démonstration que le code demeure un art de la possibilité, cette aventure technique mérite amplement le détour. Et qui sait : demain, c'est peut-être dans votre vieille base de données héritée que vous découvrirez la ressource inattendue pour votre prochaine innovation.