C'est du libre » rassure souvent les décideurs. Le code est ouvert, la licence permet de l'utiliser, de le modifier et de le redistribuer : la structure se croit protégée. Pourtant, deux projets également libres peuvent être gouvernés de façon radicalement différente, et c'est la gouvernance, pas la licence, qui détermine ce qui arrive à votre site le jour où le projet traverse une crise.

Cette fiche propose cinq questions à poser avant de s'engager, quel que soit le logiciel, puis un cas documenté pour montrer pourquoi elles comptent.

Qui détient le nom de domaine du projet et son dépôt d'extensions ou de modules ? C'est la question la plus importante et la moins posée. Le code peut être libre alors que l'infrastructure qui le distribue appartient à une entreprise ou à une personne privée.

Dans ce cas, l'accès aux mises à jour relève d'une décision privée, pas de la licence. Qui détient la marque ? Le droit d'utiliser le nom du logiciel dans une communication, une appellation de prestataire ou un appel d'offres dépend de ce point, indépendamment de la licence du code. Qui finance le développement, et dans quelle proportion ?

Un projet porté à l'essentiel par une seule entreprise suit les priorités commerciales de cette entreprise. Un projet porté par une association ou une fondation dotée d'un conseil indépendant suit les siennes. Aucun des deux modèles n'est mauvais en soi, mais ils ne présentent pas les mêmes risques.

Par où arrivent les mises à jour, et existe-t-il une autre voie ? Si toutes les mises à jour de sécurité transitent par une source unique, cette source est un point de défaillance, technique comme politique. Certaines communautés travaillent à des systèmes de distribution fédérés précisément pour cette raison.

Que se passe-t-il si cette source ferme ou vous ferme l'accès ? La réponse s'anticipe : inventaire des extensions installées, vérification que leur code est accessible ailleurs, sauvegardes restaurables, et un prestataire capable d'appliquer un correctif à la main.

WordPress fait tourner près de quatre sites web sur dix. Son dépôt d'extensions, wordpress.org, appartient personnellement à Matt Mullenweg, cofondateur du projet et dirigeant d'Automattic, l'entreprise qui édite WordPress.com.

En septembre 2024, à la suite d'un conflit public avec l'hébergeur WP Engine, l'accès de cet hébergeur aux extensions et aux mises à jour a été coupé. Un tribunal fédéral américain a ordonné son rétablissement en décembre 2024. Le mois précédent, le dépôt avait pris la main sur une extension éditée par WP Engine et installée sur des millions de sites. L'affaire judiciaire est toujours en cours : fin septembre 2026, quatre griefs pour pratiques anticoncurrentielles ont été maintenus. Les effets sur le projet lui-même sont documentés.

En janvier 2025, Automattic a réduit sa contribution au développement du cœur du logiciel. En juin 2025, la Linux Foundation a annoncé un système de distribution d'extensions fédéré, conçu pour supprimer la dépendance à une source centrale. Et en septembre 2026, le conseil d'administration d'Automattic a voté la mise en congé de son dirigeant, avant que celui-ci ne reprenne le contrôle trente-trois heures plus tard.

Aucun de ces épisodes n'a cassé les sites WordPress existants. Ils montrent en revanche ce qu'une structure accepte sans le savoir quand elle choisit un logiciel sans regarder qui le gouverne.

Cette fiche ne conclut pas qu'il faut quitter WordPress, ni qu'un modèle de gouvernance vaut mieux qu'un autre dans l'absolu. Elle propose d'ouvrir le sujet au moment du choix, quand il coûte encore peu, plutôt qu'au moment de la crise. Les mêmes questions se posent pour tout logiciel libre dont dépend un service public ou associatif, y compris les outils bureautiques, de messagerie et de visioconférence.