Votre prestataire tient ses indicateurs, mais votre activité attend toujours

Le rapport du prestataire est rassurant : disponibilité conforme, tickets traités et délais moyens respectés. Pourtant, les équipes métier passent du temps à contourner le service. Un export arrive trop tard, une interface doit être relancée à la main, une demande attend entre deux interlocuteurs. Le contrat peut paraître exécuté alors que l’entreprise ne dispose pas du fonctionnement dont elle a besoin.

Cette situation ne se résout pas forcément en changeant de fournisseur. Elle demande d’abord de rendre visible l’écart entre ce qui est mesuré et ce qui permet réellement de travailler. Pour une direction générale ou un DSI de transition, c’est un chantier de gouvernance autant qu’un sujet technique : décrire le service attendu, attribuer les responsabilités et obtenir des décisions utilisables.

Repartir d’un usage métier vérifiable

Prenons un exemple de travail, sans le présenter comme un cas client : une équipe doit transmettre ses commandes avant une heure limite. Une disponibilité moyenne de l’application ne suffit pas si l’interface de transmission se bloque précisément pendant cette fenêtre. Le service à protéger comprend l’application, les échanges de données, les accès et l’intervention éventuelle d’un opérateur.

Décrivez le parcours de bout en bout. Qui déclenche l’opération ? À quel moment est-elle considérée comme terminée ? Quelle preuve permet de le constater ? Et que se passe-t-il lorsqu’une étape échoue ? Ces questions donnent un langage commun au métier, à la DSI et au prestataire.

Ne cherchez pas immédiatement une liste exhaustive. Choisissez un parcours dont le dysfonctionnement a une conséquence concrète et observable. Vous pourrez ensuite étendre la méthode. Un engagement précis sur une opération importante vaut mieux qu’une accumulation de mesures que personne ne sait relier à l’activité.

Examiner les zones entre les responsabilités

Les incidents deviennent souvent difficiles à traiter lorsqu’ils traversent plusieurs périmètres. Le fournisseur d’application voit son composant fonctionner ; l’hébergeur observe une infrastructure disponible ; le métier constate que le résultat n’arrive pas. Sans responsable du service global, chacun peut avoir raison sur son morceau du problème.

Construisez une carte courte des dépendances et des interlocuteurs. Pour chaque étape, identifiez qui observe, qui intervient et qui arbitre. Il faut également préciser comment l’incident est transmis et à quel moment un désaccord technique remonte vers un décideur.

Cette clarification ne remplace pas le contrat. Elle prépare une discussion utile sur son exécution et, si nécessaire, sur ses évolutions avec les fonctions compétentes. Évitez de traiter une matrice de responsabilités comme une formalité documentaire : faites-la fonctionner sur un scénario d’incident avant de la considérer comme acquise.

Lire les coûts qui apparaissent après la signature

Le prix d’entrée ne raconte pas tout. Demandez comment sont traités les changements ordinaires : nouvelle interface, augmentation du volume, modification d’un rapport, ajout d’un environnement ou transfert d’une activité. L’objectif est de comprendre le fonctionnement économique du service, pas de chercher un tarif universel.

Regardez aussi le travail conservé en interne. Si les équipes passent régulièrement du temps à corriger, rapprocher ou contrôler les résultats, cette charge appartient au coût réel du fonctionnement. La faire apparaître permet de comparer plusieurs options sur une base plus complète.

Dans Révolution Numérique !, Guy de Lussigny décrit notamment le décalage entre l’achat de ressources et la maîtrise d’une capacité opérationnelle. Le passage consacré aux prestataires invite à regarder le périmètre, la gouvernance, les dépendances et les conditions de sortie, au-delà du seul prix négocié. Découvrir Révolution Numérique !.

Préparer la sortie sans annoncer une rupture

Savoir comment reprendre un service ne signifie pas vouloir quitter son fournisseur demain. C’est une manière de comprendre les accès, les connaissances, les données et les compétences dont l’entreprise dépend. Cette préparation rend également la relation plus claire lorsque les équipes changent.

Choisissez un exercice limité : récupérer un export exploitable, vérifier la documentation d’une interface ou identifier les droits nécessaires à une intervention. Notez ce qui manque et qui doit le fournir. Ne confondez pas une clause générale de réversibilité avec une capacité de reprise démontrée.

La discussion peut faire apparaître des choix : investir dans une compétence interne, documenter une opération, modifier un engagement ou accepter explicitement une dépendance. Ce sont des arbitrages de direction. Les laisser invisibles ne les fait pas disparaître.

Transformer le prochain comité en lieu de décision

Pour le prochain comité, remplacez une partie des statistiques par trois éléments : un usage prioritaire, l’écart observé et la décision attendue. Présentez les options avec leurs contraintes. Désignez un responsable et une date de vérification pour l’action retenue.

Conservez les indicateurs techniques qui aident au diagnostic. Il ne s’agit pas de les opposer aux métiers, mais de leur donner une fonction dans la chaîne de décision. Un indicateur utile doit pouvoir déclencher une question, une action ou un arbitrage ; sinon il risque de devenir un décor rassurant.

GDLTC intervient en management de transition et en pilotage de transformation numérique. Si votre organisation doit remettre à plat un service critique ou une relation fournisseur devenue difficile à piloter, le point de départ peut être ce diagnostic de fonctionnement. Présenter votre besoin de cadrage à GDLTC.

Le résultat recherché n’est pas un rapport plus sévère. C’est un service dont les responsabilités et les limites sont comprises, et une direction capable de décider avant que le prochain incident impose ses propres priorités.

#DSI #ManagementDeTransition #GouvernanceIT #Prestataires #RévolutionNumérique