La cartographie des dépendances humaines avant celle des applications

Illustration originale réalisée avec OpenAI GPT Image 2.5 Flare via Picsart ; provenance du fichier contrôlée.

La cartographie des dépendances humaines avant celle des applications

Le vendredi où personne ne sait décider

Situation illustrative : un vendredi à 16 heures, l’interface entre l’ERP et la plateforme logistique cesse d’alimenter les expéditions. Les applications sont supervisées, les contrats sont accessibles et le comité de crise est réuni. Pourtant, rien n’avance. L’administrateur qui connaît le traitement de reprise est absent. Le prestataire attend l’accord d’une responsable métier injoignable. Le directeur de programme ignore qui peut accepter un envoi dégradé. La panne technique existe, mais l’arrêt opérationnel vient surtout d’une chaîne humaine invisible.

Pour un DSI, un RSSI ou un dirigeant de transition, la première question n’est donc pas seulement « de quelles applications dépendons-nous ? ». Elle est : « de qui dépend chaque décision permettant de maintenir, dégrader ou rétablir le service ? ». Une cartographie applicative sans cette réponse décrit le système sans révéler sa capacité réelle d’action.

Le mécanisme caché derrière le point unique de défaillance

Une dépendance humaine critique apparaît lorsqu’une personne concentre un savoir, un droit, une relation ou un pouvoir d’arbitrage sans relais immédiatement mobilisable. Elle peut être technique — un script compris par un seul expert —, organisationnelle — une validation réservée à un manager —, contractuelle — un fournisseur qui ne répond qu’à son interlocuteur habituel — ou politique — un désaccord que personne d’autre n’est autorisé à trancher.

Ces fragilités se renforcent mutuellement. Une interface développée dans l’urgence, hors du comité d’architecture, peut fonctionner pendant des mois. Puis son auteur change d’équipe, la documentation reste sommaire et le métier découvre qu’un contournement manuel exige l’accord de trois responsables. Le composant n’est plus seulement une dette technique : il devient une dépendance humaine composite, difficile à voir dans un inventaire de logiciels.

Cartographier les décisions avant les composants

Le dirigeant commence par quelques processus dont l’interruption menace concrètement l’activité : facturer, livrer, payer, produire, authentifier les utilisateurs ou traiter un incident de sécurité. Pour chacun, il identifie le service numérique support, puis pose cinq questions : qui détecte l’anomalie, qui qualifie sa gravité, qui décide du mode dégradé, qui exécute la reprise et qui confirme le retour à la normale ?

Chaque réponse doit comporter un titulaire, un suppléant, un délai de mobilisation, les accès nécessaires et un critère de décision. « L’équipe infrastructure » ou « le prestataire ERP » ne désigne pas un responsable opérant. Il faut un rôle nommé, une capacité vérifiée et une escalade connue. Ensuite seulement, on relie ces acteurs aux applications, données, infrastructures et fournisseurs concernés. La carte obtenue ne cherche pas l’exhaustivité : elle rend visibles les ruptures possibles de commandement et d’exécution.

Tester la carte contre la réalité

Un organigramme ne prouve ni la disponibilité ni la compétence opérationnelle. La cartographie doit donc être confrontée à des tests courts : joindre le suppléant, retrouver la procédure, vérifier l’accès à la console, simuler une décision de bascule, demander au fournisseur son point de contact d’escalade. Le but n’est pas d’organiser un exercice spectaculaire, mais de transformer des suppositions rassurantes en preuves utilisables.

Quatre indicateurs suffisent pour piloter la première version : part des processus critiques disposant d’un décideur et d’un suppléant ; nombre de savoirs essentiels détenus par une seule personne ; délai constaté pour mobiliser la chaîne d’escalade ; proportion des modes dégradés réellement testés. On peut y ajouter les dépendances dont le propriétaire reste contesté. Une tendance importe davantage qu’un score flatteur : chaque ambiguïté supprimée réduit le temps perdu lorsque l’incident survient.

Arbitrer entre vitesse, profondeur et protection

Le compromis central oppose l’urgence à la qualité du diagnostic. Si la facturation est interrompue ou si une exposition de sécurité est avérée, le DSI protège d’abord l’activité : isolement, contournement, mobilisation du fournisseur, décision temporaire. Il n’attend pas une cartographie parfaite. En revanche, il documente au fil de l’action qui savait, qui pouvait décider, quels accès manquaient et où l’escalade s’est bloquée.

Sans danger immédiat, une séquence de deux semaines permet d’avancer méthodiquement : cadrer les décisions attendues, ouvrir un registre de preuves, croiser les entretiens, tester les points critiques, puis présenter les expositions prioritaires au comité de direction. Cette logique rejoint l’approche de DSI EN CRISE : Reprendre le contrôle de l’IT, des ERP et des grands programmes : sécuriser ce qui menace l’activité, établir les faits et remettre les responsabilités au centre.

Éviter les cartes qui rassurent mais ne protègent pas

La première erreur consiste à confondre expert reconnu et dispositif de continuité. Une personne compétente mais indisponible reste une fragilité. La deuxième est de nommer des suppléants sans vérifier leurs droits ni leur pratique. La troisième est d’interroger uniquement les managers : les dépendances réelles se trouvent souvent chez ceux qui exécutent les reprises, surveillent les échanges ou connaissent les arrangements historiques avec un fournisseur.

Autre piège : transformer l’exercice en audit exhaustif. Plus la carte accumule de détails, plus elle risque d’être périmée avant d’être utilisée. Enfin, il faut éviter de « résoudre » le problème par une documentation massive. Un document ne remplace ni une délégation explicite, ni un accès testé, ni un arbitrage accepté par les métiers.

Décider ce qui doit cesser de dépendre d’une personne

L’arbitrage final ne vise pas à supprimer toute expertise individuelle, objectif irréaliste et contre-productif. Il consiste à distinguer trois cas. Certaines dépendances peuvent être acceptées temporairement, avec une surveillance et une date de réduction. D’autres exigent un transfert de compétence, une double habilitation, une procédure de relève ou une renégociation contractuelle. Les plus dangereuses imposent une décision immédiate : retirer un veto informel, désigner un responsable unique, tester le mode dégradé ou suspendre une mise en production.

La bonne carte n’est donc pas celle qui représente le mieux le patrimoine applicatif. C’est celle qui permet au dirigeant de répondre, avant l’incident : qui décide, avec quelles preuves, dans quel délai et selon quelle solution de repli ? Lorsque ces réponses existent, la cartographie technique devient enfin actionnable. Lorsqu’elles manquent, même l’architecture la mieux documentée peut rester paralysée par une absence, un silence ou une autorité mal placée.

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