On a importé le slogan, pas la structure

J’ai été développeur chez Amazon AWS pendant un an. Sur CloudWatch, un service qui sert des millions d’utilisateurs tous les jours. Je n’ai jamais touché à une pipeline. Zéro infra as code. Zéro Kubernetes. Zéro configuration de déploiement. Je recevais des alertes sur mon code en prod, je regardais des dashboards, et quand quelque chose cassait, je débuggais mon propre code. Les pipelines, les déploiements, l’infra qui portait tout ça, c’était fait par d’autres équipes. Invisible depuis mon poste de dev.

C’est le terrain où le slogan “you build it, you run it” a été inventé et évangélisé. Et la réalité, c’est que les devs chez Amazon n’opéraient rien de ce que la majorité des boîtes FR appelle “ops”. On écrivait du code, on le surveillait, on répondait aux alertes de ce qu’on avait écrit. C’est tout.

Cette expérience m’a appris quelque chose que je n’arrête plus de voir depuis. Le devops tel qu’il est vendu dans 90% des annonces est une erreur de catégorie.

Ce que le slogan cache

“You build it, you run it” est une phrase de Werner Vogels, CTO d’Amazon, prononcée en 2006. Le contexte : une méga-organisation avec des dizaines de milliers de développeurs, des équipes SRE dédiées pour chaque domaine critique, un tooling interne qui a 15 ans d’avance sur le marché externe, une plateforme infra qu’ils possèdent littéralement, et des couches de spécialistes ops invisibles depuis le poste dev.

Le slogan a traversé l’Atlantique. La structure qui le rendait viable, elle, est restée aux États-Unis.

En France, on a pris la phrase sans prendre l’orchestration. Résultat : les boîtes mettent un “DevOps Engineer” dans chaque équipe de sept personnes, et exigent de leurs développeurs qu’ils soient capables de déployer dans plusieurs environnements, de comprendre les IAM policies, de débugger un chart Helm et de pousser une feature React dans la même semaine. On appelle ça de la montée en compétences. C’est surtout de la dilution.

Monitoring, on-call, ops : trois métiers que personne ne distingue

Le mot “devops” en FR colle ensemble trois activités qui n’ont rien à voir.

Le monitoring, c’est regarder des indicateurs. Latence, taux d’erreur, métriques business. C’est un travail de lecture. Ça demande de comprendre ce qu’on observe. C’est ce que je faisais chez Amazon, pendant mes heures de bureau, devant un tableau de bord CloudWatch que je connaissais par cœur.

L’on-call, c’est répondre aux alertes de son propre code en production. Chez Amazon, ça veut dire : une alerte part, tu investigues ton code, tu patches, tu pushes. Tu ne touches pas à l’infra. Tu touches à ce que tu as écrit. C’est un travail de responsabilité. Le dev qui a écrit le bug est le mieux placé pour le corriger.

L’ops, c’est tout le reste. Mettre en place les pipelines. Gérer les serveurs. Configurer les load balancers. Orchestrer les déploiements entre environnements. Maintenir les systèmes de déploiement. Garantir la disponibilité à l’échelle. C’est un métier entier, avec ses propres frameworks de pensée, son propre rapport au risque, sa propre littérature.

En confondant les trois sous un même titre, on demande au même humain de faire les trois. Et c’est là que le plafond arrive.

Moyen partout, bon en rien

Un dev qui passe 80% de son temps à coder et 20% à bricoler de l’infra ne deviendra jamais bon en infra. Ni bon en dev, d’ailleurs. Parce que les deux métiers ne partagent pas les réflexes. Le dev optimise pour la clarté et l’itération. L’ops optimise pour la fiabilité et le pire cas. Un dev qui écrit de l’ops écrit du code qui marche. Un ops qui écrit de l’ops écrit du code qui résiste.

Sur mes side projects je fais l’infra de bout en bout. Stacklint tourne sur Coolify derrière un Hostinger, mon Plausible est self-hébergé, mes daemons Raspberry surveillent mon observatoire. Je le fais parce que je suis seul, pas parce que je suis bon. Et le jour où l’un de ces trucs accueillera autre chose que moi et trois curieux, je sais déjà qu’il faudra que quelqu’un de spécialiste reprenne ce que j’ai bricolé.

Je ne pense pas que les devs soient mauvais. Je pense que personne n’est bon dans un métier qu’il ne pratique pas à plein temps.

Même la version light m’a montré la limite

Même dans sa version la plus légère, celle d’Amazon où je répondais aux alertes de mon propre code et pas aux alertes de toute l’infra, j’ai détesté ça.

Pas parce que c’était difficile techniquement. Parce que le contexte mental était incompatible. Quand tu ships une feature, tu es en mode création. Tu construis, tu itères, tu te projettes. Quand tu réponds à une alerte en pleine nuit, tu es en mode investigation. Tu reconstruis ce qui s’est passé, tu cherches l’origine, tu patches au plus court. Les deux modes cohabitent mal dans la même semaine, encore moins dans la même journée.

