Le 11 novembre 2026, IBM a publié son Digital Sovereignty Index. L’étude examine les preuves que les entreprises disent pouvoir apporter de leur maîtrise du numérique. Parmi les dimensions étudiées figure la capacité à changer de fournisseur ou à rétablir les opérations.

Pour un DG ou un DAF, cela ouvre une question concrète : sur un service important pour l’entreprise, avons-nous vérifié ce qu’il faudrait pour partir ?

Ce que l’étude permet de dire

Le rapport repose notamment sur une enquête auprès de 2 003 décideurs dans sept pays, dont 250 en France. Il indique que 33 % des répondants testent leur capacité à démontrer leur souveraineté en continu ou dans leurs processus réguliers de gouvernance et d’assurance. Ce chiffre ne mesure pas la proportion d’entreprises ayant réussi un changement de fournisseur.

La méthodologie, page 28 du rapport, précise que les réponses et les éléments de preuve déclarés n’ont pas fait l’objet d’un audit indépendant. En France, les participants travaillent dans des entreprises d’au moins 500 salariés. Il ne s’agit donc pas d’une mesure représentative de toutes les ETI françaises. IBM est aussi un fournisseur intéressé par ce marché.

La nouveauté est la publication de cet indice. Elle n’établit ni une obligation nouvelle ni la nécessité de quitter un prestataire.

Conserver la liberté de choisir

Dans le post du 8 juillet consacré à la dépendance aux fournisseurs d’IA, la question était posée ainsi :

Et si le risque majeur de l’IA n’était plus l’adoption... mais la dépendance à un fournisseur IA ?

La question n’est donc plus seulement Quel LLM utiliser ? Mais plutôt Comment conserver la liberté de choisir le meilleur modèle aujourd’hui… et demain ?

Demain, les organisations les plus résilientes seront peut-être celles qui auront :

  • Évité le verrouillage technologique (vendor lock-in) ;
  • Conservé la maîtrise de leurs données ;
  • Gardé la capacité d’arbitrer entre plusieurs modèles selon la performance, le coût ou les contraintes réglementaires ;
  • Intégré des alternatives open source lorsque cela fait sens.

Cette position concernait les modèles d’IA. Elle gardait une réserve : « seront peut-être ». Elle ne promettait pas qu’une architecture donnée rendrait tout changement simple.

L’exercice proposé ici applique cette question de liberté de choix à un service IT précis. Il ne suppose ni de multiplier les fournisseurs ni de tout reprendre en interne.

Un essai sur un seul service

Le Cloud Banking Forum de la Fédération bancaire européenne distinguait déjà, en juin 2020, la revue du plan, l’exercice sur table et la simulation contrôlée. Ce document propose des options de test pour le secteur bancaire ; ce n’est pas une obligation générale pour les ETI. Il fournit un repère pour choisir la profondeur de l’essai.

Prenons une situation illustrative, sans référence à un client : une ETI utilise une application hébergée pour suivre ses demandes de maintenance. Le contrat approche de son renouvellement. La direction souhaite savoir si une autre solution serait réellement accessible, sans interrompre le travail des équipes.

Le DSI propose un essai en environnement isolé. Le responsable maintenance choisit dix demandes fictives ou préalablement anonymisées : une demande ouverte, une clôturée, une avec une pièce jointe, une réaffectée à un autre technicien. Ce nombre est un point de départ pour l’exercice, pas un seuil de validation.

Avant toute extraction, l’équipe vérifie avec les achats et les personnes compétentes les conditions du contrat, les droits d’utilisation et les données qu’elle peut employer. Elle fixe la durée et le budget de l’essai. Le service courant continue de fonctionner ; aucun compte de production n’est fermé.

L’objectif n’est pas seulement d’obtenir un fichier. Il faut pouvoir reconstituer, dans un environnement de destination autorisé, une opération utile au métier : retrouver une demande, comprendre son historique, consulter sa pièce jointe et reprendre son traitement avec les bons droits.

Si aucune destination n’est disponible, l’exercice peut commencer par la lecture de l’export et l’identification des dépendances. Son résultat devra alors être nommé pour ce qu’il est : une vérification de récupération, encore insuffisante pour conclure sur le changement d’outil.

Garder une trace des écarts

Une fiche courte permet de préparer la discussion entre le DSI, le métier et le DAF. Les éléments ci-dessous sont des points à vérifier, pas les résultats d’un essai déjà réalisé.

Point à vérifier Preuve attendue dans cet exemple Si elle manque
Historique des demandes Les événements et leur ordre restent compréhensibles Préciser ce qui serait perdu ou à reconstruire
Pièces jointes Les documents sont récupérés et reliés à la bonne demande Identifier le mécanisme d’export complémentaire
Droits d’accès Un technicien voit les demandes qui lui sont autorisées Chiffrer la reprise du paramétrage
Reprise du travail Le métier peut poursuivre un cas dans la destination Décrire l’écart fonctionnel et sa conséquence
Effort nécessaire Temps passé, interventions du fournisseur et coûts connus sont consignés Séparer estimation, montant confirmé et inconnu

Sur petit écran, faites défiler le tableau horizontalement.

Le compte rendu conserve aussi la date, les versions utilisées, le périmètre exclu et la personne qui a vérifié chaque résultat. Un essai sur dix demandes ne démontre pas que l’ensemble de l’historique migrera dans le délai attendu. Les volumes, les interfaces et le fonctionnement en charge restent à examiner.

Pour un service utilisant l’IA, la même prudence s’applique : récupérer les documents ne démontre pas que les réponses d’un autre modèle seront acceptables. La qualité des résultats, les droits et les usages autorisés doivent faire partie des vérifications prévues pour ce service.

Décider ce que cette liberté vaut

Le DAF peut alors distinguer le coût du test, celui de la correction des écarts et celui d’une éventuelle transition. Il reste à compter le temps des équipes, la coexistence temporaire des solutions, l’accompagnement des utilisateurs et l’exploitation de la destination.

Dans l’épisode du 8 juillet d’In-Ear Insights, Katie Robbert rappelle que reprendre un outil en interne suppose encore des compétences de développement, d’exploitation, de test et de gestion des données. Ce retour de praticienne apporte une limite utile à l’idée d’une sortie facile grâce à l’IA. Il ne chiffre pas le coût d’une migration pour une ETI.

À l’issue de l’essai, plusieurs décisions restent possibles : demander une correction à l’éditeur, financer une vérification plus large, préparer un changement ou conserver le service en acceptant une dépendance explicitement décrite. Rester peut être une décision raisonnable. L’intérêt du travail est de savoir ce qui la motive et ce qui conduirait à la réexaminer.

Le DG peut demander une prochaine échéance liée au renouvellement du contrat ou à une évolution du service. Le DSI porte les vérifications techniques ; le responsable métier précise ce qui doit continuer à fonctionner. La méthode d’accompagnement X-PM permet de cadrer les responsabilités confiées à une direction IT et les décisions attendues.

Un test de sortie ne résout pas, à lui seul, les questions de juridiction, de sécurité ou de souveraineté de l’entreprise. Il rend simplement une partie de sa dépendance plus observable.

La souveraineté numérique est-elle devenue un critère de sélection de vos solutions IA ?

Cette question figurait aussi dans le post du 8 juillet. Pour la prochaine décision de fournisseur, on peut lui ajouter une vérification : quelle possibilité de sortie l’équipe pourra-t-elle montrer, et quelles limites restera-t-il à accepter ?

Sources et lectures