Dans un écosystème numérique dominé par quelques grands fournisseurs mondiaux, la question de la souveraineté technologique et de la maîtrise de ses dépendances est devenue stratégique pour les Directions des Systèmes d’Information (DSI). Pourtant, toutes les dépendances ne se valent pas, et toutes ne peuvent pas être réduites avec le même effort ou la même efficacité. L’enjeu pour le DSI n’est donc pas seulement de réduire les dépendances, mais de hiérarchiser ses actions selon son pouvoir réel d’agir.
La dépendance au matériel, par exemple, est épisodique (bien que régulière) et est une problématique d’approvisionnement : une fois équipé, il n’y a plus véritablement de dépendance, le matériel vous appartient. Une dépendance à Microsoft Office 365 est d’un autre niveau ; elle est immédiate, permanente mais aussi réversible ; des alternatives nombreuses existent, ici et maintenant.
Comment prioriser et s’y retrouver dans les domaines sur lesquels on peut agir ?
La tâche peut sembler ardue, voire désespérante, et il n’est pas rare que l’action soit paralysée par le constat d’un niveau de dépendance tellement élevé et multifactoriel qu’on ne sait par quel bout entamer la transformation. Ce petit guide a pour objectif d’éclaircir un peu la problématique.
1. Identifier les niveaux de dépendance
Avant de définir une stratégie, il peut être utile d’établir une cartographie des dépendances. Cette cartographie peut inclure les catégories suivantes :
- Infrastructures matérielles et réseau mondial : processeurs, mémoire, fibres optiques, câbles sous-marins, liaisons intercontinentales.
→ Zone d’action quasi nulle pour une DSI : ces dépendances sont globales et structurelles.
- Ressources énergétiques et logicielles verticales : alimentation électrique, refroidissement, outils métiers propriétaires.
→ Zone d’action limitée : il est parfois possible de négocier, d’optimiser, ou de diversifier, mais rarement de remplacer totalement.
- Couches logicielles et infrastructurelles : systèmes d’exploitation, bases de données, services de collaboration, cybersécurité, cloud, applications internes.
→ Zone d’action forte : le DSI peut ici concevoir une stratégie de substitution, d’hybridation ou d’autonomie.
2. Prioriser selon son pouvoir d’agir
Une approche pragmatique consiste à classer les dépendances selon deux axes :
- Le niveau de risque (impact sur la continuité, la sécurité, la souveraineté, ou le coût total).
- Le pouvoir d’action (capacité technique, humaine, financière et organisationnelle à agir).
Le croisement de ces deux axes permet d’obtenir quatre classes de priorisation :
- A. Risque élevé, pouvoir d’agir fort → priorité absolue.
Exemple : solutions virtualisation, de sauvegarde, de cybersécurité, d’authentification ou de gestion des données dépendantes d’un unique fournisseur. Des alternatives open source (ex. FreeIPA, Keycloak, OPNsense) peuvent être déployées en interne.
Généralement invisible pour les utilisateurs comme pour les décideurs, ce travail peut être réalisé rapidement et efficacement. Les solutions sont nombreuses et, moyennant une gestion de projet correcte, relativement simple à mettre en œuvre. Des prestataires sont disponibles pour déployer des solutions qui ne seront pas dépendantes d’acteurs tiers
- B. Risque élevé, pouvoir d’agir faible → vigilance stratégique.
Exemple : dépendance aux fournisseurs énergétiques. Ici, la résilience passe par la redondance, les audits de continuité, et le dialogue avec les partenaires publics.
Monitoring, choix de fournisseurs attachés à l’autonomie stratégique et attention portée au bon fonctionnement des services.
- C. Risque faible, pouvoir d’agir fort → opportunité progressive.
Exemple : migration d’une suite bureautique vers une alternative libre (LibreOffice, OnlyOffice, Nextcloud). Ce type d’action accroît la maîtrise tout en servant de levier culturel interne.
Ici, l’impact sur les utilisateurs est direct, et le changement visible. Chaque déploiement doit être précédé d’une réflexion sur la stratégie de migration, l’accompagnement au changement et l’effort de formation (si nécessaire). Il peut être sage de commencer par une réponse à des besoins non couverts. Un nouvel outil, mis à disposition d’utilisateurs qui n’en disposaient pas auparavant, ne souffrira pas d’une comparaison avec l’existant (et pour cause). Dans un deuxième temps, le remplacement de solutions propriétaires par des solutions libres pourra être envisagé dans un contexte de confiance installée.
- D. Risque faible, pouvoir d’agir faible → faible priorité.
Exemple : dépendance au silicium ou au réseau mondial. Ces sujets sortent du périmètre d’action d’une DSI.
Sur la base de ce classement, une stratégie intéressante pourrait donc être de porter, dans un premier temps, son attention sur les logiciels d’infrastructure (A), avant de passer aux logiciels communs (C) avec deux phases : commencer par répondre aux besoins non couverts au moyen de solutions libres puis réfléchir, en lien avec les services, au remplacement de certaines solutions logicielles.
La documentation et le monitoring de l’infrastructure et des outils déployés doivent permettre de sécuriser l’ensemble des solutions installées.
3. Domaines d’intervention concrets
Voici quelques domaines où le DSI peut réellement agir :
- Infrastructure et cybersécurité : internaliser les services essentiels (DNS, DHCP, NTP, pare-feu), réduire les dépendances aux solutions SaaS, tester des outils open source éprouvées.
- Collaboration et communication : privilégier des solutions maîtrisées et interopérables (Matrix, Nextcloud, BigBlueButton, Peertube, etc.).
- Systèmes et données : adopter des OS open source, standardiser les bases de données sur des formats ouverts, renforcer la portabilité.
- Cloud et hébergement : mettre en place une stratégie d’hybridation (cloud public + interne + edge), pour combiner flexibilité et maîtrise de l’environnement.
- Gouvernance et culture : adapter sa politique de recrutement, former les équipes, documenter toutes les solutions déployées, intégrer la réversibilité contractuelle dans les appels d’offres, et développer une culture de l’indépendance numérique.
4. Agir progressivement mais durablement
La réduction des dépendances est un processus continu, pas une révolution brusque. Les étapes typiques sont :
- Mesurer la dépendance (inventaire applicatif et contractuel).
- Qualifier les risques (juridiques, financiers, opérationnels, réputationnels).
- Définir une stratégie d’action priorisée.
- Piloter la transformation par des projets concrets et mesurables.
- Ancrer la culture d’autonomie numérique auprès des équipes.
La problématique des compétences (et de l’appétence pour le projet) est centrale, comme je l’explique dans cet article. Une mise à niveau de l’équipe (modification des fiches de poste, politique de recrutement, formations éventuelles) est indispensable. S’appuyer sur le turnover naturel de l’équipe pour enrichir l’équipe de profils correspondant au nouveau projet est un facteur majeur de succès.
5. Le DSI, architecte de la résilience
Réduire ses dépendances, c’est gagner en robustesse, agilité et souveraineté. Le rôle du DSI évolue ainsi d’un simple gestionnaire d’infrastructures à un architecte de la résilience numérique. Agir là où c’est possible et fonction de ses capacités, surveiller là où c’est nécessaire, et influencer là où c’est stratégique — telle est la ligne directrice qui peut vous permettre d’avancer vers une autonomie plus grande et une réelle maîtrise de votre système d’information.
Image d’illustration : photo de AbsolutVision sur Unsplash