Et c’est la version light. Le vrai ops, c’est le niveau au-dessus : tu portes les alertes des autres, tu passes ta vie dans le mode investigation, et tu deviens bon à ça parce que tu ne fais que ça.

C’est pour ça que je pense que c’est un métier. Pas parce que c’est plus compliqué que du dev. Parce que c’est un autre rapport au temps et à l’erreur.

À ne pas confondre : l’astreinte sur mon propre code, je l’ai faite et je la referais. C’est moi qui ai écrit le bug, c’est à moi de le réparer, ça ne se négocie pas. Ce qui me bloque, c’est l’autre direction. Qu’on me demande, en plus, de prendre en main l’infra qui fait tourner ce code, et qu’on appelle ce mélange “devops”.

Le modèle SRE, en contre-proposition

Google a pris une autre route. Le SRE, Site Reliability Engineering, ce sont des ingénieurs spécialisés ops. Ils ont une expertise software exigée, parce qu’ils doivent lire du code pour comprendre ce qui casse. Ils écrivent des outils internes pour automatiser la fiabilité. Ils portent des SLI, des SLO, des error budgets. Et ils ne font que ça. Ce ne sont pas des devs qui font l’appoint sur les runbooks. Ce sont des ingénieurs à temps plein sur la fiabilité, qui travaillent aux côtés des devs sans être des devs.

Ce modèle coûte cher. Il demande de reconnaître que l’ops est un métier, de recruter pour lui, de le payer, de lui donner du poids dans les décisions techniques. Beaucoup de boîtes FR n’ont pas envie d’en payer le prix. Alors elles disent à leurs devs : “tu feras aussi l’ops”. Et elles appellent ça du devops.

Le devops, pas le devops

Le mouvement devops, à l’origine, était un appel à casser les silos culturels. Pas un ordre de confondre les métiers. Les papiers de Patrick Debois et Andrew Shafer en 2008-2009 parlaient de coopération entre équipes, pas d’absorption du rôle ops par le rôle dev.

Ce qui a été appliqué dans la majorité des boîtes, c’est la version Disney du concept. On a pris un slogan et on a oublié la structure.

Les meilleures équipes que j’ai vues ne faisaient pas de devops. Elles avaient des développeurs qui respectaient leurs ops, et des ops qui comprenaient le code qu’ils opéraient. Et les ops, ils ne faisaient que ça.

Le calcul a changé pour le solo, pas pour la boîte

Il y a un point que je veux préciser, parce qu’il pourrait sembler en tension avec le reste, et qu’il ne l’est pas.

Quand j’écris que le dev à 20% d’ops ne deviendra jamais bon en ops, ça reste vrai sur la trajectoire de compétence. Personne n’est bon dans un métier qu’il ne pratique pas à plein temps. Mais il y a un autre bout du calcul qu’il faut tenir en parallèle. Pour un dev solo ou une équipe de dix, le besoin n’est pas d’être bon en ops. Le besoin est de ne pas couler quand le serveur tombe. Et ça, avec l’IA, c’est devenu beaucoup plus accessible.

Sur Stacklint, sur mon Plausible, sur les daemons de l’observatoire, je vais voir Claude Code comme on irait voir un sysadmin de garde. Je lui décris le symptôme, il lit la config, il propose. Mes nuits sont moins longues. Mes runbooks sont meilleurs que ceux que j’écrirais seul. Je ne suis pas devenu un meilleur ops. J’ai juste un meilleur outil pour ne pas en avoir besoin d’un vrai.

Tout l’article reste valide pour le bon contexte. Une boîte de cinq cents personnes a besoin de SRE. Un service qui doit tenir cinq neufs de disponibilité a besoin d’humains qui ne font que ça. Mais le seuil où “il faut recruter un ops” se déclenche, il s’est déplacé. À mon échelle, celle du side project ou de la petite équipe, le devops jeté à la figure du dev fait moins de dégâts qu’il y a quelques années, parce que la moitié du fardeau peut être externalisée sur un modèle.

Avant qu’on ne me le dise

Oui, j’ai écrit Je n’ai pas de chapelles. J’ai cinq fatigues. il y a quelques semaines. Non, ce billet n’en est pas une. Une chapelle, c’est Redux vs Zustand, Vue vs React, deux outils interchangeables qu’on transforme en guerre de religion. Ici la question est ailleurs : est-ce que dev et ops sont le même métier élargi, ou deux métiers qu’on a empilés sur un seul humain. Et non, “DevOps Engineer dans la team” vs “un dev plus un SRE séparé” ce n’est pas juste deux options orga équivalentes. C’est deux théories du travail, et l’une des deux dilue les deux métiers.