Aller au contenu

Zeno Suivi — Vue d'ensemble

Description

Zeno Suivi n'est ni une application ni un service : c'est une page HTML unique et statique (index.html, ~300 Ko, pas de framework), publiée directement par GitHub Pages depuis la branche main du dépôt. Elle sert de tableau de bord de suivi à Rachad et à l'équipe pour trois sujets : la réécriture Zeno V2, le CRM AEIG, et l'EDMS.

Il n'y a aucun backend, aucune base de données, aucune authentification, aucune variable d'environnement. Toutes les données vivent dans des objets JavaScript déclarés en tête du fichier HTML, ou dans deux fichiers JSON du dépôt injectés dans ce même fichier au moment du build.

Lire RULES.md avant toute modification

Le dépôt contient un RULES.md détaillé (11 règles) qui couvre le format exact des données, les règles de statut/CDC, le langage attendu selon la vue, et les étapes obligatoires après modification. Cette page en résume l'esprit mais ne le remplace pas — l'historique du dépôt montre plusieurs corrections de contenu qui auraient été évitées en le suivant (voir troubleshooting.md).

Les 5 vues, leur source, qui les édite

La page a cinq vues sélectionnées par onglet et par ancre d'URL (#chantiers, #avancement, #roadmap, #plan, #ressources).

