Plugins WordPress sous licence GPL : ce que vous obtenez vraiment

Un plugin premium vous est fourni sous la forme d’un fichier ZIP. Vous l’installez, trouvez la fonctionnalité recherchée et l’intégrez à votre site. Puis le tableau de bord vous demande une clé de licence. Le téléchargement a fonctionné, mais les mises à jour automatiques, une bibliothèque de modèles ou un service hébergé peuvent encore nécessiter un compte distinct.

Ce décalage explique une grande partie des malentendus concernant les plugins WordPress sous licence GPL. Une licence logicielle, une copie du logiciel et un abonnement auprès du développeur peuvent être réunis dans un même achat. Ils restent toutefois trois éléments différents.

Lorsqu’une copie est couverte par la GPL et distribuée conformément à ses conditions, vous disposez des libertés d’utiliser, d’étudier, de modifier et de redistribuer le logiciel dans le cadre de cette licence. Un téléchargement fourni par un tiers ne vous donne pas, à lui seul, droit aux serveurs de mise à jour du développeur d’origine, à son équipe d’assistance ou à ses services cloud payants. Il ne prouve pas non plus qui a fourni les fichiers ni s’ils ont été modifiés.

Ce guide distingue ces différents éléments pour vous aider à choisir une solution abordable sans supposer ce qu’elle comprend. Commencez par la fonctionnalité nécessaire à votre projet, déterminez où elle s’exécute, puis vérifiez qui en assurera la maintenance. Ces trois questions sont plus utiles qu’une évaluation fondée uniquement sur la mention GPL d’une offre.

Que sont les plugins WordPress sous licence GPL ?

GPL signifie GNU General Public License, ou licence publique générale GNU. WordPress lui-même est distribué sous GPLv2 ou toute version ultérieure. Le projet WordPress considère ses plugins et ses thèmes comme des œuvres dérivées qui héritent de la GPL, tout en reconnaissant sur sa page consacrée aux licences qu’il existe des zones d’incertitude juridique quant à la définition d’une œuvre dérivée. Consultez les mentions du produit concerné plutôt que de supposer que tous les produits présentés comme étant « pour WordPress » ont les mêmes conditions. Les informations de WordPress sur sa licence exposent cette position.

Les libertés concrètes sont simples :

• Utiliser : exécuter le logiciel couvert par la licence pour votre propre projet, y compris un projet commercial.
• Étudier : examiner le code source pour comprendre son fonctionnement.
• Modifier : adapter le code couvert par la licence à vos besoins.
• Partager : redistribuer des copies originales ou modifiées en respectant les conditions applicables de la licence.

Ces libertés sont attachées au logiciel ; elles ne constituent pas une promesse qu’une autre personne fera le travail à votre place. Vous pouvez, par exemple, engager un développeur pour apporter une modification, mais la licence n’inclut pas son temps de travail. La définition du logiciel libre proposée par GNU distingue clairement la liberté des utilisateurs du prix du logiciel.

Acheter une copie ne transfère pas les droits d’auteur

Les auteurs conservent leurs droits d’auteur. La GPL accorde des autorisations aux destinataires ; elle ne transforme pas le programme en contenu sans propriétaire. Sous GPLv2, la redistribution implique des obligations relatives aux mentions de licence et de droits d’auteur, aux indications de modification lorsque cela s’applique, ainsi qu’au code source correspondant lors de la distribution de formes exécutables. Les obligations exactes dépendent de la licence et de la manière dont vous distribuez l’œuvre. Consultez le texte de la licence GPLv2.

Pour un propriétaire de site, installer un plugin et exercer une activité de revente sont donc deux démarches différentes. Conserver les informations relatives à la licence du produit est utile dans les deux cas. Si vous transmettez ensuite les fichiers à un client ou redistribuez un ensemble modifié, examinez les obligations correspondantes avant de le faire.

Une modification destinée à un usage privé n’exige généralement pas que vous publiiez vos changements pour tout le monde. GNU distingue l’usage interne de la distribution dans sa FAQ sur les modifications privées.

Pourquoi un logiciel GPL peut être vendu

Un développeur peut faire payer une copie. Un redistributeur qui respecte la licence le peut également. L’expression « logiciel libre » désigne des libertés ; elle ne signifie donc pas que chaque fournisseur doit proposer un téléchargement gratuit. La FAQ de GNU sur la vente de logiciels GPL confirme que la distribution commerciale est autorisée.

