DORA, SPACE, DevEx, CORE 4 : quel framework choisir pour une équipe tech plus efficace ?

L’engineering efficiency, c’est un peu le Graal des équipes tech. Comment livrer plus vite sans sacrifier la qualité et sans augmenter la taille des équipes ? Comment éviter que les développeurs se noient sous les process tout en garantissant un produit robuste ? Depuis une dizaine d’années, plusieurs frameworks ont émergé pour tenter de répondre à ces questions, chacun apportant sa vision et ses indicateurs de mesure.

J’avais moi même réfléchi à la manière de mesurer la performance des équipes et construit mon propre framework. Mais quand je vois que des gens y ont beaucoup plus réfléchi que moi, je trouve ça très intéressant à étudier.

L’histoire commence avec DORA, le premier à proposer une approche scientifique pour évaluer et améliorer la performance des équipes de développement. Il met l’accent sur des métriques claires, mais avec le temps, ses limites apparaissent. C’est alors que SPACE entre en scène, ajoutant une dimension plus humaine à l’équation. Puis vient DevEx, qui pousse encore plus loin la réflexion en se concentrant sur l’expérience développeur elle-même. Enfin, CORE 4, le petit dernier, tente d’unifier tout cela en une approche pragmatique et actionnable.

Ces frameworks sont jeunes, mais ils évoluent rapidement. Ce qui était innovant hier devient vite insuffisant aujourd’hui. Ce qui marchait pour une équipe peut se révéler contre-productif pour une autre. Alors, comment choisir la bonne approche ? Quelles métriques privilégier ? Et surtout, comment éviter que la mesure ne devienne un objectif en soi, au détriment de l’efficacité réelle ?

Dans cet article, on va retracer cette évolution, explorer les forces et les limites de chaque framework, et voir comment ils façonnent le quotidien des équipes tech.

DORA : Le premier framework de l’engineering efficiency

Avant que DORA ne voie le jour, la mesure de la performance des équipes de développement était souvent floue, subjective et source de débats sans fin. Certains se focalisaient sur la vélocité, d’autres sur le nombre de lignes de code produites (😱), et d’autres encore sur des ressentis plus que sur des données objectives. En 2018, le DevOps Research and Assessment (DORA) a changé la donne en proposant un cadre clair, basé sur des recherches empiriques, pour mesurer et améliorer l’efficacité des équipes tech. Leur rapport annuel est téléchargeable directement depuis leur page de projet.

Une approche révolutionnaire pour l’époque ✨

DORA ne s’est pas contenté d’imposer de nouvelles métriques, il a surtout introduit une approche scientifique pour évaluer la performance des équipes de développement. Plutôt que de se perdre dans des indicateurs locaux, il a défini quatre métriques clés, centrées sur ce qui compte vraiment : la capacité d’une équipe à livrer de la valeur rapidement et en toute fiabilité. Ces métriques ont rapidement été adoptées par les entreprises cherchant à optimiser leur flux de développement.

Les quatre métriques DORA sont :

Lead Time for Changes (LTC) ⏳ : le temps nécessaire pour qu’un changement de code passe du commit en production.
Deployment Frequency (DF) 🚀 : la fréquence des mises en production.
Change Failure Rate (CFR) 🔥 : le pourcentage de déploiements entraînant une défaillance en production.
Mean Time to Recovery (MTTR) 🛠️ : le temps moyen nécessaire pour restaurer un service après une panne.

Ces métriques ont apporté une vision holistique de la performance d’une équipe, en équilibrant vitesse et fiabilité. Elles ont permis de dépasser les débats stériles autour de la productivité individuelle pour se concentrer sur l’efficacité collective.

Les limites du modèle DORA

Malgré son adoption massive, DORA a aussi ses points faibles. Le principal reproche ? Son focus quasi-exclusif sur la livraison. En se concentrant sur le pipeline de développement et de déploiement, il laisse de côté d’autres aspects cruciaux du travail des développeurs.

