WattDevis.fr : de Mozilla D à A+

En bref — situation, intervention, résultat

Le détail, section par section, ci-dessous — du contexte client (section 1) aux questions fréquentes (section 10).

1. Le client

WattDevis.fr est une plateforme française de mise en relation entre particuliers et installateurs certifiés RGE pour deux types de projets énergétiques : installation de panneaux solaires photovoltaïques et installation de bornes de recharge pour véhicules électriques. Le modèle est celui de la génération de leads B2C avec scoring 4-tiers (hot, warm, cool, cold) et distribution aux installateurs partenaires selon leur zone d'intervention.

Le projet est piloté en autonomie par un fondateur unique. Production éditoriale interne, pas d'équipe marketing externe.

2. L'objectif initial

Trois besoins simultanés qui définissent l'architecture cible :

1. Performance maximale. Atteindre Lighthouse 100/100 sur les quatre métriques mobiles (Performance, Accessibility, Best Practices, SEO) sans compromettre le contenu éditorial.
2. Volume éditorial à scale. Capacité à publier et maintenir 600+ articles techniques (guides régionaux, comparatifs, glossaire, fiches produit) sans dégradation de performance.
3. Sécurité prête NIS2/RGPD. Score Mozilla Observatory A+ avec headers de sécurité durcis (HSTS preload, CSP stricte, X-Frame-Options, Referrer-Policy, Permissions-Policy).

C'est la conjonction des trois besoins simultanés qui a justifié le choix architectural d'une migration vers Cloudflare HTML statique. Pour un client n'ayant que le besoin n°3 (sécurité), une approche plus légère reste pertinente — voir section 5.

3. État initial — WordPress sur Hostinger

Sécurité headers (Mozilla Observatory)

Score Mozilla Observatory : 30/100, grade D, 6/10 tests passés. Cette configuration est le point de départ par défaut d'une installation WordPress non durcie — environ 70 % des sites WordPress en production ne dépassent pas ce score sans intervention spécifique.

Performance Lighthouse (mobile)

Le saut de 60 à 90 sur Performance a été obtenu par optimisation cache LiteSpeed, compression Brotli, lazy loading et conversion images en WebP. Cette optimisation a néanmoins exigé un compromis sur le contenu — certaines pages restaient incomplètes pour préserver le score, ce qui n'était pas un état acceptable pour la mise en production réelle.

4. Le moment-clé : la décision de migrer

1. Plafond performance contenu. Lighthouse 100 sur mobile + 600+ articles complets simultanément n'était pas atteignable sur Hostinger sans investissement disproportionné en optimisation continue.
2. Plafond sécurité plugin-dépendant. Atteindre Mozilla A+ via plugins WordPress entrait en conflit avec le cache LiteSpeed et créait un coût de maintenance récurrent (chaque update plugin pouvant casser la CSP).
3. Plafond évolutivité. La conformité NIS2 (entrée en vigueur octobre 2024) imposait à terme des audits de sécurité réguliers. Maintenir le durcissement WordPress dans le temps demandait un budget récurrent que le projet ne pouvait pas supporter en autonomie.
4. Productivité éditoriale via assistants IA. Je voulais pouvoir demander à Claude — ou Cursor connecté à mon dépôt Git — de produire des articles, modifier des fiches ville, ajuster des pages techniques, automatiquement et en quelques minutes. Une architecture HTML statique sur Git est compatible nativement avec ce flux IA-first ; un WordPress avec Gutenberg, base de données et plugins demande une intermédiation manuelle systématique. Ce critère a pesé autant que les trois plafonds techniques précédents dans la décision finale.
5. Empreinte écologique mesurable (motif secondaire). Le WordPress en place sur Hostinger transférait typiquement 2 à 5 MB par chargement de page (cœur PHP, plugins, images non-optimisées, scripts tiers). La stack HTML statique post-migration livre la même page accueil en 300 KB à 1 MB selon contenu, soit un ratio 5 à 10× plus léger. À volume équivalent de visites, cela représente autant de bande passante économisée et d'émissions CO2 évitées par visite. Méthodologie de référence : websitecarbon.com. Ce motif n'a pas été déterminant dans la décision, mais s'aligne avec la sobriété technique recherchée.

L'arbitrage a été pris sur la base de cette équation : le coût en temps de la migration (5 jours) était inférieur au coût cumulé de maintenance du WordPress durci sur 12 mois, et la migration permettait de débloquer simultanément les trois contraintes.

5. Quand migrer vs quand sécuriser sur place

Cette section est cruciale pour comprendre la portée du présent case study. La migration WattDevis n'est pas une démonstration que WordPress est un mauvais choix. C'est une démonstration qu'une stack adaptée doit correspondre aux besoins simultanés du projet.

Voici la matrice de décision que HELIORANK applique systématiquement en discovery call :

