# Décisions de conception

Ce document garde la trace des arbitrages et surtout de leurs raisons, pour éviter de refaire les
mêmes débats dans six mois.

## 1. Pourquoi un outil sur-mesure

Les suites complètes (Redmine, Taiga, OpenProject) exigent un serveur applicatif et une base de
données à administrer — hors de proportion avec le besoin. Les mini-outils « un seul fichier HTML »
sont des Kanban sans dates.

[Markwhen](https://markwhen.com) est le concurrent sérieux : timeline en couloirs engendrée depuis du
texte markdown-ish, open source, self-hostable, avec extension VS Code et vue Gantt. Il couvre une
bonne partie du besoin.

Deux choses manquent, et ce sont elles qui justifient ce projet :

- la **manipulation directe** des barres (glisser, redimensionner) ;
- le **suivi de dérive** face à un planning de référence figé.

Si ces deux besoins disparaissaient, il faudrait sérieusement envisager d'abandonner cet outil au
profit de Markwhen.

## 2. Pas de dépendances entre phases

Une première version du cahier des charges prévoyait des dépendances fin→début avec propagation en
cascade. Abandonné.

Le coût est très supérieur à ce qu'il paraît : graphe orienté, détection de cycles, et surtout une
sémantique de propagation à trancher — la poussée est-elle une contrainte dure ou souple, la marge
existante est-elle conservée, avancer un prédécesseur tire-t-il ses successeurs en arrière, que
faire d'une date imposée de l'extérieur. Chacune de ces questions a plusieurs réponses défendables,
et se tromper produit un outil qui déplace des barres dans le dos de l'utilisateur.

En regard, le bénéfice réel en planification macro est faible. Le besoin concret — « ce projet glisse
d'un mois » — se traite en décalant les phases concernées à la main, ce qui prend quelques secondes
sur un projet de cinq ou six phases.

**Conséquence heureuse** : sans flèches à tracer entre les barres, le SVG perd sa raison d'être (voir
décision 4).

## 3. Micro-serveur Python plutôt que File System Access API

La première approche envisagée était d'écrire directement dans le fichier depuis le navigateur, via
`showOpenFilePicker` / `createWritable`, pour se passer de tout back-end.

> **Rectification (1ᵉʳ août 2026).** Le paragraphe suivant affirmait que l'API « ne fonctionne pas
> depuis `file://` ». C'est faux, et la vérification sur Chromium 150 le montre : `file://` **est**
> un contexte sécurisé (`isSecureContext === true`), `showSaveFilePicker` y ouvre bien son
> dialogue, et `localStorage` comme IndexedDB y persistent d'une session à l'autre — un handle
> peut donc y être mémorisé. Ce qui bloque réellement en `file://`, c'est autre chose : les
> **modules ES** et `fetch` y sont interdits par CORS (origine `null`), donc c'est la décision 10
> qui ferme cette voie, pas la sécurité de l'API. La conclusion ci-dessous — lancer un serveur —
> reste la bonne, mais pour ce motif-là. Voir décision 22.

Cette API exige un **contexte sécurisé**, et l'on avait cru qu'elle ne fonctionnait pas depuis
`file://`. Il fallait donc de toute façon lancer un serveur statique. Le « zéro back-end » était
perdu d'avance, tout en payant trois prix : limitation aux navigateurs Chromium, re-autorisation du
sélecteur de fichier à chaque session, et maintien d'un chemin de repli export/import pour Firefox
et Safari, doublé d'un miroir `localStorage`.

Puisqu'une commande doit être lancée dans tous les cas, autant qu'elle serve à quelque chose. Un
serveur de la bibliothèque standard, `GET` et `PUT` sur `/api/data`, tient en une centaine de lignes
— soit **moins** de code que l'API navigateur plus son repli plus son miroir. Et il fonctionne
partout, sans sélecteur à réautoriser.

Bénéfice supplémentaire : le serveur peut écrire une sauvegarde horodatée, ce que la File System
Access API ne permettait pas simplement. Elle l'était alors à chaque écriture ; son rythme a depuis
changé, voir décision 23.

## 4. DOM et CSS plutôt que SVG

Le SVG s'imposait tant qu'il fallait tracer des flèches courbes entre des barres. Les dépendances
supprimées, il ne reste que des rectangles, du texte et des losanges.

Des `div` positionnées en absolu font tout cela plus simplement : troncature du texte par
`text-overflow`, curseurs de redimensionnement, styles de survol, transitions, tout est natif en CSS.
En SVG il faudrait mesurer le texte à la main et réimplémenter des comportements que le navigateur
offre gratuitement. Les losanges de jalon se font par une rotation CSS de 45°.

## 5. Identifiants parlants plutôt qu'UUID

Le fichier de données est censé rester ouvrable dans un éditeur de texte et versionné dans git. Des
UUID rendent les deux pénibles : impossible de savoir quelle phase on lit, et un diff illisible.

`site-web` et `cadrage` coûtent la même chose à manipuler et gardent le fichier compréhensible. La
contrepartie — gérer les collisions à la création — est traitée par un suffixe numérique.

Un identifiant ne change **jamais** quand le nom est modifié : il identifie, il ne décrit pas.
Renommer une phase ne doit pas invalider les références qui pointent vers elle.

## 6. Statut plutôt que pourcentage d'avancement

Un pourcentage d'avancement sur une phase macro de plusieurs semaines est presque toujours un chiffre
inventé, et il donne une fausse impression de précision. Quatre statuts — à venir, en cours, terminé,
bloqué — se saisissent en un clic et disent l'essentiel. `blocked` en particulier porte une
information qu'un pourcentage ne peut pas exprimer.

## 7. Jours calendaires

Gérer les jours ouvrés impose de faire passer chaque calcul de date par un helper, et soulève
aussitôt la question des congés et des jours fériés — donc un calendrier à tenir à jour. Sur des
phases qui se comptent en semaines et en mois, l'écart est dans le bruit de l'estimation.

## 8. La barre cumulative repousse le projet

La ligne d'un projet porte une barre unique segmentée par phase, qui donne sa forme d'ensemble. Elle
se glisse, et le projet entier se décale avec elle.

**Ce n'était pas le cas au départ, et le motif du refus mérite d'être conservé** : la même barre
représenterait tantôt une phase, tantôt un projet entier, et un glissement de quelques pixels
déplacerait alors plusieurs mois de travail d'un coup, sans qu'on voie ce qui bouge. L'argument était
juste ; c'est le premier usage réel de l'outil qui l'a renversé. Un projet engagé glisse dans le
temps — c'est même la chose qui arrive le plus souvent —, et le faire glisser phase par phase oblige
à répéter le même geste cinq fois en priant pour que les écarts se conservent. Or ils ne se
conservent pas : chaque phase s'accroche à son propre lundi, et un projet ainsi déplacé se
déforme un peu à chaque passage.

L'objection d'origine n'a pas été balayée, elle a été traitée :

- **Les barres de phase suivent le résumé pendant le geste.** On voit exactement ce qu'on déplace
  pendant qu'on le déplace, y compris plié — où les segments colorés de la barre suffisent à le
  montrer. C'était le cœur du reproche, et il tombe.
- **Le delta est calculé une fois, sur la première phase qui bouge, puis appliqué tel quel
  partout.** Les écarts entre phases sont conservés au jour près : le projet est repoussé, il n'est
  pas replanifié. C'est précisément ce que le geste phase par phase ne savait pas faire.
- **La référence figée ne suit pas.** Repousser de trois semaines affiche aussitôt une dérive de
  trois semaines. Le geste ne cache pas ce qu'il coûte, il l'inscrit.

### Ce qui est fait est fait

Une phase `done` ne bouge pas. Décaler un projet, c'est reconnaître qu'il prendra plus de temps que
prévu, et emporter les phases terminées réécrirait un passé qu'on a vécu — en effaçant du même coup
la dérive qu'on cherche à lire.

Le geste ne « déplace » donc pas toujours : sur un projet à moitié fait, la barre s'**étire**, son
bord gauche tient et le reste s'en va. C'est assumé, et c'est même ce qu'on veut voir. Le résumé se
repose alors depuis le modèle à chaque mouvement de souris plutôt que d'être translaté, faute de quoi
l'aperçu et le résultat divergeraient.

Le critère est le **statut**, jamais la position dans le calendrier : une phase terminée en avance
reste où elle est, une phase `blocked` ou `doing` déjà commencée se décale avec le reste — c'est bien
elle qui glisse. Un projet dont toutes les phases sont closes n'a rien à repousser : sa barre perd
son `data-role`, garde le curseur par défaut, et le dit dans son infobulle plutôt que d'offrir une
prise qui ne mènerait nulle part.

Rien n'empêche un décalage vers l'arrière de faire chevaucher une phase avec une phase terminée. Il
n'y a pas de dépendances entre phases dans ce modèle (section 2) et poser ici une butée en
inventerait une par la bande.

### Pas de poignées

La barre cumulative se déplace, elle ne se redimensionne pas. Étirer un projet supposerait de dilater
chaque phase au prorata, avec des arrondis qui déforment les durées courtes et un résultat qu'on ne
peut pas prévoir avant de l'avoir vu. C'est un autre besoin, et il attendra de se présenter.

