Collaboration temps réel dans WordPress 7.0 : tester la Phase 3 de Gutenberg

Depuis 2003, WordPress est un outil solo. Un auteur, un article, un éditeur. Si deux personnes ouvrent le même article en même temps, c’est la roulette russe : celui qui enregistre en dernier écrase le travail de l’autre. En 23 ans, ce problème n’a jamais été résolu.

WordPress 7.0 change la donne. Pour la première fois, vous pouvez éditer un article à plusieurs en temps réel, comme dans Google Docs. Indicateurs de présence, modifications synchronisées, zéro conflit. Et ça fonctionne sur n’importe quel hébergement PHP, pas uniquement sur des serveurs premium avec WebSocket.

Voici comment l’activer, ce que ça change concrètement pour les équipes qui produisent du contenu sur WordPress, et les limites à connaître avant de l’adopter. Cet article se concentre sur le comment tester et utiliser la collaboration. Pour un tour d’horizon complet de WordPress 7.0, consultez notre guide complet WordPress 7.0.

La collaboration temps réel : de quoi parle-t-on exactement ?

La collaboration temps réel dans WordPress 7.0 permet à plusieurs utilisateurs connectés d’éditer le même contenu simultanément dans l’éditeur Gutenberg. Chaque participant voit les sélections de blocs et la position d’édition des autres en temps réel, avec des indicateurs de présence (avatar, nom, couleur).

C’est la Phase 3 du projet Gutenberg, inscrite dans la feuille de route en quatre phases présentée par Matt Mullenweg au WordCamp US 2018. Après la Phase 1 (l’éditeur de blocs, lancé avec WordPress 5.0 fin 2018) et la Phase 2 (le Full Site Editing, déployé progressivement de WordPress 5.9 à 6.x), cette troisième phase s’attaque au travail collaboratif. Les contours techniques ont été détaillés par Matias Ventura en 2023, avec un prototype fonctionnel présenté lors du State of the Word de la même année.

Concrètement, ça signifie que votre rédacteur peut écrire le corps d’un article pendant que vous ajustez le titre et la meta description. Ou qu’un développeur modifie un template de page pendant que le designer ajuste les blocs. Les modifications de chacun apparaissent chez les autres en quelques instants, sans rechargement de page.

Comment ça fonctionne sous le capot

L’architecture technique repose sur trois composants distincts, et c’est ce qui la rend à la fois solide et flexible.

Le moteur : Yjs et les CRDT

Le cœur du système utilise Yjs, un framework JavaScript créé par Kevin Jahns (sponsorisé par Automattic pour l’intégration dans Gutenberg). Yjs implémente les CRDT (Conflict-free Replicated Data Types) : des structures de données qui se synchronisent automatiquement entre plusieurs pairs sans jamais créer de conflit.

Le principe est élégant. Chaque modification est enregistrée comme une opération atomique avec un identifiant unique. Quand deux personnes modifient le même paragraphe au même moment, Yjs fusionne les opérations de façon déterministe : le résultat est toujours identique quel que soit l’ordre d’arrivée des modifications. Pas de "conflit de fusion" comme dans Git. Côté serveur, PHP n’ayant pas de bibliothèque Yjs native, le serveur WordPress agit comme relais : toutes les opérations CRDT s’exécutent côté client dans le navigateur (architecture détaillée sur GitHub).

L’avantage majeur des CRDT : pas besoin de serveur central autoritaire. Chaque client possède sa propre copie du document et la synchronisation est conceptuellement pair-à-pair. Les données CRDT sont stockées comme métadonnées d’un type de contenu interne dédié, avec compaction périodique via Y.mergeUpdates pour éviter une croissance illimitée du stockage.

Le transport : HTTP polling par défaut

Vous êtes sur un mutualisé à 3 €/mois ? Pas de panique. C’est ici que WordPress fait un choix pragmatique. La plupart des hébergements PHP mutualisés ne supportent pas les WebSockets. Or, WordPress doit fonctionner partout.

La solution : un transport par défaut basé sur le HTTP polling. Le navigateur interroge le serveur à intervalles réguliers via l’endpoint REST /wp/v2/sync/updates. L’intervalle est de 1 seconde par défaut, réduit à 500 ms dès qu’un second collaborateur est détecté. En cas d’erreur, un backoff exponentiel monte jusqu’à 30 secondes (décision technique documentée ici). C’est moins instantané qu’un WebSocket, mais ça fonctionne sur 100 % des hébergements WordPress existants.

