À retenir – Souveraineté du SI
- La souveraineté du SI ne se limite pas à l’hébergement.
- Le risque principal vient des dépendances invisibles.
- Cinq dépendances doivent être surveillées par les DSI.
- La cartographie du SI devient indispensable.
La souveraineté du système d’information est devenue un sujet de direction générale. Pourtant, elle reste encore souvent réduite à des questions d’hébergement, de nationalité des fournisseurs ou de conformité réglementaire.
Ces dimensions comptent, cependant elles ne disent pas tout. Pour une DSI, le véritable enjeu est de conserver la maîtrise du SI dans la durée : comprendre ses dépendances, garder la capacité de décider, d’agir, de faire évoluer et de sécuriser les composants critiques.
Être souverain ne signifie pas tout internaliser, ni se couper des grands acteurs du marché. Cela signifie disposer de marges de manœuvre suffisantes pour éviter que certains choix techniques, contractuels ou organisationnels ne deviennent irréversibles.
La souveraineté du SI : sortir d’une vision trop réductrice
Parler de souveraineté conduit souvent à se concentrer sur quelques critères visibles : localisation de l’hébergement, nationalité des fournisseurs, conformité réglementaire, usage d’un cloud dit « souverain ». Ces critères permettent de poser un premier cadre, notamment sur les données sensibles ou les obligations sectorielles, mais ils ne garantissent pas la souveraineté d’un SI.
Une entreprise peut très bien héberger ses données en Europe et rester fortement dépendante d’un fournisseur dont elle ne maîtrise ni les choix techniques ni les évolutions tarifaires. Elle peut disposer d’un hébergement local et rester exposée à des obligations juridiques extraterritoriales ; des auditions parlementaires récentes ont d’ailleurs rappelé qu’un hébergement physique en Europe ne suffit pas toujours à empêcher l’accès aux données par une autorité étrangère, dès lors que le fournisseur reste soumis à une juridiction externe.
Le sujet ne se limite donc pas à savoir où sont stockées les données. Il consiste à comprendre de quoi dépend réellement le SI et dans quelles conditions l’entreprise peut reprendre la main si nécessaire.
Concrètement, la souveraineté se vérifie en posant des questions simples :
- Peut-on récupérer ses données dans un format exploitable, sans passer par le bon vouloir du fournisseur ?
- Peut-on changer de solution sans provoquer une rupture métier de plusieurs mois ?
- Les contrats prévoient-ils une réversibilité réelle (testée, documentée, opérationnelle) ?
- Les applications critiques sont-elles connues, cartographiées, pilotées ?
- La DSI garde-t-elle la main sur les choix structurants, ou les subit-elle ?
Si plusieurs de ces réponses sont floues ou négatives, la souveraineté est partielle, quelle que soit la localisation des serveurs.
Le vrai risque : l’accumulation de dépendances invisibles
La perte de souveraineté ne résulte pas toujours d’un choix stratégique identifié. Elle se construit progressivement, au fil des projets, des urgences et des décisions prises sans vision d’ensemble.
Le scénario est souvent le même :
- Une application est déployée pour répondre à un besoin opérationnel urgent.
- Une solution SaaS est adoptée parce qu’elle est rapide à mettre en place.
- Un prestataire développe une intégration spécifique parce que personne en interne n’a le temps.
- Un contrat est renouvelé sans être ré-interrogé.
- Un outil est choisi directement par une direction métier, sans passage par la DSI.
Pris isolément, chacun de ces choix est souvent justifié. Ensemble, ils construisent un SI dont certaines dépendances deviennent difficiles à lire, à mesurer et à défaire.
Le problème n’est pas la dépendance en elle-même. C’est l’invisibilité. Une DSI qui sait qu’elle dépend fortement d’un ERP peut construire une stratégie autour de cette réalité : sécuriser la relation contractuelle, documenter les processus, former des équipes, anticiper les migrations. Une DSI qui découvre cette dépendance au moment où elle veut changer de solution se retrouve dans une position bien plus inconfortable.
Quelques situations concrètes que les DSI rencontrent régulièrement :
- Une migration de CRM bloquée parce que des connecteurs critiques ont été développés sur mesure par un prestataire qui n’est plus disponible et dont personne n’a documenté le fonctionnement.
- Un éditeur SaaS qui triple ses tarifs au renouvellement, sachant que les données clients sont dans son environnement et que la migration prendrait six mois.
- Une application métier « secondaire » dont on découvre, lors d’un incident, qu’elle alimente en réalité trois processus critiques non documentés.
- Un contrat d’infogérance qui s’est reconduit tacitement pendant huit ans, sans que personne n’ait évalué ce que représenterait une sortie.
Dans chaque cas, la dépendance existait bien avant que le problème n’apparaisse, mais elle était simplement invisible.
Les 5 dépendances critiques que les DSI doivent surveiller
Pour piloter la souveraineté du SI, la DSI doit d’abord identifier les dépendances qui peuvent limiter sa capacité d’action. Cinq dimensions méritent une attention particulière.
La dépendance applicative
Certaines applications sont devenues indispensables au fonctionnement de l’entreprise et très difficiles à remplacer. Pas nécessairement parce qu’elles sont techniquement irremplaçables, mais parce qu’elles portent des années de paramétrage, de données, de processus métiers adaptés à leur logique.
La dépendance fournisseur
Un éditeur, un intégrateur ou un infogéreur peut devenir critique dès lors qu’il concentre des compétences que l’entreprise n’a plus en interne ou des données qu’elle ne peut pas récupérer facilement. Cette dépendance peut aussi exposer à des risques réglementaires : un fournisseur soumis à une juridiction étrangère peut être contraint de communiquer des données, même hébergées localement.
La dépendance aux données
Savoir où sont les données, comment y accéder, comment les récupérer et dans quel format, c’est la base. Beaucoup d’organisations découvrent, lors d’un changement de solution ou d’un incident, que leurs données sont dispersées entre plusieurs environnements, dans des formats propriétaires, sans procédure d’export documentée.
La dépendance contractuelle
Les clauses de réversibilité, les coûts de sortie, les durées d’engagement minimum ou les conditions de migration sont souvent négligées au moment de la signature et redécouvertes au pire moment. Un contrat mal cadré peut transformer un choix technique en verrou stratégique pendant plusieurs années.
La dépendance organisationnelle
Certaines connaissances critiques reposent sur une ou deux personnes, internes ou externes. Quand le fonctionnement d’une application, d’une architecture ou d’un processus dépend trop fortement d’individus identifiés, la maîtrise du SI devient fragile. Un départ, une indisponibilité, et la DSI se retrouve aveugle sur une partie de son propre SI.
De la dépendance subie à la souveraineté pilotée
La souveraineté du SI, ce n’est pas supprimer toutes les dépendances. Ce serait irréaliste et contre-productif. Dépendre d’un ERP bien intégré et solidement contractualisé n’est pas un problème. Dépendre d’un outil secondaire dont les données sont impossibles à exporter, l’est davantage.
L’enjeu est de choisir ses dépendances, de les assumer et de les piloter.
Pour y parvenir, la DSI peut structurer son analyse autour de quelques critères concrets :
- Criticité métier : que se passe-t-il si cette application ou ce fournisseur devient indisponible demain ?
- Sensibilité des données : quelles données sont exposées, et sous quelle juridiction ?
- Facilité de remplacement : combien de temps faudrait-il pour migrer, à quel coût, avec quelles équipes ?
- Réversibilité contractuelle : les clauses de sortie sont-elles connues, testées, opérationnelles ?
- Niveau de documentation : si les personnes qui connaissent cette application partent, qu’est-ce qu’il reste ?
Ce travail de qualification n’a pas vocation à tout remettre en cause. Il permet d’identifier les zones où une perte de maîtrise aurait un impact réel et de concentrer les efforts là où ils sont vraiment nécessaires.
Concrètement, cela peut aboutir à des décisions très différentes selon les situations : renégocier un contrat pour y inclure des clauses de réversibilité solides, documenter une architecture critique, rapatrier une compétence en interne, planifier une migration sur deux ans, ou simplement décider d’assumer une dépendance en la suivant de plus près.
Pourquoi la cartographie du SI devient indispensable
On ne peut pas piloter ce qu’on ne voit pas. Et c’est précisément le problème de beaucoup de DSI face à la souveraineté : les dépendances existent, mais elles ne sont pas visibles.
C’est le rôle de la cartographie du système d’information, à condition de ne pas la réduire à un simple inventaire de logiciels. Une liste d’applications ne dit pas grand-chose sur les dépendances réelles. Ce qui compte, c’est de comprendre comment le SI fonctionne : quelles applications soutiennent quels processus métiers, où circulent les données, quels fournisseurs interviennent et dans quel cadre contractuel, quels composants sont critiques, quels risques sont associés à chaque brique.
Cette vision consolidée change concrètement ce que la DSI peut faire :
- Identifier les applications critiques et évaluer leur niveau de dépendance fournisseur
- Repérer les données sensibles et tracer leur circulation dans le SI
- Qualifier les contrats en lien avec les usages réels
- Repérer les zones de fragilité organisationnelle, là où la connaissance repose sur trop peu de personnes
- Construire des plans de réversibilité concrets, basés sur une réalité documentée plutôt que sur des suppositions
La cartographie devient aussi un support de dialogue avec la direction générale. Parler de souveraineté du SI sans données objectives, c’est difficile à défendre dans une réunion de CODIR. Avec une cartographie claire des dépendances critiques, des risques associés et des plans d’action priorisés, la DSI peut sortir d’un discours technique pour parler stratégie et obtenir les arbitrages nécessaires.
La souveraineté du SI n’est pas un slogan technologique. C’est une condition de liberté stratégique. Elle repose sur une capacité très concrète : savoir de quoi le SI dépend, mesurer les risques associés, prioriser les actions et conserver des marges de manœuvre sur les composants critiques.
Pour les DSI, la priorité n’est donc pas nécessairement de tout changer. C’est d’abord de rendre visibles les dépendances qui limitent leur capacité d’action et de décider, en connaissance de cause, lesquelles sont acceptables et lesquelles ne le sont plus.
