Le métavers de Meta s'effondre : et si nos SI avaient retenu la leçon avant d'y entrer ?

# Le métavers de Meta s'effondre : et si nos SI avaient retenu la leçon avant d'y entrer ?

*Analyse éditoriale — RiffLab Media*

Il y a quelque chose d'instructif — et d'un peu amer — à regarder l'histoire du métavers de Meta se refermer comme elle s'est ouverte : dans le bruit, le spectacle, et l'indifférence finale. En 2021, Mark Zuckerberg montait sur scène pour annoncer la « prochaine étape d'Internet ». Des centaines d'entreprises européennes, attirées par l'ampleur de la mise en scène et la pression des prestataires, ont commencé à allouer des budgets, des équipes, parfois des projets pilotes entiers à cet environnement. En 2026, Meta a silencieusement réorienté ses priorités vers l'IA générative, abandonnant l'infrastructure métavers à un lent assèchement documentaire.

La question que je veux poser ici n'est pas « qui avait raison ? ». Elle est plus inconfortable : combien de DSI et de CTO européens ont embarqué leurs équipes IT dans un écosystème dont ils ne contrôlaient rien — ni la feuille de route, ni les API, ni la pérennité — et combien en ont tiré une leçon structurelle pour la suite ?

Parce que ce qui s'est passé avec le métavers n'est pas un accident. C'est un mécanisme. Et ce mécanisme se répète.

L'histoire courte d'une promesse sans contrat

Remettons les faits en perspective. Entre 2021 et 2023, l'acteur américain a investi des dizaines de milliards de dollars dans la construction d'Horizon Worlds et de l'infrastructure matérielle associée — casques Quest, SDK de développement, environnements collaboratifs professionnels. Des partenariats ont été signés avec des cabinets de conseil, des intégrateurs, des éditeurs de formation. Des entreprises européennes, dans les secteurs de l'industrie, de la santé, de la formation professionnelle, ont lancé des expérimentations.

Puis, progressivement, les signaux ont changé. Les effectifs de la division Reality Labs ont été taillés. La communication s'est déplacée vers l'IA. Les mises à jour d'Horizon Worlds se sont espacées. Les développeurs tiers ont vu leurs roadmaps devenir caduques sans préavis officiel. En 2025-2026, le constat est sans appel : l'acteur américain a pivoté, et ceux qui avaient bâti sur sa plateforme se retrouvent avec des actifs orphelins.

Ce n'est pas un cas isolé. C'est exactement ce qui s'est passé avec Google+ pour les community managers, avec Stadia pour les studios de jeu, avec de nombreux services tiers adossés à des API Twitter/X. La mécanique est toujours la même : une plateforme US ouvre un écosystème, attire les développeurs et les entreprises, puis ferme ou pivote selon ses propres impératifs — sans que les acteurs dépendants n'aient eu leur mot à dire.

Ce que ça a coûté concrètement aux équipes IT

Parce que ce sujet n'est pas seulement stratégique, il est opérationnel. Et il faut appeler les choses par leur nom.

Les équipes IT qui ont accompagné des pilotes métavers ont consacré du temps réel à des intégrations qui ne valent plus rien. Des développeurs ont appris des SDK propriétaires — des outils non portables, non réutilisables en dehors de l'écosystème de l'acteur américain. Des architectes ont conçu des flux de données vers des environnements dont ils n'ont jamais eu accès au code source, ni aux conditions de réversibilité. Des RSSI ont accepté des flux sortants vers des infrastructures américaines soumises au CLOUD Act, souvent au prix d'arrangements contractuels fragiles.

Le coût n'est pas seulement financier — même si les budgets alloués à ces projets pilotes ne seront jamais récupérés. Le coût est en capital humain et en dette technique. Des compétences ont été développées sur des outils morts. Des architectures d'entreprise ont été pensées avec une dépendance externe non maîtrisée au cœur du dispositif. Et le pire : certaines de ces décisions ont été prises sous pression commerciale, parce que les éditeurs partenaires de Meta avaient tout intérêt à vendre la transformation.

Je pense que la vraie question à poser en CODIR aujourd'hui, ce n'est pas « quel est le prochain usage émergent à tester ? ». C'est : « Quel est notre niveau de réversibilité sur chacun des outils qui structurent le quotidien de nos équipes IT ? »

Le vrai problème : la confusion entre adoption et intégration

Il faut être honnête sur la dynamique qui a conduit des entreprises européennes sérieuses à s'exposer de cette façon. Ce n'est ni de la naïveté ni de l'incompétence. C'est une confusion structurelle que l'on retrouve dans beaucoup de décisions IT : la confusion entre tester un usage et intégrer une dépendance.

Quand une équipe IT monte un pilote sur une plateforme externe, elle croit souvent faire quelque chose de limité et de réversible. En réalité, dès lors que des données métier transitent, que des workflows sont reconfigurés autour d'un outil tiers, que des développeurs intègrent une API dans une brique du SI, la dépendance est installée. Elle ne se défait pas en une réunion de direction.