Le même geste existe au clavier : sur la ligne d'un projet, `←` et `→` le repoussent d'un jour, là où
elles ne faisaient rien. `Maj` n'y ajoute rien, pour la raison qui précède.

### Ce qui n'a pas changé

**Elle est affichée que le projet soit plié ou déplié.** Elle ne l'était d'abord qu'en mode plié, ce
qui obligeait à replier pour savoir où en était le projet entier — donc à perdre la vue qu'on était
en train d'éditer.

**Et elle est rendue à l'identique dans les deux cas.** Une première version l'épaississait en mode
plié, au motif qu'elle y était seule sur sa ligne. C'était une erreur : plier un couloir ne change
rien à ce que cette barre représente, et la voir changer d'aspect au pli laissait croire à deux
objets différents. Elle garde donc partout la même hauteur, plus mince qu'une barre de phase —
puisqu'elle voisine avec elles dès que le projet est déplié. Le fantôme de référence se cale dessous,
d'où sa variante `--cumulatif`. Étant mince, elle se repère mal une fois saisie : un anneau à sa
couleur la décolle du couloir le temps du geste, sans toucher à sa géométrie, ce qui décalerait ce
qu'on est en train de viser.

## 9. Accroche à la semaine

Au zoom trimestre, un jour représente quelques pixels : viser une date précise à la souris devient
un exercice de patience. L'accroche au lundi rend le geste franc et correspond à la granularité
réelle d'une planification macro.

Les dates exactes restent saisissables au clavier dans le panneau de détail, ce qui couvre les cas
où une phase doit démarrer un jeudi précis.

## 10. Zéro build

Modules ES natifs, chargés directement par le navigateur. Pas de `package.json`, pas de bundler, pas
de `node_modules`. Le fichier qu'on lit dans l'éditeur est exactement celui qu'exécute le navigateur,
ce qui rend le débogage direct et l'outil reprenable dans plusieurs années sans exhumer une chaîne de
compilation obsolète.

Node n'est utilisé que pour lancer les tests, via son lanceur intégré (`node --test`), sans aucune
dépendance.

**Portée après la décision 22.** Le serveur se compile désormais, mais le front, lui, ne se
compile toujours pas : aucun bundler, aucune transformation, aucun `node_modules`. Les fichiers de
`js/` sont embarqués tels quels dans le binaire et servis tels quels au navigateur — c'est bien la
ligne qu'on lit dans l'éditeur qui s'exécute, et `--dev` les sert directement depuis le disque.
Ce qui était visé ici est donc intact ; ce qui change, c'est seulement la façon dont le serveur est
distribué.

## 11. Un en-tête à trois bandes, la semaine pour grain le plus fin

L'en-tête affichait une seule rangée de graduations dont le contenu changeait selon le
zoom : des quantièmes en vue semaine, des noms de mois en vue trimestre. Il fallait
deviner l'unité affichée, et l'année n'apparaissait qu'au zoom le plus large.

Trois bandes empilées — **année**, **mois**, **numéro de semaine ISO** — lèvent
l'ambiguïté : les trois repères sont toujours là, quel que soit le zoom. Chaque cellule
est un bloc couvrant exactement son intervalle, ce qui centre le libellé sur la période
qu'il désigne au lieu de le laisser flotter après un trait.

Le jour a disparu : sur des phases qui se comptent en semaines, il n'apportait rien et
encombrait l'affichage. Le zoom ne change donc plus l'unité, seulement la largeur des
mêmes semaines.

Les numéros suivent l'**ISO 8601** : la semaine appartient à l'année où tombe son jeudi.
C'est pourquoi `semaineISO()` renvoie l'année en même temps que le numéro — afficher
« S53 » sous un bandeau « 2027 » serait faux, alors que le 1er janvier 2027 est bien en
semaine 53 de 2026.

## 12. Défilement natif sur les deux axes plutôt que synchronisé en JavaScript

La colonne des libellés était un conteneur séparé, recalé sur le défilement vertical de
la frise par un `translateY` appliqué à chaque événement `scroll`. Deux défauts : un
décalage visible d'une image sur les défilements rapides, et deux systèmes de coordonnées
à tenir cohérents.

Tout tient désormais dans un unique conteneur défilant, découpé en grille 2×2 : l'en-tête
est `sticky top`, la colonne des libellés `sticky left`, et le coin les deux à la fois. Le
navigateur gère seul le défilement des deux axes. Le code de synchronisation a disparu.

## 13. Menu contextuel plutôt que `prompt()` et `confirm()`

Les actions d'un projet passaient par un `prompt()` listant des numéros d'action à saisir
au clavier, et les suppressions par un `confirm()`. C'était rapide à écrire et pénible à
utiliser : rien n'indiquait qu'il fallait cliquer sur le nom du projet, et ces boîtes
natives bloquent le fil d'exécution.

Un bouton `⋯` explicite ouvre maintenant un vrai menu, navigable au clavier, où les
actions indisponibles sont grisées plutôt qu'absentes — « Retirer la référence » reste
visible quand aucune référence n'est figée, ce qui apprend que la fonction existe.

Les dialogues s'appuient sur l'élément `<dialog>` natif, qui fournit le voile, le piège à
focus, la fermeture par Échap et la restauration du focus sans code supplémentaire. Sur
une action destructrice, le focus initial se pose sur « Annuler » : un appui réflexe sur
Entrée ne doit rien détruire.

Une exception assumée : ajouter une phase ne demande pas son nom dans un dialogue. La
phase est créée immédiatement à la suite de la précédente, et le panneau de détail
s'ouvre avec le nom présélectionné — l'utilisateur tape simplement par-dessus. Un
dialogue de plus n'aurait rien apporté.

## 14. Une seule échelle, pas de zoom

Trois niveaux de zoom — semaine, mois, trimestre — étaient proposés. Retirés.

Depuis que l'en-tête empile l'année, le mois et le numéro de semaine (décision 11), les
trois repères utiles sont lisibles en permanence. Le zoom ne résolvait plus qu'un problème
qu'il avait lui-même créé : savoir quelle unité on regardait. Il restait un réglage de
plus à comprendre, un état de plus à gérer, et un chemin de code de plus à tester.

L'échelle unique est de **6 pixels par jour**, soit 42 pixels par semaine : assez pour que
« S32 » tienne dans sa cellule, assez serré pour qu'une année tienne dans une fenêtre de
portable.

## 15. Une frise qui s'élargit au défilement

La fenêtre affichée se déduisait des bornes des phases existantes, avec une marge fixe.
Conséquence gênante : impossible d'aller regarder un futur vide pour y planifier. La frise
s'arrêtait là où s'arrêtaient les données.

La fenêtre est désormais un **état de vue** distinct des données. Elle démarre autour des
phases existantes, puis s'élargit de six mois dès que le défilement passe à moins de
400 pixels d'un bord. On peut ainsi partir vers 2031, y poser une phase, et revenir.

Deux subtilités :

- **Élargir vers la gauche déplace l'origine de l'échelle**, donc tout le contenu se
  décale vers la droite. On compense `scrollLeft` de la même quantité, sans quoi la vue
  sauterait en arrière à chaque élargissement. Un drapeau empêche l'ajustement de
  relancer le gestionnaire de défilement.
- **La fenêtre ne rétrécit jamais**, même si les phases se resserrent : le terrain déjà
  exploré doit rester atteignable.

L'élargissement s'arrête à **dix ans de part et d'autre des données**. Ce n'est donc pas
infini au sens strict — c'est un garde-fou : rien n'est virtualisé, et un défilement
prolongé ferait autrement enfler le DOM sans limite. À l'échelle d'une planification
macro, dix ans dépassent largement l'horizon utile.

Corollaire : le recentrage est instantané, jamais animé. Sur une frise qui peut atteindre
plusieurs dizaines de milliers de pixels, une animation serait lente, et le gestionnaire
de défilement l'interromprait en élargissant la fenêtre au passage près d'un bord.

Attention en modifiant `centrerSur` : `scrollLeft` porte sur la grille entière, dont la
première colonne est celle des libellés. Comme elle est `sticky`, elle masque en
permanence les premiers pixels de la vue, et le centre utile des couloirs est décalé
d'une demi-largeur de colonne par rapport au centre de la frise.

## 16. Tags libres et filtre conjonctif

Passé une dizaine de projets, la frise devient un mur : on veut n'y voir que les projets
clients, ou que ceux d'un pôle. D'où des **tags** sur le projet, et un filtre.

**Étiquettes libres, pas de référentiel.** Aucune liste de tags autorisés n'est tenue
quelque part : les tags disponibles sont ceux que portent les projets, et un tag disparaît
de la barre de filtres dès qu'il n'orne plus rien. Un référentiel séparé aurait exigé une
interface pour le gérer, et se serait désynchronisé. La contrepartie — la dérive
orthographique, « client », « Clients », « client final » — est traitée par deux gardes :
la comparaison ignore la casse, et le dialogue d'un projet propose en un clic les tags déjà
employés ailleurs.

**Le filtre exige *tous* les tags cochés**, pas au moins un. Cocher un tag de plus resserre
donc toujours la sélection : on part du tout et on élague, sans jamais voir la frise se
repeupler en cochant. La disjonction se comporte à l'inverse, et il faut alors relire la
liste des tags actifs pour savoir dans quel sens la prochaine case va jouer.

