Journal de bord
Le cimetière des projets
Il reste des noms de domaine, des dépôts GitHub et des idées qu'on avait juré de terminer.
Ndiaga Ndiaye4 min de lecture
Journal de bordPartager sur LinkedIn
Journal de bord
Il reste des noms de domaine, des dépôts GitHub et des idées qu'on avait juré de terminer.
Quelque part, dans un compte GitHub, il existe un dépôt dont le dernier commit remonte à longtemps.
Le README est ambitieux.
La liste des fonctionnalités aussi.
Il y a même parfois un joli logo.
Et puis plus rien.
Pas de communiqué de fermeture.
Pas de cérémonie.
Juste une dernière modification, suivie d'un silence qui dure.
Bienvenue au cimetière des projets.
Je crois que beaucoup de développeurs connaissent cet endroit.
Moi, en tout cas, je reconnais très bien le chemin qui y mène. 😅
Un problème apparaît.
On imagine une solution.
On choisit une stack, on crée un dépôt, on prépare quelques maquettes.
Les premières heures sont formidables.
Tout est encore possible.
L'application n'a pas de bugs parce qu'elle n'a presque pas de fonctionnalités.
Elle n'a pas de clients mécontents parce qu'elle n'a pas encore de clients.
Et dans notre tête, la version finale fonctionne déjà parfaitement.
C'est peut-être le moment le plus dangereux.
Parce que construire quelque chose est parfois beaucoup plus amusant que découvrir si quelqu'un en a besoin.
Au début, on développe.
Ensuite, il faut expliquer le produit.
Le faire connaître.
Répondre aux premières questions.
Corriger les comportements inattendus.
Faire de la documentation.
Payer l'hébergement.
Revenir le lendemain.
Puis le surlendemain.
Et recommencer lorsque personne ne semble particulièrement impressionné.
Le travail devient moins spectaculaire.
Une correction de formulaire n'a pas le charme d'une nouvelle page d'accueil.
Un échange avec un utilisateur frustré ne ressemble pas au plaisir de choisir une architecture.
Mais c'est souvent là qu'un prototype commence à devenir un vrai produit.
On imagine volontiers que les projets meurent parce qu'ils étaient mauvais.
Parfois, oui.
Mais pas toujours.
Certains deviennent trop coûteux à maintenir.
D'autres répondent à un besoin trop limité.
D'autres encore perdent leur place face aux obligations professionnelles, familiales ou financières.
Et puis il y a ceux qui avaient surtout besoin d'exister quelques semaines, le temps de nous apprendre quelque chose.
Ce n'est pas agréable à admettre.
Surtout lorsqu'on a présenté une idée avec beaucoup d'enthousiasme.
Mais abandonner un projet n'est pas forcément abandonner une ambition.
Parfois, c'est arrêter de financer une hypothèse qui ne tient plus.
Lorsque l'intérêt du public tarde à venir, le réflexe du développeur est assez prévisible.
Ajouter quelque chose.
Un tableau de bord.
Une option premium.
Un moteur de recherche.
Une animation.
Comme si l'application attendait simplement sa prochaine fonctionnalité pour devenir indispensable.
Je connais bien cette tentation.
J'en ai même fait un billet : La fonction de trop.
Ce que l'on devrait parfois ajouter, ce n'est pas une nouvelle ligne de code.
C'est une conversation avec quelqu'un qui pourrait réellement utiliser le produit.
Avec KUMBA et KAMIT, je me pose régulièrement la même question : qu'est-ce qui mérite encore du temps ?
Je pourrais occuper toutes mes soirées à ouvrir de nouveaux chantiers.
Les idées ne manquent pas.
Ce qui manque, c'est la possibilité de les poursuivre toutes sérieusement.
Alors j'essaie d'apprendre à distinguer trois choses.
Ce que je veux créer.
Ce que je peux entretenir.
Et ce qui apporte vraiment quelque chose à d'autres personnes.
Les trois ne se rejoignent pas toujours.
Un projet arrêté ne devrait pas devenir un piège pour ses utilisateurs.
S'il contient des données, il faut penser à leur récupération ou à leur suppression.
S'il promet encore un service, il faut éviter de laisser croire qu'il est maintenu.
S'il utilise des clés d'accès ou des ressources payantes, il faut les désactiver correctement.
Et si le code peut servir à quelqu'un, peut-être mérite-t-il une dernière documentation.
Même un projet abandonné peut être terminé avec sérieux.
Je ne pense pas qu'il faille être fier d'avoir cinquante dépôts inachevés.
Mais je ne crois pas non plus qu'il faille en avoir honte.
On peut y retrouver une mauvaise décision, une bonne intuition, une technique découverte ou une idée qui n'était simplement pas arrivée au bon moment.
Tout cela ne justifie pas de continuer indéfiniment.
Cela mérite parfois d'être conservé comme une leçon.
Un projet n'a pas besoin de devenir une entreprise pour nous avoir appris quelque chose.
Il faut simplement éviter de prendre chaque nouvelle idée pour une promesse qu'on sera obligé de tenir toute sa vie.
Sinon, le cimetière risque de manquer de place. 😅
