L’erreur de disque maître de Space Quest II

• Le Disk 1 720KB de Space Quest II 2.0D/2.0F de Sierra On-Line contenait encore du code source de l’interpréteur AGI invisible dans la liste des fichiers, un cas où une erreur de préparation du disque maître a été reproduite telle quelle sur les disques commerciaux
• Dans le FAT de DOS, supprimer un fichier n’efface pas les données et se contente de marquer les secteurs comme inutilisés ; si un disque non formaté sert de maître, les données précédentes peuvent se retrouver sur toutes les copies
• Dans les 402 432 octets d’espace « free » du Disk 1, on trouvait du code source C/assembleur au lieu de la valeur de remplissage de formatage 0xF6, et l’extraction a révélé 93 fichiers et plus de 15 000 lignes, soit environ 70 % du code source de l’interpréteur AGI
• Le matériel de duplication FormMaster copiant tous les secteurs du disque octet par octet plutôt que fichier par fichier, il est possible que des données supprimées absentes de la liste réelle des fichiers aient été diffusées sur les disques destinés aux clients et aux revendeurs
• Cette erreur, survenue en mars 1988 à la fin de l’ère AGI, est restée enfouie jusqu’à la première découverte connue faite par NewRisingSun en octobre 2016, avant de devenir 36 ans plus tard un document d’archéologie numérique sur l’implémentation AGI de Sierra

---

Des traces invisibles dans la simple liste des fichiers

• Les disquettes 720KB de Space Quest II versions 2.0D et 2.0F n’ont extérieurement rien de particulier, et leur liste de fichiers ressemble à celle de n’importe quel disque de jeu Sierra
• Dans le répertoire de la 2.0D, aucun fichier supplémentaire suspect n’apparaît, et les principaux fichiers de données comme PICDIR, LOGDIR, VIEWDIR, SNDDIR, VOL.0 et VOL.1 ont été créés le 14 mars 1988
• Les fichiers .OVL sont datés du 15 mars 1988, tandis que le code de l’interpréteur AGI porte l’horodatage du 18 mars 1988, ce qui laisse une trace d’une semaine de préparation de Space Quest II 2.0D dans les bureaux de Sierra
• L’espace utilisé du disque est indiqué à 302 918 octets, et l’espace « free » à 402 432 octets, donc l’espace vide était plus grand que l’espace occupé

La zone inutilisée révélée par un éditeur hexadécimal

• Sous DOS, les secteurs inutilisés d’une disquette fraîchement formatée sont généralement remplis avec la valeur de formatage 0xF6
• Sur le Disk 2 de Space Quest II 2.0D, les secteurs inutilisés étaient bien remplis de 0xF6, mais sur le Disk 1, il n’y avait pas un seul secteur inutilisé rempli de 0xF6
• Sur le Disk 1, la plus longue séquence continue d’octets 0xF6 n’était que de 2 octets, et bien que plus de la moitié du disque soit marquée « free », d’anciennes données y restaient en réalité présentes
• La zone marquée comme inutilisée contenait du texte ressemblant à du code source C, ce qui suggère fortement que ce disque avait servi à autre chose avant d’être utilisé comme maître du Disk 1 de Space Quest II
• Dans le système de fichiers FAT de DOS, supprimer un fichier ne retire pas les données elles-mêmes, mais indique seulement que les secteurs peuvent être réutilisés ; si de nouveaux fichiers ne les écrasent pas, le contenu précédent reste intact

Le code source de l’interpréteur AGI resté sur le disque

• En extrayant le texte ASCII de la zone inutilisée, on retrouve des fonctions C comme DisplayStatusLine et StatusLineOn
• DisplayStatusLine est du code qui affiche une ligne de texte incluant le score actuel et l’état on/off du son, en lien avec la barre d’état blanche en haut de l’écran de Space Quest II
• Ce code n’appartient pas aux données du jeu, mais bien au code source de l’interpréteur AGI lui-même de Sierra
• Les secteurs inutilisés contenaient une grande quantité de code source et, comme celui-ci était stocké dans des secteurs contigus, il a été relativement facile de l’extraire puis de le séparer fichier par fichier
• Chaque fichier comportait en haut un commentaire indiquant son nom de fichier source, ce qui facilitait l’identification des points de découpe ; le résultat final est de 93 fichiers
  • 75 fichiers source C
  • 16 fichiers source assembleur
  • 2 fichiers DOS BAT
