URL publique Planificateur
Site live : https://planificateur.quatools.fr
C'est l'URL de production du Planificateur Quatools, outil de productivité IA-native (gestion de projets, tâches, time tracking, integrations MCP). Accessible publiquement.
Planificateur Quatools — productivité IA-native
Le Planificateur Quatools, c'est de la gestion projets / tâches / tracking de temps conçue pour être pilotée autant par humain que par IA. Stack : TypeScript · Supabase · MCP server custom avec 17 outils MCP exposés.
Pourquoi le Planificateur existe
Tous les outils de productivité existants sont conçus pour être pilotés à la souris :
- Linear / Asana / Jira — workflow propre, mais l'IA n'est qu'un widget collé après coup
- Notion / ClickUp — tellement flexibles qu'ils deviennent un labyrinthe sans structure pour l'agent
- Toggl / Timely — tracking de temps, mais aucune structure projet/tâche profonde
- Sunsama / Motion — IA marketing, pas IA-native
Aucun n'est pensé pour qu'un agent autonome ouvre la session, lise l'état, démarre un timer, fasse le travail, le tracke et clôture — comme un humain le ferait, mais sans humain.
Le Planificateur répond à ce manque : l'API canonique de l'app est MCP, pas REST. L'UI web et l'agent IA sont deux clients équivalents de la même surface. Conséquence : Claude (Desktop, Code, ou tout client MCP) pilote n'importe quel projet ou tâche en langage naturel, sans "intégration IA" à part.
Le défi : concevoir une app dont l'agent est un client de première classe
Quand on décide que l'API canonique est MCP, plusieurs choix se cascadent :
- Toute action métier doit avoir un outil MCP correspondant — pas d'action exclusive à l'UI
- Les outils doivent être idempotents et auto-documentés — pour qu'un agent comprenne par lecture du schéma
- Les retours doivent être structurés — un agent lit du JSON, pas un toast
- L'authentification doit être pensée pour tokens longue durée — pas de session web qui expire
- Le state doit être lisible en une query —
get_active_tasksrend en une réponse l'état complet de "ce sur quoi je travaille"
Architecture et 17 outils MCP du Planificateur
- Backend : Supabase (Postgres, Auth, RLS) — migration faite depuis Firebase pour la cohérence multi-tenant
- MCP server : TypeScript custom, déployé en parallèle de l'app web — single source of truth pour toutes les actions
- Système de timer : sessions cumulables (start → pause → resume → complete),
total_secondsagrégé, jamais de double-tracking
17 outils MCP exposés :
- Projets :
list_projects,get_project,create_project,update_project - Tâches :
list_tasks,get_task,create_task,update_task,delete_task - Tracking de temps :
start_task,pause_task,resume_task,complete_task,get_active_tasks - Configuration :
get_tracking_config,update_tracking_config - Méta :
log_insight(capture des découvertes au fil de l'eau, indexées dans FluidStore)
Roadmap : OKR pour la hiérarchie complète — module en conception : ajouter une couche Vision → Objectif → Key Result → Projet → Tâche lisible en une query par l'agent. Trois bénéfices visés :
- L'agent comprend le pourquoi de chaque tâche (pas juste son intitulé)
- L'utilisateur évite la fuite vers les side-projects en voyant en permanence ce qui est « business » vs « fun »
- Un dashboard de progression OKR remonte automatiquement les heures trackées
Preuves Planificateur et discipline système
- Utilisé en continu sur toutes mes missions — toutes les heures trackées dans ce portfolio, Sport Manager, EPHI-SPORTS, Beelib, Rocalys, AO CMA sont passées par cet outil
- Démonstration vivante : la rédaction même du corpus de ce portfolio est trackée minute par minute via les outils MCP du Planificateur. Le portfolio se mesure lui-même.
- CLAUDE.md global intègre le protocole de tracking : avant tout travail, vérifier
get_active_taskset créer/démarrer une tâche. C'est devenu une règle système appliquée à toutes mes sessions Claude — pas un rappel manuel, une discipline automatique. - Migration Firebase → Supabase réalisée proprement (tracking préservé, tâches historiques migrées)