🇬🇧 Click here to access the English version of this post
Beaucoup de tech leaders opposent souvent vélocité et qualité, comme si l’un se faisait forcément au détriment de l’autre. Cette vision est profondément ancrée dans la culture des entreprises technologiques : d’un côté, ceux qui veulent aller vite pour livrer la roadmap ; de l’autre, ceux qui plaident pour plus de rigueur, de tests et de stabilité. Et pourtant, cette opposition est une illusion.
En vérité, tous les problèmes de vélocité sont des problèmes de qualité. Quand une équipe ralentit, ce n’est presque jamais parce qu’elle ne va “pas assez vite”, mais parce qu’elle traîne derrière elle les conséquences de choix techniques, organisationnels ou méthodologiques qui ont dégradé la qualité du système. Un code mal structuré, des spécifications floues, des décisions d’architecture prises dans l’urgence ou une communication imprécise : chaque compromis sur la qualité ajoute un peu plus de friction au système. Et la somme de ces frictions finit toujours par freiner la machine. Autrement dit, la perte de vélocité est un symptôme, pas une cause. Les vrais problèmes ne se situent pas dans la vitesse d’exécution, mais dans la qualité du processus qui la rend possible.
Le mythe de la vélocité
Dans la plupart des entreprises technologiques, on confond encore vitesse et vélocité. En physique, la différence est pourtant simple : la vitesse mesure à quelle allure un objet se déplace, tandis que la vélocité mesure à quelle allure et dans quelle direction il se déplace. Autrement dit, on peut aller très vite… dans la mauvaise direction.
C’est exactement ce qui se passe dans beaucoup d’équipes produit et engineering. Elles livrent des fonctionnalités à toute allure, cochent des tickets dans Jira, tiennent leurs sprints, mais sans toujours s’assurer que leurs efforts contribuent réellement à créer de la valeur pour les utilisateurs ou à renforcer la stabilité du produit. Elles confondent mouvement et progrès. La vitesse, c’est de l’exécution brute : plus de code, plus de features, plus de releases. La vélocité, c’est la capacité à livrer régulièrement de la valeur dans la bonne direction, sans perdre en qualité ni accumuler de dette.
Une équipe peut donc aller très vite pendant quelques semaines, mais perdre sa vélocité dès que le système devient trop complexe ou instable pour soutenir ce rythme. Alors pourquoi les organisations continuent-elles à se concentrer sur la vitesse ? Parce qu’elle est visible et rassurante. Elle donne l’impression d’avancer : des tickets fermés, des graphiques qui montent, des démos à montrer. Mais cette illusion est dangereuse, car à force de viser la vitesse, on finit par sacrifier la qualité, et c’est précisément cette qualité qui conditionne la vraie vélocité. La vélocité ne vient pas de la pression, mais de la fluidité. Et cette fluidité dépend d’un seul facteur : la qualité du système tout entier, des idées au produit final.
Les multiples problèmes de qualité qui tuent la vélocité
Quand on parle de qualité, la plupart des équipes pensent immédiatement à la qualité du code : tests unitaires, dette technique, refactoring. Mais en réalité, la qualité impacte chaque étape du cycle de développement, du pitch d’idée jusqu’au feedback utilisateur. Et c’est l’accumulation de petites erreurs de qualité à chaque étape qui finit par paralyser la vélocité globale du système.
1. Mauvaise qualité dans le pitch d’idée
Tout commence avant même la première ligne de code. Si les idées sont mal formulées, non alignées avec la stratégie produit, ou validées sans données, on crée une dette dès la source : des fonctionnalités inutiles, des priorités floues, des débats interminables sur le “pourquoi” plutôt que le “comment”.
👉 Résultat : beaucoup de travail, peu de valeur livrée.
2. Mauvaise qualité dans les spécifications produit
Des specs imprécises, incomplètes ou changeantes génèrent un cycle d’allers-retours sans fin entre product et engineering (ce que j'aime appeler la "salsa product-engineering").
Les équipes discutent, reformulent, réinterprètent, parfois pendant des semaines.
👉 Résultat : le développement stagne avant même de commencer.
3. Mauvaise qualité dans les spécifications techniques
Une fois la feature validée, les problèmes continuent si la conception technique n’est pas claire ou stable. Les choix d’architecture faits dans l’urgence, les dépendances mal identifiées, ou les compromis à court terme génèrent une dette invisible mais durable.
👉 Résultat : les développements futurs deviennent plus lents et plus risqués.
4. Mauvaise qualité dans le développement
C’est la partie la plus visible, mais souvent la conséquence des précédentes. Un code mal factorisé, sans tests ou avec une faible lisibilité, ralentit tout le reste : intégration, debugging, onboarding des nouveaux développeurs.
👉 Résultat : chaque livraison demande plus de temps, chaque bug coûte plus cher à corriger.
5. Mauvaise qualité dans le test et la mise en production
Des tests insuffisants ou manuels, des environnements de staging instables, ou un process de release trop lourd freinent le flux.
👉 Résultat : peur de déployer, régressions fréquentes, et cycles de QA interminables.
6. Mauvaise qualité dans la boucle de feedback utilisateur
Enfin, même après la mise en production, un mauvais système de feedback (données incomplètes, manque de suivi, absence d’écoute client) empêche l’équipe de savoir si la fonctionnalité a réellement atteint son objectif.
👉 Résultat : des semaines d’effort pour une feature que personne n’utilise.
Chaque étape est une opportunité de créer ou de détruire de la vélocité. Et dans la majorité des cas, quand une équipe “ralentit”, ce n’est pas parce qu’elle code trop lentement, mais parce qu’elle doit compenser les problèmes de qualité accumulés en amont. Autrement dit : la vélocité se construit dès la première idée.
Restaurer la vélocité par la qualité
Restaurer la vélocité d’une équipe ne consiste pas à aller plus vite, mais à réduire la friction. Car la vélocité n’est pas une question d’énergie, mais de fluidité du système. Quand une équipe ralentit, ce n’est pas parce que les développeurs travaillent moins vite, mais parce que le système tout entier s’encrasse : idées floues, specs ambiguës, code instable, boucles de feedback trop longues. Chaque défaut de qualité ajoute une micro-résistance au flux, jusqu’à transformer la moindre livraison en parcours d’obstacles.
Retrouver la vélocité, c’est donc réparer la qualité à la source, et pour cela, la qualité doit devenir l’affaire de tous, à chaque étape du flux : product managers, designers, développeurs, QA, engineering managers. Plutôt que de s’escrimer à défendre des “principes abstraits” de qualité (“donnez-moi plus de temps pour coder”, “il nous faut plus de tests”), chacun peut agir concrètement sur son poste de travail pour réduire les gaspillages et améliorer le flux. Trois leviers simples pour y parvenir :
- Clarifier : s’assurer que chaque idée, chaque spécification et chaque ticket sont compréhensibles, testables et reliés à une vraie valeur utilisateur.
- Simplifier : éliminer la complexité inutile dans le code, les process, la communication ou la validation.
- Boucler vite : obtenir du feedback rapide, qu’il soit technique, produit ou utilisateur, pour corriger avant que les erreurs ne s’accumulent.
Autrement dit, la qualité ne se décrète pas, elle se pratique au quotidien. Et c’est en optimisant les micro-gestes de chacun que l’équipe retrouve une vélocité collective durable.
La vélocité comme reflet de la qualité collective
La vélocité n’est jamais le résultat d’un effort individuel, mais le reflet de la qualité collective d’une organisation. Chaque ticket mal rédigé, chaque décision floue, chaque bug non anticipé ajoute un grain de sable dans la machine. Et ces grains, cumulés, finissent par bloquer le flux. À l’inverse, quand chacun se concentre sur la qualité de son propre poste de travail, la fluidité revient naturellement. Moins de déchets, moins d’attente, moins de rework : le système respire à nouveau.
Les équipes les plus rapides ne sont pas celles qui travaillent dans l’urgence, mais celles qui ont appris à travailler proprement. Elles ont compris que la qualité n’est pas un luxe, mais la condition même de la vitesse durable. Car au fond, tous les problèmes de vélocité sont des problèmes de qualité. Et c’est en élevant la qualité, du code, des specs, des décisions et des interactions, que les organisations retrouvent ce qu’elles cherchent depuis toujours : la capacité d’avancer vite, dans la bonne direction, et sans friction.