• Le code complet représente plus de 15 000 lignes, et la plupart des fichiers étaient complets
• Ce disque contenait environ 70 % du code source de l’interpréteur AGI de Sierra On-Line, avec commentaires et historique des modifications inclus

Historique des modifications et traces des développeurs

• Les commentaires d’en-tête de certains fichiers source incluent un Change History
• L’en-tête de ANIMATE.C contient le nom du fichier source, une brève description indiquant qu’il « traite un cycle d’animation dans un adventure game », ainsi que des informations comme compile: MWC
• MWC semble désigner le compilateur C de Mark Williams, largement utilisé à l’époque
• L’historique des modifications comprend la date, l’heure, les initiales de l’auteur et une description du changement
• Parmi ces initiales, JAS correspond à Jeff Stephenson, principal contributeur au code de l’interpréteur AGI, et DCI à Chris Iden
• Robert Heitman apparaît également, mais son travail portait surtout sur des outils graphiques comme Picture Editor et View Editor, tandis que Jeff Stephenson et Chris Iden s’occupaient principalement du code de l’interpréteur

La carte mémoire de AGI.EXE et le calcul des 70 %

• Le Disk 1 720KB de Space Quest II 2.0D contenait, en plus des 93 fichiers source, la carte mémoire de l’exécutable AGI.EXE sur plus de 2 000 lignes
• Dans les jeux AGI commercialisés, l’exécutable de l’interpréteur s’appelle simplement AGI et ne peut pas être lancé directement, mais pendant le développement, on utilisait un interpréteur directement exécutable avec l’extension .EXE
• Quelqu’un chez Sierra a généré le 7 octobre 1987 la carte mémoire de AGI.EXE, c’est-à-dire de l’interpréteur AGI
• Cette date concorde avec le fait que le commentaire le plus récent dans l’historique du code source remonte à septembre 1987
• La carte mémoire fournit de manière relativement complète la liste des modules et fichiers source qui composent l’interpréteur AGI
• On y trouve 98 fichiers source distincts, dont 71 sont présents en version complète sur le disque de SQ2
• Sur cette base, on calcule qu’environ 70 % du code source de l’interpréteur AGI se trouvait sur le disque de Space Quest II
• Certains modules ne contiennent que des fichiers d’en-tête C et ne sont pas inclus dans ce calcul

AGI comme propriété intellectuelle de Sierra

• Sierra On-Line a traversé une période économiquement difficile autour de la sortie de King’s Quest en 1984, et Ken Williams a dû licencier environ 100 employés, faisant passer les effectifs d’environ 130 à environ 30 personnes
• Par la suite, le succès du système de jeux d’aventure AGI et des jeux créés dessus a contribué à redresser la situation de l’entreprise
• Fin 1984, King’s Quest est entré dans le top 20 des ventes de logiciels de jeux sur ordinateur et y est resté environ six mois, jusqu’à la sortie de King’s Quest II
• L’accord avec Tandy Radio Shack, qui permettait de vendre les versions Tandy des jeux dans les magasins Radio Shack, a également aidé
• De 1985 à 1988, les jeux AGI ont continué à être des best-sellers, et l’interpréteur AGI constituait à la fois une source majeure de revenus et une propriété intellectuelle centrale de Sierra On-Line
• Du point de vue de Sierra, voir 70 % du code source de l’interpréteur AGI copié en masse et livré à des dizaines ou centaines de milliers de clients représentait une grave erreur

Les conséquences d’un disque maître non formaté

• Lors de la préparation d’une nouvelle sortie, Sierra créait un disque maître de production destiné au matériel de duplication FormMaster
• FormMaster ne copiait pas seulement les fichiers du disque maître, mais tous les secteurs du disque octet par octet, qu’ils soient utilisés ou non
• Sur le Disk 1 des versions Space Quest II 2.0D et 2.0F, cette méthode a donc aussi copié les 402 432 octets qui n’étaient pas réellement utilisés comme fichiers
• Dans la préparation du disque maître, il fallait d’abord formater entièrement la disquette avant d’y copier les fichiers du jeu, et Sierra exécutait correctement cette étape sur la plupart des disques originaux de ses jeux
• Dans le cas du Disk 1 de Space Quest II 2.0D, quelqu’un semble avoir oublié cette étape de formatage, et le même disque a aussi été utilisé pour la 2.0F
• Résultat possible : des dizaines ou centaines de milliers de disques SQ2 expédiés aux clients et aux revendeurs ont pu contenir en cachette 70 % du code source de l’interpréteur AGI

