Accueil / Tech News / Réorganiser une DSI sans créer une guerre de territoires

Réorganiser une DSI sans créer une guerre de territoires

Illustration originale — Réorganiser une DSI sans créer une guerre de territoires

Illustration originale issue des IA Ariane, avec provenance vérifiée.

Situation illustrative : le directeur général demande au DSI de « simplifier l’organisation » après plusieurs retards. L’infrastructure dépend d’un responsable historique, les applications sont réparties par métiers, la cybersécurité peut bloquer une mise en production et l’équipe ERP négocie avec son intégrateur. Sur l’organigramme, le remède paraît évident : regrouper, renommer, déplacer. Dans la réalité, chaque flèche modifie un droit de décider ou un accès au budget. Traiter la réorganisation comme un exercice de dessin déclenche alors une guerre de territoires.

Le conflit ne porte pas sur les cases, mais sur les décisions

Deux équipes peuvent coopérer avec des rattachements imparfaits si elles savent qui arbitre. Une structure élégante échoue lorsque plusieurs responsables pensent posséder la même décision. Qui priorise une correction ERP face à une évolution commerciale ? Qui accepte le risque résiduel d’une dérogation de sécurité ? Qui choisit entre prolonger un contrat d’infogérance et réinternaliser une compétence ? Tant que ces questions restent implicites, le conflit demeure.

Le dirigeant IT part donc des décisions contestées, non des intitulés. Il recense les objets qui déclenchent des escalades : architecture, capacité, budget, données, fournisseurs, mise en production et risques. Pour chacun, il distingue proposition, instruction, arbitrage et exécution. Cette cartographie révèle les chevauchements sans désigner prématurément un coupable.

Fixer le mandat avant de déplacer les responsabilités

Une réorganisation échoue souvent parce que son objectif reste ambigu. Réduire les délais, maîtriser les coûts, renforcer la sécurité et rapprocher l’IT des métiers sont des finalités légitimes, mais elles ne conduisent pas aux mêmes choix. Si tout est prioritaire, chaque responsable défendra son périmètre au nom d’un objectif différent.

Le DSI doit obtenir un mandat explicite : quels résultats, quelles contraintes non négociables et quels arbitrages réellement délégués ? Cette clarification écarte la fausse promesse de consensus. Certaines décisions réduiront l’autonomie locale ; il faut préciser ce qui sera centralisé, ce qui restera fédéré et selon quelle règle une exception sera accordée.

Concevoir l’organisation à partir des flux de travail

L’étape suivante consiste à suivre des flux critiques de bout en bout : restaurer un service, corriger une vulnérabilité, livrer une évolution ERP, engager une dépense ou traiter une demande métier. À chaque relais, le DSI recherche l’attente, la double validation, le contrôle tardif et la décision sans compétence suffisante.

Il peut alors choisir un modèle adapté à chaque flux. La sécurité définit des exigences et contrôle leur application, mais ne doit pas devenir le chef de projet de toutes les corrections. Une équipe produit peut prioriser son carnet, mais ne doit pas engager seule une dépendance d’infrastructure. L’architecture peut fixer des standards, à condition d’offrir une voie d’exception rapide et documentée. Le compromis utile n’est donc ni la centralisation totale ni l’autonomie absolue : c’est une autonomie bornée par des décisions attribuées et des seuils d’escalade connus.

Installer les responsabilités sans créer une bureaucratie

Le RACI formalise qui réalise, répond du résultat, est consulté ou informé. Il ne crée ni mandat ni courage managérial. Une case ne résout rien si deux comités conservent un veto ou si le responsable ne maîtrise ni budget ni ressources.

Pour chaque décision critique, une fiche courte suffit : résultat attendu, responsable final, contributeurs obligatoires, délai de décision, critères d’escalade et trace à conserver. Le DSI teste ensuite le dispositif sur des cas récents, sans rejouer les conflits de personnes. Si une demande urgente de dérogation arrive, qui instruit les options ? Qui accepte le risque ? Dans quel délai ? Quand l’exception expire-t-elle ? Une réponse précise vaut davantage qu’un organigramme commenté pendant des semaines.

Séquencer le changement pour préserver l’exploitation

Le passage à la nouvelle organisation doit être traité comme une bascule opérationnelle. D’abord, le DSI gèle les modifications non indispensables sur les responsabilités concernées, avec une date de sortie. Ensuite, il publie les nouvelles règles de décision et nomme les titulaires ainsi que leurs relais. Puis il organise une courte période de transition durant laquelle les dossiers en cours conservent un propriétaire explicite. Enfin, il ferme les anciennes instances devenues redondantes ; les laisser survivre entretiendrait une autorité parallèle.

Cette séquence évite qu’un fournisseur reçoive deux instructions ou qu’une équipe attende un comité supprimé. Elle impose aussi de traiter changement de rôle, perte de périmètre, compétence manquante et charge transférée. Sinon, ces effets réapparaîtront sous forme de contournements.

Mesurer la qualité des arbitrages, pas l’agitation

Les indicateurs doivent montrer si l’organisation décide mieux. Le DSI peut suivre le délai entre demande et arbitrage, la part des décisions réouvertes, le nombre d’exceptions arrivées à expiration sans réexamen, les incidents liés à un passage de relais et les escalades dont le responsable final était introuvable. Il observe aussi les travaux engagés avant validation et les dossiers recevant des consignes contradictoires.

Ces mesures ne sont pas un palmarès. Elles repèrent une règle trop lente, une délégation fictive ou une instance contournée. Réduire les réunions n’est pas un succès si les décisions migrent vers des échanges privés impossibles à auditer.

Arbitrer clairement ce qui doit rester disputé

Les erreurs les plus coûteuses sont prévisibles : annoncer les personnes avant les règles, confondre consultation et codécision, multiplier les comités pour ménager chacun, imposer un gel sans échéance ou faire remonter tous les choix au DSI. Ce dernier comportement donne une impression de reprise en main, puis transforme le dirigeant en goulot d’étranglement.

L’arbitrage final doit répondre à une question simple : où l’entreprise accepte-t-elle la diversité, et où exige-t-elle une décision unique ? Les pratiques locales peuvent varier tant qu’elles respectent les seuils de sécurité, de coût et d’interopérabilité. En revanche, la responsabilité d’un risque, d’un engagement fournisseur ou d’une mise en production ne peut rester partagée au point de devenir introuvable. C’est ici que l’approche de DSI en crise est pertinente : reprendre le contrôle signifie rétablir des responsabilités vérifiables, pas occuper tout le terrain. Une DSI pacifiée n’est pas une DSI sans désaccord ; c’est une DSI où le désaccord aboutit, dans un délai connu, à une décision exécutable.

Pour approfondir

Ouvrage : DSI EN CRISE: Reprendre le contrôle de l’IT, des ERP et des grands programmes — Amazon

Ouvrage : Révolution Numérique !: Le guide pour comprendre, décider et agir dans l’entreprise numérique — Amazon

Consulter la référence

Consulter la référence

#ManagementDeTransition #DSI #DirectionDeTransition #GuyDeLussigny #TransformationNumerique

Répondre

Traduction