Rachats d’éditeurs, hausses tarifaires unilatérales, dépendances critiques… La souveraineté numérique ne se résume pas à la localisation d’un fournisseur ou de ses données. Elle repose aussi sur la capacité à maîtriser ses choix technologiques.
Autrement dit : pouvoir changer de solution ou de fournisseur lorsque le contexte l’exige, sans mettre en difficulté son activité. C’est tout l’enjeu de la réversibilité.
Mais chercher à rendre l’ensemble de son système d’information réversible serait aussi coûteux qu’illusoire. L’objectif est ailleurs : identifier les dépendances qui présentent un véritable risque pour l’entreprise et concentrer les efforts là où ils sont utiles.
Anticiper. Concevoir. Tester. Voici huit leviers pour préserver cette capacité de choix.
Sommaire
- Réversibilité : de quoi parle-t-on ?
- Anticiper : préserver sa capacité de choix dès le départ
- Concevoir : limiter les dépendances difficiles à défaire
- Piloter : vérifier sa capacité de sortieadoxe des architectures data vieillissantes
- Avec l’IA, de nouvelles dépendances à anticiper
Réversibilité : de quoi parle-t-on ?
Une dépendance technologique peut rapidement devenir une dépendance économique.
La souveraineté numérique ne consiste pas uniquement à choisir un fournisseur local ou à stocker ses données en Europe. Elle suppose aussi de se poser une question simple : si les conditions changent demain, êtes-vous réellement capables de choisir une autre voie ?
Hausse importante des tarifs, rachat d’un fournisseur, évolution contractuelle, arrêt d’un service… La réversibilité désigne la capacité à changer de solution sans provoquer une rupture majeure de service ni supporter un coût de sortie disproportionné.
Elle ne se limite donc pas à quelques clauses contractuelles. Elle se prépare dès le choix d’une solution, se construit dans l’architecture, se vérifie dans la durée et, surtout, se priorise.
Tout rendre réversible créerait une complexité inutile. La priorité consiste à sécuriser les dépendances critiques et à conserver des marges de manœuvre.
ANTICIPER : préserver sa capacité de choix dès le départ
1. Cartographier pour identifier ses dépendances
C’est le point de départ : difficile de sécuriser une dépendance qui n’a pas été identifiée. La cartographie permet de repérer les risques et de les hiérarchiser.
Pour cela, chaque application, technologie ou fournisseur peut être évalué selon plusieurs critères : criticité métier, sensibilité des données, technologie propriétaire ou open source, compétences nécessaires, contraintes contractuelles, coût d’une migration ou encore sécurité. Le score obtenu fait ressortir les dépendances les plus critiques et facilite les arbitrages.
Pour construire cette cartographie, quelques principes :
- Partir de l’existant : le BIA (business impact analysis) pour la criticité métier, la CMDB (configuration management database) pour les flux techniques et l’inventaire des contrats.
- Examiner les différentes formes de dépendance : les données (où sont-elles hébergées ?), la technologie (dépend-elle, par exemple, d’API propriétaires ?) et les compétences (qui maîtrise réellement la technologie ?).
Enfin, l’analyse ne doit pas s’arrêter au fournisseur direct. Une dépendance critique peut se cacher plus loin dans la chaîne de sous-traitance, chez un fournisseur de rang 2 ou 3. Par exemple, trois applications métiers considérées comme indépendantes peuvent reposer en réalité sur le même hyperscaler ou le même composant critique.
L’enjeu n’est pas de cartographier toute la chaîne, mais d’identifier les dépendances indirectes susceptibles d’affecter les services critiques et les acteurs dont l’organisation dépend réellement.
2. Prévoir la sortie dès la contractualisation
Le coût de sortie doit faire partie intégrante du coût total de possession. Une solution peut être économique à déployer, puis devenir progressivement difficile à remplacer. Lorsque les conditions commerciales évoluent, cette dépendance réduit la marge de négociation.
Le contrat doit donc anticiper les principaux scénarios de sortie : fin du contrat, hausse tarifaire importante, changement de contrôle du fournisseur ou non-respect de ses engagements.
Il doit aussi préciser les délais de préavis, les formats d’export des données, leur transfert et leur effacement, le maintien du service pendant la transition, l’assistance du fournisseur sortant et les coûts associés. La durée des engagements mérite également d’être questionnée.
Le bon arbitrage n’est pas nécessairement le prix le plus bas aujourd’hui, mais le niveau de dépendance que l’entreprise accepte demain.
3. Faire de la réversibilité une responsabilité partagée
La réversibilité n’est ni un sujet purement DSI ni un sujet purement juridique. Elle implique plusieurs fonctions de l’entreprise et gagne à être portée au niveau de décision adapté à la criticité des dépendances concernées.
Pour les sujets les plus structurants, son inscription dans les orientations stratégiques facilite les arbitrages, donne de la visibilité au chantier et permet de mobiliser les moyens nécessaires.
Trois parties prenantes, au minimum, sont à embarquer :
- Les achats, pour intégrer le coût de sortie dans l’évaluation économique.
- Les équipes d’architecture et de sécurité, pour valider les aspects techniques.
- Les métiers, pour définir ce qui est vraiment critique et acceptable en cas de transition.
CONCEVOIR : limiter les dépendances difficiles à défaire
4. Adopter une architecture « Réversible by Design »
C’est le point de départ : difficile de sécuriser une dépendance qui n’a pas été identifiée. La cartographie permet de repérer les risques et de les hiérarchiser.
Plus un système est fortement imbriqué, plus le remplacement d’un composant risque d’affecter l’ensemble. Quelques principes permettent de limiter ce risque :
- Séparer clairement les données, la logique métier, les interfaces et l’infrastructure.
- Privilégier les standards ouverts lorsque cela est pertinent : API ouvertes et protocoles standards plutôt que les connecteurs propriétaires.
- Introduire des couches d’abstraction pour faciliter le remplacement d’un fournisseur.
Ces choix ont eux-mêmes un coût de conception, d’exploitation et de maintenance. Ils doivent donc être réservés aux endroits où conserver plusieurs options apporte un bénéfice réel.
5. Couvrir les trois dimensions de la réversibilité : données, applications et infrastructure
Une stratégie de réversibilité doit couvrir trois dimensions complémentaires :
- Les données : sont-elles réellement récupérables ?
La portabilité et l’intégrité des données doivent être vérifiées, ainsi que la conservation de leur historique et des relations entre elles. - Les applications : les processus métier peuvent-ils continuer à fonctionner ?
La récupération des données ne suffit pas. Les fonctions critiques doivent pouvoir être reconstruites ou remplacées. - L’infrastructure : peut-elle être reconstruite ailleurs ?
Cette dimension est souvent la plus complexe à faire évoluer. Dans le cloud public, la dépendance dépasse l’hébergement : bases de données, services d’IA ou plateformes de développement peuvent accélérer les projets tout en renforçant l’attachement à un environnement.
L’enjeu est de mesurer la dépendance créée par ces services et de l’arbitrer au regard des bénéfices qu’ils apportent.
PILOTER : vérifier sa capacité de sortie
La réversibilité est une capacité opérationnelle : elle se priorise, se construit dans la durée et se vérifie par des tests réguliers. Sans cette vérification, les hypothèses initiales peuvent progressivement s’éloigner de la réalité du SI.
6. Tester pour savoir si la sortie est réellement possible
Un plan de réversibilité qui n’a jamais été testé reste une hypothèse.
Les tests peuvent notamment vérifier le délai réel d’extraction des données, leur exploitabilité, la reconstruction des interfaces, la reprise des droits et habilitations ou encore la possibilité de revenir à la situation précédente en cas d’échec.
Un test peut, par exemple, confirmer que les données sont bien exportables comme prévu au contrat, mais révéler qu’une partie des relations entre elles n’est pas conservée dans l’export. La récupération est techniquement possible ; leur réutilisation dans une autre solution nécessiterait pourtant un travail de reconstruction non anticipé.
Ce type de résultat permet de confronter les dispositions contractuelles et les choix d’architecture aux conditions réelles d’une sortie, sans attendre une migration complète pour découvrir les difficultés.
7. Prioriser les tests selon le niveau de risque
Tout tester avec le même niveau d’exigence serait coûteux et peu pertinent.
Deux critères permettent de concentrer les efforts : la criticité métier et la difficulté de sortie.
Leur croisement permet de distinguer quatre situations :
- Forte criticité, sortie difficile : le cœur de cible. C’est là qu’il faut investir en priorité, avec des tests approfondis et réguliers.
- Forte criticité, sortie facile : un plan de sortie documenté et vérifié ponctuellement permet de maîtriser le risque sans surinvestir.
- Faible criticité, sortie difficile : la dépendance peut faire l’objet d’un arbitrage et, dans certains cas, être assumée.
- Faible criticité, sortie facile : un effort minimal peut suffire.
Cette matrice fournit un cadre simple pour décider où tester, à quelle fréquence et avec quel niveau d’exigence.
8. Piloter la dette de réversibilité
La réversibilité évolue avec le système d’information. Une nouvelle application, une évolution d’architecture ou un service cloud supplémentaire peuvent créer de nouvelles dépendances.
Le pilotage repose donc sur deux actions complémentaires : réévaluer périodiquement le patrimoine existant et intégrer la question de la réversibilité dans la conception des nouveaux projets.
Au fil du temps, des choix parfaitement pertinents lors de leur mise en œuvre peuvent devenir plus difficiles à défaire. C’est cette accumulation qu’il faut surveiller comme une dette de réversibilité, afin qu’elle reste visible et puisse être arbitrée.
Avec l’IA, de nouvelles dépendances à anticiper
Un processus métier construit autour d’un LLM propriétaire ajoute de nouvelles dépendances à celles déjà connues : modèle économique du fournisseur, coût d’utilisation, disponibilité des modèles ou accès aux capacités de calcul.
Les architectures permettant de changer de modèle peuvent réduire une partie de cette dépendance. Mais l’interchangeabilité technique ne suffit pas toujours : un changement de LLM peut modifier les performances, les formats de sortie ou le comportement d’une application et nécessiter de nouveaux tests.
Prévoir des scénarios de désactivation ou de retour en arrière permet également d’identifier ce qui se passerait si un service devenait trop coûteux, indisponible ou inadapté aux besoins.
Enfin, la dépendance peut aussi être humaine. Lorsqu’une équipe intègre profondément un outil d’IA dans ses pratiques, son organisation évolue avec lui. Changer d’outil ou revenir en arrière implique alors d’adapter les usages, les compétences et les modes de travail, au-delà des seuls aspects techniques.
Directeur Division Consulting
Directeur BU Consulting
Industrie et Services
Poursuivez votre réflexion
