Comment intégrer Collabora Online à ownCloud Infinite Scale

L'intégration de Collabora Online avec ownCloud Infinite Scale (oCIS) est une intégration WOPI, différente de la configuration utilisée par ownCloud Classic. WOPI (Web Application Open Platform Interface) est le protocole qui permet à une suite bureautique en ligne de demander un fichier à une plateforme de stockage, de le modifier dans le navigateur et d'enregistrer le résultat.

Cette distinction est importante car les déploiements Infinite Scale actuels utilisent le service de collaboration intégré comme passerelle entre oCIS et Collabora. Il n'est pas nécessaire d'installer l'ancienne application ownCloud Classic Collabora et de la configurer pour qu'elle pointe vers une URL de serveur. L'application bureautique est enregistrée via les services de collaboration et d'enregistrement d'applications. La documentation officielle ownCloud WOPI mentionne Collabora parmi les applications bureautiques compatibles, tandis que la documentation du service de collaboration explique le fonctionnement du service et ses paramètres requis.

En octobre 2026, les versions officielles d'ownCloud sur GitHub incluent Infinite Scale 8.2.0, publiée le 10 août 2026. L'exemple de déploiement du projet étant susceptible d'évoluer, il est recommandé d'utiliser une version de production testée plutôt que de supposer qu'une image système continue convient. L'exemple de déploiement complet officiel d'oCIS recommande actuellement la version Collabora CODE 26.04.3.1.1dans son fichier d'environnement. Avant de figer des versions, veuillez consulter les versions officielles d'Infinite Scale et le fichier d'environnement de l'exemple de déploiement officiel .

Premièrement, comprendre les trois points d'extrémité

Une intégration en production implique généralement trois points de terminaison logiques :

Vérifié : COLLABORATION_APP_ADDR il s’agit de l’URL Collabora, qui COLLABORATION_WOPI_SRCidentifie la source WOPI utilisée par l’application bureautique. Dépend de l’environnement : la source WOPI ne nécessite pas un nom d’hôte public distinct lorsque Collabora et le service de collaboration partagent un réseau de conteneurs de confiance. L’exemple officiel actuel de Compose utilise cette source http://collaboration:9300en interne. Un déploiement séparé peut nécessiter un nom d’hôte WOPI HTTPS routé.

Action utile : définissez votre topologie avant de copier les valeurs de configuration. Si tous les composants s’exécutent dans une pile Compose officielle, partez de cet exemple. Si Collabora est hébergé sur un autre serveur ou un cluster Kubernetes, documentez le nom DNS que chaque serveur peut résoudre et atteindre.

Étape 1 : Vérification DNS, HTTPS et découverte de Collabora

Avant de modifier la configuration d'oCIS, assurez-vous que les noms ownCloud et Collabora sont correctement résolus et que Collabora expose son point de terminaison de découverte. Collabora publie les fonctionnalités WOPI via [lien manquant] /hosting/discovery. Voici une vérification de base :

dig +short cloud.example.com
dig +short office.example.com

curl -fsS https://office.example.com/hosting/discovery | head

Vous devriez recevoir du XML du point de terminaison de découverte. Si la connexion TLS se termine par un proxy inverse, vérifiez que le certificat présenté office.example.comest valide du point de vue de l'hôte oCIS ou du réseau de conteneurs.

Légende : Vérifiez la résolution des noms et le /hosting/discoverypoint de terminaison Collabora avant de déboguer l’enregistrement WOPI dans Infinite Scale.

Erreur fréquente : l’affichage d’une page d’accueil Collabora dans un navigateur ne prouve pas que l’intégration WOPI fonctionne. Cela prouve seulement que le point de terminaison web est accessible. Le service de collaboration doit également pouvoir accéder à Collabora, et Collabora doit pouvoir accéder à la source WOPI.

Action utile : exécuter les tests de connectivité à partir du même espace de noms réseau que le service concerné, par exemple, à partir de l’intérieur du conteneur de collaboration lors de l’utilisation de Docker.

