Il y a presque trois ans, j’ai écrit ici que le devops n’était pas un métier. Je le pense toujours et je n’ai pas une ligne à retirer.
Ce que je n’avais pas vu venir, c’est ce qu’on allait en faire.
On a créé des équipes devops. Puis, quand le mot a commencé à sentir le renfermé, on les a rebaptisées équipes plateforme. Et dans la majorité des endroits où je suis passé, le résultat est le même : un guichet de plus. Personne ne l’a décidé, personne n’en voulait, et tout le monde s’en accommode très bien.
Trois noms, le même travail
Il faut que je commence par là, parce que ça éclaire tout le reste : en vingt ans, j’ai changé trois fois d’intitulé sans changer une seule fois de travail.
J’ai commencé en exploitation, à l’époque où on disait simplement « système ». Le développeur écrivait, on recevait une livraison, on la mettait en production, et si ça cassait c’était pour nous. Silo parfaitement assumé, avec deux équipes qui ne se parlaient qu’en cas de problème. Puis on m’a appelé devops. Puis architecte. Puis plateforme.
À chaque fois, le même métier : faire en sorte que la production tienne, et ne pas être dans le chemin de ceux qui la font vivre. Ma façon de travailler n’a pas bougé d’un pouce, et ma façon de la défendre non plus.
Ce n’est pas de la coquetterie de vieux briscard. C’est un symptôme, et il est assez simple à lire : on ne rebaptise pas trois fois une chose qui marche.
Le devops n’a jamais tenu sa promesse
Le devops devait être une culture. Une façon de travailler qui vient par-dessus un métier, pas à la place. J’y ai cru, sincèrement, et j’y crois toujours.
Sauf que le jour où on a pu recruter « un devops », c’était plié.
Il est devenu un intitulé sur LinkedIn, puis une équipe sur un organigramme, puis une chaîne d’outils qu’on achète en trois licences. Trois façons différentes de rater exactement la même idée. J’en faisais déjà le constat il y a trois ans, et je le voyais alors comme un malentendu, une erreur de vocabulaire qui finirait par se dissiper.
Ce que je ne voyais pas, c’est que cet échec n’était pas un accident. Le devops n’avait aucun moyen de tenir sa promesse, parce qu’il ne reposait que sur de la bonne volonté. Il demandait aux gens de collaborer, de partager, de se faire confiance. C’est très bien tant que les gens restent en place et que personne ne compte les points.
Une culture sans objet ne survit pas à une réorganisation. Il suffit d’un changement de direction, de deux départs et d’un plan de charge tendu, et il ne reste rien. J’écrivais dans un vieux billet sur l’humain que quand le devops reste l’affaire d’une poignée de personnes, les silos se déplacent sans disparaître. Je pensais décrire un cas particulier. Je décrivais la règle.
Le jour où l’équipe devient un guichet
Le basculement n’a rien de spectaculaire. C’est ce qui le rend difficile à repérer.
Un développeur a besoin d’un bucket. Il vient vous voir. Vous le créez en quatre minutes, parce que c’est objectivement plus rapide que de lui expliquer comment faire. Vous êtes content, il est content, la journée avance.
Voilà. C’est fait. Vous venez d’ouvrir le guichet, et personne dans la pièce ne s’en est aperçu.
La suite se déroule toute seule, et vous l’avez peut-être vécue :
- la deuxième demande arrive, puis la cinquième, et vous vous rendez compte que vous répondez toujours la même chose ;
- du coup vous faites un modèle de demande, pour gagner du temps. C’est raisonnable ;
- le modèle devient un formulaire, parce que les gens oubliaient la moitié des informations ;
- le formulaire devient un projet de tickets, parce qu’il faut bien suivre ;
- quelqu’un demande un délai d’engagement sur le traitement des tickets ;
- et un matin vous vous entendez répondre à un collègue : « merci de passer par le formulaire ».
Chacune de ces étapes est défendable. Prises une par une, je les ai toutes défendues moi-même. L’ensemble donne une administration, et vous savez déjà à quoi ça ressemble vu de l’autre côté : j’en ai parlé dans l’article sur la dette technique, avec la maison qui rend fou et le laissez-passer A38.
Et pourquoi ça arrange tout le monde
Voilà le passage que je ne lis jamais nulle part, et c’est pourtant celui qui explique pourquoi le problème ne se corrige pas de lui-même.
Il n’y a pas de méchant dans cette histoire. Le guichet tient parce qu’il arrange les trois parties.
Le développeur. Il n’a pas envie d’apprendre le stockage objet, les politiques d’accès et les subtilités du chiffrement au repos. Et franchement, il a raison : ce n’est pas son métier, il a déjà un backlog et une revue de code qui l’attendent. Remplir un formulaire lui coûte cinq minutes, apprendre lui coûte deux jours. Il choisit rationnellement.
L’équipe plateforme. Là, il faut être honnête, et je m’inclus dedans. Être celui qui sait, c’est agréable. On est sollicité, on est utile, on résout des choses que les autres ne savent pas résoudre. Personne ne se lève le matin avec l’envie de devenir inutile. Quand on vous remercie dix fois par semaine, vous n’allez pas spontanément supprimer la raison pour laquelle on vous remercie.
Le management. Une file d’attente, ça se mesure. On compte les tickets entrants, les tickets traités, le délai moyen, et ça fait un joli graphique en fin de trimestre. Une équipe qui a rendu quatre cents demandes inutiles ne produit aucun graphique. Devinez laquelle des deux est plus facile à défendre en comité de direction.
Alors qui, dans cette histoire, a intérêt à ce que ça change ? Personne. Trois intérêts convergents, aucune mauvaise intention, et c’est exactement pour ça que ça dure.
Ce que le platform engineering a en plus
Et là je vais arrêter d’être pessimiste, parce que je ne le suis pas du tout.
Le platform engineering est en train de s’extraire des décombres du devops, et il arrive avec une chose que le devops n’a jamais eue : un objet. Quelque chose qui existe en dehors des gens, qu’on peut versionner, tester, casser, réparer et transmettre. Le devops demandait aux équipes de bien s’entendre. Une plateforme leur donne quelque chose à utiliser.
C’est toute la différence, et c’est pour ça que j’y crois cette fois. Une culture se perd à la première réorganisation. Un produit reste, parce qu’il est écrit quelque part et que des gens s’en servent tous les jours.
Encore faut-il en faire un produit. Et c’est exactement là que ça se joue, parce que la distinction est fine : un service fait les choses à votre place, un produit vous permet de les faire. Le guichet dont je parlais plus haut, c’est un service. C’est le devops qui recommence, avec de meilleurs outils.
Une équipe plateforme qui fonctionne construit un produit interne. Ça veut dire des choses très concrètes, et assez exigeantes :
- un chemin balisé pour les cas courants, qui marche sans demander la permission à personne ;
- des garde-fous plutôt que des validations. Une politique qui refuse automatiquement une configuration dangereuse vaut mieux qu’un humain qui relit une demande le mardi ;
- une documentation qui est le produit, pas son annexe. Si le chemin balisé n’est pas trouvable en deux minutes, il n’existe pas ;
- des versions, des dépréciations et des annonces, comme pour n’importe quelle bibliothèque que vous publieriez à l’extérieur ;
- et un vrai retour utilisateur, c’est-à-dire aller voir les équipes plutôt que d’attendre qu’elles ouvrent un ticket.
Posez-vous la question sur le troisième : est-ce qu’un développeur peut trouver votre chemin balisé sans vous demander où il est ? Si la réponse passe par un message privé à quelqu’un de votre équipe, ce n’est pas un produit.
Mais le point le plus dur reste le dernier. Il demande de sortir de son écran pour aller demander à des gens ce qui les bloque, en sachant qu’ils vont répondre des choses désagréables sur un outil que vous avez écrit.
C’est au fond le même déplacement que celui dont je parlais dans l’article sur l’apply : la capacité de faire quelque chose ne doit pas appartenir à des personnes, elle doit appartenir à un objet que tout le monde peut utiliser.
Le seul indicateur qui compte
Si vous voulez savoir où vous en êtes, arrêtez de compter les demandes que vous avez traitées. Comptez celles qui n’ont pas eu besoin d’être ouvertes.
Le test est brutal mais il est net : sur les cas standard, le nombre de sollicitations doit baisser. Pas rester stable, baisser. Si votre file d’attente grossit au même rythme que l’entreprise, vous n’avez pas construit une plateforme, vous avez construit un service d’assistance avec du Terraform dedans.
Et il y a un signe plus fiable encore, parce qu’il ne se triche pas : est-ce qu’une équipe produit peut livrer une nouvelle application en production, de bout en bout, sans qu’un membre de votre équipe touche un clavier ? Si la réponse est non, vous savez ce qu’il vous reste à faire.
« Mais alors on ne sert plus à rien ? »
C’est l’objection qu’on me fait à chaque fois, et je la comprends, parce qu’elle est très inconfortable quand on la reçoit.
Non. Vous ne disparaissez pas, vous montez. Et honnêtement, vous préférerez. Les cas standard partent en libre-service, et vous récupérez ce qui n’est pas standard : la migration délicate, le débit qui ne passe plus, la reprise après incident, l’arbitrage de coût, la partie de l’architecture que personne d’autre ne veut regarder. C’est du travail plus difficile et plus intéressant, et il ne manquera jamais.
Et je ne vais pas prétendre qu’il faut tout ouvrir. Certaines choses ont parfaitement leur place derrière une porte : les accès en écriture sur la production, l’engagement de dépense au-delà d’un seuil, les secrets, ce qui relève de la conformité. Le but n’a jamais été de tout donner à tout le monde. Le but, c’est de ne pas être dans le passage sur les gestes ordinaires.
La règle que j’applique est bête : si une demande revient plus de trois fois, elle n’a plus rien à faire dans une file d’attente. Elle doit devenir un bouton, une commande, ou un modèle. Et si vous n’avez pas le temps de le faire, c’est en général le signe que vous passez vos journées à traiter la même demande pour la quatrième fois.
Et les agents, dans tout ça ?
Il y a une raison de plus de s’y mettre, et elle n’existait pas quand j’écrivais mon article de 2023.
Aujourd’hui, une partie du travail est déclenchée par des choses qui ne sont pas des humains. Un agent qui doit obtenir une base de données pour finir sa tâche se retrouve bloqué exactement comme un développeur, à un détail près : il ne peut pas relancer en réunion, ni croiser quelqu’un devant la machine à café.
Autrement dit, si votre plateforme n’est consommable que par un humain qui remplit un formulaire et attend une réponse, rien d’automatisé ne pourra jamais s’en servir. Vous devenez le point de blocage de tout ce qui essaie d’aller plus vite.
Je ne dis pas que c’est une bonne ou une mauvaise nouvelle. Je dis que le guichet, qui était jusqu’ici une lenteur, devient un mur.
En conclusion
J’écrivais dans l’article sur la dette technique que la personne indispensable est en réalité une personne coincée, et qu’on ne fait pas évoluer quelqu’un qu’on ne peut pas remplacer à son poste. Une équipe plateforme indispensable, c’est exactement la même chose en plus grand. Elle est sollicitée en permanence, elle ne fait plus rien de fond, et elle est la première à sauter le jour où quelqu’un décide qu’elle coûte cher pour ce qu’elle produit.
Mon travail n’a pas changé depuis le début, et ma façon de le faire non plus. Ce sont les étiquettes qui ont bougé autour, et le devops aura été celle qui promettait le plus et qui a tenu le moins. Pas parce que l’idée était mauvaise — elle était juste, et je la défends encore — mais parce qu’on n’avait rien de solide à quoi l’accrocher.
Le platform engineering, lui, a l’objet qui manquait. C’est la première fois en vingt ans qu’on a une vraie chance de tenir cette promesse-là. À une seule condition, et c’est tout le propos de ce billet : que la plateforme reste un produit et ne redevienne pas un guichet. Sinon on aura juste changé de nom une quatrième fois.
Et pour ceux qui craignent de se rendre inutiles : une équipe qui se rend dispensable sur l’ordinaire devient indispensable sur le difficile. Ce n’est pas la même position, et ce n’est pas le même métier.
Le meilleur jour d'une équipe plateforme, c'est celui où personne ne l'a appelée.