Le playbook de GitHub pour réussir les systèmes d’ingénierie

• Pour réussir en ingénierie, il est essentiel d’équilibrer trois domaines : la qualité (Quality), la vitesse (Velocity) et la satisfaction des développeurs (Happiness)
• L’ESSP (Engineering System Success Playbook) fournit un framework en 3 étapes pour améliorer ces aspects de manière intégrée afin de maximiser les résultats business
• À travers 12 indicateurs clés conçus à partir de plusieurs frameworks comme SPACE, DevEx, DX Core 4 et DORA, il permet de comprendre la situation de l’organisation, de définir les priorités selon les objectifs d’amélioration, puis de mettre en œuvre et ajuster progressivement les changements
  • Ces 12 indicateurs sont structurés pour suivre quantitativement chaque domaine et peuvent être personnalisés selon le contexte de chaque organisation
• Toutes les améliorations reposent sur la durabilité à l’échelle de l’équipe et une pensée systémique, en mettant l’accent sur une approche équilibrée qui prend en compte à la fois les indicateurs avancés et retardés
• L’objectif est de viser un changement durable à long terme plutôt qu’une amélioration rapide
• Il est possible de commencer avec l’ESSP même sans outil de mesure dédié, et un diagnostic initial via des méthodes qualitatives comme des enquêtes peut aussi être utile
• GitHub souligne, à travers ses propres cas d’usage, que les améliorations centrées sur la qualité finissent par avoir un effet positif sur la vitesse et la satisfaction des développeurs

Les métriques de réussite de l’ingénierie chez GitHub

• Quality
  • Change failure rate : taux d’échec des changements
    → Proportion des changements ayant provoqué une panne ou un problème
    • Calcul : (nombre de déploiements en échec / nombre total de déploiements) × 100
    • Conseil : définir clairement au sein de l’équipe ce qui est considéré comme un échec (par ex. rollback, alerte de supervision, etc.)
  • Failed deployment recovery time : temps de récupération après un échec de déploiement
    → Temps nécessaire pour annuler un déploiement en échec ou rétablir un état normal
    • Calcul : médiane de l’heure de fin de récupération − l’heure de survenue de l’échec pour chaque déploiement en échec
    • Conseil : il est recommandé d’extraire automatiquement cette donnée à partir du système d’alertes ou des logs. Préférer la médiane à la moyenne pour limiter l’effet des valeurs extrêmes
  • Code security and maintainability : sécurité et maintenabilité du code
    • Calcul : évaluation globale du nombre de vulnérabilités, de la complexité, de la couverture et d’autres éléments via des outils d’analyse statique, GitHub Advanced Security, CodeQL, etc.
    • Conseil : configurer des scans automatiques réguliers. Utile pour mesurer l’effet de refactorings ou de changements de politique de sécurité
• Velocity
  • Lead time : lead time
    → Temps entre un changement de code et sa mise en production
    • Calcul : temps écoulé entre la création d’une PR et son déploiement après merge
    • Conseil : utiliser la médiane plutôt que la moyenne pour réduire les biais. Si le lead time est long, mesurer séparément le temps d’attente des PR ou les retards de review
  • Deployment frequency : fréquence de déploiement
    → Fréquence des déploiements en production
    • Calcul : nombre de déploiements sur une période donnée (par jour ou par semaine)
    • Conseil : préciser clairement si les déploiements automatisés sont inclus ; pour les petites équipes, une mesure hebdomadaire peut être plus pertinente
  • PRs merged per developer : nombre de PR fusionnées par développeur
    • Calcul : nombre total de PR fusionnées / nombre de développeurs contributeurs
    • Conseil : à utiliser non pas comme outil de comparaison, mais comme mesure de l’efficacité du workflow de l’équipe. À interpréter avec la taille ou la complexité des PR
