Sprint

Un sprint est une itération de durée fixe, un mois au maximum, pendant laquelle une équipe Scrum transforme une partie du backlog en un incrément utilisable. Deux semaines est la durée la plus répandue. Le périmètre est arrêté au début du cycle et l’équipe travaille dessus jusqu’au bout, sans réorientation en cours de route.

Le mot désigne souvent, par abus de langage, n’importe quelle période de travail intense avec une échéance. Ce n’est pas ce dont il s’agit ici. Dans la méthode agile, le sprint n’est pas un coup de collier : c’est un contenant. Il enferme une quantité de travail dans une durée qui ne bouge pas, puis se referme sur un moment d’inspection. La valeur vient de la répétition de ce cycle.

Pourquoi fixer la durée plutôt que le contenu

C’est le renversement que la plupart des fondateurs mettent du temps à digérer. En gestion de projet classique, on fixe le contenu (voici les quarante fonctionnalités à livrer) et la date s’ajuste, presque toujours vers l’arrière. Le sprint fait l’inverse : la date est verrouillée, le contenu s’ajuste.

Cette contrainte a deux effets. Elle empêche le travail de s’étaler pour occuper tout le temps disponible, ce qui arrive systématiquement quand l’échéance est lointaine. Et elle oblige à découper : une fonctionnalité qui ne tient pas en deux semaines doit être fendue en morceaux livrables, exercice qui révèle souvent que la moitié des morceaux n’avait aucune valeur.

Le sous-produit le plus utile arrive au bout de trois ou quatre cycles : l’équipe sait combien elle absorbe par sprint. Cette mesure, la vélocité, permet de répondre à « combien de temps pour cette version ? » avec un ordre de grandeur défendable plutôt qu’une intuition. Encore faut-il la relire sur les derniers sprints seulement. Depuis la généralisation des assistants de code, les repères d’avant se sont déplacés, et le temps gagné perçu diffère nettement du temps mesuré.

Les trois règles qui protègent un sprint

Le Guide Scrum, dont la version 2020 fait toujours référence, tient sur ce point en trois règles.

La durée est fixe et ne dépasse pas un mois. Un sprint ne s’allonge pas de trois jours parce que le travail n’est pas fini. Il se termine à la date prévue, avec ce qui est terminé, et le reste retourne au backlog. Prolonger un sprint détruit la seule chose qu’il apportait : un point de repère stable.

Aucun changement ne doit mettre en péril l’objectif du sprint. La formulation exacte compte. Elle n’interdit pas toute évolution du périmètre : elle interdit celles qui compromettent l’objectif. Un ajustement négocié entre le Product Owner et les développeurs reste possible, un ajout imposé le mercredi de la deuxième semaine ne l’est pas.

Seul le Product Owner peut annuler un sprint. Cas rare, prévu quand l’objectif n’a plus de sens : un concurrent sort la fonctionnalité, une décision réglementaire change la donne. Personne d’autre n’a cette autorité, ce qui protège l’équipe des changements d’humeur venus d’en haut.

Un contenant pour les autres événements

Les quatre autres événements de Scrum se tiennent à l’intérieur du sprint. Il s’ouvre par le sprint planning, qui fixe l’objectif et sélectionne les éléments à traiter. Il se rythme par le daily meeting, quinze minutes pour ajuster le plan de la journée au regard de l’objectif. Il se referme sur deux temps distincts, souvent confondus : la revue de sprint inspecte le produit avec les parties prenantes, la rétrospective inspecte la façon de travailler de l’équipe.

L’ordre importe. La revue fait remonter des retours qui alimentent le backlog, donc le planning suivant. La rétrospective produit des actions d’amélioration qui entrent dans le sprint suivant au même titre qu’une fonctionnalité. Une équipe qui garde le planning et supprime la rétrospective conserve la cadence mais perd le mécanisme d’apprentissage. Au bout de six mois, elle livre toujours, et toujours avec les mêmes frictions.

L’incrément et la definition of done

À la fin du sprint, l’équipe produit un incrément : une version du produit qui intègre le nouveau travail et tout ce qui a été fait avant, et qui fonctionne. Un incrément n’est pas une branche en attente de validation ni une démonstration sur un environnement bricolé.

Ce qui rend cette exigence vérifiable, c’est la definition of done : la liste des conditions qu’un élément doit remplir pour être déclaré terminé. Tests écrits et passants, code relu, documentation à jour, déployé sur l’environnement de recette. Sans cette liste partagée, « terminé » veut dire quelque chose de différent pour chaque développeur, et le sprint se conclut sur un lot de travaux à 90 % dont personne ne sait ce qui manque.

C’est le point sur lequel une équipe jeune se ment le plus facilement. Une user story marquée terminée mais non testée revient trois sprints plus tard sous forme de bug, au moment où plus personne n’a le contexte en tête. Une definition of done exigeante fait baisser la vélocité affichée les premiers mois. Elle la rend crédible ensuite.

Une semaine, deux semaines, un mois : comment choisir

Deux semaines s’est imposé pour une raison pratique : c’est assez long pour construire quelque chose de substantiel, assez court pour que la boucle de retour reste serrée et que la charge des rituels reste raisonnable.

Une semaine convient aux équipes qui maîtrisent leur domaine et veulent un maximum de retours, typiquement en phase de recherche de product market fit. Le coût est mécanique : la part de temps passée en planning et en revue double par rapport au temps de production.

Quatre semaines se justifient sur des sujets où le travail se découpe mal, des intégrations lourdes, des contraintes de conformité. Le risque est symétrique : plus la boucle est longue, plus l’écart potentiel entre ce qui est construit et ce qui est attendu grandit.

