Zeno Suivi — Erreurs courantes¶

Il n'y a pas de panne technique possible ici au sens classique (pas de serveur, pas de service tiers qui répond mal) — le risque principal de ce projet, montré par son propre historique git, est le contenu lui-même qui devient faux ou contradictoire parce que c'est une page à jour manuelle. Cette page recense les incidents réels (identifiés par leur commit) pour que le prochain mainteneur reconnaisse le schéma plutôt que de le redécouvrir.

Schéma n°1 : une affirmation reste affichée après avoir cessé d'être vraie¶

Le cas le plus fréquent : un texte libre (comments, note de bandeau, description) décrit un état qui a changé entre-temps, et personne ne l'a remis à jour au moment du changement.

7b96b7a — « rédaction des specs en cours » est faux depuis le 19 août : le texte affirmait un travail en cours alors qu'il était terminé depuis près de trois semaines.
bfe889f — le bandeau contredisait la page, les 4 marques faisaient peur : le message d'en-tête (lu en premier) racontait une version différente du détail des chantiers juste en dessous.
f47b34b — lève la contradiction apparente sur Digital Valley : deux endroits de la page donnaient une lecture incompatible du même sujet.
e6f7a4b — corrige la vision CRM AEIG — un seul Zeno multi-marques scopé, pas une instance séparée par marque : une erreur de fond sur l'architecture cible, pas juste une formulation datée.

Comment l'éviter : à chaque modification d'un chantier, se demander explicitement "est-ce que ce texte reste vrai si je ne le retouche pas pendant deux semaines ?" — et surtout, quand un fait change (specs terminées, décision d'architecture actée), grep rapidement les autres endroits de la page qui pourraient répéter l'ancienne version (bandeau, comments d'un chantier lié, note de la roadmap) au lieu de ne corriger que l'endroit qu'on a sous les yeux.

Schéma n°2 : doublons et entrées à fusionner¶

f7b01ea — fusionne les deux entrées Portail parent en une seule : le même chantier existait sous deux entrées distinctes dans PROJECTS, avec un risque que les deux dérivent différemment.
a6cdc0b — découpe la plateforme en 3 chantiers lisibles (sens inverse : un chantier trop large a été éclaté pour rester lisible).

Comment l'éviter : avant d'ajouter un nouveau chantier, vérifier qu'il n'existe pas déjà sous un autre nom ou dans un autre projet — RULES.md §7 rappelle qu'un nouvel onglet de projet ne se justifie que si le code/l'équipe/le repo sont réellement distincts, pas parce que le sujet paraît important.

Schéma n°3 : `status`/`cdc` mal calibrés¶

b3996ea puis f5ebaa9 — la règle elle-même a dû être corrigée : une première version disait qu'un blocage réel force le statut à Bloqué ; f5ebaa9 (« corrige RULES.md — un blocage réel ne force pas le statut à Bloqué, il se voit via le badge ») est revenu dessus, parce que ça faisait passer des outils réellement utilisés pour "non utilisables". C'est devenu RULES.md §3 (statut = "est-ce que ça sert aujourd'hui", blocker = badge séparé pour "pourquoi c'est imparfait").
12c1c92 — renomme Pédagogie — Étudiant & APE en Portail étudiant (pas de CDC, périmètre à clarifier) : un CDC déclaré 'oui' a dû être révisé.

Comment l'éviter : relire RULES.md §3 et §4 avant de trancher un statut ou un CDC, surtout en cas de doute — dans le doute, 'partiel'/'non' plutôt qu'un 'oui'/'fonctionnel' optimiste que quelqu'un devra corriger plus tard.

Schéma n°4 : liens cassés après renommage¶

6fb1ca2 — redirige les liens vers le chantier renommé : renommer un chantier (clé ou libellé) casse silencieusement ce qui pointe vers lui ailleurs dans la page (renvois, éventuellement le lien roadmap: 'x.y' côté Plan de charge — voir RULES.md §10).

Comment l'éviter : après un renommage, grep le nom/la clé de l'ancien chantier dans tout index.html avant de committer, pas seulement dans la section qu'on vient d'éditer.

Schéma n°5 : données régénérées sur la mauvaise base¶

ed31657 — régénère l'historique git sur origin/main, étend à septembre : la matrice data/git-matrix.json avait été construite sur une base git incomplète ou obsolète (branche/portée pas à jour) et a dû être refaite.

Comment l'éviter : en régénérant data/git-matrix.json (RULES.md §11), vérifier explicitement qu'on part bien d'origin/main à jour (git fetch avant) et pas d'une copie locale en retard, et que la période couverte est étendue jusqu'à la date réelle de régénération.

Schéma n°6 : incohérence de noms de personnes¶

81be613 — uniformise le nom Franck Birba partout dans le suivi : la même personne apparaissait sous des orthographes/formats différents selon les endroits (owner, support, notes), ce qui casse en pratique le regroupement par personne dans la vue Ressources.

Comment l'éviter : réutiliser exactement la même chaîne de nom que celle déjà présente ailleurs dans PROJECTS/ROADMAP plutôt que de retaper à la main — un grep -o rapide du prénom dans index.html avant d'ajouter une nouvelle entrée suffit à repérer la variante existante.

Ce que ce n'est pas¶

Il n'y a pas ici d'incident d'infrastructure à diagnostiquer (pas de conteneur, pas de base de données, pas de clé API qui expire). Le seul point technique externe à surveiller est la disponibilité de GitHub Pages elle-même et la synchronisation de l'instantané du plan de charge avec l'artifact Claude — voir diagnostics.md.