Jusqu’où peut-on externaliser ?

C’était au début des années 2010. L’entreprise où j’intervenais en tant que consultant sortait péniblement d’un vaste projet SAP, déployé dans l’ensemble des filiales européennes. Près d’une décennie d’alignement progressif des processus, de réconciliation des modèles comptables, de batailles locales autour des flux logistiques. L’infrastructure était en place, coûteuse mais robuste.

Et puis, Salesforce est arrivé. Le CRM en mode SaaS. Le discours était limpide : cette fois, on allait éviter les écueils du passé. Terminé, les projets informatiques interminables, les couches techniques à maintenir en interne, les dépendances aux compétences locales rares. Salesforce promettait l’inverse : simplicité, rapidité, standardisation native. Tout serait pris en charge — de la maintenance aux mises à jour — par le prestataire lui-même.

Ce que l’on ne mesurait pas encore, c’est que ce choix, apparemment ponctuel, modifiait en profondeur la manière dont l’entreprise gouvernait ses systèmes. On ne faisait plus qu’externaliser une brique logicielle : on externalisait un pan entier de la logique de gestion, des processus commerciaux, de la donnée client. Et ce seuil, imperceptible, avait été franchi sans bruit.

Dix ans plus tard, cette dynamique est devenue un standard. Infrastructure cloud, CRM, ERP, sécurité, conformité, authentification, même les fonctions critiques sont désormais confiées à des acteurs tiers — souvent globaux, extra-européens, et difficilement remplaçables.

C’est précisément ce glissement que les textes européens récents cherchent aujourd’hui à encadrer.

Mais ce cadre normatif, aussi structuré soit-il, produit un effet paradoxal. En voulant poser des garanties, il peut inciter les plus petits acteurs à se retirer encore davantage de la maîtrise. Face à l’inflation des exigences techniques et documentaires, la réponse est souvent réflexe : confier le tout à un prestataire "conforme", estampillé ISO ou "NIS ready". L’exigence devient délégation. La norme, un produit de marché. Le risque, un service sous-traité.

Autrement dit : plus la règle se raffine, plus l’envie de s’en délester devient forte. Et c’est là que le seuil se déplace encore — non plus par stratégie, mais par fatigue, par impuissance ou par opportunisme économique.

Ce qui devait responsabiliser finit par organiser une forme d’abdication douce. Et la question revient, plus aiguë encore :Jusqu’où peut-on externaliser sans céder, en silence, sa propre capacité à décider ?

Ce que la directive NIS 2 tente de restaurer : un principe de responsabilité indivisible

Avec l’adoption de la directive NIS 2, l’Union européenne semble vouloir refermer une brèche : celle d’une externalisation devenue si fluide qu’elle en a effacé la frontière qui sépare l’interne de l’externe. Or ce débat dépasse la sphère technique : il pose une question plus large, celle de la capacité d’une organisation à rester maîtresse de ses fonctions critiques dans un environnement interconnecté.

Le texte est clair, dans ses grandes lignes. Il pose que les entités dites « essentielles » ou « importantes » sont responsables de la cybersécurité de leurs systèmes, y compris lorsque ceux-ci sont opérés par des prestataires tiers. Il impose des obligations concrètes : évaluation des risques, mesures techniques et organisationnelles, gestion des incidents, plans de continuité, contrôle des fournisseurs. Une ligne revient avec insistance : la responsabilité ne se délègue pas.

Mais sur le terrain, ce principe se heurte à une autre réalité : la perplexité des petites structures, la complexité croissante des systèmes, la multiplication des outils des acronymes. Et l’ombre des audits à venir. Pour beaucoup, l’arrivée de NIS 2 ne produit pas un sursaut de maîtrise. Elle produit un désir de soulagement : “Trouvons vite un prestataire qui coche toutes les cases.” La norme devient un marché, et le respect des exigences un service à acheter.

Et c’est ici que le paradoxe apparaît. Là où la directive entend responsabiliser, elle encourage involontairement un retrait . Trop complexe, trop risqué, trop mouvant : mieux vaut déléguer à un acteur supposé mieux armé. Mieux vaut transférer que construire. Mieux vaut souscrire que comprendre.

Ainsi, le cycle recommence. La norme a pour but de renforcer la résilience. Mais elle devient elle-même un moteur d’externalisation.

Ce n’est plus la performance qui motive la délégation, comme avec Salesforce dix ans plus tôt. C’est désormais la conformité. Car dans cette logique, l’organisation cesse de penser ses systèmes comme ses parties “vivantes”. Elle les traite comme des boîtes noires, contractuellement bordées, mais muettes. Elle répond aux exigences externes, mais désapprend à habiter ses propres fonctions critiques.

