Un différend interne au sein de l’équipe de contributeurs du cœur de WordPress est devenu public, semant la confusion auprès d’une large partie de la communauté. Ce conflit, qui remonte à plusieurs publications et échanges sur plus d’une semaine, a culminé par une vive réaction qui a mis en lumière des tensions latentess entre plusieurs acteurs du projet.

Annonce de Mary Hubbard qui déclenche le conflit

Les événements semblent avoir commencé le 15 septembre lorsqu’Mary Hubbard, directrice exécutive de WordPress, a annoncé la création d’une nouvelle équipe nommée Core Program Team. Cette cellule a pour ambition d’améliorer la manière dont les différents groupes de contributeurs du core se coordonnent et de faciliter la collaboration entre ces équipes. Toutefois, cette annonce n’a été que l’étincelle : le désaccord qui en a résulté prend racine dans des tensions antérieures.

Mary Hubbard a publié une présentation de la mission de la nouvelle équipe :

Elle a expliqué que l’objectif principal de cette équipe est de renforcer la coordination entre les équipes du noyau, d’optimiser l’efficacité et de rendre la contribution plus accessible. La Core Program Team doit se concentrer sur la documentation des pratiques, la mise en lumière des feuilles de route et l’accompagnement des équipes naissantes grâce à des processus clarifiés.

Il a été précisé que cette équipe ne définira pas l’orientation produit : chaque équipe du core conserve son autonomie. Le rôle du Programme est davantage d’écouter, de connecter et de réduire les frictions afin que les contributeurs puissent travailler ensemble plus sereinement.

Cette annonce a provoqué une réaction vive : une intervention d’une membre de l’équipe documentation, Jenni McKinnon, a été publiée puis retirée. Le message — assez solennel — mettait en avant un examen juridique et procédural en cours qui, selon l’autrice, affectait la gouvernance structurelle du projet. Elle affirmait participer à ce contrôle en qualité de responsable au sein d’une entité identifiée comme SSRO (Strategic Social Resilience Operations) et demandait la suspension des actions liées à la nouvelle équipe tant que la revue n’était pas terminée.

Le message exigeait la mise en pause immédiate de la publication et du programme décrit. Il indiquait aussi que toute décision imputée à Mary Hubbard dans ce contexte serait considérée comme procéduralement invalide et intégrée au dossier légal. Enfin, il demandait que toutes les communications officielles relatives à ce point se fassent uniquement par des canaux sécurisés ou à l’issue de la revue.

La publication de cette déclaration a suscité étonnement et de nombreuses questions au sein des groupes Slack et Facebook liés à WordPress. Pour comprendre pleinement la dynamique, il faut remonter aux échanges antérieurs qui portaient sur la participation de l’équipe documentation lors des cycles de sortie.

Participation de l’équipe Documentation

Le 10 septembre, une prise de parole d’Estela Rueda, membre de l’équipe documentation, a attiré l’attention sur une expérimentation menée par la release squad de la version 6.9. Selon elle, l’équipe de sortie testait une configuration réduite qui excluait les responsables documentation, proposant à la place un poste transitoire de « Docs Liaison ». Dans son message, elle expliquait pourquoi cette exclusion pose problème, rappelait l’importance vitale de la documentation dans le cycle de sortie et demandait que le rôle de responsable documentation soit rétabli pour les prochaines versions.

Dans son billet, Estela Rueda a détaillé les risques :

Elle a souligné que l’absence de représentants de la documentation au sein de la release squad entraîne trop souvent une sous-estimation de la documentation lors de la planification et de la coordination des projets. La documentation n’est pas un élément accessoire : c’est une composante essentielle au maintien et à l’évolutivité du projet. Si l’on retire ce rôle de la gestion des sorties, on transmet le signal que documenter n’est pas prioritaire et on décourage de nouveaux contributeurs qui ne verront pas leur travail valorisé.

La réaction d’Jenni McKinnon, également membre de l’équipe documentation, a repris ces thèmes et ajouté une critique plus politique :

Elle a défendu le principe d’open source véritablement inclusif et affirmé que l’approche de retirer le rôle Docs sous prétexte de « réduire la charge » paraît excluante et potentiellement toxique. Retirer cette visibilité à la documentation risque d’affaiblir la transparence, l’engagement des contributeurs et l’équité dans la reconnaissance des contributions.

Ses propos se sont ensuite durcis : elle a laissé entendre que la proposition initiale avait été poussée par Mary Hubbard et qu’elle indiquait une dérive vers un modèle plus hiérarchique « top-down », accusant ce mouvement d’avoir généré des comportements problématiques en coulisses.

