Sprint de 10 jours : comment je livre un module production-ready

Pourquoi un format aussi contraint

La plupart des collaborations freelance échouent sur la même chose : un scope flou, des semaines sans visibilité, et un livrable qui n'est « presque fini » que pour celui qui l'a écrit. Le Sprint Produit est ma réponse à ces trois risques — 10 jours, un scope figé par écrit, un prix fixe (4 500 € HT), et un artefact livré chaque jour.

Le périmètre est réduit volontairement. Un module, une feature, une intégration IA — pas trois. C'est ce qui permet de finir, au sens production du terme : mergé, testé, déployé, transféré.

Jour 0 — le cadrage (gratuit, et éliminatoire dans les deux sens)

Tout commence par un appel de 30 minutes, gratuit. Son but n'est pas de vendre : c'est un go/no-go honnête. J'y pose les questions qui fâchent — qu'est-ce qui existe déjà, qu'est-ce qui a déjà été tenté, qui maintiendra le module après moi, et à quoi ressemble « réussi » pour vous, en une phrase mesurable.

Deux issues possibles :

• No-go : je ne suis pas le bon profil, ou le sujet ne tient pas en 10 jours sans le dénaturer. Je le dis tout de suite, et j'oriente si je peux.
• Go : vous recevez sous 48 h une proposition écrite d'une page — scope figé, critères de succès explicites, prix fixe, conditions (50 % au kick-off, 50 % à la livraison).

Ce document est le contrat moral du sprint. Tout ce qui n'y est pas n'est pas dans le sprint — c'est ce qui protège le délai, et donc votre budget.

J1 — kick-off : l'architecture avant le code

Le premier jour ne produit pas de feature. Il produit le cadre qui rend les neuf suivants rapides :

• accès à votre repo, votre CI, votre staging — je travaille chez vous, pas sur un clone qui divergera ;
• décisions d'architecture posées par écrit : où vit le module, quelles frontières avec l'existant, quels patterns (les vôtres d'abord — un module qui détonne avec le reste du codebase est une dette, pas un cadeau) ;
• branche dédiée, squelette compilable, premier commit en fin de journée.

Vous recevez le soir même le premier point d'avancement écrit : cinq lignes, ce qui est fait, ce qui bloque, ce qui arrive demain. Vous en recevrez un chaque jour ouvré — c'est non négociable, c'est ce qui remplace la réunion de suivi.

J2-J7 — l'implémentation, avec une démo à mi-parcours

Six jours de construction, avec deux disciplines :

Les tests accompagnent le code, ils ne le suivent pas. Les chemins critiques du module sont couverts au fur et à mesure — unitaires sur la logique, intégration sur les frontières. C'est ce qui rend le J10 serein au lieu d'héroïque.

La démo de mi-parcours (autour de J5) est sur du vrai. Pas des slides : le module qui tourne, branché sur vos données de staging. C'est le moment où on ajuste — un détail d'UX, un cas métier oublié au cadrage. Les ajustements qui tiennent dans l'enveloppe sont intégrés ; ceux qui n'y tiennent pas sont notés pour un éventuel sprint suivant, et on le dit clairement.

J8-J9 — staging, monitoring, et la production si elle est prête

Un module « fini sur ma machine » n'est pas fini :

• déploiement sur votre staging via votre CI/CD (je la complète si nécessaire, je ne la remplace pas) ;
• monitoring branché : logs structurés, métriques sur les chemins critiques, alerte sur ce qui doit réveiller quelqu'un ;
• passage en production si vos process le permettent dans la fenêtre — sinon, tout est prêt pour que votre équipe le fasse sans moi.

J10 — la livraison qui ne crée pas de dépendance

Le dernier jour est entièrement consacré au transfert :

• démo finale face aux critères de succès écrits au J0 — chaque critère est vert, ou son état est documenté sans ambiguïté ;
• PR mergée dans votre branche principale, revue par votre équipe si vous en avez une ;
• doc d'architecture : les décisions prises et leur pourquoi, pas un roman — ce qu'il faut pour que le prochain dev ne défasse pas en un mois ce qui a été pensé en dix jours ;
• session de transfert en visio avec votre équipe : le code, les choix, les pièges, les questions.

Après le J10, les questions et correctifs sur le périmètre livré sont inclus. L'objectif est explicite : aucune dépendance à ma présence. Si votre équipe ne peut pas faire évoluer le module sans moi, j'ai raté quelque chose.

Ce que je refuse de mettre dans un sprint

Le format ne convient pas à tout, et le dire fait partie de l'offre :

• une refonte complète — 10 jours n'y suffisent pas, et prétendre l'inverse produit du travail bâclé ;
• un scope qui dépend d'inconnues externes non maîtrisées (un prestataire tiers qui doit livrer « bientôt », une API pas encore documentée) ;
• du legacy figé sans marge de manœuvre — si rien ne peut bouger, personne ne peut livrer proprement dedans.

Pour ces cas-là, le bon format est une mission longue — ou parfois, honnêtement, autre chose qu'un freelance.

Les questions qu'on me pose au cadrage

Pourquoi un prix fixe plutôt qu'un TJM ? Parce que le risque de dépassement doit être chez moi, pas chez vous. Le scope figé est la contrepartie : c'est lui qui rend le prix fixe tenable.

Et si le sprint révèle un problème plus gros ? Ça arrive — un sprint est aussi un audit grandeur nature de votre codebase. Le problème est documenté, chiffré, et vous décidez : sprint suivant, mission longue, ou rien. Sans pression — le livrable du sprint en cours reste dû.

10 jours consécutifs ? Pleins mais étalables sur 3 semaines — ça absorbe vos contraintes de planning et les miennes sans diluer l'engagement.

Le détail de l'offre, les tarifs et les autres formats sont sur la page services. Et si vous voulez vérifier que je livre vraiment — quatre de mes produits sont en ligne, testables publiquement.