WordPress.com et WordPress.org : le piratage n'est pas le même

Deux produits, un seul nom dans la bouche des gens

WordPress.org, c'est le logiciel : vous (ou l'hébergeur) posez les fichiers, la base, les plugins. Un piratage, c'est un PHP, une option, un user, un voisin. WordPress.com, c'est une plateforme : pas de FTP classique sur le plan de base, thèmes et plugins limités, collabs et applications connectées. Un « hack » y ressemble plutôt à un compte volé, une app malveillante, un domaine personnalisé qui pointe encore vers une vieille machine, ou un Jetpack mal lié.

Traiter un site .com comme un .org (demander le FTP, réinstaller le cœur) bloque tout le monde. L'inverse — « Automattic va nettoyer » alors que vous êtes chez o2switch — attend une aide qui ne viendra pas. La première ligne du ticket, c'est l'hébergeur réel.

Les pages de cas de ce site parlent surtout .org, parce que c'est là que les fichiers et les boutiques PHP vivent. Le guide WordPress aussi. Si vous êtes .com, une partie des reco (mu-plugins, wp-config) ne s'applique pas ; d'autres (mots de passe, collabs, domaine) si.

Comment savoir où vous êtes

Vous payez Automattic / WordPress.com, l'admin est `wordpress.com/home/...`, pas de gestionnaire de fichiers hébergeur : plutôt .com. Vous avez cPanel, Plesk, un `wp-config.php`, un FTP : .org. Un domaine `truc.wordpress.com` est .com. Un `www.agence.fr` peut être les deux : domaine personnalisé branché sur .com, ou .org chez un hébergeur.

Les en-têtes HTTP (`x-hacker`, `host` chez Automattic, vs LiteSpeed / Apache chez l'hébergeur) et un whois / un panel aident. Si une agence a le seul accès, demandez : « qui a le contrat d'hébergement ? ». La facture tranche plus vite qu'un scan.

Un plan WordPress.com « Creator / Business » avec plugins ouverts se rapproche d'un .org hébergé chez eux : plus de surface, encore peu de FTP brut selon l'offre. Lisez l'offre, ne supposez pas.

• Contrat et facture d'hébergement.
• Présence d'un wp-config / FTP.
• URL de login réelle (wp-admin sur votre domaine vs wordpress.com).

Sur .com : apps, collab, Jetpack, domaine mappé

Révoquez les comptes collab que vous ne nommez pas, tournez votre mot de passe WordPress.com (et le 2FA), passez en revue les applications connectées. Un prestataire parti en 2021 avec un rôle Editor suffit. Ce n'est pas un mu-plugin ; c'est un compte plateforme.

Si le domaine est « mappé » : vérifiez les DNS. Un A record oublié vers un ancien VPS infecté donne un split-brain : une partie des visiteurs voit le site propre .com, l'autre le vieux WordPress pirate. Safe Browsing flag alors « votre » marque. Nettoyez ou éteignez l'ancien hôte — voisin / ancien serveur.

Le support Automattic traite les abus sur leur infra. Ils ne feront pas un constat CNIL à votre place, ni un ticket Stripe. Fournissez-leur des URL et des captures, pas « le site est lent ».

Sur .org : fichiers, plugins, voisin de compte

Là, les articles de ce lot s'appliquent : SMTP, REST, cron, options, thème enfant, staging. L'hébergeur fournit logs et archive. Un plugin de sécurité aide à trier, pas à clore. Commencez par WordPress piraté et les premiers gestes.

WooCommerce, Elementor, les thèmes nulled : c'est ce monde. WordPress.com simple n'a pas ce checkout-là. Si vous avez WooCommerce, vous n'êtes presque certainement pas sur un plan .com verrouillé.

Jetpack n'est pas une preuve de .com

Jetpack se pose sur un .org et parle à WordPress.com. Un site .org « hacked » avec Jetpack actif a parfois un compte WordPress.com lié : révoquez les connexions douteuses dans Jetpack / wordpress.com/me. Inversement, désinstaller Jetpack ne nettoie pas un shell PHP.

Les alertes « Jetpack scan » sont des signatures, comme Wordfence. Un JS dans les options passe. Traitez-les comme des pistes.

Ce que vous pouvez faire seul dans chaque cas

.com : mots de passe, 2FA, collabs, apps, DNS, ticket Automattic, éventuellement export des contenus et reconstruction. Vous ne comparerez pas de cœur ZIP.

.org : copie du compte, panel, FTP, users, options, comparaison de fichiers. Si wp-admin est down, le panel et WP-CLI restent. WP-CLI.

Dans les deux cas, un checkout ou une base clients sort du bricolage du dimanche. Créer un espace si le doute porte sur des cartes ou des exports.

Emails, SMTP et checkout selon l'hébergeur

Sur .com, l'envoi transactionnel passe par leur infra ; un spam « depuis votre domaine » vient plutôt d'un DNS / SPF cassé, d'une boîte ailleurs, ou d'un ancien hôte encore autorisé. Sur .org, le plugin SMTP et `mail()` du compte sont les suspects n°1 — WP Mail SMTP.

Un paiement Stripe branché sur .com (simple) vs WooCommerce .org : même prestataire, même devoir d'informer si un skimmer a pu voir des champs. Le HTML se lit dans les deux cas. La chasse au fichier PHP, seulement en .org.

Quand l'agence a « mis sur WordPress » sans préciser

Demandez le contrat, les accès, et qui facture l'hébergement. Tant que ce n'est pas clair, n'installez pas Wordfence « au cas où » sur une plateforme qui ne le permet pas, et n'attendez pas Automattic pour un VPS. Une heure de clarification évite trois jours de tickets croisés.

Si l'agence a les deux (un .com vitrine et un .org boutique), traitez-les comme deux sites. Un incident sur l'un n'absout pas l'autre — surtout si les DNS et les emails se partagent le domaine. Voir domaine blacklisté email.

• Hébergeur nommé (facture).
• Collabs / FTP / panel relus.
• DNS : un seul hôte utile par nom.
• Checkout : HTML relu, quel que soit le CMS.