**Le filtre n'est pas enregistré.** C'est un état de vue, comme la fenêtre temporelle
(décision 15) : un filtre qui survivrait au rechargement rouvrirait le planning amputé sans
qu'on se souvienne pourquoi. Le masquage d'un projet (`hidden`), lui, est bien enregistré —
et les deux ne font pas la même chose :

| | Filtre par tags | Masquage (`hidden`) |
|---|---|---|
| Portée | La vue entière, libellé compris | Les barres seules, le libellé reste grisé |
| Durée de vie | La session | Enregistré dans le fichier |
| Question posée | « Je ne regarde que les projets clients » | « Ce projet existe, mais il encombre ma frise » |

Le masquage n'a plus de bouton dédié dans la colonne : voir décision 20.

**La couleur d'un tag est calculée, pas choisie** : une teinte HSL dérivée du nom par
hachage. Rien à stocker, rien à saisir, et le même tag garde sa couleur partout. Des
collisions de teinte sont possibles et sans gravité — le nom est toujours écrit à côté.

**Un tag trop long est tronqué, pas refusé.** Contrairement à une date invalide, qui bloque
le chargement en nommant le fautif, la longueur d'un tag est cosmétique : refuser d'ouvrir
un planning entier pour un libellé bavard serait disproportionné. La limite est donc
appliquée en normalisant, ce qui la rend vraie par construction — aussi bien pour un fichier
édité à la main que pour une saisie dans le dialogue.

Créer un projet alors qu'un filtre est actif **préremplit ses tags** avec ceux du filtre :
sans cela, le nouveau venu naîtrait invisible, hors de la vue depuis laquelle on vient de le
demander.

## 17. Le panneau de détail n'est pas modal

Le panneau s'ouvrait derrière un voile couvrant toute la page. L'intention était
raisonnable — concentrer l'attention sur la phase en cours d'édition —, mais elle
allait contre ce que fait un outil de frise : on y compare, on passe d'une phase à
la suivante, on ajuste en regardant le voisinage.

Trois conséquences, dont deux invisibles à la lecture du code :

- passer d'une phase à l'autre imposait fermer, cliquer, rouvrir, alors que c'est
  le geste le plus fréquent de l'outil ;
- le raccourci `←` `→` était **inatteignable**. Le panneau plaçait le focus dans
  le champ « Nom », et `app.js` ignore les flèches quand la frappe part dans un
  `input` — pour en sortir il aurait fallu cliquer ailleurs, ce que le voile
  interdisait précisément ;
- le rafraîchissement du panneau depuis la frise, prévu pour qu'un glisser se
  reflète dans les champs, ne pouvait jamais se produire à la souris.

Le voile a donc disparu. Le panneau reste posé sur le bord droit, la frise
continue de vivre derrière lui, et cliquer une autre barre y bascule la
sélection. Le focus se pose sur le panneau lui-même — assez pour que le clavier
le suive, pas assez pour capturer les flèches. Le champ « Nom » n'est
présélectionné que pour une phase fraîchement créée, dont le nom provisoire est
justement là pour être écrasé.

**Cliquer à côté ferme quand même.** C'était le seul service que rendait le
voile, et il ne valait pas la frise inerte qu'il coûtait. Un écouteur sur
`document` le rend sans calque : il ferme les panneaux au `pointerdown`, sauf
sur deux familles de cibles.

- Les **surfaces protégées** — un panneau, le menu, un dialogue, la poignée de
  colonne — où l'on est manifestement au travail.
- Les **cibles ouvrantes** : une barre, une poignée de barre, un libellé de
  phase, tout élément portant `data-action`. Leur propre gestionnaire ouvre déjà
  le bon panneau, et les faire passer par la fermeture générale serait pire
  qu'inutile : celle-ci redessine la frise, ce qui détacherait du DOM l'élément
  visé avant que son gestionnaire — ou le glisser qui commence peut-être — n'ait
  fini. C'est aussi pourquoi `fermer()` sort tout de suite quand le panneau est
  déjà fermé : sans cette garde, chaque clic dans le vide relancerait un rendu
  complet.

Échap et la croix restent les deux autres façons de fermer.

## 18. La colonne des libellés est redimensionnable

La colonne portait, sur 250 pixels fixes, le triangle de pli, le nom, les tags,
l'étiquette de dérive, l'œil et le menu. Sur le jeu d'exemple, il ne restait que
**56 pixels au nom** : « Refonte du site web » s'affichait « Refon… », pendant que
« client » se réduisait à « c. ». Le pire des deux mondes — des pastilles qui
occupaient la place d'un tag sans en livrer le nom.

Trois corrections, dans l'ordre de leur rendement :

- **Les commandes passent en surimpression**, révélées au survol de la ligne.
  Ce sont des actions occasionnelles ; elles coûtaient soixante pixels en
  permanence à une information lue en continu. Elles sont posées en `absolute`,
  et non retirées du flux au repos, pour que rien ne se déplace à l'approche du
  curseur. Elles restent visibles sans survol sur un projet masqué, seul chemin
  pour le rétablir.
- **Les tags cèdent en bloc plutôt que de rétrécir.** Deux pastilles au plus,
  puis un compteur `+N` dont l'infobulle donne les manquants. Un tag présent dans
  le filtre courant passe devant : c'est lui qui explique la présence du projet à
  l'écran, il ne doit pas tomber dans le compteur.
- **Le nom cède en dernier**, et pas en deçà de sept caractères.

Restait qu'aucune largeur ne convient à la fois à « Site web » et à « Refonte du
portail fournisseurs — lot 2 ». D'où une poignée dans le coin de la grille —
seul point de la colonne qui reste visible quel que soit le défilement —, avec
double-clic pour revenir au défaut et flèches au clavier.

**Cette largeur est conservée, dans `localStorage`.** C'est la première entorse à
la règle des décisions 15 et 16, où les états de vue meurent avec la session, et
elle est délibérée : la fenêtre temporelle et le filtre décrivent *ce qu'on
regarde*, une largeur de colonne décrit *l'écran sur lequel on regarde*. La
placer dans le planning imposerait à un portable la largeur choisie sur un
27 pouces ; ne pas la garder du tout obligerait à réajuster la poignée à chaque
ouverture, ce qui la rendrait inutile. `localStorage` est exactement le bon
rangement : local à la machine, hors des données.

## 19. Le nom d'une phase reste accroché au bord visible

Le libellé d'une barre était écrit à son bord gauche. Une phase de plusieurs mois
dont le début sortait de l'écran occupait donc toute la largeur de la vue sans
qu'on puisse lire son nom, parti sous la colonne des libellés.

Le nom vit désormais dans son propre élément, en `position: sticky`, calé sur la
largeur de la colonne — c'est-à-dire sur le premier pixel réellement visible de
la frise. Trois détails le rendent possible, et aucun n'est cosmétique :

- un `overflow: hidden` sur la barre en aurait fait le conteneur défilant de
  référence, et le décalage n'aurait plus eu lieu. Le rognage du texte trop long
  est donc porté par le nom lui-même, pas par la barre ;
- le décalage est plafonné par la boîte du parent, ce qui garantit que le nom ne
  sort jamais de sa barre — d'où `inline-block`, qui laisse au texte la marge de
  manœuvre qu'un bloc pleine largeur n'aurait pas ;
- quand le nom occupe presque toute sa barre, la marge s'épuise et il finit par
  s'enfoncer sous la colonne. On lit alors sa fin plutôt que rien, ce qui reste
  un progrès, et la colonne des libellés donne de toute façon le nom entier.

## 20. Ce que porte la ligne d'un projet

Trois commandes s'y étaient accumulées sans qu'on se demande si chacune méritait
sa place. Le tri s'est fait sur une seule question : cette action est-elle assez
fréquente pour valoir un bouton permanent ?

**L'œil disparaît.** Il faisait doublon avec l'entrée « Masquer de la frise » du
menu, qui reste. Le masquage est une décision durable sur un projet — on le pose
une fois et on l'oublie — pas un geste qu'on refait dix fois par séance. Depuis
que les tags existent (décision 16), c'est d'ailleurs le filtre qui répond au
besoin courant de dégager la vue. La fonction demeure, elle ne coûte simplement
plus de pixels à tout le monde en permanence. Le format de données est inchangé :
`hidden` reste un champ du projet.

**Le `+` apparaît.** Ajouter une phase est l'action la plus fréquente de l'outil,
et elle était enterrée dans un menu.

**Le nom du projet devient cliquable.** Il portait déjà `cursor: pointer` sans
qu'aucune action n'y réponde — un curseur qui promet et ne tient pas. Il ouvre
maintenant le dialogue des paramètres, ce que la main annonçait.

**Il n'y a plus de commande « Ajouter un jalon ».** Un jalon n'est pas un autre
objet : c'est une phase dont la fin rejoint le début, soit une case à cocher du
panneau au même titre que le statut. Deux entrées de menu obligeaient à trancher
avant d'avoir rien saisi, alors que la bascule reste possible ensuite dans les
deux sens. Une seule commande crée une phase ; on coche « Jalon » si c'en est un.

## 21. Un projet s'édite comme une phase

