Qu’est-ce qu’un sprint ? Le guide du fondateur non technique

Un sprint, c’est l’horloge de votre projet logiciel. Comprenez comment il fonctionne et vous gardez le contrôle du build sans devenir manager technique. Ratez-le, et vous découvrez trop tard que vous avez payé deux semaines qui n’ont rien produit.

Un fondateur qu’on connaît a envoyé un message un samedi soir, à la troisième semaine du projet : « l’équipe dit qu’elle va livrer au prochain sprint, mais personne ne m’a expliqué ce que ça veut dire et j’ai déjà dépensé la moitié du budget. » Il n’était pas lent. C’était un ancien consultant qui savait lire un bilan. Personne n’avait simplement traduit « sprint » dans la seule langue qui comptait pour lui : celle de l’argent et du contrôle.

Un sprint est un cycle de travail court et fixe, généralement de deux semaines, pendant lequel une équipe de développement s’engage à livrer une partie fonctionnelle de votre logiciel. À la fin du sprint, quelque chose tourne, vous le testez, et l’équipe démarre le cycle suivant. C’est l’unité de temps de base du développement logiciel moderne et le cœur du cadre Scrum. Ça, c’est la définition de dictionnaire. La partie utile, celle que personne n’écrit pour qui paie la facture, arrive maintenant.

Le sprint n’est pas une cérémonie technique. C’est votre point de contrôle.

Presque tous les articles sur le sprint ont été écrits pour ceux de l’intérieur : le scrum master, les développeurs, la personne qui anime la daily. Ils expliquent le rituel. Vous n’avez pas besoin du rituel. Vous avez besoin de savoir une chose : le sprint est l’intervalle le plus court dans lequel vous pouvez répondre à la question « l’argent qui est entré s’est-il transformé en logiciel qui fonctionne ? ».

En dehors du logiciel, vous fonctionnez déjà comme ça. Un restaurant fait sa caisse tous les soirs. Une équipe commerciale revoit son pipeline chaque semaine. Le sprint, c’est la clôture de caisse de votre build. Toutes les deux semaines, le projet cesse d’être une promesse et devient quelque chose que vous pouvez ouvrir dans un navigateur et tester. Sans ce point d’arrêt, le développement devient une boîte noire de trois mois où vous signez des chèques et vous priez.

C’est pour ça que la durée est fixe et courte. Si un sprint durait trois mois, vous découvririez un problème de cap trop tard pour le corriger à bon compte. Avec deux semaines, le pire cas, c’est de perdre deux semaines. Cher, mais rattrapable. Le sprint transforme un grand risque opaque en une série de petits risques visibles.

Combien de temps dure un sprint (et pourquoi c’est presque toujours deux semaines)

Scrum autorise des sprints d’une à quatre semaines. En pratique, le standard du marché pour les produits en phase précoce est de deux semaines, et il y a une raison opérationnelle derrière.

Une semaine, c’est trop court : la moitié du temps part en planification et en review, il reste peu pour construire. Quatre semaines, c’est trop long : vous reperdez la visibilité, et un mauvais virage coûte un mois. Deux semaines, c’est le point où l’équipe a assez de temps pour livrer quelque chose de réel et où vous avez assez de fréquence pour ne pas perdre le contrôle.

Si un prestataire vous propose des sprints de quatre semaines ou, pire, « nous ne travaillons pas en sprints, on livre tout à la fin », prenez-le comme un signal. Ce n’est pas forcément de la fraude. Mais c’est moins de visibilité pour vous, et la visibilité, c’est justement ce que vous achetez quand vous externalisez un build sans avoir un CTO qui surveille.

Ce qui se passe dans un sprint, depuis votre siège

Un sprint a quatre moments. La littérature technique traite les quatre comme des rituels d’équipe. Voici ce que chacun signifie pour vous, la personne qui paie.

Sprint planning (le début). L’équipe décide quoi construire durant les deux prochaines semaines, en tirant des éléments du backlog, la liste priorisée de tout ce dont le produit a besoin. Votre rôle ici est court et décisif : garantir que ce qui entre dans le sprint est ce qui compte le plus pour le business maintenant, pas ce qui est le plus amusant à coder. Vous ne décidez pas le comment. Vous défendez le quoi.

La daily (le milieu). Une conversation courte et quotidienne où l’équipe se synchronise. Vous n’avez presque jamais besoin d’y être. Si un prestataire exige votre présence à la daily tous les jours, quelque chose ne va pas : soit ils ne savent pas s’organiser, soit ils essaient de faire de vous le chef de projet que vous avez engagé précisément pour ne pas l’être.

Sprint review (la fin, et la partie qu’on ne saute pas). Le dernier jour, l’équipe vous montre ce qu’elle a construit, qui fonctionne. Pas des slides. Pas « c’est à 80 % ». Du logiciel qui tourne. C’est la réunion la plus importante de votre mois. C’est là que vous vérifiez si l’argent est devenu produit, que vous le testez de vos propres mains, et que vous dites ce qui est bon et ce qui est revenu de travers. Si vous ne pouvez participer qu’à une seule chose dans tout le projet, participez à la review.

Rétrospective (l’entretien du moteur). L’équipe discute de comment améliorer son propre processus. C’est interne. Vous n’avez pas besoin d’y être, mais ça vaut le coup de demander, de temps en temps, ce qui en est sorti. Une équipe qui ne change jamais rien en rétrospective est une équipe qui n’apprend pas.

Comment le sprint protège votre budget

Voici la vraie raison de vous en soucier. Le sprint est la meilleure défense qui existe contre les deux façons les plus courantes dont un projet logiciel brûle de l’argent : le scope creep et un build qui s’éloigne du business.