Une offre peut facturer des téléchargements individuels, l’accès à un catalogue ou des services de livraison. La question utile au moment de l’achat est de savoir ce que ce paiement vous apporte. Un ensemble moins cher peut être intéressant si les fichiers inclus conviennent à votre projet et si vous êtes en mesure de les maintenir. Un abonnement auprès du développeur peut être pertinent si les services du compte vous font gagner du travail ou fournissent une fonctionnalité indispensable. Aucune de ces conclusions ne découle du seul prix.

Ce que comprend l’offre : droits, fichiers et services

Imaginez que vous comparez deux offres pour le même plugin. Toutes deux mentionnent un accès GPL, mais l’une inclut un compte auprès du développeur tandis que l’autre fournit les téléchargements sur son propre portail. Utilisez ce tableau pour faire apparaître les différences avant de comparer les coûts.

Lisez chaque ligne séparément. Un vendeur peut apporter une aide réactive à l’installation sans fournir l’assistance du développeur d’origine. Un ensemble peut contenir une part importante du code premium sans donner accès à un service cloud. Une licence autorisant la redistribution ne peut pas authentifier un fichier ZIP particulier.

Le tableau vous aide aussi à formuler vos besoins. Remplacez « j’ai besoin de la version premium » par « je dois créer ce formulaire, recevoir les demandes envoyées et obtenir des versions maintenues ». Cette formulation se vérifie plus facilement dans la documentation et sur un site de test.

Pour un travail en équipe, conservez le tableau complété avec les notes du projet. Plusieurs mois plus tard, la personne chargée d’une mise à jour doit pouvoir retrouver le fournisseur et le processus de maintenance sans reconstituer les détails d’un ancien achat.

Plugins WordPress premium : la licence GPL et les clés sont deux choses différentes

Une clé de licence est généralement un identifiant au sein du système d’un fournisseur. Ce qu’elle permet dépend du produit. Elle peut relier une installation aux mises à jour, à l’assistance, à du contenu téléchargeable ou à un service payant. Appuyez-vous sur la documentation du fournisseur pour comprendre ce comportement : la présence d’un champ de clé dans le tableau de bord ne suffit pas à en déterminer la fonction.

Lorsque vous examinez la licence GPL des plugins WordPress premium, distinguez trois éléments : le code couvert par la licence, le fonctionnement de la fonctionnalité installée et le droit d’accès vérifié par le fournisseur. Étudiez le parcours que vous souhaitez utiliser plutôt que de vous fier à une affirmation générale telle que « fonctionnalités premium incluses ».

Les fonctions locales peuvent être utiles sans service hébergé

Prenons un exemple fictif : un plugin calcule un résultat à partir d’informations déjà stockées sur votre serveur. Si le code nécessaire est inclus et peut fonctionner dans votre environnement, le calcul n’a peut-être pas besoin d’un compte distant. Une distribution fournie par un tiers pourrait convenir à cet usage.

Ajoutons maintenant une exigence : le résultat doit être envoyé par une plateforme de messagerie payante. Le calcul local et l’envoi du message reposent sur des dépendances différentes. Même si le code d’intégration du plugin est présent, l’accès au service de messagerie doit faire l’objet d’un accord distinct.

Cette distinction vous évite de payer pour un service inutile et vous aide à prévoir le budget d’un service indispensable. Décrivez le besoin sous la forme d’une action observable : « Le visiteur envoie le formulaire, les données sont enregistrées et la confirmation arrive dans la boîte de réception. » Identifiez ensuite les parties qui relèvent du plugin, de votre hébergement et d’un prestataire externe.

Elementor : anticiper les fonctions dépendantes de l’abonnement

Les informations d’Elementor sur le renouvellement montrent pourquoi les affirmations générales concernant un accès premium expiré sont peu fiables. Sa documentation sur l’expiration indique qu’en l’absence de renouvellement, l’accès aux mises à jour Pro et à l’ajout de fonctionnalités Pro est supprimé, et que l’accès aux fonctionnalités Pro existantes peut être limité. Une copie installée ne doit donc pas être considérée comme une garantie que toutes les fonctions de modification premium resteront disponibles indéfiniment. Vérifiez les exigences actuelles des fonctionnalités nécessaires à votre projet. La documentation d’Elementor sur l’expiration de l’abonnement fournit la référence pertinente.

