La version CODE 26.04 de Collabora Online, annoncée le 8 juin 2026, inclut des améliorations en matière d'interopérabilité et d'ergonomie des documents. Cependant, ses notes de version ne présentent pas de comparaison contrôlée de la RAM ou de la latence avec ONLYOFFICE Docs. Pour une décision éclairée, il est recommandé d'effectuer des tests de performance sur les configurations exactes que vous prévoyez de déployer, sur le même serveur, avec les mêmes documents, le même navigateur, la même plateforme de stockage et les mêmes actions utilisateur. Les exigences minimales des fournisseurs constituent des indications de planification et non des résultats de performance comparables.
Cette procédure de référence mesure deux éléments distincts : l’utilisation des ressources serveur et le temps perçu par l’utilisateur lors de l’ouverture et de la modification d’un document. Elle ne prétend pas qu’une suite logicielle soit systématiquement plus rapide. La complexité des fichiers, leur intégration, le chemin réseau, les polices utilisées et le nombre de sessions simultanées peuvent influencer le résultat.
Ce que les exigences publiées peuvent – et ne peuvent pas – vous dire
La configuration Docker requise pour ONLYOFFICE est actuellement de 4 Go de RAM et 4 Go de swap minimum. Sa documentation précise que les besoins réels varient en fonction du nombre d'utilisateurs actifs simultanés, du type et de la taille des documents. Son guide de dépannage Docker indique qu'une utilisation de 2 à 4 Go est normale pour quelques dizaines d'utilisateurs actifs. Ces informations concernent la configuration d'ONLYOFFICE et ne permettent pas une comparaison directe avec Collabora.
Collabora indique que les besoins matériels dépendent du nombre d'utilisateurs simultanés ; sa FAQ précise également que les performances diminuent avec l'augmentation du nombre d'utilisateurs simultanés et dépendent des ressources du serveur. CODE et le produit Collabora Online associé constituent deux options de déploiement distinctes. Un test CODE à domicile ne présume pas du déploiement d'un abonnement en production, de même qu'un test d'ONLYOFFICE Community Edition ne représente pas automatiquement une autre édition ou architecture. Consignez l'édition, la version, la méthode de déploiement et l'intégration pour chaque exécution.
En octobre 2026, CODE 26.04 était une version récente de Collabora. Ses notes de version décrivent des améliorations, notamment l'interopérabilité des documents, mais ne précisent pas la consommation de RAM par utilisateur ni la latence d'édition par rapport à ONLYOFFICE. Il est donc conseillé de tester les versions stables les plus récentes ; cela ne constitue pas une preuve de gain de vitesse.
Élaborer un test équitable et reproductible
- Utilisez le même hôte et le même chemin d'intégration. Attribuez à chaque suite les mêmes limites de processeur et de mémoire, le même emplacement de stockage, le même proxy inverse, la même configuration TLS et la même route réseau. Si vous exécutez les deux conteneurs simultanément, ils se disputeront les mêmes ressources ; il est donc préférable d'arrêter une suite, de mesurer son utilisation, puis de la remplacer par l'autre. Laissez l'hôte inactif par ailleurs.
- Indiquez les versions logicielles. Notez l'étiquette ou la version exacte de l'image, l'édition, la version de Docker, le système d'exploitation hôte, la version du navigateur et la plateforme connectée. Évitez les étiquettes flottantes, notamment
latestlors d'une comparaison, car le logiciel peut changer d'un test à l'autre. - Préparez des fichiers représentatifs. Incluez un petit document texte, une feuille de calcul avec des formules et des graphiques, et le fichier le plus volumineux ou le plus complexe que vos utilisateurs ouvrent fréquemment. Utilisez des copies de test, et non les fichiers de production. Stockez-les sur la même plateforme documentaire que celle utilisée pour le travail quotidien.
- Maintenez des conditions client stables. Utilisez le même ordinateur, le même navigateur, la même connexion réseau, la même taille d'écran et les mêmes extensions de navigateur. Fermez les onglets inutiles. Pour chaque essai, assurez-vous que le document est complètement fermé avant de commencer une mesure d'ouverture à froid ; effectuez ensuite des essais d'ouverture à chaud distincts.
- Définissez les durées avant les tests. Mesurez le temps écoulé entre l'ouverture du document et son affichage complet, permettant ainsi sa modification. Pour évaluer la latence d'édition, chronométrez une action définie, comme la saisie d'une courte phrase et l'attente de son affichage pour un second collaborateur. Enregistrez le résultat de chaque test plutôt que de vous fier à une seule mesure.
Mesurer l'utilisation du serveur et le délai visible par l'utilisateur
Mémoire et processeur
Capturez une valeur de référence au repos une fois le service stabilisé. Enregistrez ensuite la mémoire et le processeur utilisés par le conteneur lors de l'ouverture, de la modification et du maintien d'un fichier ouvert. Répétez l'opération avec plusieurs documents et utilisateurs simultanés, à des niveaux correspondant à votre charge de travail prévue. Pour Docker, docker stats --no-streamaffichez un instantané des ressources ; utilisez-le de manière répétée à chaque étape ou collectez une série temporelle avec votre système de surveillance existant. Enregistrez également la mémoire disponible au niveau de l'hôte, car l'utilisation rapportée par un conteneur ne reflète pas à elle seule la charge de l'ensemble de la machine.
Signalez la mémoire maximale, la mémoire moyenne pendant la phase active et la mémoire inactive après la fermeture des documents. Conservez le même intervalle d'échantillonnage. Ne confondez pas la mémoire utilisée après la fermeture d'un document avec la capacité d'une équipe : les sessions, la taille des fichiers, la complexité du rendu et l'édition simultanée sont autant de facteurs importants. Si le déploiement prend en charge les métriques Prometheus, collectez-les de manière systématique ; Collabora documente les métriques compatibles avec Prometheus et la surveillance des sessions en temps réel. Pour ONLYOFFICE, utilisez les outils de diagnostic de conteneur et les recommandations de ressources documentés. Évitez de comparer les métriques de processus internes d'un produit avec le total de l'ensemble du conteneur de l'autre produit.
latence d'ouverture et de modification
Effectuez au moins cinq ouvertures à froid et cinq ouvertures à chaud pour chaque fichier représentatif. Indiquez le temps médian et le temps le plus long observé, et non seulement le meilleur résultat. Une ouverture à froid comprend des opérations telles que le chargement du document et l'affichage de son interface initiale ; une ouverture à chaud peut bénéficier de l'utilisation du cache. Utilisez la même définition de « prêt » dans les deux éditeurs.
Pour évaluer le délai de collaboration, connectez deux sessions de navigateur et mesurez le temps écoulé entre une modification spécifique dans une session et sa mise à jour visible dans l'autre. Répétez cette action plusieurs fois, sans aucun autre document ouvert et sous la charge simultanée prévue. Cela permet de capturer l'effet combiné de l'éditeur, du serveur, de l'intégration de stockage et du réseau. Si le navigateur et le serveur se trouvent sur des réseaux différents, enregistrez les temps de latence aller-retour ; la latence réseau peut fortement impacter le traitement de l'éditeur.
Lisez les résultats sans exagérer.
| Modèle observé | Interprétation probable | Prochaine vérification |
|---|
| RAM élevée au repos | Les services de démarrage ou les sessions mises en cache peuvent constituer une base de référence ; les produits peuvent nettoyer différemment les documents inactifs. | Mesurer après un intervalle d'inactivité fixe et comparer la mémoire hôte ainsi que la mémoire du conteneur. |
| Ouverture rapide, modifications lentes sous charge | Les opérations d'édition ou de collaboration peuvent être limitées par le processeur, les rappels de stockage ou le réseau. | Répétez l'opération avec un niveau de concurrence inférieur et examinez simultanément le processeur, le disque et le réseau. |
| Un seul fichier est lent. | La structure des fichiers, les formules, les objets incorporés ou les polices de caractères peuvent constituer le facteur limitant. | Testez un autre fichier de taille similaire, puis examinez les caractéristiques spécifiques du fichier problématique. |
| Les ouvertures à froid diffèrent, les ouvertures à chaud non. | L'initialisation ou le comportement du cache peuvent expliquer une grande partie de cet écart. | Conserver séparément les résultats obtenus avec des températures froides et chaudes ; ne pas faire la moyenne des deux. |
Choisissez la suite qui répond à votre objectif de latence tout en prévoyant une marge de mémoire et de processeur suffisante pour une concurrence réaliste. En cas de résultats proches, privilégiez la compatibilité des documents, la prise en charge de l'intégration, la facilité d'utilisation et les licences. Relancez le test après une mise à niveau majeure ou une modification de l'infrastructure. Pour des informations détaillées et spécifiques à chaque version, consultez les notes de version de Collabora CODE 26.04 , la FAQ et la présentation de la sécurité et de la surveillance de Collabora Online, ainsi que les exigences Docker de l'édition Community d'ONLYOFFICE et les guides de dépannage et d'utilisation de Docker . Ces ressources décrivent chaque produit séparément ; il ne s'agit pas d'un test comparatif direct et contrôlé.