Piloter une externalisation sans indicateurs, c'est avancer à l'aveugle ; la piloter avec trente métriques, c'est se noyer. La bonne approche tient en une dizaine de KPI, répartis en quatre familles, lus en tendance. Voici la liste complète, avec ce que chacun révèle.

Famille 1 — Prévisibilité

1. Écart estimé / livré. La part des tâches livrées dans le délai annoncé. C'est l'indicateur le plus parlant : une mission saine livre à peu près ce qui était prévu.

2. Respect du périmètre. Le travail livré correspond-il à ce qui était demandé, sans dérive ni raccourci ? Mesure la fiabilité de la compréhension.

3. Stabilité des estimations. Les estimations sont-elles régulièrement révisées à la hausse en cours de route ? Une dérive répétée signale un problème de cadrage ou de séniorité.

Famille 2 — Qualité

4. Bugs après mise en production. Le nombre d'incidents sur le périmètre du développeur après déploiement. La qualité réelle se lit après coup, pas à la livraison.

5. Taux de revues sans retour bloquant. Une revue de code qui passe sans correction majeure est bon signe. Un taux qui se dégrade alerte tôt.

6. Dette technique introduite. Le code livré facilite-t-il ou complique-t-il les évolutions futures ? Qualitatif, mais essentiel sur la durée.

Famille 3 — Fluidité

7. Délai de réponse. Le temps de réaction dans les échanges quotidiens. La fluidité est souvent le premier indicateur à se dégrader quand une mission tourne mal.

8. Blocages signalés tôt. Un bon développeur lève la main avant d'être bloqué une journée entière. Des blocages découverts à la livraison sont un signal négatif.

9. Participation aux rituels. Présence et contribution réelle aux daily, sprints et revues. Mesure l'intégration à l'équipe.

Famille 4 — Valeur

10. Fonctionnalités réellement en production. Au bout du compte, le seul KPI qui résume les autres : ce qui est livré, stable, et utilisé. C'est la valeur, pas l'activité.

Les KPI à NE PAS suivre

Trois métriques séduisantes mais trompeuses :

  • 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 isolément — un ticket peut être trivial ou majeur.

Ces métriques poussent à optimiser le mauvais comportement.

Comment les lire

Règle Pourquoi
Peu d'indicateurs (3 à 5 actifs) Trop de KPI = aucun suivi réel
Des tendances, pas des photos Un mauvais chiffre isolé n'est pas un signal
Le KPI ouvre une conversation Il ne remplace pas le point régulier
Mesurer la valeur, pas l'activité L'activité se simule, la valeur non

Quand ces KPI deviennent visibles

Le meilleur moment pour observer ces indicateurs, c'est dès les premières semaines. C'est tout l'intérêt d'un essai court : la prévisibilité, la qualité et la fluidité réelles se révèlent vite sur de vraies tâches.

Chez MG Talents, l'essai de deux semaines sur votre backlog réel rend ces KPI lisibles d'emblée, et l'intégration du développeur à vos rituels — avec un interlocuteur unique côté agence — facilite leur suivi sans micromanagement. Vous décidez de poursuivre sur des indicateurs concrets, pas sur une promesse.