Quand Trello a été présenté à TechCrunch Disrupt en septembre 2011, 131 000 personnes se sont inscrites en 48 heures. L’outil proposait un concept d’une simplicité désarmante: un tableau, des colonnes, des cartes que l’on déplace en temps réel. Pas de formation nécessaire, pas de manuel, pas de consultant pour configurer l’environnement. En 2015, la plateforme comptait 10 millions d’utilisateurs, construits sans un centime de capital-risque.
Six ans après son lancement, Atlassian a racheté Trello pour 425 millions de dollars. Un chiffre impressionnant, mais révélateur: l’entreprise n’a jamais atteint le statut de licorne (valorisation d’un milliard) que le marché lui promettait. Pour les chefs de projet, cette trajectoire contient des enseignements concrets sur la manière de choisir et d’évaluer leurs propres outils.
Un produit horizontal dans un métier vertical
Joel Spolsky, fondateur de Fog Creek Software et créateur de Trello, a formulé le problème avec lucidité: “Créer un produit horizontal utile dans tous les domaines est presque impossible.” Trello a été conçu comme un outil généraliste. On pouvait l’utiliser pour organiser un déménagement, planifier un mariage ou gérer un projet de développement logiciel. Cette polyvalence, qui explique l’adoption massive, portait en elle la faiblesse structurelle du produit.
La gestion de projet est un métier vertical. Elle repose sur des concepts précis: les dépendances entre tâches (la tâche B ne peut commencer qu’après la fin de la tâche A), le chemin critique (la séquence de tâches qui détermine la durée minimale du projet), la décomposition hiérarchique du travail ou WBS (Work Breakdown Structure), le suivi des risques et l’allocation des ressources. Un outil qui ignore ces dimensions n’est pas un outil de gestion de projet, quel que soit le nombre de cartes qu’il permet de déplacer.
La monétisation manquée comme signal
L’un des aspects les plus instructifs de l’histoire de Trello concerne sa stratégie de monétisation. En 2013, deux ans après le lancement, l’entreprise a introduit “Trello Gold”: un abonnement premium dont les avantages se limitaient à des fonds d’écran personnalisés et des emojis supplémentaires. Pas de fonctionnalités de pilotage, pas de reporting avancé, pas de gestion des ressources.
Ce choix n’était pas un accident. Il reflétait une réalité produit: Trello n’avait pas de fonctionnalités avancées à vendre parce que l’architecture même de l’outil n’était pas prévue pour en accueillir. Un tableau Kanban, par conception, ne gère ni les dépendances, ni le chemin critique, ni la charge par collaborateur. Ces fonctionnalités auraient nécessité de repenser entièrement le produit.
Pour un chef de projet qui évalue un outil, c’est un critère révélateur: que propose la version payante? Si les fonctionnalités premium sont cosmétiques, c’est souvent le signe que l’outil a atteint son plafond fonctionnel.
Quand le Kanban est devenu une commodité
En 2016, GitHub, Asana, Airtable et d’autres plateformes ont toutes intégré des vues Kanban dans leurs propres produits, transformant ce qui était l’innovation centrale de Trello en brique standard disponible partout. Justin Rosenstein, co-fondateur d’Asana, résumait la situation: “Nous voyons Trello comme une fonctionnalité, pas comme un produit.”
Cette commoditisation illustre un principe que les chefs de projet gagneraient à appliquer à leurs propres choix d’outillage: une interface de visualisation ne constitue pas un avantage décisif. Ce qui différencie un outil de gestion de projet performant d’un simple tableau de tâches, ce sont les capacités de planification, de suivi et d’anticipation qu’il met à disposition.
Ce qu’il faut chercher dans un outil de gestion de projet
L’expérience de Trello permet de dégager les dimensions fonctionnelles qu’un chef de projet devrait évaluer lorsqu’il choisit un outil pour un projet d’envergure.
La modélisation des dépendances est le premier critère. Sans elle, le chef de projet ne peut pas anticiper l’effet d’un retard sur une tâche en amont sur l’ensemble du calendrier. Il découvre les problèmes au lieu de les prévoir.
Le reporting intégré doit permettre de répondre à des questions simples mais essentielles: quel est l’avancement réel du projet? Le rythme actuel est-il compatible avec la date de livraison prévue? Si ces réponses nécessitent un export vers un tableur, l’outil ne remplit pas sa fonction.
La gestion de la charge par collaborateur permet d’identifier les goulots d’étranglement avant qu’ils ne provoquent des retards. Un outil qui montre les tâches sans montrer les personnes laisse le chef de projet sans visibilité sur la répartition réelle de la charge.
Le suivi des risques, même sous une forme simple (un registre avec probabilité, impact et plan de réponse), intégré dans le même environnement que la planification, évite la dispersion des informations critiques dans des documents annexes.
Enfin, la structuration hiérarchique du travail permet de piloter un projet à différents niveaux de granularité, du lot de travail global à la tâche individuelle, sans perdre la vision d’ensemble.
Adapter l’outil au projet, pas l’inverse
Le piège le plus fréquent n’est pas de choisir un mauvais outil, c’est de conserver trop longtemps un outil devenu inadapté. Les équipes s’habituent à compenser manuellement les manques: elles créent des tableaux de bord dans un tableur parallèle, gèrent les dépendances lors de réunions de synchronisation, suivent les risques dans un document que personne ne consulte régulièrement. Ces contournements ont un coût invisible en temps et en fiabilité. La trajectoire de Trello rappelle qu’un outil doit évoluer avec la complexité des projets qu’il sert, et que la facilité de prise en main ne compense pas l’absence de fonctionnalités structurantes quand le projet l’exige.