Elle a affirmé que, malgré l’apparence collaborative du projet, la proposition reflétait une volonté centralisatrice menée par Mary Hubbard, et que cela avait causé des préjudices, y compris des comportements abusifs non publics. Elle insistait sur la nécessité d’alerter la communauté sur ces dynamiques et leurs conséquences.

Capture d’écran du commentaire du 10 septembre

Un membre de l’équipe Documentation prié de se retirer

Le point d’orgue a été atteint aujourd’hui avec la publication d’un message indiquant qu’Jenni McKinnon avait été invitée à « se mettre en retrait » de l’équipe documentation. Ce communiqué, signé par Milana Cap, précise les raisons et la procédure envisagée par la direction de l’équipe docs.

Dans sa note, Milana Cap explique pourquoi cette décision a été prise :

Elle indique que la direction de l’équipe documentation a demandé à Jenni de se retirer temporairement. La source du problème est liée aux récents changements dans la structuration de la release squad et aux discussions sur le rôle de la documentation dans les sorties. Selon la direction, Jenni a publié des commentaires jugés non alignés avec les objectifs de l’équipe, incluant des appels à des changements majeurs à l’échelle du projet et des demandes de retrait de certains responsables.

Ces positions auraient contredit l’intention affichée de l’équipe documentation. Après des démarches privées visant à désamorcer la situation et des demandes répétées pour que Jenni cesse ces publications, l’équipe a estimé qu’il était nécessaire de lui demander un retrait temporaire pour réévaluer sa participation. La porte est laissée ouverte à un éventuel retour si les conditions sont favorables à la fois pour elle et pour l’équipe.

Cette décision interne semble avoir précipité la réaction publique observée dans les commentaires de l’annonce de Mary Hubbard, alimentant un débat qui dépasse la seule question du rôle de la documentation.

Prise de recul : le tableau d’ensemble

À première vue, les événements décrits sont des tensions internes ponctuelles. Néanmoins, plusieurs voix au sein de la communauté soulignent des problèmes structurels plus profonds : une dette technique croissante sur le core, une inquiétude quant à l’orientation stratégique et des signaux de fatigue générale chez les contributeurs. Ces éléments, mis bout à bout, donnent l’impression à certains observateurs que des fissures commencent à apparaître dans la gouvernance du projet.

Sur le plan humain, l’épuisement (ou burnout) est un facteur souvent évoqué. Dans les commentaires de son billet, Estela Rueda rappelait que le nombre de contributeurs varie fortement selon les sorties et les projets, et que ceux qui restent sur la durée finissent fréquemment par se sentir épuisés et devoir prendre des pauses.

Elle a noté que l’effet de vague des contributions rend la continuité difficile, et que les contributeurs de longue date affichent parfois des signes d’épuisement nécessitant des pauses pour préserver leur engagement à long terme.

Pour un observateur extérieur, ces incidents — la remise en question des rôles, l’éviction temporaire d’un membre, les allégations de contrôle centralisé — peuvent donner l’impression d’une fragilité organisationnelle. Mais il est important de replacer ces événements dans leur contexte :

• WordPress est un projet massif, soutenu par une communauté mondiale qui combine bénévoles, contributeurs salariés et structures d’organisation. Les débats vifs y sont historiquement fréquents et font partie du processus d’ajustement.
• Les tensions autour de la documentation, bien que préoccupantes, révèlent aussi une prise de conscience utile : la documentation technique joue un rôle critique dans la scalabilité, l’adoption et la qualité perçue du produit. Sa marginalisation présente un risque concret, notamment pour l’interface entre code et utilisateurs.
• Les discussions sur la gouvernance et la conformité procédurale (notamment celles impliquant des revues juridiques) traduisent une maturation du projet vers des mécanismes de responsabilité plus formalisés, mais cela génère aussi des frictions lorsque ces mécanismes entrent en tension avec les pratiques communautaires établies.

Impacts potentiels sur le projet et sur le SEO

En tant que développeur et consultant SEO, je constate plusieurs conséquences possibles :

• Risques pour la documentation : si la documentation est perçue comme secondaire, les ressources et l’attention allouées risquent de diminuer. Or une documentation incomplète ou obsolète nuit directement à la capacité des développeurs à intégrer correctement WP et à la qualité des tutoriels et articles techniques disponibles en ligne. Cela peut altérer la visibilité organique des contenus liés à WordPress, car les développeurs et créateurs de contenu s’appuient fortement sur la documentation officielle pour écrire des guides et articles optimisés.
• Confiance de la communauté : une gouvernance perçue comme centralisée peut décourager les nouveaux contributeurs et pousser certains acteurs clés à se retirer, réduisant le vivier de talents qui assure la maintenance et l’innovation sur le long terme.
• Visibilité et adoption : des frictions prolongées et une communication mal gérée peuvent créer un flou autour des priorités du projet, ce qui a un effet secondaire sur l’écosystème (extensions, thèmes, services). Dans le pire des cas, cela ralentit les intégrations et la mise à jour des sites existants, affectant indirectement le référencement et la sécurité du parc de sites WP.

