Gestion de tâches en Kanban
SupTaskFlow
Application web de gestion de tâches en Kanban (tableaux, colonnes et cartes), avec comptes utilisateurs et déplacement des cartes par glisser-déposer, dont la position est conservée en base.
Le projet
Le sujet imposait une application full-stack complète, avec un back en CMS découplé et un front séparé. L'objectif concret : permettre à quelqu'un de s'inscrire et d'organiser visuellement ses tâches par glisser-déposer, avec des données strictement cloisonnées par compte.
C'est ce cloisonnement, absent par défaut du CMS choisi, qui a constitué le vrai travail, bien plus que les opérations de création et de modification.
Le projet est terminé et fonctionnel, exécutable en local ; il n'a pas été déployé.
Fonctionnalités
- Authentification complète : inscription, connexion, déconnexion, avec déconnexion automatique si le jeton expire
- Kanban à trois niveaux : gestion des tableaux, des colonnes et des cartes
- Glisser-déposer persistant : les cartes se déplacent dans une colonne comme entre colonnes, et gardent leur position après rechargement
- Cartes enrichies : description, date limite avec badge dynamique (« 3j de retard », « Aujourd'hui »), étiquettes colorées
- Interface optimiste : l'affichage réagit instantanément, avec retour en arrière automatique et message d'erreur si le serveur refuse
Les difficultés rencontrées
Une fois le glisser-déposer en place, les cartes se déplaçaient correctement à l'écran mais revenaient à leur position d'origine au rechargement de la page. L'API renvoyait les cartes dans un ordre non déterministe : la notion de « position dans la colonne » n'existait tout simplement pas en base. Le problème n'était donc pas dans le glisser-déposer mais dans le modèle de données : nous confondions l'ordre d'affichage, qui vit dans l'interface, avec l'ordre métier, qui doit être enregistré. Côté back, j'ai rendu la position explicite en ajoutant un champ dédié sur les colonnes et les cartes, et exposé les routes permettant de le mettre à jour, y compris quand une carte change de colonne. Un choix délibéré dans le modèle : les positions sont espacées de mille plutôt que de se suivre, ce qui permet d'insérer une carte entre deux autres sans tout réécrire. Le front s'appuie dessus pour trier à l'affichage et n'envoyer que les positions réellement modifiées.
Les contrôleurs par défaut du CMS renvoyaient tous les tableaux, y compris ceux des autres utilisateurs. J'ai dû les redéfinir pour vérifier la propriété à chaque requête, en remontant la chaîne des relations de la carte jusqu'à son propriétaire. Cela dit, la vérification récupère les données puis filtre côté serveur applicatif : c'est suffisant à l'échelle du projet, mais ne tiendrait pas en production (la bonne approche serait de filtrer directement dans la requête envoyée à la base).
Ce que j'en ai retiré
- Un ordre d'affichage doit être une donnée, pas un effet de bord : tout ce qui est visible et doit survivre à un rechargement appartient au modèle.
- La sécurité ne s'hérite pas d'un framework. Celui-ci fournissait l'authentification (qui es-tu ?), mais pas l'autorisation (as-tu le droit d'accéder à cette ressource ?). La seconde partie se code, ressource par ressource.
- Une interface optimiste n'est acceptable qu'avec un chemin de retour en arrière : afficher un succès qui n'a pas eu lieu est pire qu'afficher un délai.
- Concevoir une API pour quelqu'un d'autre : mon binôme consommait ce que j'exposais, donc chaque décision de format devenait un contrat. C'est très différent d'écrire un back qu'on est seul à utiliser.