Vélocité en développement logiciel : comment mesurer la vélocité agile en 2026

Yury Pukhov CEO & Mobile Engineering Lead, YuSMP Group

La vélocité (développement logiciel) est l’outil de prévision le plus simple de l’agilité : additionnez le travail qu’une équipe a terminé pendant un sprint, faites la moyenne sur plusieurs sprints, et vous savez à peu près ce que l’équipe peut prendre en charge la fois suivante. L’idée vient de l’Extreme Programming et fait aujourd’hui partie des pratiques courantes de Scrum et des autres frameworks itératifs, mais c’est aussi l’un des chiffres les plus mal utilisés du management de l’ingénierie.

Bien utilisée, la vélocité transforme une réunion de planification en une courte discussion fondée sur des données. Les problèmes commencent quand quelqu’un en fait un objectif : les estimations gonflent et, au bout d’un ou deux trimestres, le chiffre ne veut plus dire grand-chose. Les entreprises qui achètent des services de product engineering orientés résultats regardent donc la vélocité à côté des métriques de livraison et de produit, et non isolément, car une vélocité stable ne dit pas si le travail livré a fait bouger un indicateur métier.

Vous trouverez ci-dessous la formule avec un exemple chiffré sur six sprints, une prévision de release réutilisable, une comparaison de la vélocité avec la capacité, le débit et les métriques DORA, ainsi que les erreurs qui transforment la vélocité en indicateur de vanité – y compris les nouvelles erreurs apportées par les outils de codage IA en 2026.

Qu’est-ce que la vélocité en développement logiciel ?

La vélocité en développement logiciel est la quantité de travail qu’une équipe agile termine pendant une itération, mesurée dans les mêmes unités relatives que celles utilisées pour estimer – le plus souvent des story points (estimations relatives de l’effort, de la complexité et de l’incertitude plutôt qu’en heures). Seul compte le travail qui satisfait la Definition of Done de l’équipe, c’est-à-dire la liste de critères partagée qui indique quand un élément est vraiment terminé. Ce chiffre sert à prévoir ce que la même équipe pourra terminer lors des prochaines itérations.

La vélocité est une mesure empirique : elle enregistre ce qui s’est passé au lieu de prédire ce qui devrait se passer. La valeur de la vélocité réside dans la tendance sur plusieurs sprints, pas dans un sprint isolé. Une équipe qui a terminé 30, 34 et 32 points lors de ses trois derniers sprints de deux semaines a une vélocité d’environ 32 points par sprint, et ce chiffre n’a de sens que pour cette équipe, avec son échelle d’estimation, sa base de code et sa Definition of Done.

Le concept est apparu à la fin des années 1990 dans l’Extreme Programming, où les équipes utilisaient la quantité de travail terminée lors de la dernière itération (« yesterday’s weather », la météo d’hier) pour planifier la suivante. Le livre de Mike Cohn Agile Estimating and Planning a ensuite popularisé la vélocité avec les story points. Le Scrum Guide officiel n’exige pas du tout la vélocité ; il indique seulement que la performance passée et la capacité de l’équipe éclairent la quantité de travail sélectionnée lors du Sprint Planning.

Vélocité de sprint ou vélocité d’équipe

La vélocité de sprint est le nombre de points terminés dans un sprint précis, tandis que la vélocité d’équipe est la moyenne sur plusieurs sprints récents. La vélocité de sprint est un point de données ; la vélocité d’équipe est le chiffre de planification. Planifier sur un seul sprint est risqué, car un sprint peut être faussé par des congés, un incident de production ou une story exceptionnellement grosse terminée le dernier jour.

Quelles unités utiliser pour mesurer la vélocité ?

Les story points sont l’unité de vélocité la plus courante, mais toute unité cohérente de travail terminé convient. Le choix compte moins que sa stabilité dans le temps.

