Je commence toujours des side projects mais je ne les livre jamais
Un plan d’exécution de 90 jours pour transformer l’énergie du week-end en valeur livrée à des utilisateurs.
Commencer un side project paraît simple.
L’idée est évidente. La première version semble proche. La stack est amusante. Le week-end laisse juste assez d’espace pour avancer.
Puis le projet grossit.
Une fonctionnalité devient trois. La landing page doit être polie. L’onboarding n’est pas tout à fait prêt. L’analytics peut attendre. L’idée change de forme. Quelques semaines plus tard, le repo existe, mais personne ne l’utilise.
Ce n’est pas de la paresse.
La plupart des side projects n’échouent pas parce que la personne qui construit s’en fiche.
Ils échouent parce que construire continue de ressembler à du progrès longtemps après que livrer a disparu.
Pourquoi les side projects se bloquent
Les side projects sont fragiles parce qu’ils vivent sur l’énergie restante.
Après le travail, la famille, l’administratif et la vie normale, le projet reçoit ce qu’il reste d’attention. Le plan doit donc être brutalement clair.
Mais la plupart des plans de side project sont vagues :
- construire le MVP,
- nettoyer l’UI,
- ajouter l’auth,
- écrire du contenu,
- améliorer le produit,
- lancer bientôt.
Ce ne sont pas des actions hebdomadaires.
C’est du brouillard.
Un système utile pour side project doit protéger quatre choses :
- un petit résultat utilisateur,
- une limite de MVP dure,
- du vrai feedback avant plus de polish,
- un signal visible de livraison chaque semaine.
Sans cela, le projet dérive vers la construction privée.
Le mini diagnostic
Si vous commencez toujours des side projects sans les livrer, vérifiez quelle faille casse la boucle.
1. Le résultat utilisateur n’est pas assez petit
“Construire une app pour les créateurs” est trop large.
“Aider un créateur à rédiger trois meilleures réponses sponsor en 10 minutes” est assez petit pour être testé.
La version plus petite n’est pas moins ambitieuse. Elle est plus livrable.
Demandez :
- Qui est le premier vrai utilisateur ?
- Quel travail la première version doit-elle l’aider à faire ?
- Quel résultat peut-il ressentir en une session ?
- Que peut-on retirer sans casser ce résultat ?
Si le résultat utilisateur est vague, chaque fonctionnalité paraît nécessaire.
2. La limite du MVP continue de bouger
Le scope creep est discret parce que chaque fonctionnalité supplémentaire semble raisonnable.
Le projet “a juste besoin” d’un réglage de plus, d’un dashboard de plus, d’une étape d’onboarding de plus, d’une intégration de plus.
Mais la limite du MVP n’est pas la liste de tout ce qui rendrait le projet sympa.
C’est la plus petite version capable de créer un signal utile.
Un side project a besoin d’une règle comme :
Si cela n’aide pas le premier utilisateur à atteindre le premier résultat, cela attend.
Cette règle empêche l’énergie de fuir vers du travail optionnel.
3. Le feedback arrive trop tard
Construire en privé est confortable.
Le feedback l’est moins, parce qu’il peut révéler que l’idée est confuse, inutile ou destinée à la mauvaise personne.
Mais le feedback tardif coûte cher.
Vous n’avez pas besoin d’un grand lancement pour obtenir un signal. Vous avez besoin de quelque chose d’assez spécifique pour le montrer à quelques personnes :
- une démo brute,
- un flow cliquable,
- une landing page avec une seule promesse,
- un court Loom,
- une version manuelle du workflow,
- un premier utilisateur que vous observez pendant l’utilisation.
Le but n’est pas d’obtenir des compliments.
Le but est d’apprendre ce qui doit changer avant de construire un mois de plus.
4. La distribution est traitée comme une dernière étape
Beaucoup de side projects sont construits comme si les utilisateurs arrivaient après le lancement.
Cela arrive rarement.
La distribution fait partie du projet, pas de la célébration après le projet.
Chaque semaine doit inclure une action visible de distribution :
- l’envoyer à trois personnes précises,
- poster une démo concrète,
- poser une vraie question de problème dans une communauté,
- écrire une courte page de cas d’usage,
- relancer quelqu’un qui a montré de l’intérêt,
- demander à un utilisateur ce qui l’a bloqué.
Si personne ne voit le projet, le projet ne peut rien vous apprendre.
Un plan simple de side project sur 90 jours
Utilisez cette structure comme première version.
Résultat
En 90 jours, livrer la plus petite version du side project qui aide un groupe d’utilisateurs clair à obtenir un résultat utile, puis utiliser le vrai feedback pour décider quoi construire ensuite.
Jalon 1 : figer le premier résultat
Écrivez le premier résultat en une phrase :
- utilisateur,
- problème,
- résultat,
- temps ou effort économisé,
- preuve que le résultat a eu lieu.
Exemple :
Aider des fondateurs solo à transformer des notes de lancement brouillonnes en plan d’action hebdomadaire d’une page en moins de 15 minutes.
Puis retirez tout ce qui ne soutient pas ce résultat.
Jalon 2 : livrer une version visible
La version visible n’a pas besoin d’être complète.
Elle doit être assez utilisable pour créer un signal :
- quelqu’un l’essaie,
- quelqu’un répond,
- quelqu’un dit ce qui l’a confus,
- quelqu’un demande une pièce manquante,
- quelqu’un dit qu’il ne l’utiliserait pas et pourquoi.
Ce signal vaut plus qu’une fonctionnalité privée de plus.
Jalon 3 : construire la boucle de feedback
Chaque semaine, répétez la même boucle :
- livrer une petite amélioration,
- la mettre devant de vraies personnes,
- capturer le feedback,
- décider quoi couper, garder ou changer,
- choisir une prochaine action.
Le projet survit parce que la boucle survit.
Boucle d’exécution hebdomadaire
Lancez cette boucle une fois par semaine :
- Choisissez le plus petit résultat utilisateur pour cette semaine.
- Coupez une fonctionnalité ou tâche qui ne sert pas ce résultat.
- Livrez un artefact visible, même petit.
- Demandez du feedback à trois personnes précises.
- Décidez la prochaine action à partir du signal, pas du backlog d’idées.
C’est la différence entre “je travaille sur un side project” et “je livre un side project”.
Transformez cela en plan
Si votre side project redémarre toujours avec une nouvelle excitation mais sans valeur livrée à des utilisateurs, ne commencez pas par réorganiser le backlog.
Commencez par la douleur :
Je commence toujours des side projects, mais je ne les livre jamais.
Puis transformez-la en système d’exécution de 90 jours : un résultat utilisateur, une limite de MVP dure, des signaux de livraison hebdomadaires, des boucles de feedback et des prochaines actions.
Utilisez le Générateur de plan d’exécution de 90 jours pour créer une première version. Quand la prévisualisation est utile, sauvegardez-la comme mission X18 vivante pour que le projet continue d’avancer après le week-end.
