Observer avant de patcher
Un audit m'a diagnostiqué une erreur de calcul dans la boucle de prière de Limon. J'ai failli corriger. Le code disait l'inverse: le mécanisme était sain. Le code, lui, ne raconte pas d'histoire.
Le verdict qui donne envie de corriger
Un audit automatisé m'a signalé un bug dans Limon. Une erreur de calcul, disait-il, dans la boucle de prière. Le genre de verdict qui donne envie d'ouvrir le fichier et de corriger tout de suite. J'ai failli le faire. Puis j'ai lu le code. Le bug n'existait pas.
Ce que fait une prière
Dans Limon, tu joues un dieu qui observe des peuples sans les piloter. Quand un camp souffre, il t'implore: une prière se lève. Réponds à temps, avec le bon pouvoir sur le bon camp, et elle est exaucée: le peuple gagne en ferveur, toi en foi. Laisse le compte à rebours s'épuiser, et la prière tourne au doute.
Petite mécanique, mais elle porte tout le rapport entre le joueur et son peuple. Cassée, le cœur du jeu est froid.
Le diagnostic qui sonnait juste
Un audit, ici, c'est une passe d'analyse: je confie mon code à un agent, à charge pour lui de trouver ce qui cloche. Celui-ci a rendu un verdict précis. La fenêtre de grâce, le délai pendant lequel une action du dieu peut encore être créditée à une prière, serait trop courte. Conséquence annoncée: les prières expireraient avant d'être reconnues. Une erreur arithmétique, un mauvais réglage de deux nombres l'un par rapport à l'autre.
Ça tombait sous le sens. Une fenêtre trop courte, des prières jamais exaucées, un joueur frustré sans comprendre pourquoi. Le diagnostic racontait une histoire cohérente. C'est exactement ce qui le rendait dangereux.
Ce que le code disait vraiment
J'ai ouvert le fichier de configuration. Deux valeurs.
La durée d'une prière: 420 pas de simulation. La fenêtre de grâce: 500. Cinq cents est plus grand que quatre cent vingt. La fenêtre n'est pas trop courte, elle est plus longue que la vie entière d'une prière. Une prière meurt de vieillesse à 420, bien avant que la fenêtre de 500 ne se referme. Le rapport diagnostiqué était inversé.
Pire pour le diagnostic: en lisant la boucle, j'ai vu que le crédit n'est même pas piloté par ce compte à rebours. Quand le dieu agit sur un camp qui prie, avec le pouvoir du bon type, un simple drapeau se lève sur ce camp (un booléen, un oui ou non en mémoire). Au moment où le besoin se résout, si le drapeau est levé, la prière est exaucée. Le timing n'est pas la porte. L'action l'est. Toute l'histoire de la fenêtre trop courte reposait sur un mécanisme qui n'était pas celui du code.
Le fil-piège que j'ai construit
Je n'allais pas me contenter de lire. Lire, c'est déjà mieux que patcher à l'aveugle, mais je voulais voir le comportement réel.
J'ai écrit un diagnostic, un script en lecture seule qui n'asserte rien et ne modifie aucun fichier: il fait tourner la simulation et imprime des chiffres. Deux mondes comparés sur la même graine. Dans le premier, un dieu qui répond: à chaque prière, il lance le bon pouvoir sur le bon camp. Dans le second, un dieu passif qui ne fait jamais rien, mon témoin, ma ligne de base. Foi forcée côté dieu qui répond, pour isoler le seul mécanisme prière vers résolution et écarter l'économie de foi. Huit mille pas de simulation, trois graines différentes.
Le verdict de l'observation a contredit celui de l'audit. Le dieu qui répond exauce; le dieu passif, non. L'écart entre les deux est la signature d'un mécanisme qui fonctionne. Il n'y avait pas d'erreur arithmétique à corriger. S'il restait un problème, il était ailleurs: dans la lisibilité, dans le fait que le joueur ne comprenne pas toujours qu'il vient d'exaucer une prière. Un problème de ressenti, pas de calcul. Un tout autre chantier.
La tentation du patch
Voilà ce que j'ai gardé de l'épisode. Un audit, humain ou machine, est excellent pour lever un drapeau: quelque chose sent mauvais, ici. Il est beaucoup moins fiable quand il explique pourquoi. L'agent avait produit une cause plausible, chiffrée, racontable. Elle était fausse.
Le piège n'est pas l'outil, c'est la tentation. Un diagnostic bien formulé donne l'illusion d'avoir compris, et un patch prêt à écrire fait le reste. J'aurais pu échanger deux nombres, casser un équilibre sain, et créer le vrai bug en croyant réparer un faux.
Ma règle depuis: ne jamais patcher sur la foi d'un diagnostic. Aller lire le code, ou mieux, le faire tourner et regarder ce qu'il fait vraiment. Détecter, c'est repérer un symptôme. Comprendre, c'est autre chose, et ça ne se délègue pas. Le code, lui, ne raconte pas d'histoire. Il exécute la sienne, et c'est la seule qui compte.