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

Les métriques d'équipe technique qui comptent vraiment ne sont pas dans votre dashboard. Les plus précieuses sont deux : le ressenti du terrain, capté en écoutant les développeurs au quotidien, et les indicateurs de qualité du code suivis en tendance plutôt qu'en valeur absolue. La vélocité en story points ou le nombre de tickets fermés par sprint ont leur place, mais ils mesurent l'activité, pas la santé. Voici ce qu'un CTO devrait réellement regarder, et pourquoi.

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.

Encore faut-il calibrer ce signal selon le contexte de l'équipe, car il ne se lit pas de la même façon partout. En télétravail, les « WTF » ne traversent plus l'open space : ils se diluent dans des messages privés, des silences en visio, des caméras qui restent éteintes. Le manager doit alors aller chercher activement ce qu'il captait passivement : multiplier les points informels, soigner les canaux où l'agacement peut s'exprimer sans cérémonie. La culture d'entreprise compte tout autant : dans une équipe où la critique est mal vue, l'absence de « WTF » n'est pas un bon signe, c'est le symptôme d'une parole verrouillée. À l'inverse, une équipe très expressive râlera bruyamment sur des détails sans gravité ; le bruit de fond y est plus élevé et il faut apprendre à distinguer la grogne rituelle de l'alerte réelle. Bref, ce n'est pas un seuil universel : c'est un baromètre qu'on étalonne sur sa propre équipe, en apprenant son rythme et ses codes avant de savoir le lire.

Pour clarifier ma façon de hiérarchiser ces signaux, voici comment je distingue les trois familles de métriques qui composent le tableau de bord d'un CTO.

Les trois se complètent. Le ressenti terrain alerte le premier, les métriques de qualité confirment et localisent le problème, les métriques de flux mesurent l'impact des corrections. Aucune ne suffit seule.

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.

Chez Wizbii, nous avions ritualisé cette lecture en tendance. Une fois par mois, on regardait l'évolution de la couverture de tests et du nombre de bugs ouverts par grande zone du produit, projetée à toute l'équipe. L'objectif n'était jamais d'atteindre un chiffre, mais de rendre visible une dérive avant qu'elle ne fasse mal. Quand la courbe d'une zone se dégradait deux mois de suite, c'était le déclencheur d'une conversation : est-ce qu'on accepte cette dette parce que le business le justifie, ou est-ce qu'on est en train de la subir sans s'en rendre compte ? Cette simple habitude a évité plusieurs fois qu'un module ne devienne ingérable. Et surtout, elle déplaçait la discussion sur la qualité du registre moral (« vous codez mal ») vers le registre factuel (« la tendance dit que cette zone réclame de l'attention »).

Une mise en garde toutefois : ces indicateurs de qualité ne valent que comme outil de pilotage collectif. Le jour où une couverture de tests devient un objectif individuel inscrit dans un entretien d'évaluation, vous obtiendrez des tests écrits pour gonfler le chiffre, pas pour protéger le produit. Le même principe vaut pour les métriques Accelerate : un indicateur transformé en cible individuelle cesse d'être un indicateur fiable.

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.

Comment manager une équipe de devs sans être technique

On manage une équipe de devs sans être technique en pilotant le flux et le moral, pas le code. Tenez trois rituels minimum (un point hebdo d'équipe, une revue de priorités, un échange individuel régulier), endossez le rôle de MOA en exprimant le besoin métier sans dicter la solution, et exigez une visibilité par les tendances qualité et le ressenti terrain plutôt que par la lecture du code.

Quand un fondateur me dit qu'il a peur de « ne pas pouvoir suivre » ses développeurs faute de bagage technique, je le rassure : votre travail n'est pas de relire les pull requests, c'est de protéger le cadre dans lequel l'équipe produit de la valeur. Et ce cadre se pilote très bien sans écrire une ligne de code.

Le minimum vital tient en trois rituels. Un point d'équipe court chaque semaine, où vous écoutez plus que vous ne parlez : c'est là que se captent les « WTF » dont je parle plus haut, le signal le plus précoce d'un problème. Une revue de priorités, où vous tranchez ce qui passe avant quoi en fonction du métier et du business, pas de la difficulté technique. Et un échange individuel régulier avec chaque personne, parce qu'une frustration se dit à chaud, en tête-à-tête, bien avant d'apparaître dans un indicateur. Trois rituels, pas dix : au-delà, vous ajoutez de la cérémonie sans ajouter de pilotage.

Votre vrai rôle, c'est celui de maîtrise d'ouvrage (MOA). Vous portez le « pourquoi » et le « quoi » : le problème métier, le résultat attendu, la valeur pour l'utilisateur et l'entreprise. L'équipe porte le « comment » : l'architecture, les outils, l'implémentation. Le piège classique du fondateur non-technique, c'est de basculer du côté du « comment » en répétant des bouts de jargon entendus à droite à gauche. Restez sur votre terrain. Une exigence métier claire (« je veux qu'un client puisse annuler en deux clics et être remboursé sous 24 h ») vaut mille suggestions techniques approximatives. Si ce partage des rôles vous parle, le guide des 5 signaux pour structurer son équipe tech le détaille côté fondateur.

Reste la question de la visibilité, celle qui angoisse le plus : comment savoir si ça avance bien quand on ne lit pas le code ? La réponse tient dans tout cet article. Vous regardez les tendances de qualité (la couverture de tests monte ou descend, les bugs ouverts s'accumulent ou se résorbent), vous écoutez le ressenti terrain, et vous demandez à l'équipe de traduire son travail en avancement métier, pas en détail technique. Un bon développeur sait expliquer où il en est sans vous noyer dans l'implémentation ; s'il n'y arrive pas, c'est en soi un signal. Vous n'avez pas besoin de relire le code pour savoir si l'équipe est saine, vous avez besoin de savoir quoi écouter et quoi regarder. Pour la suite logique, savoir avec qui et dans quel ordre étoffer cette équipe, le guide composer sa première équipe tech prend le relais.

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.

Si vous deviez ne retenir qu'une chose, ce serait celle-ci : une métrique n'a de valeur que par la conversation qu'elle déclenche. Un chiffre que personne ne regarde ne sert à rien ; un chiffre transformé en cible individuelle devient nuisible. Entre les deux, il y a la bonne pratique : peu d'indicateurs, lus en tendance, partagés ouvertement avec l'équipe et les parties prenantes, au service d'une décision et non d'un jugement. Pour aller plus loin sur le pendant produit de ces signaux, le CPO a lui aussi ses métriques qui comptent vraiment.