Sortir de l'orbite Microsoft : le guide de migration vers ONLYOFFICE pour les équipes IT européennes

# Sortir de l'orbite Microsoft : le guide de migration vers ONLYOFFICE pour les équipes IT européennes

> Contexte 2026. Depuis l'entrée en vigueur du Data Act européen et la montée en puissance des audits de conformité, les DSI d'ETI françaises, allemandes et néerlandaises sont de plus en plus nombreux à poser la même question : peut-on continuer à confier la bureautique de l'entreprise à un acteur soumis au droit américain ? Ce guide ne vend pas ONLYOFFICE. Il analyse ce qu'une migration vers cette suite implique concrètement — techniquement, contractuellement, culturellement — pour une organisation qui veut reprendre la main sur son infrastructure documentaire.

Pourquoi ce guide maintenant : ce que le verrouillage Microsoft révèle

Avant les étapes, un diagnostic lucide s'impose.

L'acteur américain dominant ne vend plus simplement un logiciel de bureautique. Il vend un écosystème : authentification (Azure AD / Entra ID), stockage (OneDrive/SharePoint), communication (Teams), automatisation (Power Platform), et désormais couche d'IA (Copilot). Chaque brique rend la suivante plus difficile à remplacer. C'est un modèle de verrouillage par la valeur ajoutée incrémentale — chaque nouvelle fonctionnalité augmente le coût de sortie.

Côté contrat, les clauses de transfert de données vers des serveurs américains n'ont pas disparu avec le Privacy Shield, ni avec le Data Privacy Framework. Elles se sont simplement déplacées dans des niveaux de documentation moins visibles. Un RSSI qui n'a pas audité ses amendements contractuels depuis 18 mois opère dans une zone grise juridique réelle.

ONLYOFFICE — suite développée par l'éditeur letton Ascensio System SIA, donc soumis au droit européen — n'est pas une réponse magique. C'est une hypothèse de travail sérieuse, à condition de l'évaluer méticuleusement.

Étape 1 — Cartographier votre dépendance réelle avant de toucher quoi que ce soit

La première erreur des migrations échouées : commencer par le déploiement logiciel plutôt que par l'audit de la dépendance.

Ce qu'il faut produire :

• Un inventaire des formats de fichiers en circulation dans l'organisation (DOCX, XLSX, PPTX natifs ? Macros VBA actives ? Fichiers liés à des add-ins propriétaires ?)
• La liste des automatisations internes qui s'appuient sur COM/OLE ou sur l'API Microsoft Graph
• Une cartographie des flux de données : quels documents quittent le périmètre européen, vers quels data centers, dans quel cadre contractuel ?
• L'identification des usages collaboratifs en temps réel (co-édition) et leur criticité métier

Ce que cet audit révèle systématiquement :

Dans la majorité des ETI européennes auditées par des cabinets spécialisés, 15 à 20 % des fichiers bureautiques comportent des dépendances actives (macros, liaisons externes, formulaires liés à des bases de données). Ces fichiers ne migreront pas automatiquement. Ils constituent le vrai sujet de la migration, pas les documents Word standards.

Sans cet audit, toute estimation de charge de migration est une fiction.

Étape 2 — Choisir votre mode de déploiement : l'enjeu de souveraineté se joue ici

ONLYOFFICE se déploie selon plusieurs modèles. Ce choix n'est pas qu'une question technique — c'est le choix de souveraineté lui-même.

Option A : On-premise sur infrastructure propre ou hébergeur européen

C'est le modèle le plus souverain. Vous contrôlez les données, les mises à jour, les accès. La charge d'administration revient à votre équipe IT. Pour les ETI sans DSI structurée, c'est un engagement réel.

Option B : Instance managée chez un hébergeur certifié européen (SecNumCloud ou équivalent national)

Le compromis pertinent pour une PME qui n'a pas la capacité d'administrer une infrastructure documentaire 24/7. La condition sine qua non : vérifier que l'hébergeur n'a pas de clause de sous-traitance vers des acteurs américains pour la couche infrastructure.

Option C : ONLYOFFICE Cloud hébergé par l'éditeur

Ascensio est basé à Riga. Juridiquement, vous restez en droit européen. Mais vous perdez le contrôle opérationnel. Ce modèle se justifie pour une phase de test ou pour des structures très légères.

Ce que ce choix révèle sur le verrouillage précédent : Si votre organisation ne peut pas répondre en moins d'une heure à la question « où sont physiquement stockés nos documents de travail », c'est que la dépendance à l'acteur américain a déjà effacé cette visibilité.

Étape 3 — Gérer la compatibilité documentaire sans se voiler la face

ONLYOFFICE affiche une compatibilité élevée avec les formats OOXML (la famille DOCX/XLSX/PPTX). Dans la pratique, la compatibilité est solide sur les documents courants. Elle se dégrade sur trois catégories précises :

1. Les macros VBA complexes. ONLYOFFICE dispose d'un moteur de macros JavaScript (compatible avec une partie de la logique VBA), mais la migration des macros avancées requiert un recodage manuel. Il n'existe pas de convertisseur automatique fiable à ce jour.