Le transport est conçu pour être pluggable : les hébergeurs peuvent substituer un transport WebSocket ou WebRTC via un filtre WordPress. WordPress VIP propose déjà un provider WebSocket dédié pour une synchronisation quasi-instantanée. Mais ce n’est pas requis : la collaboration fonctionne dès l’activation, quel que soit votre hébergeur.

L’interface : présence et indicateurs d’édition

Côté UI, chaque éditeur connecté est représenté par son avatar et une couleur unique. Quand un collaborateur sélectionne un bloc ou édite du texte, vous voyez sa zone d’édition en temps réel avec son nom. L’interface est discrète, les indicateurs de présence apparaissent sans encombrer l’éditeur. Précision importante : WordPress 7.0 n’affiche pas de curseur de souris en direct comme Google Docs. La visibilité porte sur les sélections de blocs et les positions d’édition, pas sur le pointeur.

Activer la collaboration dans WordPress 7.0 Beta

Pendant la phase beta, la collaboration temps réel est en opt-in (annonce Beta 1). Elle n’est pas activée par défaut. Il faut la déclencher manuellement. Voici la procédure complète.

1. Installer WordPress 7.0 Beta

Sur un site de test (jamais en production pendant la beta), installez la dernière WordPress 7.0 Beta via le plugin WordPress Beta Tester ou téléchargez directement depuis wordpress.org/news.

2. Activer la collaboration

Rendez-vous dans Réglages → Écriture. Une nouvelle section "Collaboration" apparaît avec l’option "Activer la collaboration temps réel". Cochez-la et enregistrez. Ce toggle a été ajouté dans une version récente du plugin Gutenberg, avant la Beta 1 de WordPress 7.0.

Alternativement, une constante wp-config.php permet d’activer la fonctionnalité par code et d’ajuster les paramètres par défaut (nombre de collaborateurs simultanés, type de transport). Consultez la documentation développeur officielle pour le nom exact de la constante et les valeurs disponibles.

3. Tester avec deux navigateurs

Le test le plus simple : ouvrez le même article dans deux navigateurs différents (ou deux sessions avec des comptes WordPress distincts). Modifiez un paragraphe dans le premier navigateur. La modification apparaît dans le second en quelques secondes.

Ce que révèlent les premiers retours

L’appel aux testeurs a été lancé le 11 mars 2026 sur make.wordpress.org. Les premiers retours confirment que l’activation est simple : un toggle dans Réglages → Écriture, et la fonctionnalité se greffe dans Gutenberg sans modifier l’interface de base.