Un cas d’archéologie numérique révélé seulement en 2016

• Cet incident était presque certainement involontaire, et il semble que ni Sierra, ni ses concurrents, ni ses clients ne s’en soient aperçus à l’époque
• La première découverte connue a été faite en octobre 2016 par l’utilisateur en ligne NewRisingSun
• Le fait que cela se soit produit à la fin de l’ère AGI est également important
  • En mars 1988, Sierra avait déjà développé le système de jeux d’aventure SCI
  • La sortie de King’s Quest IV, premier jeu à utiliser SCI, approchait
• Si ce code source de l’interpréteur AGI avait pu être exposé accidentellement un ou deux ans plus tôt, les conséquences auraient pu être plus graves
• Le code source extrait de l’interpréteur AGI a été mis en ligne dans un dépôt GitHub
• L’implémentation AGILE, un interpréteur AGI web, s’est à l’origine appuyée en partie sur ce code source AGI

[GN⁺]

Avis de Hacker News

• La version DOS de Double Dragon II: The Revenge, sortie en 1989, était distribuée sur deux disquettes, dont l’une contenait l’intégralité du code source sous forme d’archive compressée supprimée.
  Elle n’apparaissait pas avec la commande DIR, mais pouvait être récupérée facilement : https://tcrf.net/Double_Dragon_II:The_Revenge(DOS)

  • Quand on ouvre des ROM, c’est toujours amusant de voir des cas où des répertoires et noms de fichiers se sont retrouvés gravés tels quels dans le silicium pendant la compilation.
    Même à une époque où chaque octet coûtait littéralement de l’argent, il est drôle de constater qu’un bon nombre d’entrées FAT de gens ont fini cuites dans des cartouches.
    https://forums.nesdev.org/viewtopic.php?t=17324
  • Question peut-être un peu idiote, mais je me demande comment ce genre de chose arrive.
    J’imagine qu’ils finalisaient le jeu, créaient une sorte de disquette master, puis l’envoyaient à l’usine de production en masse ; du coup je me demande comment une archive compressée supprimée a pu se retrouver sur le master. Peut-être qu’ils l’ont copiée par erreur puis supprimée avant la sortie.
  • C’était mon deuxième jeu multijoueur, essayé chez un ami sur l’ordinateur de son père.
    Le premier, c’était aussi sur cette même machine : Spacewar! en version DOS. Si ma mémoire est bonne, Double Dragon II plantait quand on arrivait au boss, donc je ne l’ai jamais terminé, mais j’en garde un bon souvenir.

• Ces derniers temps, je fais beaucoup de rétro-ingénierie de ROM de synthétiseurs.
  La ROM du Yamaha DX9 contenait, dans l’espace vide restant du binaire, des fragments de table de symboles du firmware[0], ainsi qu’un gros bloc de code 6303 qui venait probablement du système de développement. Tomber par hasard sur ce genre de choses procure une sensation vraiment étonnante. J’étais tellement absorbé par tout ça que j’avais l’impression d’être un archéologue logiciel jetant un bref coup d’œil dans le passé, et je suis descendu très loin dans le terrier du lapin pour essayer de comprendre quels outils de développement Yamaha utilisait. Je n’ai rien trouvé de définitif, mais lire la documentation des outils de développement de l’époque m’a rendu plus reconnaissant envers les workflows modernes.
  0: https://ajxs.me/blog/Hacking_the_Yamaha_DX9_To_Turn_It_Into_...

  • J’aime aussi la rétro-ingénierie côté synthétiseurs : j’avais analysé le Yamaha A-sampler il y a quelque temps et créé un outil de gestion permettant aux utilisateurs de disquettes Yamaha A-sampler d’effectuer plus rapidement les opérations de base.
    J’ai fait beaucoup d’entrées-sorties brutes et d’analyse de secteurs de disque bruts sur BeBox, et BeOS disposait de bons outils pour bidouiller les systèmes de fichiers. Grâce à ça, j’ai créé un pilote de système de fichiers pour Windows, qui fonctionnait assez bien pour recevoir le soutien de Yamaha. Si un jour l’envie te prend de faire de la rétro-ingénierie sur la ROM Yamaha du A-sampler, contacte-moi. Ce domaine m’intéresse beaucoup. Ton travail sur les DX9/DX7 est excellent, et en tant qu’utilisateur de ces deux synthétiseurs depuis leur lancement, je trouve ça vraiment passionnant.

