Combien de temps donner à un projet avant d'abandonner ?

La réponse tient en un chiffre : 30 jours, fixés à l'avance et annoncés à quelqu'un d'autre que toi. Pas parce que 30 est magique, mais parce que c'est le seuil le plus court qui laisse le temps de livrer une version réduite d'un projet, et le plus long qu'on peut tenir sans se mentir sur l'envie réelle de continuer. Voici pourquoi ce chiffre précis, et ce qui se passe si tu prends plus de temps ou moins.

Le chiffre qui compte, ce n'est pas la durée, c'est la date de fin

« Je me donne quelques mois pour voir » n'est pas un délai, c'est une façon polie de ne jamais trancher. Sans date de fin fixée à l'avance, chaque mauvais jour devient une raison de repousser la décision d'un mois de plus, et le projet meurt d'usure plutôt que d'un choix. Une date précise, posée le premier jour, change la question : elle ne devient plus « est-ce que j'ai encore envie aujourd'hui » mais « est-ce que ce sera fini à temps ».

Pourquoi pas six mois ou un an

Un horizon long a l'air raisonnable, il est en fait le plus dangereux : il donne à ton scope tout l'espace pour grossir. Une fonctionnalité de plus ici, un refactor propre là, et six mois suffisent à ne jamais rien sortir, parce que rien n'oblige à couper. La cause numéro un d'abandon n'est pas la difficulté du projet, c'est un scope trop large qu'on n'a jamais fini de réduire. Voir comment réduire un projet à son MVP pour la méthode qui force ce choix. Plus le délai est long, moins il force quoi que ce soit.

Pourquoi pas une semaine non plus

À l'inverse, un délai trop court pousse à bâcler ou à choisir une idée tellement petite qu'elle ne prouve rien. Sept jours suffisent à tester une hypothèse isolée, pas à construire quelque chose que tu peux montrer à un inconnu et lui demander de payer. Le seuil des 30 jours vient de là : c'est le plus court délai qui laisse le temps de couper un vrai scope à l'os sans le réduire à néant.

Le vrai test : la motivation survit-elle à l'ennui

Les deux ou trois premiers jours de n'importe quel projet carburent à la nouveauté, pas au projet lui même. Une fenêtre de 30 jours dépasse largement ce pic initial : elle t'oblige à traverser la partie ennuyeuse, les bugs répétitifs, les décisions sans gloire, là où la plupart des projets perso meurent en silence. Si l'envie tient jusqu'au jour 20 malgré l'ennui, ce n'est plus de l'enthousiasme de lancement, c'est un vrai signal.

Ce qui doit être vrai à la fin des 30 jours

• Quelqu'un d'autre que toi sait que le délai existe. Une deadline privée ne coûte rien à rater. Vue par des gens qui vont checker, elle devient réelle.
• Le scope tenait dans le délai dès le premier jour, pas un scope ambitieux réduit en catastrophe le jour 28.
• Il existe une version montrable, même imparfaite. Pas un projet terminé, un projet qu'un inconnu peut ouvrir et comprendre.

C'est tout le principe de la méthode Lance ou Dégage : un contrat de 30 jours signé devant d'autres makers qui voient ta progression, via le build in public, pas seulement le résultat final. Abandonner en cours de route devient visible au lieu de rester un secret entre toi et ton dossier de code jamais terminé. Si la question n'est plus « combien de temps » mais « est-ce que cette idée mérite seulement d'être tentée », comment valider une idée avant de se lancer vient avant ce chrono, pas après.

Envie de fixer ta propre date de fin, devant des gens qui vont checker ? Rejoins un sprint de 30 jours.