Dwarf Fortress passe au contrôle de version après dix ans de refus

Trois citations de Tarn Adams, espacées de dix ans, racontent une trajectoire rare dans l'industrie : l'auteur de l'une des simulations les plus complexes de l'histoire du jeu vidéo a d'abord refusé ouvertement tout système de contrôle de version, puis a fini par l'adopter en 2023. Le développeur et blogueur Simon Willison a rassemblé ces déclarations dans une chronologie et note, avec une pointe de regret, que l'époque sans version control semble désormais terminée.

Trois citations, une évolution

En mars 2013, lors d'un AMA sur Reddit, Adams expliquait qu'il n'aimait pas l'impression de « commiter dans une boîte noire sans bénéfice immédiat ». Le motif est compréhensible et très humain : l'outil exige de la discipline dès le départ, alors que son utilité n'apparaît qu'au moment de la catastrophe.

En mars 2016, dans un entretien accordé à PC Gamer, il est allé plus loin. Selon lui, quelqu'un qui ne sait pas ce qu'est le version control ne lui criera pas dessus, tandis que quelqu'un qui le sait lui demandera : « Qu'est-ce qui ne va pas chez vous, comment pouvez-vous seulement travailler comme ça ? » Adams admettait qu'il n'était « tout simplement pas fait pour ça » et que, en 15 ans, les raisons avaient changé mais que le résultat était resté le même.

En mars 2023, dans un entretien à Game Developer sur la préparation de la sortie officielle de Dwarf Fortress sur Steam, il a employé une tout autre formule : il faut surveiller les canaux Discord et « utiliser le version control », si bien que le processus est devenu « définitivement un peu plus compliqué ».

Pourquoi ce code en particulier

Willison formule ainsi sa principale surprise : vu la complexité interne de Dwarf Fortress, il est difficile d'imaginer une base de code qui aurait davantage besoin du version control. Le jeu simule un monde, son histoire et des personnages individuels, et la moindre modification peut briser une chaîne de dépendances à un endroit inattendu. Travailler des années sur un tel projet sans historique des changements ni possibilité de revenir en arrière peut véritablement être qualifié d'art. Willison, du reste, le dit explicitement en ces termes.

Nuance importante : ces citations ne permettent pas de déduire quand exactement la transition a eu lieu, quel outil est utilisé ni qui l'a introduit. On sait seulement qu'au printemps 2023, il faisait déjà partie du processus de travail.

Ce qui a changé : Steam et l'argent

La citation de mars 2023 date de la période qui suit la sortie du jeu sur Steam. D'après PC Gamer, cette sortie a fait des auteurs des millionnaires après 20 ans de travail sur la simulation. Willison plaisante en disant qu'il est un peu déçu : les développeurs ont « cédé » avant d'atteindre ce cap, mais la course en elle-même reste impressionnante.

Une explication plausible s'impose d'elle-même, même s'il s'agit d'une interprétation et non d'un fait tiré des citations : le projet compte davantage de participants, de processus et d'obligations extérieures. Pour un développeur seul avec un seul ordinateur, l'historique des modifications ressemble à de la bureaucratie. Pour une équipe qui gère un cycle de livraison et un produit commercial, il est indispensable comme l'air qu'on respire.

Jalons clés

• Mars 2013, AMA Reddit : refus du version control à cause d'une « boîte noire sans bénéfice immédiat ».
• Mars 2016, PC Gamer : « Je ne suis tout simplement pas fait pour ça », alors que le développement dure depuis environ 15 ans.
• Mars 2023, Game Developer : le version control est cité comme une partie du travail quotidien, au même titre que les canaux Discord.
• La sortie sur Steam, d'après PC Gamer, a fait des auteurs des millionnaires.
• Inconnus : la date exacte de la transition et l'outil utilisé.

Ce qu'en retiennent les développeurs

L'histoire de Dwarf Fortress illustre bien qu'on peut survivre sans version control, mais qu'on ne peut pas passer à l'échelle sans lui. Pour un projet individuel, c'est une question d'habitude ; pour une équipe, une question de survie.

Si vous travaillez avec des agents IA pour le code, l'argument devient encore plus tranchant. Un agent peut réécrire des dizaines de fichiers en une seule session, et sans commit propre avant son lancement, il n'y a aucun moyen d'annuler le résultat. Le socle minimal de bonnes pratiques : commiter avant chaque session avec un agent, garder une branche dédiée à chaque tâche et relire le diff avant d'accepter les modifications. Adams a passé dix ans à prouver qu'on pouvait s'en passer. Mais c'est lui aussi qui a fini par arrêter.