Une vision trop orientée « ops » : DORA mesure l’efficacité d’un pipeline, mais il ne dit rien sur l’expérience des développeurs ni sur la qualité du code produit. Une équipe peut avoir des métriques DORA excellentes tout en souffrant d’une dette technique énorme ou d’un environnement de travail toxique.
Un manque de granularité : les métriques sont utiles pour suivre une tendance globale, mais elles ne disent rien sur les causes profondes des problèmes. Par exemple, une augmentation du « Change Failure Rate » peut être due à un manque de tests, une pression excessive sur les devs, ou un mauvais découpage des fonctionnalités.
Une adaptation parfois difficile : certaines équipes, en particulier dans des contextes où les cycles de release sont naturellement longs (comme l’embarqué ou certaines fintechs), ont du mal à appliquer ces métriques sans forcer artificiellement leur processus.

Un socle fondateur, mais pas suffisant

DORA a été une avancée majeure et reste aujourd’hui un point de référence incontournable. Il a permis aux entreprises de passer d’un modèle intuitif à une approche data-driven pour mesurer l’efficacité des équipes tech. Mais à mesure que le secteur évoluait, de nouvelles questions se sont posées : comment mesurer la satisfaction et l’expérience des développeurs ? Comment prendre en compte des éléments plus qualitatifs, comme la collaboration ou la charge cognitive ?

C’est là que de nouveaux frameworks sont apparus, cherchant à compléter ou dépasser DORA en intégrant une vision plus large de l’engineering efficiency. SPACE, le successeur direct, a été le premier à proposer une alternative plus complète, en intégrant des dimensions humaines et organisationnelles. Voyons comment il a changé la donne.

SPACE : Un nouveau regard sur la productivité des développeurs 🚀

DORA a marqué un tournant dans la façon dont les équipes tech mesurent leur efficacité, mais il s’est vite heurté à une limite majeure : il se concentre uniquement sur la performance des pipelines de développement et de déploiement. Or, être efficace ne se résume pas à livrer du code rapidement. Il faut aussi prendre en compte la collaboration, la satisfaction des développeurs et la qualité du travail produit. C’est pour répondre à ces enjeux que Nicole Forsgren, Margaret-Anne Storey et d’autres chercheurs ont introduit le modèle SPACE en 2021.

Un modèle pensé pour la complexité du travail des devs

SPACE repose sur une idée simple mais puissante : la productivité des développeurs ne peut pas être mesurée avec une seule métrique. Au contraire, elle est multidimensionnelle et repose sur plusieurs facteurs interdépendants. Plutôt que de se limiter aux métriques de livraison comme DORA, SPACE élargit la perspective en intégrant des éléments plus humains et organisationnels.

Les cinq dimensions du modèle SPACE sont :

Satisfaction et bien-être 😊 : à quel point les développeurs sont-ils satisfaits de leur travail et dans quel état mental se trouvent-ils ? Un développeur frustré ou en burnout sera moins productif, même si les livraisons restent fréquentes.
Performance ⚡ : ici, on ne parle pas seulement de vitesse, mais aussi de la qualité du travail produit. Un code rapide à livrer mais plein de bugs est-il vraiment un signe de productivité ?
Activité 📊 : combien de commits, de pull requests, de revues de code ou de tickets traités ? Attention, cette métrique seule est trompeuse, car beaucoup d’activités ne sont pas directement visibles (résolution de problèmes, mentoring, documentation…).
Collaboration et communication 🤝 : comment les équipes interagissent-elles ? Une équipe qui fonctionne bien ensemble est plus efficace qu’une somme d’individus hyper-productifs mais isolés.
Efficacité et flux 🔄 : les développeurs peuvent-ils avancer sans interruption ? Une équipe submergée de réunions ou empêtrée dans des process lourds mettra du temps à livrer, même si elle est compétente.

Une évolution majeure par rapport à DORA