Les paramètres d'un projet — nom, couleur, tags — passaient par un `<dialog>`
modal à valider, quand ceux d'une phase s'éditaient dans un panneau latéral au
fil de la saisie. Deux formes pour la même opération à un niveau de granularité
près, avec deux modèles mentaux à tenir : ici on tape et ça s'applique, là on
tape et il faut confirmer.

Les projets ont rejoint le panneau (`js/projet.js`, jumeau de `js/detail.js`).
Même en-tête, même édition en direct, même bouton de suppression au bas du
formulaire. Les deux panneaux occupent le même bord de l'écran : ouvrir l'un
ferme l'autre.

**« Nouveau projet » ne demande donc plus rien.** Le projet est créé aussitôt
avec un nom provisoire, et le panneau s'ouvre avec ce nom présélectionné — on
tape par-dessus. C'est exactement le parti pris déjà retenu pour l'ajout d'une
phase (décision 13), qui cesse ainsi d'être une exception : plus aucune création
ne passe par un formulaire à valider.

Conséquences en cascade, toutes bienvenues :

- la couleur s'applique au clic sur sa pastille, donc la frise change sous les
  yeux — le seul moyen de juger si la teinte se distingue de celle des couloirs
  voisins, ce qu'un aperçu dans un dialogue ne montrait pas ;
- il n'y a plus de bouton « Annuler », donc plus le cas où fermer la fenêtre
  perdait la saisie ;
- `creerDialogueProjet` disparaît de `menu.js`, qui ne garde que le menu
  contextuel et la confirmation.

Le `<dialog>` natif reste pour cette dernière : sur une action irréversible,
interrompre franchement *est* le but, et le voile, le piège à focus et la
fermeture par Échap y sont gratuits.

Une contrepartie assumée : un projet créé par mégarde existe dans le fichier
même si l'on ferme le panneau sans rien saisir. Il porte alors le nom
« Nouveau projet », se voit sur la frise, et se supprime d'un clic depuis son
propre panneau — ce qui reste moins coûteux que d'imposer un dialogue à tout le
monde à chaque création.

## 22. Un binaire Go plutôt qu'un script Python

`serve.py` supposait Python installé et une commande tapée dans un terminal, depuis le dossier du
dépôt. C'est une friction quotidienne pour un outil qu'on veut ouvrir d'un geste, et un obstacle
net sous Windows, où Python est absent par défaut.

L'objectif visé : **poser l'outil et son planning dans un dossier synchronisé, et les retrouver
sur n'importe quelle machine**. Trois voies menaient là.

**Un `index.html` autonome en `file://`.** Séduisante — zéro exécutable, longévité maximale — mais
elle impose de renoncer aux modules ES, bloqués par CORS depuis `file://` (voir la rectification en
décision 3), donc de concaténer les sources en un fichier unique. Et surtout elle enferme dans
Chromium : Firefox et Safari n'implémentent pas la File System Access API.

**Tauri.** Accès direct au disque, sans dialogue ni permission, et le code du navigateur reste
intact. Mais un webview système à installer sous Linux (WebKitGTK), un rendu à vérifier sur trois
moteurs différents, une chaîne Rust et une intégration continue multi-OS pour produire les
binaires. C'est contradictoire avec la décision 10 : une chaîne Tauri de 2026 ne se recompilera pas
aussi sûrement dans dix ans qu'un fichier HTML s'ouvrira.

**Un binaire Go qui contient le serveur et l'interface**, retenu. Il conserve exactement
l'architecture éprouvée — mêmes routes, même fichier JSON, mêmes sauvegardes horodatées, front
inchangé — en supprimant la seule vraie friction, l'installation. `CGO_ENABLED=0` produit un
exécutable statique de 6 Mo qui ne dépend de rien, pas même de la glibc, et les cinq plateformes se
compilent depuis une seule machine sans intégration continue.

Face à `file://`, il garde **tous** les navigateurs et les modules ES. Face à Tauri, il n'exige
aucun webview et divise l'outillage par dix. Ce qu'il concède : l'interface s'ouvre dans un onglet
plutôt que dans une fenêtre d'application, et il faut un binaire par plateforme.

Deux choix de détail méritent d'être notés.

Le port n'est plus fixe : lancé par un double-clic, l'utilisateur n'a aucun moyen de passer
`--port` si 8000 est occupé. Le serveur essaie donc les dix premiers ports libres à partir de 8000.
Un `--port` explicite, lui, n'est jamais contourné — c'est un choix de l'utilisateur.

Le fichier de données est cherché **à côté de l'exécutable**, pas dans le répertoire courant, qui
est imprévisible lors d'un double-clic. Le mode `--dev` fait exception : il sert l'interface depuis
le disque et lit `data/projets.json`, pour qu'un rafraîchissement suffise à voir ses modifications
sans recompiler.

`serve.py` a été supprimé une fois le binaire validé en usage réel. Il n'y avait rien à migrer : le
format du fichier et les routes sont identiques, et son historique reste dans git si le besoin de
le relire se présentait.

## 23. Une sauvegarde par séance, pas une par modification

Le serveur copiait le planning dans `backups/` avant **chaque** écriture. Comme l'interface
enregistre après une seconde d'inactivité, une séance d'édition un peu soutenue produisait des
dizaines de fichiers quasi identiques.

Le défaut n'est pas l'espace occupé — cinquante copies d'un planning macro pèsent 250 Ko — mais ce
que la rotation en fait : les cinquante emplacements se remplissaient en une après-midi, et
chassaient précisément les états anciens qu'on cherche à retrouver. Un filet de sécurité qui ne
remonte pas plus loin que la dernière demi-heure protège de la faute de frappe, pas de la bêtise
qu'on découvre le lendemain.

La copie est donc prise **à l'ouverture**, et une seule fois. C'est le bon moment : l'état d'avant
la séance est exactement celui vers lequel on veut revenir, et il est figé avant qu'on y touche.
Deux garde-fous complètent la règle :

- si le serveur reste allumé longtemps — un serveur local qu'on ne ferme jamais est un cas
  réel —, une copie est reprise au plus une fois par jour, faute de quoi une session de trois
  semaines ne laisserait qu'un seul point de reprise ;
- si le planning est identique à la dernière sauvegarde, rien n'est écrit. Rouvrir l'outil sans
  avoir rien modifié n'a pas à consommer un emplacement.

À raison d'une copie par séance, les cinquante conservées couvrent des mois. Pour un historique
plus long ou plus fin, la vraie réponse n'est pas d'en garder davantage mais de versionner le
planning dans git, ce que son format texte indenté rend parfaitement lisible (voir décision 5).

Ce changement a rendu concurrentes deux étapes qui ne l'étaient pas — la copie et le remplacement
dépendent maintenant d'un état partagé, la date de la dernière sauvegarde. Un verrou les sérialise,
ce qui protège au passage du cas où deux onglets enregistrent en même temps.

## 24. Une vue par mois, en lecture seule, à côté de la frise

La frise répond très bien à « comment ce projet-là s'étale-t-il », et très mal à « qu'est-ce qui
arrive le mois prochain ». La seconde question traverse les projets, alors que la frise les range
précisément en couloirs séparés : il faut balayer une colonne de dates à travers tous les couloirs,
en gardant en tête ce qu'on a vu plus haut. Avec cinq projets et une échelle de six pixels par
jour, c'est déjà pénible ; c'est la raison pour laquelle on ressortait un tableur à côté.

D'où une seconde vue, atteinte par deux boutons dans la barre d'outils. Trois arbitrages la
définissent.

**Une phase est rattachée au mois de son début, et à lui seul.** Une phase de trois mois n'apparaît
donc qu'une fois. La répéter dans chaque mois traversé aurait donné un tableau de charge —
« qu'est-ce qui tourne en octobre » —, qui est une question légitime mais une autre vue : le
doublon coûte la lecture en diagonale qui fait tout l'intérêt de celle-ci, et brouille le compte
affiché en tête de mois. La fin est écrite sur la ligne (« 31 → 13 nov. »), ce qui suffit à voir
qu'une phase déborde et jusqu'où.

**Les mois sans rien ne sont pas représentés.** Un planning à horizon de deux ans a des trous ;
intercaler « novembre 2026 — rien » ferait défiler du vide, alors que l'absence se lit déjà dans le
saut d'un titre au suivant.

**La liste ne s'édite pas.** Aucune poignée, aucun glisser, et un clic sur une ligne n'ouvre pas le
panneau de détail. Ce n'est pas une lacune à combler plus tard : déplacer une phase demande de voir
ce qu'elle chevauche et ce qu'elle repousse, c'est-à-dire le voisinage que la frise montre et que
la liste, ordonnée par date et non par projet, a justement dissous. Une date qu'on modifie sans
voir son contexte est une date qu'on modifie à l'aveugle. La vue sert donc à faire le point, la
frise à arbitrer. Seules les pastilles de tags restent cliquables — filtrer ne change pas les
données, c'est une façon de regarder.