• Ce jeu a occupé une place tellement forte dans mon enfance que, quand j’y repense tant d’années plus tard, ça me paraît presque irréel.
  Imaginer ressentir aujourd’hui le même type de connexion avec un jeu dans ma vie actuelle me semble impossible. Tout ce qui m’entoure ressemble simplement à un jeu, une série, un objet ; alors que Space Quest 2, 3 et 4 sont entremêlés à une partie fondamentale de mon ADN.

  • Space Quest III a été mon premier jeu Sierra, et il a clairement ce pouvoir-là.
    Les jeux Sierra de cette période étaient vraiment particuliers. J’ai surtout beaucoup joué à Police Quest II, LSL III et Hero's Quest à peu près à la même époque. Il y avait quelque chose de magique dans les jeux Sierra EGA à interface texte ; pour moi, ils se situaient exactement au bon endroit, émotionnellement et créativement, entre Infocom et les versions VGA point-and-click qui sont venues ensuite.
  • J’ai commencé par le 6, puis je suis revenu aux épisodes 1 à 5, et ils sont clairement devenus une partie centrale de ma personnalité.
    Space Quest est aussi lié à l’une de mes histoires préférées de l’Internet des débuts. À l’époque où les sites web étaient surtout hébergés sur Geocities et par des étudiants qui s’ennuyaient, il existait des sites de fans de Space Quest, et j’avais envoyé un e-mail à l’administrateur de l’un des gros sites SQ pour lui dire que j’aimais les jeux et son site. Je devais avoir environ 14 ans ; il m’a répondu qu’il pouvait m’envoyer les jeux originaux pour quelque chose comme 40 dollars. C’étaient tous les originaux, avec les boîtes et les disquettes. Comme on était vers 1997, j’étais un peu inquiet à l’idée d’envoyer 40 dollars à un inconnu à l’autre bout du pays en espérant qu’il enverrait vraiment quelque chose, mais il l’a fait. Quelques semaines plus tard, tous les jeux sont arrivés exactement comme décrits, et j’étais aux anges. Je suis devenu un vrai croyant du jour au lendemain, et c’est encore aujourd’hui une sorte de noyau solaire d’optimisme auquel je me raccroche. Jess, si jamais tu es quelque part, tu étais authentique. J’espère qu’on se recroisera un jour.
  • J’ai un ressenti très similaire.
    Mon père travaillait dans une aciérie et était ami avec le responsable informatique de là-bas, qui lui a donné une copie de SQ2 pour qu’on l’essaie à la maison. J’ai joué à ce jeu comme un fou, mais j’étais assez jeune et beaucoup de choses m’échappaient. Quand j’étais vraiment bloqué, je demandais à mon père de demander au responsable informatique comment passer un passage précis, et il me semble qu’au lieu de donner directement la réponse, il donnait gentiment des indices. Environ 35 ans ont passé, mais je me souviens encore assez précisément de rêves que j’ai faits en lien avec ce jeu. Il a vraiment eu un grand impact.
  • J’ai le même sentiment, mais surtout pour Space Quest II.
    J’ai joué à SQ I beaucoup plus tard, et SQ III ne m’a pas touché aussi fortement. Les suivants n’étaient même plus des jeux EGA à saisie de texte. SQ II ravive énormément de souvenirs, et j’ai aussi appris une partie de mon anglais grâce à lui. Je me souviens de la satisfaction d’avoir découvert qu’on pouvait faire “rub berries” avec Roger Wilco.
  • J’étais tellement content que free little dude fonctionne pour sauver la créature au début du jeu.
    C’était la première fois que je jouais à ce genre de jeu, et vers dix ans, j’y suis resté accroché pendant des semaines.