Pour un projet utilisant un constructeur de pages, distinguez la page publiée de la possibilité de la modifier et de l’enrichir ultérieurement. Un client qui prévoit des changements réguliers de mise en page a besoin d’une organisation de maintenance qui couvre le travail de modification, et pas seulement d’un téléchargement initial. La comparaison entre les versions GPL et nulled d’Elementor approfondit ce choix propre au produit.

Wordfence : modifier l’interface ne donne pas accès au cloud

Wordfence établit une distinction encore plus nette. L’entreprise indique que ses services Premium payants sont fournis par ses serveurs cloud et nécessitent une clé payante achetée auprès de Wordfence. Modifier une interface locale pour qu’elle affiche « Premium » ne donne pas accès à ces services. Les explications de Wordfence sur son produit authentique décrivent cette dépendance.

Ce principe dépasse le cas des plugins de sécurité : vérifiez d’où provient le bénéfice recherché. Si vous avez besoin d’un flux de données précis, d’un traitement hébergé ou d’un service rattaché à un compte, confirmez directement le droit d’accès à ce service. Le nom d’une fonctionnalité affiché dans un tableau de bord constitue une preuve moins solide qu’une confirmation d’accès par le prestataire. Pour comprendre le rôle plus large du produit, consultez notre présentation de Wordfence Premium.

Mises à jour : posséder une copie et maintenir un site

Les fichiers reçus aujourd’hui ne représentent qu’une étape dans la vie d’un site. WordPress, PHP, votre thème et les autres plugins continuent d’évoluer autour d’eux. Une décision d’achat pertinente prévoit un moyen d’assurer la maintenance future.

Notez trois étapes distinctes :

1. Obtenir la version : qui met à votre disposition un ensemble maintenu ?
2. La livrer : comment cet ensemble arrive-t-il sur l’installation ?
3. Valider le résultat : qui confirme que les parcours importants du site fonctionnent encore ?

Un outil de mise à jour automatique s’occupe de la livraison. Il ne remplace pas les deux autres étapes. Un téléchargement manuel peut également convenir si une personne est responsable du processus et dispose du temps nécessaire. Choisissez une organisation que vous pourrez appliquer régulièrement.

Lire les promesses de mise à jour comme des conditions de service

« Mises à jour incluses » appelle une deuxième phrase. L’offre prévoit-elle un accès aux téléchargements pendant un abonnement actif, une livraison par un outil de mise à jour distinct ou un accès lié à un achat particulier ? Les modules complémentaires sont-ils couverts ? Que se passe-t-il lorsque l’accès prend fin ? Consignez les conditions actuelles du produit et de la formule plutôt que de généraliser une promesse affichée pour tout un catalogue.

Une licence de code source n’oblige pas un fournisseur à vous envoyer indéfiniment toutes les versions futures. Cette fourniture constitue une promesse de service à évaluer séparément. Évitez de fonder un projet sur une mention « à vie » si les conditions exactes n’expliquent pas ce que cette durée signifie et quel service elle concerne.

Vérifier séparément les parcours importants

Pour un site de réservation, la vérification de maintenance doit comprendre une réservation. Pour une boutique, elle doit inclure le parcours d’achat pertinent. Pour un site de génération de prospects, elle doit comprendre l’envoi et la réception d’une demande. L’activation réussie d’un plugin n’est que le début de ces vérifications.

Utilisez un environnement de préproduction lorsque c’est possible et prévoyez une solution de restauration avant de remplacer un composant important. La documentation de WordPress sur les mises à jour recommande de réaliser des sauvegardes au préalable. Nos présentations de WP STAGING Pro et d’UpdraftPlus Premium permettent de poursuivre la réflexion sur la préproduction et la restauration.

Le meilleur processus de maintenance est celui qui reste utilisable lors d’un changement de personnel. Conservez suffisamment de notes pour qu’une autre personne puisse obtenir le bon ensemble, comprendre ses dépendances et répéter les vérifications essentielles.

Assistance : identifier la personne responsable

Supposons qu’une mise à jour casse une mise en page. Un distributeur peut aider à installer un ensemble de remplacement, tandis que le développeur d’origine peut être mieux placé pour rechercher un défaut du produit. Votre agence peut être responsable de la personnalisation du thème à l’origine du conflit. Ce sont des missions d’assistance différentes.