Les **notes** d'une phase, elles, se consultent ici : un triangle en tête de ligne les déplie en
dessous. Lire n'est pas éditer, et une note est précisément ce qu'on va chercher quand on fait le
point — « pourquoi cette phase est-elle bloquée ». Elles restent repliées par défaut, pour deux
raisons. La densité d'abord : trois lignes de notes sous chaque intitulé étalent un mois sur deux
écrans et ruinent la lecture en diagonale. Et parce qu'elles ne sont pas régulières — une phase sur
trois en porte —, les afficher d'office produirait des lignes de hauteurs inégales, ce qui casse
l'alignement des colonnes sur lequel repose tout le balayage du regard.

**Toute la ligne déplie, pas seulement le triangle.** Une première version faisait de l'intitulé
lui-même le bouton, avec un chevron à sa suite : la cible était trop petite pour un geste aussi
banal, et rien ne justifiait cette parcimonie dans une vue où le clic n'a aucun autre effet. Le
triangle reste, mais comme indicateur plutôt que comme cible — c'est lui qui dit ce qui va se
passer, et il reprend le triangle qui plie un projet sur la frise, au même endroit et avec la même
rotation : ce qui s'apprend d'un côté vaut de l'autre. Le curseur et le fond au survol signalent
que la ligne réagit. Les lignes sans notes, elles, ne réagissent pas : promettre un geste qui ne
fait rien est pire que ne rien promettre.

Le triangle n'en reste pas moins un vrai `button` : la ligne, elle, n'est pas focusable, et c'est
donc lui le seul chemin clavier vers les notes. L'état déplié vit dans le DOM et nulle part
ailleurs — il ne survit pas à un changement de filtre, qui reconstruit la liste. Le remonter dans
l'état de l'application pour qu'il y survive serait payer cher une continuité que personne ne
réclame : quand la liste change, on la relit.

Le filtre par tags, lui, vaut pour les deux vues sans rien changer à sa mécanique : c'est le même
état, la même barre, au même endroit. Un filtre posé sur la frise se retrouve en passant à la
liste, ce qui rend la bascule sûre — on ne se demande jamais si l'une montre plus que l'autre. Les
deux tamis de la frise s'appliquent d'ailleurs à l'identique : l'œil (`hidden`) écarte un projet de
la liste comme il écarte ses barres.

La vue choisie n'est pas enregistrée, contrairement à la largeur de la colonne des libellés
(décision 18). Cette largeur est un réglage d'écran, la vue est un geste de consultation : on passe
par la liste pour faire le point, on revient à la frise pour travailler. L'outil s'ouvre donc
toujours sur la frise, celle où l'on modifie. Le défilement horizontal de la frise, lui, est
mémorisé le temps de l'aller-retour : masquer un élément lui fait perdre son `scrollLeft`, et
revenir des années avant ce qu'on regardait serait une punition pour avoir consulté la liste.

Deux conséquences dans le code, toutes deux de bon aloi : les noms de mois et `formaterDateLongue`
sont remontés de `timeline.js` vers `model.js`, et les pastilles de tags dans `tags.js`. Deux vues
sœurs les emploient, aucune n'a à importer l'autre pour écrire « septembre ».

## 25. Les notes sont en markdown, et le projet en a

Une phase avait des notes : un `textarea` de quatre lignes au bas du panneau, du texte brut. Un
projet n'en avait aucune. Les deux manques se tiennent.

**Le projet en avait besoin.** La frise dit quand les choses arrivent ; elle ne dit pas qui pilote,
sur quel budget, ni pourquoi le prestataire est engagé jusqu'en janvier. Ce contexte-là finissait
dans les notes de la première phase venue, où il n'a rien à faire — il survit à la phase, il ne
survit pas à sa suppression. Le champ est donc monté d'un cran, et le panneau d'un projet reçoit le
même bloc que celui d'une phase : renommer un projet et renommer une phase sont la même opération à
un niveau près (décision 21), y écrire une note aussi.

**Quatre lignes fixes étaient un plafond arbitraire.** Les autres champs du panneau ont une taille
dictée par leur contenu — une date en fait dix caractères, un statut en fait quatre. Une note n'a
aucune taille propre : elle fait ce qu'on a à dire. Elle prend donc toute la hauteur que les champs
au-dessus lui laissent, avec un plancher sous lequel le corps du panneau défile plutôt que de
l'écraser.

### Pourquoi un analyseur maison

Le markdown demandait une dépendance, ou du code. Une dépendance aurait été le premier
`node_modules` de l'outil, contre la décision 10, pour une syntaxe dont on n'emploie ici qu'une
poignée de formes. On a donc écrit `js/markdown.js` : un sous-ensemble, environ trois cents lignes,
sans DOM ni réseau — ce qui le rend testable sous Node comme `model.js`, le rendu proprement dit
vivant dans `notes.js`.

Le choix du sous-ensemble suit ce qu'on écrit dans une note de suivi : titres, emphase, code,
listes, cases à cocher, liens, citations, séparateur. Pas de tableaux ni d'images — ils ne tiennent
pas dans un volet latéral. Pas de HTML brut, jamais : le DOM est bâti nœud par nœud, sans un seul
`innerHTML`. Un planning s'échange, on en ouvre un qu'un autre a écrit, et une note est du texte
libre ; la seule façon sûre d'en afficher est de ne jamais laisser le navigateur l'interpréter comme
du balisage. Les URL passent une liste blanche de schémas — `http`, `https`, `mailto` — et un lien
refusé retombe sur son libellé plutôt que de disparaître.

Deux écarts au standard, assumés. **Un retour à la ligne en est un** : CommonMark recolle les lignes
d'un paragraphe et exige deux espaces en fin de ligne pour un vrai retour, piège invisible dans un
champ où l'on jette une petite liste à la volée. Et **ce qui n'est pas reconnu reste du texte** :
`**gras` sans fermeture s'affiche tel quel, parce qu'une note à moitié écrite est l'état normal
d'une note et que l'aperçu doit suivre la frappe sans à-coups.

### On lit d'abord, on écrit ensuite

Le bloc s'ouvre sur l'**aperçu** quand la note existe, sur la **saisie** quand elle est vide. C'est
l'usage : on ouvre une phase bloquée pour relire pourquoi, une phase vierge pour y consigner
quelque chose. Un crayon bascule d'un état à l'autre, et la barre d'outils ne paraît qu'en saisie —
en aperçu elle ne commanderait rien, et sa place revient au texte.

Six boutons, pas plus : gras, italique, titre, liste, case à cocher, lien. Le markdown entier reste
accessible au clavier puisque c'est du texte ; la barre n'est là que pour épargner la syntaxe des
formes courantes. Une barre exhaustive prendrait deux rangées dans le volet et repousserait la note
d'autant.

Les **cases à cocher se cliquent dans l'aperçu**, et c'est le seul geste de l'aperçu qui modifie les
données. Une note de suivi contient des choses à faire ; les cocher en rouvrant la saisie pour
transformer un `[ ]` en `[x]` serait une corvée absurde. La bascule réécrit **la seule ligne visée
dans le texte d'origine** plutôt que de régénérer la note depuis l'arbre : régénérer normaliserait
au passage les marqueurs, l'indentation et l'emphase de l'utilisateur, qui verrait sa mise en forme
réécrite pour avoir coché une case.

Dans la **vue par mois**, en revanche, les cases sont inertes. La liste est en lecture seule
(décision 24) et une case cliquable y serait la seule chose qu'on puisse modifier — une exception
isolée dans une vue dont toute la promesse est qu'on n'y casse rien. On les voit cochées ou non, ce
qui est justement ce qu'on vient y chercher quand on fait le point.

### `Ctrl+Z` doit continuer de marcher

Une barre d'outils écrit dans le champ à la place de l'utilisateur, et la façon évidente de le faire
— affecter `champ.value` — **vide la pile d'annulation** du navigateur. `Ctrl+Z` cesse alors de
remonter au-delà du bouton pressé, et la frappe qui précédait devient irrécupérable. C'est un prix
qu'on ne peut pas faire payer à un champ de saisie : annuler est le réflexe le plus élémentaire
qu'on ait devant du texte, et l'ancien champ de notes, lui, l'honorait sans qu'on ait rien à écrire.

Toutes les écritures passent donc par `document.execCommand('insertText')`, qui laisse le navigateur
enregistrer l'opération comme si elle avait été tapée. L'API est marquée obsolète et reste sans
remplaçant pour cet usage : les `InputEvent` synthétiques qui devaient lui succéder ne modifient
rien, un navigateur ignorant les événements qu'il n'a pas produits. Tenir notre propre historique
reviendrait à réimplémenter `Ctrl+Z`, `Ctrl+Y` et la fusion des frappes voisines — sans commune
mesure avec le service rendu par un champ de notes. Si la commande échoue, on retombe sur
l'affectation directe : on perd l'annulation, jamais la saisie.

Deux gardes vont avec. `execCommand` écrit **là où est le focus**, sans considération pour l'élément
qu'on croit viser : on vérifie donc que le champ l'a bien pris, faute de quoi la commande irait
insérer du markdown dans le champ « Nom ». Et une insertion vide n'en est pas une — c'est une
suppression, que `insertText` ne traite pas partout, d'où le passage par `delete`.

Une seule écriture y échappe : cocher une case depuis l'aperçu, où le champ est masqué et ne peut
pas prendre le focus. Le geste vide donc la pile — sans grande conséquence, puisqu'on n'était pas en
train d'y taper.

### Le volet s'élargit, les infobulles s'aplatissent