• Je ne pense pas que le moteur AGI contenait une sauce secrète particulière dont un concurrent aurait pu tirer profit en cas de fuite
  Il y a peut-être d’autres exemples, mais Hugo's House of Horrors était, quelques années plus tard, un jeu de style AGI créé par une seule personne. Au-delà de la nouveauté initiale de l’aventure graphique, si les jeux Sierra ont bien marché, c’est parce qu’un effort énorme était consacré à la création des graphismes et à l’écriture du jeu lui-même. Cela ne veut pas dire que la technologie ne comptait pour rien, mais sa part dans le résultat final était plutôt faible.

  • À cette époque, il était bien plus difficile d’obtenir des informations et des exemples de code utiles
    Apprendre et créer un logiciel fonctionnel était immensément plus difficile qu’aujourd’hui, et il y avait très peu de choses sur lesquelles s’appuyer. Sous MS-DOS, il existait très peu d’open source significatif, et encore moins de moteurs de jeu open source. Dans ce contexte, si le code source d’AGI avait largement fuité, il aurait pu avoir une vraie importance, au moins comme plan montrant précisément comment certains des jeux PC les plus populaires de l’époque étaient conçus.
  • Je me demande parfois si du code source divulgué a vraiment de la valeur
    Surtout lorsqu’il ne contient pas de secrets exploitables par des hackers, comme des clés ou des portes dérobées. Le code divulgué n’a évidemment pas de licence ; si l’on veut éviter les procès, on ne peut donc pas le réutiliser tel quel dans son propre produit. Au final, il faut lire ce code, comprendre les techniques, puis les appliquer à son propre travail sans que cela sente la violation de copyright, ce qui est généralement plus difficile que de repartir de zéro. Même s’il existe des cas favorables, je me demande à quelle fréquence cela se traduit réellement par un avantage concurrentiel. Les développeurs réécrivent souvent du code même lorsqu’il existe de l’open source bien documenté avec une licence permissive. Lire du code est souvent plus difficile que l’écrire, et même simplement le recompiler peut s’avérer compliqué. Cela peut rendre la copie un peu plus facile, mais les jeux étaient généralement crackés et distribués en quelques jours, et le code de protection contre la copie n’était peut-être pas inclus dans les sources.
  • On dirait quelqu’un qui a grandi à une époque où l’on pouvait « faire quelque chose sans écrire en ASM ni en C »
    Il y avait probablement plusieurs ordres de grandeur de moins de personnes capables de parler ces langages, et encore moins capables de produire quelque chose de cohérent avec.
  • À l’époque, le taux d’apprentissage des réseaux neuronaux internes était quasiment au maximum
    Aujourd’hui, il baisse rapidement, si bien que les choses que l’on rencontre maintenant ont moins de force pour former les poids internes qu’à l’époque.

• Les commentaires d’historique des modifications sont vraiment excellents
  À une époque bien antérieure aux outils de gestion de sources capables de montrer clairement ce genre de choses, ils témoignent d’un haut niveau de soin et de savoir-faire. Franchement, même après CVS/SVN/Git, cela n’est toujours pas évident pour beaucoup de gens. Cet article me rappelle aussi le célèbre texte « No Silver Bullet »[1] de 1986, qui prédisait que le logiciel continuerait pour l’essentiel à être écrit comme alors, péniblement, commande après commande, par des programmeurs. Le fait que le code du moteur de jeu et les commentaires de l’article original ressemblent à quelque chose que j’aurais pu écrire aujourd’hui conforte, près de 40 ans plus tard, cette prédiction.
  [1] https://en.wikipedia.org/wiki/No_Silver_Bullet

  • Même aujourd’hui, on voit beaucoup trop de messages de commit git du genre « fix » ou « stuff ».

• La version Famicom de Air Fortress contient une quantité absurdement élevée de choses qui se sont retrouvées involontairement dans la ROM
  On y trouve notamment du code ASM non compilé, des listings de répertoires MS-DOS, des chaînes issues de l’un des EXE utilisés pour construire le jeu, et bien d’autres choses. La cartouche japonaise faisait 128+128 Ko. Plus tard, lors de la création de la version NES américaine, la majeure partie des 128 Ko de données graphiques s’est révélée être des graphismes dupliqués ou inutilisés, les graphismes réellement uniques représentant environ 36 Ko. En supprimant l’image d’une planète dans l’une des fins, les graphismes ont été réduits à 32 Ko, et le jeu est sorti sur une cartouche 128+32 Ko au lieu d’une cartouche 128+128 Ko.
  Source : https://tcrf.net/Air_Fortress

