9 produits livrés en 11 mois en solo — voici exactement comment

La question qu'on me pose en entretien

"Vous avez livré 9 produits en 11 mois. C'est pas un peu… optimiste comme chiffre ?"

Non. C'est documenté, daté, observable sur GitHub. Et ce n'est pas un coup de force.

C'est un système. Reproduisible. Et la plupart de ce qui le rend possible n'a rien à voir avec écrire du code plus vite.

Le préalable : accepter de ne plus faire 80 % du travail "normal"

Quand on construit 9 produits seul, on apprend très vite ce qu'il faut arrêter de faire :

• Plus d'estimations. Je ne dis plus "ça prendra 3 semaines". Je dis "je livre quelque chose vendredi, on verra ce que c'est".

• Plus de specs avant code. Les specs servent à coordonner une équipe. Seul, je suis mon propre coordinateur. Je code une première version, je la regarde tourner, elle me dit ce qu'elle est.

• Plus de refactos esthétiques. Aucun de mes 9 produits n'a un code "joli". Ils ont un code qui marche et qui livre. La beauté coûte une semaine ; je n'ai pas une semaine.

• Plus de réunions internes. Évident en solo. Moins évident quand on a des co-modérateurs / contributeurs : je communique en async sur Discord, jamais en synchrone.

Ce que je remplace : un seul moment de réflexion sérieuse par semaine — le dimanche soir — où je décide ce qui passe en premier la semaine suivante. Tout le reste, c'est de l'exécution.

Ce que je paie une fois pour livrer dix fois

L'autre moitié de la productivité, c'est l'investissement en infrastructure personnelle. Pas pour les projets clients. Pour moi.

Quelques exemples concrets :

1. Un dépôt monorepo de "patterns réutilisables"

J'ai un repo portfolio-libs avec 8 bibliothèques que je publie en privé sur npm :

• @portfolio/crdt-engine — sync offline avec Yjs
• @portfolio/offline-core — gestion file d'attente + retry exponentiel
• @portfolio/map-engine — clustering 50 000 points à 60 FPS
• @portfolio/chart-kit — graphes SVG sans dépendance, moins de 2 Ko
• @portfolio/backend-kit — helpers Fastify
• @portfolio/vue-kit — composants Vue 3 réutilisés sur 3 projets
• @portfolio/mock-utils — données de test cohérentes
• @portfolio/build-config — config Vite / TypeScript partagée

Quand je commence un nouveau projet, je n'écris jamais un client offline. Je n'écris jamais un clustering de carte. Je n'écris jamais un graphe SVG. J'importe.

Coût d'extraction de ces 8 libs : ~3 semaines au total, étalées sur 1 an.

Économie par nouveau projet : 4-6 semaines.

À partir du 3e projet, c'est rentabilisé. Au 9e, c'est de l'effet de levier pur.

2. Un template d'architecture .NET / Blazor / Fusion

Tous mes SaaS .NET récents (OneRP, SaleCast, PromptVault, Racine) suivent exactement la même architecture :

src/
├── Application/
│   ├── Domains/         ← un dossier par bounded context
│   ├── Fusion/          ← ComputeServices + CommandHandlers
│   ├── Services/        ← services transverses
│   └── Database/        ← EF Core + migrations
├── Components/          ← pages Razor + composants UI
├── Properties/
└── Program.cs           ← copié-collé d'un projet à l'autre, 30 lignes

Chaque nouveau projet, je clone le squelette en 30 secondes. Mon Program.cs configure Fusion, EF Core, Serilog, Auth0, Hangfire en 30 lignes copiées-collées.

J'ai pas un IDE template official Visual Studio. J'ai un script bash :

salecast-clone() {
  cp -r ~/templates/blazor-fusion-saas ./"$1"
  cd ./"$1" && sed -i '' "s/__APP__/$1/g" $(grep -rl __APP__ .)
  echo "✓ projet $1 prêt en 2 secondes"
}

C'est moche. C'est efficace.