Parce qu’un sprint a un périmètre fixe, il crée une frontière. Cette idée géniale qui vous est venue le mercredi ne fait pas irruption au milieu du sprint en cours pour bousculer ce qui a été convenu. Elle part au backlog et entre dans le prochain sprint, quand vous et l’équipe réévaluez les priorités à tête reposée. La frontière du sprint, c’est ce qui empêche chacun de vos éclairs d’inspiration de devenir une urgence pour l’équipe et une facture plus grosse pour vous.

Et parce que chaque sprint se termine par du logiciel qui fonctionne, vous n’êtes jamais à plus de deux semaines de la vérité. Un projet de trois mois sans sprints peut être 100 % à côté de la plaque au jour 89 et vous ne le découvrez qu’au jour 90. Avec des sprints, vous avez six points de correction en chemin. Chaque review est une occasion de dire « ce n’est pas ça » tant que changer de cap coûte encore peu cher.

Une façon concrète de l’utiliser : à la fin de chaque sprint, faites le calcul rapide. Vous avez payé X pour deux semaines. La valeur business réelle qui a atterri en deux semaines vaut-elle X ? Pas besoin d’être exact. Après trois ou quatre sprints, vous sentirez si le rythme est juste ou si vous payez cher pour peu. Cet instinct, recalibré toutes les deux semaines, vaut plus que n’importe quel rapport.

Sprint, Scrum et design sprint ne sont pas la même chose

Trois mots proches qui embrouillent tout le monde, alors autant les séparer vite.

Scrum est le cadre entier : rôles, cérémonies, artefacts. Le sprint est une partie de Scrum, le cycle de temps. C’est la différence entre « le football » et « le temps de jeu ». Vous n’avez pas besoin de maîtriser Scrum. Vous avez besoin de comprendre le sprint.

Design sprint est autre chose : un processus de cinq jours créé chez Google pour tester une idée vite, avant de construire. Malgré le nom, il a peu à voir avec le sprint de développement. Si quelqu’un vous propose un « design sprint », il parle de valider un concept en une semaine, pas de construire du logiciel en cycles.

Et non, le sprint du logiciel n’a aucun rapport avec la course de vitesse. Le mot a été emprunté à l’athlétisme pour l’idée d’un effort court et concentré. Rien de plus.

L’erreur que les fondateurs non techniques font avec les sprints

La plus courante, ce n’est pas d’ignorer le sprint. C’est de l’utiliser à l’envers. Le fondateur comprend qu’il y a un cycle, alors il traite chaque sprint comme une promesse de livraison et met la pression à l’équipe comme sur une chaîne de production : « pourquoi cette fonctionnalité n’a pas été finie ce sprint ? ».

Le problème, c’est qu’un sprint n’est pas une garantie de livraison. C’est un engagement à essayer dans une boîte de temps fixe. Parfois l’équipe découvre en cours de route que la tâche était plus complexe qu’elle en avait l’air. Un sprint qui se termine par « c’est plus dur qu’on pensait, voici ce qu’on a appris » n’est pas un sprint raté. C’est le sprint qui fait son travail : vous donner la mauvaise nouvelle en deux semaines et pas en deux mois.

La bonne question à la review n’est jamais « pourquoi ce n’est pas fini ». C’est « qu’avons-nous appris, et qu’est-ce que ça change pour le prochain sprint ». Un fondateur qui traite le sprint comme une chaîne d’usine casse la confiance de l’équipe et, ironie, ralentit le projet. Le cycle fonctionne quand vous l’utilisez comme instrument de vision, pas comme fouet.

Si vous montez la logique de votre produit à partir de zéro, le sprint est l’horloge qui garde le roadmap connecté à la réalité. Le roadmap dit vers où. Le sprint livre les deux prochains pas et vous montre si le terrain est celui que vous imaginiez.

Questions fréquentes

Qu’est-ce qu’un sprint, en une phrase ?

Un cycle de travail fixe, généralement de deux semaines, pendant lequel une équipe de développement livre une partie fonctionnelle du logiciel que vous pouvez tester à la fin.

Quelle est la différence entre un sprint et un backlog ?

Le backlog est la liste complète et priorisée de tout ce dont le produit a besoin. Le sprint est la tranche de cette liste que l’équipe s’engage à construire maintenant. Le backlog est le menu ; le sprint est ce que vous avez commandé cette fois-ci. On détaille le backlog dans ce guide.

Combien de sprints faut-il pour construire un produit ?

Ça dépend du périmètre, mais un premier produit sérieux prend généralement de 4 à 10 sprints, soit de deux à cinq mois. Méfiez-vous de qui promet « un sprint » pour quelque chose que vous mettriez vous-même des mois à décrire.

Dois-je participer à toutes les réunions du sprint ?

Non. Vous devez être à la sprint review, à la fin de chaque cycle, et être écouté au planning. La daily appartient à l’équipe. Un prestataire qui exige votre présence tous les jours est probablement mal organisé.

Qu’est-ce qu’un sprint dans Scrum ?

C’est exactement la même chose. « Sprint dans Scrum » rend simplement explicite que le cycle fait partie du cadre Scrum, où il est né. Il n’existe pas de sprint « différent » à l’intérieur de Scrum.

Le sprint a-t-il un rapport avec la course de vitesse ?

Seulement dans le nom. Le mot a été emprunté à l’athlétisme pour l’image d’un effort court et intense. En logiciel, il décrit le cycle de travail, pas une course.

Le sprint est l’instrument le plus simple dont vous disposez pour transformer un build externalisé en quelque chose que vous contrôlez sans comprendre le code. Deux semaines, une livraison qui tourne, une question honnête : est-ce que ça valait le coup ? Posez cette question six fois de suite et vous aurez piloté un projet logiciel entier sans jamais avoir ouvert un éditeur de code.