Trois cent quarante pixels suffisaient à des champs de date ; ils ne suffisent pas à une liste
imbriquée, où chaque niveau mange une indentation. Le panneau reçoit donc la **même poignée** que la
colonne des libellés (décision 18) : même geste, même double-clic de remise à zéro, même
mémorisation dans `localStorage` — c'est un réglage d'écran, pas une donnée à synchroniser. Une
largeur unique pour les deux panneaux, parce que ce qu'on élargit est le volet, pas l'un ou l'autre
de ses contenus. Elle est plafonnée à la fenêtre sans être écrasée pour autant : la largeur voulue
et la largeur appliquée sont deux variables distinctes, faute de quoi réduire un instant la fenêtre
ferait perdre le réglage.

Les **infobulles** de la frise, elles, ne peuvent pas montrer de rendu : l'attribut `title` du
navigateur ne connaît que le texte. Les notes y sont donc **aplaties** — marques retirées, et
remplacées par un caractère qui porte le même sens là où il y en a un : `•` pour un tiret, `☐` et
`☑` pour une case, `│` pour une citation. Sans cela, survoler une barre afficherait la source
markdown, astérisques comprises, soit une note *moins* lisible qu'avant qu'on ne l'enrichisse. Deux
infobulles taisaient d'ailleurs les notes et les disent maintenant : celle d'un jalon — c'est
pourtant là qu'on consigne une décision — et celle du libellé d'un projet, seul endroit de la frise
où ses notes à lui peuvent se lire, faute de barre qui lui appartienne.

### Le format passe en version 4

Ajouter un champ n'oblige à rien : une version 3 se relit sans encombre. Mais le validateur
reconstruit chaque projet champ par champ et laisse tomber ce qu'il ne connaît pas. Sans
incrémenter, un binaire antérieur ouvrirait un fichier plus riche que lui sans broncher et en
effacerait toutes les notes de projet à la première sauvegarde. Le numéro ne sert qu'à cela : faire
échouer bruyamment ce qui échouerait silencieusement.

## 26. Un curseur clavier, et des raccourcis à la vim

L'outil savait déjà décaler une phase aux flèches, mais pas la **choisir** : `selection` n'était
posée que par `ouvrirPhase`, appelée depuis un clic. Il fallait donc la souris pour commencer, et
tout raccourci ajouté par-dessus aurait hérité de cette dépendance.

### `selection` devient `curseur`, et survit à la fermeture

L'ancienne variable disait deux choses à la fois : « voici la phase que je manipule » et « le
panneau est ouvert dessus ». Les deux se séparent.

Le curseur désigne une **ligne de la frise**, et la ligne d'un projet en est une : c'est de là qu'on
plie, qu'on renomme, qu'on ajoute une phase et qu'on supprime le projet. D'où `{ projet, phase }`
avec `phase` à `null`, plutôt que deux curseurs concurrents dont l'un serait toujours à ignorer.

Il **survit à `Échap`**, alors que `selection` s'effaçait : un curseur qui disparaît à la fermeture
du volet ne peut pas servir de point de départ au déplacement suivant. En contrepartie, la marque
reste visible après un clic dans le vide — c'est le prix d'un curseur, et il se paie une fois.

Comme il peut désigner une ligne qu'un changement vient d'emporter — phase supprimée, projet replié,
filtre resserré —, `dessiner` commence par le **normaliser** : la ligne du projet sert de refuge,
puisqu'elle survit à ces trois cas, et l'effacement n'est que le dernier recours. Placer ce contrôle
dans `dessiner` plutôt qu'à chaque appelant garantit qu'aucun chemin ne l'oublie.

### Le volet suit le curseur

Ce n'est pas un agrément mais une nécessité : les raccourcis agissent sur le curseur, et un panneau
resté sur une autre phase donnerait deux cibles concurrentes à l'écran. On éditerait dans les champs
une phase que `Espace` ou `dd` n'atteindraient pas. Ouvert, le panneau est donc la vue détaillée du
curseur — ce qui fait de `j` et `k` le moyen le plus rapide de relire tout un projet.

Ce parcours passe par un **clic** sur une barre, qui ouvre le volet sans prendre le champ. Ouvrir au
clavier place la frappe dans le nom, où les raccourcis se taisent, et `Échap` referme tout : les deux
usages ne se rejoignent pas, et c'est un compromis assumé plutôt qu'un oubli. Le rendre continu
demanderait de faire d'`Échap` une sortie de champ avant d'être une fermeture — deux appuis là où il
en faut un aujourd'hui, y compris à la souris.

### Deux couches qui ne se recouvrent pas

Les **flèches modifient** la phase du curseur, les **lettres déplacent** et commandent. Aucun
raccourci documenté n'a changé de sens.

La décision 17 tient, mais son partage se déplace. Elle laissait le focus sur le panneau et non dans
un champ, pour que les flèches restent atteignables juste après avoir sélectionné une phase — au
clic, c'est toujours le cas. Ouvrir le volet **au clavier**, en revanche, est une demande explicite
d'écrire : `Entrée` et `e` saisissent donc le nom tous les deux. Ce qui protège les flèches n'est
plus le focus mais `Échap`, qui referme le volet sans déplacer le curseur — « `e`, taper, `Échap`,
flèches » enchaîne sans la souris.

Ce qui ne doit **jamais** prendre le focus, c'est le volet qui suit un déplacement du curseur : la
frappe suivante partirait dans le champ, où les raccourcis se taisent, et on ne saisirait plus jamais
qu'un nom. D'où le paramètre `saisir` de `ouvrirSousCurseur`, vrai sur commande, faux au passage.

`clavier.js` ne connaît rien du planning : il traduit des frappes en noms d'actions, que `app.js`
lui fournit. Les séquences à deux temps se déclarent dans la même table que les autres, et les
préfixes — `g` aller, `z` plis, `d` détruire — s'en déduisent au lieu d'être listés à part. Un
préfixe resté en attente s'oublie au bout de deux secondes : vim ne le fait pas, mais vim n'est pas
posé sur un écran qu'on quitte des yeux, et un `d` abandonné puis retrouvé cinq minutes plus tard
viserait une autre ligne.

Les touches **se taisent** dès que le clavier appartient à quelqu'un d'autre : une saisie en cours,
un dialogue modal, le menu contextuel — qui navigue déjà aux flèches — ou un glisser en cours. Sans
cela, `a` dans un nom de phase créerait une phase au lieu d'écrire un `a`.

`AltGr` est la seule combinaison tolérée avec `Maj`, et il n'y a pas le choix : sur un clavier
français, `{` et `}` ne s'obtiennent qu'avec lui. Windows le présente comme `Ctrl`+`Alt`, si bien
que refuser les deux ensemble rendrait ces deux touches inatteignables sur les binaires Windows.

### Insérer se dit en dates

`model.js` trie les phases par date de début. « Avant » et « après » ne peuvent donc pas s'exprimer
en rangs : `o` et `O` calculent une date et laissent le tri faire le reste. Les quatre points
d'insertion — `A` à la fin du projet, `a` au début, `o` après la phase du curseur, `O` avant — ne
diffèrent que par ce calcul, et passent tous par `ajouterUnePhase`, qui garde son comportement
d'origine quand aucune date ne lui est donnée.

`P` reste à part : un projet naît **hors de tout curseur**, sans date et sans ligne de référence.
L'agréger à la famille `a`/`o` aurait suggéré une position qu'il n'a pas.

### Le curseur se peint dans la colonne, pas seulement sur la barre

La barre portait déjà un contour. Il ne suffit pas : le curseur se pose sur des lignes qui n'ont
aucune barre en face — celle d'un projet, un projet plié, un projet masqué. La colonne des libellés
est le seul endroit qui porte une ligne pour *chaque* position atteignable, et c'est aussi ce qui
permet à `app.js` d'y compter les enfants pour amener le défilement au bon endroit. L'énumération de
`lignesFrise` et celle de `construireLibelles` doivent donc rester d'accord.

Sur la ligne d'un projet, le trait d'accent seul se noyait dans son fond coloré et son triangle de
pli : elle prend aussi une teinte, mélangée à sa couleur propre plutôt qu'au fond de la surface. La
teinte passe par une redéfinition de `--fond-libelle` et non par `background`, parce que le dégradé
qui donne un fond aux commandes du projet s'appuie sur cette même variable — un fond posé en direct
y laissait une couture.

### Le `?` n'est pas facultatif

Des raccourcis d'une lettre ne se devinent pas. Un bouton dans la barre d'outils et la touche `?`
ouvrent la même table, dans un `<dialog>` **modal** — contrairement aux deux panneaux : celui-ci ne
sert qu'à lire, et laisser `j` déplacer le curseur derrière la table qui explique `j` serait absurde.

La table est écrite à la main plutôt que bâtie depuis `SEQUENCES`, qui associe une touche à un nom
d'action : cela ne dit ni ce que l'action fait, ni dans quel ordre la présenter, ni quelles touches
vont par paires. La génération aurait produit une liste exacte et illisible.

### La vue par mois n'a pas de curseur

Elle se lit, elle ne s'édite pas (décision 24) : rien n'y aurait de sens à désigner. `j`, `k`, `gg`
et `G` y font donc ce qu'ils font dans un document — ils déroulent la liste. `gm` et `ga` marchent
dans les deux vues, le reste attend le retour à la frise.

