Les KPIs d'Ingénierie qui Comptent Vraiment
J'ai assisté un jour à une réunion du conseil d'administration où un VP Engineering a présenté un tableau de bord avec douze métriques. Lignes de code par développeur. Nombre de PRs par sprint. Story points complétés. Tout était au vert. Le conseil a hoché la tête.
Deux mois plus tard, le produit ne pouvait toujours pas intégrer un client sans contournement manuel, les déploiements plantaient une semaine sur deux, et deux ingénieurs senior avaient commencé à passer des entretiens ailleurs.
Le tableau de bord mesurait l'activité. Personne ne mesurait si l'organisation d'ingénierie était saine, productive ou en progression. C'est le piège : les équipes choisissent des métriques faciles à collecter plutôt que des métriques qui leur apprennent quelque chose d'utile.
Les Métriques qui Vous Disent Vraiment Quelque Chose
Métriques DORA : Votre Référence de Livraison
J'ai écrit sur les métriques DORA en détail auparavant, donc je ne vais pas répéter l'argumentaire complet ici. Mais les quatre métriques DORA — Fréquence de Déploiement, Lead Time pour les Changements, Temps Moyen de Restauration et Taux d'Échec des Changements — sont ce qui se rapproche le plus d'une mesure scientifiquement validée de la performance de livraison logicielle.
Elles restent le fondement. Si vous ne les suivez pas, commencez par là avant d'ajouter quoi que ce soit d'autre. Elles vous indiquent si votre équipe peut livrer de manière fiable et se rétablir rapidement, ce qui est la base de tout le reste.
Cycle Time : De l'Idée à la Production
Le cycle time va plus loin que le lead time de DORA. Il mesure le parcours complet depuis "nous avons décidé de construire ceci" jusqu'à "c'est en production et les utilisateurs l'utilisent". Cela capture les décisions produit, les transferts de design, les clarifications de spécifications — tous les goulots d'étranglement non-code que les équipes d'ingénierie héritent.
Quand le cycle time est élevé mais que le lead time DORA est faible, le problème n'est pas dans l'exécution technique. C'est dans tout ce qui est en amont : spécifications peu claires, approbations lentes, goulots d'étranglement design, ou trop de choses en cours simultanément. Le cycle time révèle la friction organisationnelle, pas seulement la friction du pipeline.
Suivez-le en horodatant quand un ticket passe de "prêt pour le développement" à "déployé". La plupart des outils de gestion de projet peuvent afficher cela avec une configuration minimale.
Incidents avec Impact Client
Tous les incidents ne se valent pas. Un job en arrière-plan qui échoue mais réessaie avec succès n'est pas la même chose qu'un checkout en panne pendant 40 minutes un vendredi après-midi. Ce qui compte, c'est la fréquence et la gravité des incidents que les utilisateurs ressentent réellement.
Suivez deux choses :
- Fréquence des incidents — combien d'incidents avec impact client par mois ?
- Distribution de la gravité — sont-ils SEV-1 (critiques pour l'activité) ou SEV-3 (dégradation mineure) ?
Une équipe qui a deux SEV-3 par mois est dans une position fondamentalement différente d'une équipe qui a deux SEV-1 par mois, même si le nombre est identique. Agréger sans la gravité n'a aucun sens.
La tendance compte plus que le nombre absolu. Les incidents diminuent-ils dans le temps ? La gravité baisse-t-elle ? Cela vous dit si vos investissements en fiabilité portent leurs fruits.
Temps-jusqu'à-Première-Valeur pour les Nouvelles Recrues
Celle-ci est sous-estimée et presque personne ne la suit : combien de temps faut-il à un nouvel ingénieur pour livrer quelque chose de significatif en production ?
Pas "combien de temps jusqu'à ce qu'ils fusionnent une correction de faute de frappe". Combien de temps jusqu'à ce qu'ils livrent un vrai travail — une fonctionnalité, une correction de bug avec impact business, une amélioration d'infrastructure significative.
Si les nouveaux ingénieurs mettent six semaines à livrer leur première contribution réelle, vous avez un problème d'onboarding, un problème de complexité de base de code, ou les deux. Les équipes d'élite font livrer les nouvelles recrues dès la première semaine. Pas parce qu'elles prennent des raccourcis, mais parce qu'elles ont investi dans la documentation, l'expérience développeur et une propriété claire.
Cette métrique vous dit aussi quelque chose sur la qualité des recrutements. Si un ingénieur met trois mois à devenir productif quelle que soit son ancienneté, le problème vient probablement de votre environnement, pas de la personne.
Satisfaction et Engagement de l'Ingénierie
Je sais — ça semble mou. Mais la rétention en ingénierie est l'une des lignes de coût les plus chères que vous ne suivez pas, et quand quelqu'un remet sa démission, le mal est fait. Remplacer un ingénieur senior coûte six mois de salaire et douze mois de contexte.
Faites une enquête de pouls trimestrielle. Cinq à sept questions : Croyez-vous en ce que nous construisons ? Avez-vous les outils pour faire votre meilleur travail ? Avez-vous le sentiment de progresser ? Recommanderiez-vous cette équipe à un ami ? Suivez les tendances. Une tendance à la baisse sur deux trimestres est une alarme incendie.
Les Métriques Dangereuses
Certaines métriques ne sont pas seulement inutiles — elles endommagent activement les équipes quand le leadership y prête attention.
Lignes de code. Un développeur qui supprime 500 lignes de code mort et simplifie un module a fait un travail plus précieux que celui qui a écrit 500 lignes de nouveau code pour résoudre un problème qui aurait pu être évité. Mesurer les lignes de code incite au bloat.
Nombre de commits. Facile à manipuler, trivialement gonflé, et ne vous dit rien sur la qualité ou l'impact du travail. Un développeur travaillant sur un problème architectural difficile pourrait avoir trois commits en une semaine. Un développeur produisant du boilerplate pourrait en avoir trente. Les trois commits valent probablement plus.
Métriques de performance individuelle. Classer les développeurs par nombre de PRs ou tickets fermés crée une compétition qui détruit la collaboration. Les meilleures cultures sont orientées équipe. Le classement individuel pousse les gens vers le comportement de héros et loin des revues de code, du mentorat et de l'aide aux coéquipiers.
Heures enregistrées. Mesure la présence, pas la productivité. Les ingénieurs senior font souvent leur travail le plus impactant en moins d'heures. Si vous mesurez les heures, vous gérez une chaîne de montage.
Présenter les Métriques au Leadership Sans Qu'Elles Soient Manipulées
Le conseil veut savoir trois choses : L'équipe est-elle efficace ? S'améliore-t-elle ? Où sont les risques ?
Voici la structure que j'utilise :
Performance de livraison — métriques DORA, avec tendance trimestrielle. Montrez la direction, pas seulement le chiffre. "Notre fréquence de déploiement est passée de hebdomadaire à quotidienne ce trimestre, et le taux d'échec des changements est passé de 22% à 11%." C'est une histoire que le conseil peut suivre.
Qualité et fiabilité — incidents avec impact client avec tendance mensuelle, avec répartition de la gravité. Si les incidents augmentent, expliquez pourquoi (nouvelle zone fonctionnelle, défis de montée en charge) et ce que vous faites à ce sujet.
Santé de l'équipe — temps-jusqu'à-première-valeur pour les recrues récentes, plus les tendances d'engagement. Ce sont des indicateurs avancés. Une équipe saine avec un onboarding solide et un engagement élevé livrera. Une équipe épuisée avec un pipeline d'onboarding cassé est un risque, même si la production actuelle semble bonne.
Une chose à surveiller : présentez des métriques au niveau équipe, jamais des métriques individuelles. Dès qu'un membre du conseil voit une liste classée de performance des développeurs, il vous demandera de gérer d'après cette liste. Et alors la métrique devient l'objectif, l'objectif est manipulé, et vous avez perdu le signal.
Gardez le tableau de bord à cinq ou six métriques. Si vous avez besoin de douze métriques pour expliquer comment va l'ingénierie, c'est que vous ne comprenez pas comment va l'ingénierie.
La Métrique Derrière la Métrique
Chaque métrique est un proxy. Les métriques DORA sont un proxy pour la capacité de livraison. Les nombres d'incidents sont un proxy pour la fiabilité. Les scores d'engagement sont un proxy pour le risque de rétention. Aucune ne capture le tableau complet à elle seule.
La vraie compétence en leadership d'ingénierie, c'est savoir quels proxies faire confiance, quand approfondir l'investigation, et quand un chiffre vous dit ce que vous voulez entendre plutôt que ce qui se passe réellement.
Chez Conectia, quand nous intégrons des ingénieurs senior dans une équipe, ils deviennent souvent le catalyseur d'une meilleure mesure — non pas parce qu'ils installent des tableaux de bord, mais parce qu'ils apportent l'habitude de demander "comment savons-nous que ça fonctionne ?". Ils ont vu suffisamment d'équipes pour savoir quels signaux comptent et lesquels sont du bruit. C'est un état d'esprit que vous ne pouvez pas obtenir d'une métrique.
Vous voulez des ingénieurs qui apportent le jugement pour savoir quoi mesurer et quoi ignorer ? Parlez à un CTO — nos ingénieurs senior LATAM ont travaillé dans suffisamment d'équipes pour savoir quels KPIs font vraiment bouger les choses.
