Coach agile vous accompagne dans votre agilité
Dec 17

Il faut que je te parle de SPACE : un framework pour mesurer la performance des équipes de développement

La mesure de la productivité des développeurs a longtemps posé (et pose encore) problème.

Pendant des années, managers et équipes ont cherché le bon indicateur, souvent en vain. Faut-il compter les lignes de code, le nombre de commits, la vélocité ?

En réalité, aucune mesure unique ne peut résumer la performance d’une équipe de développement. Le framework SPACE a été conçu précisément pour résoudre ce dilemme. Issu de travaux récents, SPACE propose une approche multidimensionnelle qui prend en compte à la fois les résultats, l’activité, la collaboration, l’efficacité et, surtout, le facteur humain. SPACE offre ainsi une vision plus complète et plus juste de la performance des équipes de développement qu’une simple métrique unidimensionnelle.

Cerise sur le gâteau (en tout cas pour moi), à l’origine de SPACE il y a aussi Nicole Forsgren, co-autrice d’Accelerate dont j’ai tant pu parler sur Scrum Life.

Origine du framework SPACE

Le framework SPACE a vu le jour en 2021 sous l’impulsion d’un groupe de chercheurs de GitHub, Microsoft Research et l’Université de Victoria, parmi lesquels, comme je viens de le mentionner, Nicole Forsgren et la professeure Margaret-Anne Storey.

Ce collectif de chercheurs s’est penché sur LA question que j’ai personnellement croisée tout au long de ma carrière : la difficulté persistante à définir et mesurer la “productivité” et l’efficacité (on parlera d’impact et de valeur plus tard) des développeurs malgré des décennies de recherches et d’essais pratiques.

Dans “The SPACE of Developer Productivity”, papier originel de SPACE,  les auteurs partent d’un constat simple mais souvent oublié : la productivité des développeurs est un concept complexe, multidimensionnel, et profondément contextuel. Chercher à la résumer avec un seul indicateur conduit presque toujours à des effets pervers.

SPACE ne propose donc pas une nouvelle “métrique miracle”, mais un cadre de réflexion pour observer la performance des équipes sous plusieurs angles complémentaires, en assumant les tensions naturelles entre vitesse, qualité, collaboration et bien-être.

C’est dans ce contexte que SPACE a été conçu, avec l’ambition de combiner plusieurs dimensions en tension afin de mieux comprendre ce qui rend les développeurs et les équipes productifs.

TÉLÉCHARGEZ “The SPACE of Developer Productivity” gratuitement !

Objectifs et problèmes adressés par SPACE

L’objectif premier de SPACE est de permettre une évaluation plus équilibrée de la performance des équipes de développement. Plutôt que de se focaliser sur un indicateur unique (qui risque de donner une vision biaisée), SPACE invite à considérer plusieurs axes complémentaires. Ce framework cherche ainsi à résoudre plusieurs problèmes classiques dans l’évaluation de la productivité logicielle :

  • Éviter la myopie des métriques uniques : Un des constats à l’origine de SPACE est qu’aucune métrique isolée ne peut refléter toute la complexité du travail des développeurs. Par exemple, mesurer uniquement l’activité (commits, tâches terminées, etc.) ne dit rien de la qualité du code ni de la satisfaction de l’équipe. De même, se concentrer uniquement sur la performance individuelle peut nuire à la dynamique de groupe. SPACE répond à cela en combinant plusieurs dimensions, évitant de tout réduire à un seul chiffre.
  • Réhabiliter le facteur humain : Bien souvent, les mesures de productivité traditionnelles ignoraient le ressenti des développeurs, leur satisfaction ou les aspects culturels. SPACE intègre explicitement le bien-être et la collaboration dans la mesure de la performance. L’idée est de valoriser ce qui est souvent invisible dans les chiffres bruts (comme le mentorat, le partage de connaissances ou la cohésion de l’équipe) mais qui est crucial pour la réussite sur le long terme. En ce sens, SPACE souligne que les indicateurs ne sont pas réservés aux managers : ils doivent aussi servir aux développeurs eux-mêmes, pour améliorer leurs flux de travail et éviter l’épuisement professionnel.
  • Encourager les bonnes pratiques : En privilégiant une approche multi-indicateurs, SPACE démystifie plusieurs conceptions erronées. Par exemple, il rappelle que plus d’activité n’est pas synonyme de plus de valeur produite, ou que la productivité ne se résume pas à des outils et processus techniques. En mesurant également la satisfaction et la collaboration, on incite les organisations à créer un environnement propice au bien-être, ce qui en retour influence positivement la productivité. L’usage du framework vise donc à équilibrer les priorités : livrer du logiciel efficacement, tout en maintenant des équipes heureuses, en bonne santé et engagées sur la durée.

