Le module de collaboration instantanée de WordPress en difficulté

La sortie très attendue de WordPress 7.0 a été repoussée parce que la fonctionnalité de collaboration en temps réel (RTC) n’était pas suffisamment stable. Ce report a suscité des débats : certains estiment que cette fonctionnalité ne devrait pas être intégrée au core, tandis que d’autres voient dans ce contretemps le révélateur de limites plus profondes au sein de WordPress.

Collaboration en temps réel (RTC)

Le projet Gutenberg a été planifié selon une feuille de route en quatre phases : l’éditeur par blocs (block editor, phase 1), l’édition complète du site (Full Site Editing, phase 2), la collaboration en temps réel (phase 3) et enfin l’intégration de fonctionnalités multilingues dans le cœur du système (phase 4).

La version WordPress 7.0, initialement prévue pour le 9 avril, devait concrétiser la phase 3 tout en rassemblant d’autres améliorations importantes, notamment des capacités rendant l’utilisation de l’IA plus accessible au sein de l’écosystème WordPress.

La fonctionnalité de RTC permet à plusieurs contributeurs d’éditer simultanément un même contenu et les éléments de mise en page basés sur des blocs dans l’éditeur. Cet outil promet d’être particulièrement utile pour les rédactions, agences et équipes distribuées qui travaillent à plusieurs sur des pages ou articles.

RTC a fait l’objet de tests

Du côté commercial de l’écosystème, Automattic a rendu la fonctionnalité disponible à des testeurs bêta sur WordPress.com depuis octobre 2025. Ces testeurs provenaient essentiellement de la clientèle entreprise de WordPress VIP. La documentation officielle précise que la collaboration en temps réel est la plus fluide lorsque l’on utilise les blocs natifs de WordPress, et suggère que l’expérience peut devenir problématique si des blocs tiers ne respectent pas les bonnes pratiques de développement.

Selon un retour publié sur le site officiel de WordPress.org, voici un résumé du comportement observé lors de ces tests :

Les équipes de test ont constaté que la collaboration en temps réel fonctionne de manière très fluide sur des sites conçus pour les versions modernes de WordPress. Les organisations qui exploitent l’éditeur par blocs avec des blocs natifs ou des blocs personnalisés développés dans les règles de l’art ont rapporté des expériences stables et peu de dysfonctionnements.

Un responsable technique d’une grande institution de recherche a indiqué que son équipe, ayant investi dans une compréhension approfondie de Gutenberg, n’avait rencontré « aucun problème » significatif.

Pour éprouver la robustesse de la fonctionnalité, plusieurs équipes ont poussé des scénarios intensifs :

– ajout simultané de dizaines de blocs ;

– copie massive de contenus en parallèle ;

– groupes entiers éditant la même publication au même moment (une équipe a décrit l’expérience comme « très amusante »).

Lors de ces tests de résistance, avec des blocs natifs et des blocs personnalisés modernes, la collaboration en temps réel s’est révélée remarquablement résiliente.

Toutefois, ces essais utilisaient une implémentation reposant sur des tables existantes pour stocker les événements d’édition. Cette approche a rapidement montré ses limites et a engendré plusieurs bogues. En conséquence, l’équipe a décidé de créer une table dédiée dans la base de données destinée à l’RTC, afin d’améliorer la stabilité et la montée en charge.

La version bêta testée avait également une contrainte : elle plafonnait le nombre d’utilisateurs pouvant éditer simultanément une même ressource.

Un ticket sur GitHub fournit une explication technique sur les limites de l’ancienne implémentation :

L’implémentation connue était limitée en matière de performance et de scalabilité, mais elle offrait une vision simple du fonctionnement de la collaboration.

En restreignant par défaut le nombre de collaborateurs simultanés à une valeur basse, on diminue le risque de surcharge.

C’est précisément l’un des problèmes visés par la création d’une table spécifique. Une fois cette refonte de stockage réalisée, il faudra relancer des séries de tests : c’est à ce stade que les hébergeurs auront un intérêt marqué pour évaluer l’impact réel de la RTC sur leurs infrastructures.

Signe de problèmes plus profonds ?

