Un village-jouet avec les vraies maisons

TL;DR

Jah est un vrai village habité. Pour le modifier sans risquer les habitants, il fallait pouvoir travailler sur du réel sans toucher au réel. On a donc monté, en local, une copie jetable des données de production : la vraie base, les vrais comptes, les vrais salons — dans un dossier qu'on détruit d'un Remove-Item. Le geste a été outillé deux fois : une procédure écrite (le savoir) et un agent qui l'exécute (le faire). Et comme une copie vivante ne sert à rien si personne ne la touche, on a ajouté son jumeau : un agent qui joue dans l'interface à la place de l'humain — clique, écrit, navigue, capture. Deux paires livrées, une seule PR.

Carte : statuts projets (Jah = vfjah) · atlas.

Le problème : on ne modifie pas une vraie maison pour tester la peinture

Un village où l'on ne peut pas essayer quelque chose sans risquer de peindre les murs des habitants, c'est un village qu'on n'ose pas faire évoluer. Jah est petit (un processus, un fichier, une poignée de dépendances) mais il est habité : dix-sept comptes, trois villages, plus de mille messages. Tester une mécanique ou reproduire un bug « en vrai » demandait jusqu'ici soit des données de démo (un village factice, tout le monde se connaît), soit de prendre un risque sur la production.

La réponse tient en une phrase : copier la vraie base, la poser à côté, et jouer dessus.

Ce qu'on a monté

Le dépôt savait déjà tourner en local sur un dossier de données dédié (JAH_DATA_DIR). Il ne manquait qu'à remplir ce dossier avec du réel — proprement.

1. Mesurer l'état : où vit la base sur le serveur, quel backup est le plus récent, quelle taille font les images.
2. Copier en lecture seule : la base et les fichiers sortent du conteneur de production par une copie (docker cp puis scp) — jamais une écriture, jamais un arrêt.
3. Rendre la copie utilisable : les mots de passe de prod sont hachés et inconnus, c'est voulu. On pose donc un mot de passe local sur un compte de la copie, et seulement de la copie.
4. Démarrer Jah sur cette copie : mêmes écrans, mêmes comptes, mêmes salons — mais à la maison.

Résultat mesuré : Jah 4.0.23 en local, connecté en fg@jah, avec les vrais contacts et les vrais salons (#agora, #debug, #gazette, #jerem) à l'écran. La copie vit dans un dossier ignoré par Git : on la détruit quand on a fini, et il ne reste rien.

Le piège qui a failli tout arrêter (et ce qu'il apprend)

Premier démarrage : refusé. Le serveur annonçait que des migrations déjà appliquées avaient « changé depuis ». Sauf que rien n'avait changé — Git voyait un arbre propre, les empreintes des fichiers étaient identiques au dépôt.

La cause était ailleurs, et elle est instructive : les fins de ligne. Sur une machine Windows, la configuration Git la plus courante réécrit les fichiers textes avec des fins de ligne Windows (CRLF) ; la production, sous Linux, les a enregistrées avec des fins de ligne Unix (LF). Le contenu est identique, la somme de contrôle ne l'est pas — et c'est pourtant elle que le serveur vérifie pour se prémunir d'une migration modifiée en douce.

Le dépôt déclare pourtant, noir sur blanc, que tout doit être en LF. La correction est donc triviale : réaligner les fichiers sur ce que le dépôt exige déjà. Leçon à garder : « Git dit propre » et « le disque est propre » peuvent être deux choses différentes — la preuve vivait dans une somme de contrôle, pas dans un git status.

Le geste, outillé deux fois : le savoir et le faire

Un savoir qui ne vit que dans une tête (ou dans un fil de conversation) meurt à la session suivante. On l'a donc écrit deux fois, à deux niveaux :

• une procédure — le comment, en six étapes, avec le piège des fins de ligne et le chemin de destruction : c'est la mémoire longue, réutilisable par n'importe quel agent ou par un humain ;
• un agent dédié — la force d'exécution, avec sa loi de sûreté inscrite noir sur blanc : production en lecture seule, jamais écraser les données de dev, jamais deviner un mot de passe, ne rien livrer depuis la copie.

Séparer les deux est volontaire : la procédure peut changer sans réécrire l'agent, et l'agent peut exécuter sans réinventer la procédure. La règle qui gouverne les deux tient en une ligne du projet : on ne fait pas confiance à la prose, on fait confiance à une mesure rejouable.

Le jumeau : un agent qui joue à la place de l'humain

Une copie vivante ne sert à rien si personne ne la touche. D'où le second geste, plus amusant : un agent qui joue dans l'interface à la place de l'humain — il ouvre la page locale, se repère dans l'écran, clique, écrit, navigue, capture. Ses garde-fous sont stricts : local uniquement (jamais la production), aucun secret saisi, un geste vérifié à la fois, et — la règle la plus importante — un bug trouvé n'est jamais corrigé par lui : il en écrit les étapes de reproduction, et le correctif suit le chemin normal, test rouge d'abord.

C'est la même philosophie que le reste : le geste qui se répète devient un outil, pas une improvisation. Un humain qui demande souvent la même chose doit pouvoir la demander une fois de plus — sans réexpliquer comment.

Pourquoi ça compte

• On peut enfin essayer en vrai, sans risque. Le village-jouet a les vraies maisons, et on éteint la lumière en partant.
• La production est en lecture seule pendant toute la manœuvre. La seule chose qu'on lui prend, c'est une copie.
• Le savoir survit. Deux procédures, deux agents, indexés dans les fichiers que tout agent lit au démarrage : la prochaine session n'a plus à réinventer la roue.
• Rien de visible pour les habitants. Aucun changement d'écran, aucune nouvelle dépendance : seulement de quoi travailler sur du réel sans jamais le frôler.

Ce qu'on garde

• Travailler sur du réel, dans une copie jetable. Le meilleur des deux mondes : des vraies données, zéro risque, zéro trace.
• Écrire le geste récurrent, deux fois. La procédure (le savoir) et l'agent (le faire) ne se remplacent pas — ils se complètent.
• Un piège mérite un chapitre. Les fins de ligne n'ont l'air de rien ; elles ont bloqué un démarrage complet et coûté une enquête. Une fois nommé, le piège devient une étape.
• L'humain reste au centre. Les agents font les gestes, mais c'est toujours FG qui décide ce qui touche la production. La copie, elle, ne demande la permission à personne.