DOC
Accueil/ Projets/ MJY Task Platform/ ADR 0008 : Import de listes de tâches par document (template à colonnes fixes)

ADR 0008 : Import de listes de tâches par document (template à colonnes fixes)

  • Statut : Accepté
  • Décideurs : Julien (Commanditaire), Seer MENSAH-ASSIAKOLEY (Développeur)
  • Date : 8 juillet 2026

Contexte et Problème

Julien souhaite pouvoir importer un document de « to-do list » complet et que la plateforme en crée automatiquement les tâches, assignées aux collaborateurs. Les exemples fournis (liste de déco boutique, checklists opérationnelles ENGWE) sont formulés de manières hétérogènes :

- @Sofia Guedra trouve un tapis leopard pour les escalier -> my tam commande
- chiner : miroir bulle + miroir lavabo -> sofia + my tam chine et my tam commande
- Commande plantes ? bambou -> on commande quand ?

Deux difficultés :

  1. Formulation libre : les lignes mélangent l'action, le ou les responsables, des notes et des questions ouvertes. Sans cadre, il faut une IA pour deviner « qui / quoi / quand » à chaque import.
  2. Coût récurrent : faire analyser chaque document par un LLM à chaque upload représente un coût par import et un risque d'erreur d'interprétation.

Il faut un mécanisme d'import fiable, à coût maîtrisé, qui reste simple à remplir pour un utilisateur non technique (Julien).

Facteurs de Décision

  • Coût maîtrisé : pas de dépendance à un appel LLM payant à chaque import.
  • Parsing fiable et déterministe : même entrée → même sortie, sans interprétation floue.
  • Facilité de remplissage : la personne qui remplit le document (Julien) n'est pas technique ; le format ne doit pas casser facilement.
  • Alignement au modèle de données : le document ne doit demander que des informations réellement stockables dans la table task.
  • Contrôle humain avant écriture : éviter la création en masse de tâches mal assignées.

Options Envisagées

Option A : Import libre + interprétation par IA (LLM)

L'utilisateur upload n'importe quel document (Slack, notes, PDF) ; un LLM structure le contenu en tâches.

  • Avantage : aucune contrainte de format pour l'utilisateur.
  • Inconvénient : coût par import, erreurs d'interprétation, résultats non déterministes, difficile à tester/reproduire.

Option B : Template à colonnes fixes + parsing déterministe + écran d'aperçu (Recommandée)

On fournit un template à colonnes fixes (tableau Markdown et CSV/Excel). Le parsing est déterministe (aucune IA). Un écran d'aperçu affiche les tâches détectées et les assignés résolus avant création ; l'utilisateur corrige et valide.

  • Avantage : coût nul par import, déterministe, testable, l'aperçu absorbe les cas ambigus sans IA.
  • Inconvénient : demande à Julien de remplir un template plutôt que de coller du texte libre.

Option C : Saisie manuelle uniquement (statu quo)

On ne fait pas d'import ; chaque tâche est créée à la main.

  • Avantage : rien à développer.
  • Inconvénient : ne répond pas à la demande (Julien veut charger des listes entières d'un coup).

Décision Retenue

L'Option B : Template à colonnes fixes + parsing déterministe + écran d'aperçu a été retenue.

Justification

C'est la seule option qui répond à la fois au besoin (charger une liste entière d'un coup) et au facteur de coût (pas de LLM par import). Le template supprime l'ambiguïté à la source ; l'écran d'aperçu garde un humain dans la boucle pour les rares cas non résolus (nom inconnu, action partagée). L'IA reste une évolution possible en surcouche si Julien veut un jour coller du texte libre, sans remettre en cause ce socle.

Règles fonctionnelles arrêtées

  • Colonnes du template : Tâche (obligatoire) · Notes · Assigné à · Responsable · Priorité · Pilier · Échéance. Le projet cible est choisi au moment de l'upload (une liste = un projet), il n'est pas une colonne.
  • Mapping vers la table task :
    Colonne template Champ task Remarque
    Tâche title obligatoire
    Notes description y compris le « pourquoi » et les infos hors-tâche
    Assigné à owner personne qui réalise la tâche
    Responsable manager personne qui valide (optionnel)
    Priorité priority bloquant→blocking, haute→high, vide/normale→normal
    Pilier pillar texte libre (ex. Atelier, Stock, Achats…)
    Échéance due_end date
    - created_by automatique = auteur de l'import (jamais dans le document)
    - status automatique = todo
  • Sémantique owner / manager / created_by : confirmée par le code (src/pages/EmployeeDashboard.jsx, src/hooks/useData.jsx). owner = assigné/faiseur, manager = validateur, created_by = créateur automatique. Le -> sofia d'une liste correspond à owner.
  • Matching des noms : normalisation (minuscules, trim, suppression des accents, espaces compactés) puis correspondance avec member.name. Si aucun membre ne correspond → owner laissé vide, à compléter par Julien dans l'écran d'aperçu.
  • Une tâche = un seul owner : task.owner est une FK unique. Une action partagée entre plusieurs personnes est éclatée en autant de tâches que de personnes (fidélité littérale). Le co-équipier peut être rappelé dans Notes.
  • Ré-import : pas de déduplication. Chaque upload = un nouveau lot de tâches. La mise à jour d'une tâche existante se fait manuellement dans l'application, jamais via un ré-upload.
  • Périmètre V1 : import ponctuel uniquement. Les checklists récurrentes (montage vélo par unité, checklist d'ouverture quotidienne, inventaire hebdomadaire, émargement sécurité) ne sont pas couvertes en V1 et feront l'objet d'un cadrage ultérieur.

Conséquences

Positives

  • Coût par import nul : parsing 100 % déterministe, aucune dépendance LLM.
  • Reproductible et testable : un même fichier produit toujours le même résultat.
  • Sûr : l'écran d'aperçu empêche la création en masse de tâches mal assignées.
  • Aligné au schéma : le template ne demande que des champs réellement persistés.

Négatives / Points de vigilance

  • Friction de remplissage : Julien doit saisir sa liste dans le format du template plutôt que de coller du texte libre.
  • Tâches partagées dupliquées et indépendantes (point d'honnêteté) : une action confiée à N personnes crée N tâches distinctes (id différents, owner différents). Ces copies ne sont pas synchronisées : si une personne termine la sienne, les autres restent ouvertes, et l'action compte pour N unités dans les statistiques « avancement par manager » du tableau de bord Super Manager. Comportement accepté pour la V1 (pour une action réellement collective, il est même cohérent que chacun suive sa part) ; à réévaluer si le besoin de tâches multi-assignées apparaît.
  • Pas de déduplication au ré-import : uploader deux fois la même liste crée les tâches en double. C'est un choix assumé (l'aperçu permet de décocher les lignes non voulues) ; une détection de doublons pourra être ajoutée plus tard si nécessaire.
  • Checklists récurrentes non couvertes : une grande partie de l'activité ENGWE repose sur des procédures récurrentes ; leur import/génération est reporté à une V2.