6. Timeline réelle de la mission WattDevis

7. Architecture cible

Stack retenue

• Cloudflare Pages : hébergement des 680 fichiers HTML statiques pré-générés (gratuit jusqu'à 100k builds/mois, latence edge sub-50ms en France)
• 2 Cloudflare Workers serverless :
  • lead-intake (~1000 lignes ESM modulaires) — POST /api/lead/submit, validation, anti-spam multi-couches, lead scoring 4-tiers, persistance KV, notification Resend
  • tracking (~200 lignes) — POST /api/track/event pour funnel analytics, agrégation 3 niveaux en KV (par jour, par variant A/B, par slug)
• 2 KV namespaces : LEADS_KV (TTL 90 jours) et FUNNEL_KV (agrégation)
• Cloudflare Resend integration : email transactionnel pour notifications leads hot/warm

Choix techniques structurants

• Aucune dépendance npm runtime côté backend Worker (code 100 % auditable)
• Pipeline de build local (60-90 secondes pour 680 pages) avec génération images AVIF/WebP/JPG en 3 tailles (600w/1200w/1920w)
• Cache busting déterministe via hash de contenu dans les noms de fichiers
• Schema.org propre sur chaque page (Article, FAQPage, BreadcrumbList)
• CSP stricte sans 'unsafe-inline' sur script-src, externalisation des inline JS, hashes pour les éléments restants

8. Résultats mesurables (vérifiables publiquement)

Mozilla Observatory

Vérifiable en temps réel : Mozilla Observatory wattdevis.fr

Lighthouse mobile

Vérifiable en temps réel : PageSpeed Insights wattdevis.fr

Indexation Google Search Console (la métrique la plus impressionnante)

Cumul sur 23 jours (14 avril → 6 mai 2026) : 5 718 impressions, 40 clics, position moyenne 7-9 en amélioration constante. À J+23, le site sert 608 impressions journalières — soit +56 % par rapport au pic de J+17. La courbe reste ascendante : pas un plateau, une montée continue après stabilisation de l'architecture.

Pourquoi cette vélocité d'indexation

Cette vélocité — 0 à 608 impressions journalières en 23 jours sur un domaine sans backlinks — n'est pas due à l'autorité du domaine (il n'en a pas), à des backlinks (il n'y en a pas), ou à un budget Google Ads (zéro). Elle est imputable directement à trois facteurs techniques cumulés :

• Architecture statique sans goulet serveur — Googlebot crawle des fichiers HTML servis directement par l'edge Cloudflare, sans hit de cache PHP, sans timeout MySQL. Aucune limite de taux serveur, même lors des bursts d'exploration intense (376 requêtes en une seule journée le 16 avril 2026).
• Données structurées Schema.org propres et validées sur chaque page (Article, FAQPage, BreadcrumbList).
• Volume éditorial cohérent (680 pages) avec maillage interne dense — Google identifie une autorité topique sur le solaire/borne dès la première vague de crawl.

Crawl health post-migration (15 avril → 6 mai 2026)

Données extraites du rapport Crawl Stats de Google Search Console sur 22 jours d'observation post-migration :

• 3 342 demandes d'exploration par Googlebot — Google crawle activement le site (~152 requêtes/jour de moyenne).
• 93,74 % de réponses bien servies : 87,58 % en 200 OK + 6,16 % en redirections 301 permanentes (anciennes URLs WordPress redirigées vers leurs équivalents migrés).
• 4,85 % de 404 sur d'anciennes URLs WordPress dépubliées — point d'amélioration identifié, mappage de redirections 301 à enrichir dans une prochaine itération pour faire passer le ratio sain au-dessus de 98 %.
• 0,42 % d'erreurs réelles (5XX serveur + DNS + autres 4XX) — seuil très bas indiquant la stabilité de l'infrastructure Cloudflare Pages.
• 62,42 % du crawl par Googlebot Smartphone — l'indexation se fait en mobile-first, cohérent avec la priorisation Lighthouse mobile.
• « Aucun problème » signalé par Google Search Console sur la santé globale du crawl.

Stabilisation du TTFB serveur (avril → mai 2026)

Le temps de réponse serveur mesuré directement par Google a évolué d'une phase initiale élevée (469 à 970 ms en mi-avril, le temps que les caches edge Cloudflare se stabilisent sur les pop régionaux) vers un régime stable à 120-128 ms en mai 2026. Soit 6 à 12 fois plus rapide qu'un WordPress moyen non optimisé (TTFB typique 800-1 500 ms). Cette performance edge constitue désormais le socle technique pour la suite de la croissance du site, indépendamment de la phase initiale d'indexation.

Visibilité AI multi-moteurs (écosystème Bing / Copilot)

Indépendamment de l'indexation Google, le site est suivi par Bing Webmaster Tools dans son onglet "AI Performance Overview" qui agrège les citations à travers l'écosystème AI alimenté par l'index Bing : Bing Copilot (Microsoft), ChatGPT search (qui utilise Bing comme backend), Perplexity (combinaison Brave + Bing).

Cumul sur 14 jours : 29 citations IA, 5 jours actifs sur 14, pic à 10 citations/jour. Couverture multi-engines simultanée : Copilot Microsoft, ChatGPT, Perplexity.

Pourquoi ce signal compte indépendamment de Google : Google Aperçu IA et le Mode IA Google utilisent leurs propres modèles et leur propre index. Bing alimente un écosystème distinct (Copilot, ChatGPT, Perplexity). Atteindre la visibilité sur ces deux pôles algorithmiques indépendants démontre que la méthodologie technique (schema.org propre, llms.txt structuré, vitesse de crawl, autorité topique cohérente) produit des signaux reconnus par tous les moteurs IA majeurs — pas par un seul moteur, ni par chance.

Citation directe ChatGPT (session anonyme, 5 mai 2026). Sur la requête commerciale « comparateur de devis photovoltaïque en France », ChatGPT cite spontanément WattDevis aux côtés des comparateurs établis du marché, avec un descriptif valorisant la transparence éditoriale (« 3 devis rapides sans démarchage agressif, met en avant la transparence aides incluses »). Pour un domaine neuf sans backlinks payants, cette présence dans les recommandations natives de ChatGPT constitue une preuve d'autorité topique organique sur la verticale énergies renouvelables.

Note : les réponses des moteurs IA conversationnels sont non-déterministes. La citation observée est indicative à date et peut varier au gré des mises à jour de modèle et d'index.

9. Ce que ce case study NE prétend PAS

Pour éviter toute lecture exagérée, voici ce qui n'est pas démontré par WattDevis :

• Pas une critique de WordPress. WordPress reste un excellent CMS pour des projets avec des besoins éditoriaux fréquents par équipe non-technique. Le Pack Mozilla A+ WordPress (3 500 €) prouve qu'on peut atteindre la sécurité maximale sans quitter WordPress.
• Pas une obligation de migrer pour avoir A+. Mozilla A+ est atteignable sur WordPress via Worker Cloudflare proxy (Pack 3 500 €) ou Worker hardening avancé (Pack Pro 4 500 €).
• Pas une promesse de 608 impressions/jour. Les volumes d'indexation dépendent de la qualité éditoriale et du marché ciblé. La vélocité observée chez WattDevis est exceptionnelle mais reproductible avec une discipline éditoriale comparable.
• Pas une garantie de position 1. Un site Lighthouse 100 + Mozilla A+ optimise l'INDEXATION (vitesse de crawl + qualité technique). Les positions finales dépendent ensuite du contenu, de la concurrence, et de signaux que ce case study ne couvre pas.

10. Questions fréquentes

Faut-il migrer de WordPress pour obtenir un score Mozilla Observatory A+ ?

Non. Mozilla A+ est atteignable sans quitter WordPress, via un Worker Cloudflare placé en proxy devant le site existant — aucun changement d'hébergement, aucun plugin à installer. La migration vers HTML statique ne se justifie que lorsque trois besoins se cumulent : sécurité maximale, performance Lighthouse 100 et volume éditorial à maintenir dans la durée. Pour un besoin de sécurité isolé, le pack proxy reste l'option la plus économique.

Pourquoi l'indexation Google a-t-elle été aussi rapide sur un domaine neuf ?

La vélocité — 0 à 608 impressions journalières en 23 jours — n'est due ni à l'autorité du domaine, ni à des backlinks, ni à un budget publicitaire, tous absents. Elle tient à trois facteurs techniques cumulés : une architecture statique servie directement par l'edge Cloudflare, sans goulet serveur ni timeout, que Googlebot peut crawler sans limite de taux ; des données structurées Schema.org propres et validées sur chaque page ; et un volume éditorial cohérent avec un maillage interne dense, qui signale une autorité topique dès la première vague de crawl.

Quand vaut-il mieux migrer vers Cloudflare HTML plutôt que sécuriser le site en place ?

La migration coûte structurellement plus cher en intervention initiale, mais devient rentable au-delà de 6 à 12 mois pour les projets qui cumulent trois besoins simultanés : sécurité, performance et édition de contenu à grande échelle. Pour un projet avec un ou deux besoins isolés, un pack Mozilla A+ ou Performance Engineering appliqué à la stack existante est systématiquement plus économique et tout aussi durable.

Combien de temps prend une migration de ce type ?

La migration WattDevis a demandé 5 jours intensifs pour générer les 680 fichiers HTML, créer les deux Workers Cloudflare et configurer sécurité, sitemap et schema.org. Une migration complète avec mise en place d'un CMS git-based pour une édition par une équipe non technique s'étale plutôt sur 4 à 8 semaines.