Pourquoi j’ai créé TinyPM : le gestionnaire de projets que j’aurais aimé avoir.
Pendant plusieurs années, j’ai travaillé comme chef de projet.
Comme beaucoup de professionnels dans ce rôle, j’ai utilisé une multitude d’outils de gestion de projets. Certains étaient excellents sur le plan fonctionnel, d’autres plus discutables, mais ils avaient souvent un point commun : ils étaient conçus pour gérer les projets… et finissaient parfois par compliquer le travail des équipes.
Au fil des années, j’ai vu défiler des diagrammes de Gantt sophistiqués, des workflows configurables à l’infini, des tableaux de bord remplis d’indicateurs, des automatisations complexes et des dizaines de fonctionnalités dont personne ne se servait réellement.
Le problème n’était pas forcément la qualité de ces outils.
Le problème était souvent leur décalage avec la réalité du terrain.
Le chef de projet passait du temps à structurer, organiser, paramétrer et suivre. Les contributeurs, eux, devaient souvent naviguer dans une interface complexe simplement pour mettre à jour l’état d’une tâche ou consulter ce qu’ils avaient à faire.
Et lorsque l’outil devient plus contraignant que le travail qu’il est censé faciliter, l’adhésion disparaît.
Combien de fois ai-je vu des projets revenir à des fichiers Excel, des listes partagées ou des échanges de mails parce que l’outil officiel était perçu comme trop lourd ?
Cette frustration m’a accompagné longtemps.
Je me suis souvent dit qu’il devait être possible de faire plus simple.
Pas plus pauvre.
Pas moins puissant.
Simple.
D’une simple Todo List à un véritable outil de gestion de projet
À l’origine, TinyPM ne devait même pas être un logiciel de gestion de projets.
Je voulais simplement créer une application de gestion de tâches pour mon propre usage.
Une sorte de Todo List moderne.
Une application où je pourrais centraliser mes tâches, définir des priorités, suivre mon avancement et visualiser rapidement ce qui devait être fait.
L’objectif était modeste.
Quelques écrans. Quelques listes. Une base de données. Rien de plus.
Mais comme souvent dans les projets personnels, une idée en entraîne une autre.
Une fois les premières fonctionnalités en place, j’ai commencé à me poser des questions.
Comment visualiser les tâches autrement qu’en liste ?
Comment suivre l’avancement d’un projet ?
Comment identifier rapidement les blocages ?
Comment représenter les dépendances entre les tâches ?
Comment permettre à quelqu’un de consulter ses tâches depuis son téléphone ?
À chaque réponse, TinyPM gagnait une nouvelle capacité.
Progressivement, la simple liste de tâches s’est transformée en véritable outil de gestion de projets.
[CAPTURE D’ÉCRAN : vue principale de TinyPM avec la liste des tâches]
Une conviction : chaque fonctionnalité doit servir à quelque chose
L’expérience acquise en gestion de projet m’a servi de filtre.
À chaque nouvelle idée, je me posais la même question :
Est-ce que cette fonctionnalité m’aurait réellement aidé lorsque je gérais des projets ?
Si la réponse était non, elle n’entrait pas dans TinyPM.
Je ne voulais pas reproduire ce que je reprochais à de nombreux outils du marché : accumuler des fonctionnalités parce qu’elles existent ailleurs.
Je voulais construire un outil centré sur les besoins réels.
Pourquoi j’ai choisi de centrer TinyPM sur les tâches
Cette approche a fortement influencé les choix fonctionnels.
TinyPM repose avant tout sur les tâches.
Les projets existent pour organiser les tâches.
Les vues existent pour mieux les comprendre.
Les statistiques existent pour les analyser.
Mais la tâche reste l’élément central.
Parce qu’au final, un projet avance lorsque les tâches avancent.
C’est également la raison pour laquelle l’interface privilégie toujours l’accès rapide aux informations importantes : statut, priorité, échéance, responsable et avancement.
Une même donnée, plusieurs façons de comprendre un projet
L’une des leçons que j’ai retenues de mes années de gestion de projets est qu’il n’existe pas une seule manière de suivre un projet.
Selon son rôle, chacun a besoin d’une représentation différente.
Certains préfèrent les listes.
D’autres travaillent naturellement avec un tableau Kanban.
Les chefs de projet ont souvent besoin d’un diagramme de Gantt pour comprendre les dépendances et l’impact des retards.
Les managers apprécient une vue calendrier pour visualiser la charge globale.
C’est pourquoi TinyPM propose plusieurs vues qui reposent toutes sur les mêmes données.
Changer de vue ne change pas l’information.
Cela change simplement la manière de la comprendre.
Une tâche déplacée dans le Kanban apparaît immédiatement dans le planning. Une modification dans le planning est visible dans les listes.
Toutes les représentations restent synchronisées.
Le Kanban : l’outil que tout le monde comprend
S’il y a une vue que les équipes adoptent immédiatement, c’est généralement le Kanban.
Le principe est universel :
À faire
En cours
En revue
Terminé
Pas besoin de formation.
Pas besoin de documentation.
Quelques secondes suffisent pour comprendre comment cela fonctionne.
C’est pourquoi le Kanban occupe une place importante dans TinyPM.
Déplacer une carte est souvent plus naturel que remplir un formulaire.
Et lorsque la mise à jour devient simple, les informations restent à jour.
[CAPTURE D’ÉCRAN : vue Kanban avec déplacement d’une carte]
Le Gantt : planifier sans subir la planification
J’ai également longtemps utilisé les diagrammes de Gantt.
Ils sont extrêmement utiles lorsqu’un projet comporte des dépendances entre tâches.
Mais ils deviennent rapidement pénibles lorsqu’il faut recalculer manuellement tout un planning après un retard.
J’ai donc voulu que TinyPM fasse ce travail automatiquement.
Lorsqu’une tâche est déplacée, les tâches dépendantes peuvent être recalculées afin de maintenir la cohérence du planning.
L’objectif n’est pas de remplacer le jugement humain.
L’objectif est d’éviter les tâches répétitives.
[CAPTURE D’ÉCRAN : diagramme de Gantt avec dépendances]
Pourquoi une application mobile était indispensable
Aujourd’hui, nous ne travaillons plus exclusivement derrière un bureau.
Nous participons à des réunions, nous nous déplaçons, nous travaillons parfois à distance.
Je trouvais donc important qu’un utilisateur puisse consulter ses tâches ou mettre à jour leur statut depuis son téléphone aussi facilement que depuis son ordinateur.
C’est pour cette raison que TinyPM existe à la fois sous forme d’application web et d’application mobile.
Les deux interfaces partagent les mêmes données et poursuivent le même objectif : permettre de retrouver rapidement l’information utile sans avoir à naviguer dans une multitude d’écrans.
[CAPTURE D’ÉCRAN : application mobile Android/iOS]
Ce que je n’ai volontairement pas mis dans TinyPM
Créer un logiciel est souvent un exercice de renoncement.
À chaque fonctionnalité ajoutée, l’interface devient un peu plus complexe et l’expérience utilisateur un peu moins évidente.
J’ai donc volontairement laissé de côté certaines fonctionnalités pourtant présentes dans de nombreux outils du marché :
les workflows ultra-configurables ;
les dizaines de statuts différents ;
les tableaux de bord surchargés ;
les systèmes de paramétrage nécessitant plusieurs heures de configuration ;
les fonctionnalités rarement utilisées mais coûteuses en complexité.
Non pas parce qu’elles sont inutiles, mais parce qu’elles ne correspondaient pas à l’objectif de TinyPM : rester simple à comprendre et rapide à adopter.
Construire l’outil que j’aurais aimé utiliser
Au fond, TinyPM est probablement le projet le plus personnel que j’ai développé.
Il ne répond pas à un cahier des charges client.
Il ne cherche pas à reproduire un produit existant.
Il est le résultat de nombreuses années passées à utiliser des outils de gestion de projets, à observer ce qui fonctionnait bien, mais aussi ce qui compliquait inutilement le quotidien des équipes.
Si je devais résumer TinyPM en une phrase, ce serait probablement celle-ci :
Un outil de gestion de projet doit aider à réaliser le travail, pas devenir un travail supplémentaire.
Je ne prétends pas avoir créé l’outil parfait.
Je suis convaincu qu’il n’existe pas.
Mais j’ai essayé de construire un outil cohérent avec ma vision de la gestion de projet :
privilégier la simplicité ;
limiter les manipulations inutiles ;
conserver une vue claire de l’avancement ;
offrir plusieurs modes de visualisation adaptés aux différents profils ;
permettre aux équipes d’adopter l’outil sans effort.
C’est cette philosophie qui guide encore aujourd’hui l’évolution de TinyPM.
Et c’est probablement ce qui le différencie le plus des autres outils.
Dans le prochain article, je quitterai la casquette de chef de projet pour reprendre celle de développeur. Nous verrons comment j’ai conçu l’interface de TinyPM avec Blazor, MudBlazor et Syncfusion, et pourquoi ces technologies se sont imposées naturellement dans ce projet.
