Note
You build it, you run it !
En 2003, Google inventait et popularisait le SRE : Site Reliability Engineering. L'idée est simple : celui qui construit le logiciel est aussi celui qui en garantit la fiabilité en production.
En 2003, Google inventait et popularisait le SRE : Site Reliability Engineering. L’idée est simple : celui qui construit le logiciel est aussi celui qui en garantit la fiabilité en production.
Plus de 20 ans plus tard, on en a majoritairement gardé que des dashboards Grafana et les alertes PagerDuty. On a oublié le message de fond.
La plupart des organisations ont toujours un mur entre ceux qui codent et ceux qui opèrent. D’un côté, les devs qui livrent des features. De l’autre, une équipe ops qui éponge. Entre les deux, du YAML et des incompréhensions…
Ce modèle arrive (peut-être enfin) en bout de course. Pourquoi maintenant ?
Parce que le coding augmenté par l’IA change la donne, mais pas forcément comme on le croit. On retient l’autocomplétion, la génération de code. C’est passer à côté de l’essentiel.
Ce que l’IA change vraiment, c’est le coût marginal d’acquisition d’une compétence adjacente.
Un développeur backend qui n’a jamais écrit de playbook Ansible peut désormais, avec un assistant IA correctement contextualisé, produire une configuration parfaitement opérationnelle de qualité en une fraction du temps.
L’IA ne remplace pas sa compréhension. Elle abaisse la barrière d’entrée.
Résultat : le profil “T-shaped”, réunissant expertise profonde + capacité à opérer sur les domaines voisins, passe du vœu pieux à la réalité. Elle est là la révolution !
Et c’est là que tout converge.
Si l’IA libère de la bande passante cognitive, moins de plomberie, moins de syntaxe à chercher, moins de tâches répétitives, cette bande passante peut et doit aller quelque part.
Le “quelque part” le plus rentable, c’est la production !
Le développeur devient l’acteur le plus efficace pour assurer le MCO et le MCS de son logiciel. Pourquoi ? Parce que personne ne connaît mieux le comportement attendu d’un service que celui qui l’a conçu.
Le développeur qui a implémenté la synchro CalDAV sait que le pic de latence du lundi matin est normal (recalcul des récurrences). Le même pic un mercredi ? Problème. Aucun runbook ne capture cette nuance. Mais le dev, armé d’observabilité et assisté par une IA contextualisée, diagnostique en minutes ce qui prendrait des heures à une équipe déconnectée du code.
C’est ça, le SRE at scale.
Ce n’est pas demander à chaque dev de devenir expert Kubernetes certifié. C’est reconnaître que le coût cognitif de la compétence opérationnelle a suffisamment chuté pour que chaque développeur puisse et doive devenir le premier gardien de son logiciel en production.
3 forces convergent : → Le modèle T-shaped qui élargit le développeur → L’IA qui en abaisse le coût → Le context engineering qui en garantit la pertinence dans le temps.
Le code ne s’arrête pas à la Pull Request. Il commence vraiment quand un utilisateur l’exécute.
Les organisations qui comprendront cela en premier auront un avantage structurel durable.
Les autres continueront à chercher des “SRE seniors” introuvables sur le marché.
Commentaires
Réponses imbriquées possibles. Vous commentez en tant qu'invité : choisissez un pseudo, et c'est tout. Modération a posteriori : tout est publié immédiatement, je peux retirer si besoin.