Une fois choisie, la durée ne bouge plus. Elle sert d’unité de mesure, et une unité qui change de taille ne mesure plus rien.

Sprint et release : deux cadences distinctes

C’est l’ambiguïté la plus fréquente en 2026 : livrer en fin de sprint ne veut pas dire mettre en production en fin de sprint. Avec une chaîne d’intégration continue et des feature flags, une équipe déploie plusieurs fois par jour tout en gardant un sprint de deux semaines. Le code part en production dès qu’il est prêt, la fonctionnalité s’active quand le produit le décide, et la release visible pour l’utilisateur suit son propre calendrier.

Le sprint garde alors sa fonction première : un rythme de décision et d’inspection. Il répond à « qu’est-ce qu’on construit maintenant, et qu’est-ce que ça a donné », pas à « quand est-ce que ça part en production ». Confondre les deux conduit à retenir artificiellement du code terminé pendant dix jours, ce qui augmente le risque de chaque mise en ligne au lieu de le réduire.

Sprint ou flux continu : quand le cadre ne convient pas

Le sprint suppose qu’on puisse geler des priorités pendant deux semaines. Certaines équipes n’ont pas ce luxe. Le support, l’exploitation, la maintenance d’un parc applicatif vivent d’arrivées imprévisibles. Leur imposer des sprints produit le même scénario tous les quinze jours : un plan cassé dès le troisième jour, puis une équipe qui finit par voir le rituel comme une comédie.

Kanban répond mieux à ce contexte, avec un flux continu et une limite sur le travail en cours plutôt qu’un lot figé. Beaucoup d’équipes atterrissent sur un mélange des deux, parfois appelé Scrumban, qui conserve la cadence d’inspection et la rétrospective sans engagement ferme sur un lot de travail. Le signal qui doit alerter : si le périmètre du sprint est renégocié à chaque fois, ce n’est pas l’équipe qui est indisciplinée, c’est le cadre qui ne correspond pas à son activité.

Les erreurs qui vident un sprint de son sens

Le sprint en cascade miniature. Analyse du lundi au mercredi, développement jusqu’au jeudi suivant, tests le dernier jour. Le cycle en V compressé dans deux semaines cumule les défauts des deux modèles : la rigidité de l’un et la pression de l’autre. Les tests sautent à la première difficulté.

Planifier à 100 % de la capacité. Il y a toujours un incident, une absence, une clarification qui prend deux jours. Viser environ 80 % de la vélocité observée laisse la marge nécessaire pour les absorber sans sacrifier l’objectif du sprint.

Ne garder que des fonctionnalités. Un sprint sans part réservée aux corrections et à l’entretien technique fonctionne quelques mois, puis la vitesse s’effondre sans cause apparente. La dette technique se chiffre et se rembourse par tranches, sprint après sprint.

Piloter la vélocité comme un indicateur de performance. Dès qu’elle sert à comparer des équipes ou à mettre la pression, les points gonflent. La mesure reste, sa valeur informative disparaît.

Livrer sans objectif. Un sprint réduit à une liste de tickets sans intention commune produit un incrément décousu. La question de fin de sprint n’est pas « avons-nous tout coché » mais « qu’est-ce que l’utilisateur peut faire aujourd’hui qu’il ne pouvait pas faire il y a deux semaines ».

FAQ sprint

Que faire du travail non terminé à la fin d’un sprint ?

Il retourne au backlog et le Product Owner le repriorise. Rien n’oblige à le reprendre au sprint suivant : entre-temps, la revue a peut-être révélé un sujet plus urgent. Un élément qui déborde systématiquement signale presque toujours un découpage trop gros ou une definition of done floue, pas un manque d’effort.

Peut-on faire des sprints sans faire du Scrum ?

Oui, et c’est fréquent. Beaucoup d’équipes gardent la cadence fixe, le planning et la rétrospective sans adopter les rôles ni la totalité du cadre. Cela fonctionne tant que l’inspection en fin de cycle est réelle. Si personne ne regarde ce qui a été produit ni comment l’équipe a travaillé, il ne reste qu’un calendrier découpé en tranches de deux semaines.

Un sprint peut-il être interrompu par une urgence en production ?

Oui. Un incident bloquant passe avant l’objectif du sprint, aucun cadre ne prétend le contraire. Ce qui compte est le traitement : l’urgence est absorbée, l’équipe retire du périmètre l’équivalent du temps consommé, et la rétrospective se demande pourquoi l’incident est arrivé. Quand les urgences reviennent toutes les semaines, elles relèvent de la qualité du produit et méritent leur place dans le prochain sprint.

Comment Polara Studio travaille en sprints

Chez Polara Studio, le sprint de deux semaines est l’unité standard sur les projets de développement. Planning le lundi matin, daily de quinze minutes, revue et rétrospective le vendredi de la deuxième semaine. La durée ne change pas d’un projet à l’autre, ce qui nous permet de comparer les vélocités et d’estimer les nouveaux projets à partir de repères réels.

Nous planifions à environ 80 % de la capacité mesurée et réservons une part de chaque sprint aux corrections et à la dette technique. Le déploiement, lui, est continu : le code part en production dès qu’il passe la definition of done, indépendamment de la fin du sprint.

Ce que nous observons projet après projet : les deux ou trois premiers sprints sont les moins productifs et les plus utiles. C’est là que le vocabulaire commun se construit avec le client et que l’équipe découvre ce qu’elle sait vraiment livrer en dix jours. Les fondateurs qui acceptent cette phase d’amorçage obtiennent ensuite des prévisions assez solides pour engager leur calendrier commercial.