Du build au run : pourquoi celui qui code doit aussi opérer

Dans l'industrie du logiciel, un modèle domine : d'un côté ceux qui construisent, de l'autre ceux qui exploitent. On conçoit, on livre, on passe le relais, et une autre équipe prend en charge la vie du système en production. Ce découpage paraît rationnel. En pratique, sur des systèmes critiques, il produit des résultats prévisibles, et rarement bons.

L'équipe qui construit optimise pour la livraison et la démonstration, pas pour la nuit de garde. L'équipe qui exploite hérite d'un système qu'elle n'a pas conçu et qu'elle découvre en production, souvent au pire moment. Entre les deux, le client paie la facture des incidents. Faire l'inverse, c'est-à-dire faire opérer le système par ceux qui l'ont conçu, n'est pas un détail d'organisation. Cela change la nature même de ce qu'on produit.

Le modèle dominant, et son défaut

La séparation du build et du run s'est imposée parce qu'elle semble efficace : des spécialistes de la construction, des spécialistes de l'exploitation, chacun son métier. Le problème est le point de jonction. Au moment du transfert, une masse de contexte se perd : les hypothèses implicites, les fragilités connues, les raisons derrière tel choix. L'équipe de run reçoit un système, pas la compréhension qui va avec.

Ce transfert imparfait a un coût qui n'apparaît que plus tard, en production. Le premier incident sérieux révèle ce qui n'a pas été transmis. On découvre les angles morts au plus mauvais moment, sous pression, avec un utilisateur qui attend. La séparation paraît économique sur le papier, mais elle déporte le coût là où il fait le plus mal.

Optimiser pour la démo ou pour la nuit de garde

Le fond du problème est une affaire d'incitations. Quand on construit sans avoir à exploiter, on optimise naturellement pour ce qui se voit : la fonctionnalité, la démonstration, la date de livraison. Ce qui ne se voit pas, la supervision, la reprise sur incident, la dégradation maîtrisée, passe au second plan, parce que personne dans l'équipe de build n'en paiera le prix.

À l'inverse, quand on sait que l'on sera de garde, les priorités changent d'elles-mêmes. On se demande non seulement « est-ce que ça marche ? » mais « qu'est-ce qui se passe quand ça casse, et qui le verra ? ». Cette question, posée pendant la conception et non après, oriente des dizaines de petites décisions vers la robustesse plutôt que vers l'effet.

Celui qui sera réveillé code différemment

C'est l'idée centrale : on ne conçoit pas de la même façon selon que l'on porte ou non la responsabilité de l'exploitation. Celui qui sait qu'il sera réveillé à trois heures du matin si le système tombe intègre, sans même y penser, la supervision, les alertes, les mécanismes de reprise. Il évite la complexité inutile, parce que c'est lui qui devra la débrouiller en pleine nuit.

Cette responsabilité produit des systèmes plus simples et plus robustes, non par vertu mais par intérêt bien compris. La simplicité cesse d'être un principe abstrait pour devenir une stratégie de survie. Le code que l'on opère soi-même est, presque mécaniquement, du meilleur code : plus sobre, mieux instrumenté, conçu pour être compris vite sous pression.

Pas d'écran entre vous et l'ingénierie

Pour le client, ce modèle a une conséquence directe : il n'y a plus d'écran entre lui et l'ingénierie. Celui qui répond est celui qui conçoit et qui opère, pas une couche commerciale qui relaie des messages vers une équipe lointaine. Quand un problème survient, l'information remonte sans déperdition et la décision se prend au bon niveau, par des gens qui comprennent réellement le système.

Cette absence d'intermédiaire raccourcit tout : le temps de compréhension, le temps de correction, le temps de réponse. Elle supprime aussi le jeu de renvoi de responsabilité entre celui qui a construit et celui qui exploite, puisque c'est la même équipe. Sur un système critique, cette continuité de responsabilité vaut plus que n'importe quel engagement contractuel.

Le run nourrit le build

Il y a enfin un bénéfice plus discret : opérer rend meilleur pour construire. Voir le système vivre, encaisser des pics, tomber et se relever, enseigne des choses qu'aucune phase de conception ne peut anticiper. Chaque incident est une leçon qui remonte directement dans la façon de concevoir la version suivante. Le run devient une source d'apprentissage, pas seulement une charge.

Cette boucle entre la conception et l'exploitation est vertueuse. Ceux qui construisent apprennent en continu de la réalité de la production, et ceux qui opèrent comprennent le système de l'intérieur. Séparer les deux, c'est couper cette boucle, et se priver de l'apprentissage le plus précieux qui soit : celui de la production réelle.

Le revers : ce que ce modèle exige

Faire opérer ceux qui construisent n'est pas gratuit, et ce n'est pas pour tout le monde. Le modèle exige des profils capables d'assumer les deux rôles, donc de la séniorité. On ne met pas un débutant d'astreinte sur un système critique : la pression d'un incident en production, la nuit, ne pardonne pas l'inexpérience. Cette exigence de compétence est le prix d'entrée du modèle.

Il demande aussi un engagement que tout le monde n'est pas prêt à prendre. Accepter d'être responsable de ce qu'on livre, sur la durée, jusqu'à l'astreinte, change le rapport au travail. C'est plus exigeant qu'une logique de projet où l'on passe à la suite une fois la livraison faite. Mais c'est précisément cette exigence qui sélectionne les équipes capables de tenir l'infrastructure critique.

Un engagement, pas un slogan

Du build au run, ce n'est pas une formule pour une plaquette. C'est un engagement concret : celui qui vous répond est celui qui a conçu votre plateforme et qui l'opère. C'est ce qui aligne les intérêts, supprime les intermédiaires, et produit des systèmes faits pour durer en production, pas seulement pour bien paraître en démonstration.

C'est aussi un choix exigeant, car il interdit de livrer puis de disparaître. Mais c'est précisément cette exigence qui fait la différence sur l'infrastructure critique. On opère ce qu'on construit, parce que c'est la seule manière honnête de répondre, vraiment, de ce que l'on a livré.