3. Une discipline brutale sur la première version

Voici le test que je fais sur chaque idée de feature :

"Si je devais montrer un screen de cette feature à un client demain matin, qu'est-ce qui doit absolument être dessus ? Tout le reste, je le coupe."

Exemples concrets :

• PromptVault : la première version n'avait pas d'authentification. Pas de comptes. Tu installais l'extension, ça marchait. J'ai ajouté Auth0 au mois 4, quand un client l'a demandé. Avant ça, des dizaines de personnes l'utilisaient sans login. Personne n'a râlé.

• SaleCast : la première version supportait un seul connecteur (PrestaShop). J'ai ajouté Shopify au mois 2, Amazon au mois 3, eBay/Magento/WooCommerce ensuite. Si j'avais voulu les 6 d'un coup, je ne les aurais jamais finis.

• Racine : la première version n'avait pas d'IA cadeau. C'était juste un arbre généalogique avec les anniversaires. L'IA est venue 2 mois après.

À chaque fois, le projet aurait été abandonné si j'avais voulu le finir avant de le montrer.

Le rythme réel

Voici ce à quoi ressemble une semaine standard chez moi :

Lundi      → Bug fix critiques sur le projet en production
              (1-2h max, sinon je décide qu'il peut attendre)
Mardi      → Feature principale projet 1 (4h focus block)
Mercredi   → Feature principale projet 2 (4h focus block)
Jeudi      → Refacto, dette technique, doc (sur 1 projet à la fois)
Vendredi   → Ship — finir une feature, déployer, communiquer
Samedi     → Off (rarement respecté, je sais)
Dimanche   → 1h de planification de la semaine suivante

Pas de mode "j'essaie de tout faire en parallèle". Chaque jour est dédié à un projet ou une tâche transverse. Le multi-tasking est un mensonge — il y a juste des switches de contexte qu'on ne voit pas.

Les 9 projets, pour ceux qui comptent

Pour qu'il n'y ait pas de doute sur la formule "9 produits en 11 mois" :

Aucun de ces produits n'est un prototype HTML mort. Tous tournent. Le plus petit (aiSelector) fait 4 000 lignes de C#. Le plus gros (SaleCast) fait 47 000.

Ce que ça donne en entretien

Quand un recruteur lit "9 produits en 11 mois", il me pose immédiatement la bonne question : "Comment tu choisis ce qui passe en premier ?"

Ma réponse est toujours la même :

"Je choisis ce qui apprend le plus. Pas ce qui rapporte le plus, pas ce qui est le plus mature, pas ce qui est le plus demandé. Ce qui m'apprend une compétence que je n'avais pas la veille."

Sur 18 mois, ça m'a fait apprendre :

• WebGPU + WGSL (Poisson) — sur du compute parallèle 100K éléments
• Fusion RPC + zero-REST (OneRP) — patterns que j'ai réutilisés sur 3 SaaS
• CRDT + Yjs (MyRoadTrip) — synchronisation distribuée field-level
• Foundation models en C# pur (SaleCast) — ONNX Runtime + ML.NET production
• Chrome MV3 + MutationObserver (PromptVault) — extensions production
• s&box / Source 2 (Ultra RP) — moteur 2026 avant tout le monde
• Multi-tenant scoped (Racine) — isolation EF Core au query level

C'est 7 nouvelles compétences techniques en 18 mois, toutes documentées par un produit qui tourne. Pas par une formation Udemy.

La leçon

Livrer vite n'est pas une question de vitesse. C'est une question de discipline sur ce qu'on refuse de faire.

Le développeur qui mettait 6 mois à livrer un produit fait probablement 60-70 % du travail "officiel". Spec, estimation, refacto, revues, réunions, démos, validations.

Moi je fais 100 % du travail qui livre. Et 0 % du reste.

À court terme, ça scandalise les processus. À moyen terme, ça produit 9 produits là où d'autres en produisent 1.

Et c'est cette différence-là qu'un recruteur veut comprendre quand il regarde un CV.