Quatre questions qui reviennent depuis juillet, et pourquoi elles ne se tranchaient pas

TL;DR

Il reste quatre décisions à prendre sur ce projet. Elles traînent depuis juillet : elles ont traversé trois plans successifs, chaque fois présentées comme « à arbitrer », jamais arbitrées.

En les réexaminant ce soir, j'ai trouvé pourquoi : deux d'entre elles étaient mal posées. Je demandais « on garde ou on supprime ? » là où la vraie question était « doit-on distinguer deux usages ? ». Et j'ai découvert, en vérifiant, que j'avais affirmé deux fois une chose fausse : que le dossier d'outils était autonome. Il ne l'est pas — du code l'appelle.

Une question mal posée ne se tranche pas. Elle se repose.

1. Commençons par une image : le blog est un immeuble

Pour comprendre le premier sujet, il faut une image simple.

Un serveur, c'est un immeuble. Chaque logiciel qui tourne dedans doit occuper un numéro de porte. On appelle ça un « port », mais l'analogie tient : une porte, un occupant. Si deux logiciels s'installent au 5195, le second reste dehors — il ne démarre pas.

Le blog occupe deux portes fixes :

Et deux portes temporaires, ouvertes seulement pendant les tests : 5196 et 5221.

Le planning des portes

Il existe un fichier dans le dépôt — _ssot/ports.json — qui joue le rôle d'un planning de toutes les portes du royaume. Il est partagé entre tous les projets : « le 5195, c'est le blog ; le 5198, c'est la supervision ; le 4340, c'est la documentation… ».

C'est une bonne idée. Elle évite que deux projets se disputent la même porte.

Ce que j'ai vérifié ce soir

Le planning est exact sur les portes fixes du blog : 5195 et 5220 y sont, correctement attribuées. ✅

Mais il est muet sur les deux portes temporaires : 5196 et 5221 n'y figurent pas du tout.

Est-ce grave ? Moins que je le pensais. Un planning de portes sert à éviter que deux services permanents se marchent dessus. Or 5196 et 5221 ne s'ouvrent que le temps d'un test, quelques minutes, puis se referment. Ce n'est pas tout à fait la même catégorie.

Et un détail qui mérite d'être raconté

Il y a un mois, exactement ce piège a frappé. Le raccourci de test du blog — celui qu'on utilise pour essayer une modification sans toucher au vrai site — pointait vers la porte 5198. Sauf que 5198 appartient déjà à la supervision des agents.

Deux occupants pour une porte. Le test aurait échoué au démarrage, sans que personne ne fasse le lien avec le planning.

Le planning le disait, noir sur blanc. Personne ne l'a lu — parce qu'on ne relit pas un planning. On le consulte pour écrire, jamais pour vérifier.

Et tu as déjà publié un article là-dessus le 15 septembre : « Un registre de ports qui ment ». Il raconte la même histoire avec un autre port, et la conclusion était la même : le registre était consulté pour écrire, jamais relu pour vérifier.

2. Le dossier d'outils — ici, je me suis trompé

Ce qui existe

Il y a un dossier dans le dépôt, opencode-manager/, qui contient 17 fichiers : ce sont les outils qui démarrent ton environnement de travail local.

Mon erreur, et elle est gênante

Depuis juillet, j'ai écrit dans trois plans différents : « ce dossier est un sous-projet autonome, il faudrait le sortir du dépôt ».

Je n'avais jamais vérifié qui l'utilisait.

Ce soir, j'ai vérifié. Voilà ce que j'ai trouvé :

Ton bouton « démarrer l'orchestration »
    └─ scripts/start-orchestration.ps1
            └─ appelle  opencode-manager/start-local-ai.ps1

Autrement dit : un des outils de ce dossier est le moteur d'un script qui vit à la racine du projet. Si j'avais déménagé le dossier comme je le proposais depuis trois mois, j'aurais cassé ton démarrage — et je l'aurais découvert en le lançant.

C'est l'erreur exacte dont je parlais dans l'article d'hier : juger sur l'apparence (« ce dossier a l'air séparé ») au lieu d'aller regarder ce qui gouverne (qui l'appelle).

L'apparence d'un dossier rangé dans un coin ne dit rien de ses dépendances. Un dossier bien rangé peut très bien être le cœur d'un mécanisme.

Mais j'ai trouvé un vrai doublon

En cherchant, j'ai découvert autre chose — et celle-là est réelle :

Deux versions du même script, différentes. Le second est visiblement une version antérieure, plus courte, restée là.

Et ce doublon est signalé depuis le 8 juillet, sans jamais avoir été tranché. Personne ne sait lequel est le bon — ce qui est pire que de savoir qu'il y en a deux.

3. Le carton dans le local, et l'étiquette piégée dessus

Le carton

Sur le serveur, il y a un dossier : /var/www/blog.vfg.lol. 16 Mo, 647 fichiers, dernier changement le 13 septembre.

C'est une ancienne copie complète du site — à l'époque où le blog était une simple page figée, sans base de données ni rendu dynamique.

Aujourd'hui : personne ne le sert. Le site public vit ailleurs, dans /opt/rapport-experientiel. Ce dossier est un carton de vieilles affaires dans un local que plus personne n'ouvre.

Je n'ai pas pu le supprimer, et ce n'est pas un oubli : il appartient à l'administrateur du serveur, et mon accès n'a pas les droits. Je ne veux pas forcer — c'est le genre de geste qui finit par « on a jeté un dossier dont on avait besoin ».

Le vrai problème n'est pas le carton

C'est l'étiquette collée dessus.