2. Les fonctionnalités de mise en page avancée. Certains comportements typographiques, les styles imbriqués complexes ou les mises en page multi-colonnes se comportent différemment. L'écart est généralement cosmétique, mais il peut être bloquant pour des documents contractuels ou des modèles normalisés.

3. Les add-ins tiers. Si votre organisation s'appuie sur des extensions développées pour l'écosystème Microsoft, elles n'existent pas en version ONLYOFFICE. C'est un point d'arrêt qui doit être identifié à l'étape 1.

Action concrète : Constituer un corpus de test de 50 à 100 documents représentatifs de votre production réelle (pas des échantillons propres), les ouvrir dans ONLYOFFICE, documenter les dégradations. Ce test prend une journée. Il évite six mois de déploiement qui se retourne contre vous.

Étape 4 — Planifier la montée en compétence des utilisateurs sans dramatiser

Le changement d'interface est réel. Il ne justifie ni la paralysie décisionnelle ni un plan de conduite du changement disproportionné.

Ce qui change pour l'utilisateur final :

L'interface ONLYOFFICE est délibérément proche de celle de la suite Microsoft dans sa version ruban. L'objectif est clairement de réduire la friction de transition. Pour un usage courant (rédaction, tableur simple, présentation), la courbe d'apprentissage est faible.

Ce qui demande de l'accompagnement :

• Les utilisateurs « power users » qui ont automatisé des workflows via macros ou Power Automate
• Les équipes qui utilisent la co-édition intensive en temps réel (ONLYOFFICE le supporte, mais différemment)
• Les processus qui s'appuyaient sur des formulaires Word liés à des bases de données internes

Format recommandé : Une session de 2 heures par profil utilisateur (standard / avancé), organisée en interne par les référents IT, suffit dans la majorité des cas. Évitez les formations génériques achetées à l'extérieur — elles ne connaissent pas votre configuration.

Étape 5 — Sécuriser la transition documentaire sans coupure brutale

Une migration bureautique ne se fait pas en bascule unique un lundi matin. Le modèle de coexistence temporaire est la norme, pas l'exception.

Protocole de coexistence :

• Définir un périmètre pilote (une équipe, un service) pour un déploiement de 60 à 90 jours en conditions réelles
• Maintenir la lecture/écriture des formats OOXML dans ONLYOFFICE pendant toute la phase de transition (l'éditeur supporte nativement ces formats en lecture et écriture)
• Ne pas forcer la conversion vers le format ODF en phase initiale — c'est un objectif de souveraineté à moyen terme, pas un prérequis au démarrage
• Documenter les incidents de compatibilité remontés par le pilote : c'est la base de votre plan de traitement avant déploiement généralisé

Sur la question ODF vs OOXML : À terme, migrer vers l'Open Document Format est cohérent avec une stratégie de souveraineté (format ouvert, non contrôlé par un acteur américain). Mais imposer ce changement en même temps que le changement d'outil revient à cumuler deux ruptures. Séquencez.

Étape 6 — Encadrer contractuellement le nouveau périmètre

Changer d'outil sans revoir les contrats associés ne desserre pas le verrouillage — il le déplace.

Points de vigilance contractuels avec tout nouvel éditeur, y compris européen :

• Clause de portabilité des données : pouvez-vous récupérer l'intégralité de vos documents et métadonnées dans un format exploitable si vous résiliez ?
• Clause de sous-traitance technique : l'éditeur peut-il déléguer l'hébergement ou le support à un tiers non-européen sans vous en informer ?
• Modalités d'audit : avez-vous le droit de faire auditer les conditions de traitement de vos données ?
• Engagement de maintien des formats ouverts : l'éditeur s'engage-t-il à maintenir la compatibilité ODF et OOXML dans les versions futures ?

Ces questions valent pour ONLYOFFICE comme pour tout autre acteur. La souveraineté est d'abord une posture contractuelle avant d'être un choix logiciel.

Ce que cette migration ne résout pas

Soyons directs. Migrer la bureautique vers ONLYOFFICE est une étape utile dans une stratégie de souveraineté numérique. Ce n'est pas une stratégie complète.

La messagerie, l'annuaire, la gestion des identités, la visioconférence, la signature électronique — chacun de ces périmètres représente un vecteur de dépendance potentiel indépendant. Une organisation qui déploie ONLYOFFICE mais continue d'utiliser Microsoft Entra ID pour l'authentification n'a desserré qu'un seul maillon d'une chaîne plus longue.

La valeur de ce type de migration est double : elle produit de la souveraineté opérationnelle sur le périmètre documentaire, et elle génère une compétence organisationnelle — la capacité à conduire une migration souveraine — qui sera réutilisable sur les périmètres suivants.

C'est peut-être le gain le plus durable.

*RiffLab Media est un média indépendant. Cet article ne constitue pas une recommandation commerciale pour ONLYOFFICE ou tout autre éditeur. Les éléments présentés sont fondés sur des informations publiquement disponibles en 2026.*