Piloter plusieurs sites quand la décision reste centralisée

7 novembre 2026

Le lundi où tout remonte au siège

Situation illustrative : à 7 h 20, un site logistique signale que l’interface entre l’ERP et l’outil d’expédition ne transmet plus les ordres. Le directeur local peut interrompre les départs, mais pas autoriser un fonctionnement dégradé ; le DSI régional peut mobiliser le support, mais pas modifier la priorité des clients ; le RSSI peut refuser une extraction non sécurisée, mais pas décider quelles commandes attendre. À 9 heures, personne n’a pris la décision complète. C’est une centralisation conçue pour maîtriser les risques, devenue incapable de trancher au rythme des opérations.

La centralisation fabrique une dette de décision

Dans une organisation multisite, le siège centralise souvent les budgets, les standards ERP, la cybersécurité, les fournisseurs et les changements structurants. Elle se dégrade lorsque toute exception locale emprunte le même circuit qu’une décision irréversible. Une panne limitée, un écart de données ou un retard fournisseur remonte alors plusieurs étages, avec des informations reformulées à chaque passage. Le délai d’arbitrage augmente tandis que la responsabilité se dilue.

Le dirigeant IT doit distinguer trois objets : la règle commune, l’écart constaté et la décision opérationnelle immédiate. Le siège possède la première. Le site doit documenter le deuxième. La troisième revient à celui qui supporte réellement la conséquence métier, dans des limites définies à l’avance. Sans cette séparation, l’IT finit par décider à la place de l’exploitation, ou l’exploitation contourne l’IT pour tenir ses engagements.

Cartographier les décisions, pas seulement les applications

La première étape n’est pas de refaire l’organigramme ni de lancer un nouvel outil de ticketing. Il faut établir un registre court des décisions qui bloquent régulièrement l’activité : suspendre une production, basculer vers une procédure manuelle, accepter une donnée provisoire, décaler un déploiement, isoler un équipement, prévenir certains clients. Pour chaque décision, cinq éléments suffisent : déclencheur observable, décideur nommé, délai maximal, preuves nécessaires et limite d’autorité.

Cette cartographie révèle les responsabilités ambiguës. Un responsable peut être « consulté » sur le papier alors que son accord est indispensable dans les faits. À l’inverse, un comité peut être déclaré décisionnaire sans être disponible dans le délai utile. Le registre doit donc séparer fait vérifié, hypothèse, conséquence métier et question ouverte. Trente décisions bien qualifiées valent davantage qu’un inventaire exhaustif impossible à exploiter en comité.

Donner aux sites une autonomie bornée

Décentraliser ne signifie ni abandonner le core model ni laisser chaque établissement créer ses propres règles. Il s’agit d’accorder une autonomie conditionnelle. Un site peut, par exemple, activer un mode dégradé pour un périmètre prioritaire, pendant une durée fixée, avec des données contrôlées et une trace des opérations. Il ne peut pas étendre silencieusement cette dérogation, modifier une règle de sécurité ou transformer l’exception en procédure permanente.

Le DSI définit les conditions techniques et la réversibilité. Le RSSI fixe les interdits non négociables et les mesures compensatoires acceptables. L’exploitation choisit ce qui doit partir, attendre ou être communiqué au client. La finance éclaire l’exposition économique sans confondre coût déjà engagé, engagement contractuel et reste à faire. Cette répartition évite deux erreurs symétriques : faire porter au site un risque qu’il ne peut évaluer, ou confier au siège une décision qu’il ne peut prendre assez vite.

Installer un rythme d’arbitrage adapté

Toutes les décisions ne justifient pas une réunion de crise. Le dispositif peut fonctionner sur trois cadences. En temps réel, une cellule réduite traite les événements qui menacent la continuité, avec un décideur métier et un décideur IT identifiés. Chaque semaine, un point multisite examine les exceptions répétées, les dépendances critiques et les décisions arrivant à échéance. Chaque mois, la direction tranche les écarts structurels : capacité supplémentaire, évolution du core model, changement de fournisseur ou investissement de résilience.

Le tableau de pilotage doit rester décisionnel. Quelques indicateurs suffisent : nombre d’arbitrages hors délai, âge des questions ouvertes, taux d’exceptions prolongées, incidents récurrents sur une même dépendance, décisions prises sans preuve attendue et écarts locaux sans propriétaire. La moyenne globale peut masquer un site durablement fragile ; les données doivent donc rester lisibles par établissement, processus et dépendance commune.

Refuser les faux remèdes

La première erreur consiste à ajouter un niveau de validation après chaque incident. On rassure le siège, mais on allonge le prochain arrêt. La deuxième est d’exiger un consensus entre fonctions dont les responsabilités diffèrent : le RSSI n’a pas à valider une priorité commerciale, pas plus que le directeur de site ne doit accepter seul un risque cyber. La troisième est de mesurer uniquement la disponibilité technique. Un service peut être rétabli tandis que les commandes restent bloquées, les données incohérentes ou les équipes sans consigne utilisable.

Enfin, standardiser les applications ne standardise pas les décisions. Deux sites peuvent partager le même ERP tout en interprétant différemment une unité, un statut ou une règle de validation. Reporter cet arbitrage au « nettoyage des données » déplace un choix industriel vers l’équipe technique. Le désaccord doit recevoir un propriétaire métier, une échéance et une règle provisoire explicite.

L’arbitrage final : cohérence ou vitesse

Le dirigeant n’a pas à choisir définitivement entre pouvoir central et autonomie locale. Il doit décider ce qui mérite une cohérence absolue et ce qui exige une réponse proche du terrain. Les standards de sécurité, l’architecture cible et les engagements majeurs restent centraux. Les priorités opérationnelles, dans un cadre testé et réversible, doivent pouvoir être décidées localement.

C’est aussi la logique de DSI EN CRISE : protéger l’activité, fiabiliser le diagnostic et rétablir les responsabilités avant de prétendre reprendre le contrôle des programmes et des coûts. Dans un groupe multisite, la maîtrise ne se mesure pas au nombre de décisions remontées au siège, mais à la capacité de prendre chaque décision au bon niveau, avec assez de preuves, dans le temps réellement disponible.