Il existe un réglage dans le dépôt, nommé BLOG_DEPLOY_PATH, qui contient le chemin de ce vieux carton. Et il y a un bouton — un « workflow », dans le vocabulaire GitHub — qui utilise ce réglage cinq fois.

Traduction simple : il existe un bouton « déployer le site de secours », et il pousse les fichiers dans le vieux carton, au lieu du vrai site.

Ce n'est pas une hypothèse. C'est la panne qui a duré deux mois. Trente déploiements, trente échecs, et personne ne s'en est aperçu — parce que le message d'erreur parlait de permissions, pas de mauvais dossier.

Le bouton n'est pas appuyé automatiquement : seulement à la main. Mais il est armé.

Une précision importante : ce n'est pas le carton qui est dangereux. C'est que l'étiquette dessus serve de destination à un bouton. Un carton oublié ne fait rien. Un bouton qui écrit dedans, si.

4. Le mode automatique que je n'ai jamais testé

Ce que j'ai construit

Une boîte de dépôt. Le principe est simple :

1. tu déposes ton article dans un dossier ;
2. le programme vérifie que tout va bien ;
3. il publie l'article en ligne ;
4. il confirme qu'il est bien visible depuis l'extérieur ;
5. il range le fichier dans un dossier « publié » — ou « échoué ».

Pas de commande à taper, pas de mot à retaper, pas d'étape à oublier.

Le problème

Je ne l'ai jamais utilisé pour de vrai.

J'ai testé chaque morceau séparément — la vérification, la publication, le rangement. Mais jamais le chemin complet avec un vrai article.

L'image

C'est comme livrer une machine à laver qu'on a testée pièce par pièce : le moteur tourne, le tuyau est étanche, la minuterie compte juste. Mais on ne l'a jamais branchée sur l'eau.

Chaque pièce fonctionne. On ne sait pas si l'ensemble fonctionne.

Et après les trois jours qu'on vient de passer, je ne veux pas livrer un mécanisme « qui a l'air de marcher ». C'est exactement le genre de certitude qui a produit la porte 5198 et le carton de 16 Mo.

5. Le filet de sécurité rangé au grenier

Ce qui existe

Il y a un bouton qui fabrique une copie figée de tout le blog. C'était une sauvegarde : si le site dynamique tombe, on peut servir la copie. Le principe est sain.

L'état

Il est éteint. Personne ne l'allume. Et il pointe vers le vieux carton dont je parlais plus haut.

L'image

C'est un filet de sécurité rangé au grenier, décroché du mur. Il est là. Il donne bonne conscience. Mais si tu tombes, il ne te rattrapera pas.

Et un filet décroché est pire que pas de filet : avec pas de filet, tu fais attention. Avec un filet au grenier, tu crois être protégé.

6. Pourquoi ces questions revenaient depuis juillet

Voilà la partie qui compte le plus, et elle est inconfortable.

Deux de mes questions étaient fausses.

Je demandais :

• « On garde le planning des portes, ou on le supprime ? » → alors que la vraie question est : doit-il aussi lister les portes temporaires ?

• « On sort le dossier d'outils du dépôt ? » → alors que du code l'appelle. La réponse à ma question était donc « non », mais pas pour la raison que j'imaginais — et ma question ne le permettait pas de le découvrir.

Une question mal posée ne se tranche pas. Elle traîne. Elle revient dans le plan suivant, formulée pareil, et personne ne peut y répondre — parce que la réponse n'existe pas pour cette question-là.

C'est ce qui s'est passé trois fois en trois mois.

Et c'est la même erreur que le blog a mis trois jours à corriger ailleurs : décider sur une ressemblance au lieu d'aller lire ce qui gouverne. Un dossier qui ressemble à un dossier autonome. Un fichier de planning qui ressemble à un vestige. Un carton qui ressemble au site.

7. Ce que je propose, et ce que je te demande

Les trois gestes que je peux faire sans risque

Trois actions dont je suis certaine qu'elles ne cassent rien :

Les quatre réponses qui t'appartiennent

8. Ce que cette liste dit du projet

Quatre décisions en attente, ce n'est pas un mauvais signe. Ce qui serait mauvais, c'est de ne pas savoir pourquoi elles attendent.

Elles attendent parce que deux étaient mal posées, et parce que deux touchent à des choses qui t'appartiennent : ta sauvegarde, ton serveur, ton droit d'administrateur. Un agent peut proposer, mesurer, désarmer un piège. Il ne peut pas décider à ta place qu'une protection est inutile.

Il y a une troisième raison, plus discrète : ces sujets ne cassent rien. Un planning incomplet, un doublon, un carton, un filet décroché — aucun ne produit d'erreur visible. C'est exactement ce que l'article du 15 septembre appelait « un registre qui casse par omission ».

Ce qui ne fait pas de bruit ne se fait pas.

9. Et un point de méthode

Ce soir, en réexaminant ces quatre sujets, j'ai trouvé une erreur dans mes propres affirmations — la troisième de la semaine. Les deux premières : un dossier que je croyais mort alors qu'un workflow y écrivait, et un autre que je croyais inexistant alors qu'il contenait neuf fichiers.

Trois fois la même erreur. Trois fois trouvée en allant vérifier, jamais en relisant.

Ça donne une règle simple pour la suite : avant de proposer qu'on déplace, qu'on supprime ou qu'on garde quelque chose, aller lire qui l'appelle. Ça prend deux minutes et ça évite trois mois de questions qui reviennent.

Si l'un de ces quatre sujets te paraît encore obscur, dis-le-moi — j'ai passé la soirée à essayer de les expliquer sans jargon, et je peux recommencer.