Ce mécanisme est d'autant plus insidieux que les acteurs américains sont précisément très forts pour rendre l'entrée facile et la sortie coûteuse. Les SDK sont bien documentés, les sandbox généreux, les premiers mois gratuits ou quasi-gratuits. C'est la définition même du vendor lock-in à l'échelle plateforme.

Et ici, la souveraineté numérique n'est pas un concept abstrait réservé aux débats de politique industrielle. C'est une question de résilience opérationnelle pour chaque DSI qui se demande demain matin si son SI fonctionnera encore si un acteur américain décide de changer ses priorités.

L'abandon du métavers par Meta est une démonstration grandeur nature. Gratuite. Il serait dommage de ne pas en tirer les conséquences.

Ce que les équipes IT européennes peuvent faire autrement

Je ne vais pas dresser une liste de solutions miracles — ce serait intellectuellement malhonnête. Mais je veux pointer quelques postures concrètes qui changent la donne dans le quotidien des équipes.

Premièrement, distinguer ce qui est expérimental de ce qui est structurant. Un pilote sur une plateforme externe peut avoir du sens, à condition de le cadrer explicitement comme tel : durée limitée, périmètre fonctionnel restreint, données non critiques, et surtout — critère de sortie défini dès le départ. Pas « on verra dans six mois », mais « si dans six mois telles conditions ne sont pas réunies, on sort, et voilà comment ».

Deuxièmement, exiger la portabilité comme critère de sélection non négociable. Avant toute intégration d'un outil tiers dans le SI, la question doit être posée explicitement : que se passe-t-il si cet acteur disparaît, pivote, ou double ses tarifs ? Existe-t-il un format d'export standard ? Une API ouverte ? Une alternative européenne capable de reprendre le périmètre fonctionnel ? Ce n'est pas du pessimisme, c'est de l'architecture.

Troisièmement, cultiver une veille sur les acteurs européens du même espace fonctionnel. Pas pour en faire une liste exhaustive, mais pour s'assurer qu'il existe des alternatives crédibles avant d'installer une dépendance. Des acteurs comme Whereby — entreprise norvégienne — ou des solutions de collaboration bâties sur des protocoles ouverts comme Matrix montrent qu'il est possible de construire des usages collaboratifs sans s'enfermer dans un écosystème propriétaire américain. Ce ne sont pas des exemples parfaits. Mais ce sont des preuves que l'alternative existe.

Quatrièmement — et c'est peut-être le plus difficile — résister à la pression de l'adoption par mimétisme. Beaucoup de pilotes métavers en entreprise n'ont pas été lancés parce que le DSI y croyait. Ils ont été lancés parce qu'un concurrent avait communiqué là-dessus, parce qu'un cabinet de conseil avait mis la technologie dans son rapport annuel, parce qu'un comité de direction voulait montrer que l'entreprise « explorait ». Cette pression existe, elle est réelle. Il faut la nommer pour pouvoir y résister.

2026 : la leçon doit être tirée maintenant, pas au prochain cycle

Nous sommes en 2026 et le cycle recommence déjà. L'IA générative est en train de reproduire exactement la même dynamique : des acteurs américains proposent des plateformes séduisantes, des intégrations faciles, des cas d'usage impressionnants. Des équipes IT européennes commencent à tisser des dépendances dans leurs SI — souvent sans cartographie claire des données qui transitent, sans plan de réversibilité, sans évaluation sérieuse des alternatives européennes.

Je ne dis pas que toute adoption d'un outil américain est une erreur. Ce serait caricatural et contre-productif. Je dis que l'absence de questionnement souverainiste dans la décision d'adoption est une faute professionnelle pour un DSI ou un CTO européen en 2026. Pas une faute morale. Une faute de gouvernance.

L'abandon du métavers par l'acteur américain est une opportunité pédagogique rare. Il illustre, sans ambiguïté, ce qui arrive quand les impératifs stratégiques d'une entreprise californienne cotée en bourse divergent des besoins opérationnels d'une PME industrielle allemande, d'un ETI de services français ou d'un acteur de santé belge. Ces entreprises n'étaient pas dans l'équation de Meta. Elles ne l'ont jamais été.

Il faut arrêter de construire des SI en supposant qu'on l'est.

La souveraineté numérique ne commence pas à Bruxelles dans un règlement. Elle commence dans la salle de réunion où une équipe IT décide d'intégrer — ou non — un outil dont elle ne contrôle ni la feuille de route, ni les données, ni la pérennité. C'est là que tout se joue. Et c'est là, concrètement, que les DSI et CTO européens peuvent reprendre la main.

*Cet article reflète la ligne éditoriale de RiffLab Media. Les positions exprimées sont celles de la rédaction.*