• Ce genre de situation s’est en réalité produit très souvent
  The Cutting Room Floor recense environ 500 cas, allant de quelques morceaux de code inclus par accident à la présence de la majeure partie du code
  https://tcrf.net/Category:Games_with_uncompiled_source_code

  • Après une vérification rapide, il semble que ce cas précis de code non compilé de l’interpréteur AGI sur cette disquette de Space Quest II n’y figure pas encore
    Je me demande si j’arrive à la même conclusion. La même chose s’est produite sur une disquette de King's Quest III, et cela semble en fait être arrivé presque au même moment que le cas Space Quest II.

• Ce que je préfère, c’est qu’il semble que personne n’ait découvert le code source présent sur la disquette pendant toute une génération
  « Étonnamment, ni Sierra, ni ses concurrents, ni ses clients ne semblent avoir remarqué que cela s’était produit, et la découverte n’a été faite que des décennies plus tard. La première découverte connue est celle de l’utilisateur en ligne NewRisingSun, en octobre 2016. » Cela me fait penser aux avancées récentes autour de Tetris et de Super Mario Bros. Quand je jouais à ces jeux enfant, je pensais que, des décennies plus tard, ils ne seraient plus que des artefacts oubliés, impossibles à lancer sauf pour les passionnés les plus dévoués. Mais Internet et les émulateurs ont donné une nouvelle vie à ces premiers jeux et à l’informatique de cette époque.

  • La dernière phrase semble donner la réponse
    Des gens ont sûrement découvert les fichiers supprimés, mais avant que l’Internet ne soit généralisé, il est probable que cela ne se soit pas largement su ni n’ait été documenté.
  • Certaines personnes utilisent des outils modernes comme l’imagerie de flux pour préserver d’anciens logiciels et permettre des copies parfaites de disquettes
    Il se peut que quelqu’un ait découvert des données restées dans l’espace libre en imageant ce genre de disquette.

• Entre 1987 et 1993, j’ai préparé environ neuf disquettes master pour deux apps Mac.
  J’utilisais toujours des disquettes neuves, et nous avions une longue checklist pour vérifier que la disquette était la bonne. Heureusement, tout s’est bien passé, et certaines ont notamment servi à produire 100 000 disquettes. Heureusement qu’aujourd’hui plus personne n’a à faire ça.

  • On fait encore quelque chose de similaire aujourd’hui, sauf que ça s’appelle des couches Docker.
    J’ai déjà vu des couches comme celles-ci : base, ajout des outils, ajout du code source, compilation, suppression du code source, suppression des outils supplémentaires, release. Du genre : « Pourquoi l’image Docker est-elle aussi grosse ? Bon, le stockage ne coûte pas cher… ». Il existe pourtant des solutions simples, comme les builds multi-stage ( https://docs.docker.com/build/building/multi-stage/ ). Mais si l’on ne sait pas que la vue actuelle d’une image Docker inclut toutes les couches précédentes, ce genre d’erreur peut arriver de temps en temps.

• À l’époque où l’on préparait à la main les artefacts de release, il arrivait souvent qu’ils contiennent des restes qui n’étaient pas censés être publiés.
  Par exemple du contenu coupé[1] ou des symboles de débogage[2]. Quand je suis tombé par hasard sur des symboles de débogage cachés dans l’archive de données d’une version démo d’un jeu vidéo sur lequel je faisais du reverse engineering, c’était inattendu, mais extrêmement utile. De nos jours, avec le CI/CD, les builds automatisés et les autres pratiques de développement modernes, ce genre de chose est probablement moins fréquent.
  [1] https://tcrf.net
  [2] https://www.retroreversing.com/games/symbols

  • Je soupçonne que les bonnes pratiques comme le CI/CD ne sont pas aussi répandues dans le développement de jeux qu’on pourrait le penser.
  • Les pipelines CI/CD peuvent aussi avoir l’effet inverse.
    S’il n’y a pas d’erreur, personne ne va lire des milliers de lignes de sortie console. Même si le package final de release contient beaucoup trop de choses inutiles, les tests ont de bonnes chances de passer. Mon intuition va donc plutôt dans le sens inverse : cela pourrait arriver plus souvent, ou au moins le CI/CD pourrait rendre ce genre de problème plus probable qu’avec des builds manuels. Il peut aussi y avoir d’autres facteurs.