Comment préserver les compétences critiques lors de l’externalisation

Le jour où le prestataire sait, et l’entreprise ne sait plus

Situation illustrative : un lundi matin, une panne bloque les commandes. Le contrat d’infogérance prévoit une prise en charge rapide, mais personne en interne ne peut expliquer l’enchaînement entre l’ERP, les interfaces et les contrôles de sécurité. Le prestataire traite l’incident ; le DSI doit décider s’il accepte une correction, déclenche le plan de continuité et assume le risque métier. L’entreprise a externalisé davantage que des tâches : une partie de sa capacité à comprendre et à arbitrer.

L’externalisation devient dangereuse non lorsque le fournisseur travaille beaucoup, mais lorsque le client ne peut plus formuler une exigence, contester un diagnostic ni reprendre la main. Le sujet n’est donc pas de tout conserver en interne. Il consiste à protéger les compétences qui rendent l’organisation capable de décider sous contrainte.

Distinguer la production déléguée de la responsabilité conservée

Un dirigeant IT peut externaliser l’exploitation d’une plateforme, l’administration d’un réseau ou une partie du support. Il ne peut pas déléguer la responsabilité de la disponibilité attendue, du niveau de risque accepté ou de la priorité donnée aux activités. Cette frontière doit être tracée service par service avant l’appel d’offres, pas après la signature.

La première question n’est pas : quelles tâches coûtent moins cher ailleurs ? C’est : quelles connaissances faut-il posséder pour gouverner ce service ? Pour un ERP, cela peut inclure la compréhension des processus critiques, des interfaces, des personnalisations et des mécanismes de reprise. En cybersécurité, la gouvernance des identités, la qualification du risque, les règles d’escalade et la direction d’une crise ne doivent pas devenir une boîte noire. Le fournisseur apporte une capacité d’exécution ; le client conserve le jugement, l’acceptation et la décision.

Cartographier les compétences avant de compter les postes

Une liste de fonctions ne suffit pas. Le DSI doit partir des décisions qu’il devra encore prendre dans trois situations : fonctionnement normal, changement majeur et incident grave. Pour chacune, il identifie les connaissances nécessaires, les personnes qui les détiennent, les preuves disponibles et le délai acceptable pour les mobiliser.

Cette cartographie révèle quatre catégories. Les compétences souveraines permettent d’arbitrer : architecture, sécurité, données, finances IT, portefeuille et relation métier. Les compétences de contrôle servent à vérifier les travaux reçus. Celles de continuité permettent d’agir lorsque le fournisseur est défaillant. Enfin, les compétences de marché servent à challenger prix, choix techniques et engagements contractuels.

Le bon périmètre interne ne se déduit donc pas d’un ratio universel. Il dépend de la criticité du service, de la concentration fournisseur, de la difficulté de recruter et du coût d’une perte de maîtrise.

Organiser le transfert comme une production vérifiable

Un transfert de connaissances ne se résume pas à déposer des documents ou à organiser quelques réunions. Il faut des livrables utilisables : architecture à jour, procédures d’exploitation, dépendances, historique des décisions, scénarios de reprise, matrices d’escalade et critères d’acceptation. Chacun doit avoir un propriétaire interne et une date de validation.

La démarche peut suivre cinq étapes. D’abord, observer le service réel et ses exceptions. Ensuite, faire exécuter les opérations sensibles par le fournisseur sous regard interne. Puis inverser les rôles : l’équipe interne exécute, le prestataire observe. Tester ensuite un incident ou une reprise sans mobiliser l’expert habituel. Enfin, corriger les lacunes constatées avant de prononcer l’acceptation du transfert.

Cette logique transforme la connaissance en capacité démontrée. Elle évite de payer une transition théorique dont la faiblesse n’apparaîtra qu’au premier incident sérieux.

Piloter avec des indicateurs de maîtrise, pas seulement des SLA

Un SLA peut être respecté tandis que la dépendance augmente. Le comité de pilotage doit donc suivre des indicateurs complémentaires : proportion des services critiques disposant d’un propriétaire interne nommé, couverture des rôles par un suppléant, décisions d’architecture documentées, procédures réellement testées, accès d’urgence contrôlés, écarts de compétences ouverts et délai de production des éléments nécessaires à une réversibilité.

Le DSI peut demander combien d’incidents majeurs ont reçu un diagnostic contradictoire, combien de changements ont été amendés par le client et quelles opérations restent impossibles sans une personne précise. Ces questions mesurent le jugement. Elles doivent conduire à des actions : formation, binômage, recrutement ciblé, rotation des responsabilités ou exercice de sortie partielle. Sans correction financée, la mesure documente seulement la dépendance.

Éviter les fausses sécurités

Première erreur : conserver des postes mais vider les rôles. Une équipe interne qui ne voit plus les journaux, ne participe plus aux changements et ne valide plus les choix perd rapidement sa compétence. Deuxième erreur : confondre documentation et savoir-faire. Une procédure non exercée ne garantit aucune autonomie. Troisième erreur : désigner un unique référent, créant une dépendance personnelle à la place d’une dépendance fournisseur.

Autre piège : exiger une réversibilité contractuelle sans entretenir les conditions techniques de sortie. Données incompréhensibles, scripts non transférables ou compétences absentes rendent la clause illusoire. À l’inverse, tout internaliser fragilise une organisation incapable de maintenir une expertise rare. La maîtrise consiste à savoir ce qui est fait, décider ce qui doit l’être et disposer d’options crédibles.

Arbitrer explicitement ce que l’entreprise refuse de perdre

Au terme de l’analyse, le dirigeant doit rendre un arbitrage lisible : ce qui est externalisé, ce qui reste interne, ce qui sera détenu en double et ce qui pourra être reconstruit dans un délai accepté. Cette décision doit associer DSI, RSSI, métiers, achats et direction générale, car le coût apparent du contrat ne reflète ni la dépendance future ni l’impact d’une incapacité à agir.

Dans Révolution Numérique !, la maîtrise des fournisseurs et la réduction des dépendances s’inscrivent dans une gouvernance reliant technologie, risques et décisions d’entreprise. Le principe est directement opérationnel : accepter l’expertise externe, sans abandonner l’architecture, la connaissance des processus, la capacité d’accepter un changement ni le commandement en crise.

Le meilleur contrat n’est pas celui qui promet de tout prendre en charge. Il laisse au client une organisation explicite, des compétences entretenues et une sortie praticable. Externaliser l’exécution peut accélérer l’entreprise ; externaliser son discernement l’immobilise.

Pour approfondir

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

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

Consulter la référence

Consulter la référence

#GouvernanceIT #ArchitectureSI #DSI #GuyDeLussigny #TransformationNumerique