Ce qui est réalisé
V1 locale avec sujets, user stories, tâches, sprints, Kanban et sauvegarde JSON. Serveur, interface et scripts sont présents.
Piloter / UML classes & états
Un Kanban taillé
pour sa propre façon de travailler.
Sujets, user stories, tâches, sprints de durée libre : un outil local qui reprend le vocabulaire des équipes agiles, appliqué à des projets personnels.
Le besoin
Suivre plusieurs projets en parallèle, chacun avec son propre rythme, sans outil en ligne ni compte à créer. Les outils du marché imposent souvent des sprints de durée fixe ; ici, chaque sujet a ses propres sprints.
L’analyse
Deux modèles suffisent à décrire l’outil : la structure des données et le cycle de vie d’une tâche. La règle d’affichage du Kanban, qui dépend des dates du sprint, a été formulée comme une expression logique avant d’être codée.
Côté architecture, un serveur PowerShell traite les actions dans une boucle extensible ; l’interface sépare strictement HTML, CSS et JavaScript.
Les modèles documentés
Structure des données
UML 2 · diagramme de classes← Faire défiler le schéma →
Cycle de vie d’une tâche
UML 2 · machine à états← Faire défiler le schéma →
Règles de gestion
Ce que l’outil doit respecter.
- RG-01Trois niveaux : sujet (thème) → user story (besoin) → tâche (élément atomique).
- RG-02Les sprints appartiennent à un sujet, avec des dates de début et de fin libres.
- RG-03Kanban : une tâche s’affiche si elle est créée avant la fin du sprint et n’a pas été close avant son début.
- RG-04Bloquer ou annuler exige un motif.
- RG-05Sauvegarde automatique à chaque modification.
Ce que ce projet démontre
La règle RG-03 est typique d’une exigence qui semble claire en réunion et devient ambiguë au moment de coder. L’écrire sous forme logique, puis la représenter dans le modèle, supprime l’ambiguïté.
État au 13 octobre 2026
Une réalisation, un périmètre précis.
Ce qui a été vérifié
La documentation décrit la V1. La conversation d’origine et la dernière validation en usage n’ont pas été retrouvées pendant l’inventaire.
Limites actuelles
L’état des fichiers ne confirme pas à lui seul un usage quotidien actuel. La restauration et le comportement avec les données actuelles doivent être vérifiés.
Prochaine étape
Relancer avec un jeu d’essai, vérifier visibilité du Kanban, transitions et persistance, puis documenter la version validée.
Exemples de critères de recette
Ces critères décrivent le résultat attendu. Ils ne constituent pas, à eux seuls, des tests réussis.
- Une tâche créée avant la fin du sprint et non close avant son début apparaît dans le Kanban ; les autres cas sont exclus selon la règle RG-03.
- Bloquer ou annuler une tâche sans motif est refusé ; avec motif, le nouvel état et le motif persistent après réouverture.
Parlons de votre projet
Un besoin concret.
Une première discussion.
Un processus trop manuel, une donnée peu fiable ou une idée à tester ? Commençons par clarifier ce qui vous serait vraiment utile.
Échanger avec Loïc