Chantiers (#chantiers)

État de chaque chantier Zeno, CRM AEIG et EDMS : statut, disponibilité d'un cahier des charges (CDC), porteur, point bloquant, sous-tâches.

  • Source des données : objet PROJECTS, déclaré à la main dans le premier <script> d'index.html (ligne ~1847). Deux origines possibles pour une même affirmation — lecture directe du code, ou reprise du suivi Excel de Rachad — et RULES.md §2 impose que le champ comments précise systématiquement laquelle s'applique, pour ne jamais laisser croire à un audit qui n'a pas eu lieu.
  • Qui édite : Yémalin Modeste (ou tout contributeur qui a lu RULES.md), directement dans PROJECTS.
  • Règles de contenu notables (RULES.md §3-5) : status: 'bloque' signifie "inutilisable aujourd'hui", pas "a un défaut connu" — un chantier fonctionnel avec un point bloquant identifié reste 'fonctionnel' et porte un badge blocker visible à côté. cdc: 'oui' ne se coche que sur un document récent et vérifié, jamais sur un vieux .md d'architecture retrouvé dans un repo. Le texte visible (name, desc, comments, tasks[].label) doit rester lisible par un manager non technique — zéro jargon.
  • Après modification : node scripts/bake.mjs — voir Le mécanisme de « baking » ci-dessous.

Avancement V2 (#avancement)

Rapport direction de la réécriture Zeno V2 : pourcentage pondéré, 5 phases, date de fin estimée, messages clés. Vue calculée à partir de ROADMAP et du SNAPSHOT (plan de charge) — rien à éditer directement ici. Reste en langage direction, sans référence technique.

Roadmap V2 (#roadmap)

Les 5 phases et 39 chantiers de docs/architecture/ROADMAP_V2.md (dépôt Zeno), confrontés à l'état réel lu dans le code du dépôt aeig-plateform.

  • Source : objet ROADMAP, déclaré à la main dans un second <script id="roadmap-data"> (ligne ~2270).
  • Qui édite : à la main, RULES.md §10. Le champ real ('done' | 'partial' | 'none' | 'check') doit toujours refléter une lecture de code datée, jamais une supposition — quand un chantier est livré, on passe real à 'done' et on précise où (branche, dossier, date) dans note.
  • Lien avec le Plan de charge : un chantier se rattache à une demande par son numéro (roadmap: '2.3') ou ses tickets Plane (tk) — renuméroter un chantier sans mettre à jour les demandes de l'artifact casse ce lien silencieusement.
  • Après modification : rien à lancer (pas de copie statique pour cette vue), juste vérifier dans un navigateur.

Plan de charge (#plan)

Demandes en cours (tickets Plane + chantiers de la roadmap) affectées à une ressource, charge restante, échéancier par personne.

  • Source réelle : un artifact Claude externe, pas ce dépôt. Voir Dépendance externe ci-dessous.
  • Ce que contient le dépôt : uniquement un instantané (data/plan-snapshot.json), un export figé de la base de l'artifact à une date donnée. Toute modification faite dans l'artifact (affectation, statut, charge restante, capacité, réglages de calibrage) reste invisible sur GitHub Pages tant que cet instantané n'a pas été régénéré et republié.

Ressources (#ressources)

Qui a développé quoi depuis janvier 2026 (commits par module et par développeur), fiches par personne, frise chronologique, points d'attention.

  • Source : data/git-matrix.json, produit le 7 septembre 2026 à partir de l'historique git réel de Zeno (branche main, 7 janvier → 27 août 2026) et d'aeig-plateform (main et refacto, jusqu'au 17 août), en rattachant chaque commit à un module d'après les chemins de fichiers modifiés.
  • Cette vue est la seule qui dépend directement des dépôts de code réels qu'elle documente — pas de suivi Excel ni de saisie manuelle. C'est du minage d'historique git, pas une base de données vivante : il n'y a pas de mise à jour incrémentale, seulement des régénérations complètes.
  • Rafraîchir : demander à une session Claude Code (dans un clone du dépôt Zeno) de régénérer data/git-matrix.json avec la même structure et la même liste d'auteurs, puis node scripts/build.mjs. Limite connue : la frise est câblée sur 8 mois fixes (MONTH_LBL dans le code) — en ajouter un demande d'étendre cette liste.

Le mécanisme de « baking » — pourquoi ça compte

index.html contient deux copies du même contenu pour la vue Chantiers : le script JavaScript qui génère dynamiquement le HTML au chargement de la page, et une copie statique déjà rendue dans les <div id="summary">, <div id="modules">, etc.

Cette duplication n'est pas un accident ni une dette technique — elle existe parce que la page est régulièrement partagée par lien dans Gmail ou WhatsApp Web, deux contextes qui génèrent un aperçu de la page sans exécuter de JavaScript. Sans la copie statique, ces aperçus afficheraient une page vide, ce qui casse l'usage principal de l'outil (un lien qu'on partage pour montrer un état sans que le destinataire ait à cliquer).

node scripts/bake.mjs régénère cette copie statique à partir de PROJECTS (il charge le script d'index.html dans un bac à sable Node minimal, avec des éléments DOM factices, pour ré-exécuter les mêmes fonctions de rendu que le navigateur). C'est pourquoi il faut le relancer après chaque modification de PROJECTS — sans ça, le code source est à jour mais ce que les gens voient réellement dans un aperçu sans JS reste périmé.

Dépendance externe : l'artifact Claude « Plan de charge »

La vue Plan de charge, et dans une moindre mesure les colonnes Ressources/Fin estimée d'Avancement V2 et les fiches de capacité de Ressources, dépendent d'un artifact Claude externe intitulé « Plan de charge Zeno » (lien visible dans la bannière de ces vues sur la page publiée, et codé en dur dans index.html sous ARTIFACT_URL).

Cet artifact héberge une base partagée (collections demandes, resources, réglages settings/plan) où les affectations, statuts, charges restantes et capacités sont modifiables et enregistrés pour tous les lecteurs de l'artifact — c'est là que se fait l'édition réelle du plan de charge, pas dans ce dépôt.

Dépendance externe informelle, pas un compte technique

Ce n'est pas une base de données ni un service avec des identifiants classiques — c'est un artifact Claude, dont l'accès en édition dépend de qui peut l'ouvrir et le modifier dans Claude. Si Yémalin est seul à avoir ce lien et les droits dessus, personne d'autre ne peut éditer le plan de charge ni republier un instantané à jour. Voir continuite-acces-externes.md pour ce qui reste à vérifier/transmettre à Cédric Gnansounou sur ce point précis.

Pour republier l'instantané depuis une session Claude Code (RULES.md §9) :

  1. Exporter la base de l'artifact (outil Artifact, read_db, db_op: list, sur demandes et resources, puis get sur settings/plan) dans un dossier local.
  2. node scripts/snapshot-from-dump.mjs <dossier> → écrit data/plan-snapshot.json avec la date d'export.
  3. node scripts/build.mjs → injecte le snapshot (et la matrice git) dans index.html, relance bake.mjs.
  4. Vérifier les cinq onglets dans un navigateur, puis committer index.html et data/plan-snapshot.json.

Ce qu'il ne faut jamais faire (RULES.md §9) : ré-amorcer la base de l'artifact depuis Plane (les écritures set écrasent les affectations faites à la main), ou éditer le bloc généré SNAPSHOT directement dans index.html (perdu au prochain build.mjs).

Relation avec les vrais dépôts de code (Zeno, aeig-plateform)

Zeno Suivi ne contient aucun code applicatif — il rapporte sur deux autres dépôts :

  • Zeno — le dépôt applicatif dont ce dépôt suit la réécriture V2 ; docs/architecture/ROADMAP_V2.md y vit et sert de base à l'objet ROADMAP.
  • aeig-plateform — le dépôt du CRM AEIG ; son historique git alimente data/git-matrix.json (bloc v2), et son code réel sert à vérifier les affirmations real de la roadmap.

Les affirmations de ce dépôt ne sont donc fiables que si elles ont été vérifiées contre le code de ces deux dépôts — RULES.md §2 en fait une règle explicite (toujours dire si une affirmation vient d'une lecture de code ou d'un simple report du suivi Excel de Rachad).