RUN vs BUILD : le faux dilemme (et comment éviter la guerre civile IT)

Dans de nombreuses directions informatiques, la fracture est devenue familière. D’un côté, le RUN, sommé d’assurer la stabilité, la disponibilité, la sécurité, coûte que coûte. De l’autre, le BUILD, poussé à livrer toujours plus vite, à transformer, innover, digitaliser. Entre les deux, une tension permanente, parfois larvée, parfois ouverte. Priorités contradictoires, ressentiments, accusations croisées : « vous bloquez l’innovation » contre « vous mettez la prod en danger ». Le RUN contre le BUILD. Un faux dilemme devenu une vraie guerre civile IT.

Un clivage hérité, mais mal posé

Historiquement, la séparation RUN / BUILD avait du sens. Elle permettait de structurer les responsabilités, de professionnaliser l’exploitation d’un côté, la conduite de projets de l’autre. Mais ce modèle, figé, ne résiste plus à la réalité des systèmes d’information modernes.

Les architectures sont devenues hybrides, interconnectées, souvent fragiles. Les cycles projets se sont raccourcis. Les métiers attendent des évolutions continues, pas des « big bang » tous les cinq ans. Dans ce contexte, opposer RUN et BUILD revient à découper artificiellement un continuum qui ne devrait jamais être rompu.

Un incident majeur aujourde’est plus rarement « un problème d’exploitation pure ». Il est souvent le résultat d’un choix de conception, d’une dette accumulée, d’un compromis projet mal arbitré. Inversement, un projet qui dérape le fait souvent parce que le RUN n’a pas été intégré dès le départ.

Le vrai sujet : le modèle opératoire

Le problème n’est donc pas le RUN, ni le BUILD. Le problème, c’est le modèle opératoire. Qui décide des priorités ? Sur quels critères ? Comment arbitre-t-on entre stabilité immédiate et transformation nécessaire ?

Dans beaucoup d’organisations, le RUN est jugé sur des indicateurs de disponibilité et de coûts, tandis que le BUILD est évalué sur des délais et des livrables. Deux systèmes d’objectifs qui s’ignorent, voire se contredisent. Le RUN est incité à refuser le changement, le BUILD à le forcer. La guerre est inscrite dans la gouvernance elle-même.

Un modèle opératoire mature part d’un principe simple : la stabilité est un prérequis de la transformation, et la transformation est une condition de la stabilité future. Les deux sont indissociables.

ITIL et SRE : sortir du dogme, entrer dans le pragmatisme

Trop souvent, les débats RUN vs BUILD se crispent autour des méthodes. ITIL serait synonyme de lourdeur, de procédures, de lenteur. Le SRE serait l’apanage des environnements modernes, agiles, orientés produit. Cette opposition est aussi caricaturale que stérile.

ITIL, appliqué de manière pragmatique, apporte un cadre indispensable : gestion des incidents, des problèmes, des changements, des actifs. Il permet de rendre visible le coût réel de l’instabilité et de structurer la décision. Le SRE, de son côté, introduit une culture précieuse : l’automatisation, la mesure de la fiabilité, la notion de budget d’erreur, la responsabilité partagée entre conception et exploitation.

Les organisations qui progressent ne choisissent pas entre ITIL et SRE. Elles les combinent intelligemment. Elles utilisent ITIL pour structurer, sécuriser, rendre pilotable. Elles s’inspirent du SRE pour casser les silos, responsabiliser les équipes produit et intégrer la fiabilité dès le design.

La priorisation, nerf de la paix sociale

La guerre civile IT naît presque toujours d’un défaut de priorisation. Quand tout est prioritaire, plus rien ne l’est. Le RUN éteint des incendies pendant que le BUILD lance de nouveaux chantiers, sans lien explicite entre les deux.

Une priorisation saine repose sur des arbitrages explicites, partagés avec les métiers. Quel est l’impact business d’un incident récurrent ? Quelle est la valeur réelle d’un projet supplémentaire livré ce trimestre ? Quelle dette acceptons-nous de porter, et pour combien de temps ?

Sans ces arbitrages, le RUN est condamné à subir, le BUILD à pousser. Avec eux, la discussion change de nature. On ne parle plus en termes d’équipes ou de périmètres, mais de risques, de valeur et de trajectoire.

La dette technique, grande oubliée des arbitrages

La dette technique est souvent invoquée, rarement traitée. Elle est le symptôme le plus visible du faux dilemme RUN vs BUILD. Chaque contournement projet, chaque mise en production précipitée, chaque exception acceptée « temporairement » alimente une dette que le RUN devra absorber plus tard.

Mais tant que la dette n’est pas rendue visible, chiffrée, priorisée, elle reste un sujet abstrait. Le RUN la subit, le BUILD la crée sans toujours en mesurer les conséquences. Là encore, le problème est moins technique que politique.

Les organisations les plus matures intègrent la dette dans leur pilotage. Elles consacrent une part assumée de leur capacité à la résorber. Elles acceptent de ralentir certains projets pour éviter l’effondrement futur. Ce n’est pas un renoncement, c’est un investissement.

RUN et BUILD : une responsabilité partagée

Sortir du faux dilemme suppose aussi de faire évoluer les rôles. Le RUN ne peut plus être le simple gardien du temple, opposé par principe au changement. Il doit être associé aux choix d’architecture, aux décisions de design, aux arbitrages projets. Le BUILD, de son côté, ne peut plus ignorer les contraintes d’exploitation et se défausser une fois la mise en production effectuée.

La logique produit, lorsqu’elle est bien comprise, va dans ce sens. Une équipe est responsable d’un service de bout en bout, sur la durée. Elle conçoit, elle déploie, elle exploite. Cela ne supprime pas le RUN, mais cela le transforme : moins d’exécution répétitive, plus d’expertise, de support de niveau avancé, d’ingénierie de fiabilité.

Éviter la guerre civile, un enjeu de leadership

Au fond, RUN vs BUILD est un révélateur de maturité managériale. Quand la gouvernance est floue, les équipes s’affrontent. Quand les arbitrages sont implicites, les conflits deviennent personnels. Quand la vision est absente, chacun défend son périmètre.

Éviter la guerre civile IT suppose un leadership clair, capable de poser un modèle opératoire lisible, d’assumer des priorités, de reconnaître les contraintes des deux côtés. Cela suppose aussi d’expliquer, encore et encore, que la stabilité n’est pas l’ennemie du changement, mais sa condition.

Le faux dilemme, la vraie trajectoire

RUN ou BUILD ? La question est mal posée. Le vrai enjeu est de construire une trajectoire où l’IT est à la fois fiable aujourd’hui et capable d’évoluer demain. Où la dette est maîtrisée, pas subie. Où les équipes travaillent ensemble, autour d’objectifs communs, plutôt que face à face.

Stabiliser sans transformer mène à l’obsolescence. Transformer sans stabiliser mène au chaos. La seule voie viable est celle de l’équilibre assumé, piloté, arbitré.

Vous êtes confronté à des tensions RUN / BUILD, à une dette qui explose, à des priorités impossibles à tenir ? Le sujet n’est pas de choisir un camp, mais de refonder le modèle. Stabilisation et transformation ne s’opposent pas : elles se construisent ensemble.