• Story points : estimations relatives de l’effort, de la complexité et de l’incertitude, souvent sur une échelle de type Fibonacci (1, 2, 3, 5, 8, 13).
• Jours ou heures idéaux : estimations d’effort sans interruption, plus faciles à expliquer aux parties prenantes mais plus souvent lues comme des engagements de délai.
• Nombre d’éléments : stories ou tickets terminés par sprint, ce qui fonctionne bien quand le travail est découpé en éléments de taille similaire.
• Tailles de t-shirt converties en nombres : S, M et L associés à des valeurs fixes, un compromis pour les équipes qui débutent en estimation.

Compter des éléments plutôt que des points supprime le rituel d’estimation et se comporte comme un débit. Cela ne fonctionne que si l’équipe découpe systématiquement le travail en petits morceaux comparables.

Comment calculer la vélocité en développement logiciel agile ?

Pour calculer la vélocité en développement logiciel agile, additionnez les story points de tous les éléments qui ont satisfait la Definition of Done pendant un sprint, puis faites la moyenne de ce total sur les trois à cinq derniers sprints de même durée. La formule est : vélocité = somme des story points terminés sur les sprints retenus ÷ nombre de sprints retenus.

1. Fixez la durée du sprint. Utilisez des itérations de même durée, par exemple deux semaines, sinon les sprints ne sont pas comparables.
2. Ne comptez que le travail terminé. Un élément compte lorsqu’il satisfait la Definition of Done : codé, relu, testé et accepté. Les éléments partiellement terminés comptent zéro.
3. Additionnez les points par sprint. Faites la somme des estimations de tous les éléments terminés ; ce total est la vélocité du sprint.
4. Faites la moyenne de plusieurs sprints. Prenez une moyenne glissante des trois à cinq derniers sprints pour lisser le bruit.
5. Communiquez une fourchette, pas un chiffre unique. Notez les valeurs récentes la plus basse et la plus haute à côté de la moyenne, car c’est l’écart qui rend les prévisions honnêtes.

Le tableau ci-dessous présente un exemple chiffré pour une équipe de cinq ingénieurs travaillant en sprints de deux semaines.

Une moyenne glissante des trois derniers sprints (35, 21 et 33) donne une vélocité d’environ 30 points. Sur les six sprints, la moyenne est de 29 points avec une fourchette de 21 à 35. Pour planifier, cette équipe doit s’attendre à environ 29–31 points lors d’un sprint normal et considérer tout ce qui dépasse 35 comme improbable sans changement dans l’équipe ou dans le travail.

Les story points non terminés comptent-ils dans la vélocité ?

Non, les story points non terminés ne comptent pas dans la vélocité. Si une story est terminée à 90 % à la fin du sprint, elle rapporte zéro point à ce sprint et son estimation complète compte dans le sprint où elle est terminée. Répartir les points pour « récompenser » un travail partiel masque le vrai problème, qui est généralement une story trop grosse ou un sprint surchargé. Réestimer les stories reportées est facultatif ; beaucoup d’équipes conservent l’estimation initiale pour éviter l’inflation.

Faut-il compter les bugs et la dette technique dans la vélocité ?

Les bugs et le travail sur la dette technique ne doivent compter dans la vélocité que si l’équipe les estime en points avant le sprint, comme les stories. Si la correction de bugs non planifiée est exclue, la vélocité baisse quand la qualité est mauvaise, ce qui est une information utile. La règle importante est la cohérence : décidez une fois pour toutes comment l’équipe traite les bugs, les spikes et la maintenance, et gardez cette règle stable pour que la tendance reste comparable.

De quoi avez-vous besoin pour mesurer la vélocité avec précision ?

Pour mesurer la vélocité avec précision, il faut une équipe stable, une durée de sprint fixe, une Definition of Done stricte et une pratique d’estimation cohérente. Dès que l’une de ces quatre conditions change, la vélocité passée devient un mauvais prédicteur du travail futur.