Étape 2 : Configurer le service de collaboration à échelle infinie

Le service de collaboration n'est pas démarré automatiquement par une ocis serverconfiguration générique en mode supervisé. La documentation ownCloud précise qu'il doit être démarré explicitement, car les administrateurs peuvent exécuter plusieurs instances de ce service pour différents produits bureautiques.

Les paramètres importants de Collabora sont :

COLLABORATION_APP_NAME=CollaboraOnline
COLLABORATION_APP_PRODUCT=Collabora
COLLABORATION_APP_ADDR=https://office.example.com
COLLABORATION_WOPI_SRC=http://collaboration:9300
OCIS_URL=https://cloud.example.com

La source WOPI ci-dessus correspond exactement à la topologie utilisée par l'exemple Compose officiel actuel : Collabora et le service de collaboration partagent le même réseau Docker. Si votre serveur Collabora est externe, remplacez l'URL interne par l'adresse à laquelle Collabora peut accéder.

Ce service dépend également de l'infrastructure de passerelle et de fournisseur d'applications d'Infinite Scale. Dans un déploiement à conteneurs séparés, la documentation ownCloud précise que la configuration oCIS doit être partagée avec le conteneur de collaboration, car des secrets générés sont nécessaires à l'ensemble des services. Consultez la définition officielle actuelle de Collabora Compose .

Légende : Un processus de service de collaboration doit commencer par l’adresse Collabora prévue et la source WOPI ; utilisez les journaux de service réels pour confirmer les valeurs dans votre déploiement.

Action utile : si vous avez créé le déploiement manuellement, comparez votre environnement à l’environnement officiel collabora.ymlau lieu de copier les paramètres d’un ancien tutoriel cs3org/wopiserver.

Étape 3 : Configurer Collabora pour l’hôte WOPI et l’intégration dans le navigateur

Collabora doit faire confiance à l'hôte WOPI et être autorisé à s'afficher dans la page web ownCloud. L'exemple officiel oCIS Compose transmet à Collabora des options qui terminent la connexion TLS au niveau du proxy inverse et sont configurées net.frame_ancestorssur le domaine oCIS. Il génère également une clé de preuve WOPI avant de démarrer Collabora.

Dans l'exemple officiel, les valeurs pertinentes côté Collabora incluent :

DONT_GEN_SSL_CERT=YES

extra_params:
  --o:ssl.enable=...
  --o:ssl.ssl_verification=...
  --o:ssl.termination=true
  --o:welcome.enable=false
  --o:net.frame_ancestors=cloud.example.com

Les options SSL exactes dépendent du point de terminaison TLS. Pour une utilisation sur Internet, il est recommandé d'utiliser HTTPS avec vérification de certificat activée. Cette INSECURE=trueoption est présente dans l'exemple pour les configurations locales utilisant des certificats auto-signés ; le guide de déploiement d'ownCloud recommande explicitement aux administrateurs de la supprimer ou de la désactiver pour les serveurs publics.

Légende : Un point de terminaison Collabora accessible est une condition préalable ; les déploiements en production doivent l’exposer via HTTPS avec un certificat approuvé par les autres composants.

Action utile : si le chargement du document génère une iframe vide ou une erreur CSP, examinez les outils de développement du navigateur et les en-têtes du proxy inverse. Ne désactivez pas la vérification des certificats ni les restrictions de sécurité du contenu de manière générale dans le seul but de permettre le chargement de la page.

Étape 4 : Types de fichiers du bureau d’enregistrement et édition des tests

Le service d'enregistrement d'applications d'Infinite Scale détermine quelle application peut ouvrir chaque type MIME. Sa configuration permet de définir le type MIME, l'extension, l'icône, l'application par défaut et d'autoriser ou non les utilisateurs à créer de nouveaux fichiers de ce type. La documentation officielle du service d'enregistrement d'applications décrit ces champs.

Un point essentiel : le nom de l’application utilisé par le registre doit correspondre au fournisseur de collaboration que vous avez enregistré. Les exemples de déploiement officiels actuels de Collabora utilisent « as » et « as » CollaboraOnlinecomme nom de produit. N’utilisez pas de noms copiés d’anciens exemples sans vérifier la version de déploiement.COLLABORATION_APP_NAMECollabora