Et ce que NIS 2 voulait prévenir — la perte de gouvernance, la vulnérabilité systémique, la défaillance en chaîne — continuera de se produire. Mais dans les “règles”.

À partir de quand une dépendance devient-elle critique ?

La gestion des identités et des accès n’est pas un sujet visible. Elle fonctionne en arrière-plan, entre les mots de passe oubliés, les comptes à créer, les droits à retirer, les permissions temporaires. Elle semble mineure, presque logistique. Et pourtant, elle structure tout. Pour les acteurs de taille moyenne, c’est souvent l’un des premiers chantiers à être externalisé.

Trop technique, trop mouvant, trop réglementé. La cryptographie, les authentifications multi-facteurs, les droits croisés, les traces d’audit : on préfère déléguer. On choisit un acteur reconnu et on lui confie le trousseau numérique de l’entreprise. Au départ, tout fonctionne bien. L’authentification est fluide, les comptes sont provisionnés automatiquement, les audits sont générés sur demande.

Et puis, un jour, un incident survient. Un compte compromis. L’entreprise, bien qu’elle soit légalement responsable, n’a plus les clés techniques pour comprendre. Elle n’a accès qu’à des interfaces, à des journaux partiels, à un rapport rédigé par le prestataire. Et une obligation de notification à l’autorité compétente. Après l’incident, le diagnostic commencera inévitablement par cette phrase que l’on a toutes et tous déjà entendus “On soupçonne … mais on ne saura jamais”.

Les cadres actuels ne définissent pas de seuil critique d’externalisation, ce moment une externalisation deviendrait une perte de gouvernance. Parce que ce seuil n’est pas juridique. Il est opérationnel et lorsqu’il est franchi, c’est souvent sans retour car la compétence s’est perdue.

C’est le moment où l’organisation ne peut plus comprendre, ni reconfigurer les mécanismes qu’elle utilise chaque jour. Car elle dépend d’un acteur extérieur pour vérifier qu’elle-même est en opérationnelle. Et elle ne peut retrouver son autonomie sans reconstruire toute sa logique d’accès.

Le bon sens exigerait que ces dépendances soient connues, cartographiées, gouvernées. Mais aujourd’hui, dans la pratique, cette cartographie est rarement faite. Et lorsqu’elle existe, elle rarement tenue à jour. L’entreprise ne pilote plus son environnement numérique. Elle le traverse. Elle devient locataire de son propre accès.

Vers une orientation stratégique : gouverner les dépendances, non les subir

Il serait tentant, à ce stade, de conclure par une injonction : il faut réinternaliser. Reprendre la main en rapatriant les fonctions critiques et en reconstituant la compétence.

Mais ce serait une illusion. Le numérique aujourd’hui n’est pas un système modulaire où l’on choisit ce que l’on garde et ce que l’on délègue. Il est un tissu serré de services interdépendants, distribués, souvent opaques, et l’autonomie absolue est un mythe.

La directive NIS 2, en ne fixant pas de seuil formel, ne dit pas qu’il faut tout garder en interne. Elle impose plutôt une exigence de lucidité : être capable d’identifier ce qui, une fois externalisé, rend l’organisation dépendante au point de ne plus pouvoir agir seule en cas de rupture.

Car lorsqu’une fonction critique n’est plus ni compréhensible, ni réversible, ni même questionnable en interne, l’organisation ne pilote plus. Elle s’aligne. Elle suit. Elle devient structurellement liée aux choix d’un tiers, sans marge d’arbitrage. Et aucune norme ne peut restaurer cette capacité de décision une fois qu’elle a été abandonnée.

L’orientation stratégique ne consiste donc pas à inverser le mouvement de l’externalisation, mais à le penser dans ses effets. À distinguer ce qui peut être confié sans conséquence durable de ce qui, une fois délégué, transforme l’organisation de manière irréversible.

Cela suppose un travail rarement engagé : une cartographie non pas des services, mais des seuils de non-retour. Non pas des prestataires, mais des fonctions de pilotage. Non pas des flux de données, mais des zones où la responsabilité se dissout. Autrement dit, identifier les fonctions qui doivent rester sous contrôle direct, clarifier les responsabilités associées à chaque dépendance, et évaluer la capacité de l’organisation à reprendre la main en cas de besoin.

Gouverner ses dépendances, c’est être capable d’identifier ce qui, dans la chaîne des services numériques, engage directement la capacité de l’organisation à comprendre, à décider, à réagir. Cela commence souvent par une question simple, mais rarement posée :

Si ce service s’interrompt, quelle est notre autonomie réelle pour y faire face ?

En d’autres termes : jusqu’où reste-t-on acteur de ce que l’on délègue ?