Run vs Change : arrêter la guerre interne et financer la transformation

Le conflit le plus coûteux de la DSI

Dans beaucoup d’organisations, la transformation ne cale pas parce que la stratégie est mauvaise. Elle cale parce qu’une guerre larvée consomme l’énergie : Run vs Change. D’un côté, l’exploitation se bat pour tenir la production, éviter l’incident majeur, répondre aux tickets, gérer les astreintes, absorber les urgences. De l’autre, les équipes projets veulent livrer, moderniser, migrer, sécuriser, industrialiser. Et au milieu, les métiers veulent tout : du service stable et des changements rapides.

Ce conflit est presque toujours structurel. Pas moral. Les gens sont de bonne volonté, mais le système d’incitation est mauvais : le run n’est jamais “fini”, donc il aspire toute la capacité. Le change est toujours “urgent”, donc il pousse à court-circuiter les règles. Puis chacun reproche à l’autre de bloquer. Résultat : incidents + rework + délais + fatigue. Et la transformation devient une promesse perpétuelle.

La sortie par le haut repose sur une idée simple : on ne réconcilie pas le run et le change par un discours. On les réconcilie par un modèle opératoire, des arbitrages explicites, et un portefeuille financé.

Le modèle opératoire : clarifier qui fait quoi, et à quel rythme

La première cause de la guerre interne, c’est le flou. Les mêmes équipes portent le run, les urgences, et les projets, sans règle de capacité. Le modèle opératoire doit rendre deux choses visibles : les responsabilités et la capacité.

Un modèle opératoire efficace commence par définir deux chaînes complémentaires :

La chaîne Run : incident, demande, changement standard, supervision, maintenance, continuité. Elle vise la stabilité, la disponibilité, et la réactivité.

La chaîne Change : évolutions, projets, modernisation, migrations, sécurité structurelle, réduction de dette, rationalisation. Elle vise la valeur future.

Ces deux chaînes doivent parler la même langue, mais ne pas se mélanger. Si tout le monde fait tout, personne ne pilote rien.

Le bon compromis, dans la plupart des contextes, est un mode “produit/plateforme” : une équipe possède un service, et elle répartit explicitement sa capacité entre run et change. Le modèle le plus pragmatique est un pourcentage : par exemple 60% run, 40% change, ou 70/30 selon l’état de santé. L’important n’est pas le chiffre exact, c’est qu’il soit acté, visible, et tenu.

Et quand l’exploitation est très instable ? On assume une phase de stabilisation : on remonte le run à 80–90% temporairement, mais on finance en parallèle la réduction des causes racines. Sinon, on ne sort jamais du cercle vicieux.

L’arbitrage : arrêter les “urgences” qui ne paient pas

Le deuxième carburant de la guerre interne, ce sont les urgences non arbitrées. Tout arrive “prioritaire”. Les métiers escaladent. Les managers poussent. Les équipes subissent. Et le backlog devient une file d’attente où l’ordre est dicté par le bruit.

La solution est brutale mais libératrice : un backlog unique par produit/service, trié, qualifié, et gouverné. On y met tout : incidents majeurs, problèmes, évolutions, dette, sécurité, demandes structurantes. Puis on classe avec des critères métiers : impact financier, risque opérationnel, conformité, fréquence, effort, dépendances.

L’arbitrage devient alors une décision explicite : “Si on prend ça maintenant, on repousse ça.” C’est cette phrase qui manque dans les organisations en guerre. Sans cette phrase, chacun protège son périmètre et le système devient politique.

Un levier très efficace est de limiter le “fast lane”. Par exemple : un quota d’urgences par semaine, ou un circuit d’escalade strict (seul un sponsor peut déclencher un traitement hors plan). Quand l’urgence coûte quelque chose, elle redevient rare. Quand l’urgence est gratuite, elle devient la norme.

Le portefeuille : financer la transformation comme un actif, pas comme un bonus

