Glossaire des métriques d’ingénierie et de l’agilité
Les termes que les équipes d’ingénierie utilisent pour planifier, estimer, mesurer et s’améliorer — définis en langage clair, avec une lecture approfondie liée quand elle existe dans nos cours gratuits et notre blogue.
34 termes · 6 sections · Publié en juillet 2026
Livraison et flux
7 termesTemps de cycle
Le temps de cycle est le temps entre le début du travail sur un élément et la fin de ce travail : le chronomètre part quand quelqu’un commence l’élément et s’arrête quand il est complété. Il mesure l’efficacité interne de l’équipe, et sa variation compte autant que sa moyenne. Une équipe dont les éléments prennent de 3 à 5 jours est bien plus prévisible qu’une équipe qui varie de 1 à 30.
Délai de livraison (lead time)
Le délai de livraison (lead time) est le temps total entre la demande d’un travail et sa livraison au client. Il équivaut au temps de cycle plus le temps en file d’attente, et les files représentent souvent 80 % ou plus. Le lead time est ce que vivent les clients; le temps de cycle est ce que l’équipe contrôle directement. Les deux comptent, et les équipes qui ne voient que le temps de cycle sous-estiment énormément la durée réelle de la livraison.
Débit (throughput)
Le débit (throughput) est le nombre d’éléments de travail qu’une équipe complète par unité de temps, par exemple huit fonctionnalités par sprint. Il mesure le taux de sortie et la capacité d’un système de livraison. Contrairement à la vélocité, le débit compte les éléments terminés plutôt que des points estimés, ce qui en fait une quantité mesurée et non devinée.
Limite de WIP
Une limite de WIP est un plafond sur le nombre d’éléments de travail qu’une équipe accepte en cours à la fois. C’est la pratique kanban la plus contre-intuitive : en faisant moins à la fois, tu termines plus au total, parce que la loi de Little lie le délai de livraison directement à la quantité de travail dans le système. Les limites de WIP sont des expériences, pas des calculs; commence quelque part et ajuste.
Loi de Little
La loi de Little est une relation de la théorie des files d’attente, démontrée par John Little en 1961, qui établit que le délai de livraison égale le travail en cours divisé par le débit. Pour tout système stable, réduire le WIP raccourcit le délai sans que personne travaille plus vite. Une équipe qui termine 10 éléments par semaine avec 40 en cours prend en moyenne 4 semaines par élément; plafonner le WIP à 20 réduit ça de moitié, à 2.
Blocage
Un blocage est tout ce qui empêche un élément de travail ou une personne d’avancer : une dépendance envers une autre équipe, une panne technique, des exigences floues, des ressources manquantes ou un fournisseur externe. Les blocages passés sous silence ou peu discutés comptent parmi les pires tueurs d’objectifs de sprint, et c’est pourquoi les faire remonter est la partie la plus précieuse de toute mêlée.
Dette technique
La dette technique est le coût accumulé des raccourcis pris dans le code, chaque « je nettoierai ça plus tard » qui n’arrive jamais. Comme une dette financière, elle porte intérêt : le code désordonné prend plus de temps à changer, cache des bogues et ralentit les nouveaux membres de l’équipe. Le remaniement continu est la façon dont les équipes remboursent la dette avant qu’elle ne se transforme en base de code ingérable.
Plus : Refactoring (XP Essentials)
Estimation et planification
4 termesPoints de récit
Les points de récit sont une unité d’estimation relative qui combine l’effort, la complexité et l’incertitude plutôt que le temps. Un récit de 5 points représente environ deux fois l’effort d’un récit de 2 points, mais pas nécessairement deux fois les heures. Les échelles courantes incluent Fibonacci (1, 2, 3, 5, 8, 13), les puissances de 2 et les tailles de t-shirt, où les écarts entre les valeurs forcent un vrai choix.
Vélocité
La vélocité est le nombre de points de récit qu’une équipe complète par sprint, utilisée pour transformer des estimations relatives en prévisions. La logique est « la météo d’hier » : une équipe qui a fait en moyenne 25 points en complétera probablement environ 25 au prochain sprint. La vélocité est un outil de planification, pas une métrique de productivité; fixe des cibles dessus et les équipes gonflent simplement leurs estimations.
Planning poker
Le planning poker est une technique d’estimation où chacun estime un élément de travail en privé et le révèle au même moment, ce qui élimine l’ancrage sur le premier chiffre prononcé. L’écart est le signal : un 3 unanime signifie une compréhension partagée et on passe au suivant, tandis qu’un écart entre 2 et 13 signifie que deux personnes imaginent un travail fondamentalement différent.
Plus : The Minimum Useful Estimate (Software Delivery Fundamentals)
Sprint
Un sprint est une itération de durée fixe d’un mois ou moins qui sert de battement de cœur à scrum et contient tous les autres événements scrum. Les sprints s’enchaînent sans pause, chacun porte un objectif de sprint qui donne le focus, et chacun devrait se terminer par un incrément potentiellement livrable. Une durée de sprint constante bâtit le rythme et la prévisibilité.
Cérémonies
5 termesRétrospective
Une rétrospective est une rencontre d’équipe récurrente qui inspecte la façon dont l’équipe a travaillé ensemble durant le dernier sprint et produit un plan d’amélioration. Les participants sont l’équipe seulement, sans parties prenantes, et le résultat est un petit ensemble d’améliorations actionnables. C’est le cœur de l’amélioration continue : saute-la et l’équipe arrête de s’améliorer.
Mêlée quotidienne (daily scrum)
Une mêlée quotidienne, appelée daily scrum dans scrum, est un événement quotidien de 15 minutes où les développeurs inspectent la progression vers l’objectif du sprint et adaptent le plan de la journée. C’est de la coordination, pas un rapport d’état : le résultat est un plan à jour, et les blocages remontent ici mais se règlent après, pas pendant la rencontre.
Mêlée quotidienne asynchrone
Une mêlée asynchrone est une mêlée qui se tient sans rencontre synchrone : les mises à jour sont générées automatiquement à partir de l’activité déjà enregistrée dans des outils comme Jira, Linear, GitHub et GitLab, ou soumises par écrit à l’horaire de chacun. La prémisse est simple : si le travail est déjà enregistré quelque part, les humains ne devraient pas avoir à le réciter.
Action (action item)
Une action est un engagement précis, avec un responsable, de changer quelque chose, typiquement produit par une rétrospective. La plupart meurent en silence : un sondage de la communauté du PMI a révélé que près des deux tiers des équipes mettent en œuvre moins de 25 % des actions de leurs rétrospectives. Chaque action abandonnée est une petite promesse brisée, et avec assez de promesses brisées, l’équipe apprend à arrêter de soulever les problèmes.
Sécurité psychologique
La sécurité psychologique est la conviction que tu peux t’exprimer — questions, préoccupations, erreurs ou désaccords — sans punition ni humiliation. Ce n’est pas une question de gentillesse; c’est une question de franchise rendue possible. Le projet Aristote de Google a révélé que la sécurité psychologique était le prédicteur numéro un des équipes performantes, plus important que le talent individuel.
Plus : Creating Psychological Safety (Scrum Master Essentials)
Mesure et métriques
10 termesMétriques DORA
Les métriques DORA sont quatre mesures de la performance de livraison logicielle : fréquence de déploiement, délai de livraison des changements, taux d’échec des changements et temps moyen de rétablissement. Elles viennent du programme DevOps Research and Assessment derrière la recherche Accelerate et les rapports annuels State of DevOps, qui constatent invariablement que les équipes d’élite livrent plus vite avec moins d’échecs. Mesurées en vase clos, elles sont de l’instrumentation, pas de l’insight.
Fréquence de déploiement
La fréquence de déploiement est la métrique DORA qui mesure la fréquence à laquelle une équipe livre du code en production. Elle peut être calculée automatiquement depuis les pipelines CI/CD comme GitHub Actions, GitLab CI/CD et Bitbucket Pipelines. Au-delà du chiffre brut, c’est une preuve de débit réel : une équipe qui déploie souvent avec une qualité stable démontre la livraison, pas juste la fermeture de billets.
Délai de livraison des changements
Le délai de livraison des changements est la métrique DORA qui mesure le temps qu’un commit prend pour se rendre en production. Les longs délais s’expliquent généralement par un WIP élevé, de gros lots ou des goulots de révision plutôt que par du code lent, alors cette métrique se lit mieux avec les signaux de flux déjà présents dans tes données de gestion de projet.
Taux d’échec des changements
Le taux d’échec des changements est la métrique DORA qui mesure le pourcentage de déploiements en production causant un échec qui demande une correction. C’est un signal de qualité : les pics corrèlent souvent avec des échéanciers pressés, de nouveaux contributeurs ou des changements d’infrastructure, et c’est pourquoi le chiffre est le plus utile quand il est relié au contexte de sprint qui l’explique.
Temps moyen de rétablissement (MTTR)
Le temps moyen de rétablissement, ou MTTR, est la métrique DORA qui mesure le temps nécessaire pour rétablir le service après une panne en production. Un rétablissement rapide signale une réponse aux incidents solide et une connaissance profonde de la base de code, et c’est pourquoi le MTTR se lit comme un signal de responsabilité et d’opérations plutôt qu’un pur chiffre de vitesse.
Efficacité du développeur
L’efficacité du développeur mesure si le travail d’une personne en ingénierie crée des résultats durables, pas la quantité d’activité qu’il génère. Simyl Flow la note sur six dimensions : Livraison, Flux, Qualité, Collaboration, Responsabilité et Adaptabilité. La notation multidimensionnelle résiste à la manipulation, et la mesure reste axée sur les résultats : aucun suivi des frappes, aucune surveillance de l’utilisation des outils, et les profils individuels sont privés par défaut.
Productivité vs efficacité du développeur
La productivité et l’efficacité du développeur sont des mesures différentes : la productivité compte l’activité (commits, lignes de code, billets fermés) tandis que l’efficacité mesure les résultats, soit si le travail livré a créé de la valeur durable. La distinction compte parce que les métriques d’activité invitent à la surveillance et à la manipulation, alors que l’efficacité déduit à partir des résultats au lieu de suivre l’utilisation des outils, et privilégie le coaching plutôt que le jugement.
Score de santé
Un score de santé est une note de 0 à 100, avec des lettres de A à F, qui résume la santé de sprint d’une équipe sur les six dimensions d’efficacité. Son rôle est de fermer la boucle d’amélioration : après qu’une rétrospective a changé la façon de travailler de l’équipe, la tendance du score de santé montre si ce changement a vraiment fait bouger l’aiguille.
Loi de Goodhart
La loi de Goodhart est l’observation, nommée d’après l’économiste britannique Charles Goodhart, que « quand une mesure devient une cible, elle cesse d’être une bonne mesure ». En ingénierie, elle se manifeste par la manipulation des métriques : cible la vélocité et les estimations gonflent; cible les récits fermés et le travail est marqué terminé avant de l’être. Le tableau de bord reste vert pendant que la livraison souffre.
Métriques de vanité
Les métriques de vanité sont des chiffres qui montent sans corréler avec les résultats d’affaires : commits par jour, lignes de code, points de récit complétés, PR fusionnées. Elles sont tentantes parce qu’elles sont faciles à collecter et donnent des graphiques satisfaisants, mais elles créent des incitatifs pervers et une illusion de visibilité. Le test : si ce chiffre double, est-ce que la valeur d’affaires double?
Méthodes
5 termesScrum
Scrum est un cadre agile léger pour développer des produits complexes, fondé sur l’empirisme : transparence, inspection et adaptation. Il définit trois rôles (product owner, scrum master, développeurs), cinq événements dont le sprint et la rétrospective, et trois artefacts. Le Guide Scrum ne fait que 13 pages parce que scrum est volontairement incomplet : un cadre avec des garde-fous, pas une méthodologie étape par étape.
Kanban
Kanban est une méthode adaptative pour gérer le travail intellectuel qui visualise le flux de travail, limite le travail en cours et fait évoluer le processus par incréments. Sa philosophie est « commence où tu es » : aucun rôle prescrit, aucun événement requis, aucune itération fixe. Elle est née du système de production de Toyota et a été adaptée au logiciel par David J. Anderson dans les années 2000.
Extreme Programming (XP)
Extreme Programming (XP) est une méthodologie agile, établie par le livre de Kent Beck de 1999 Extreme Programming Explained, qui est prescriptive sur la pratique d’ingénierie là où scrum reste silencieux : écris les tests d’abord, programme en binôme, remanie continuellement et intègre plusieurs fois par jour. Ses cinq valeurs sont la communication, la simplicité, la rétroaction, le courage et le respect.
Plus : XP Essentials (free course)
Programmation en binôme
La programmation en binôme, c’est deux développeurs qui travaillent ensemble à un même poste : l’un tape (le conducteur) pendant que l’autre observe, anticipe et navigue. La recherche citée dans la littérature XP montre que les binômes produisent du code avec environ 15 % moins de défauts en ne prenant qu’environ 15 % plus de temps — en somme, une révision de code continue plus une diffusion des connaissances dans l’équipe.
Développement piloté par les tests (TDD)
Le développement piloté par les tests (TDD) est la pratique d’écrire un test qui échoue avant d’écrire le code de production, répétée dans un cycle rouge-vert-remaniement : écris un test qui échoue, écris le minimum de code pour le faire passer, puis nettoie pendant que les tests restent verts. Le TDD est une technique de conception déguisée en technique de test; la réflexion qui produit les tests est le but.
IA et outillage
3 termesMCP (Model Context Protocol)
MCP, le Model Context Protocol, est un protocole ouvert qui permet aux assistants IA comme Claude et ChatGPT de se connecter directement à des outils et des sources de données externes. Simyl Flow expose 17 outils MCP en lecture seule sur 8 domaines, couvrant les mêlées, les rétrospectives, les métriques et les actions, pour que les assistants IA qu’une équipe adopte puissent vérifier s’ils aident vraiment.
Plus : AI assistant integrations
Workflow exhaust
Le workflow exhaust, ce sont les données structurées que tes outils existants émettent déjà comme effet secondaire du travail normal : historique de commits, révisions de PR, transitions de billets et exécutions de pipelines CI/CD. Le principe derrière le terme : les données nécessaires pour mesurer la livraison existent déjà; le problème n’a jamais été la disponibilité, mais qu’elles restaient dans des silos, déconnectées du contexte qui leur donne un sens.
Ship and stick
Ship and stick est un cadre de mesure qui pose deux questions sur tout changement dans la façon de travailler d’une équipe, qu’il s’agisse d’un nouvel outil, d’un processus ou d’un assistant IA : le travail a-t-il été livré, et a-t-il continué à créer de la valeur en production? Ses signes vitaux incluent le taux de reprise (retours en arrière et correctifs urgents), la trajectoire de qualité dans le temps et la prévisibilité de la livraison, lus ensemble plutôt qu’en vase clos.
Les définitions, c’est la partie facile
Savoir ce que veut dire temps de cycle, ce n’est pas la même chose que connaître le tien. Simyl Flow calcule ces métriques à partir des outils que ton équipe utilise déjà et montre si tes changements fonctionnent.