Votre vélocité tech n'est pas un KPI. C'est un signal d'alarme.

Votre vélocité tech chute. Et si le problème n'était pas technique ?

"Notre vélocité est en baisse."

Vous l'avez dit la semaine dernière en COMEX. Votre CTO a hoché la tête. Votre VP Product a soupiré. Et tout le monde s'est mis d'accord : il faut recruter des devs, optimiser les process, installer des outils.

Erreur.

Ce diagnostic est faux. Et cette solution va aggraver le problème.

Car traiter la vélocité comme un KPI à optimiser, c'est comme essayer de guérir une grippe en cassant le thermomètre. Vous masquez le symptôme sans toucher à la maladie.

La vélocité tech ne mesure pas la performance de vos équipes. Elle révèle l'état de votre organisation.

La vélocité mesure votre capacité à créer de la valeur. Pas à coder vite.

Prenons un exemple concret.

Équipe A : 50 story points fermés ce mois-ci. Équipe B : 30 story points.

Qui performe le mieux ?

Impossible à dire sans contexte.

• Si l'équipe A a livré 5 features dont 4 dorment en production sans utilisateurs, sa vélocité ne vaut rien.
• Si l'équipe B a refactorisé une brique critique qui va débloquer 6 mois de roadmap, elle a créé infiniment plus de valeur.

La vélocité brute (story points, tickets fermés, lignes de code) ne dit qu'une chose : est-ce que vous produisez du code.

Pas si ce code sert à quelque chose.

C'est pour ça que les meilleurs CTOs ne pilotent jamais la vélocité seule. Ils la croisent avec :

• Le time-to-market (combien de temps entre l'idée et la mise en prod ?)
• L'impact business (cette feature a-t-elle changé un indicateur clé ?)
• La stabilité (combien de bugs générés par sprint ?)

Une vélocité qui monte avec un time-to-market qui explose ? Vous produisez du code inutile.

Une vélocité stable avec zéro impact business ? Vous développez les mauvaises choses.

Ce qu'une chute de vélocité révèle vraiment

Quand un CEO nous appelle chez Hones avec ce problème, notre première question n'est jamais "combien de développeurs avez-vous ?".

C'est : "Comment est organisée votre boîte ?"

Parce qu'une chute brutale de vélocité cache toujours un ou plusieurs de ces signaux :

Votre roadmap change trop souvent

Scénario classique : en janvier, vous priorisez la feature X. En février, un concurrent sort Y, donc tout bascule. En mars, un gros client réclame Z.

Résultat : vos équipes passent leur temps à replanifier, re-estimer, re-architecturer. Elles ne livrent rien car elles n'ont jamais le temps de finir.

Diagnostic : ce n'est pas un problème tech. C'est un problème de gouvernance.

Votre product management est défaillant

Vos specs arrivent incomplètes. Vos user stories sont floues. Vos critères d'acceptation changent en cours de sprint.

Vos devs passent 50% de leur temps en réunions de clarification. Ils codent des features, les refont, les recalibrent.

Diagnostic : ce n'est pas un problème de compétence. C'est un problème de processus.

Votre dette technique vous paralyse

Chaque nouveau développement nécessite 3 jours de contournement. Vos tests ne passent plus. Votre CI/CD plante une fois sur deux.

Vous avez mis la dette sous le tapis pendant 2 ans. Maintenant, elle prend 70% du temps de vos équipes.

Diagnostic : ce n'est pas de la lenteur. C'est de la paralysie.

Vos équipes sont sous pression destructrice

Vous avez poussé pendant 6 mois pour "aller plus vite". Vos devs ont livré en sacrifiant la qualité, les bugs s'accumulent, le moral plonge, les meilleurs partent.

Et maintenant, vous ralentissez deux fois plus vite.

Diagnostic : ce n'est pas un manque de motivation. C'est de l'épuisement.

Le piège : ajouter des ressources pour compenser

Face à une vélocité en berne, la tentation est énorme : recruter.

Plus de devs = plus de code = plus de vélocité. Non ?

Non.

Ajouter des ressources sur un système dysfonctionnel ne fait qu'amplifier le dysfonctionnement.

Exemple vécu chez un de nos clients (SaaS B2B, série B, 80 personnes) :

• Avant recrutement : 5 devs, vélocité moyenne 40 points/sprint
• Après recrutement de 3 devs : vélocité tombe à 28 points/sprint

Pourquoi ? Parce que les nouveaux ont dû être onboardés, formés, intégrés. Les anciens ont passé 40% de leur temps en mentoring. Les process n'ont pas suivi. Les réunions ont explosé en nombre.

Recruter n'a fait qu'accélérer le chaos.

La bonne approche ? Ils ont mis les recrutements en pause pendant 3 mois. Restructuré les équipes. Clarifié la roadmap. Remboursé la dette critique.

Résultat 6 mois plus tard : la vélocité a doublé avec la même taille d'équipe.

Ce qu'un CEO doit faire face à une chute de vélocité

1. Challenger votre roadmap

Posez-vous cette question : si je ne pouvais livrer que 3 choses dans les 6 prochains mois, lesquelles auraient le plus d'impact ?

Puis comparez avec ce que vos équipes développent réellement.

Vous allez probablement découvrir qu'une partie de vos développements n'ont aucun impact mesurable.

2. Stabiliser vos priorités

Une roadmap qui change tous les mois n'est pas agile. C'est du pilotage à vue.

Fixez des jalons trimestriels. Tenez-les. Arrêtez de réagir à chaque mouvement concurrent.

Vos équipes ont besoin de prévisibilité pour être efficaces.

3. Mesurer l'impact, pas l'output

Arrêtez de demander "combien de tickets fermés cette semaine ?".

Demandez : "Quelle feature a eu le plus d'impact utilisateur ce mois-ci ? Comment on le sait ?"

Si votre CTO ne peut pas répondre, c'est là qu'est le problème.

4. Investir dans l'organisation, pas juste dans les ressources

Avant d'embaucher, demandez-vous :

• Est-ce que mes équipes ont les outils pour travailler efficacement ?
• Est-ce que mes process de décision sont fluides ?
• Est-ce que mon product management est solide ?

Si la réponse est non, recruter ne fera qu'ajouter du bruit.

Conclusion : la vélocité comme boussole, pas comme objectif

La vélocité tech est un indicateur puissant. Mais uniquement si vous la lisez correctement.

Elle ne vous dit pas si vos équipes vont assez vite. Elle vous dit si votre organisation fonctionne.

Une vélocité qui chute, c'est rarement un problème de compétence. C'est presque toujours un problème de structure.

Alors avant de demander à vos équipes "d'aller plus vite", demandez-vous : qu'est-ce qui les ralentit ?

La réponse est probablement dans votre organisation. Pas dans leur code.

Et vous, CEO : quand avez-vous challengé votre roadmap pour la dernière fois ?

‍