SPACE marque une vraie rupture avec DORA en ajoutant une dimension qualitative à l’engineering efficiency. DORA te dit si ton équipe déploie vite et bien. SPACE cherche à comprendre pourquoi une équipe est efficace ou non.

Le premier changement fondamental est l’intégration du facteur humain. Là où DORA mesure des performances globales, SPACE prend en compte le bien-être et la satisfaction des développeurs. Car un développeur heureux, qui évolue dans un environnement sain, aura plus d’impact sur le long terme qu’un développeur sous pression qui enchaîne les livraisons sans prendre le temps de souffler.

Ensuite, SPACE abandonne l’idée qu’il existe une seule métrique clé pour juger de la productivité. Il propose au contraire un équilibre entre plusieurs dimensions, ce qui permet une analyse plus fine et plus adaptée aux réalités des équipes.

Enfin, SPACE met un accent particulier sur la collaboration et l’efficacité des flux de travail. Dans de nombreuses entreprises, le vrai frein à la productivité n’est pas la vitesse des développeurs, mais les interruptions constantes, la dette organisationnelle et les outils inadaptés. Avec SPACE, on peut identifier ces problèmes et agir sur eux.

Les défis de l’approche SPACE

Même si SPACE apporte une vision plus complète, son application n’est pas toujours évidente. Contrairement à DORA, qui repose sur quatre métriques faciles à suivre, SPACE nécessite une approche plus nuancée et contextuelle. Il faut trouver les bons indicateurs pour chaque dimension, ce qui demande du temps et une bonne compréhension des besoins de l’équipe.

Autre point, certaines métriques SPACE sont plus difficiles à mesurer objectivement. La satisfaction ou la collaboration, par exemple, nécessitent souvent des enquêtes internes ou des entretiens qualitatifs, ce qui peut ralentir l’adoption du framework.

Enfin, comme tout modèle, SPACE ne fait pas tout. Il n’élimine pas la nécessité de suivre les métriques DORA ou d’autres indicateurs plus spécifiques à chaque équipe. Il sert plutôt de complément pour enrichir l’analyse et mieux comprendre les leviers de performance.

Une nouvelle vision de l’engineering efficiency

SPACE a ouvert la voie à une approche plus globale et plus humaine de la productivité des développeurs. Il a permis de dépasser la simple mesure de la vitesse de livraison pour inclure des dimensions humaines, collaboratives et organisationnelles. Cette vision a inspiré d’autres frameworks, comme DevEx, qui pousse encore plus loin l’analyse en se concentrant spécifiquement sur l’expérience développeur. Voyons comment il s’inscrit dans cette évolution.

DevEx : Placer l’expérience développeur au cœur de l’efficacité ❤️

Après avoir exploré les frameworks DORA et SPACE, une question persiste : comment améliorer concrètement la productivité des développeurs en tenant compte de leur expérience quotidienne ? C’est ici qu’intervient le DevEx, ou Developer Experience, un concept qui met l’accent sur le vécu des développeurs et les frictions qu’ils rencontrent dans leur travail quotidien.

Genèse du DevEx

Le DevEx n’est pas simplement une nouvelle mode ; il découle d’une prise de conscience croissante que la satisfaction et le bien-être des développeurs ont un impact direct sur la qualité et la rapidité des livraisons. Une étude de McKinsey de 2020 a révélé que les entreprises offrant un meilleur environnement de travail à leurs développeurs ont enregistré une croissance des revenus supérieure à celle de leurs concurrents.

Cette approche a été formalisée dans un cadre proposé par Abi Noda, Margaret-Anne Storey, Nicole Forsgren et Michaela Greiler, visant à mesurer et améliorer l’expérience développeur en se concentrant sur trois dimensions clés.

Les trois dimensions du DevEx

