CTO en environnement multi-sites : passer du régional au national sans casser le RUN

La plupart des transformations IT échouent pour une raison simple : elles confondent l’ambition avec la mécanique. Sur le papier, passer d’une organisation régionale à un modèle national semble rationnel. Mutualiser, standardiser, industrialiser, négocier mieux, sécuriser mieux. Dans la réalité, l’entreprise multi-sites est un organisme nerveux : des centaines de points de présence, des équipes locales qui “tiennent” le quotidien, des habitudes qui compensent des failles, et une exploitation qui ne pardonne pas. Le jour où l’on centralise trop vite, ce n’est pas seulement un organigramme qu’on déplace, c’est le RUN qu’on fragilise.

Le passage du régional au national ne se gagne pas avec des slides. Il se gagne avec des arbitrages clairs, un operating model tenable, et une discipline documentaire qui rend l’IT lisible. C’est l’esprit “One IT / One Doc” : une seule manière de piloter, une seule vérité opérationnelle, une seule mémoire de l’entreprise. Pas pour faire joli, mais pour pouvoir tenir le service, partout, tout le temps.

Le piège classique : centraliser l’autorité sans centraliser la maîtrise

Dans les modèles régionaux, l’IT vit souvent sur un équilibre implicite. Les responsables locaux connaissent le terrain, les utilisateurs, les bâtiments, les “petits” fournisseurs, les contraintes réelles. Ils compensent, contournent, bricolent parfois, mais ils garantissent une continuité. Quand un siège décide de centraliser, il prend en général la main sur la décision, les budgets, les outils, les contrats. Très bien. Mais s’il ne prend pas en même temps la main sur la maîtrise opérationnelle, il crée un vide.

Ce vide se traduit immédiatement : escalades qui explosent, tickets qui stagnent, décisions prises loin du terrain, promesses de standardisation qui se heurtent aux exceptions, et surtout, perte de confiance des sites. À partir de là, chaque incident devient politique. Le RUN, qui devrait rester technique et industriel, se transforme en conflit d’interprétation : “avant, on savait faire”, “au siège, ils ne comprennent pas”, “on nous impose des outils”, “on nous retire nos moyens”.

La centralisation doit donc être conçue comme une reconfiguration de responsabilités, pas comme une prise de pouvoir. Si l’entreprise ne le comprend pas, elle centralise le contrôle et décentralise la colère.

Le RUN n’est pas un poste de dépense, c’est une promesse tenue

Le RUN est souvent décrit comme un coût à réduire. C’est une erreur de cadrage. Le RUN est une promesse de disponibilité, de sécurité et de productivité. Dans un environnement multi-sites, cette promesse vaut plus qu’ailleurs : une indisponibilité locale peut devenir une perte immédiate de chiffre, un blocage opérationnel, une dégradation de qualité, ou une tension sociale. Le RUN, c’est la continuité du réel.

Passer au national sans casser le RUN exige d’accepter une vérité : on ne transforme pas un système en production comme on restructure un organigramme. Il faut conserver une capacité locale, mais la mettre au service d’un modèle commun. Ce n’est pas un paradoxe, c’est une architecture : le local exécute, le national gouverne, et l’ensemble s’aligne sur des standards qui protègent la qualité.

Standardiser ne veut pas dire uniformiser, mais choisir ce qui doit être identique

La standardisation échoue lorsqu’elle cherche à tout rendre pareil. Une entreprise multi-sites n’est pas homogène : bâtiments, réseaux, historiques applicatifs, contraintes métiers, maturité des équipes, partenaires locaux. Vouloir uniformiser intégralement, c’est fabriquer de la résistance. La bonne approche consiste à définir ce qui doit être strictement identique parce que cela sécurise et industrialise, et ce qui peut rester variable parce que cela n’impacte pas la maîtrise.

Les domaines où l’identique est non négociable sont connus : identité et accès, poste de travail, cybersécurité, sauvegardes, supervision, référentiels, ITSM, procédures de crise, chaîne de support, gestion des changements. Ce sont des fondations. Si elles diffèrent par région, le national devient ingérable. À l’inverse, certains éléments peuvent tolérer une marge locale, à condition d’être documentés et gouvernés : contraintes d’infrastructure de site, spécificités de flux, particularités réglementaires, environnement physique.

Ce travail n’est pas un exercice théorique. C’est une série d’arbitrages assumés. Et ces arbitrages doivent être exprimés comme des règles simples, comprises par les sites : voilà ce qui est standard, voilà ce qui est adaptable, voilà qui décide, voilà comment on déroge, voilà ce que ça coûte.

“One IT / One Doc” : la discipline qui évite la transformation à l’aveugle

Dans les organisations multi-sites, la perte de contrôle vient souvent d’un problème banal : l’information n’est pas au même endroit, pas au même format, pas à jour, ou pas fiable. Les connaissances sont dans la tête de quelques personnes. Les procédures sont des PDF introuvables. Les configurations réelles ne correspondent plus aux schémas. Les contrats sont connus par un petit cercle. Et quand un incident majeur arrive, on découvre que la vérité est fragmentée.