Aspects de gouvernance et gestion de conflit

Les éléments mis au jour dans cette affaire pointent vers des questions de gouvernance courantes dans les grands projets open source :

• Clarté des rôles : lorsque les responsabilités (par ex. qui prend les décisions opérationnelles) ne sont pas clairement définies et communiquées, les malentendus se multiplient. La création d’une Core Program Team visant à clarifier les processus est une réponse logique, mais son introduction doit être accompagnée d’une communication transparente et d’un calendrier partagé.
• Procédures disciplinaires et d’escalade : la demande de retrait temporaire d’un membre montre qu’il existe des mécanismes pour gérer les situations conflictuelles. Il est crucial que ces mécanismes soient perçus comme équitables, proportionnés et accessibles, afin d’éviter les accusations de décisions arbitraires.
• Médiation : dans les communautés dispersées, des médiateurs neutres et reconnus peuvent aider à rapprocher des positions opposées et à réduire l’intensité des affrontements publics.

Recommandations pratiques (orientation constructive)

Sans proposer de solutions miracles, voici plusieurs pistes concrètes et rationnelles qui pourraient améliorer la situation et prévenir des tensions similaires :

• Renforcer la documentation comme priorité stratégique : formaliser le rôle des leads documentation au sein des release squads. Cela garantit une présence systématique lors des décisions importantes et protège la qualité des livrables.
• Transparence des processus : publier des procédures claires pour la création d’équipes transversales (Core Program Team), les objectifs attendus, la durée des expérimentations et les critères d’évaluation. Mettre en place des compte-rendus publics simplifiés pour permettre à la communauté de suivre l’avancement.
• Canaux sécurisés pour les sujets sensibles : lorsque des revues juridiques ou des questions de conformité sont en cours, préciser comment la communication externe doit être gérée afin d’éviter la désinformation ou les interprétations erronées.
• Mécanismes de restitution et de feedback : instaurer des boucles de feedback régulières entre les équipes (Core, Docs, Release) et la communauté, avec des revues de fin d’expérimentation pour décider des ajustements nécessaires.
• Soutien à la santé des contributeurs : reconnaître explicitement le risque de burnout et mettre en place des ressources (rotations, périodes de pause encouragées, documentation de passation) pour assurer la pérennité des compétences clés.
• Médiation externe : faire appel à des facilitateurs ou médiateurs reconnus par la communauté pour gérer les ruptures de confiance et aider à reconstruire des relations de travail sereines.

Conséquences possibles à court et moyen terme

À court terme, on peut s’attendre à une période de clarifications : audits internes, confirmations des rôles, ajustements de communication et éventuellement révisions de la structure proposée pour la Core Program Team. Les discussions publiques vont probablement perdurer tant que des réponses complètes ne seront pas apportées sur la gouvernance et les recours procéduraux évoqués.

À moyen terme, si les acteurs prennent le temps de formaliser les processus et de restaurer la confiance, le projet peut ressortir renforcé de cet épisode : une gouvernance plus claire, une documentation mieux intégrée aux cycles de sortie et des pratiques de collaboration plus robustes sont autant d’atouts qui profiteront à l’ensemble de l’écosystème WordPress.

Conclusion — points à retenir

Ce différend met en lumière plusieurs enjeux structurants : la place centrale de la documentation, la nécessité d’une gouvernance claire et partagée, la gestion des tensions publiques vs. privées, et l’importance de protéger la santé des contributeurs. En tant que développeur et consultant en SEO, j’insiste sur le fait que la documentation est un levier majeur pour la qualité des implémentations et la visibilité organique autour d’WordPress. Une documentation fiable, maintenue et valorisée est un actif stratégique pour tout projet logiciel à large adoption.

Enfin, bien que cet épisode ait pris une tournure remarquée, il s’inscrit dans la vie d’un grand projet open source : des frictions surgissent, des ajustements se font, et l’équilibre entre autonomie des équipes et coordination centralisée est un sujet permanent. L’efficacité de la résolution dépendra de la capacité des acteurs à formaliser des règles claires, à restaurer la confiance et à préserver l’engagement des contributeurs à long terme.