Il y a une semaine, j'ai publié Todo — mon kanban local pour piloter des agents. Depuis, je l'utilise tous les jours, sur plusieurs projets, avec plusieurs agents. Et en une semaine, l'outil a changé.
Pas de refonte. Pas de "v2". Juste quelques features ajoutées au fil de l'eau, chacune née d'une friction réelle que je ne connaissais même pas avant de commencer à m'en servir.
Voilà ce qui me frappe en regardant cette semaine : un outil qu'on fait soi-même grandit différemment d'un outil qu'on subit. Et je crois que ça mérite un article à part.
Le cycle "friction → feature" est devenu ridiculement court
Prenons un exemple concret.
Lundi, je crée un ticket pour refaire le système d'eau d'Aekan. Très vite, je réalise que c'est trop gros — mon agent programmer et mon agent technical-artist doivent se partager le boulot. Je commence à créer plusieurs tickets reliés par #42 dans les descriptions. Sauf que l'agent perd le fil, et moi aussi.
Mardi, j'ai des sub-tickets.
Pas parce que c'était sur une roadmap. Pas parce qu'une demande a remonté d'un backlog. Parce que j'en avais besoin la veille, que le code est à moi, et qu'il m'a fallu quelques heures pour l'ajouter proprement.
Dans le monde du SaaS, ce même besoin aurait fini dans un forum communautaire, aurait été agrégé avec 50 autres demandes similaires, aurait attendu un trimestre pour passer en under consideration, puis peut-être un an avant d'atterrir en prod. Ou jamais.
Le ratio "besoin détecté → feature livrée" est passé de plusieurs mois à quelques heures. Ça change tout.
Les features "trop petites" existent enfin
Voici la deuxième chose que l'usage a révélée : il y a une catégorie entière de features qui n'existaient nulle part — non pas parce qu'elles sont inutiles, mais parce qu'elles sont trop petites pour qu'un éditeur s'en occupe.
Exemple : un Ctrl+Z qui annule la dernière action sur le board.
C'est l'une des features les plus utiles que j'aie ajoutées cette semaine. Elle fait littéralement une chose : quand tu fais une connerie sur un ticket, tu fais Ctrl+Z et c'est annulé. Déplacement par erreur, mauvaise priorité, sub-ticket glissé au mauvais endroit — tout s'annule.
Quelques outils le font partiellement (Linear a un toast "undo" sur certaines actions, Trello aussi sur les drag-and-drop), mais rarement de manière complète et au clavier. Pourquoi ? Parce que c'est trop petit pour justifier un roadmap item, et trop diffus pour être un argument commercial. Mais quand tu l'utilises toi-même, c'est la différence entre "je bouge les tickets sans y penser" et "je fais gaffe à chaque clic".
Psychologiquement, c'est énorme. Et c'est typiquement le genre de feature qu'on n'a que dans les outils qu'on fait pour soi.
L'outil sait des choses que je ne savais pas
Autre observation étrange de cette semaine : mes agents m'ont fait découvrir des bugs que je n'aurais jamais trouvés tout seul.
Un agent a créé un ticket avec "status": "EnCours" au lieu de "En cours". Le ticket est parti dans une colonne fantôme. Un autre a envoyé des commentaires avec un author vide — "null a créé le ticket" dans l'historique.
Ce sont des cas que je n'aurais jamais déclenchés en tant qu'utilisateur humain. Mais un agent, qui lit la doc vite et teste tout, les trouve en une journée.
Résultat : j'ai ajouté des validations silencieuses que je n'aurais jamais écrites si j'étais resté le seul utilisateur. L'API est devenue plus robuste parce qu'elle a été testée par des agents avant d'être testée par des humains.
C'est une inversion intéressante : les agents sont mes meilleurs QA.
La satisfaction de régler ses propres bugs
Il y a aussi un truc que je n'avais pas anticipé et dont je voudrais parler honnêtement : la satisfaction émotionnelle de régler ses propres irritants.
Quand tu tombes sur un bug dans un SaaS payant, tu fais quoi ? Tu signales, tu attends, tu oublies. L'irritant persiste et te pourrit la journée à chaque fois que tu recroises le bout de workflow concerné.
Quand tu tombes sur un bug dans ton propre outil, tu le fixes. Dans la foulée. Et à chaque fois que tu recroises ce bout de workflow, tu te dis "ah oui, j'avais fait ça bien".
Cette petite satisfaction répétée, mise bout à bout sur une semaine, ça a un effet réel sur l'énergie qu'on met dans ses autres projets. C'est pas un argument qu'on voit souvent, mais c'est vrai.
Ce que ça dit du rapport à nos outils
Je crois qu'on est en train de traverser un moment intéressant. Pendant vingt ans, on a externalisé notre outillage à des SaaS qui décident ce qu'on peut faire, à quel rythme, et à quel prix. On a appris à vivre avec des outils "presque bons", qui ne font jamais exactement ce qu'on veut mais qu'on tolère parce que les construire nous-mêmes serait trop cher.
Ce coût-là s'effondre. Pas uniquement grâce aux agents IA — mais grâce à la combinaison de meilleures stacks, de templates solides, et de l'aide d'agents qui accélèrent la phase "je code" de 5 à 10x.
Ce que ça veut dire concrètement : les outils sur-mesure redeviennent économiquement rationnels pour des besoins qui, hier, n'auraient jamais justifié le coût.
Todo, c'est un kanban. Il y en a des dizaines sur le marché. Mais aucun n'est exactement ce dont j'ai besoin, et aucun ne le deviendra jamais — parce que mon besoin est trop niche pour leur roadmap. Alors je le fais moi-même, et je le sculpte au fil des semaines.
En résumé
Cette semaine, Todo a gagné : des sub-tickets, un sub-kanban dédié, un Ctrl+Z global, et trois validations silencieuses. Rien de révolutionnaire en soi. Mais chaque ajout a résolu une irritation que je n'aurais jamais vu corrigée dans un outil tiers.
Et c'est peut-être ça, le vrai message : quand on commence à faire ses propres outils, on réalise à quel point on acceptait des compromis sans s'en rendre compte.
Le code
Tout est à jour sur GitHub :
Si l'approche vous intéresse — ou si vous construisez aussi des outils sur-mesure pour votre workflow — rejoignez-moi sur Discord.