SRE vs DevOps : quel modèle pour votre organisation ?

Nous entendons souvent : "Sommes-nous une équipe DevOps ou SRE ?" La réponse : ça dépend de votre maturité, votre taille, et vos priorités. Et souvent, vous commencez par DevOps et migrez progressivement vers SRE.

Comprendre la différence est critique pour structurer vos équipes à bon escient.

DevOps : la philosophie

DevOps est une culture et un ensemble de pratiques qui rapproche dev et ops.

Objectif : réduire la friction entre développement et production, en donnant aux devs plus de responsabilité opérationnelle.

Caractéristiques :

• Devs et ops travaillent dans une même équipe
• Déploiements fréquents (plusieurs fois par jour)
• Automatisation de l'infra (Infrastructure as Code)
• Propriété partagée : "You build it, you run it"
• Feedback rapide (logs, métriques centralisées)

Exemple : Une équipe de 8 personnes (6 devs + 2 profils ops) gère une application de bout en bout : code, CI/CD, déploiement, support production.

Avantages DevOps

• Vélocité : les devs poussent directement en production, pas d'attente ops
• Responsabilisation : les devs se sentent responsables du code en production
• Rentabilité : une équipe, zéro passage de relais

Inconvénients DevOps

• À partir d'une certaine échelle (> 100 services), c'est difficile à gérer
• Les devs se noient dans l'ops et ne font plus de code métier
• Manque de standardisation (chaque équipe a ses patterns)

SRE : la discipline

SRE = Site Reliability Engineering. C'est une discipline qui applique le génie logiciel à l'exploitation.

Objectif : rendre la production aussi fiable que possible, sans laisser les devs gérer tous les détails opérationnels.

Caractéristiques :

• Équipe SRE séparée des devs (mais étroitement liée)
• SLOs explicites ("99,95 % de disponibilité")
• Error budgets (si on dépasse, on ralentit les déploiements)
• Automatisation de la fiabilité (pas juste la rédaction de runbooks manuels)
• Obsession pour la réduction du toil (éliminer les tâches répétitives)

Exemple : Une équipe platform SRE (10-15 personnes) maintient la plateforme Kubernetes partagée. Chaque équipe produit déploie via GitOps, mais ne gère pas les incidents critiques.

Avantages SRE

• Standardisation : patterns uniformes, moins de variabilité
• Expertise : les SRE se concentrent sur la fiabilité, pas dilués dans le code métier
• Passage à l'échelle : une équipe SRE peut supporter 50+ services
• Gestion des incidents : discipline rigoureuse, post-mortems systématiques

Inconvénients SRE

• Coût supérieur (équipe dédiée)
• Risque de silos : "ce n'est pas mon problème, c'est SRE"
• Surcharge de processus (définition des SLOs, suivi des error budgets)

Les métriques DORA : comment mesurer ?

Avant de choisir, mesurez où vous en êtes actuellement. Les métriques DORA (définies par Google, popularisées par le livre "Accelerate") sont le standard :

# Mesurer vos métriques DORA

# 1. Deployment Frequency : nombre de merges/semaine
git log --oneline --since="7 days ago" | wc -l

# 2. Lead Time : temps moyen entre commit et deploy
# (nécessite tagging ou CI logs)

# 3. Change Failure Rate : nombre de incidents / nombre de deployments
# (d'un incident tracking system)

# 4. MTTR : durée moyenne des incidents
# (d'un incident tracking system)

Si vous mesurez :

• Fréquence de déploiement < 1/semaine -> DevOps en place mais pas mature, ou SRE non mature
• Taux d'échec des changements > 30 % -> Problèmes de tests/stabilité

SLO, SLI, SLA : les briques du SRE

SLI : Service Level Indicator

C'est une métrique mesurée : "Quel pourcentage des requêtes répondent en < 100ms ?"

SLI = (nombre de requêtes complétées en < 100ms) / (nombre total de requêtes)

Exemples :

• Latence : % des requêtes répondant en < X ms
• Disponibilité : % du temps où le service est en ligne
• Taux d'erreur : % des requêtes réussies
• Débit : requêtes par seconde supportées

SLO : Service Level Objective

C'est la cible : "Nous visons 99,5 % de disponibilité."

SLO = cible pour le SLI

SLA : Service Level Agreement

C'est le contrat : "Nous garantissons 99,9 % ou vous êtes remboursé."