Joost de Valk, fondateur de Yoast SEO, a récemment publié un billet évoquant la nécessité de réécrire une partie du code de WordPress pour le rendre plus sécurisé, moderne et performant. Il a cité le cas de la collaboration en temps réel comme un symptôme révélateur des limites actuelles du core.

Dans son article, il expliquait :

Le report de WordPress 7.0 met en lumière un problème structurel : l’équipe a dû revoir la façon dont les données de collaboration en temps réel sont stockées — la méthode initiale consistant à entasser ces données dans postmeta n’était pas viable. On envisage désormais l’utilisation d’une table personnalisée. Ce schéma se répète : une nouvelle fonctionnalité heurte les limites du modèle de données existant, et l’équipe doit soit bricoler une solution, soit suspendre et repenser l’approche.

Il s’agit du point de vue d’un acteur influent de l’écosystème, mais l’opinion n’est pas unanime. Les échanges sur le canal Slack de Post Status ont montré que plusieurs membres de la communauté s’opposent à l’idée d’un refactoring massif du cœur de WordPress.

Ce débat soulève des questions techniques et philosophiques : faut-il moderniser en profondeur la base de code (ce qui implique une lourde dépense de ressources et des risques de rupture de compatibilité), ou faut-il privilégier l’évolution incrémentale et la compatibilité ascendante pour préserver le vaste parc d’installations WordPress ?

Impact sur les hébergeurs WordPress

Un sujet récurrent, évoqué en privé par certains acteurs, est l’effet potentiel de la RTC sur les environnements d’hébergement mutualisé. Il est difficile d’évaluer précisément ce risque aujourd’hui, car la fonctionnalité est encore en cours d’évolution : la version testée sur WordPress.com était optimisée pour l’environnement d’Automattic, qui diffère d’un hébergeur mutualisé classique.

Dans un contexte d’hébergement partagé, plusieurs questions opérationnelles se posent :

• Quelle sera la charge générée si des milliers de clients activent la RTC et éditent simultanément ?

• Les prestataires devront-ils limiter le nombre d’éditeurs simultanés dans l’éditeur par blocs pour certains plans ?

• Une politique à plusieurs niveaux (plafond pour l’offre basique, plafond supérieur pour les offres pro) sera-t-elle nécessaire pour garantir la stabilité de la plateforme ?

En pratique, les hébergeurs devront évaluer trois aspects techniques principaux :

• La charge réseau : la synchronisation en temps réel implique un trafic continu (websockets, requêtes périodiques, API) qui peut augmenter les I/O réseau et le nombre de connexions persistantes par serveur.

• La charge base de données : le stockage et la lecture fréquente d’événements d’édition exigent des opérations d’E/S plus intensives. Une table dédiée et des index adaptés seront essentiels pour maintenir la latence basse.

• La mémoire et le CPU serveur : la cohabitation de nombreuses sessions d’édition en parallèle peut accroître la consommation CPU (rejeu d’opérations de fusion, résolution de conflits) et la mémoire utilisée par les processus gérant les connexions temps réel.

Pour limiter les risques, certains hébergeurs envisageront probablement :

• De proposer une configuration dédiée ou optimisée pour la RTC (notamment sur des offres managées ou cloud).

• De documenter des bonnes pratiques à destination des agences et développeurs (ex. privilégier les blocs natifs et les patterns conformes aux APIs de Gutenberg).

• D’appliquer des limites par abonnement pour préserver l’expérience globale des clients, tout en laissant des options de montée en charge pour les comptes professionnels.

Autant d’éléments qui vont influer sur le modèle tarifaire, la communication commerciale (sans en faire un appel à l’achat) et la gestion technique des offres d’hébergement.

Le RTC devrait‑il être un plugin ?

Parmi les voix critiques, Matt Cromwell a récemment remis en question l’appartenance de la RTC au cœur de WordPress. Dans son article d’opinion, il rappelle la philosophie de conception de WordPress : le core doit rester utile à la majorité des utilisateurs afin de préserver la simplicité et la légèreté du CMS.

La philosophie officielle, citée par Cromwell, indique que l’on conçoit pour l’utilisateur moyen de WordPress, souvent peu technique, qui souhaite principalement rédiger sans se soucier des détails techniques. Voici un extrait de cette philosophie :

