Dépendances numériques : mesurer ce que l'on peut encore décider

Cartographier ses dépendances ne suffit pas : encore faut-il avoir vérifié ce que l'on peut faire si elles changent.

Dépendances numériques : mesurer ce que l’on peut encore décider

Savoir qui sont ses fournisseurs ne dit pas ce que l’on pourrait faire sans eux. Le Centre commun de recherche (JRC) de la Commission européenne a consacré une notice, datée du 15 octobre, à ses métriques de souveraineté numérique. Cette notice distingue quatre couches : gouvernance, infrastructures et logiciels, produits et marchés, personnes. Elle décrit des indicateurs complémentaires, sans les fondre dans une note unique. Elle ne permet pas d’établir clairement que les jeux de données ou le rapport complet soient accessibles au public : l’intérêt est donc dans la méthode. Comment passer d’une cartographie des dépendances à une mesure utile aux décisions ?

Connaître ses fournisseurs, ses logiciels et la localisation de ses données constituent un premier état des lieux. Il faut ensuite savoir ce que l’organisation peut faire si une brique change ses conditions, devient indisponible ou coûte trop cher. Le risque se révèle dans l’écart entre la dépendance identifiée et la capacité à y répondre.

L’Indice de Capital de Maîtrise (ICM) mesure cet écart. Il distingue trois niveaux : déclaré, mobilisable et vérifié. Une procédure ou une clause existent : la capacité est déclarée. Une équipe sait l’activer dans un délai compatible avec le besoin : elle est mobilisable. Un exercice fournit une preuve observable de son efficacité : elle est vérifiée. Ce repère transforme la liste des dépendances en questions de pilotage.

Je traduis les quatre couches du JRC en questions opérationnelles. Pour la gouvernance : qui arbitre et qui assume la responsabilité ? Pour les infrastructures et les logiciels : qui peut les administrer, les mettre à jour ou les remplacer ? Pour les produits et les marchés : quelles solutions alternatives existent, et à quel coût de transition ? Pour les personnes : quelles compétences sont disponibles ? Ces couches s’influencent : une compétence concentrée sur une seule personne fragilise aussi la gouvernance.

J’en ai fait l’expérience lors de la fusion des systèmes d’information des académies de Caen et de Rouen. Nous avons choisi d’héberger le système d’information fusionné au CRIANN, le centre régional informatique normand, plutôt que de centraliser les serveurs à Auzeville, près de Toulouse. Ce choix n’a pas supprimé la dépendance à un hébergeur. Il a préservé une capacité d’intervention : les équipes ont gardé la main sur l’exploitation et la proximité avec les systèmes. C’est un retour d’expérience, pas une preuve de réversibilité : celle-ci suppose un exercice. Voilà ce qu’une mesure doit éclairer : les dépendances présentes, mais aussi les marges de décision et d’intervention conservées par l’organisation.

Deux dépendances comparables sur une carte peuvent appeler des décisions différentes. L’une soutient une fonction essentielle, concerne beaucoup d’usagers ou n’a pas de solution de remplacement ; l’autre dispose d’un mode dégradé documenté et d’une équipe capable de le mettre en œuvre. La priorité dépend autant des conséquences que du nombre de fournisseurs.

Une cartographie utile suit les chaînes de dépendance au-delà du contrat principal : hébergement, identité, logiciels, support, API, sous-traitants. Pour chaque maillon, il faut savoir qui peut changer la configuration, où se trouvent les compétences, si les données et paramètres sont exportables dans un format réutilisable, et quelle autre équipe pourrait reprendre l’exploitation. Les angles morts se logent souvent dans ces responsabilités non attribuées.

Dans les 90 jours, un DSI peut éprouver cette capacité pour un service critique :

· Exporter puis réimporter les données et paramètres d’un service critique.

· Simuler la révocation des accès d’un prestataire et vérifier les effets en aval.

· Chronométrer le redémarrage du service en mode dégradé.

· Désigner un titulaire et un suppléant capables de diagnostiquer chaque brique critique.

· Faire tourner la fonction prioritaire sur la solution de remplacement identifiée.

Le capital de maîtrise se construit dans les choix concrets. Une organisation peut dépendre de tiers tout en conservant des options : comprendre l’architecture, décider du niveau de risque, maintenir les compétences, négocier les conditions de sortie et tester la continuité. La localisation reste un critère parmi d’autres ; elle ne remplace pas ces capacités.

Pour chaque dépendance, la direction peut alors arbitrer : la réduire, l’assumer ou renforcer les preuves qui permettent de la gouverner.

Au comité de direction, la question devient : "Que nous empêche cette dépendance de décider ou de faire, et qu’avons-nous vérifié pour pouvoir agir si elle évolue ?" La réponse se construit service par service, par des arbitrages explicites et des exercices dont les résultats sont connus. Une organisation ne maîtrise pas ses dépendances parce qu’elle les a recensées, mais parce qu’elle a vérifié ce qu’elle peut encore décider, maintenir et remplacer lorsqu’elles changent.

Sources à la rédaction

Joint Research Centre, Commission européenne, "Digital Sovereignty Metrics — Dataset collection", notice datée du 15 octobre 2026. Elle décrit le cadre et ses quatre couches ; le dépôt ne permet pas d’établir clairement l’accès externe au rapport complet et aucun résultat chiffré n’est repris ici. Consulter la notice

Jacky Galicher, "Indice de Capital de Maîtrise (ICM)", niveaux déclaré, mobilisable et vérifié. Consulter la page ICM