Quelle est la santé de votre équipe technique ?

Chaque dimension croise deux ou trois indicateurs. Le délai de revue, par exemple, prend davantage de sens quand on le regarde avec les incidents de livraison. Les pourcentages indiquent le poids de chaque indicateur dans sa dimension.

La question « combien de départs mettraient le projet en danger ? » porte sur le bus factor : le nombre minimal de départs qui ferait perdre des connaissances indispensables au projet. Plus ce nombre est bas, plus cette dépendance mérite d’être discutée avec l’équipe.

• Partage de connaissances : les personnes indispensables (60 %) et le temps qu’il faut à un nouveau développeur pour livrer une première contribution significative (40 %).
• Vélocité : le délai entre un ticket et sa mise en production (40 %), la fréquence de déploiement (30 %) et le délai de revue des pull requests (30 %).
• Qualité : la fréquence des incidents causés par un déploiement (40 %), le temps de rétablissement après une mise en production ratée (30 %) et le délai de revue (30 %).
• Autonomie : la possibilité de livrer une fonctionnalité courante sans attendre quelqu’un (70 %) et la part du temps passée en réunion (30 %).
• Scalabilité : le temps d’intégration (50 %), les personnes indispensables (30 %) et la taille de l’équipe (20 %), car une petite équipe a moins de marge pour absorber une arrivée ou un départ.
• Moral : le moral perçu (40 %), les départs volontaires des douze derniers mois (40 %) et la charge de réunions (20 %).

Chaque dimension est la moyenne pondérée de ses indicateurs, arrondie à l’entier. Le score global est la moyenne des six dimensions, et il place l’équipe dans l’un des quatre niveaux ci-dessous.

Le rapport retient toujours les deux dimensions les plus basses comme points d’attention prioritaires, même quand le score global est bon. Ce classement permet de commencer la discussion ; il ne prouve pas à lui seul qu’une action est nécessaire. Certaines réponses plafonnent une dimension : une seule personne indispensable limite le partage de connaissances à 40, et une livraison qui dépend d’une personne clé limite l’autonomie à 30.

Quand deux personnes répondent, le rapport compare leurs lectures : l’écart d’une dimension est la différence entre leurs deux scores, de 0 à 100. Les écarts sont classés du plus grand au plus petit, et les deux premiers sont mis en avant, car ce sont eux qui méritent une discussion avant toute action.

• De 80 à 100, « Épanoui » : l’équipe livre, partage et tient la charge. L’enjeu est de le rester pendant la croissance.
• De 60 à 79, « Solide » : les fondations tiennent, une ou deux dimensions demandent une action ciblée.
• De 40 à 59, « Fragile » : plusieurs signaux se renforcent. Sans correction, la livraison ralentit et les départs deviennent plus probables.
• Sous 40, « Critique » : l’équipe fonctionne en mode survie. La priorité est de sécuriser les personnes clés et la mise en production.

DORA (DevOps Research and Assessment) est le programme de recherche qui publie chaque année le rapport « Accelerate State of DevOps ». Ses métriques de livraison logicielle sont très utilisées pour mesurer la performance d’une équipe de développement. Le radar reprend les quatre métriques historiques, sous une forme qu’un dirigeant peut renseigner sans outillage.

Les choix des questions sur la fréquence de déploiement et le temps de rétablissement suivent les paliers du rapport 2024 : les équipes les plus performantes déploient à la demande, plusieurs fois par jour, et se rétablissent en moins d’une heure ; les moins performantes déploient entre une fois par mois et une fois tous les six mois, et mettent entre une semaine et un mois à se rétablir.

DORA compte aujourd’hui cinq métriques, avec le taux de déploiements non planifiés causés par un incident. Elle précise qu’elles s’appliquent à une application ou à un service, et qu’elles ne servent pas à mettre des équipes en concurrence. Le radar suit le même principe : il décrit un système de travail, pas la performance de chacun.

• Fréquence de déploiement : combien de fois l’équipe met en production sur une période. C’est une question du radar, comptée dans la vélocité.
• Délai de mise en production d’un changement : DORA le mesure du commit au déploiement. Le radar demande le délai entre le ticket et la production, plus large, car il inclut l’attente avant le développement, celle que voit un dirigeant.
• Taux d’échec des changements : la part des déploiements qui exigent une intervention immédiate. Le radar demande à quelle fréquence un déploiement cause un incident.
• Temps de rétablissement après un déploiement raté : le temps qu’il faut pour rétablir le service. C’est une question du radar, comptée dans la qualité.

Sources

• DORA, les métriques de performance de livraison logicielle (en anglais) (nouvel onglet)
• DORA, rapport Accelerate State of DevOps 2024 (en anglais) (nouvel onglet)

Ces profils illustrent des combinaisons possibles de réponses au questionnaire. Ils peuvent vous aider à choisir les questions à poser à l’équipe.

• L’équipe qui repose sur un héros : la vélocité et la qualité tiennent, parfois très bien, mais le partage de connaissances, la scalabilité et souvent l’autonomie sont en creux. Une personne indispensable, une intégration longue, des livraisons qui passent par elle. Première action : faire circuler son savoir avant de lui confier davantage.
• L’équipe bloquée par les validations : l’autonomie et la vélocité sont basses, la qualité reste correcte. Plusieurs validations par fonctionnalité, des revues qui attendent plusieurs jours, beaucoup de réunions. Le code sort propre, mais lentement. Première action : examiner ce que protège chaque validation, retirer une étape redondante si le contrôle reste assuré et convenir d’un délai de revue.
• L’équipe qui s’use : le moral est bas, avec une charge de réunions élevée et des départs récents, alors que la vélocité et la qualité restent bonnes. Les livraisons peuvent masquer cette difficulté. Première action : écouter l’équipe, alléger les réunions et examiner les causes de départ.

Quand les livraisons ralentissent, examinez comment le travail circule : les temps d’attente, les validations et les dépendances peuvent expliquer une partie des délais.

Les causes ci-dessous laissent chacune une trace dans les réponses du radar. Le radar ne dit pas laquelle domine chez vous, mais il montre où chercher en premier.

• Le travail attend : revues qui prennent plusieurs jours, validations en série, une personne clé par qui tout passe. Le temps de développement change peu, le temps d’attente s’allonge.
• Les mises en production font peur : l’équipe déploie moins souvent, regroupe les changements, et chaque livraison devient plus lourde et plus risquée.
• La dette technique s’accumule : chaque évolution touche du code fragile, et les incidents consomment le temps prévu pour la roadmap. Le calculateur de dette technique en estime le coût.
• Le savoir est concentré : les nouveaux arrivants mettent des semaines à contribuer, et les plus anciens passent leur temps à répondre aux questions.
• Les réunions grignotent le temps de construction : à partir de 40 % du temps en réunion, la réponse ne vaut plus que 33 points sur 100, et 0 au-delà de 60 %, en autonomie comme en moral.
• L’équipe s’use : chaque départ emporte du savoir et relance une intégration, ce qui pèse sur ceux qui restent.

• Enquêter sur le ralentissement d’une équipe de développement