• Developer Happiness
  • Flow state experience : expérience d’état de flow
    • Calcul : évaluation via enquête développeur de la « fréquence/durée récente des expériences de concentration profonde »
    • Conseil : une enquête régulière au moins une fois par mois est recommandée. Inclure des réponses libres peut apporter des insights qualitatifs
  • Engineering tooling satisfaction : satisfaction vis-à-vis des outils d’ingénierie
    • Calcul : collecte, via enquête développeur, du niveau de satisfaction à l’usage des outils et des souhaits d’amélioration
    • Conseil : détailler par catégorie d’outil (IDE, CI, suivi des tickets, etc.) permet d’identifier des axes d’amélioration concrets
  • Copilot satisfaction : satisfaction d’utilisation de Copilot
    • Calcul : enquête de satisfaction auprès des détenteurs d’une licence Copilot (NPS ou score)
    • Conseil : il est recommandé de comparer plusieurs moments, par exemple juste après le déploiement puis trois mois plus tard. Les retours peuvent aussi servir à améliorer la formation et les cas d’usage
• Business Outcomes
  • AI leverage : niveau d’exploitation de l’IA
    • Calcul : part des commits avec Copilot, taux d’adoption des suggestions de code IA, temps d’utilisation, etc.
    • Conseil : il est possible d’utiliser la Copilot Telemetry API de GitHub ou une instrumentation interne. L’analyse est plus pertinente lorsqu’elle est combinée à des retours qualitatifs
  • Engineering expenses to revenue : ratio des dépenses d’ingénierie sur le chiffre d’affaires
    • Calcul : dépenses liées à l’ingénierie / chiffre d’affaires total
    • Conseil : un cadre comptable interne clair est nécessaire. Une analyse mensuelle ou trimestrielle des tendances est recommandée pour les comparaisons
  • Feature engineering expenses to total engineering expenses : part des dépenses de développement de fonctionnalités dans les dépenses totales d’ingénierie
    • Calcul : (dépenses liées au développement de fonctionnalités / dépenses totales d’ingénierie)
    • Conseil : pour une mesure précise, il faut clarifier à l’avance les critères de classification des coûts hors fonctionnalités, comme la maintenance, l’infrastructure ou les tests

[3 étapes pour réussir en ingénierie]

Step 1: Identify the current barriers to success

• Il est essentiel d’identifier les problèmes du processus de développement actuel et les obstacles qui entravent la réussite de l’ingénierie
• Cela sert de baseline pour définir les axes d’amélioration et les priorités à venir
• Approche
  • Analyser l’ensemble du flux du SDLC (Software Development Life Cycle) afin d’identifier les points de blocage
  • Chez GitHub, l’analyse s’appuie sur 12 métriques standard, mais il est possible de n’en utiliser qu’une partie selon les spécificités de l’organisation
• Participation de l’équipe
  • Le processus d’amélioration ne doit pas être défini par un seul responsable, mais par l’ensemble des membres de l’équipe
  • Commencer une discussion utile avec seulement quelques métriques suffit déjà
• Méthodologie

  • 1. Comprendre le flux de base

    • Le flux global de l’ingénierie est découpé comme suit :
      • Plan → Develop → Review → Build → Test → Release → Operate

  • 2. Recueillir des signaux quantitatifs

    • Analyser des données quantitatives comme :
      • Fréquence de déploiement : à quelle fréquence les déploiements ont lieu
      • Lead time : le temps écoulé entre l’écriture du code et son déploiement
      • Taux d’échec des changements : la proportion d’erreurs après déploiement
      • MTTR (temps moyen de rétablissement) : le temps nécessaire pour rétablir le service après un incident

  • 3. Recueillir des signaux qualitatifs

    • Recueillir des retours d’expérience des développeurs et des équipes :
      • À quel moment les membres de l’équipe ressentent-ils de l’inefficacité ?
      • Quels outils ou procédures provoquent des problèmes de manière répétée ?
      • Quelles activités représentent la plus forte charge mentale ?
    • Méthodes :
      • Utiliser des enquêtes, rétrospectives et entretiens individuels
      • Il est également possible d’utiliser une liste prédéfinie de questions ESSP

  • 4. Définir les problèmes clés

    • Définir les barrières (Barrier) à partir des données recueillies
    • Exemples :
      • "Le lead time est long, ce qui retarde le développement de nouvelles fonctionnalités"
      • "Les échecs de build sont fréquents, ce qui réduit la fiabilité des déploiements"
      • "Les développeurs subissent souvent un changement de contexte (context switching)"
    • Les problèmes doivent être formulés de manière concrète et observable

  • 5. Définir les priorités des métriques

    • Plutôt que d’essayer d’améliorer toutes les métriques en même temps, se concentrer sur une ou deux métriques ayant le plus grand impact
    • Cette priorisation servira ensuite, dans les Step 2 et Step 3, de référence pour les tentatives d’amélioration et la mesure des résultats