• Une équipe stable. Ajouter ou retirer des personnes modifie la vélocité, souvent pendant plusieurs sprints. Les nouveaux membres commencent par ralentir l’équipe le temps de monter en compétence.
• Une durée de sprint constante. Des sprints de deux semaines ne peuvent pas être comparés à des sprints de trois semaines sans normalisation.
• Une Definition of Done solide. Si « terminé » signifie tantôt « mergé », tantôt « mis en production », la vélocité dérive pour des raisons qui n’ont rien à voir avec la production réelle.
• Une pratique d’estimation cohérente. Les mêmes stories de référence et les mêmes personnes qui estiment gardent les points comparables dans le temps.
• Un outil de suivi fiable. Jira, Azure DevOps, Linear ou un outil similaire doit enregistrer correctement les changements de statut, sinon les données sont incomplètes.

Si votre équipe estime en heures ou en jours plutôt qu’en points, la même logique s’applique. Notre guide de l’estimation de projet logiciel compare les story points, l’estimation à trois points et d’autres techniques qui alimentent une planification fondée sur la vélocité.

Comment les équipes utilisent-elles la vélocité pour planifier sprints et releases ?

Les équipes utilisent la vélocité comme une donnée parmi d’autres pour décider combien de travail intégrer au prochain sprint et pour prévoir quand un backlog de taille connue sera terminé. Elle éclaire la décision mais ne la prend pas. L’équipe s’engage toujours en fonction des personnes réellement disponibles, de ce qui compte le plus à ce moment-là et de ce qui pourrait mal tourner dans ce sprint précis.

Comment fixer un objectif de sprint à partir de la vélocité

Lors du Sprint Planning, partez de la vélocité moyenne et ajustez-la en fonction des variations de capacité connues. Si l’équipe tourne en moyenne à 30 points et qu’un ingénieur sur cinq est absent la moitié du sprint, un objectif réaliste se situe autour de 27 points. Jours fériés, astreintes, onboarding et ateliers prévus réduisent la capacité et doivent être déduits avant que l’équipe ne s’engage.

Le guide de Scrum en développement logiciel décrit comment s’articulent le Sprint Planning, le Sprint Goal et le Sprint Backlog ; la vélocité sert simplement à maintenir le périmètre choisi dans les limites de ce que l’équipe a prouvé pouvoir terminer.

Prévoir une release avec une fourchette

Pour prévoir une release, divisez le backlog restant par la vélocité basse et la vélocité haute de l’équipe afin d’obtenir une fourchette de dates plutôt qu’une date unique. Pour un backlog de release de 240 points et une vélocité comprise entre 26 et 34 points par sprint :

1. Cas optimiste : 240 ÷ 34 ≈ 7 sprints.
2. Cas pessimiste : 240 ÷ 26 ≈ 9,2, soit 10 sprints.
3. Conversion en calendrier : avec des sprints de deux semaines, la prévision est de 14 à 20 semaines.

• Prévoyez une marge pour la croissance du périmètre. Les backlogs grossissent généralement pendant la livraison à mesure que l’équipe en apprend davantage ; suivez les changements de périmètre séparément pour qu’ils restent visibles.
• Refaites la prévision à chaque sprint. Mettez à jour la fourchette avec chaque nouveau point de données au lieu de défendre la première estimation.
• Utilisez une prévision probabiliste pour les grosses releases. Une simulation de Monte-Carlo, qui rejoue des milliers de scénarios possibles à partir de votre vélocité ou de votre débit historiques, donne des réponses du type « 85 % de chances d’ici la semaine 18 », plus honnêtes qu’une date unique.

Quelle est la différence entre vélocité, capacité, débit et productivité ?

La vélocité mesure le travail terminé par sprint, la capacité le temps de travail disponible, le débit le nombre d’éléments terminés par période et la productivité le rapport entre production, valeur et effort. Ces métriques répondent à des questions différentes et sont faciles à confondre, ce qui mène à de mauvaises décisions.

Les équipes qui fonctionnent en flux continu plutôt qu’en sprints suivent rarement la vélocité et s’appuient sur le débit, le cycle time et les limites de travail en cours ; le guide Kanban en développement logiciel explique ce modèle. Pour une vision plus large de la mesure au-delà du sprint, consultez notre article sur la productivité dans le développement logiciel.

Qu’est-ce qui influence la vélocité en développement logiciel ?