En somme, le framework SPACE sert à mieux comprendre ce qui fait qu’une équipe de développement est performante. Ses concepteurs le résument comme un moyen de « penser rationnellement la productivité dans un espace beaucoup plus grand », afin de prendre de meilleures décisions pour les projets comme pour les individus.

Les cinq dimensions du framework SPACE

Le nom SPACE est un acronyme formé des cinq dimensions clés que le framework propose d’observer en parallèle :

Satisfaction & bien-être – Correspond à l’épanouissement professionnel des développeurs : à quel point ils se sentent satisfaits de leur travail, de l’équipe, des outils, et comment ils se portent sur le plan du stress et de la santé mentale. C’est la dimension humaine du cadre. L’idée est que des développeurs heureux et en bonne santé seront plus créatifs, plus motivés et donc plus productifs sur la durée. Exemple : on peut évaluer cette dimension via des sondages de satisfaction, des enquêtes de climat d’équipe, ou en surveillant les signes de burnout.

Performance – Il s’agit des résultats obtenus par l’équipe, plutôt que du simple effort fourni. Concrètement, la performance répond à la question : le travail accompli apporte-t-il de la valeur ? Il ne s’agit pas de produire beaucoup de code, mais du code de qualité qui fonctionne et satisfait les utilisateurs. La performance se mesure donc en termes d’impact (satisfaction client, adoption d’une fonctionnalité, valeur métier générée) et de qualité (fiabilité du logiciel, absence de bugs) plutôt qu’en quantité brute. Exemple : on peut suivre des indicateurs tels que le taux de défauts en production, la satisfaction utilisateur, ou des métriques DevOps de qualité (taux de réussite des déploiements, etc.).

Activité – Cette dimension reflète le volume d’actions accomplies par les développeurs pendant leur travail. Cela inclut des données comme le nombre de commits, le nombre de pull requests créées ou revues, le nombre de tâches terminées, etc. L’activité est la mesure la plus instinctive (et historiquement la plus utilisée) de la “productivité” car elle est facile à quantifier. Cependant, SPACE insiste sur le fait que l’activité brute n’est qu’une vue partielle : une activité élevée peut tout aussi bien refléter un travail efficace que du bruteforce dû à des obstacles ou une mauvaise planification. Il faut donc toujours l’interpréter aux côtés des autres dimensions. Exemple : des métriques d’activité typiques sont le nombre de commits par jour, le volume de code produit, le nombre de déploiements effectués sur une période donnée, etc.

Communication & collaboration – Cette dimension couvre la façon dont les individus et les équipes travaillent ensemble. Le développement logiciel est un effort collectif, nécessitant coordination, échanges d’information et feedbacks permanents. Une équipe qui communique bien et où la collaboration est fluide aura moins de doublons, moins d’erreurs de compréhension et intègrera plus rapidement le travail de chacun. À l’inverse, de mauvais canaux de communication peuvent provoquer retards et frustrations. Exemple : on peut regarder la qualité des revues de code (est-ce que les revues sont constructives ?), le taux de participation aux discussions techniques, le temps nécessaire pour onboarder un nouveau membre dans l’équipe, ou même cartographier les réseaux de collaboration (qui travaille avec qui) au sein du projet.