• Conseils pour réussir le Step 1
  • 1. Se concentrer sur la cause racine plutôt que sur les apparences
    • Il ne faut pas se limiter aux symptômes de surface, mais creuser en profondeur jusqu’à la racine du problème
      • Exemple : la lenteur peut sembler venir des « tests manuels », alors que la cause réelle peut être un manque de confiance dans les tests automatisés
    • Pour cela, il est utile de se référer aux antipatterns fréquemment observés en software engineering
  • 2. S’appuyer sur les antipatterns
    • Un antipattern désigne une solution souvent utilisée qui ne résout pas réellement le problème et peut même entraîner des effets secondaires
    • GitHub fournit des ressources distinctes présentant des exemples d’antipatterns pouvant exister dans une équipe, qui peuvent donc être utilisées comme outil d’auto-évaluation
  • 3. Faire participer les bonnes personnes
    • Dans la Task 1 du Step 1, il est important de recueillir les contributions de personnes occupant des rôles variés
      • Par exemple : développeurs, testeurs, opérations, sécurité, product managers, etc.
    • Cela permet de comprendre le workflow dans son ensemble sous plusieurs angles et d’éviter d’ignorer certains points de vue
  • 4. Utiliser de manière équilibrée les données quantitatives et qualitatives
    • Les métriques seules ne permettent pas de comprendre tout le contexte
    • En plus de l’analyse quantitative, il faut aussi recueillir des retours qualitatifs sur les enjeux psychologiques, culturels et de collaboration au sein de l’équipe
    • Exemple : une baisse du moral de l’équipe, un manque de communication ou des frustrations exprimées en rétrospective n’apparaissent pas dans les chiffres
  • 5. Ne pas retenir trop de barrières
    • Ne cherchez pas à résoudre tous les problèmes d’un coup ; concentrez-vous sur les barrières les plus urgentes et les plus impactantes
    • Définir trop de chantiers d’amélioration dès le départ risque de faire perdre la capacité d’exécution et l’élan
  • 6. Garantir la sécurité psychologique
    • Il faut créer un environnement dans lequel les membres de l’équipe peuvent s’exprimer honnêtement sans craindre de préjudice ni de représailles
    • C’est une condition essentielle pour faire émerger les vrais problèmes, et cela renforce la fiabilité ainsi que l’efficacité des actions d’amélioration
  • 7. La comparaison sert à apprendre, pas à évaluer
    • Les comparaisons de métriques entre équipes ou les différences de workflow doivent être utilisées pour produire des insights, et non pour évaluer quantitativement les performances
    • Chaque équipe a un contexte, des objectifs, une stack technique et des contraintes différents ; les comparaisons simplistes peuvent donc prêter à confusion
    • À la place, il faut encourager une culture d’apprentissage où l’on partage ce qui fonctionne et les enseignements tirés

Étape 2 : Évaluez ce qui doit être fait pour atteindre votre objectif cible

• Objectif
  • Étape consistant à analyser quels changements doivent être mis en œuvre pour résoudre le problème central (Barrier) défini à l’étape 1
  • Au-delà de la simple introduction de fonctionnalités ou du changement d’outils, il s’agit d’identifier les causes profondes et les solutions aux niveaux organisationnel, technique et culturel