Avant d’acheter, identifiez le prestataire qui prendra en charge le problème que vous êtes le moins en mesure de résoudre. « Assistance incluse » doit renvoyer à un périmètre précis : aide à l’installation, diagnostic, transmission au développeur, intervention sur du code personnalisé ou autre. Ne supposez pas qu’un achat auprès d’un tiers crée une relation client avec l’auteur d’origine.

Pour un projet personnel simple, la documentation et vos propres compétences de maintenance peuvent suffire. Pour un site client assorti d’une échéance, l’accès à l’équipe du développeur peut justifier un abonnement officiel même lorsque le logiciel est disponible ailleurs. Le facteur déterminant est la responsabilité qui reste à assumer, et non l’idée que chaque projet aurait besoin de la même formule d’assistance.

Précisez cette responsabilité lors de la remise du projet. Si le client s’attend à ce que le site reste maintenu, indiquez le titulaire du compte, la personne qui paie les services futurs et celle qui applique les mises à jour. Une promesse vague d’« inclure le plugin » laisse ces trois questions sans réponse.

Thèmes WordPress sous licence GPL : examiner tout l’ensemble graphique

L’achat d’un thème comprend souvent davantage que le code qui affiche votre site. Il peut inclure des modèles, des polices, des photographies, des données de démonstration et des connexions à une bibliothèque hébergée par l’auteur. Consultez les mentions de licence de ces composants et les conditions de tout service distinct.

Le répertoire de thèmes de WordPress.org exige une licence compatible avec la GPL pour les thèmes soumis, y compris les ressources qu’ils contiennent. Cette exigence constitue une référence utile, mais elle ne prouve ni le contenu ni la licence d’un téléchargement provenant d’une autre place de marché. Consultez les exigences de vérification des thèmes WordPress.

Dans un exemple de projet de portfolio, l’intérêt peut résider dans la mise en page du thème, alors que les photographies de démonstration sont inutiles. Les remplacer par vos propres créations retire une dépendance du projet graphique. Pour un projet construit autour d’une collection précise de modèles téléchargeables, les conditions d’accès à la bibliothèque ont beaucoup plus d’importance.

Dressez une courte liste des ressources avant de vous engager à reproduire une démonstration :

• Quelles mises en page sont réellement comprises dans l’ensemble fourni ?
• Quelles images, polices et icônes apparaîtront sur le site terminé ?
• Où se trouvent les mentions de licence et d’attribution correspondantes ?
• Quelles ressources nécessitent un compte distinct ou un téléchargement ultérieur ?

Distinguez également les autorisations relatives au logiciel de celles qui concernent la marque. La GPL ne signifie pas qu’une place de marché est affiliée au développeur d’origine. WordPress dispose lui-même d’une politique de marque distincte, qui illustre pourquoi une licence logicielle et une politique de marque répondent à des questions différentes.

Le thème choisi doit vous permettre de réaliser un design concret, et pas seulement offrir un bel aperçu. Confirmez la présence des composants nécessaires avant de promettre à un client l’apparence exacte de la démonstration.

GPL, nulled et provenance : demander ce qui a été fait aux fichiers

GPL décrit une licence. Dans les discussions sur les places de marché, « nulled » désigne couramment un logiciel modifié pour supprimer ou contourner les mécanismes liés à la licence. Les vendeurs n’utilisent pas ce terme de manière uniforme ; demandez donc une explication des modifications réelles plutôt que de considérer l’étiquette comme un rapport technique complet.

Une modification n’est pas, à elle seule, une preuve de logiciel malveillant ou d’infraction juridique systématique. La GPL autorise les modifications dans le cadre de ses conditions. Un changement déclaré peut néanmoins avoir des conséquences pratiques : il peut affecter les mises à jour, les requêtes externes ou la compatibilité. Un changement non déclaré vous laisse avec moins d’informations pour établir un diagnostic.

De même, une affirmation selon laquelle les fichiers sont « intacts » doit être étayée par des éléments de provenance. Qui a fourni l’archive ? Quelles preuves soutiennent cette affirmation ? L’identité du produit et les mentions de licence sont-elles cohérentes ? Lorsqu’un ensemble de référence fiable est disponible, une comparaison peut aider à révéler des différences. Elle n’explique pas automatiquement leur objectif et ne prouve pas que chaque fichier est sûr.