Efficacité & flux – La dernière dimension évalue la capacité de l’équipe à avancer sans friction. Il s’agit de mesurer à quel point le travail progresse avec un minimum d’interruptions, de délais ou de gâchis d’efforts. On parle parfois de flow : cet état de concentration maximale où le développeur est pleinement productif sur une tâche, ou de flux de valeur dans le pipeline de delivery (parcours des tâches depuis l’idée jusqu’en production). Un bon score en efficacité/flux signifie que les processus sont bien huilés, avec peu de goulets d’étranglement, et que les développeurs peuvent régulièrement se mettre en flux sur des tâches complexes. Exemple : des indicateurs concrets incluent le temps de cycle (temps moyen pour qu’une fonctionnalité ou un changement de code aille du développement à la production), le nombre d’interruptions ou de changements de priorité subis en cours de travail, le nombre de passages de relais entre équipes (qui peut ralentir la livraison), etc. Une organisation très efficiente cherchera par exemple à réduire le temps d’attente à chaque étape du processus de développement et déploiement..

Ces cinq dimensions forment ensemble la « constellation » SPACE. L’idée forte est qu’il faut jongler entre elles : améliorer une dimension ne doit pas se faire au détriment total d’une autre. Par exemple, maximiser la vitesse de livraison (efficacité) ne sert à rien si la qualité s’effondre derrière (performance), ou si les développeurs se démoralisent en cours de route (satisfaction). SPACE permet justement de visualiser ces arbitrages et de chercher un équilibre adapté à chaque contexte.

SPACE metrics

Application concrète du framework SPACE

Comment une organisation agile peut-elle utiliser SPACE au quotidien ? La mise en œuvre du framework se fait en plusieurs étapes : définir des métriques pertinentes pour chaque dimension, collecter ces données, puis ajuster les pratiques en conséquence. Voici quelques recommandations et exemples d’indicateurs typiques pour chaque dimension :

  • Choisir plusieurs métriques, sur plusieurs axes : Il est conseillé de combiner au moins trois indicateurs couvrant des dimensions différentes de SPACE pour éviter une vision biaisée. Par exemple, une équipe pourrait suivre en parallèle le moral de l’équipe (Satisfaction), le taux d’échec des déploiements (Performance) et le temps de cycle (Efficacité). L’essentiel est de ne pas se focaliser sur un seul chiffre, mais de croiser les enseignements. En pratique, on observe souvent qu’un indicateur seul peut être trompeur : une hausse du nombre de commits (activité) pourrait sembler positive, mais si parallèlement la satisfaction plonge et que les bugs augmentent, on comprend qu’il y a un problème de fond. SPACE invite donc à suivre un panel équilibré de métriques pour avoir le contexte global.
  • Intégrer les métriques dans la vie de l’équipe : Une fois les indicateurs définis, il est important de les suivre régulièrement et d’en faire un outil de pilotage agile. Par exemple, les résultats SPACE peuvent être discutés lors des rétrospectives de sprint, des réunions d’équipe ou des one-on-one hebdomadaires. L’organisation doit créer un climat de confiance autour de ces mesures : l’objectif n’est pas de fliquer individuellement les développeurs, mais de détecter des axes d’amélioration collectifs. Si un indicateur se dégrade (par ex. une baisse de satisfaction dans l’équipe), cela devient un sujet d’action à part entière pour le Scrum Master, le Product Owner ou le manager, au même titre qu’un impediment technique. En agile, on peut ainsi intégrer les métriques SPACE au processus d’inspection et d’adaptation continue de l’équipe.
  • Utiliser des indicateurs adaptés à son contexte : SPACE ne fournit pas une liste figée de KPI universels – chaque organisation doit choisir les métriques précises qui ont du sens pour elle. Cela peut dépendre de la culture, des outils en place, du type de produit développé, etc. Par exemple, dans une équipe DevOps, on utilisera naturellement les quatre métriques DORA (voir section suivante) comme indicateurs de Performance/Efficacité. Une équipe applicative grand public pourra ajouter un indicateur d’engagement utilisateur (p. ex. taux d’utilisation active d’une fonctionnalité) pour la dimension Performance. L’important est de couvrir les cinq dimensions autant que possible, avec des métriques actionnables (sur lesquelles l’équipe peut agir). Souvent, on conseille de sélectionner 1 à 3 métriques par dimension jugée critique, plutôt que de tout mesurer en vrac.