“One IT / One Doc” n’est pas un slogan de documentation. C’est un operating system. Un référentiel unique des services, des standards, des procédures, des décisions, des architectures, des fournisseurs, des responsabilités. Un endroit où l’on sait comment on opère, comment on change, comment on escalade, comment on sécurise, comment on rétablit. L’objectif n’est pas de produire des documents, mais de rendre l’IT pilotable et transmissible.

Ce point est crucial en centralisation : le national ne peut pas gouverner ce qu’il ne voit pas. Et il ne peut pas industrialiser ce qu’il ne décrit pas.

L’operating model : la question qui décide du succès

Le passage au national se joue dans un mot souvent négligé : operating model. Qui fait quoi, où, avec quel mandat, avec quels outils, avec quels KPI, avec quel budget, avec quel droit d’arbitrage. Tant que ce modèle est flou, les régions continuent de faire “comme avant”, le siège pense que “c’est en cours”, et la friction augmente.

Un operating model solide dans un multi-sites assume généralement une logique en trois couches. Une gouvernance nationale qui fixe les règles, arbitre les priorités, tient l’architecture et la sécurité, pilote les fournisseurs stratégiques. Un niveau “run factory” qui industrialise l’exploitation, la supervision, le support N1/N2, les changements, la base de connaissances. Et une présence locale, plus légère, orientée proximité et exécution, capable d’absorber la réalité terrain et de garantir la réactivité sur les sites.

Le point clé, c’est la frontière. Ce qui reste local doit être précisément défini, sinon le local redevient un SI parallèle. Et ce qui devient national doit être réellement opéré, sinon le national devient une coquille administrative.

Arbitrer, c’est renoncer, et c’est ce que le siège hésite à faire

L’échec le plus fréquent tient à la peur d’arbitrer. On veut ménager tout le monde. On garde les exceptions. On accepte les “encore un outil”, “encore un fournisseur”, “encore une procédure régionale”. Puis on s’étonne que l’ensemble soit ingérable. La centralisation sans renoncements est une centralisation de façade.

Un CTO en environnement multi-sites doit imposer une hiérarchie. Une pile standard. Un modèle cible compréhensible. Une trajectoire. Et surtout, la capacité de dire non, vite, et de manière argumentée. Dire non à une exception non justifiée. Dire non à un achat local hors cadre. Dire non à une intégration fragile. Dire non à un “projet” qui n’a pas de valeur claire. Ce sont ces “non” qui protègent le RUN, parce qu’ils protègent la cohérence.

L’arbitrage ne doit pas être vécu comme une domination, mais comme une protection : protection du service, de la sécurité, des coûts, et des équipes.

Ne pas casser le RUN : la méthode du double rythme

Le passage au national doit accepter un double rythme. Un rythme d’exploitation qui reste stable, prévisible, sécurisant, avec des changements maîtrisés, des fenêtres connues, et une capacité de retour arrière. Et un rythme de transformation qui avance, mais sans faire porter son risque sur la production.

La bonne approche consiste à stabiliser d’abord ce qui donne de l’air. Standardiser le poste, l’identité, l’ITSM, la supervision, les sauvegardes, la chaîne de support. Puis seulement accélérer. Quand ces fondations sont en place, la centralisation devient une simplification, pas une agression.

Le vrai test : la confiance des sites et la lisibilité des engagements

À la fin, un modèle national est jugé sur une question très simple : est-ce que les sites vivent mieux qu’avant ? Pas en théorie, en pratique. Est-ce que les incidents sont pris plus vite ? Est-ce que les demandes sont traitées avec des délais clairs ? Est-ce que la sécurité est plus forte sans être plus pénible ? Est-ce que les changements sont mieux maîtrisés ? Est-ce que les utilisateurs comprennent où s’adresser, et ce qu’ils peuvent attendre ?

La centralisation réussie est celle qui rend le service plus prévisible. Le régional était souvent réactif mais artisanal. Le national doit être industriel mais humain. C’est ce mélange qui fait gagner : une machine qui tient, et une proximité qui écoute.

CTA : structurer une direction technique capable de délivrer

Passer du régional au national sans casser le RUN n’est pas un projet, c’est une conduite. Cela exige une direction technique structurée, un operating model clair, des arbitrages assumés, une discipline “One IT / One Doc”, et une obsession de la continuité de service.

Je suis DSI/CTO de transition. J’accompagne les organisations multi-sites dans la structuration de leur direction technique, la centralisation pragmatique, la standardisation utile, la reprise en main du RUN, et la remise sous contrôle des programmes et des fournisseurs.

Je suis disponible pour une nouvelle mission : guy@de-lussigny.com : 06 45 90 40 79