Tags sur les projets, en version 3 du format

Un projet porte désormais une liste d'étiquettes libres, destinées à filtrer la
frise. Il n'y a pas de référentiel à tenir : les tags disponibles sont ceux que
portent les projets.

normaliserTags() nettoie la liste à l'enregistrement — espaces réduits, vides
écartés, doublons fusionnés à la casse près, tri alphabétique pour qu'une
ressaisie dans un autre ordre ne produise aucun diff. Les accents, eux, comptent :
« éditeur » et « editeur » restent deux tags distincts, contrairement aux
identifiants qui doivent tenir dans une URL.

Un tag trop long est tronqué plutôt que refusé : sa longueur est cosmétique, et
bloquer le chargement d'un planning entier pour un libellé bavard serait
disproportionné. La validation ne vérifie donc que le type — un tag mal typé
serait un tag qu'on croit poser et qui ne filtre rien.

teinteTag() dérive une teinte HSL du nom par hachage : la couleur d'un tag n'est
ni stockée ni saisie, et reste la même partout où il apparaît.

Le format passe en version 3. Un fichier en version 2 se charge sans rien
demander, ses projets recevant une liste vide, et il est réécrit en version 3 à
la première sauvegarde. Le bump empêche une version antérieure de l'outil
d'effacer silencieusement les tags en réécrivant le fichier.

Dix tests couvrent la normalisation, la comparaison, la teinte et le filtre.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/modele-donnees.md

@@ -9,12 +9,13 @@ dans un diff git et éditable à la main.
 
 ```json
 {
-  "version": 2,
+  "version": 3,
   "projects": [
     {
       "id": "site-web",
       "name": "Refonte du site web",
       "color": "#3b82f6",
+      "tags": ["client", "web"],
       "collapsed": false,
       "hidden": false,
       "baselineDate": "2026-06-12",
@@ -48,9 +49,12 @@ dans un diff git et éditable à la main.
 
 | Champ | Type | Description |
 |---|---|---|
-| `version` | entier | Version du format. Vaut `2`. Sert à détecter un fichier trop ancien au chargement. |
+| `version` | entier | Version du format. Vaut `3`. Sert à détecter un fichier trop ancien au chargement. |
 | `projects` | tableau | Les projets, dans l'ordre d'affichage des couloirs. |
 
+Un fichier en version `2` — celle d'avant les tags — se charge sans rien demander : ses projets
+reçoivent une liste de tags vide, et il est réécrit en version `3` à la première sauvegarde.
+
 ## Projet
 
 | Champ | Type | Description |
@@ -58,6 +62,7 @@ dans un diff git et éditable à la main.
 | `id` | chaîne | Identifiant parlant, dérivé du nom (`Refonte du site web` → `site-web`). Unique dans le fichier. |
 | `name` | chaîne | Nom affiché. Non vide. |
 | `color` | chaîne | Couleur du couloir, en hexadécimal `#rrggbb`. |
+| `tags` | tableau | Étiquettes libres servant à filtrer la frise. Trié, sans doublon, éventuellement vide. |
 | `collapsed` | booléen | `true` si le couloir est plié. |
 | `hidden` | booléen | `true` si le projet est masqué de la frise. Ses données restent intactes. |
 | `baselineDate` | chaîne ou absent | Date à laquelle la référence a été figée. Absent si elle ne l'a jamais été. |
@@ -91,6 +96,36 @@ Appliquées par `js/model.js` et couvertes par `tests/model.test.js`.
   Un `id` ne change jamais si le nom est modifié ensuite — il identifie, il ne décrit pas.
 - `status` fait partie des quatre valeurs autorisées ; toute autre valeur est ramenée à `todo`.
 - `color` est un hexadécimal `#rrggbb` valide.
+- `tags` est un tableau de chaînes. Le tableau lui-même et le type de ses éléments sont vérifiés —
+  un tag mal typé serait un tag qu'on croit poser et qui ne filtre rien. Leur *contenu*, en revanche,
+  est normalisé sans erreur (voir ci-dessous).
+
+## Tags
+
+Une étiquette libre, posée sur un projet, sans liste fermée à tenir à jour : les tags disponibles
+sont simplement ceux que portent les projets.
+
+À l'enregistrement, `normaliserTags()` nettoie la liste :
+
+- espaces de bord retirés, espaces internes réduits à un seul ;
+- tags vides écartés ;
+- doublons fusionnés **à la casse près** — `Client` et `client` sont le même tag, et c'est la
+  première graphie rencontrée qui est conservée ;
+- tag tronqué au-delà de **24 caractères** (`MAX_LONGUEUR_TAG`) ;
+- tri alphabétique, pour que ressaisir les mêmes tags dans un autre ordre ne produise aucun diff git.
+
+Les **accents comptent** : `éditeur` et `editeur` restent deux tags distincts. C'est la différence
+avec `fabriquerId()`, qui les retire parce qu'un identifiant doit tenir dans une URL — un tag, lui,
+n'est jamais qu'affiché.
+
+La **couleur** d'un tag n'est pas stockée : elle se déduit du nom par un hachage
+(`teinteTag()` → une teinte HSL entre 0 et 359). Elle est donc stable d'une session à l'autre et
+identique partout où le tag apparaît, sans rien avoir à gérer. Deux tags peuvent tomber sur des
+teintes voisines : la couleur aide à repérer, elle ne porte pas d'information à elle seule — le nom
+est toujours écrit à côté.
+
+Le **filtre**, lui, n'est pas dans le fichier : c'est un état de vue, au même titre que la fenêtre
+temporelle. Voir [decisions.md](decisions.md), section 16.
 
 Un fichier invalide n'est jamais réparé en silence : le chargement échoue avec un message qui pointe
 le projet et la phase fautifs, pour que le fichier puisse être corrigé à la main.