Exemples d’indicateurs par dimension : Pour illustrer concrètement, voici quelques métriques souvent utilisées dans chaque catégorie SPACE :

  • Satisfaction & bien-être : résultats de sondages de satisfaction interne (score de bonheur de l’équipe), eNPS (Employee Net Promoter Score, recommandation de l’entreprise par les employés), taux d’utilisation des congés (pour s’assurer que l’équipe prend du repos), taux de rétention des développeurs, etc.
  • Performance : qualité du code (densité de bugs, incidents en production, couverture de tests), impact client (feedback utilisateurs, taux de churn ou de rétention client, nombre de tickets support), respect des engagements (fonctionnalités livrées dans les délais, objectifs produit atteints).
  • Activité : fréquence des commits (commits par jour/sprint), nombre de pull requests créées et mergées, vélocité Agile (points terminés par itération), taux de participation aux revues de code, répartition du temps entre dev et tâches transverses, etc.
  • Communication & collaboration : nombre de réunions et temps passé en réunion, taux de participation aux outils collaboratifs (ex : messages sur Slack, commentaires dans les tickets), temps d’intégration du code (combien de temps une pull request reste ouverte avant d’être intégrée – reflet de la coordination), feedback 360° sur la cohésion d’équipe, durée d’onboarding des nouveaux développeurs.
  • Efficacité & flux : temps de cycle complet (du premier commit au déploiement en prod), fréquence de déploiement (combien de releases par jour/semaine), MTTR – Mean Time to Restore (temps de rétablissement du service après un incident), nombre d’interruptions subies (par ex. support, changements de priorités en cours de sprint), nombre de handoffs entre équipes sur une même initiative, etc.

En appliquant ces métriques, une organisation agile peut visualiser ses points forts et faibles sous différents angles. Par exemple, si l’activité est élevée mais que l’efficacité est faible (beaucoup de travail en cours mais des délais longs pour livrer), le framework pointera vers un problème potentiel dans le processus (goulots d’étranglement, blocages techniques…). De même, si la performance technique est bonne mais que la satisfaction des développeurs est en baisse, l’entreprise saura qu’elle doit agir sur la charge de travail ou la culture d’équipe pour éviter le burn-out. L’approche SPACE s’inscrit ainsi parfaitement dans une démarche d’amélioration continue : on mesure régulièrement, on détecte les goulots d’étranglement ou les risques (motivation, fatigue) et on ajuste avant que cela n’affecte lourdement le produit ou l’équipe.

Combinaison avec d’autres frameworks (DORA, OKR…)

Il existe évidemment d’autres frameworks et outils pour évaluer la performance en développement logiciel. Comment SPACE se situe-t-il par rapport à ceux-ci ? Intéressons-nous à deux références populaires et à la manière dont elles peuvent se compléter avec SPACE.

DORA : focus sur la performance DevOps