• 1. Analyser les causes profondes de l’état actuel

  • Il faut aller au-delà des simples résultats comme « c’est lent » ou « la satisfaction est faible », et déterminer :
    • pourquoi c’est lent,
    • quelles en sont les raisons structurelles et organisationnelles,
    • et distinguer ce qui peut être changé de ce qui ne peut pas l’être
  • Outils disponibles :
    • la méthode des 5 pourquoi
    • le diagramme d’Ishikawa (cause-effet)
    • l’analyse des retours qualitatifs lors des rétrospectives d’équipe

• 2. Faire émerger des solutions possibles

  • Brainstormer des solutions techniques, culturelles et liées aux processus au problème
  • Exemples :
    • Technique : accélérer les tests, améliorer le pipeline CI/CD
    • Culturel : revoir les pratiques de code review, améliorer l’onboarding
    • Processus : limiter la taille des PR, modifier les critères de merge
  • Méthode recommandée par GitHub :
    • combiner des solutions fondées sur l’observation et des améliorations centrées sur les personnes

• 3. Évaluer les effets et les risques

  • Pour chaque solution, évaluer les éléments suivants :
    • effet attendu : quels indicateurs d’amélioration peuvent être influencés
    • faisabilité : ressources de l’équipe et capacité d’exécution réaliste
    • acceptabilité organisationnelle : niveau de résistance au changement
    • distinction court terme / long terme : obtient-on des résultats rapides ou un changement durable
  • Pour cela, un pilotage pilote (Pilot) est recommandé
    • tester à petite échelle dans une équipe, recueillir du feedback, puis décider d’un éventuel déploiement plus large

• 4. Définir les priorités et communiquer

  • Parmi les différentes solutions, prioriser selon les critères suivants :
    • celles qui peuvent produire le plus grand impact
    • celles qui sont les plus réalisables
    • celles qui répondent au point de douleur le plus urgent
  • Cette décision doit être partagée avec l’équipe et faire l’objet d’un consensus,
    • et il est préférable de la formuler clairement sous forme d’OKR ou d’objectifs d’amélioration
• Conseils pour réussir l’étape 2
  • 1. Toujours prendre en compte la durabilité à long terme
    • Se concentrer uniquement sur les résultats à court terme peut au contraire créer des problèmes à long terme
      • Exemple : l’introduction d’un nouvel outil peut améliorer immédiatement la vitesse, mais sans formation, support et gestion du changement, cela peut au contraire provoquer erreurs et confusion
    • Toute tentative d’amélioration doit donc s’inscrire dans une stratégie qui prend aussi en compte la maintenabilité et la capacité de diffusion
  • 2. Prendre en compte les arbitrages entre les différentes zones
    • Veillez à ce qu’un changement qui améliore une zone (par ex. la vitesse) ne sacrifie pas une autre zone (par ex. la satisfaction des développeurs ou la qualité)
      • Exemple : assouplir les critères de review peut accélérer le rythme, mais dégrader la qualité du code ou augmenter la fatigue des développeurs
    • Il faut toujours garder à l’esprit que l’impact s’étend à plusieurs zones et adopter une approche équilibrée
  • 3. Impliquer l’équipe dès le départ
    • Plus un changement est directement porté et construit par l’équipe, plus ses chances de succès sont élevées
    • Recueillir l’avis des membres afin que le changement puisse se faire de manière bottom-up
    • Un changement imposé de manière unilatérale et top-down peut entraîner résistance et désengagement
  • 4. Définir clairement les indicateurs de réussite
    • Avant de mettre en œuvre un changement, il faut se mettre d’accord sur ce qui constitue un succès
    • Exemple : si l’objectif est de « réduire le temps de déploiement »,
      • indicateur retardé : diminution réelle du temps de déploiement
      • indicateur avancé : réduction du temps d’attente des PR, hausse des réponses « je constate une amélioration de la vitesse des PR » dans les enquêtes développeurs
    • L’idéal est de définir à la fois des Leading Indicators et des Lagging Indicators
  • 5. Privilégier les expérimentations rapides plutôt qu’un plan parfait
    • Une approche itérative consistant à essayer rapidement, même de petits changements, puis à améliorer à partir du feedback est efficace
      • Au départ, même une tentative imparfaite peut être testée à petite échelle, puis étendue si son efficacité est démontrée
    • C’est utile pour réduire le risque d’échec et renforcer l’agilité et la capacité d’adaptation de l’équipe face au changement
  • 6. Commencer par les changements qui produisent de grands effets avec peu d’efforts
    • Quand les changements à mener sont nombreux et complexes, commencer par les améliorations à “fort impact et faible coût”
    • Exemple : introduire un guide de review simple ou supprimer des notifications inutiles peut être appliqué rapidement tout en ayant un fort effet sur la satisfaction
    • Les premières réussites donnent confiance à l’équipe et fournissent l’élan nécessaire pour s’attaquer à des problèmes plus difficiles

