Souveraineté numérique : distinguer les risques des slogans

Dans cette situation illustrative, un comité exécutif doit choisir en trois semaines la plateforme qui hébergera les données clients, les traitements analytiques et plusieurs services critiques. Un candidat promet rapidité, richesse fonctionnelle et exploitation mondiale. Un autre offre davantage de garanties de localisation et de réversibilité, mais exige plus d’intégration. Le débat se crispe aussitôt : les uns brandissent la souveraineté, les autres dénoncent un protectionnisme coûteux. Le DSI et le RSSI ont pourtant une responsabilité plus utile : transformer ces positions en risques comparables, en décisions assumées et en conditions contractuelles vérifiables.

Sortir du faux choix entre autonomie totale et abandon

La souveraineté numérique n’impose ni de tout internaliser ni d’écarter systématiquement les fournisseurs non européens. Elle mesure la capacité de l’organisation à continuer de décider lorsque ses données, ses opérations ou ses compétences dépendent d’un tiers. Le véritable sujet est donc le pouvoir restant après la signature : peut-on contrôler les accès, faire évoluer l’architecture, changer de prestataire, récupérer les informations dans un format exploitable et maintenir un service essentiel pendant une transition ? Une infrastructure hébergée en interne n’est pas souveraine si un expert unique en détient les clés. Inversement, un service externe peut rester maîtrisable si les dépendances sont connues et les issues praticables.

Décomposer le risque avant de comparer les offres

Un dirigeant IT doit refuser le score global qui mélange tout. Il commence par classer les services selon les conséquences d’une indisponibilité, d’une divulgation, d’une altération ou d’une impossibilité de migrer. Il distingue ensuite les données : opérationnelles, personnelles, stratégiques, techniques ou publiques. Puis il examine chaque dépendance : juridiction applicable, sous-traitants, administration à distance, composants propriétaires, licences, interfaces, formats d’export, compétences disponibles et concentration des achats chez un même acteur. Cette décomposition évite qu’une localisation rassurante masque une dépendance logicielle, ou qu’une certification générale dispense d’étudier le service réellement acheté.

Organiser un arbitrage pas à pas

La démarche commence par un scénario métier précis : que faut-il préserver si le fournisseur augmente fortement ses tarifs, suspend une fonction, subit une rupture majeure ou ne convient plus ? Le DSI décrit les capacités minimales à maintenir. Le RSSI qualifie les menaces et les preuves attendues. Les métiers fixent la durée d’interruption tolérable et les modes dégradés acceptables. Les achats testent les engagements, les responsabilités et le coût de sortie. La direction juridique analyse les clauses et les territoires concernés sans transformer son avis en garantie absolue. Enfin, le comité décide explicitement ce qu’il accepte, finance et réexamine. La souveraineté devient ainsi un processus de décision, non un label décoratif.

Pour rendre l’arbitrage lisible, chaque option doit être examinée sous plusieurs horizons. À court terme, quels gains opérationnels et quels risques immédiats ? À moyen terme, quelles interfaces, compétences et dépenses deviennent incontournables ? À long terme, quelles décisions l’entreprise ne pourrait-elle plus prendre seule ? Cette lecture empêche un prix d’entrée attractif d’effacer les coûts de dépendance. Elle permet aussi de distinguer le risque résiduel accepté de celui simplement ignoré. Le dossier soumis au dirigeant doit présenter les hypothèses, les mesures compensatoires, le propriétaire du risque et la date de réexamen. Sans cela, le choix technique devient une délégation implicite de stratégie.

Exiger des preuves plutôt que des promesses

Une clause de réversibilité n’a de valeur que si elle décrit les données restituées, leur format, le délai, l’assistance, le prix et le sort des copies résiduelles. Une sauvegarde ne suffit pas si sa restauration n’est jamais testée hors de l’environnement principal. Une interface annoncée comme standard ne protège pas lorsque les règles métier, les historiques ou les configurations restent inexportables. Avant engagement, l’équipe peut réaliser un export complet, reconstruire un jeu de données, vérifier les journaux d’administration et simuler le remplacement d’un composant critique. Le résultat attendu n’est pas une indépendance parfaite, mais une dépendance choisie dont la rupture a été préparée.

Mesurer la maîtrise dans la durée

Quelques indicateurs ramènent le sujet au pilotage : proportion des services critiques dotés d’un plan de sortie testé ; délai constaté pour restaurer un service sur une solution alternative ; part des données exportables avec leur contexte ; nombre de comptes privilégiés externes et qualité de leur traçabilité ; concentration des dépenses par fournisseur ; disponibilité interne des compétences indispensables ; écarts entre engagements contractuels et tests réalisés. Il faut aussi suivre le coût prévisionnel d’une migration, car une sortie techniquement possible peut devenir économiquement irréaliste. Ces mesures doivent être revues lors des renouvellements, des changements d’architecture et des acquisitions, pas seulement au lancement.

Éviter les erreurs qui fabriquent une souveraineté de façade

La première erreur consiste à sélectionner un fournisseur sur son passeport sans analyser sa chaîne technique et contractuelle. La deuxième est de confondre hébergement local et contrôle opérationnel. La troisième est d’exiger une réversibilité tout en reportant sa préparation jusqu’au jour du départ. Viennent ensuite l’accumulation de solutions alternatives non exploitables, l’absence de compétences internes et le refus de toute dépendance, qui renchérit les projets sans réduire les risques prioritaires. Enfin, traiter toutes les applications avec le même niveau d’exigence dilue les moyens : une messagerie secondaire et un système pilotant la production ne justifient pas les mêmes protections.

Décider en fonction de la criticité, puis assumer le compromis

L’arbitrage final peut retenir la solution la plus performante, y compris lorsqu’elle crée une dépendance importante, à condition de limiter son périmètre, protéger les données les plus sensibles, maintenir des compétences, négocier les sorties et financer les tests. Pour un service vital sans solution de continuité crédible, la direction peut au contraire accepter davantage de coût ou moins de fonctionnalités afin de préserver sa liberté d’action. C’est cette logique que développe Révolution Numérique ! : relier technologie, gouvernance, coûts, résilience et dépendances pour décider sans se laisser enfermer. La souveraineté utile ne proclame pas l’autonomie ; elle rend chaque renoncement visible, responsable et révisable.

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