Le framework DORA (pour DevOps Research & Assessment) dont j’ai beaucoup parlé (Tu peux voir toutes nos vidéos sur Scrum Life) est très répandu dans les équipes qui adoptent DevOps. Il se concentre sur quatre métriques clés liées aux performances de livraison logicielle : le délai de changement (lead time for changes), la fréquence de déploiement, le temps de rétablissement en cas d’incident (MTTR) et le taux d’échec des changements. Ces indicateurs DORA mesurent principalement la vitesse et la stabilité du pipeline de déploiement. Par rapport à SPACE, on voit que DORA ne couvre qu’une partie des dimensions (principalement l’Efficacité/Flux et un aspect de Performance technique). DORA n’intègre pas directement des notions comme la satisfaction des développeurs ou la collaboration d’équipe. Cependant, loin d’être en concurrence, les deux approches sont jugées complémentaires. En pratique, beaucoup d’organisations commencent par suivre les métriques DORA pour améliorer leur pipeline, puis élargissent ensuite le périmètre avec SPACE afin d’avoir une vue plus holistique sur l’efficacité et la santé de leurs équipes. Utilisés conjointement, DORA et SPACE fournissent un véritable balanced scorecard (tableau de bord équilibré) : on s’assure de ne pas optimiser la vitesse de livraison au détriment de la qualité du code ou du bien-être de l’équipe, et vice-versa.

OKR : aligner les métriques sur les objectifs

Un résumé très rapide : Les OKR (Objectives and Key Results) forment un cadre de gestion des objectifs, largement employé pour aligner les efforts d’une équipe sur la stratégie d’entreprise. OKR n’est pas un système de métriques en soi, mais plutôt une manière de fixer des objectifs et de mesurer les résultats clés qui y sont associés. Dans ce sens, OKR et SPACE peuvent aussi se compléter. En effet, on peut très bien définir des OKR liés à l’amélioration de certaines dimensions SPACE. Par exemple, un objectif trimestriel pourrait être « Améliorer la satisfaction de l’équipe », avec comme résultats clés d’atteindre un score de satisfaction interne de X/10 et de réduire le taux de rotation du personnel de Y% (liés à la dimension Satisfaction). De même, un OKR « Améliorer la qualité de livraison » pourrait utiliser des KPI DORA/SPACE comme réduire le taux d’échecs de déploiement en dessous de Z% (Performance) et le délai moyen de livraison à N jours (Efficacité). L’idée est que les OKR donnent le cadre d’objectifs, et des frameworks comme SPACE fournissent les mesures concrètes pour suivre ces objectifs. En combinant les deux, une entreprise agile s’assure que ses objectifs stratégiques incluent des composantes techniques et humaines, et que les améliorations de productivité recherchées sont bien alignées avec la création de valeur et la santé de l’organisation.

En conclusion

En définitive, le framework SPACE apporte aux leaders agiles et aux équipes de développement un outil précieux pour naviguer dans la complexité de la productivité logicielle. En embrassant à la fois la satisfaction des développeurs, la performance produit, l’activité réalisée, la collaboration d’équipe et l’efficacité des processus, SPACE offre une vision équilibrée et multidimensionnelle de la performance. Ce faisant, il aide à repérer plus facilement les points de friction (techniques ou humains), à préserver le moral de l’équipe, et à optimiser en continu les façons de travailler. Plutôt que de piloter « à l’aveugle » ou avec un seul indicateur, les organisations peuvent grâce à SPACE ajuster leurs actions avec finesse – par exemple en allouant du temps pour améliorer l’expérience développeur autant que pour accélérer le pipeline. En complément d’autres cadres comme DORA ou OKR, SPACE contribue à bâtir des équipes plus efficaces, heureuses et résilientes. Et comme on le dit souvent en agile : « On obtient ce que l’on mesure ». En mesurant ce qui compte vraiment sous plusieurs angles, le framework SPACE aide à obtenir ce qu’il y a de meilleur d’une équipe de développement – à la fois en termes de résultats et de bien-être collectif.

Pour aller plus loin : ressources de référence sur le SPACE framework

Le framework SPACE s’appuie sur des travaux de recherche solides, mais il a surtout été largement vulgarisé et enrichi par des praticiens du monde Dev, DevOps et Engineering Management. Voici une sélection de ressources de référence pour approfondir le sujet, selon que tu préfères lire, écouter ou regarder.

📘 Articles de vulgarisation et d’application

 

🎥 Vidéos et podcasts de référence

Leave a reply