Étape 3 : Mettez en œuvre vos changements, suivez les résultats et ajustez

• Exécuter dans l’organisation les tentatives d’amélioration (Intervention) définies à l’étape 2,
  puis mesurer leurs résultats et, si nécessaire, les ajuster ou les améliorer de manière itérative afin de viser un succès continu de l’ingénierie

• 1. Mise en œuvre (Implement the change)

  • Avant la mise en œuvre, il faut clarifier les points suivants :
    • Quel changement va être apporté ?
    • Qui en sera responsable ?
    • Sur quels indicateurs l’évaluation reposera-t-elle ?
    • À partir de quand et jusqu’à quand les mesures seront-elles effectuées ?
  • Points à prendre en compte lors de l’exécution :
    • Désignation d’un responsable : clarifier l’ownership
    • Onboarding et formation des équipes : tous les membres doivent comprendre pourquoi le changement est nécessaire et ce qui va changer
    • Documentation du changement : conserver une trace pour pouvoir s’y référer lors des rétrospectives et des itérations futures
  • Exemples d’adoption :
    • modification de la stratégie de cache de build pour améliorer la vitesse du CI/CD
    • modification de la politique de code review (par ex. introduction d’une règle de réponse sous 24 heures)

• 2. Suivi (Monitor the change)

  • Après la mise en œuvre du plan d’amélioration, suivre les effets à l’aide des indicateurs définis à l’avance
    • réduction ou non du lead time
    • baisse ou non du taux d’échec
    • amélioration ou non de la satisfaction des développeurs, etc.
  • Outils :
    • GitHub Insights, Copilot Telemetry, systèmes BI internes
    • tableaux de bord de rapports hebdomadaires/mensuels
    • enquêtes auprès des développeurs ou retours de rétrospective
  • Point important :
    • il faut pouvoir comparer avec la baseline
    • il est important de regarder la tendance, et non une valeur unique

• 3. Collecte de feedback (Collect feedback)

  • Au-delà des indicateurs quantitatifs, il est nécessaire de recueillir des retours pour savoir si, du point de vue des développeurs, le changement a réellement été utile
    • utiliser des rétrospectives, des enquêtes anonymes, des réunions en 1:1, etc.
    • vérifier si l’amélioration est réellement perceptible ou si, au contraire, le changement génère de la fatigue
  • Un changement mis en œuvre trop vite, sans consensus organisationnel, peut provoquer résistance et rejet

• 4. Ajuster ou itérer (Adjust as needed)

  • Si les résultats de la tentative d’amélioration ne sont pas à la hauteur des attentes ou s’ils entraînent des effets secondaires, il faut réagir ainsi :
    • revenir en arrière sur le changement ou le compléter
    • ne conserver que certains éléments et réduire le périmètre
    • étendre l’application à une échelle plus large
  • Que le changement soit un succès ou un échec, il faut toujours en tirer des enseignements :
    • quels éléments ont été efficaces ?
    • quels points ont constitué des freins ?
    • que faudrait-il changer la prochaine fois ?
