CTO : les métriques d'équipe qui comptent vraiment

Quand on parle de métriques d'équipe technique, on pense immédiatement à des dashboards remplis de graphiques : vélocité en story points, nombre de tickets fermés par sprint, temps de cycle. Ces indicateurs ont leur utilité, mais les métriques les plus importantes sont souvent celles qu'on ne trouve dans aucun outil.

La métrique numéro un : les "WTF" de votre équipe

À mon sens, la principale métrique à suivre dans une équipe technique est le nombre de "What The Fuck" entendus dans les open spaces, sur Slack, Teams, ou en visio. Ça peut paraître anecdotique, mais c'est un signal extrêmement fiable. Quand les développeurs s'énervent publiquement, c'est en général qu'il y a quelque chose qui cloche sérieusement.

Cette population est en effet, pour une partie d'entre elle, peu prompte à exprimer en public ce qui ne va pas. Les développeurs ont tendance à encaisser les frustrations, à contourner les problèmes, à faire avec. Quand ils commencent à exprimer ouvertement leur agacement, c'est qu'il est grand temps d'aller les écouter. Le problème est probablement là depuis un moment.

Ce n'est pas une métrique qu'on peut formaliser dans un dashboard. On pourrait l'imaginer avec un Employee NPS, mais ce type d'enquête ne traduit pas tout. On ne dit pas à froid lors d'un questionnaire la même chose qu'on peut dire à chaud après un poker planning ou un sprint planning tendu. C'est un ressenti de manager qui se capte en écoutant les conversations en open space, autour de la machine à café, pendant la pause déjeuner, ou directement en entretien trimestriel.

Un exemple concret

J'ai vu une équipe sur un très gros projet B2C perdre énormément en vélocité sans raison technique apparente. En les écoutant parler entre eux en open space et pendant les pauses déjeuner, j'ai compris le problème : ils ne trouvaient plus de sens technique à leur plateforme. Ils estimaient que les équipes produit et business n'écoutaient pas suffisamment leurs alertes et que la plateforme se dégradait en qualité et en maintenabilité avec le temps.

On a pris une demi-journée pour en parler ensemble, pour objectiver leur ressenti avec des données concrètes, et pour construire un plan d'action structuré. Une fois ce plan formalisé, on l'a présenté aux autres parties prenantes qui l'ont compris et ont accepté des changements significatifs de roadmap pour se prémunir contre ces risques. Le plus intéressant : à l'issue de cette première réunion, alors qu'aucune amélioration technique n'avait encore été réalisée, le moral de l'équipe est remonté en flèche. Et la vélocité avec. Le simple fait d'avoir été écoutés et de voir un plan concret a suffi à débloquer la situation.

Les métriques de qualité : regarder les tendances, pas les chiffres absolus

En dehors de ce ressenti terrain, les métriques les plus importantes à regarder sont celles liées à la qualité du code : nombre de tests unitaires, couverture de ces tests, complexité cyclomatique, nombre de bugs ouverts. Mais la manière de les lire est cruciale.

Il ne s'agit pas de fixer des seuils absolus. Même sur un projet neuf, espérer une couverture de test à 100% est une utopie. Ce qui compte, c'est la tendance. Voir si un projet a une qualité qui décline est un indicateur fort, qu'il faut rendre visible à l'ensemble de l'équipe et aux parties prenantes. Une couverture de test qui baisse, une complexité cyclomatique qui augmente : ces signaux peuvent s'expliquer et s'accepter, mais ne pas les connaître est rapidement un problème.

C'est toute la différence entre la dette technique qu'on connaît et qu'on accepte, et la dette technique qu'on subit. La première est un choix stratégique : on sait qu'on achète de la dette, on sait qu'on devra la rembourser plus tard, mais on le fait sciemment, en pleine connaissance de cause, parce que le contexte business le justifie. La seconde est un angle mort qui s'accumule silencieusement jusqu'au jour où la plateforme devient impossible à faire évoluer.

Convaincre un fondateur de l'importance de la qualité

En général, si un fondateur fait appel à un CTO externe ou à un accompagnement, c'est qu'il a déjà pris conscience que la qualité devait être un enjeu fort. Si ce n'est pas le cas, il suffit souvent de prendre en compte son contexte : son passé, ce qu'il veut faire avec son produit, sa trajectoire de croissance. Et de lui montrer les exemples d'entreprises qui ont réussi en misant sur la qualité.

Les métriques Accelerate tournent énormément autour de ces questions de qualité, et pour une bonne raison : la qualité d'aujourd'hui est la capacité à innover de demain. Un produit dont la qualité baisse continuellement va entraîner une cascade de problèmes : risques forts d'introduction de nouveaux bugs à chaque livraison, incapacité à faire évoluer le produit rapidement, et potentiellement départ des meilleurs développeurs qui préféreront aller dans des entreprises ayant fait le choix d'investir dans la qualité.

On peut, par moment et sur certaines parties du produit, décider sciemment de baisser la qualité attendue. C'est parfaitement acceptable quand l'enjeu business le justifie : valider rapidement une hypothèse, sortir une fonctionnalité critique avant un concurrent, répondre à une urgence client. Ce qui n'est pas acceptable, c'est de le faire sans le savoir ou sans le mesurer.

En résumé

Les meilleures métriques d'une équipe technique ne se trouvent pas toutes dans un dashboard. Le ressenti terrain, capté en écoutant les développeurs dans leur quotidien, est souvent le signal le plus précoce d'un problème. Complétez-le avec des métriques de qualité de code suivies en tendance, pas en valeur absolue. Et surtout, faites la différence entre la dette technique choisie et la dette technique subie : la première est un outil stratégique, la seconde est une bombe à retardement.