Projet indie à temps partiel : les vraies contraintes que personne n'avoue

En bref — Construire un projet indie à temps partiel ne se résume pas à ‘trouver 2 heures par jour’ : ce sont tes réserves d’énergie cognitive — pas ton agenda — qui dictent ce que tu peux produire. Les stratégies qui fonctionnent en situation contrainte sont radicalement différentes de celles vendues par les gourous du side project.

---

La phrase revient dans tous les threads. “Deux heures par jour, et en six mois tu as un produit.” Dix mille likes, deux cents commentaires enthousiastes, et personne pour demander : deux heures de quoi, quand, et dans quelle condition de vie ?

Moi j’ai construit mes premiers produits pendant que je travaillais à temps plein. Et depuis que je construis SEK — mon studio indie — j’ai un fils qui vient de naître, une adolescente, et une vraie vie hors écran. La question du temps partiel n’est pas une phase passagère à traverser en serrant les dents. C’est une condition permanente pour beaucoup d’entre nous. Autant regarder les choses en face.

L’illusion des « 2 heures par jour » : ce que les gourous ne montrent pas

La promesse a l’air solide. Deux heures par jour, c’est 14 heures par semaine. En un mois, tu approches 60 heures. Sur un an : 720 heures. Les maths fonctionnent. Ce qui ne fonctionne pas, c’est la prémisse.

La première erreur, c’est de confondre temps disponible et temps utilisable. Il y a une différence fondamentale entre deux heures libres à 7h du matin, reposé, café en main, et deux heures récupérées à 22h après une journée de réunions, un dîner de famille et une mise au lit qui a duré trop longtemps. Dans les deux cas, l’agenda affiche “disponible”. Dans les deux cas, le résultat n’a rien à voir.

La deuxième erreur, c’est le silence sur le type de travail. Certaines tâches — debug complexe, architecture de base de données, écriture de contenu dense — réclament un état de concentration qu’on appelle parfois deep work. Ces tâches s’effondrent dès qu’on est fatigué ou interrompu. D’autres — répondre à des emails, mettre à jour une doc, tester une interface — se font en mode dégradé sans trop de casse. Les gourous ne séparent jamais les deux.

La troisième erreur est la plus silencieuse : la dette d’attention. Une journée de travail salarié consomme de l’énergie cognitive, même si tu n’as pas l’impression d’avoir “travaillé dur”. Les open spaces, les Slack qui clignotent, les réunions qui n’ont pas lieu d’être : tout ça érode la ressource la plus précieuse pour un maker, qui est la bande passante mentale disponible pour prendre des décisions de qualité.

Ce n’est pas du pessimisme. C’est un diagnostic honnête. Et un diagnostic honnête, c’est le seul point de départ utile.

Cartographier ton énergie disponible, pas ton agenda

Avant de bloquer des créneaux dans ton calendrier, fais un autre exercice : cartographie ton énergie sur une semaine type. Pas les heures libres — l’état mental à ces heures.

Concrètement : pendant 5 à 7 jours, note en fin de journée les moments où tu t’es senti capable de résoudre un problème nouveau. Pas “j’avais du temps”, mais “j’avais la bande passante pour décider, créer, avancer”. Pour la plupart des gens qui combinent emploi et projet, ces fenêtres sont au nombre de deux ou trois par semaine, rarement plus. Et elles sont souvent le matin, en début de semaine.

L’enseignement pratique : arrête de distribuer tes tâches de façon uniforme sur la semaine. À la place, identifie tes 2-3 “blocs d’énergie haute” et réserve-les exclusivement pour le travail de fond — les décisions importantes, le code qui exige de la clarté, la stratégie produit. Tout le reste — les tâches mécaniques, les reviews, les petites publications — peut aller sur des créneaux d’énergie basse.

Un exemple générique qui illustre bien la mécanique : imagine un développeur avec un emploi à temps plein et un enfant en bas âge. S’il essaie de travailler sur son projet tous les soirs, il produit peu, de mauvaise qualité, et se sent constamment épuisé. S’il concentre tout son effort sur le mardi et le jeudi matin (levé une heure plus tôt), avec rien d’autre sur ces créneaux, il avance réellement. Ce n’est pas une question de discipline — c’est une question de physiologie et de design de rythme.

