
Traiter les fournisseurs historiques devenus indispensables
Situation illustrative : un lundi matin, l’ERP ralentit pendant la préparation des expéditions. L’équipe interne sait relancer certains traitements, mais une interface ancienne reste comprise par deux consultants du fournisseur historique. Celui-ci propose une intervention immédiate, à condition de signer un avenant plus large. Le DSI doit choisir sous pression : accepter, négocier ou temporiser. Le sujet n’est pourtant ni la loyauté du prestataire ni la continuité technique. Il concerne une dépendance devenue décisionnelle : quand un tiers détient les connaissances, les accès, les preuves et le rythme de résolution, l’entreprise ne maîtrise plus complètement son service, même si les indicateurs contractuels restent au vert.
Reconnaître l’indispensabilité sans chercher un coupable
Un fournisseur devient indispensable par accumulation. Une solution personnalisée vieillit, les équipes changent, les exceptions se multiplient, la documentation perd sa valeur et les responsables internes délèguent progressivement l’analyse. Le prestataire finit par connaître les enchaînements entre applications, données, métiers et procédures mieux que le client. Cette position peut résulter de décisions raisonnables prises séparément, non d’une manœuvre délibérée.
Le dirigeant doit donc éviter deux erreurs symétriques : nier la dépendance pour préserver l’apparence de contrôle, ou accuser le fournisseur avant d’avoir établi les faits. La bonne question n’est pas : pouvons-nous nous passer de lui demain ? Elle est : quelles capacités précises ne savons-nous plus exercer sans lui ? Exploiter, diagnostiquer, restaurer, modifier, auditer, négocier une licence ou préparer une bascule ne constituent pas la même dépendance.
Cartographier les leviers détenus
La première étape consiste à produire une carte opérationnelle, non un inventaire contractuel. Pour chaque service critique, le DSI identifie qui peut autoriser une intervention, accéder aux environnements, expliquer une configuration, retrouver une version, restaurer les données et valider le retour au service. Il distingue ensuite quatre objets : la connaissance, les droits d’accès, les actifs techniques et les engagements commerciaux.
Cette séparation révèle les fausses sécurités. Posséder le code ne garantit pas de savoir le reconstruire. Disposer d’un compte administrateur ne prouve pas que l’équipe maîtrise les conséquences d’un changement. Une clause de réversibilité n’équivaut pas à une procédure testée. À l’inverse, une forte dépendance technologique peut rester gouvernable si les décisions, les responsabilités, les coûts et les scénarios de sortie sont explicites. Le diagnostic doit nommer les inconnues plutôt que remplir artificiellement les cases.
Sécuriser le service avant de rééquilibrer la relation
Lorsque l’activité est exposée, la priorité reste la continuité. Menacer de remplacer immédiatement le prestataire peut provoquer de la rétention défensive, démobiliser les experts ou retarder une résolution. Le DSI sécurise d’abord un dispositif provisoire : interlocuteurs nommés, escalade disponible, accès vérifiés, sauvegardes exploitables, journal des décisions et conditions d’intervention claires. Il sépare l’urgence technique de la négociation structurelle.
Cette discipline protège la discussion commerciale. Un avenant nécessaire à la remise en service peut être limité dans son objet et sa durée, sans engager silencieusement plusieurs années de dépendance supplémentaire. Inversement, refuser toute concession au nom de la fermeté peut coûter davantage si l’organisation ne dispose d’aucune solution de repli crédible. La décision se prend sur l’exposition réelle du métier, pas sur une posture d’acheteur ou de technicien.
Construire une désensibilisation mesurable
Réduire la dépendance ne signifie pas remplacer immédiatement le fournisseur. Il faut transférer des capacités par paliers. Le premier peut viser l’observation : accès aux journaux, compréhension des traitements, documentation des dépendances et participation aux diagnostics. Le deuxième porte sur l’exécution supervisée : restaurations, mises en production, changements de configuration ou reprise d’incident réalisés avec l’équipe interne. Le troisième exige l’autonomie vérifiée sur un périmètre choisi.
Chaque transfert doit produire une preuve utilisable : procédure rejouée, environnement reconstruit, incident simulé, sauvegarde restaurée, référentiel mis à jour, compétence attribuée à plusieurs personnes. Une réunion de passation ou un dépôt documentaire ne suffit pas. Le fournisseur reste rémunéré pour le service et la transmission attendus ; l’entreprise, elle, affecte du temps interne. Sans capacité d’absorption, la meilleure clause de transfert ne produit qu’une archive supplémentaire.
Piloter avec des indicateurs qui révèlent le pouvoir
Les niveaux de service mesurent souvent des délais, rarement la maîtrise. Il faut leur ajouter des indicateurs de dépendance : part des incidents critiques diagnostiqués sans assistance externe, nombre d’opérations sensibles exécutables en interne, proportion d’accès nominatifs contrôlés, délai de restitution des éléments techniques, couverture des composants par une documentation rejouée et concentration des connaissances sur quelques individus.
Le DSI suit aussi les demandes de changement refusées ou retardées, les écarts entre devis et factures, les licences sans propriétaire métier, les prestations reconduites faute d’alternative et les actions de transfert arrivées à échéance sans preuve. Ces mesures ne servent pas à humilier le partenaire. Elles rendent les arbitrages visibles : payer une expertise rare peut être rationnel ; payer indéfiniment pour compenser une connaissance jamais transmise l’est beaucoup moins.
Arbitrer entre partenariat, mise en concurrence et sortie
Trois erreurs reviennent fréquemment. La première consiste à lancer un appel d’offres avant d’avoir récupéré les informations nécessaires : la concurrence compare alors des offres fondées sur des inconnues. La deuxième est de multiplier les prestataires, ce qui disperse les responsabilités sans recréer de compétence interne. La troisième est d’imposer une réversibilité totale, coûteuse et irréaliste, au lieu de cibler les fonctions dont l’indisponibilité arrêterait l’activité.
L’arbitrage final doit comparer trois trajectoires explicites. Renforcer le partenariat convient si le fournisseur coopère, si son expertise reste différenciante et si la dépendance devient gouvernable. Introduire un second acteur peut sécuriser un domaine précis, à condition de définir les responsabilités. Organiser la sortie s’impose lorsque les accès, les coûts, les risques ou le refus de transmettre rendent la relation incompatible avec la maîtrise attendue. Dans l’esprit de DSI EN CRISE, reprendre le contrôle ne consiste pas à tout internaliser : il s’agit de protéger l’activité, établir les faits et rendre les responsabilités décidables. Un fournisseur historique peut rester stratégique. Il ne doit plus être le seul à savoir pourquoi le système tient.
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
#ManagementDeTransition #DSI #DirectionDeTransition #GuyDeLussigny #TransformationNumerique




