--- title: "Todo — Un kanban piloté par agents, pensé pour le dev solo" description: "J'ai publié Todo, un outil de gestion de projet local, léger et pilotable par IA. Pourquoi je l'ai construit, et comment je l'utilise avec Claude et Lain." date: 2026-04-06T14:00:00+02:00 tags: ["Todo", "Tooling", "IA", "Open Source"] --- J'utilise Azure DevOps depuis des années pour gérer mes projets. C'est un excellent outil — quand on bosse en équipe, avec des sprints, des pipelines, des boards reliés à des repos. Mais quand on est dev solo et qu'on veut juste **suivre l'avancement d'un projet avec un agent IA**, c'est overkill. Pareil pour GitHub Projects : c'est faisable, mais il y a de la friction — surtout quand on veut qu'un agent autonome puisse créer des tickets, les déplacer, commenter, sans passer par une configuration lourde. Alors j'ai fait ce que je fais de mieux ces derniers temps : j'ai construit l'outil moi-même. **→ [Todo sur GitHub](https://github.com/Ekioo/Todo)** --- ## Le problème Quand je travaille sur Aekan ou sur d'autres projets, j'ai pris l'habitude de déléguer des tâches à **Claude** et **Lain**. Je leur donne un objectif, ils planifient, exécutent, et rendent compte. Mais pour que ça fonctionne bien, il faut un outil de suivi partagé — un endroit où l'agent peut : - Voir les tickets existants et leur statut - Créer de nouveaux tickets quand il identifie du travail - Déplacer un ticket d'une colonne à l'autre quand c'est fait - Commenter pour expliquer ce qu'il a fait (ou ce qui bloque) - Vérifier s'il a été mentionné quelque part Avec Azure DevOps, c'est possible via l'API, mais ça demande un setup OAuth, des permissions, du mapping de champs. Avec GitHub Projects, il faut passer par GraphQL, gérer des tokens, et le modèle de données est parfois contre-intuitif. Rien d'insurmontable, mais à chaque fois c'est du temps passé sur la plomberie plutôt que sur le projet. --- ## La solution : un SaaS local en deux jours Si je peux expédier un outil fonctionnel en deux jours, pourquoi ne pas le faire ? Todo est né de cette idée : un kanban **sur-mesure, léger, local, et pensé dès le départ pour être piloté par des agents**. Concrètement, c'est : - Un **board kanban** classique avec colonnes, tickets, labels, priorités - Une **API REST complète** sous `/api` — tout ce que l'UI fait, l'API le fait aussi - Un **système de mentions** avec `@agent:claude` ou `@owner` pour communiquer entre humains et agents - Du **Markdown** partout — descriptions, commentaires, références croisées avec `#ticket` - Une **base SQLite par projet** — isolation totale, zéro configuration - Le tout tourne en **local** sur `localhost:5230` Pas de cloud, pas d'auth complexe, pas d'abonnement. Tu clones, tu `dotnet run`, c'est parti. ![Le board Todo en action](/images/blog/todo-board-screenshot.png) --- ## Comment ça marche avec un agent L'API a été conçue pour qu'un agent puisse se débrouiller seul. Voici le workflow type : 1. **Découverte** — l'agent liste les projets, les colonnes, les membres, les labels disponibles 2. **Lecture** — il consulte le board, filtre par priorité, cherche les tickets qui le concernent 3. **Action** — il crée un ticket, le déplace, ajoute un commentaire, change la priorité 4. **Communication** — il mentionne `@owner` pour signaler un blocage, ou vérifie ses propres mentions pour voir s'il a du travail en attente Les agents s'identifient avec le format `agent:{nom}` — par exemple `agent:claude` ou `agent:lain`. Ça permet de savoir qui a fait quoi dans l'historique d'activité. --- ## Un exemple concret avec Aekan Sur Aekan, j'ai un projet Todo avec des colonnes **Backlog → En cours → Review → Done**. Quand je veux avancer sur une feature : 1. Je crée un ticket (ou je demande à Claude de le faire) avec la description du besoin 2. Claude prend le ticket, le passe en "En cours", et commence à travailler 3. Quand c'est terminé, il le déplace en "Review" avec un commentaire qui explique ce qu'il a fait 4. Je review, je valide (ou je commente), et je passe en "Done" Si Lain identifie un bug pendant un test automatisé, il crée directement un ticket avec le contexte, la priorité, et mentionne `@owner`. Je le vois au prochain coup d'oeil sur le board. Simple, fluide, sans cérémonie. En réalité, sur Aekan, ce n'est pas un ou deux agents — c'est **13 agents spécialisés** qui tournent en autonomie, orchestrés par un moteur custom que j'appelle le **dispatcher**. Il gère le routing, le parallélisme, l'apprentissage, et l'évaluation des agents — le tout branché sur l'API de Todo. J'en parle en détail dans [un article dédié](/blog/dispatcher-agent-orchestration). --- ## Pourquoi open source Cet outil résout **mon** problème, mais je suis convaincu qu'il peut servir à d'autres. Si vous travaillez avec des agents IA et que vous cherchez un outil de suivi léger, sans friction, et que vous pouvez faire évoluer comme vous voulez — c'est exactement pour ça qu'il a été construit. Le code est propre, le stack est simple (.NET 10, Blazor, SQLite), et l'API est documentée via OpenAPI. Forkez, adaptez, contribuez. **→ [github.com/Ekioo/Todo](https://github.com/Ekioo/Todo)** --- ## Suivez le développement Si ce genre d'outils vous intéresse — ou si vous voulez suivre comment j'utilise l'IA au quotidien dans mes projets — rejoignez-moi sur **Discord**. C'est là que je partage en temps réel. **→ [Rejoindre le Discord](https://discord.gg/4MVPfw9wTQ)**