La famille, elle, impose ses propres contraintes non négociables. Avec mon fils tout jeune et mon adolescente, les soirs de semaine sont souvent hors scope pour le travail profond. Je n’en fais pas une tragédie — j’en fais un paramètre de design. La contrainte est réelle, elle se contourne ou elle se planifie, elle ne se nie pas.

Les 3 types de tâches à prioriser quand tu as 45 minutes devant toi

Quarante-cinq minutes est probablement la durée de créneau la plus courante pour un salarié avec une vie. Pas deux heures, pas une journée entière : 45 minutes entre deux engagements. Voilà comment les utiliser sans les gaspiller.

1. Les décisions irréversibles qui débloquent la suite

C’est la catégorie la plus rentable et la plus souvent évitée, parce qu’elle est inconfortable. Choisir ta stack technique. Définir le périmètre MVP. Décider de pivoter ou de tenir sur ton positionnement. Ces décisions ont tendance à stagner parce qu’elles font peur — et on les remplace par des tâches de confort (encore un peu de research, encore un redesign de wireframe).

Un créneau de 45 minutes bien disposé suffit pour trancher l’une de ces questions, à condition d’arriver avec le problème déjà posé sur papier, pas à résoudre à chaud. La règle : si une décision bloque deux autres tâches en aval, elle passe en priorité absolue sur le prochain créneau d’énergie haute. Pas dans une semaine.

2. Les micro-livraisons publiables immédiatement

Ce sont les petites unités de valeur qu’on peut livrer d’un coup : une page de landing publiée, un article court mis en ligne, une feature minuscule mais fonctionnelle déployée, un email envoyé à une liste — même petite. Ces micro-livraisons ont deux vertus. D’abord, elles font exister le projet dans le monde réel, ce qui change radicalement la dynamique mentale. Ensuite, elles génèrent parfois un feedback immédiat qui t’oriente sans avoir à deviner.

La tentation inverse — accumuler du travail invisible pendant des semaines avant de livrer quoi que ce soit — est le piège classique du side project salarié. On prépare, on améliore, on peaufine. Et rien n’arrive en dehors de son disque dur.

3. Les boucles de feedback actives

Une conversation avec un utilisateur potentiel. Un post dans une communauté de makers pour tester une idée. Un formulaire Typeform posté dans un Slack. Ces actions prennent 15 à 30 minutes et valent plus que des heures de travail en chambre, parce qu’elles confrontent tes hypothèses à la réalité.

Dans un projet indie, le feedback loop est souvent la ressource la plus sous-utilisée. Les gens ont peur du regard extérieur sur quelque chose d’inachevé. Mais un projet en temps partiel ne peut pas se permettre de construire pendant 6 mois avant de montrer quoi que ce soit : tu n’as pas 6 mois de runway cognitif à dilapider dans la mauvaise direction.

Si le sujet te parle, le dossier statistiques solopreneur & IA 2026 donne du contexte sur l’économie de ces projets en solo — sans chiffres fabriqués.

Comment l’IA compresse le temps de production sans compresser la qualité

C’est là que la donne change vraiment par rapport à ce qui était possible il y a cinq ans.

L’IA ne crée pas des heures supplémentaires dans ta journée. Elle compresse certaines phases de production qui, auparavant, consommaient des créneaux entiers d’énergie haute pour un résultat souvent médiocre si on était fatigué.

Voilà les phases où le gain est réel et mesurable, dans mon expérience directe :

Le code boilerplate et la plomberie. Générer la structure initiale d’un projet, écrire des tests unitaires répétitifs, créer des migrations de base de données — ce sont des tâches à faible valeur cognitive mais à forte consommation de temps. Un agent bien configuré les traite en minutes. Tu gardes ton énergie haute pour les décisions d’architecture qui, elles, réclament un jugement humain.