• Conseils pour réussir l’étape 3
  • 1.Ne pas attendre une perfection immédiate
    • tous les changements ne produisent pas immédiatement une amélioration visible
      • les effets peuvent mettre du temps à apparaître
      • l’équipe a aussi besoin d’une phase d’adaptation au changement ; la patience et l’observation continue sont donc essentielles
    • au début, il est utile d’utiliser des outils de feedback qualitatif comme les enquêtes pour mesurer la perception du changement
  • 2.Continuer à itérer et à améliorer le changement
    • même après un premier succès, il ne faut pas le laisser tel quel ; le changement doit lui aussi évoluer et être ajusté en permanence
    • selon de nouveaux problèmes ou des évolutions de l’environnement externe, il peut être nécessaire de réexaminer les plans d’amélioration existants
    • il faut encourager l’équipe à considérer cela comme une activité régulière et à maintenir le cycle d’amélioration
  • 3.Faire attention aux effets secondaires involontaires
    • certains changements peuvent provoquer des frictions inattendues dans d’autres domaines
      • par ex. améliorer la vitesse de déploiement est positif, mais si la validation qualité est insuffisante, cela peut entraîner une hausse des bugs
    • il faut examiner non seulement les indicateurs, mais aussi les évolutions du flux de travail dans son ensemble, et agir immédiatement en cas de signe anormal
  • 4.Vérifier en continu l’état de la sécurité psychologique
    • même après le changement, il faut maintenir un environnement où l’équipe peut soulever librement les problèmes
    • pour éviter l’accumulation de problèmes non exprimés, il faut créer une atmosphère où les membres peuvent donner un feedback honnête
    • insatisfaction vis-à-vis du processus modifié, augmentation excessive de la charge de travail, stress imprévu, etc.
  • 5.Évaluer en continu les effets à long terme
    • l’essentiel n’est pas la performance à court terme, mais des résultats durables et l’amélioration du moral de l’équipe
    • au fil du temps :
      • vérifier si le changement s’est durablement installé
      • s’il n’a pas entraîné de nouveaux effets secondaires ou problèmes
      • et s’il y a maintien ou baisse des performances, avec un suivi continu
  • 6.Utiliser le feedback comme opportunité d’apprentissage
    • même un changement raté constitue un précieux actif d’apprentissage
    • il faut analyser ce qui n’a pas fonctionné sur la base des données et du feedback, puis l’intégrer à la tentative suivante
    • il est aussi important de promouvoir une culture qui encourage l’équipe à considérer l’échec comme une opportunité d’apprentissage

Beyond the steps: Make the playbook work for you

• Adapter à votre contexte

  • choisir les indicateurs à mesurer et les méthodes (télémétrie vs enquêtes) en fonction des caractéristiques de l’organisation
  • il ne faut pas faire de la mesure une fin en soi ; elle doit servir d’outil au service d’améliorations concrètes

• Change management

  • il est important d’aider l’organisation à bien s’adapter au changement en utilisant des frameworks de conduite du changement comme les modèles ADKAR ou Kotter

• Growth mindset

  • considérer chaque tentative comme une occasion d’apprendre, avec une attitude d’acceptation de l’échec, est essentiel à l’amélioration continue

• Gamification

  • une conception de récompenses fondée sur la motivation peut avoir des effets positifs, mais si elle est mal conçue, elle peut au contraire entraîner une baisse de la qualité ou des déséquilibres

Alternatives to the GitHub Engineering System Success Playbook

• Selon le contexte, au lieu de l’ESSP, il est aussi possible de recourir à une analyse simple centrée sur l’usage des fonctionnalités ou à des stratégies d’amélioration fondées sur des outils individuels
• L’essentiel est d’adopter une approche réaliste adaptée à l’équipe et à l’organisation, ainsi qu’un effort d’amélioration continu