Cas avances¶

Platform engineering, inner source, DX ops, community of practice et métriques DORA.

Platform engineering¶

Le platform engineering est l'évolution naturelle du DevOps à grande échelle. Une équipe plateforme construit et maintient les outils et services internes qui permettent aux équipes produit de livrer en autonomie.

Internal Developer Platform (IDP)¶

L'IDP est le produit que l'équipe plateforme livre aux développeurs. Il regroupe :

Self-service de provisioning (environnements, bases de données, queues)
Golden paths : chemins recommandes pour les cas d'usage courants
Observabilité par défaut : monitoring, logging, tracing pre-configures
Pipelines CI/CD standardises et maintenus par la plateforme

Golden paths¶

Un golden path est une approche recommandee, documentee et supportee pour accomplir une tâche courante. Il n'est pas obligatoire, mais il est le chemin de moindre résistance.

Sans golden path	Avec golden path
Chaque équipe reinvente sa configuration K8s	Template maintenu, sécurisé, mis à jour centralement
Proliferation de patterns CI/CD incompatibles	Pipeline standard avec variantes documentees
Observabilité hétérogène, impossible a comparer	Instrumentation par défaut, dashboards standards

Platform engineering n'est pas des ops renommes

L'équipe plateforme construit des produits pour les développeurs. Elle a un backlog produit, des utilisateurs internes, des métriques d'adoption. Ce n'est pas de l'ops renomme — c'est une discipline différente avec ses propres indicateurs de succès.

Inner source infra¶

L'inner source applique les pratiques open source (contributions, pull requests, reviews) aux projets internes. En infrastructure, cela signifie que n'importe quelle équipe peut contribuer au code infra d'une autre équipe.

Processus de contribution¶

graph LR
    A["Equipe A\nidentifie un besoin"] --> B["Fork ou branche\ndu repo infra"]
    B --> C["Developpement\nde la contribution"]
    C --> D["Pull request\nvers equipe proprietaire"]
    D --> E["Review\npar maintainers"]
    E -->|Acceptee| F["Merge\net deploiement"]
    E -->|Amendements| C

Conditions de succès¶

Code infra version dans Git, avec README et documentation
Guidelines de contribution claires (CONTRIBUTING.md)
Revue rapide : SLA de review inférieur à 2 jours ouvrables
Culture de review bienveillante (blameless culture appliquee au code)

DX ops : faciliter la vie des développeurs¶

La Developer Expérience (DX) ops consiste à mesurer et améliorer la qualité de l'expérience des développeurs avec les outils et processus d'exploitation.

Axes d'amélioration¶

Axe	Objectif	Exemple
Self-service	Éliminer les tickets d'attente	Portal Backstage pour provisionner des ressources
Documentation	Trouver en moins de 5 min	Catalogue de services avec runbooks intégrés
Feedback loop	Savoir si ca marche avant la prod	Environnements éphémères, feature flags
Onboarding	Être productif en 1 jour	Dev environment as code, scripts d'initialisation

Mesurer la DX¶

DORA metrics (voir section suivante) : proxy de la fluidite du delivery
Developer satisfaction survey : NPS interne trimestriel
Time to first PR pour les nouveaux : proxy de l'onboarding
Time to provision : durée réelle pour obtenir une ressource en self-service

Community of practice¶

Une community of practice (CoP) est un groupe transverse de personnes partageant un domaine d'expertise ou d'intérêt. En ops, les CoP permettent de mutualiser les apprentissages sans centraliser les décisions.

Formats courants¶

Format	Fréquence	Objectif
Guilde ops	Bimensuelle	Partage des pratiques, décisions transverses
Show & tell	Mensuel	Demonstrations, retours d'expérience
Meetup interne	Trimestriel	Presentations approfondies, intervenants externes
Canal Slack / Teams	Permanent	Questions, partage de liens, near misses

Facteurs de succès¶

Participation volontaire, pas obligatoire
Facilitation tournante pour distribuer le leadership
Livrables concrets : standards, ADR, playbooks partages
Soutien management : du temps dédié, pas juste "faites-le en plus"

Métriques DORA¶

Les métriques DORA (DevOps Research and Assessment) sont les quatre indicateurs de performance du delivery software les plus valides empiriquement.

Les quatre métriques¶

Métrique	Définition	Elite	High	Medium	Low
Deployment frequency	Fréquence des déploiements en prod	Plusieurs fois/jour	1x/jour–1x/sem	1x/sem–1x/mois	< 1x/mois
Lead time for changes	Commit → production	< 1 heure	1j–1 sem	1 sem–1 mois	> 1 mois
Change failure rate	% déploiements causant un incident	< 5%	5-10%	10-15%	> 15%
Time to restore	Durée de restauration après incident	< 1 heure	< 1 jour	1j–1 sem	> 1 sem

Matrice DORA¶

quadrantChart
    title DORA - Throughput vs Stabilite
    x-axis Stabilite faible --> Stabilite elevee
    y-axis Throughput faible --> Throughput eleve
    quadrant-1 Elite performer
    quadrant-2 A risque - rapide mais instable
    quadrant-3 Low performer
    quadrant-4 A ameliorer - stable mais lent
    Elite: [0.85, 0.85]
    High: [0.65, 0.65]
    Medium: [0.4, 0.4]
    Low: [0.2, 0.2]

Mesurer les métriques DORA¶

Deployment frequency : events de déploiement dans le CI/CD (GitLab, GitHub Actions, ArgoCD)
Lead time : timestamp commit vs timestamp déploiement en prod, extrait du VCS
Change failure rate : incidents tagges "triggered by deployment" / total déploiements
Time to restore : durée entre ouverture et résolution des incidents de production

Commencer par une seule métrique

Vouloir mesurer les quatre métriques simultanément sans données de base est ambitieux. Commencer par le deployment frequency (le plus simple) et le change failure rate (le plus impactant) pour montrer de la valeur rapidement.