Une agence partenaire nous a sollicités récemment pour revendre l’une de nos extensions de gestion de réservations sous son propre nom, avec sa propre grille tarifaire et son propre support de premier niveau. La proposition était intéressante commercialement, mais elle nous a obligés à formaliser, noir sur blanc, une série de points que nous vérifions désormais systématiquement avant d’accepter ce type d’accord, tant les zones grises sont nombreuses dans l’écosystème WordPress.
Ce billet ne traite pas de l’architecture technique freemium d’une extension, sujet déjà couvert par ailleurs, mais bien de ce qu’il faut vérifier en amont d’un accord de marque blanche, avant même de discuter des conditions commerciales.
La licence GPL ne se négocie pas
Toute extension WordPress, dès lors qu’elle s’appuie sur les fonctions du cœur, hérite obligatoirement de la licence GPL ou d’une licence compatible, conformément aux exigences du répertoire officiel et à la philosophie du projet. Cela signifie concrètement qu’une agence qui revend une extension en marque blanche ne peut légalement interdire à ses propres clients de redistribuer ou de modifier le code source qu’ils ont acquis, quelle que soit la marque affichée sur l’interface.
Ce point surprend souvent les agences venues d’univers logiciels différents, habituées à des licences propriétaires strictes. Avant tout accord, il vaut mieux s’assurer que l’agence revendeuse a bien compris cette contrainte, et qu’elle ne promet pas, dans ses propres conditions de vente, une exclusivité ou une confidentialité du code que la GPL rend juridiquement inapplicable.
Les dépendances tierces intégrées
Une extension complexe embarque souvent des bibliothèques tierces via Composer ou npm, chacune avec sa propre licence. Avant toute revente en marque blanche, il convient de vérifier que chaque dépendance reste compatible avec une redistribution commerciale, et que leurs conditions respectives, en particulier les licences de type MIT, Apache 2.0 ou BSD généralement compatibles, ne soient pas remplacées en cours de route par une version sous une licence plus restrictive lors d’une mise à jour future.
composer show --format=json | jq '.installed[] | {name, license}'Cette commande, lancée avant chaque nouvelle version majeure destinée à la revente, permet de vérifier rapidement qu’aucune dépendance n’a changé silencieusement de licence entre deux versions, un risque réel avec certains paquets qui évoluent vers des modèles de licence plus commerciaux au fil du temps.
La marque et l’origine du code
- Le nom affiché dans l’en-tête de l’extension et dans son écran de réglages doit clairement identifier l’agence revendeuse, sans laisser croire à une origine différente.
- Un client final doit pouvoir identifier, en cas de besoin, l’éditeur technique réel de l’extension, ne serait-ce que pour des raisons de responsabilité en cas de faille de sécurité découverte plus tard.
- Le texte de licence lui-même, présent dans le fichier
readme.txtou l’en-tête principal, ne doit jamais être modifié pour masquer l’origine du code, ce qui serait à la fois trompeur et contraire à l’esprit de la GPL.
Le support, contractuellement défini
Le point le plus souvent négligé dans ce type d’accord concerne le support. Une agence revendeuse promet naturellement un support de premier niveau à ses propres clients, mais que se passe-t-il lorsqu’un bug touche réellement le cœur de l’extension et nécessite une intervention de l’éditeur original ? Sans accord écrit précisant les délais de remontée, les canaux de communication et les responsabilités respectives, chaque incident devient une négociation informelle, rarement à l’avantage du client final.
Les questions à trancher avant signature
- Quel délai maximal s’engage l’éditeur original à respecter pour traiter un bug remonté par l’agence revendeuse ?
- Qui informe le client final en cas de faille de sécurité découverte dans le code d’origine, et sous quel délai ?
- L’agence revendeuse a-t-elle accès au dépôt de code source à jour, ou reçoit-elle uniquement les versions packagées, avec le risque de retard que cela implique ?
- Que se passe-t-il pour les clients existants si l’accord de marque blanche prend fin, l’extension continue-t-elle de fonctionner et de recevoir des mises à jour ?
Le serveur de mises à jour privé
Si l’extension n’est pas distribuée via WordPress.org, ce qui est généralement le cas en marque blanche, un serveur de mises à jour privé doit être mis en place, avec une gestion de licences propre à chaque revendeur. Ce sujet technique, déjà traité en détail ailleurs, mérite ici d’être vérifié sous un angle contractuel précis : qui héberge ce serveur, qui en assume la disponibilité, et que se passe-t-il pour les clients finaux si ce serveur venait à disparaître avec la fin de la relation commerciale entre les deux parties.
Une règle que nous appliquons désormais avant toute signature de ce type d’accord : si une question de licence, de support ou de continuité de service reste floue à l’oral, elle doit être tranchée par écrit avant la première vente, jamais après le premier incident.
En résumé
Vendre une extension en marque blanche engage bien plus que la simple cession d’un droit d’usage commercial : la licence GPL continue de s’appliquer, les dépendances tierces doivent rester surveillées, et le support doit être formalisé avant la première vente plutôt qu’improvisé au premier incident. Cette checklist ne remplace pas un accord juridique en bonne et due forme, mais elle évite d’aborder cette discussion en ignorant les points qui, dans notre expérience, finissent toujours par ressurgir.
