Externaliser sans piloter, c'est avancer à l'aveugle. Mais piloter à coups de tableaux de bord intrusifs, c'est tuer la relation et perdre du temps. Le bon équilibre tient en quelques KPI orientés résultat, lus avec discernement. Voici lesquels suivre — et lesquels ignorer.
Le principe : mesurer la valeur, pas l'activité
La tentation est de mesurer ce qui se compte facilement : heures travaillées, lignes de code, tickets fermés. Le problème est que ces chiffres mesurent l'activité, pas la valeur. Un développeur peut produire beaucoup de code médiocre, ou peu de code excellent. Les bons KPI regardent le résultat.
Les trois familles de KPI utiles
1. La prévisibilité
L'indicateur le plus parlant : l'écart entre l'estimé et le livré. Une mission saine livre à peu près ce qui était prévu, dans les délais annoncés. Des écarts répétés signalent soit un problème d'estimation, soit un blocage non remonté.
- À suivre : part des tâches livrées dans le délai estimé.
- Bon signe : régularité, même imparfaite.
2. La qualité
La qualité se mesure surtout après coup :
bugs détectés après mise en production sur le périmètre du développeur ;
retours en revue de code : une revue qui passe sans correction majeure est bon signe ;
stabilité : le code livré ne casse pas d'autres parties du produit.
À suivre : nombre d'incidents post-livraison, taux de revues sans retour bloquant.
Bon signe : tendance stable ou décroissante dans le temps.
3. La fluidité de collaboration
Souvent négligée, c'est pourtant elle qui fait la différence sur la durée :
délai de réponse dans les échanges quotidiens ;
blocages signalés tôt plutôt que découverts à la livraison ;
participation aux rituels (daily, revues).
À suivre : qualitatif, observé en continu plutôt que chiffré.
Bon signe : le développeur lève la main avant d'être bloqué une journée entière.
Les KPI à éviter
- Le nombre de lignes de code. Plus de code n'est pas mieux ; souvent l'inverse.
- Les heures pointées. Vous payez un résultat, pas une présence.
- Le nombre de tickets fermés pris isolément : un ticket peut être trivial ou majeur.
Ces métriques poussent à optimiser le mauvais comportement.
Lire les KPI sans micromanager
Trois règles simples :
- Peu d'indicateurs, bien choisis. Trois à cinq suffisent.
- Une tendance, pas une photo. Un mauvais chiffre isolé n'est pas un signal ; une tendance l'est.
- Le KPI ouvre une conversation, il ne la remplace pas. Un écart se discute lors d'un point régulier, pas par un email comminatoire.
En résumé
| Famille | Bon KPI | À éviter |
|---|---|---|
| Prévisibilité | Écart estimé / livré | — |
| Qualité | Bugs post-prod, revues sans retour | Lignes de code |
| Fluidité | Réponse rapide, blocages remontés tôt | Heures pointées |
Chez MG Talents, ce pilotage est facilité par l'intégration du développeur à vos rituels et un interlocuteur unique côté agence. L'essai de deux semaines est d'ailleurs le premier endroit où ces indicateurs deviennent visibles : vous voyez la prévisibilité, la qualité et la fluidité réelles avant tout engagement durable.