Mardi soir, 23h12. Mon fils dort depuis deux heures. J'ai trois onglets Cursor ouverts, un prompt à moitié écrit, et cette voix dans ma tête qui dit : dépêche-toi, t'as perdu la soirée, rattrape.
Alors je rush. Je code un truc. Je ship. Je me couche à 1h avec l'impression d'avoir avancé.
Le lendemain matin, en préparant le petit-déj, je regarde ce que j'ai pushé. C'est de la merde. Pas de la merde technique — de la merde stratégique. Un feature que personne n'a demandé. Un composant qui ne résout rien. Du mouvement sans direction.
L'accélération n'était pas un levier. C'était une fuite.
Sahil Bloom a posté un truc qui m'a arrêté net :
> "Major cheat code for life: Become difficult to rush."
Le monde te pousse à rusher. Décisions rushées. Conversations rushées. Timelines rushées. Et dans l'écosystème solopreneur/IA, c'est pire : chaque jour un nouveau modèle, un nouveau framework, un nouveau type sur Twitter qui a "buildé en 48h" ce que tu planifies depuis trois semaines.
Mais Sahil ne dit pas "sois lent". Il dit : deviens difficile à presser. C'est radicalement différent.
### Ce que la paternité solo m'a forcé à comprendre
Avant d'être papa solo, je pouvais rusher. Nuit blanche ? OK. Weekend de code ? Facile. Sprint de 72h pour un lancement ? Let's go.
Mon fils a tué cette option. Et c'est la meilleure chose qui me soit arrivée en tant que builder.
Quand tu as un enfant qui se réveille à 6h45 quoi qu'il arrive, tu ne peux plus tricher avec le temps. Tu as tes créneaux — 21h-23h en semaine, quelques heures le week-end pendant la sieste — et c'est tout.
Alors soit tu paniques et tu rushes dans ces créneaux. Soit tu acceptes la contrainte et tu deviens chirurgical.
J'ai fait les deux. Le rush m'a donné : trois projets abandonnés, un burnout silencieux en mars, et la culpabilité de m'être énervé sur mon fils parce que j'étais crevé par ma propre bêtise.
La lenteur stratégique m'a donné : un produit qui tourne, des utilisateurs qui reviennent, et assez d'énergie pour être présent au petit-déj.
Le choix est fait.
### Ship, learn — pas ship, ship, ship
La culture solopreneur vénère le shipping. "Ship fast, break things." "Launch in a weekend." Et l'IA a amplifié ça : avec Cursor et Claude, tu peux techniquement builder un MVP en 48h.
Mais pouvoir aller vite ne signifie pas que tu dois aller vite.
Le vrai cycle, celui qui construit quelque chose de durable, c'est ship, learn. Pas ship, ship, ship.
- Ship : mets un truc dehors. Petit. Imparfait. Mais réel.
- Learn : écoute. Regarde les données. Parle aux gens. Comprends ce qui manque.
- Puis ship à nouveau — mais cette fois, tu sais pourquoi.
Le rush supprime la phase "learn". Tu enchaînes les ships sans jamais absorber le feedback. Tu construis un château de features sur des fondations de suppositions.
J'ai un tableau dans Notion avec deux colonnes : "Shipped" et "Learned". Si la colonne Learned est vide depuis plus d'une semaine, je sais que je suis en train de rusher. Je m'arrête. Je ferme Cursor. Je vais marcher avec mon fils.
Et bizarrement, c'est souvent pendant ces marches que la vraie solution apparaît.
### Le test du produit creux
En janvier, j'ai rushé un outil d'automatisation de prompts. Trois nuits blanches. Fier de moi. Lancé un dimanche soir avec un post LinkedIn.
47 likes. 12 inscriptions. 0 utilisateurs actifs après une semaine.
Produit creux. Le pain qui s'effondre à la cuisson.
En avril, j'ai pris un autre angle. Même domaine — l'IA appliquée — mais cette fois, j'ai passé trois semaines à discuter avec des gens avant d'écrire une ligne de code. J'ai shippé un prototype moche. J'ai écouté. J'ai itéré. Lentement.
Résultat : moins spectaculaire au lancement. Pas de post viral. Mais des gens qui utilisent le truc tous les jours. Qui m'envoient des messages pour demander la suite.
La différence ? Trois semaines de fermentation vs trois nuits de rush.
### L'accélération comme fuite
Voici la vérité inconfortable : la plupart du temps, quand je rushe, ce n'est pas parce que j'ai un deadline. C'est parce que j'ai peur.
Peur que l'idée soit mauvaise — alors je code au lieu de valider.
Peur que quelqu'un d'autre lance avant moi — alors je bâcle au lieu de différencier.
Peur de l'inaction — alors je confonds agitation et progrès.
Le rush est l'anesthésiant de l'incertitude. Tant que tu codes, tu ne penses pas. Tant que tu ships, tu ne doutes pas. Tant que tu bouges, tu n'affrontes pas la question qui fait mal : est-ce que quelqu'un a vraiment besoin de ça ?
Devenir "difficult to rush", comme dit Sahil, c'est accepter de rester assis avec cette question. De la regarder en face. Et de ne bouger que quand tu as une réponse — même partielle.
### Mon nouveau rythme
Aujourd'hui, je builde comme je fais du pain.
Je mélange les ingrédients (idée + recherche utilisateur). Je pétris (prototype rapide). Puis je laisse lever. Longtemps. Je ne touche pas. Je fais autre chose. Je vis ma vie de père.
Et quand c'est prêt — quand le feedback a fait son travail, quand la structure est là — j'enfourne.
C'est moins sexy que "j'ai buildé ça en un weekend". Ça ne fait pas de bon contenu LinkedIn. Mais ça fait des produits qui tiennent. Et un père qui tient aussi.
La prochaine fois que tu te retrouves à 23h avec trois onglets ouverts et cette urgence artificielle dans le ventre, pose-toi une seule question :
Est-ce que j'avance, ou est-ce que je fuis ?
Si la réponse est honnête, tu fermeras le laptop. Et demain matin, au petit-déj, tu sauras exactement quoi builder.
Et si tu veux mettre l'IA au service de ton temps — un SaaS sur mesure ou une automatisation n8n — on en parle sur sebastiendebollivier.com.