Après le démarrage, connectez-vous à ownCloud Web et ouvrez un document Office compatible. Le déroulement normal se présente comme suit :

• ownCloud Web sélectionne l'application de siège social pour le type MIME du document.
• Le service de collaboration crée les informations de lancement WOPI.
• Collabora se charge dans le navigateur et demande le fichier via WOPI.
• Les modifications sont répercutées dans Infinite Scale via la même intégration.

Légende : Le test final consiste à ouvrir un véritable document bureautique depuis ownCloud Web, à le modifier dans Collabora, à le fermer et à vérifier que la version enregistrée est à nouveau visible dans Infinite Scale.

Action utile : apportez une petite modification à un document de test temporaire, fermez l’éditeur, rouvrez le fichier et vérifiez que la modification a bien été prise en compte. Une page qui se contente de charger l’éditeur ne constitue pas un test complet de chemin d’écriture.

Utilisez l'exemple Compose officiel lorsque vous n'avez pas besoin d'une topologie personnalisée.

Pour un déploiement Docker classique, l'exemple fourni par ownCloud est la solution la plus sûre ocis_full. Il inclut Infinite Scale, le service de collaboration Collabora et Traefik. Le guide officiel précise que le déploiement nécessite des domaines pour oCIS et Collabora et documente le composant WOPI comme faisant partie de la pile. Consultez le guide de déploiement complet officiel .

Un fichier d'environnement typique orienté production comprend des valeurs conceptuellement comme :

OCIS_DOCKER_IMAGE=owncloud/ocis
OCIS_DOCKER_TAG=<tested-production-version>
OCIS_DOMAIN=cloud.example.com

COLLABORA=:collabora.yml
COLLABORA_DOCKER_TAG=<tested-collabora-version>
COLLABORA_DOMAIN=office.example.com

INSECURE=false

Commencez ensuite la pile avec :

docker compose pull
docker compose up -d
docker compose ps

Vérifié : l’exemple officiel actuel de proxy inverse autorise l’encodage des barres obliques, des points d’interrogation et des pourcentages sur le point d’entrée HTTPS, car Collabora les requiert. Dépend de l’environnement : si vous utilisez Nginx, HAProxy, un contrôleur d’entrée ou un équilibreur de charge cloud au lieu de Traefik, vous devez reproduire la gestion des URL, le comportement WebSocket/proxy, les certificats et les délais d’expiration requis par cette plateforme.

Action utile : ne traduisez pas littéralement les étiquettes Traefik dans un autre proxy. Utilisez-les pour comprendre les exigences de routage, puis implémentez-les en utilisant la syntaxe documentée de votre proxy.

Guide de dépannage

Ce que l'on sait, ce qui dépend de votre déploiement et ce qu'il faut éviter de supposer

À noter : Infinite Scale prend en charge Collabora via WOPI, le service de collaboration intégré constitue le pont actuel, et le déploiement complet officiel fournit une architecture de référence fonctionnelle.

Cela dépend de votre environnement : si le point de terminaison WOPI est une URL de conteneur interne ou un nom d’hôte public, où se termine la connexion TLS, quel proxy vous utilisez et si Collabora s’exécute sur le même réseau qu’oCIS.

Attention : les instructions d’ownCloud Classic ne s’appliquent pas à Infinite Scale. La documentation Classic qui vous invite à installer une application Collabora/richdocuments ou à la configurer via l’interface d’administration de Classic décrit une architecture produit différente.

Le flux de travail d'intégration le plus fiable est donc le suivant : partir du modèle de déploiement officiel Infinite Scale, prouver l'accessibilité du réseau et du protocole TLS, configurer le service de collaboration, confirmer que Collabora fait confiance à l'hôte WOPI et peut l'atteindre, enregistrer les types MIME pertinents et enfin tester l'ouverture et l'enregistrement d'un document réel.