VMware-Broadcom : le vrai coût de la dépendance numérique
Un cas d'école, au sens propre
Lorsque Broadcom a racheté VMware, beaucoup y ont vu une opération financière. Les DSI, eux, y ont découvert quelque chose de beaucoup plus inquiétant. En effet, le jour où un fournisseur devient incontournable, ce n'est plus le client qui choisit. C'est le fournisseur qui fixe les règles. Hausse brutale des licences, disparition de certaines offres, nouveaux contrats imposés : le cas VMware est devenu le révélateur d'un phénomène plus profond, celui de la dépendance numérique. Sur les premiers renouvellements post-acquisition, plusieurs médias spécialisés ont rapporté des hausses tarifaires de plusieurs centaines de pour cent pour certains grands comptes. Quelques organisations ont même évoqué des augmentations supérieures à 1 000 %, faute d'alternative immédiatement mobilisable.
Les politologues Henry Farrell et Abraham Newman ont forgé le concept d'« interdépendance militarisée » (weaponized interdependence). Il décrit comment une position centrale dans une infrastructure mondiale peut devenir un levier de pouvoir. Ainsi, le dossier VMware montre que cette dépendance numérique ne concerne pas seulement les États : elle s'applique aussi aux grandes infrastructures numériques privées.
Les entreprises peuvent encore arbitrer un budget ou renégocier un contrat. Or, l'école publique ne peut pas interrompre un service parce qu'un fournisseur a changé de politique commerciale. Lorsqu'une dépendance devient critique, c'est la continuité du service public qui est en jeu.
Une dépendance numérique qui ne dit pas son nom
L'Éducation nationale a additionné, ces quinze dernières années, les dépendances numériques sans jamais les gouverner comme telles. Les déploiements massifs de Chromebooks dans certaines académies et collectivités illustrent cette logique. Ce choix est souvent analysé sous l'angle du coût, de la simplicité de gestion ou des usages pédagogiques — plus rarement sous celui de la dépendance stratégique. Par ailleurs, les décisions successives des autorités de protection des données danoise et néerlandaise ont rappelé qu'un hébergement européen ne suffit pas à garantir la maîtrise effective des traitements. C'est le cas notamment lorsque l'architecture globale reste sous le contrôle d'un acteur extra-européen.
C'est tout l'enjeu de ce que j'appelle la dette de dépendance. À la différence de la dette technique, elle ne se voit pas dans le code ou l'infrastructure. Elle se loge plutôt dans les clauses de sortie qu'on n'a pas négociées, les formats propriétaires qu'on a laissés s'installer, les compétences qu'on n'a pas maintenues en interne. Or, elle ne se paie pas tout de suite : elle se paie le jour où le fournisseur change les règles. Et ce jour-là, il est déjà trop tard pour négocier.
Pour avoir dirigé les systèmes d'information de deux grandes académies, j'ai souvent constaté un même réflexe. Les décisions technologiques sont évaluées à l'aune de leur coût immédiat ou de leur facilité de déploiement, rarement de leur coût de sortie. C'est pourtant ce dernier qui révèle la véritable dépendance.
Aujourd'hui, cette dépendance ne porte plus seulement sur les infrastructures. Elle se loge également dans les interfaces, les API et les identités numériques. Elle concerne aussi les plateformes collaboratives et, désormais, les modèles d'intelligence artificielle qui structurent nos usages quotidiens.
Ce que le cas VMware devrait nous enseigner
Trois leçons du dossier VMware-Broadcom transposent directement à l'école publique.
La réversibilité n'est pas une clause, c'est une capacité. Une clause de réversibilité sur le papier ne protège personne si l'organisation a perdu, en interne, les compétences pour réellement migrer. C'est vrai pour un environnement de virtualisation d'entreprise. Ce l'est tout autant pour un environnement numérique de travail académique construit autour d'un seul écosystème.
On ne négocie bien que ce que l'on connaît. On ne peut hiérarchiser des dépendances qu'on n'a pas identifiées. Combien d'académies et de collectivités seraient aujourd'hui capables de dire, application par application, quelles briques sont réellement substituables à court terme et lesquelles ne le sont pas ?
Le rapport de force se construit avant la crise, pas pendant. Les entreprises touchées par le changement de politique VMware n'ont pas eu le temps de s'organiser : elles ont subi. Ainsi, la gouvernance des dépendances numériques consiste précisément à ne pas attendre ce moment-là pour se poser la question.
L'angle mort de la gouvernance des dépendances numériques
Le débat sur la souveraineté numérique se concentre souvent sur la couche technique — cloud souverain, SecNumCloud, hébergement européen. C'est nécessaire, mais insuffisant. Le véritable déficit n'est pas technique. Il est dans la gouvernance, dans l'absence d'instance qui arbitre réellement. Au niveau d'une académie ou d'un ministère, personne ne tranche entre facilité d'usage à court terme et maîtrise à long terme. Le risque n'est plus la panne. Il est dans la normalisation silencieuse d'une dépendance : on cesse même de la questionner parce qu'elle simplifie le quotidien.
La dette de gouvernance produit, progressivement, la dette de dépendance.
Un pilotage déjà engagé, mais encore incomplet
Il serait injuste de laisser croire que rien n'est fait. Lors de son audition devant la commission d'enquête parlementaire sur les dépendances numériques, le directeur du numérique pour l'éducation a rappelé les actions déjà engagées par le ministère. Elles comprennent le recours à Linux pour le socle technique, la priorité donnée aux logiciels libres, un cadre de cohérence technique limitant les dépendances aux technologies non européennes, et le développement de services collaboratifs reposant sur des briques ouvertes.
Cette stratégie est réelle et mérite d'être saluée. Mais elle concerne essentiellement les infrastructures ministérielles. Elle ne couvre que partiellement les choix opérés depuis des années par les académies et les collectivités. Ces choix concernent les équipements, les environnements numériques ou les services cloud. Le ministère sécurise progressivement son infrastructure centrale. Mais le front-end pédagogique — celui qui structure le quotidien des élèves — demeure largement tributaire des choix des académies et des collectivités. C'est là que la gouvernance des dépendances reste à construire.
Gouverner la dépendance numérique avant de choisir la technologie
Rien de ce qui précède ne plaide pour un système d'information scolaire totalement autarcique. Cet objectif est hors de portée, dans l'éducation comme ailleurs. En revanche, le service public doit s'appliquer à lui-même l'exigence qu'il devrait exiger de ses fournisseurs : savoir ce dont il dépend, en mesurer le poids, et conserver la capacité d'en sortir avant d'en avoir besoin.
C'est précisément pour éviter cette situation que je propose une nouvelle grille de lecture : l'Analyse d'Impact des Dépendances Numériques (AIDN), à l'image de l'analyse d'impact prévue par le RGPD. Avant toute décision structurante, elle viserait à évaluer le coût stratégique d'une dépendance, les conditions de sa réversibilité et le maintien des compétences nécessaires pour l'exercer. Car on ne gouverne correctement que ce que l'on mesure.
La question n'est donc plus de savoir si nous dépendons de fournisseurs internationaux. Elle est de savoir si nous disposons encore, collectivement, des compétences et de la gouvernance nécessaires pour choisir nos dépendances plutôt que les subir.
Une dépendance numérique n'est jamais problématique tant que tout fonctionne. Elle le devient le jour où l'on découvre que l'on n'a plus réellement le choix. Gouverner les dépendances numériques ne consiste pas à rechercher une impossible autonomie complète. Il s'agit de préserver, dans la durée, la liberté de choisir.
La véritable souveraineté ne consiste pas à tout produire soi-même. Elle consiste à pouvoir partir lorsque partir devient nécessaire.
La question n'est donc plus de savoir quelles technologies nous utilisons, mais lesquelles nous sommes encore capables de quitter.