SLA >= SLO (on promet moins que ce qu'on peut faire)

Error Budget

Si votre SLO est de 99,9 % (~43 min de downtime autorisé par mois), vous avez un error budget d'environ 43 minutes.

Error Budget = (1 - SLO) × durée de la période
             = (1 - 0.999) × 43 200 min
             = 43,2 min par mois

Utilisation :

• Si vous avez 20 min de downtime ce mois, il vous reste 23 min
• Si vous les épuisez, les déploiements sont ralentis (revue de code, tests additionnels)
• Cela crée une tension saine entre vélocité et fiabilité

# Exemple Prometheus SLO definition
apiVersion: v1
kind: ConfigMap
metadata:
  name: slo-config
data:
  slo.yaml: |
    apiVersion: v1
    kind: SLOGroup
    metadata:
      name: api-service
    spec:
      serviceName: "api"
      slos:
      - name: "availability"
        description: "% of successful requests"
        target: 0.999
        indicator:
          latencyThreshold: 100ms
      - name: "latency"
        description: "% of requests under 100ms"
        target: 0.95
        indicator:
          latencyThreshold: 100ms

Le choix : DevOps vs SRE -- framework de décision

Pour faciliter la décision, voici un framework comparatif concret qui résume les dimensions clés :

Ce framework permet de positionner votre organisation objectivement. La plupart des entreprises suisses que nous accompagnons se situent dans la zone hybride : assez grandes pour avoir besoin de standards, mais pas assez pour justifier une équipe SRE de 20 personnes.

Choisir DevOps si :

• < 20 services
• Équipes < 10 personnes
• Tolérance aux incidents modérée (95-99 % acceptable)
• Vélocité > Stabilité
• Peu de dépendances inter-équipes

Choisir SRE si :

• 50 services

• Équipes > 50 personnes
• Disponibilité critique (99,9 %+)
• Stabilité >= Vélocité
• Services interdépendants (A -> B -> C)
• Compliance stricte (SLA Tier 1 externe)

Choisir hybride si (cas le plus courant) :

• Vous avez actuellement un modèle DevOps
• Vous avancez vers une maturité SRE
• Certaines équipes sont proches du code (DevOps), d'autres focalisées sur l'infra (SRE)

Recommandation pour les organisations de 500+ personnes : Hybride. Une équipe platform SRE (10-20 personnes) maintient l'infra partagée, mais chaque squad produit reste en mode DevOps pour son service.

Architecture recommandée pour 500+ collaborateurs

┌─────────────────────────────────────────┐
│ Équipe Platform SRE (15 personnes)      │
│ - Infrastructure Kubernetes             │
│ - Fiabilité des bases de données        │
│ - Stack d'observabilité                 │
│ - Responsable d'incident                │
└─────────────────────────────────────────┘
           ↓
┌──────────────────────┬──────────────────────┬──────────────────────┐
│ Squad A (8 devs)     │ Squad B (10 devs)    │ Squad C (6 devs)     │
│ Modèle DevOps :      │ Modèle DevOps :      │ Modèle DevOps :      │
│ - Propre code        │ - Propre code        │ - Propre code        │
│ - Déploiement GitOps │ - Déploiement GitOps │ - Déploiement GitOps │
│ - Support SLA par    │ - Support SLA par    │ - Support SLA par    │
│   Platform SRE       │   Platform SRE       │   Platform SRE       │
└──────────────────────┴──────────────────────┴──────────────────────┘

Éléments partagés maintenus par Platform SRE :

• Cluster Kubernetes
• Monitoring/alerting (Prometheus/Grafana)
• Logging (ELK, Splunk)
• Gestion des incidents
• Rotation d'astreinte pour P1/P2
• Disaster recovery
• Capacity planning

Éléments possédés par chaque Squad :

• Code source
• Déploiements (GitOps/ArgoCD)
• Développement de fonctionnalités
• Tests unitaires/intégration
• Backlog

Interface :

• Les squads utilisent Platform SRE via Slack/runbooks
• Platform SRE escalade lors des incidents critiques
• Réunion d'alignement hebdomadaire
• SLOs et error budgets partagés

Métriques de succès

Après 6 mois d'implémentation SRE, vous devriez voir :

Fréquence de déploiement : 1/jour → 2-3/jour
Délai de mise en production : 3 semaines → 3 jours
Taux d'échec des changements : 25 % → 10-15 %
MTTR : 2 heures → 30 min
Toil : 50 % ops → 20 % ops
Satisfaction des développeurs : +30 %

Conclusion

DevOps et SRE ne s'opposent pas. SRE est une évolution de DevOps avec plus de discipline et d'échelle.

À retenir :

• Commencez par DevOps (plus simple, plus rapide)
• À partir d'une certaine complexité, migrez vers SRE
• Pour 500+ personnes, l'hybride est le point d'équilibre idéal
• Mesurez avec les métriques DORA, définissez des SLOs explicites
• Les error budgets créent une tension saine entre vélocité et fiabilité

Hidora aide les organisations à structurer leurs équipes selon ce modèle et à implémenter les pratiques SRE/DevOps correctement.

À lire aussi :

• SLA vs Managed Services : comprendre les modèles de support
• Équipe DevOps : comment éviter le burnout

Cet article vous a été utile ? Découvrez comment Hidora peut vous accompagner : Professional Services · Managed Services · SLA Expert