La vélocité en développement logiciel dépend surtout de la stabilité de l’équipe, de la taille du travail, des interruptions, de la dette technique et de la qualité de la chaîne de livraison, et non de l’ardeur au travail des personnes. Connaître ces facteurs permet d’expliquer une baisse avant que quelqu’un ne demande à l’équipe d’« aller plus vite ».

• Composition et changements de l’équipe. Les recrutements, les départs et les ingénieurs partagés entre équipes font varier la vélocité.
• Taille et clarté des stories. Les stories grosses et floues sont reportées d’un sprint à l’autre et rendent la vélocité instable.
• Travail non planifié. Les incidents de production, les demandes de support urgentes et les sollicitations ponctuelles des parties prenantes consomment de la capacité.
• Dette technique et santé du code. Un code fragile, des tests manquants et des dépendances complexes ralentissent chaque modification.
• Processus de revue et de déploiement. De longues files de revue de code, des tests manuels et une CI lente retardent le moment où le travail est « terminé ».
• Dépendances externes. Attendre une autre équipe, l’API d’un fournisseur ou une validation de sécurité bloque un travail par ailleurs fini.
• Travail en cours. Commencer beaucoup d’éléments à la fois disperse l’attention et en termine moins.

La complexité des tâches mérite un examen à part, car un même nombre de points peut cacher des niveaux de risque très différents. Notre guide des métriques de complexité des tâches en développement logiciel présente des mesures cognitives et de code qui expliquent pourquoi certains sprints patinent.

Vélocité agile ou developer velocity : quelle différence ?

La vélocité agile est un chiffre de planification d’équipe exprimé en story points, tandis que la « developer velocity » est un terme de management plus large qui désigne la rapidité avec laquelle une organisation d’ingénierie transforme des idées en logiciel fonctionnel. Les deux partagent un mot mais répondent à des questions différentes.

Le terme developer velocity a été popularisé par l’étude McKinsey sur le Developer Velocity Index de 2020, qui reliait de solides pratiques d’ingénierie – outils, product management, culture – à la performance de l’entreprise. Selon l’étude McKinsey, les entreprises du quartile supérieur de l’indice ont vu leur chiffre d’affaires croître quatre à cinq fois plus vite que celles du quartile inférieur. La developer velocity, dans ce sens, concerne les capacités et l’environnement, pas les points de sprint.

Pour mesurer la performance de livraison à l’échelle de l’organisation, la plupart des équipes utilisent en 2026 les métriques DORA publiées par le programme DevOps Research and Assessment de Google : fréquence de déploiement, délai de mise en production des changements, taux d’échec des changements et temps de restauration du service. Les métriques de flux comme le cycle time et le travail en cours complètent le tableau. La vélocité peut s’y ajouter comme aide à la planification d’équipe, mais ne doit pas les remplacer. Notre liste des KPI de développement logiciel montre comment ces métriques s’articulent.

Quelles sont les erreurs les plus courantes avec la vélocité ?

L’erreur la plus courante consiste à traiter la vélocité comme un objectif de performance, ce qui gonfle rapidement les estimations et détruit sa valeur pour la planification. La loi de Goodhart décrit bien cet effet : lorsqu’une mesure devient un objectif, elle cesse d’être une bonne mesure.

• Comparer la vélocité entre équipes. Chaque équipe a sa propre échelle de points ; 40 points dans une équipe et 20 dans une autre ne disent rien de celle qui livre le plus.
• Fixer des objectifs de vélocité. Demander « 10 % de points en plus au prochain trimestre » produit surtout des estimations plus grosses, pas davantage de valeur livrée.
• Utiliser la vélocité dans les évaluations individuelles. La vélocité est une métrique d’équipe ; la répartir par personne encourage l’optimisation locale et décourage le pair programming et la revue de code.
• Compter le travail partiellement terminé. Créditer des stories inachevées donne une vélocité d’apparence stable alors que la livraison ne l’est pas.
• Ignorer la qualité. Une vélocité en hausse accompagnée de plus de défauts échappés ou de déploiements ratés signifie généralement que l’équipe prend des raccourcis.
• Planifier à la vélocité maximale. S’engager sur le meilleur sprint jamais réalisé ne laisse aucune place au travail imprévu et fait passer la plupart des sprints pour des échecs.
• Recalibrer les story points en silence. Changer les stories de référence sans remettre à zéro l’historique de vélocité casse la comparabilité.