## 27. Le cycle de vie d'un projet, et l'horizon

L'outil est employé pour piloter les chantiers d'une petite mairie : beaucoup plus de projets
imaginables que de temps pour les mener, et une crainte première — **ne rien oublier**. Une idée
qu'on ne peut pas traiter cette année ne doit pas disparaître pour autant.

Or l'outil ne connaissait que les projets déjà planifiés. Tout ce qui n'était pas encore engagé
vivait ailleurs — un carnet, une tête, un compte rendu de réunion — de sorte que l'arbitrage se
rendait **sans voir le planning**, alors que c'est précisément le planning qui dit s'il y a la
place.

### La priorité est une décision d'avant l'engagement

Le point de départ était une matrice d'Eisenhower dans le panneau d'un projet. Deux objections
l'ont déplacée.

L'urgence est **déjà dans les dates**. La resaisir crée un champ qui se périme en silence : un
projet coché « urgent » en juin ne l'est plus en septembre, et rien ne viendra le décocher.

Surtout, une fois un projet planifié, **l'arbitrage est déjà rendu** — ce sont ses dates qui le
portent. Une priorité posée sur un projet engagé ne déciderait plus rien, elle commenterait. Le
lieu de la priorisation est donc en amont, sur ce qui n'est pas encore engagé.

### Quatre états, dont deux se déduisent

Un projet traverse quatre états, et deux d'entre eux se lisent dans les données sans qu'on ait
rien à tenir à jour :

| État | Comment on le sait |
|---|---|
| **Envisagé** | il n'a qu'un horizon, pas encore de phase |
| **Engagé** | on lui a donné au moins une phase datée |
| **Terminé** | toutes ses phases sont finies **et** on l'a acté |
| **Écarté** | on a décidé de ne pas le faire |

Une règle unique les résume : **les phases commandent l'état, sauf quand on a prononcé quelque
chose.** Livré n'est pas clos, et abandonner est une décision — ces deux-là s'actent. Le reste se
déduit.

**Clore un projet termine toutes ses phases avec lui.** Sans cela la frise se contredirait : une
ligne éteinte au-dessus de segments pâles, et la vue par mois annonçant des tâches à venir dans un
projet fini. C'est donc la seule opération du cycle qui **écrase des données** — le statut d'une
phase bloquée est perdu, et rouvrir le projet ne peut pas le deviner. Elle se confirme à ce titre,
comme une suppression (décision 21), mais **seulement quand il reste quelque chose à écraser** : un
dialogue qui ne prévient de rien apprend à cliquer sans lire.

Engager n'est donc pas un bouton : c'est un geste, celui de donner ses premières dates fermes. Et
écarter n'est pas supprimer — le projet quitte la frise mais reste retrouvable, avec dans ses notes
la raison pour laquelle on a dit non. Les mêmes idées reviennent tous les deux ans, portées par
d'autres : savoir qu'on les a déjà examinées, et sur quel motif, a de la valeur.

### L'horizon est le repli des bornes

Un projet envisagé n'est pas une ligne hors du temps : il porte un **horizon**, exprimé en mois —
« mars 2027 », « de mars à septembre 2027 », « courant 2028 » — et il se pose **sur la frise**, à
cet horizon. C'est là que l'arbitrage devient concret : quand le printemps 2027 est déjà chargé et
que six projets pâles s'y superposent, on décide devant l'évidence plutôt que dans l'abstrait.
C'est ce qui remplace le calcul de charge que l'outil ne fera jamais.

La règle tient en une phrase, et elle ne mélange pas le saisi et le calculé :

> L'emprise temporelle d'un projet se calcule depuis ses phases. Un projet qui n'en a pas encore la
> déclare à la main : c'est son horizon.

Les phases gagnent toujours. `bornesProjet()` fait déjà ce calcul et retourne `null` quand il n'y a
aucune phase — l'horizon bouche ce trou, il n'ajoute pas de règle. Corollaire : **on ne réécrit
jamais une saisie par un calcul**. Un projet qui perdrait sa dernière phase retrouve l'horizon qu'il
avait déclaré, pas l'enveloppe des phases disparues.

Le grain est le mois, jamais l'année : en début de mandat, tout est à faire, et un horizon annuel ne
range plus rien. Un horizon s'exprime comme un intervalle de mois plutôt que par des crans nommés —
ni trimestre ni semestre à apprendre, un seul mécanisme, et trois propriétés qui en découlent :

- **la largeur de la barre pâle *est* l'incertitude**, l'œil la lit sans qu'on l'écrive ;
- **la précision de l'horizon suit la maturité du projet** : on resserre à mesure qu'on y voit
  clair. Il n'y a pas de frontière entre envisagé et engagé, il y a un dégradé ;
- **engager, c'est préciser au jour près** ce qui était au mois près.

La barre d'un projet envisagé se dessine donc autrement : pâle, aux bords fondus, et **accrochée au
mois** — jamais au jour. C'est l'accroche au lundi de la décision 9 poussée d'un cran : le geste
existe, il ne permet simplement pas de poser une date qu'on n'a pas.

Elle fut d'abord rendue **immobile**, au motif qu'interdire physiquement valait mieux qu'une
convention. L'usage a tranché autrement, et pour une bonne raison : on ajuste un horizon *en
regardant ses voisins*, pour voir si le printemps 2027 est déjà chargé. Obliger à passer par un
panneau pour ce réglage-là, c'est le faire à l'aveugle. L'accroche au mois suffisait à protéger ce
qui devait l'être.

L'horizon **survit à l'engagement**. Non pour le comparer à ce qui a été planifié, mais parce que ne
rien effacer est ici plus simple qu'effacer, et parce qu'il sert de filet si le projet se dépeuple.

### Un horizon échu remonte à la surface

Un backlog échoue toujours de la même façon : tout ce qu'on n'ose pas refuser y atterrit, il gonfle,
plus personne ne le relit. Les deux garde-fous habituels — un plafond, une péremption qui efface —
sont ici interdits par la crainte de départ.

L'horizon en fournit un meilleur : **un projet dont l'horizon est dépassé se signale**. On est en
juin, quatre projets visaient le premier trimestre : il faut trancher, on repousse ou on écarte.
Rien ne disparaît, mais rien ne dort — et la relecture tombe d'elle-même au rythme des arbitrages
budgétaires.

### Ce qui ancre un projet écarté

La question n'a pas la même réponse selon d'où vient l'écartement.

Un projet écarté **depuis l'état engagé** garde ses phases datées, dont certaines ont réellement eu
lieu. Il a un ancrage, et un vrai : le travail fait ne doit pas s'effacer, puisque la frise est notre
mémoire.

Un projet écarté **depuis l'état envisagé** n'a rien. Son horizon a cessé d'être une prévision — on
ne le fera pas à cette date, on ne le fera pas du tout — et l'y laisser serait un mensonge sur la
frise.

D'où **la date d'écartement**, posée automatiquement, jamais saisie. C'est l'ancrage commun aux deux
cas, celui sans lequel les écartés ne forment plus qu'un tas. Il ne s'agit pas de journaliser les
décisions — les comptes rendus de réunion font ce travail, et mieux — mais d'horodater une sortie.

La clôture est horodatée de la même façon, et c'est ce qui donne au modèle sa forme définitive :
**les deux actes prononcés laissent une date, et ces deux dates sont l'unique trace de l'état dans le
fichier.** Acter, c'est dater. Il n'y a pas de champ « état » — il se lit dans ces deux dates et dans
la présence de phases.

On les retrouve d'abord en les cochant dans le filtre par état, ce qui les ramène dans la colonne
des libellés, groupés et éteints. Cela répond à « je sais que ça existe, je veux le retrouver ». Cela
ne répond pas à « relire d'un coup deux ans d'idées écartées avec leurs motifs », qui demanderait une
liste — geste assez rare pour attendre que le manque se fasse sentir.

### La réanimation ne demande aucun mécanisme

Puisque les états se déduisent, il suffit de **retirer l'écartement** : le projet retrouve tout seul
l'état que ses données commandent. Des phases, il redevient engagé ; un horizon seul, envisagé. Pas
de destination à choisir, une seule commande.

Le système se referme bien : un projet écarté en 2026 et réanimé aujourd'hui revient avec un horizon
périmé, donc se signale aussitôt comme échu. On le redate dans la foulée.

```
                    écarté  ←──────┐
                   ↗   ↑           │ réanimer
                  /    │           │ (l'état se
   envisagé ──────┴─ engagé ──→ terminé   recalcule)
   (un horizon)    (≥ 1 phase)  (acté)
        ↑              │
        └──────────────┘
     s'il perd sa dernière phase
```

### L'état ne passe pas par les tags

Un tag est libre, disparaît quand plus personne ne le porte, et dérive orthographiquement
(décision 16) : trois propriétés inacceptables pour un état. Ce sont deux mécanismes indépendants
qui filtrent la même frise, et les tags restent disponibles pour ce à quoi ils servent.

