Kanban

Organiser les tâches en liste ou en tableau, avec règles métier, récurrence et historique.

Objectif: Garder les mêmes règles métier dans l’interface et dans l’API.
Points clés: Règles WIP, Blazor, API, EF Core, accessibilité, tests et CI.

Domaines

Dépôt GitHub Télécharger le CV

Tableau Kanban en thème sombre avec cinq colonnes, tâches, priorités et limites WIP visibles. — Tableau configurable montrant tâches, priorités et limites WIP.

Problème

Le problème à résoudre

Créer un gestionnaire de tâches qui combine interactions Kanban, règles métier, historique, import/export et API sans dupliquer la logique entre l’interface Web et les endpoints HTTP.

Architecture

Les pièces du système

Todo.Domain contient tâches, sous-tâches, étiquettes, colonnes, historique, paramètres et invariants.
Todo.Contracts regroupe DTO, requêtes, formats d’import/export et exceptions contractuelles.
Todo.Application orchestre les cas d’usage et le transfert de données.
Todo.Infrastructure fournit EF Core, SQLite, repository et initialisation/mise à niveau de la base.
Todo.Ui porte l’interface Razor, tandis que Todo.Web l’héberge en Blazor Interactive Server.
Todo.Api expose les mêmes capacités applicatives via des Minimal APIs et OpenAPI.

Décisions

Décisions techniques

Faire des limites WIP une règle métier. La limite d’une colonne n’est pas un simple avertissement visuel : le domaine la modélise et les déplacements/API réutilisent cette règle.
Partager les cas d’usage entre Web et API. Todo.Web et Todo.Api s’appuient sur Todo.Application afin d’éviter une logique métier différente selon le point d’entrée.
Persister la configuration du tableau. Ordre, visibilité, couleur et limites WIP des colonnes sont conservés en base plutôt que reconstruits uniquement dans l’état de l’interface.
Prévoir une alternative clavier au drag-and-drop. Les déplacements restent accessibles sans dépendre exclusivement du glisser-déposer.

Schéma

Vue d’ensemble de l’architecture

Le schéma complète l’étude de cas avec les composants et frontières réellement présents dans le projet.

Schéma du gestionnaire Kanban reliant l’hôte Web Blazor et l’API aux couches UI, Application, Domain, Contracts et Infrastructure SQLite. — Architecture Web métier avec règles WIP dans le domaine et persistance EF Core/SQLite.

Implémentation

Points techniques principaux

Création, modification, suppression, achèvement et réouverture de tâches.
Sous-tâches, étiquettes, priorités, échéances, rappels, récurrence et historique horodaté.
Vues Liste et Kanban avec glisser-déposer, réorganisation persistante et alternative clavier.
Cinq colonnes configurables avec nom, ordre, couleur, visibilité et limite WIP.
Import/export JSON ou CSV, thèmes clair/sombre et réduction des animations.
API REST pour tâches, tableau, paramètres, historique et données.
Persistance EF Core/SQLite, tests multi-couches, formatage, audit NuGet et CI GitHub Actions.

Difficultés

Difficultés résolues

Maintenir la cohérence des déplacements Kanban. Le changement de colonne, l’ordre persistant et les limites WIP doivent rester cohérents pour le drag-and-drop, le clavier et l’API.
Historiser sans polluer les vues. Les actions importantes sont persistées et exposées par un historique dédié plutôt que dispersées dans l’état UI.
Faire évoluer une base SQLite locale. Le prototype applique des mises à niveau additives afin de préserver les données créées par les versions précédentes.

Qualité

Tests et garde-fous

Tests du domaine, de l’application, de l’infrastructure SQLite et du formatage d’interface.
dotnet format vérifie le style avant build et tests.
La CI audite également les dépendances NuGet directes et transitives vulnérables.

Livraison

Livraison et CI/CD

GitHub Actions exécute restore, format, build Release, tests et audit NuGet sur develop, main et pull requests.
Le Makefile expose make verify et les commandes de lancement Web/API.
Nullable, analyse statique et builds déterministes sont inclus dans la quality gate .NET.

Résultats

Résultats observables

Un gestionnaire combinant vues Liste et Kanban, récurrence, historique et règles WIP.
Des colonnes configurables et limites WIP persistées plutôt qu’un tableau uniquement visuel.
Une API REST et des formats d’import/export qui réutilisent les mêmes données métier.

Compromis

Compromis techniques

SQLite rend le projet simple à lancer et à conserver localement, mais ne vise pas un service collaboratif distribué.
Les rappels sont signalés lorsque l’application Web est ouverte ; aucune infrastructure de notification native ou serveur n’est incluse.
Le projet reste volontairement mono-utilisateur et sans authentification afin de concentrer le périmètre sur le domaine et les interactions.

Limites

Les limites actuelles

Le branding public reste encore partagé entre le nom du dépôt Kanban et le nom interne Todo.
L’authentification et la collaboration multi-utilisateur ne sont pas incluses.
Les notifications natives et la synchronisation hors ligne avec l’API ne sont pas implémentées.

Suite

Prochaines étapes

Harmoniser le branding Kanban/Todo avant une release utilisateur stable.
Ajouter authentification et collaboration uniquement si le projet doit dépasser le périmètre mono-utilisateur local.
Externaliser les rappels/notifications si l’application doit prévenir l’utilisateur lorsqu’elle n’est pas ouverte.

Captures

Le produit en situation

Quelques écrans pour parcourir le projet.

Tableau Kanban en thème clair avec cinq colonnes et plusieurs tâches réparties selon leur état. — Même tableau en thème clair.

Synthèse

Compétences et techniques mobilisées

Règles métier explicites autour des colonnes et limites WIP.
Réutilisation des mêmes couches Application/Domain depuis l’interface Blazor et l’API.
Les déplacements disposent d’une alternative clavier, les paramètres du tableau sont persistés et la CI vérifie formatage, build, tests et audit NuGet.