SRE et DevOps : faut-il un gardien de la prod dans votre startup ?

"On a un problème de fiabilité en prod, il nous faut un SRE." J'entends cette phrase régulièrement chez mes clients. Mais derrière l'acronyme à la mode, peu de fondateurs savent vraiment ce que fait un SRE — et surtout s'ils en ont réellement besoin.

SRE et choix d'infra

Le rôle du SRE dépend beaucoup de vos choix d'hébergement. Si vous hésitez encore entre Cloud public et VPS, cet article sur le choix d'hébergement vous aidera à y voir plus clair.

SRE vs DevOps : les différences en un coup d'œil

	DevOps	SRE
Nature	Culture, ensemble de pratiques	Rôle concret, métier à part entière
Objectif	Fluidifier la collaboration dev/ops	Garantir la fiabilité des systèmes en production
Outils clés	CI/CD, IaC, conteneurs	SLOs, error budgets, monitoring, incident management
Qui l'incarne	Toute l'équipe (c'est une culture)	Un ingénieur ou une équipe dédiée
Quand	Dès le premier déploiement	Quand la complexité ou le trafic l'exigent

En résumé : le DevOps est une philosophie, le SRE est une façon concrète de la mettre en œuvre. Google résume ça par "SRE implements DevOps". En pratique, les deux sont complémentaires.

Ce que fait vraiment un SRE

Le SRE (Site Reliability Engineer) est né chez Google au début des années 2000. L'idée était simple : appliquer les méthodes du développement logiciel aux problématiques d'exploitation. Au lieu de gérer l'infra à la main, on l'automatise. Au lieu de réagir aux incidents, on les anticipe.

Définir les objectifs de fiabilité (SLOs)

Le SRE ne cherche pas le 100% de disponibilité — ça n'existe pas, et même si c'était possible, ça coûterait beaucoup trop cher. Il définit des SLOs (Service Level Objectives) : des objectifs de fiabilité réalistes et mesurables.

Exemple concret : "Notre API doit répondre en moins de 200ms pour 99,5% des requêtes." Ce chiffre n'est pas arbitraire — il est calibré en fonction de l'impact business. Pour un site e-commerce, 99,9% est critique. Pour un back-office interne, 99% peut largement suffire.

Gérer l'error budget

Concept contre-intuitif mais puissant : le budget d'erreur. Si votre SLO est à 99,5%, vous avez droit à 0,5% d'indisponibilité par période. Tant que vous êtes dans ce budget, vous pouvez déployer agressivement. Quand le budget est consommé, on ralentit et on stabilise.

Ce mécanisme résout une tension classique entre devs et ops : les devs veulent livrer vite, les ops veulent de la stabilité. Le budget d'erreur donne un cadre objectif pour arbitrer.

Réduire le "toil"

Le "toil", c'est le travail manuel, répétitif, qui ne crée pas de valeur durable. Redémarrer un serveur qui plante tous les jours, lancer manuellement un script de migration, répondre aux mêmes alertes. Le SRE a pour mission d'automatiser tout ce qui peut l'être — l'objectif classique chez Google est de ne pas dépasser 50% de temps en toil.

Piloter les incidents

Quand la prod tombe, le SRE coordonne la réponse. Pas en mode panique, mais avec un processus structuré : identification, mitigation, communication, puis post-mortem. Le post-mortem est probablement la pratique la plus précieuse : analyser ce qui s'est passé sans chercher de coupable, pour éviter que ça se reproduise.

SRE, DevOps Engineer, Admin Sys : la confusion

C'est l'erreur que je vois le plus souvent : recruter un "SRE" pour en faire un admin sys glorifié, ou confondre le rôle avec celui d'un DevOps Engineer.

Rôle	Focus principal	Compétences clés
Admin Sys	Maintenir l'infra existante	Linux, réseaux, sécurité
DevOps Engineer	Automatiser les pipelines de déploiement	CI/CD, IaC, conteneurs
SRE	Fiabilité des systèmes en production	Dev + Ops + métriques business

La différence fondamentale : un SRE pense en termes de service rendu à l'utilisateur, pas en termes de serveurs ou de pipelines. Il écrit du code — beaucoup de code — pour automatiser, monitorer et fiabiliser. C'est un développeur qui a choisi de résoudre les problèmes de production.

Si votre "SRE" passe ses journées à configurer des serveurs et répondre à des tickets, ce n'est pas un SRE — c'est un admin sys avec un titre à la mode.

Quand introduire un SRE dans votre startup ?

C'est la question que me posent la plupart des CTO que j'accompagne. Et la réponse est rarement "tout de suite".

Avant 10 développeurs : probablement pas

À ce stade, vos devs gèrent eux-mêmes le déploiement et le monitoring. Et c'est normal. Un setup Docker sur un VPS avec un bon CI/CD couvre 90% des besoins. La culture DevOps — chaque dev est responsable de son code en prod — suffit largement.

Investir dans un SRE à ce stade, c'est comme embaucher un DRH quand on est 5 : le rôle n'a pas encore de matière.

Entre 10 et 30 développeurs : les signaux d'alerte

C'est souvent dans cette phase que les premiers vrais problèmes de fiabilité apparaissent. Les signaux qui indiquent qu'un SRE pourrait vous aider :

Les incidents se répètent : les mêmes problèmes reviennent toutes les semaines
Les devs passent plus de 20% de leur temps sur des sujets ops : debugging prod, alertes, déploiements cassés
Personne ne sait dire si le système est "en bonne santé" : pas de métriques, pas de SLOs, on découvre les problèmes quand les clients appellent
Les déploiements font peur : on déploie le vendredi soir en croisant les doigts (ou pire, on ne déploie plus le vendredi)

Si vous cochez 2-3 de ces cases, il est temps de structurer le sujet. Pas forcément en recrutant un SRE senior — parfois, un dev expérimenté avec un appétit pour le sujet peut lancer la dynamique.

Au-delà de 30 développeurs : quasiment indispensable

Quand vous passez en mode scaling, la fiabilité devient un enjeu business de premier ordre. Un incident en prod qui touche des milliers d'utilisateurs, ça se chiffre vite — en revenus perdus, en confiance client, en charge support.

À cette échelle, une équipe SRE (ou au minimum un SRE senior) apporte une vraie valeur : des SLOs partagés avec le business, un processus d'incident management rodé, et une culture du post-mortem qui fait progresser toute l'organisation.

Comment intégrer le SRE dans une culture DevOps

L'erreur classique : créer une équipe SRE en silo qui devient le nouveau "mur" entre dev et ops. Exactement ce que le DevOps cherchait à supprimer.

Le SRE comme enabler, pas comme gatekeeper

Le SRE ne devrait jamais être celui qui "autorise" les déploiements. Son rôle est de donner aux devs les outils et la visibilité pour déployer en confiance : monitoring, alerting, runbooks, feature flags.

En pratique, ça veut dire que le SRE travaille avec les équipes de dev, pas à côté. Il participe aux sprints, comprend le produit, et ses priorités sont alignées sur celles du business — pas sur une liste de tickets infra déconnectée.

Les rituels à mettre en place

Quelques pratiques concrètes qui fonctionnent bien :

Post-mortems blameless : après chaque incident significatif, une analyse factuelle partagée avec toute l'équipe. Pas de coupable, des apprentissages.
Revue mensuelle des SLOs : avec le CTO et les leads dev. Le budget d'erreur est-il respecté ? Faut-il ralentir les releases ou peut-on accélérer ?
On-call partagé : les devs participent à l'astreinte, pas seulement le SRE. Ça les responsabilise sur la qualité de leur code en prod.
Toil review trimestrielle : identifier les tâches répétitives et décider lesquelles automatiser en priorité.

Les pièges à éviter

Ne pas transformer le SRE en équipe support. Si chaque équipe dev envoie ses problèmes de prod au SRE "parce que c'est son job", vous avez recréé le silo ops. Le SRE construit des outils et des processus — il ne devrait pas être le seul à savoir déployer ou debugger la prod.

Ne pas viser la perfection. Un SLO à 99,99% quand vos utilisateurs sont 200 personnes sur un back-office, c'est du sur-engineering. Commencez simple, mesurez, itérez. C'est d'ailleurs le même principe que pour le choix de votre stack technique : la solution la plus simple est souvent la meilleure.

Le SRE et le CTO : quelle relation ?

Le SRE est un allié précieux pour le CTO, surtout dans les phases de croissance. Il fournit des données objectives sur l'état du système — pas des impressions, des métriques.

Quand un CEO demande "est-ce que notre plateforme est fiable ?", le CTO ne devrait pas répondre "oui, je crois". Avec un SRE et des SLOs en place, la réponse devient : "Notre SLO de disponibilité est à 99,7% ce mois-ci, au-dessus de notre objectif de 99,5%. Notre temps de réponse P95 est à 180ms, dans la cible."

C'est un changement fondamental dans la façon dont la tech communique avec le business. Et c'est exactement ce qu'on attend d'un CTO qui dépasse le rôle de premier dev.

En résumé

Le SRE n'est pas un buzzword ni un admin sys rebrandé. C'est un rôle qui prend tout son sens quand votre startup atteint un niveau de complexité où la fiabilité devient un enjeu business.

Stade	Approche recommandée
Early-stage (< 10 devs)	Culture DevOps, chaque dev gère la prod de son périmètre
Growth (10-30 devs)	Un dev expérimenté qui lance les pratiques SRE (SLOs, post-mortems)
Scale-up (30+ devs)	Équipe SRE dédiée, processus d'incident management, on-call structuré

L'important n'est pas le titre sur la fiche de poste, mais les pratiques : des objectifs de fiabilité mesurables, une culture du post-mortem, et une automatisation systématique du travail répétitif. Le reste suivra.

Besoin de structurer votre équipe technique ?

Que vous soyez en phase de création d'équipe technique ou de scaling, je vous aide à définir les bons rôles — SRE inclus — et les bonnes pratiques pour fiabiliser votre plateforme sans sur-ingénierie.