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 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 :

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

L’Assemblée nationale, dans le cadre de la commission d’enquête de l’assemblée nationale sur « les dépendances structurelles et les vulnérabilités dans le numérique et les risques pour l’indépendance de la France », reçoit un certain nombre d’acteurs du numérique.

J’ai parfois le sentiment, en écoutant ces auditions, que l’accent est surtout mis sur le législatif, le financier et le choix des solutions. Sauf que ce que renvoient les intervenants, quand on sait lire entre les lignes, c’est que la problématique est, d’abord et surtout, humaine.

Je note, par exemple, que ceux qui semblent avoir les compétences techniques les moins avancées sont aussi ceux qui ont tendance à mettre en avant la résistance des utilisateurs (« ils ont pris des habitudes »), l’énorme effort d’accompagnement et de formation nécessaire et les coûts élevés du changement. Les intervenants qui disposent de compétences techniques et ont déjà eu à gérer des transformations de ce type sont plutôt rassurant de ce point de vue-là.

Qui résiste vraiment ?

En réalité, c’est du côté des DSI que se trouve la résistance. C’est dans les services informatiques que des habitudes ont été prises, et un autre positionnement permettrait d’envisager l’avenir avec un peu plus de sérénité (et à moindre coût). Problème : il remet en cause l’organisation telle qu’elle est (et dont les DSI qui s’expriment ont la responsabilité) et leur propre capacité à mettre en œuvre un nouveau projet, différent sous bien des aspects.

Edward Jossa, directeur général de l’UGAP, au cours de son audition, évoque le sujet (extrait ici) : il y a une problématique de formation des DSI et de ré-internalisation des compétences. L’UGAP n’est qu’une centrale d’achat, et ce sont les DSI qui font leur choix parmi les logiciels disponibles. Il a raison, et si les DSI ont plutôt tendance à se tourner vers des solutions non souveraines, c’est bien de ce côté-là qu’il faut regarder.

De l’importance du recrutement

Nous avons tous tendance à recruter des profils qui nous ressemblent. Pour pratiquer le recrutement depuis des années, je sais que j’ai tendance à choisir des profils plutôt techniques, parce que c’est le monde d’où je viens. Un DSI qui dispose de compétences fortes en gestion de projets ou de partenaires s’intéressera plutôt à des profils de ce type, et c’est tout à fait adapté dans le contexte classique d’un service informatique où l’on s’appuie sur de la sous-traitance et sur des logiciels du marché, faciles à déployer, intégrés et couramment utilisés. C’est aussi ce à quoi la plupart des écoles pour futurs DSI s’attellent : former au management, à la gestion de projet, à la gestion financière et à l’utilisation des outils les plus courants.

Mais ce fonctionnement est mal adapté à une migration vers les logiciels libres, où les produits sur étagère sont rares et où ils ne donnent leur pleine dimension que quand ils sont gérés par des équipes compétentes (et motivées). Cette orientation technique est aussi celle qui permet de gérer la transition à moindre coût et de prendre en compte l’enjeu de « souveraineté » dans toutes ses dimensions : sécurisation, auto-hébergement, documentation, etc.

Entamer une transition, c’est d’abord prendre conscience de cela : il faut revoir sa politique de recrutement, et éventuellement réorganiser ses équipes, voire changer de responsable informatique. Penser qu’on pourra faire entrer les logiciels libres dans un fonctionnement qui a été pensé pour l’exploitation de logiciels propriétaires, c’est multiplier les probabilités d’échec (et de résistance).

Prendre le risque de l’échec…

Le problème se pose peu pour des logiciels métiers pour lesquels, parce qu’ils ont la compétence et qu’ils en connaissent les fonctionnalités, les prescripteurs sont souvent les services eux-même. Il se pose surtout, et de façon aiguë, pour les solutions communes (messagerie, cloud, etc.) ou d’infrastructure (virtualisation, routage, cybersécurité, etc.).

Plutôt que de réfléchir à un nouveau paradigme, les équipes vont tenter à toute force de faire entrer les nouveaux équipements et logiciels dans un fonctionnement qu’elles connaissent : utilisation d’Active Directory pour l’authentification et le déploiement de logiciels ou de règles de sécurité, intégration des machines Linux dans le domaine Windows, compatibilité avec Outlook, synchronisation des smartphones avec ActiveSync, etc. tout en s’appuyant sur les mêmes prestataires (qui ne sont pas forcément compétents)… je vois cela très régulièrement.

Il existe pourtant de nombreuses solutions permettant de gérer tout cela dans un environnement libre… et hybride (une transition prend du temps et, pendant un long moment, des solutions libres et propriétaires vont coexister, il faut pouvoir gérer), et c’est l’une des clés d’un changement réussi. Encore faut-il les connaître.

Imaginer qu’on va pouvoir opérer un changement de ce niveau avec une équipe qui a parfois peiné pour obtenir un niveau de maîtrise suffisant sur des logiciels propriétaires souvent complexes est une illusion. Revoir sa politique RH, démarrer progressivement et accélérer aux fur et à mesure du renouvellement des profils est beaucoup plus efficace, et moins coûteux. Et étant donné que dans ce domaine (comme dans d’autres), mal faire est pire que ne rien faire, je ne vois pas de meilleure stratégie.

Pour vous en convaincre, regardez de près comment sont constituées les équipes qui avancent vite (DINUM, Échirolles, Gendarmerie…). Vous verrez à quel point elles sont organisées de façon très différente de ce qu’on peut observer habituellement.

Pour un DSI qui n’a pas conscience de ces enjeux et qui ne juge qu’à l’aune de ce qu’il connaît, la perspective d’une réorientation complète de son service pour atteindre un niveau d’autonomie acceptable a de quoi effrayer. D’autant qu’en général il ne sait pas du tout comment s’y prendre : il n’a pas été formé et a in fine du mal à imaginer que cela soit concrètement possible (et donc souhaitable).