Adaptez cette évaluation aux enjeux du projet. Un prototype local jetable et une boutique client en ligne ne subissent pas les mêmes conséquences lorsqu’un composant cesse de fonctionner. Dans les deux cas, consignez ce que vous savez et ce qui reste incertain. La confiance doit reposer sur des preuves identifiables, une documentation utile et un processus de livraison que vous pouvez maintenir, plutôt que sur une mention réunissant licence et sécurité en une seule affirmation.

Des fichiers authentiques nécessitent aussi un suivi de sécurité

Un ensemble peut correspondre aux fichiers originaux du développeur tout en contenant une vulnérabilité connue présente dans le logiciel d’origine. L’authenticité renseigne sur la provenance des fichiers ; le suivi de sécurité consiste à déterminer si un problème touche le logiciel installé et quelle intervention permet d’y remédier.

Lorsque vous examinez un avis de sécurité, comparez l’identité exacte du produit et la version installée aux plages de versions concernées. Des noms similaires ou la mention « dernière version » d’un vendeur ne suffisent pas. Recherchez le correctif ou la mesure d’atténuation indiquée, puis obtenez-le par votre processus de maintenance. La base publique de vulnérabilités de Patchstack est l’une des ressources possibles pour cette recherche ; l’absence de problème répertorié ne prouve pas qu’un ensemble est sécurisé.

Utilisez les analyses et les essais en préproduction selon leur objectif précis. Les options d’analyse documentées par Wordfence décrivent des vérifications de signatures malveillantes connues et de motifs suspects, dont le périmètre dépend des réglages. Un essai en préproduction montre si un parcours fonctionne dans cet environnement. Ces vérifications ne peuvent pas établir l’absence de toute vulnérabilité ou de toute modification nuisible. Distinguez la vérification des fichiers du suivi des mises à jour et désignez une personne chargée de suivre les avis pertinents après l’installation.

Trois décisions de projet à partir du même tableau

Les exemples suivants sont des scénarios de planification illustratifs, et non des comptes rendus de tests de plugins ou de résultats obtenus par des clients.

Un indépendant qui explore un nouveau design de site

L’indépendant souhaite comparer des mises en page et tester un parcours local avant de s’engager sur un site client. Aucune fonctionnalité cloud payante n’est nécessaire à cette exploration. Les priorités sont des fichiers utilisables, des mentions de licence claires et un environnement dans lequel les expériences peuvent être abandonnées.

Un accès GPL fourni par un tiers pourrait être un moyen pratique d’évaluer le code disponible, à condition que les fichiers et les conditions répondent à ces besoins. Avant de l’adopter en production, l’indépendant doit réexaminer les mises à jour, les dépendances des fonctions de modification premium et la remise du projet. Un choix adapté à l’exploration n’est pas automatiquement une organisation complète de maintenance.

La décision peut être consignée brièvement : « Adapté à ce prototype ; la mise en production nécessite un processus de mise à jour confirmé et les services associés aux comptes dont le client a besoin. » Cette phrase préserve le résultat utile sans exagérer la portée de l’achat.

Une agence qui livre un site de génération de prospects

L’agence a besoin de davantage qu’un formulaire sur une page. Les demandes doivent être enregistrées ou acheminées correctement, les notifications doivent parvenir au client et une personne doit résoudre les incidents après la remise du site.

Commencez par répertorier chaque dépendance. Si les fonctions locales du formulaire sont fournies dans l’ensemble, évaluez-les séparément de l’envoi des e-mails ou d’un service CRM. Attribuez ensuite la responsabilité des identifiants et de la relation d’assistance. Le client doit savoir quels abonnements sont récurrents et quel prestataire contacter.

Une formule officielle du développeur peut être le bon choix lorsque l’assistance directe ou des fonctionnalités liées à un compte sont essentielles. Une distribution fournie par un tiers peut convenir à une autre organisation dans laquelle l’agence assure la maintenance et les services indépendants nécessaires. L’agence doit chiffrer la responsabilité qu’elle accepte, et pas seulement le téléchargement.

Une boutique qui choisit un composant de sécurité

Le propriétaire de la boutique a précisément besoin d’un service payant d’information sur les menaces et suppose qu’un plugin affichant la mention premium le fournira. L’exemple de Wordfence montre pourquoi le droit d’accès doit être vérifié auprès du prestataire du service.

La décision doit commencer par cette dépendance : obtenir l’accès légitime au service nécessaire, puis choisir et maintenir le logiciel compatible. Si le propriétaire choisit plutôt un niveau de service gratuit, documentez son périmètre réel. Ne le présentez pas comme donnant accès à un flux payant simplement parce qu’un écran local affiche une mention premium.