Boucles de rétroaction (Feedback loops) : Il s’agit de la rapidité et de la qualité des retours que les développeurs reçoivent suite à leurs actions. Des boucles de rétroaction rapides permettent aux développeurs de progresser efficacement, tandis que des retours lents peuvent entraîner des frustrations et des retards. Par exemple, des temps de compilation longs ou des processus de revue de code inefficaces peuvent nuire à la productivité.
Charge cognitive (Cognitive load) : Cette dimension concerne la quantité d’effort mental nécessaire pour accomplir une tâche. Une charge cognitive élevée peut résulter de code mal documenté, de systèmes complexes ou d’objectifs flous, obligeant les développeurs à consacrer plus de temps et d’énergie pour éviter les erreurs. Réduire cette charge passe par une simplification des processus et une amélioration de la clarté des tâches.
État de flux (Flow state) Cet état mental se caractérise par une immersion totale et une concentration intense dans une activité. Favoriser cet état conduit à une productivité accrue, une meilleure innovation et une satisfaction professionnelle élevée. Les interruptions fréquentes, les réunions non planifiées ou un environnement de travail bruyant peuvent empêcher les développeurs d’atteindre cet état optimal.

Évolution par rapport aux autres frameworks

Le DevEx se distingue des frameworks précédents en plaçant l’expérience humaine au centre de la mesure de l’efficacité. Contrairement à DORA, qui se concentre sur des métriques de performance spécifiques, ou à SPACE, qui élargit la perspective en intégrant des dimensions humaines et organisationnelles, le DevEx propose une approche encore plus centrée sur le développeur.

Cette focalisation sur l’expérience individuelle permet d’identifier des points de friction spécifiques qui peuvent ne pas apparaître dans des métriques plus globales. Par exemple, une équipe peut avoir des indicateurs DORA excellents tout en ayant des développeurs insatisfaits en raison de processus internes lourds ou d’un manque de reconnaissance.

En intégrant des mesures perceptuelles (telles que des enquêtes de satisfaction) et des mesures de workflow (comme les temps de build ou les délais de revue de code), le DevEx offre une vision holistique de l’environnement de travail des développeurs. Cette combinaison permet aux organisations d’identifier non seulement ce qui ne fonctionne pas, mais aussi pourquoi cela ne fonctionne pas, ouvrant ainsi la voie à des améliorations ciblées.

CORE 4 : Unifier les frameworks pour une efficacité optimale 🚀

Après avoir exploré les frameworks DORA, SPACE et DevEx, une question demeure : comment intégrer ces différentes approches pour obtenir une vision cohérente et complète de l’efficacité des équipes de développement ? C’est précisément pour répondre à cette interrogation que le DX Core 4 a été conçu, offrant une synthèse des meilleures pratiques en matière de mesure de la productivité des développeurs.

Genèse du DX Core 4

Le DX Core 4 est né de la collaboration entre des experts reconnus, notamment Laura Tacho et Abi Noda, en partenariat avec les auteurs des frameworks DORA, SPACE et DevEx, tels que le Dr. Nicole Forsgren et le Dr. Margaret-Anne Storey. Face à la multiplicité des frameworks existants et aux défis que cela posait aux leaders technologiques, l’objectif était de créer un cadre unifié, pratique et équilibré pour mesurer la productivité des développeurs

Les quatre dimensions du DX Core 4

Le DX Core 4 repose sur quatre dimensions clés, chacune accompagnée de métriques spécifiques :

Vitesse (Speed) 🚀 : Cette dimension évalue la rapidité avec laquelle les équipes livrent des fonctionnalités ou des correctifs. Elle inclut des métriques telles que le temps de cycle et la fréquence des déploiements.
Efficacité (Effectiveness) 🎯 : Elle mesure la capacité des équipes à atteindre les objectifs fixés et à produire des résultats attendus. Les indicateurs peuvent inclure le pourcentage de tâches accomplies par rapport aux prévisions et la satisfaction des parties prenantes.
Qualité (Quality) 🛠️ : Cette dimension se concentre sur la stabilité et la fiabilité du code produit. Les métriques associées comprennent le taux de défaillance des changements et le nombre de bugs en production.
Impact (Impact) 📈 : Elle évalue l’effet des livraisons sur les objectifs commerciaux, tels que l’augmentation des revenus ou l’engagement des utilisateurs. Les indicateurs peuvent inclure la contribution aux objectifs stratégiques et le retour sur investissement des projets.