« Concevoir pour la majorité
Beaucoup d’utilisateurs finaux de WordPress ne sont pas technophiles. Ils ne savent pas ce qu’est AJAX, et se préoccupent peu de la version de PHP utilisée. L’utilisateur moyen veut simplement pouvoir écrire sans problèmes ni interruptions. Ce sont ces utilisateurs que nous concevons en priorité, car ce sont eux qui passent le plus de temps à utiliser le logiciel pour ce à quoi il est destiné. »

Cromwell conclut que si une fonctionnalité n’est pertinente que pour une minorité d’utilisateurs, elle a davantage sa place sous la forme d’un plugin plutôt que dans le core. Selon lui, la collaboration en temps réel ne répond pas à ce critère et son intégration au cœur affaiblirait la légèreté de WordPress.

En face, d’autres arguments plaident pour une présence dans le core : la popularité croissante de workflows collaboratifs, l’intérêt des agences, et la demande exprimée par des équipes éditoriales. Par exemple, le plugin de collaboration Atarim — dont la version gratuite est installée sur plus de 1 000 sites — revendique une utilisation par plus de 120 000 sites auprès d’agences et freelances. Ce chiffre témoigne que la collaboration visuelle et en équipe est une attente réelle pour une part significative d’utilisateurs professionnels.

Le choix entre intégrer une fonctionnalité dans le core ou la fournir comme plugin repose donc sur plusieurs critères :

• La part d’utilisateurs qui ont réellement besoin de la fonctionnalité au quotidien.

• L’impact sur la complexité et la maintenabilité du core.

• Les exigences en matière d’infrastructure (charge, sécurité, compatibilité).

• La capacité de la communauté et des entreprises à maintenir la fonctionnalité si elle reste en plugin.

En définitive, il s’agit d’un arbitrage entre accessibilité (proposer la fonctionnalité nativement) et modularité (laisser les utilisateurs qui en ont besoin l’activer via une extension).

L’IA dans WordPress

La feuille de route en quatre étapes de Gutenberg date de 2018, et à l’époque il était impossible d’anticiper l’ampleur que prendrait l’IA quelques années plus tard. Aujourd’hui, l’intégration de l’IA représente une des attentes majeures pour WordPress 7.0 : assistants de rédaction, suggestions de contenu, génération d’images et automatisation de tâches éditoriales font partie des usages pressentis.

Cependant, il est probable que la collaboration en temps réel et l’IA finiront par coexister dans le même ensemble fonctionnel : la RTC facilite le travail simultané entre freelances, agences, clients et équipes internes réparties géographiquement, et l’IA peut accélérer la création et la mise en forme des contenus. Ensemble, ces outils peuvent renforcer la productivité des équipes éditoriales modernes.

Du point de vue de l’architecture, l’intégration conjointe de la RTC et des fonctions basées sur l’IA pose plusieurs défis :

• Coordination des actions humaines en temps réel avec les modifications automatisées proposées par l’IA.

• Gestion des droits et de l’éthique lorsque des suggestions générées automatiquement modifient le contenu collaboratif.

• Sécurité et confidentialité des données transmises aux services d’IA, en particulier pour les hébergements réglementés ou sensibles.

Ces considérations renforceront la nécessité d’un design robuste et d’API claires pour que les intégrateurs puissent piloter finement ces interactions.

Featured Image by Shutterstock/Summit Art Creations

En synthèse, le report de WordPress 7.0 pour stabiliser la RTC est révélateur d’un moment charnière : WordPress doit concilier modernisation technique, exigence de compatibilité et attentes d’un marché professionnel de plus en plus orienté vers le travail collaboratif et l’IA. Les choix faits maintenant — architecture de données, niveau d’intégration au core ou en plugin, et support des hébergeurs — détermineront la qualité d’usage pour des millions d’utilisateurs et la capacité de la plateforme à évoluer sereinement.

Références

• Ticket GitHub expliquant les limites de l’ancienne implémentation RTC

• Article de Joost de Valk sur la nécessité de refactorer WordPress

• Philosophie de conception de WordPress

• Page du plugin Atarim (collaboration visuelle)