Le transport HTTP polling introduit une latence perceptible entre les modifications. L’intervalle de polling est de 1 seconde par défaut, réduit à 500 ms dès qu’un second collaborateur est détecté (source : PR #74564). En pratique, comptez 1 à 3 secondes entre une modification et son apparition chez l’autre éditeur, selon la charge serveur. C’est perceptible mais tout à fait acceptable pour de l’édition éditoriale.

Le moteur Yjs gère les éditions concurrentes de façon déterministe : deux modifications simultanées sur le même bloc sont fusionnées automatiquement par l’algorithme CRDT, sans perte de données. C’est le principal avantage par rapport au système de verrouillage actuel de WordPress, qui bloque purement et simplement l’accès au second éditeur.

Ce qui fonctionne, et ce qui coince encore

Ce qui marche bien

• Blocs Gutenberg natifs : paragraphes, titres, images, listes, colonnes, la synchronisation est fluide sur tous les blocs du core
• Présence visuelle : les avatars et indicateurs de sélection des collaborateurs sont clairs et discrets
• Édition hors ligne : Yjs gère nativement la perte de connexion. Les modifications locales se synchronisent automatiquement à la reconnexion, les conflits sont résolus par le CRDT
• Compatibilité hébergeurs : le HTTP polling fonctionne sur tout hébergement PHP standard, sans configuration serveur supplémentaire

Ce qui pose problème

• Bloc Classic Editor (core/freeform) : incompatible avec la collaboration. Si vos anciens articles utilisent l’éditeur classique, la collaboration ne fonctionne pas dessus
• Meta boxes classiques : quand des meta boxes legacy sont détectées, la collaboration est automatiquement désactivée pour éviter des écritures non synchronisées. Seules les meta enregistrées avec show_in_rest: true participent au store collaboratif
• Accessibilité : l’équipe Core reconnaît que les standards d’accessibilité ne sont pas encore atteints pour les fonctionnalités collaboratives, un chantier en cours
• Blocs tiers : les blocs qui utilisent des éditeurs personnalisés (certains page builders) peuvent ne pas synchroniser correctement. Chaque éditeur de blocs tiers devra adapter son code pour supporter les CRDT de Yjs
• Limite de collaborateurs : la limite par défaut de 2 éditeurs simultanés peut sembler restrictive pour les équipes éditoriales. Elle est configurable, mais l’impact sur la charge serveur avec le HTTP polling reste à mesurer sur les mutualisés

Quel impact pour les agences et les équipes ?

Vous travaillez en équipe sur WordPress ? Si vous êtes seul sur votre blog, la collaboration temps réel est un gadget sympa mais pas transformant. En revanche, pour les agences, les équipes éditoriales, les rédactions, ça change le workflow.

Prenez un workflow classique en agence : le rédacteur écrit, envoie le brouillon au correcteur, qui corrige et renvoie au chef de projet, qui valide et publie. Avec la collaboration temps réel, deux de ces personnes peuvent travailler sur le même article simultanément (la limite par défaut est de 2, configurable par l’hébergeur). Le rédacteur écrit la conclusion pendant que le correcteur corrige l’introduction. Le chef de projet prend le relais ensuite pour les meta SEO.

En tant que formateur WordPress certifié Qualiopi, j’accompagne régulièrement des équipes éditoriales dans leur transition vers Gutenberg. Jusqu’ici, le reproche récurrent était : "Google Docs fait mieux pour le collaboratif." Avec WordPress 7.0, cet argument s’affaiblit. Pas totalement, Google Docs a 15 ans d’avance sur le collaboratif et propose un suivi du curseur plus fin. Mais suffisamment pour que le workflow reste dans WordPress plutôt que de faire des allers-retours entre trois outils.

Préparer votre site pour la collaboration

La sortie officielle de WordPress 7.0 est prévue pour le 9 avril 2026. Voici ce que vous pouvez faire maintenant pour être prêt.

1. Convertissez vos contenus Classic Editor en blocs Gutenberg : la collaboration ne fonctionne pas avec le bloc freeform ni avec les meta boxes classiques. L’outil de conversion intégré à WordPress fait le gros du travail
2. Vérifiez la compatibilité de vos plugins : les plugins qui modifient l’éditeur (ACF, Elementor, page builders) doivent être testés. Contactez les éditeurs pour connaître leur feuille de route WordPress 7.0
3. Mettez à jour PHP : WordPress 7.0 abandonne PHP 7.2 et 7.3. Le minimum passe à PHP 7.4, mais PHP 8.3 est fortement recommandé pour les performances du polling
4. Testez sur un staging : installez la beta sur un environnement de test et simulez l’édition collaborative avec un collègue
5. Préparez vos rôles utilisateurs : décidez qui pourra collaborer simultanément (éditeurs, auteurs, administrateurs). La collaboration nécessite les permissions d’édition sur le contenu ciblé

Pour un tour d’horizon complet des nouveautés de WordPress 7.0, consultez notre guide complet WordPress 7.0. L’article que vous lisez ici se concentre sur le test pratique de la collaboration, pas sur la liste des changements.

Mon avis : une avancée historique, avec des réserves

La collaboration temps réel dans WordPress 7.0, c’est un moment pivot. WordPress rattrape en une version ce que Google Docs propose depuis plus de 15 ans et ce que Notion a popularisé depuis 2016. Le choix de Yjs comme moteur CRDT est solide : c’est un framework open source éprouvé, et Automattic a sponsorisé Kevin Jahns, son créateur, pour l’intégrer dans Gutenberg (PR #68483).

Ma réserve principale concerne la performance sur les hébergements mutualisés. Le HTTP polling est un choix pragmatique pour la compatibilité universelle, mais il génère du trafic serveur proportionnel au nombre d’éditeurs connectés. La limite par défaut de 2 collaborateurs simultanés est sage pour cette première itération. Les agences qui espèrent 10 rédacteurs sur le même article devront patienter ou investir dans un hébergement avec transport WebSocket.

L’incompatibilité avec le Classic Editor est prévisible mais frustrante. Si vous avez des centaines d’articles en mode classique, la migration vers les blocs Gutenberg devient une priorité. Ce n’est pas un hasard : WordPress pousse fort pour que tout le monde bascule sur les blocs. La collaboration est l’argument massue.

Malgré ces réserves, je recommande à tous les propriétaires de sites WordPress de tester la beta sur un staging. L’appel aux testeurs est lancé. C’est le moment de remonter des bugs, de donner du feedback à l’équipe Core, et de préparer vos workflows pour le 9 avril. WordPress n’a pas souvent l’occasion de proposer quelque chose d’aussi structurant pour le travail en équipe.

Et après ?

La collaboration temps réel, c’est un premier pas. Mais ce qui m’intéresse, c’est ce qui vient ensuite. Les "suggested edits" inline dans l’éditeur (comme dans Google Docs) ? Un suivi fin du curseur au caractère près ? La gestion de versions avec diff visuel ? L’attribution par bloc pour savoir qui a écrit quoi ? Ces fonctionnalités sont explicitement exclues de WordPress 7.0 mais en discussion pour les versions suivantes sur make.wordpress.org.

Si vous êtes formateur, chef de projet, ou si vous gérez une équipe de rédacteurs sur WordPress, c’est maintenant qu’il faut tester. Pas en avril quand tout le monde se ruera dessus. Installez la beta sur un staging, cassez des trucs, remontez des bugs. C’est comme ça qu’on fait avancer WordPress.

Questions fréquentes

La collaboration temps réel sera-t-elle activée par défaut dans WordPress 7.0 ?

Pendant la beta, la fonctionnalité est opt-in (à activer manuellement via Réglages → Écriture). Pour la version finale du 9 avril 2026, la décision sera finalisée autour de la RC2 (26 mars 2026). L’équipe Core collecte les retours pour déterminer si l’activation par défaut est envisageable.

Combien de personnes peuvent éditer simultanément ?

Par défaut, WordPress 7.0 Beta limite la collaboration à 2 éditeurs simultanés par article (source). Cette limite est configurable via une constante wp-config.php, et les hébergeurs peuvent l’augmenter. Côté Yjs, il n’y a pas de limite technique stricte. La contrainte pratique vient du transport HTTP polling, qui génère une requête par éditeur toutes les 500 ms à 1 s. Avec un transport WebSocket, la limite effective est beaucoup plus haute.

La collaboration fonctionne-t-elle avec le Full Site Editor ?

Oui. La Phase 3 de Gutenberg couvre à la fois l’éditeur d’articles (post editor) et l’éditeur de site (site editor). Vous pouvez collaborer sur les templates, les parties de template et les patterns globaux. En revanche, l’éditeur de code (mode Code dans l’éditeur) n’est pas encore supporté.

Que se passe-t-il si je perds ma connexion Internet pendant l’édition ?

Yjs gère l’édition hors ligne nativement. Vos modifications sont stockées localement et synchronisées automatiquement dès que la connexion revient. Les conflits éventuels sont résolus par l’algorithme CRDT, aucune perte de données.

Les page builders (Elementor, Divi) supportent-ils la collaboration ?

Pas encore officiellement. La collaboration repose sur la synchronisation des attributs de blocs Gutenberg. Les page builders qui utilisent leur propre éditeur visuel (Elementor, Divi, Beaver Builder) devront adapter leur code pour supporter les CRDT de Yjs. Suivez les annonces de chaque éditeur pour connaître leur calendrier de compatibilité.

Mon hébergeur doit-il supporter les WebSockets ?

Non. WordPress 7.0 utilise le HTTP polling comme transport par défaut, qui fonctionne sur tous les hébergements PHP standard. Les WebSockets sont un bonus optionnel pour réduire la latence, pas une obligation. Le choix du HTTP polling a été fait après évaluation des alternatives (WebSocket, HTTP long-polling, WebRTC), toutes rejetées pour des problèmes de compatibilité universelle.

La collaboration temps réel fonctionne-t-elle avec les Custom Post Types ?

Oui, à condition que le Custom Post Type utilise l’éditeur Gutenberg (paramètre show_in_rest à true et support de l’éditeur de blocs). Les CPT qui utilisent encore les meta boxes classiques ne sont pas compatibles : la collaboration est automatiquement désactivée quand des meta boxes legacy sont détectées, pour éviter des écritures non synchronisées.

Faut-il un hébergement spécial pour utiliser la collaboration temps réel ?

Non. La collaboration temps réel fonctionne sur tout hébergement PHP capable de faire tourner WordPress 7.0 (PHP 7.4 minimum, PHP 7.2 et 7.3 étant abandonnés). Le transport par défaut est le HTTP polling, qui ne nécessite aucune configuration serveur particulière. Avec la limite par défaut de 2 collaborateurs simultanés et le HTTP polling, un hébergement mutualisé classique suffit. Pour augmenter cette limite ou réduire la latence, un VPS ou un hébergeur proposant le WebSocket offrira de meilleures performances.