Comment améliorer la vélocité sans manipuler les story points ?

On améliore durablement la vélocité en supprimant les frictions du système de livraison – stories trop grosses, temps d’attente, reprises – plutôt qu’en poussant les gens à terminer plus de points. Une vraie amélioration se traduit par une vélocité plus élevée ou plus stable, avec une qualité constante et un cycle time plus court.

1. Découpez les stories plus finement. Les éléments qui tiennent en deux ou trois jours sont rarement reportés, ce qui rend la vélocité plus prévisible.
2. Limitez le travail en cours. Terminer avant de commencer autre chose réduit les changements de contexte et les éléments à moitié faits en fin de sprint.
3. Réduisez les délais de revue de code et de CI. Une revue dans la journée et une chaîne rapide et fiable raccourcissent le chemin vers « terminé ».
4. Investissez dans les tests automatisés. Une suite de tests solide réduit les tests de régression manuels et les reprises dues aux défauts échappés.
5. Remboursez la dette technique de façon délibérée. Réservez une part fixe de chaque sprint à la dette dans les zones qui ralentissent le plus l’équipe.
6. Protégez l’équipe du travail imprévu. Faites passer le support et les demandes urgentes par une seule personne en rotation au lieu d’interrompre tout le monde.
7. Menez les rétrospectives sur des données réelles. Examinez les reports, le temps bloqué et le cycle time, choisissez une amélioration par sprint et vérifiez qu’elle a fonctionné.

Comment les outils de codage IA modifient-ils la vélocité en 2026 ?

Les assistants de codage IA peuvent augmenter la quantité de code produite, mais en 2026 ils rendent la vélocité plus difficile à interpréter, car coder plus vite ne signifie pas automatiquement livrer plus vite un logiciel qui fonctionne. Les équipes doivent surveiller les métriques de qualité et de stabilité à côté de la vélocité lorsqu’elles adoptent des outils d’IA.

Le rapport DORA 2025 sur le développement logiciel assisté par l’IA a constaté qu’environ 90 % des professionnels de la tech interrogés utilisent l’IA au travail et que l’adoption de l’IA a désormais une relation positive avec le débit de livraison. La même étude a montré que l’adoption de l’IA reste corrélée à une plus grande instabilité de livraison, c’est-à-dire davantage d’échecs de changements et de reprises. DORA décrit l’IA comme un amplificateur : elle renforce les bons systèmes d’ingénierie et révèle les faibles.

• Recalibrez les estimations. Si les tâches routinières deviennent plus rapides avec l’IA, les stories de référence devront peut-être être réestimées ; remettez alors à zéro la base de vélocité.
• Surveillez la charge de revue. Davantage de code généré déplace souvent le goulot d’étranglement vers la revue de code et les tests, ce qui plafonne la vélocité réelle.
• Suivez le taux d’échec des changements. Une hausse de la vélocité accompagnée d’un taux d’échec en hausse n’est pas une amélioration.

Que vous apprend la vélocité sur une équipe de développement externalisée ?

La vélocité vous indique si une équipe externalisée est prévisible, pas si elle est productive ni si elle offre un bon rapport qualité-prix. Une vélocité stable avec des fourchettes de release honnêtes est un bon signe ; une vélocité qui ne fait qu’augmenter signale généralement de l’inflation.

Lorsque vous travaillez avec une équipe externe ou une équipe de développement dédiée, posez quatre questions simples : comment estimez-vous, que contient votre Definition of Done, que deviennent les reports, et comment prévoyez-vous une release ? Demandez ensuite à voir la vélocité à côté du cycle time, des défauts échappés et de la fréquence de déploiement. Un partenaire qui ne communique que des story points, ou qui promet une vélocité fixe avant de connaître votre base de code, vend un chiffre plutôt qu’un processus de livraison.

Questions fréquentes