La transformation échoue aussi parce qu’elle est financée comme un supplément d’âme. On demande aux équipes déjà saturées de “trouver du temps” pour transformer. C’est une illusion. Une transformation non financée, c’est du bénévolat. Et le bénévolat n’est pas un modèle opératoire.

Financer la transformation, ce n’est pas seulement mettre du budget projet. C’est dégager de la capacité. Concrètement, un portefeuille sain distingue trois lignes :

Le portefeuille Run : ce qu’on doit faire pour tenir le service (MCO, support, incidents, demandes récurrentes).

Le portefeuille Change : les évolutions à valeur métier (nouvelles fonctionnalités, déploiements, nouveaux sites, améliorations process).

Le portefeuille Santé : la réduction de dette et de risque (stabilisation, refactoring, modernisation infra, sécurité structurelle, qualité de données, automatisation, observabilité). C’est cette ligne qui est souvent sacrifiée, alors que c’est elle qui réduit le coût du run et libère de la capacité.

La clé est d’acter une règle : un pourcentage minimum de capacité et/ou de budget doit aller à la “santé” du SI. Sinon, le run continue d’augmenter et l’entreprise paye la facture en incidents, en délais, et en stress.

Le mécanisme qui change tout : un rythme de delivery, même petit

Une organisation en guerre vit dans l’improvisation : on livre quand on peut, on déploie quand on est prêt, on corrige quand ça brûle. Pour sortir de ce mode, il faut installer un rythme.

Le release train est un outil simple : une date fixe de livraison (toutes les deux ou quatre semaines), une fenêtre de gel, des critères d’entrée et de sortie, et une revue post-release. Ce mécanisme oblige à anticiper, réduit les déploiements sauvages, et aligne run et change : le run sait quand les changements arrivent, le change sait quelles contraintes respecter.

Ce n’est pas une bureaucratie. C’est un système anti-chaos. Même un train mensuel transforme la dynamique : les équipes cessent de courir après l’instant, et commencent à construire un flux.

La “paix” Run/Change : des contrats internes, pas des opinions

Arrêter la guerre interne, c’est formaliser un contrat simple entre run et change :

Le change s’engage à respecter le cadre de livraison (tests, rollback, communication, fenêtre).

Le run s’engage à fournir les conditions de stabilité et d’observabilité, et à traiter les incidents de manière structurée.

La gouvernance s’engage à arbitrer, à protéger la capacité, et à financer la ligne “santé”.

Et surtout, les métiers s’engagent à prioriser : tout ne peut pas être urgent. C’est la condition de la vitesse durable.

Ce contrat doit être visible. Par exemple via une page “service” par produit : SLA, backlog, roadmap, risques, indicateurs. Quand les règles sont visibles, la discussion devient factuelle. Quand elles ne le sont pas, elle devient émotionnelle.

Les indicateurs qui réconcilient

Les KPI ne doivent pas servir à punir, mais à arbitrer. Quelques indicateurs suffisent :

Pour le run : incidents majeurs, MTTR, respect SLA, taux de récurrence, taux de résolution N1.

Pour le change : lead time, taux d’échec des changements, incidents post-change, throughput par train.

Pour la santé : dette réduite (items clos), automation coverage, observabilité, réduction des contournements, baisse des tickets récurrents.

Le signal le plus puissant, c’est la baisse du rework. Quand le rework baisse, la capacité augmente. Quand la capacité augmente, la transformation s’auto-finance partiellement.

Conclusion : la transformation se finance par la clarté

Le conflit Run vs Change n’est pas une fatalité. C’est le symptôme d’un système non piloté : flou des responsabilités, capacité invisible, urgences gratuites, dette non financée, absence de rythme. La solution n’est pas d’exiger “plus d’effort”. La solution est de changer le système.

Un modèle opératoire clair, des arbitrages explicites, et un portefeuille structuré transforment la guerre en collaboration. Et quand le run cesse d’être un incendie permanent, il ne “bloque” plus le change : il le rend possible. Parce qu’en IT, la vraie vitesse vient rarement de l’héroïsme. Elle vient de la maîtrise.