Un angle mort

C’est, à mon sens (et pour le moment), l’un des angles morts de cette commission : passer au libre (une des conditions de la souveraineté), ce n’est pas remplacer un logiciel propriétaire par un logiciel libre. Le changement à opérer est beaucoup plus profond. RH, préparation budgétaire, reporting, de nombreuses choses sont à revoir. Peu de DSI sont formés pour le faire, et les dispositions législatives n’aideront pas (elles pourraient même avoir des effets délétères, en obligeant des équipes qui ne sont pas prêtes à adopter un fonctionnement pour lesquelles elles ne sont pas organisées).

Il serait intéressant de se pencher sur cette problématique et d’interroger ceux qui forment, en ce moment-même, les futurs DSI qui sont censés, dans un futur proche, prendre à bras le corps la problématique d’autonomie stratégique qui se pose à nous en raison des récents bouleversements géopolitiques.

Image d’illustration : photo de Ross Findon sur Unsplash
Nombre de mots de cet article produits ou inspirés par une IA : 0

C’est vrai, et plusieurs articles s’en sont fait l’écho dont un, récent, de Médiapart.

Dans un contexte géopolitique où l’autonomie stratégique (ou la souveraineté numérique) est maintenant un sujet, c’est évidemment regrettable. D’autant qu’en parallèle, on entend parler d’initiatives comme NIRD qui adressent avec efficacité les enjeux associés. Mais il faut choisir ses combats, et savoir prioriser ses choix.

Quels sont les enjeux principaux liés aux choix d’un ministère aussi important que celui de l’Éducation Nationale ?

• ne pas se rendre dépendant d’acteurs privés et étrangers ;
• assurer la confidentialité des échanges ;
• protéger les données personnelles ;
• dépenser au mieux l’argent du contribuable ;
• ne pas inscrire dans l’esprit des élèves que PC = Microsoft et smartphone = Google.

La première chose à savoir c’est que, si le ministère s’équipe pour ses besoins propres, il n’équipe pas les établissement scolaires. Écoles primaires et maternelles sont équipées par les communes, les collèges sont équipés par les conseils départementaux et les lycées sont équipés par les conseils régionaux. Et cela concerne aussi bien les élèves que les enseignants.

À cet égard, il n’est peut-être pas inintéressant de se pencher sur les chiffres. De quoi parle-t-on quand on parle de « Ministère de l’Éducation Nationale » ? Combien de personnels concernés ?

Si on exclut les personnels enseignants, environ 350 000 personnes travaillent pour le ministère. Ce sont celles qui sont principalement concernés par l’utilisation des outils Microsoft.

Les enseignants sont autour de 850 000 (710 000 dans le public, et 140 000 dans le privé), et les élèves sont 12,6 millions.

En ne prenant pas en compte les établissements privés sous contrat, le nombre total de personnes qui sont concernées par l’équipement en informatique de l’éducation nationale est donc d’environ 13,7 millions (12,6 millions d’élèves + 710 000 enseignants + 350 000 autres personnels)

Parmi celles-ci, 13,3 millions de personnes sont utilisatrices de matériels et de solutions logicielles proposés par les collectivités, soit 97% de la population concernée par l’éducation nationale (élèves et enseignants). Le choix du ministère pour ses besoins propres ne concerne donc que 3% des personnes équipées.

Cela reste regrettable, d’autant que les échanges entre administration et structures d’enseignements sont nombreux. Cela pourrait compliquer le travail avec les établissements qui font le choix de s’équiper de solutions libres et gratuites (NIRD) ou qui sont équipés par des collectivités qui font aussi un choix de ce type. Mais, d’expérience, ces problèmes de compatibilité sont finalement plutôt rares, et n’empêchent pas les établissements de fonctionner.

Et puis le signal donné par le ministère peut sembler contradictoire, certains se plaignant d’un « faites ce que je dis, pas ce que je fais », qu’il est bien difficile de ne pas entendre. Les choix réalisés par les décideurs ne sont pas sans influence sur les discours tenus dans certains établissements.

Mais on peut aussi imaginer que, si la grand majorité des établissements faisait le choix d’un numérique éthique et durable, cela influencerait sur les choix faits au niveau « central ». Nous sommes dans un système : d’un côté l’autorité, de l’autre le nombre.

En conclusion :

• Quand on soutient une démarche telle que NIRD, on adresse 70% des personnels de l’éducation nationale et 97% de l’ensemble des personnes concernées par leur équipement informatique. On éduque également nos enfants à l’utilisation d’outils qui n’oblitèrent pas leurs libertés.

• Quand on proteste contre un nouveau contrat signé (ou prolongé) avec Microsoft, on adresse les 3% restants (et 30% des personnels).

Au regard des enjeux à adresser, il me semblait important de rappeler ces chiffres.

Soutenons les initiatives des collectivités et établissements qui se posent les bonnes questions, et n’exagérons pas l’impact de décisions qui, finalement, ne concernent que quelques centaines de milliers d’agents et assez peu nos enfants, et donc assez peu l’avenir.

Ajout du 10 avril 2026 : lors d’une audition à l’assemblée nationale, Audran Le Baron, directeur du numérique pour l’éducation, confirme cette analyse et indique le chiffre, plus faible encore, de 40 000 postes équipés avec la suite Microsoft Office. Un extrait est disponible ici.

Merci à Stéphane Paillet et Thierry Joffredo qui, par nos échanges sur Mastodon, ont alimenté cette réflexion.

Image d’illustration : Photo de Vadim Bogulov sur Unsplash