En combinant ces quatre dimensions, le DX Core 4 offre une vue d’ensemble équilibrée de la performance des équipes de développement, en tenant compte à la fois de la rapidité, de l’efficacité, de la qualité et de l’impact commercial.

Évolution par rapport aux autres framewoks

Le DX Core 4 se distingue des frameworks précédents par sa capacité à intégrer les points forts de chacun :

DORA : En incorporant des métriques de performance système, le DX Core 4 conserve l’accent mis sur la livraison rapide et fiable.
SPACE : Le DX Core 4 adopte une approche multidimensionnelle similaire, mais fournit des métriques plus spécifiques et actionnables, facilitant ainsi leur mise en œuvre.
DevEx : En intégrant des mesures de l’expérience développeur, le DX Core 4 reconnaît l’importance du bien-être des équipes pour assurer une productivité durable.

Ainsi, le DX Core 4 offre une approche holistique qui englobe les aspects techniques, humains et commerciaux de la productivité des développeurs.

Mise en œuvre du DX Core 4 chez Alan

Pour illustrer l’application concrète du DX Core 4, je te propose d’écouter l’épisode de podcast que j’ai enregistré avec Julien Femia. Nous y discutons de la mise en place de ce framework chez Alan et des bénéfices observés.

Conclusion

Le DX Core 4 représente une avancée significative dans la mesure de l’efficacité des équipes de développement. En unifiant les approches précédentes, il fournit un cadre complet et équilibré qui aide les organisations à aligner leurs objectifs techniques et commerciaux tout en tenant compte du bien-être des développeurs. Son adoption peut conduire à des améliorations notables en termes de performance, de qualité et d’impact, comme en témoignent les résultats obtenus par des entreprises telles qu’Alan.

Une évolution constante

L’engineering efficiency est un sujet en perpétuelle évolution. Ce qui a commencé avec DORA et ses métriques de performance des pipelines de livraison a progressivement intégré des dimensions plus larges avec SPACE, puis s’est encore affiné avec DevEx et CORE 4. Chaque framework a apporté un regard nouveau sur la manière de mesurer et d’améliorer la productivité des développeurs, tout en révélant les limites des approches précédentes.

DORA a marqué un tournant en proposant une méthode claire pour mesurer l’efficacité des équipes tech. Mais en se concentrant uniquement sur la vitesse et la fiabilité des livraisons, il laissait de côté des aspects cruciaux comme le bien-être des développeurs et la qualité du travail produit. SPACE est alors venu enrichir cette vision en intégrant des facteurs humains et organisationnels.

DevEx a poussé encore plus loin cette approche en mettant l’expérience développeur au centre des préoccupations. Il a souligné que la productivité ne dépend pas seulement des process et des outils, mais aussi des conditions de travail et des obstacles invisibles qui ralentissent les équipes au quotidien.

Enfin, CORE 4 cherche à synthétiser ces différentes approches pour offrir un cadre pragmatique et équilibré. Il tente de rassembler le meilleur de chaque framework pour proposer une vision cohérente de la productivité, en tenant compte aussi bien de la vitesse, la satisfaction, la qualité du code que de la collaboration.

Ce parcours montre bien une tendance forte : plus on avance, plus on comprend que l’engineering efficiency ne peut pas être réduite à une seule métrique ou un seul axe d’amélioration. Il ne suffit pas de livrer rapidement, il faut aussi que les développeurs puissent travailler dans de bonnes conditions, avec les bons outils et les bons process.

Et toi, où en es-tu sur ces sujets ? As-tu déjà testé certains de ces frameworks ? Quels ont été tes apprentissages ? Dis-moi ce que tu as fait de tout ça, j’aimerais beaucoup avoir ton retour.