Ici, un coût de téléchargement inférieur ne peut pas remplacer le service requis. Dans un autre projet, le code exécuté localement peut répondre à l’ensemble du besoin. L’application du même tableau clarifie les deux décisions.

Une liste de vérification avant l’achat ou l’installation

Utilisez cette liste pour transformer une offre générale en un choix précis pour votre projet. Elle sert de point de repère ; les procédures détaillées d’inspection et de mise à jour méritent un traitement distinct.

1. Définissez le résultat attendu. Décrivez l’action que le plugin ou le thème doit permettre. « Créer et modifier les pages de demande de renseignements du client » est plus clair que « obtenir Pro ».
2. Lisez la licence de l’ensemble. Vérifiez les mentions effectives, les composants inclus et les conditions distinctes de certaines ressources. Conservez-les dans le dossier du projet.
3. Identifiez les fichiers fournis. Établissez quels ZIP et modules complémentaires sont inclus, qui les fournit et si des modifications sont déclarées.
4. Répertoriez les dépendances externes. Notez les comptes développeur, clés API, fonctionnalités hébergées et bibliothèques téléchargeables nécessaires au résultat.
5. Confirmez l’accès futur. Consignez la manière dont les versions maintenues vous parviendront, la durée de livraison promise par le fournisseur et les conséquences du renouvellement.
6. Attribuez l’assistance. Nommez la personne ou le prestataire responsable des problèmes d’installation, des défauts du produit et des intégrations personnalisées.
7. Vérifiez l’adéquation opérationnelle. Examinez les exigences documentées et testez les parcours importants du projet dans un environnement approprié avant de vous y fier.
8. Préparez la remise du projet. Conservez les coordonnées des fournisseurs, les conditions de service, les notes de restauration et les titulaires des comptes là où la prochaine personne chargée de la maintenance pourra les trouver.

Si une réponse essentielle manque, résolvez cette dépendance avant de l’intégrer à une promesse faite au client. Vous pouvez continuer à évaluer les autres possibilités entre-temps. Une décision complète n’exige pas la solution la plus coûteuse ; elle exige un parcours crédible entre les fichiers reçus et le résultat nécessaire.

Les questions qui se posent après l’achat

L’utilisation d’un plugin GPL place-t-elle le contenu de mon site sous GPL ?

Vos articles et photographies ne deviennent pas GPL simplement parce qu’un programme GPL les traite. GNU distingue un programme de ce qu’il produit, tout en précisant qu’un résultat contenant des éléments copiés du programme peut soulever d’autres questions. Vérifiez séparément les modèles copiés et les ressources incluses. Les explications de GNU sur les résultats produits par un programme couvrent cette distinction.

Un client peut-il conserver le logiciel à la fin du contrat avec l’agence ?

Pour une copie couverte par la GPL et correctement fournie au client, les autorisations relatives au logiciel et les services de l’agence sont deux sujets distincts. La remise du projet doit expliquer quels comptes, mises à jour et dispositifs d’assistance continuent, expirent ou nécessitent un remplacement. Évitez de considérer la résiliation d’un contrat de maintenance comme une preuve que les droits sur le logiciel disparaissent.

Que faire si le distributeur cesse de proposer des téléchargements ?

Conservez les informations relatives aux fichiers et recherchez un autre processus légitime de maintenance. Posséder encore une archive ne signifie pas qu’elle est maintenue. Examinez si le développeur d’origine peut fournir une formule adaptée, si une autre source répond à vos exigences ou si remplacer le composant est la solution la plus praticable.

Évaluez l’offre selon les exigences de votre projet

Les plugins WordPress sous licence GPL peuvent fournir un accès utile et abordable à des logiciels riches en fonctionnalités. Leur intérêt apparaît plus clairement lorsque vous comprenez les droits couverts, les fichiers fournis et les services nécessaires à votre fonctionnement.

Complétez le tableau avant de comparer les offres. Choisissez l’organisation qui fournit les fonctionnalités nécessaires et confie la maintenance à une personne identifiée. Si vous souhaitez explorer les possibilités, utilisez le catalogue d’offres WPPerks comme point de départ, puis vérifiez les conditions actuelles du produit concerné et de chaque service distinct dont votre site a besoin.