WordPress 7 RTC : co-édition en temps réel, guide et impacts

WordPress 7.0, la prochaine version majeure du célèbre système de gestion de contenu (CMS), introduit une fonctionnalité clé du point de vue du flux de travail collaboratif : la collaboration en temps réel (RTC).

Cette nouvelle fonctionnalité permet aux utilisateurs de travailler simultanément sur des articles, des pages et d’autres contenus, améliorant ainsi la productivité et la créativité au sein des éditeurs de contenu.

Analysons cette nouvelle fonctionnalité et son implémentation dans WordPress 7.0, ainsi que les avantages qu’elle offre aux utilisateurs et aux équipes de contenu.

Qu’est-ce que la collaboration en temps réel (RTC) ?

Cette fonctionnalité permet à plusieurs utilisateurs de travailler simultanément sur le même contenu dans WordPress. Lorsqu’un utilisateur modifie un article ou une page, les autres utilisateurs peuvent voir ces modifications en temps réel, ce qui facilite la collaboration et la coordination entre les membres de l’équipe. Un peu à la manière de Google Docs, où plusieurs personnes peuvent éditer un document en même temps et voir les changements quasi instantanément.

Présence, curseurs de chaque utilisateur, sélection sont visibles, et les modifications sont synchronisées en temps réel (avec un délai minimal).

Gutenberg 22.8 permet de gérer les notifications de collaboration en temps réel dans les préférences de l’éditeur (sur un article ou une page dans le menu options … > Préférences).

Comment fonctionne la collaboration en temps réel dans WordPress 7.0 ?

La RTC repose sur Yjs, une bibliothèque JavaScript de synchronisation en temps réel. Yjs permet de gérer les conflits d’édition et de synchroniser les modifications entre les utilisateurs de manière efficace, même en cas de connexion instable.

Par défaut l’outils utilise du polling HTTP (le client interroge régulièrement le serveur) pour synchroniser les modifications ce qui permet de fonctionner sur tous les hébergeurs sans nécessiter de configuration spécifique. Ce mécanisme de polling est suffisant pour la plupart des cas d’utilisation, offrant une expérience de collaboration fluide et réactive.

Cependant, pour une expérience optimale le filtre sync.providers permet de configurer d’autres méthodes de synchronisation, offrant une latence plus faible et une meilleure réactivité. Voir à ce sujet la section “Aller plus loin : remplacer le transport de synchronisation” en fin d’article.

Est-ce que la collaboration est réellement en temps réel ?

Par défaut il s’agit de quasi temps réel plus que du temps réel strict, avec un délai de synchronisation de :

• 4000 ms (4 secondes) sans collaborateurs actifs
• 1000 ms (1 seconde) avec au moins un collaborateur actif

Ces délais ont été revus à la hausse lors de la dernière beta pour réduire la charge sur les serveurs et améliorer les performances globales.

Donc la RTC n’est pas strictement en temps réel, ni constante, mais elle s’adapte dynamiquement en fonction de l’activité des collaborateurs pour offrir une expérience de collaboration fluide tout en optimisant les ressources du serveur.

Cette fonctionnalité est-elle activée par défaut ?

A ce jour (RC2), la collaboration en temps réel est en opt in par défaut, ce qui signifie que les utilisateurs doivent activer manuellement cette fonctionnalité via les paramètres de WordPress dans Réglages > Écriture > Collaboration.

Il serait aussi possible de l’activer dans le fichier wp-config.php en utilisant la constante WP_ALLOW_COLLABORATION :

define( 'WP_ALLOW_COLLABORATION', true );

Pourquoi la collaboration en temps réel est-elle désactivée en présence de meta boxes ?

Le système ne prend en charge que les données gérées par l’éditeur de blocs et les flux compatibles avec l’API REST. Les meta boxes classiques, largement utilisées par de nombreux plugins et thèmes, ne sont pas intégrées à ce mécanisme de synchronisation. Pour éviter tout risque de conflit ou de perte de données, WordPress désactive automatiquement la collaboration dans le contenu concerné dès qu’une meta box est détectée.

Pour les développeurs, cela implique une évolution des pratiques : afin de rendre leurs fonctionnalités compatibles avec la RTC, il est recommandé de migrer les meta boxes vers des post meta enregistrées via register_post_meta avec l’option show_in_rest => true, ce qui permet leur exposition dans l’API REST et donc leur synchronisation en temps réel. Ces données peuvent ensuite être manipulées via des extensions basées sur les stores de données WordPress ou intégrées dans des interfaces compatibles avec le block editor, comme des panneaux latéraux ou des blocs personnalisés. Cette approche garantit à la fois la compatibilité avec la collaboration en temps réel et la préservation de l’intégrité des données.

Aller plus loin : remplacer le transport de synchronisation

Pour les hébergeurs ou les équipes avec une infrastructure existante, le filtre sync.providers permet de remplacer le polling HTTP par un transport WebSocket. Avantages : latence réduite, charge serveur allégée, alignement avec votre pile technique.

Toutefois cette mise en place n’est pas triviale et nécessite de gérer (déployer et maintenir) l’infrastructure WebSocket, ainsi que les aspects de sécurité liés à l’authentification et à la validation des connexions.

Plutôt que de coder une solution complète “from scratch”, WordPress suggère comme point de départ la bibliothèque y-websocket. Elle fournit le client et un serveur Node.js minimal. Un exemple de plugin complet et open source est disponible sur le dépôt VIP Real-Time Collaboration.

Attention, le serveur WebSocket étant une infrastructure externe, l’autorisation y est entièrement de votre responsabilité. Le pattern habituel est un jeton de courte durée émis par un endpoint REST WordPress, validé côté serveur à chaque connexion.

Un premier guide d’implantation est disponible sur le blog de Make WordPress Core : Building a Custom Sync Provider for Real-Time Collaboration.

Mise à jour du 26 mars 2026 : Gutenberg 22.8 améliore la RTC en affichant également la sélection et permettant de gérer les notifications dans les préférences de l’éditeur.

Mise à jour du 2 avril 2026 : Ajout de la section “Aller plus loin : remplacer le transport de synchronisation” pour expliquer comment passer du polling HTTP à un transport WebSocket pour une expérience de collaboration plus fluide et réactive.

Sources :

• Real-Time Collaboration in the Block Editor.
• What’s new in Gutenberg 22.8 (25 March).
• Building a Custom Sync Provider for Real-Time Collaboration.