Quitter Microsoft 365 ne se résume pas à remplacer Outlook, Teams ou SharePoint. Au fil des années, les entreprises ont construit autour de ces outils des processus métiers, des automatisations et des habitudes de travail qui rendent toute migration complexe. Dans cette tribune exclusive, Veronika Mazour-Mestrallet, CEO et cofondatrice d’eXo Platform, explique pourquoi la souveraineté numérique passe moins par une rupture brutale avec Microsoft que par la capacité à réduire progressivement ces dépendances et à retrouver une véritable liberté de choix.
Remplacer Outlook, Teams, OneDrive ou la suite Office ne suffit pas à sortir de l’écosystème Microsoft. Avec le temps, la dépendance s’étend à l’architecture du système d’information, aux processus métiers, aux compétences internes et au modèle économique.
Pour Veronika Mazour-Mestrallet, directrice générale d’eXo Platform, il faut regarder au-delà des applications visibles : comprendre où se nichent les dépendances, comment elles se renforcent entre elles et comment les réduire progressivement pour préserver la réversibilité et retrouver une capacité de choix.
Derrière les applications visibles, plusieurs couches du système d’information
On peut représenter cet ensemble comme un arbre : Teams, Outlook ou OneDrive en sont les feuilles visibles, mais ils reposent sur des racines qui s’étendent dans le système d’information. Un fichier partagé dans Teams s’appuie notamment sur SharePoint, tandis qu’Outlook s’inscrit dans un environnement qui repose sur Exchange. SharePoint ne se limite d’ailleurs pas au stockage : il peut aussi structurer les documents, les projets, les règles d’accès, les procédures et leurs circuits de validation.
À mesure que l’on descend dans l’architecture, d’autres briques apparaissent : Entra ID pour la gestion des identités et des accès, Intune pour l’administration des terminaux, Defender et Purview pour certaines fonctions de sécurité, de conformité et de gouvernance des données, puis éventuellement Azure pour l’infrastructure cloud. Remplacer une application ne revient donc pas seulement à changer l’outil visible, mais à intervenir dans un ensemble de couches qui se sont imbriquées au fil du temps.
Les usages métiers créent des dépendances plus difficiles à cartographier
À cette architecture s’ajoutent les usages et les processus construits au fil des années. Ils sont plus difficiles à repérer car ils ne correspondent plus à un produit clairement identifié, mais à des habitudes de travail, des automatisations et des applications intégrées au fonctionnement quotidien. Un service RH peut ainsi avoir structuré dans SharePoint ses procédures et ses documents, puis ajouté des circuits de validation avec Power Automate, des formulaires ou de petites applications métier. Au moment de migrer, l’enjeu n’est plus seulement de remplacer SharePoint, mais d’identifier tout ce qui dépend de cette organisation et de déterminer ce qu’il faudra reprendre, adapter ou reconstruire.
Cette logique vaut aussi pour les applications développées en interne ou les solutions externes connectées à l’environnement Microsoft. Microsoft Graph, par exemple, permet à des applications d’accéder aux utilisateurs, groupes, mails, calendriers, documents ou autres données de l’environnement Microsoft. Une application peut donc ne pas être éditée par Microsoft tout en restant fortement dépendante de ses services. Cette dépendance peut concerner des usages aussi différents que la téléphonie intégrée à Teams ou des fichiers Excel enrichis pendant des années de macros sur lesquelles reposent certains traitements financiers. Pris isolément, chacun de ces usages peut sembler remplaçable ; ensemble, ils forment un réseau de dépendances difficile à cartographier et à reproduire ailleurs.
La dépendance se joue aussi dans les compétences et les coûts
Lorsqu’une DSI exploite depuis des années Azure, les outils de sécurité Microsoft, Entra ID ou Intune, ses équipes ont acquis une connaissance approfondie de cet environnement. Changer de technologie implique aussi de faire évoluer les compétences et les pratiques d’administration.
À cela s’ajoute une dépendance économique. Microsoft regroupe de nombreux services dans des offres groupées : une fonction peut déjà être comprise dans le contrat, tandis qu’adopter une application alternative ajoute une dépense sans supprimer le coût de l’offre existante. Ce mécanisme favorise le maintien des outils déjà en place et renforce progressivement l’imbrication entre architecture, usages, compétences et modèle économique.
Sortir de Microsoft n’implique pas de tout remplacer d’un seul coup
Face à cet empilement, un basculement complet et immédiat paraît difficilement envisageable pour de nombreuses organisations. L’objectif est plutôt de retrouver progressivement de la liberté dans les choix technologiques, en commençant par rendre visibles les dépendances existantes : données, processus métiers, applications connectées à l’environnement Microsoft, briques critiques pour la sécurité ou encore compétences internes.
Cette cartographie sert ensuite à établir des priorités. Certaines briques peuvent être remplacées rapidement, tandis que d’autres demanderont plusieurs années. La trajectoire dépendra de chaque organisation : certaines pourront, par exemple, changer leurs applications tout en conservant temporairement leur système de gestion des identités. Cette coexistence n’est pas un échec de la stratégie de sortie. Elle peut au contraire être la condition pour rendre celle-ci réaliste.
L’interopérabilité devient alors essentielle pour organiser cette transition. Elle facilite la coexistence entre l’environnement existant et de nouvelles solutions pendant la migration, sans imposer un remplacement général en une seule fois. L’enjeu n’est pas nécessairement de supprimer toute technologie Microsoft, mais de retrouver assez de liberté pour rester en mesure de faire d’autres choix à l’avenir.
Les fournisseurs européens doivent eux aussi changer d’échelle
Cette trajectoire ne repose pas uniquement sur les organisations qui souhaitent réduire leur dépendance. Elle impose aussi une responsabilité aux fournisseurs européens. Remplacer une suite fortement intégrée par une juxtaposition de logiciels indépendants ne suffit pas : les alternatives doivent être capables de fonctionner ensemble et de proposer une continuité crédible entre messagerie, collaboration, bureautique, visioconférence, téléphonie, gestion des terminaux, hébergement et sécurité.
L’enjeu n’est pas de reconstruire un nouveau monolithe européen, mais un écosystème suffisamment intégré et industrialisé pour que le client n’ait pas à recréer lui-même toutes les connexions et intégrations qui font aujourd’hui la force de l’écosystème Microsoft. C’est notamment la logique poursuivie avec Live Collaboration, l’écosystème construit par Orange Business avec plusieurs éditeurs européens, dont eXo Platform. Des initiatives comme EuroCommons ou le Digital Commons EDIC vont également dans ce sens, en travaillant sur l’interopérabilité, la mutualisation et le développement de briques communes à l’échelle européenne.
L’IA, nouvelle couche de dépendance
L’intelligence artificielle risque désormais d’ajouter une nouvelle couche à cet empilement. Les organisations commencent à construire des agents qui s’appuient sur leurs données, leurs droits d’accès et leurs processus métiers, et qui pourront progressivement agir dans leurs applications et déclencher des automatisations. Si ces usages se développent dans un environnement trop difficile à quitter, ils risquent d’ajouter de nouvelles dépendances à celles déjà accumulées.
La réversibilité doit donc être pensée dès la conception de ces nouveaux usages. Réduire la dépendance à Microsoft ne signifie pas nécessairement supprimer toute technologie Microsoft. Cela signifie surtout éviter de se retrouver dans une situation où changer est devenu techniquement, opérationnellement ou économiquement impossible. La souveraineté numérique commence là : retrouver la capacité de choisir aujourd’hui et demain.