Les premiers jets de contenu. Articles, descriptions produit, emails de séquence d’onboarding — l’IA produit un premier jet solide à partir d’un brief bien formulé. Le brief, lui, réclame ta pensée propre. La révision, elle aussi. Mais la page blanche et la structure de base disparaissent du problème.

Le debugging de premier niveau. Coller un stack trace dans un agent et obtenir les 3 hypothèses les plus probables : ça ne remplace pas le diagnostic, mais ça divise par deux le temps passé à chercher dans la mauvaise direction.

L’administration invisible. Répondre à des demandes standard, suivre des tickets, faire du reporting : la charge mentale de ces tâches est disproportionnée par rapport à leur valeur. L’automatisation partielle (agents, workflows) n’est pas de la paresse — c’est de la récupération de bande passante pour ce qui compte.

Ce que l’IA ne fait pas, et il faut l’assumer honnêtement : elle ne prend pas les décisions stratégiques à ta place. Elle ne sait pas si ton produit va trouver sa clientèle. Elle ne détecte pas que tu construis la mauvaise chose. Ce jugement-là reste humain, il réclame du recul, de l’exposition au terrain, et une capacité à tirer un signal du bruit. Aucun outil ne te le confisque, mais aucun outil ne te le remplace non plus.

La combinaison gagnante en temps partiel : l’IA absorbe la charge mécanique, toi tu concentres tes créneaux d’énergie haute sur les décisions et les interactions qui exigent ton jugement. Ce n’est pas une promesse — c’est ce que je pratique dans la construction de SEK depuis que l’outillage IA a atteint un niveau d’utilité réelle.

Pour aller plus loin sur l’aspect technique sans te retrouver bloqué, /unstuck/ est fait pour ça : déblocage rapide sur un point précis, sans perdre une demi-journée à tourner en rond.

Ce que le temps partiel t’apprend que le full-time ne peut pas

Il y a une chose que les gens qui ont sauté tout de suite dans le full-time indie ne réalisent pas toujours : la contrainte de temps partiel force une sélection impitoyable.

Quand tu as du temps illimité (ou ce qui y ressemble), tu peux te permettre de travailler sur des tâches basses priorité sans trop en souffrir. Tu peux refaire le design trois fois, explorer des features qui n’ont pas de demande validée, passer une semaine sur un détail technique que personne ne verra jamais. Le temps partiel, lui, ne laisse pas cette latitude.

Chaque créneau compte assez pour que tu te poses la question : est-ce que c’est la chose la plus importante à faire maintenant ? Cette discipline, imposée par la contrainte, est souvent ce qui distingue les projets qui avancent de ceux qui stagnent dans un backlog infini.

Le salariat donne aussi un filet que l’euphorie du “je me lance” masque facilement. Les décisions sous pression financière sont parmi les pires décisions produit. Brûler son runway trop vite, accepter n’importe quel client pour payer les factures, sous-évaluer son offre parce qu’on a peur : ces patterns arrivent presque systématiquement quand on a sauté trop tôt. Le temps partiel, lui, permet de valider avant de dépendre.

Ce n’est pas une raison de rester salarié indéfiniment. C’est une raison de rester salarié tant que le produit n’a pas prouvé quelque chose. Un signal de traction, même faible — premiers utilisateurs payants, liste email qui grandit, feedback enthousiaste d’un segment précis — change complètement l’équation.

---

Construire en solo, avec peu de temps et une vraie vie autour : c’est une contrainte, pas une malédiction. Ce qui tue les projets indie en temps partiel, ce n’est pas le manque d’heures. C’est l’illusion qu’on peut tout faire, le manque de sélection des tâches, et l’énergie gaspillée à faire semblant que les soirs épuisés valent les matins clairs.

Ce que je pratique chez SEK n’est pas un système parfait. C’est un système honnête, ajusté à une vie réelle avec deux enfants, un studio à construire, et zéro envie de sacrifier l’un pour l’autre.

Si tu construis aussi quelque chose depuis une position contrainte et que tu veux un regard externe sur ta progression technique, Sébastien De Bollivier travaille en freelance avec des projets à exactement ce stade.

Une idée à shipper ? Un site, un SaaS, une automatisation IA — construits avec toi.

Parler de ton projet