DevOps n'est pas un poste que l'on recrute

On nous demande souvent de « mettre en place le DevOps ». La demande est presque toujours formulée comme un recrutement : une personne, un titre, un outil à installer. Six mois plus tard, l'équipe a un serveur d'intégration et toujours le même problème.

Le symptôme, pas la cause

Le vrai symptôme est simple à reconnaître. Demandez à un développeur ce qui se passe si le service qu'il vient de livrer tombe à 2 h du matin. S'il répond « je ne sais pas, c'est l'infra qui gère », vous n'avez pas un problème d'outillage.

Tant que la personne qui écrit le code ne subit jamais les conséquences de ce qu'elle livre, elle n'a aucune raison de rendre son service observable, redémarrable ou tolérant à la panne. Ce n'est pas de la négligence : c'est une boucle de retour absente.

Les trois changements qui comptent

1. L'équipe qui écrit le service le porte. Pas seule, pas sans astreinte organisée, mais elle est dans la boucle. Le premier réflexe change dès la première alerte reçue.
2. La mise en production cesse d'être un événement. Si livrer demande une réunion, un créneau et trois validations, l'équipe livrera rarement et gros. Les gros lots sont exactement ce qui casse.
3. L'infrastructure est du code relu. Un serveur configuré à la main est un serveur que personne ne sait reconstruire. Le jour où il faut le refaire, c'est une nuit de travail au lieu d'une commande.

Ce que cela n'est pas

Ce n'est pas supprimer les administrateurs système. Les compétences réseau, stockage et sécurité ne se dissolvent pas parce qu'on a écrit un fichier de configuration. Ce qui change, c'est leur rôle : construire les rails que les équipes produit empruntent, plutôt qu'exécuter des tickets de déploiement.

Ce n'est pas non plus un projet avec une date de fin. Il n'y a pas de moment où le DevOps est « terminé ».

Par où commencer

Prenez un seul service, celui qui vous réveille le plus souvent. Donnez-en la responsabilité à l'équipe qui l'écrit, mettez ses journaux et ses alertes là où cette équipe les verra, et automatisez sa mise en production de bout en bout. Mesurez le délai entre un commit et sa présence en production, avant puis après.

C'est le seul chiffre qui vous dira si quelque chose a changé.