Les deux filtres ne se comportent d'ailleurs pas pareil, et il faut que cela se voie : **celui des
tags est conjonctif, celui des états est disjonctif**. Un projet porte plusieurs tags mais un seul
état — cocher `client` + `urgent` resserre, cocher `envisagé` + `engagé` élargit. La même case à
cocher voudrait sinon dire deux choses opposées selon la ligne où elle se trouve.

Comme celui des tags, le filtre par état **n'est pas enregistré** : c'est un état de vue, pas un
réglage.

### Ce que le premier essai a corrigé

Trois choses ne se sont vues qu'en manipulant l'outil, et toutes disaient la même : **un projet
envisagé ne doit pas être un citoyen de seconde zone**.

**Engager démarre à l'horizon.** La première phase d'un projet envisagé naissait à la date du jour,
comme celle de n'importe quel projet vide. Elle apparaissait donc à des mois de la barre pâle qu'elle
venait remplacer, et le lien entre les deux se perdait. Elle commence maintenant au premier jour de
l'horizon : engager, c'est préciser au jour près ce qu'on avait déclaré au mois près, pas repartir
d'ailleurs.

**Les deux actes sont dans le panneau, pas seulement dans le menu.** Ils avaient été rangés dans le
menu ⋯ au nom de la décision 20 — un bouton permanent se mérite, et clore un projet est rare. Mais
c'est dans le panneau qu'on **lit** l'état du projet, donc c'est là qu'on cherche à en changer : les
y chercher et ne pas les trouver coûte plus cher que deux boutons de plus. Ils figurent aux deux
endroits, comme « plier » ou « masquer ».

**Les projets sans phase paraissent dans la vue par mois.** Ils n'y figuraient pas, faute de phase à
lister — alors qu'un projet visé pour mars 2027 *arrive* bel et bien en mars 2027. Les omettre
revenait à dire que la liste ne montre que l'engagé, quand toute cette décision pose le contraire.
Ils s'y rattachent au premier mois de leur horizon, dans les mêmes colonnes que les phases mais en
italique. C'est ce qui a fait renommer `phasesParMois` en `entreesParMois` : la liste ne montre plus
seulement des phases.

La règle porte sur **l'absence de phases et non sur l'état**, exactement comme `empriseProjet` : un
projet écarté avant d'avoir jamais été engagé n'a lui non plus que son horizon pour se situer, et
il doit se retrouver là quand on ouvre le cimetière. La distinguer par l'état aurait fait du
cimetière de la liste par mois une collection des seuls projets qui avaient démarré — soit
l'inverse de ce qu'on y cherche.

### Ce qui a été reporté, et pourquoi

Ces choix ne sont pas des refus définitifs. Ils attendent leur moment, et il vaut mieux savoir
lequel.

**La matrice d'Eisenhower.** Elle n'a pas de sens sur des projets engagés, pour les raisons
ci-dessus. Sur les seuls envisagés elle redevient cohérente, et se branche même bien : l'horizon
fournit l'axe d'urgence, il ne resterait que l'importance à saisir. À reprendre quand une liste
existera, et seulement si l'horizon seul ne suffit pas à départager.

**Une vue liste des envisagés.** La frise sait situer, elle ne sait pas ranger : on ne peut pas
ordonner six projets par priorité dans un empilement de couloirs. Cette première étape ne livre donc
**aucun mécanisme d'ordre explicite entre projets** — ce qu'elle livre, c'est l'horizon, et c'est
déjà l'arbitrage le plus décisif. Reste le départage fin entre projets visant le même trimestre.

**Un dézoom de l'axe temporel**, pour embrasser plusieurs années d'un coup. Le jour où il arrivera,
il faudra rouvrir la décision 14, « une seule échelle, pas de zoom ».

**Une vue de rétrospective.** La frise défile en arrière sans limite (décision 15) : le passé y est
déjà lisible, et un écran de plus l'aurait redit. Corollaire à tenir : **un projet terminé reste sur
la frise**, éteint mais présent, sinon on perd le bilan.

**Des dates réelles à côté des dates prévues.** Ce serait doubler chaque champ pour un gain nul :
dans cet outil on recale les barres au fil de l'eau, donc la date de fin *devient* le réel. La
contrepartie est assumée — la qualité du bilan dépend de l'entretien de la frise, et aucun champ ne
répare un planning qu'on ne tient pas.

**Un repère de fin de mandat**, comme le repère « aujourd'hui ». Pertinent sur le principe, sans
urgence en début de mandat.

**Un retour arrière déclaré**, d'engagé vers envisagé. On déplace les dates, cela suffit. Le seul
cas où il survient — retirer la dernière phase — se résout tout seul par la règle des bornes.

## 28. Une date qu'on ne décide pas

Toutes les phases d'un planning ne sont pas nôtres. Certaines sont **déléguées** — un prestataire les
tient, on n'a que le résultat —, d'autres portent une **contrainte extérieure** : une fenêtre de
maintenance chez l'hébergeur, une échéance réglementaire, une date de salon. Une phase reçoit donc un
booléen `fixed`, et le décalage d'un projet (section 8) ne l'emporte pas.

Sans elle, le geste ajouté en section 8 était activement nuisible : repousser un projet de trois
semaines repoussait aussi l'audit du commissaire aux comptes, ce qui est faux et ce que rien ne
signalait.

### Pourquoi ce n'est pas un cinquième statut

C'était la formulation spontanée — « ajouter un état ». Elle a été écartée, parce que les quatre
statuts existants disent tous **l'avancement** (section 6), et qu'une date imposée n'est pas une
étape du travail : une phase déléguée est tour à tour à venir, en cours, terminée, et elle reste
déléguée tout du long. En faire une cinquième valeur aurait créé une exclusion mutuelle fausse — on
ne pourrait plus dire d'une phase déléguée qu'elle est bloquée, ce qui est précisément la situation
qu'on veut voir venir de loin.

Le modèle avait déjà le patron : **`milestone` est un booléen à côté de `status`**, pas un statut. Un
jalon peut être `todo` ou `done` sans que cela pose la moindre question. `fixed` suit exactement le
même chemin, et les deux se combinent librement — un jalon à date imposée est le cas le plus courant
des deux.

**À ne pas confondre avec `blocked`**, dont il est le voisin immédiat dans un formulaire :
`blocked` dit *ça n'avance pas*, `fixed` dit *cette date ne m'appartient pas*. Une phase peut être
les deux, l'une ou l'autre, ou aucune. Le libellé retenu — « date imposée » plutôt que « fixe » —
sert d'abord à cela : il nomme la cause, là où « fixe » n'aurait nommé que l'effet, et six mois plus
tard c'est la cause qu'on cherche en relisant.

### Le verrou est souple

Une phase à date imposée **se glisse toujours seule**, à la souris comme aux flèches. Seul le
décalage de son projet l'épargne. « Imposée » veut donc dire *indépendante du projet*, et non
*immuable* : quand l'hébergeur déplace son créneau, on déplace la barre, sans rien avoir à décocher.

Le verrou dur avait été envisagé — barre non glissable, dates saisies au panneau — au motif qu'on
marque une phase pour la protéger d'un geste accidentel. Il ajoutait une friction permanente pour un
risque occasionnel, et il aurait fait diverger cette case de son modèle, `milestone`, qui n'empêche
rien non plus.

Corollaire : un projet dont toutes les phases sont terminées **ou** imposées n'offre aucune prise, et
sa barre cumulative le dit dans son infobulle. C'est le comportement déjà écrit pour les projets
entièrement clos ; il n'a pas eu à changer, seule la liste des phases emportées s'est resserrée.

### Ce que ça donne à l'œil

Deux **taquets** verticaux aux extrémités de la barre, comme les butées d'une pièce qui ne coulisse
plus ; un **cercle** pour un jalon, qui n'a pas d'extrémités où en poser. La marque se cumule avec
les quatre textures de statut au lieu de leur disputer la place — c'est bien une phase à venir, en
cours ou bloquée, qui se trouve en plus tenue par le dehors.

Elle se pose en `box-shadow` interne, donc sans toucher à la géométrie : la barre garde exactement la
largeur de ses dates. Sur une phase de deux jours, les taquets occupent presque toute la barre et la
texture de statut disparaît ; c'est accepté, une fenêtre de maintenance de deux jours se lit de toute
façon à son infobulle.

### Le format passe en version 6

Un champ ajouté n'y obligerait pas — la v5 se relit sans encombre. Ce qui y oblige, c'est le sens du
numéro : le validateur reconstruit chaque phase champ par champ et laisse tomber ce qu'il ne connaît
pas. Sans incrément, un binaire antérieur ouvrirait un fichier v6 sans broncher et en effacerait
toutes les dates imposées à la première sauvegarde — les phases concernées se remettant alors à
suivre le décalage de leur projet, en silence. C'est exactement le genre de perte que ce numéro
existe pour empêcher.

La migration ne devine rien : toute phase héritée reçoit `false`. Rien dans les données ne permettrait
d'inférer laquelle était déléguée, et un faux positif ici immobiliserait une phase sans qu'on
comprenne pourquoi.

Au passage, `donneesInitiales` dans `main.go` a été remis d'aplomb : le serveur écrivait encore
`version 4` pour un planning vide, deux versions en retard. Sans conséquence — le validateur accepte
un fichier plus ancien et le remonte — mais un fichier neuf se déclarait d'avant le cycle de vie.