Crater Stack : quatre plugins maison pour résoudre les problèmes des sites à l’international
1. Les quatre ruptures d’un site à l’international
Lors des audits de sites clients, ce qui revient sans cesse n’est pas un “manque de fonctionnalités”, mais l’information sur un même sujet dispersée à trois ou quatre endroits, sans synchronisation. Les quatre ruptures les plus typiques :
| Rupture | Symptôme | Coût réel |
|---|---|---|
| Rupture linguistique | Le plugin de traduction ne gère que la traduction, pas le hreflang ni les URL multilingues | La traduction est faite, mais introuvable dans la langue cible |
| Rupture des leads | Plugin de formulaires, outil statistique et CRM chacun de leur côté | Des demandes arrivent, mais impossible de savoir d’où, donc impossible d’optimiser |
| Rupture de sécurité | Soit aucune protection, soit un plugin de sécurité qui bloque tout | Les crawlers IA sont bloqués par erreur, le canal GEO devient inopérant |
| Rupture de contenu | Les actifs de contenu (documentation technique, études de cas) ne peuvent pas entrer en masse sur le site | Le temps de l’équipe contenu part dans la “copie manuelle” |
Le point commun de ces quatre ruptures : chaque maillon pris isolément fonctionne, c’est leur enchaînement qui pose problème.
Prenons la “rupture linguistique” : la fonction de traduction est très pratique, mais elle n’est pas reliée à la couche SEO, donc elle génère des pages en allemand sans hreflang ni URL allemande correspondants —la page existe, mais les moteurs de recherche ignorent son existence.
La logique de conception de la stack n’est donc pas d'”empiler des fonctionnalités”, mais de rendre chaque chaîne fluide de bout en bout.
2. LinguaSEO : la couche linguistique
Rupture traitée : traduction et SEO séparés.
Compétence clé
| Capacité | Contenu concret | Ce que ça résout |
|---|---|---|
| Traduction automatique | Traduction de contenu + changement de langue | Rendre le site lisible pour vos clients |
| URL multilingues | Une structure d’URL distincte par langue | Permettre aux moteurs de recherche de trouver chaque version linguistique |
| Génération automatique des balises hreflang | Liens réciproques et x-default générés automatiquement | Éviter le “contenu dupliqué” sur un site multilingue |
| Sitemaps multilingues | Un sitemap distinct par langue | Permettre aux moteurs de recherche de découvrir toutes les versions linguistiques |
| Suivi de l’état des traductions | Marquer comme non traduit / traduit / à mettre à jour | Éviter qu’une page allemande reste obsolète après une mise à jour |
| Contrôle du menu d’administration | Masquer et réordonner les menus de la barre latérale | Simplifier l’interface d’administration pour vos clients |
Notre parti pris
« Traduire, c’est référencer »— La traduction et le SEO ne sont pas deux étapes, mais deux résultats d’une même action. Chaque page traduite génère en une seule fois : le contenu dans la langue cible, une URL distincte, les balises hreflang et une entrée de sitemap.Ces quatre éléments doivent être produits par la même opération, sinon l’un d’eux sera forcément oublié.
Ce que nous ne faisons pas
| Ce que nous ne faisons pas | Raison |
|---|---|
| Pas de service de traduction humaine | L’extension gère la chaîne technique ; la qualité de la traduction reste du ressort du traducteur ou du client |
| Aucune modification des caractéristiques produit | Les caractéristiques sont des faits : l’extension ne les génère ni ne les modifie |
| Pas de remplacement automatique par glossaire | La cohérence terminologique repose sur le traducteur qui suit le glossaire, pas sur un remplacement automatique (qui provoque des erreurs) |
III. crater LeadPulse : la couche leads
Rupture traitée : Formulaires, tracking et attribution fonctionnent chacun de leur côté.
Trois modules clés
| 模块 | Fonctionnalités | Choix de conception |
|---|---|---|
| Conversion des formulaires | 22 types de champs, dont indicatifs téléphoniques internationaux, contacts de messagerie instantanée et devises multiples | Affichage conditionnel, colonnes de largeur variable, validation par champ |
| Conversion des boutons | Statistiques d’impressions / clics / taux de conversion + détail des clics | Suivi de tous les CTA, pas seulement des formulaires |
| Statistiques de trafic | UV/PV quotidiens, tendances sur 7/14/30 jours, top 100 des pages clés | Statistiques séparées pour les humains et les robots |
Trois choix de conception à expliquer
① Chaque conversion porte 26 données de source et d’appareil.
Canal, environnement de visite, pays/région, type d’appareil, Click ID, etc. L’objectif est clair :savoir si ce prospect vaut la peine d’être suivi, et pas seulement « recevoir une demande ».
② Identification des robots IA (plus de 50 robots, répartis en 5 catégories).
Les robots n’exécutent pas JavaScript : la collecte passe donc par des hooks côté serveur, avec des statistiques distinctes de celles des visiteurs humains. L’activité des robots IA (GPTBot, ClaudeBot, PerplexityBot, etc.) est un signal préalable au GEO— comme nous l’expliquons dans un autre article, être lu est la condition, être cité est le résultat.
③ L’attribution suit le principe de « comparabilité ».
- First Touch n’est enregistré que lorsqu’une source réelle est présente (une visite directe n’occupe pas la première position)
- Last Touch est écrasé à chaque visite, avec last_non_direct comme référence par défaut
- 12 types de Click ID stockés séparément, conservés 90 jours
- Référents du même domaine exclus
- WeChat est stocké comme dimension « environnement de visite », orthogonale au « canal »
Ce que nous ne faisons pas
| Ce que nous ne faisons pas | Raison |
|---|---|
| Pas de service de notification par e-mail | Notifications et configuration SMTP à la charge du client ou d’un tiers (pour éviter les conflits avec les systèmes existants du client) |
| Nous ne jugeons pas la valeur des leads à la place du client | Nous fournissons uniquement les données ; l’évaluation et le suivi relèvent de l’équipe métier du client |
| Pas de profilage individuel des visiteurs | Uniquement des statistiques et de l’attribution, sans profilage individuel (exigence de conformité) |
IV. CraterGuard : la couche sécurité
Rupture traitée : Les politiques de sécurité et les canaux métier entrent en conflit.
Compétence clé
| Capacité | Contenu |
|---|---|
| Renforcement de la base de sécurité | Protection de la connexion, permissions de fichiers, réduction de la surface d’exposition aux vulnérabilités courantes |
| Gestion de l’API REST | Verrouillée par défaut (renvoie 401cg_rest_locked), ouverte à la demande si nécessaire |
| Protection contre les accès anormaux | Détection des requêtes à haute fréquence, des User-Agents anormaux et des comportements de scan |
| Audit et correction de sécurité | Fournit un processus de scan et de correction, avec un appel minimaliste domaine + identifiants |
Un choix déterminant : pas de “blocage uniforme”
L’effet secondaire le plus courant des extensions de sécurité est de bloquer en même temps les crawlers d’IA et les crawlers de moteurs de recherche. Dans un contexte GEO, c’est un problème fatal :le canal GEO du site est fermé par sa propre politique de sécurité, et personne ne le sait.
Le principe de conception de CraterGuard est donc l’ouverture graduée :
| Type | Politique |
|---|---|
| Crawlers de moteurs de recherche (Googlebot / Bingbot) | Autorisés (avec vérification d’authenticité) |
| Crawlers de recherche IA | les autoriser(canal GEO) |
| Crawlers d’entraînement IA | Autorisés selon la politique |
| Scans / comportements d’attaque | Bloqués |
Répartition des rôles avec robots.txt : robots.txt est une “déclaration” (il indique aux crawlers de ne pas venir), CraterGuard est l'”exécution” (il bloque ou laisse réellement passer au niveau applicatif).Les deux doivent être cohérents— si robots.txt autorise GPTBot mais que CraterGuard le bloque au niveau applicatif, l’autorisation ne sert à rien. C’est l’une des contradictions de configuration les plus fréquemment détectées lors des audits.
V. CraterInflux : la couche d’entrée de contenu
Rupture traitée : Les actifs de contenu ne peuvent pas entrer sur le site de manière sûre et en masse.
Conception en trois étapes
| Phase | Ce que nous faisons | Pourquoi cette conception |
|---|---|---|
| ① Répétition | Analyse le paquet et fournit les chiffres (à ajouter / à mettre à jour / ignorés / en conflit) | Sans écriture en base, pour voir clairement ce qui va se passer |
| ② Aperçu | Aperçu léger (sans écriture en base, vérifie uniquement le rendu du corps) / aperçu complet (écrit un brouillon temporaire, nettoyé automatiquement après 30 minutes) | Permet à l’auteur de vraiment voir la page avant publication |
| ③ Publication | Écriture en base et génération de la liste des URL (liens bruts / Markdown / CSV copiables) | Vérifiable et diffusable après publication |
Format du paquet et idempotence
| Élément | Design |
|---|---|
| Structure du paquet | manifest.json(répertoire racine) +content/*.html+media/ |
| Format du corps | Fragment HTML (sans front-matter) |
| Clé d’idempotence | pack_id+external_id (Non déduite du titre ni du slug Bloquer ou limiter le débit |
| Catégories et étiquettes | Créées automatiquement si elles n’existent pas, ou ignorées selon la configuration |
| Médias | Les images bitmap vont dans la médiathèque ;les SVG sont intégrés par défaut (embed), sans risque d’upload |
Pourquoi la clé d’idempotence ne peut-elle pas être le titre ou le slug ? Parce qu’un titre modifié d’un mot ou un slug ajusté à la main suffit à créer des doublons par déduction, et qu’ils sont ensuite très difficiles à nettoyer.Seul un identifiant “stable côté source” utilisé comme clé garantit qu’un import répété est sans danger.
Valeurs par défaut sécurisées (non configurables)
| Par défaut | Explication |
|---|---|
| Statut brouillon par défaut | Importer ne signifie pas publier |
| Aucun exécutable dans le paquet | .php/.js/.phar rejet immédiat du paquet entier |
| Limites de taille | 2 Mo par fichier / 50 Mo pour le paquet décompressé / 500 Ko de contenu par entrée |
| Protection anti zip bomb | Lecture du répertoire central avant décompression, rejet si dépassement |
| Liste blanche de désinfection SVG | Suppression script/ attributs d’événement / références externes (via analyse DOM, pas par regex) |
VI. CraterHub : couche d’autorisation et de distribution
Au-dessus des quatre extensions métier, il existe un composant de gestion :CraterHub gère l’autorisation, la distribution et les mises à jour en ligne.
| Rôle | Emplacement de déploiement | Responsabilité |
|---|---|---|
| Maître (master) | Côté fournisseur (verrouillage par domaine) | Gérer les licences, générer les autorisations |
| Agent (agent) | Site client | Vérifier les autorisations, remonter l’état |
| Dépôt de versions | Serveur de distribution | Fournir le manifeste et les fichiers |
Les licences sont enregistrées de manière centralisée : actuellement 6 au total, correspondant au thème et à chaque extension.L’intérêt de cette conception est de faire de « que faire à l’expiration d’une licence » une question aux règles claires, plutôt que de la traiter dans l’urgence le jour venu :
| Niveau | Sémantique |
|---|---|
| A | Arrêt des ajouts uniquement (l’existant et le front restent inchangés, plus de mises à jour mais correctifs maintenus) |
| B | L’existant est conservé, les ajouts s’arrêtent |
| C | Retrait progressif (la base de sécurité est conservée à vie) |
Un principe de conception important : sans CraterHub installé, chaque extension passe en mode « autoriser / silencieux », avec un comportement identique octet pour octet à celui d’avant l’installation. Cela garantit que les extensions restent utilisables seules, sans défaillance globale en cas d’oubli d’installation du composant de gestion.
Une exception mérite d’être signalée : sans CraterHub, CraterSync passe en « dégradé lecture seule » — il peut analyser, simuler et prévisualiser, mais pas publier. En cause : l’écriture en masse sur le site est une action à fort impact, donc conservatrice par défaut.
VII. Pourquoi développer en interne plutôt qu’assembler
L’écosystème public de extensions WordPress est riche, et la plupart des fonctionnalités ont des solutions toutes faites. La raison du développement interne n’est pas « faire mieux soi-même », mais trois problèmes concrets :
| Question | Situation de l’assemblage | Traitement en interne |
|---|---|---|
| Référentiels non unifiés | Chaque extension a son propre référentiel d’attribution / SEO, les données ne peuvent pas être fusionnées | Toute la gamme partage le même référentiel de données et les mêmes définitions de champs |
| Chaîne non connectée | Il faut écrire du code de liaison entre traduction et SEO, entre formulaires et attribution | La chaîne est conçue de bout en bout dès le départ |
| Sécurité et conformité non maîtrisables | La qualité du code et le traitement des données des extensions tierces ne sont pas auditables | Code maîtrisé, auditable, modifiable, explicable au client |
Il y a aussi une raison pratique : la maintenabilité à long terme du site client. Les problèmes de l’assemblage éclatent souvent au bout de deux ans — une extension qui cesse d’être mise à jour, une mise à jour qui introduit une incompatibilité, un référentiel de données qui change et rend les données historiques incomparables.Le développement interne coûte en investissement initial, mais rapporte une maintenance prévisible sur le long terme.
Une limite claire
Cette pile technique ne remplace pas le système métier du client :
| ne remplace pas | Explication |
|---|---|
| ERP / CRM | L’extension produit des données de prospects, connectables ; elle ne prend pas en charge la gestion de la relation client |
| Plateforme d’emailing | Les notifications et les séquences d’e-mails sont gérées par une plateforme spécialisée |
| Système de design | Fournit la structure et les spécifications des composants, le visuel dépend du thème |
Positionnement : “la base technique des sites à l’international”—— consolider les quatre chaînes du site lui-même (langue, leads, sécurité, contenu) pour que les systèmes métier qui s’y connectent n’aient plus à gérer ces problématiques de fond.
FAQ — Questions fréquentes
| Situation | Combinaisons recommandées |
|---|---|
| Site à l’international monolingue, axé sur les leads | crater + crater Shield |
| Site à l’international multilingue | crater + crater + crater Shield |
| Volume de contenu important, import en masse nécessaire | Ajouter crater Hub |
| Besoin d’une autorisation centralisée et de mises à jour en ligne | Ajouter crater Core |
| Dimension | Assemblages courants | Stack technique crater |
|---|---|---|
| Référentiel de données | Défini indépendamment par chaque extension | Unifié pour toute la gamme (champs canal, environnement et source identiques) |
| Sécurité et canal IA | L’extension de sécurité bloque par défaut le trafic non humain | Autorisation par niveaux, avec un canal de recherche IA explicitement préservé |
| Écriture en masse | Écriture directe en base, on écrit puis on vérifie | Répétition → aperçu → publication, brouillon par défaut |
| Stratégie d’idempotence | Décision le plus souvent sur le slug ou le titre | pack_id+external_id, identifiant stable côté source |
| niveau | Mise en œuvre |
|---|---|
| Chargement des ressources | Ressources du front chargées à la demande, les styles de l’administration n’entrent pas dans le front |
| Requête | Tables de données indexées, requêtes statistiques mises en cache par agrégation |
| Requête externe | L’attribution des visiteurs passe par défaut par le “mode léger” (lecture des en-têtes CDN + déduction du fuseau horaire), sans requête IP à chaque visite |
Pour conclure
Le travail technique d’un site à l’international tombe vite dans le réflexe « installer une extension, configurer une fonction » — chaque installation règle un problème précis, mais l’ensemble reste fragmenté.
La vraie question à se poser d’abord est :sur mon site, quels maillons sont rompus ?
La couche linguistique est-elle rompue (traduction et SEO sont-ils connectés) ? La couche leads est-elle rompue (les demandes sont-elles traçables jusqu’à leur source) ? La couche sécurité est-elle rompue (les crawlers IA sont-ils bloqués par erreur) ? La couche contenu est-elle rompue (le contenu entre-t-il efficacement sur le site) ?
Ce n’est qu’une fois les quatre maillons rétablis que le site dispose d’une base utilisable ; et une fois cette base solide, les actions de premier niveau — SEO, GEO, publicité, contenu — produisent un effet cumulé. C’est aussi la raison d’être de cette stack technique — non pas pour ajouter des « fonctionnalités » au site, mais pour que chaque maillon ne se rompe plus en cours de route.