Kiwop avait depuis des années un site sous WordPress. Il fonctionnait, mais il ne nous représentait plus. Nous avions évolué vers des projets de développement logiciel sur mesure, des architectures headless et de l'intelligence artificielle appliquée, et notre propre site restait un monolithe PHP avec des plugins accumulés au fil des ans. C'était comme un menuisier avec la porte de chez lui cassée.
En janvier 2026, nous avons décidé de tout arrêter et de repartir de zéro. Pas un redesign sur WordPress, mais une architecture entièrement nouvelle. Cet article raconte pourquoi, comment et quels résultats nous avons obtenus.
L'ancien site : ce qui ne fonctionnait pas
Ce n'est pas que le site était cassé. Il chargeait, il avait bonne apparence, il avait du contenu. Mais il accumulait des problèmes qui s'aggravaient au fil du temps :
Performance médiocre. WordPress avec ses plugins de cache, d'optimisation d'images et ses page builders générait un HTML lourd. Les Core Web Vitals sur mobile ne passaient pas de manière consistante, et Google pénalise de plus en plus l'expérience utilisateur.
Sécurité exposée. WordPress est le CMS le plus attaqué au monde. Le panneau d'administration se trouve à /wp-admin, les endpoints de l'API sont connus, et chaque plugin est une surface d'attaque potentielle. Le maintenir à jour était un travail constant.
Rigidité. Modifier le design d'une section impliquait de toucher aux templates PHP, aux hooks, au CSS inline du page builder et de prier pour que rien d'autre ne casse. Le contenu était couplé à la présentation.
Dette technique dans le contenu. Des années de publications avaient laissé plus de 240 articles de faible qualité, près de 200 doublons WPML non traduits et des dizaines de pages thin content. Google voyait tout, et l'autorité du domaine se diluait.
La décision : architecture headless
Quand nous disons "headless", nous ne parlons pas d'une mode technologique. Nous parlons de séparer deux choses qui n'ont pas besoin d'aller ensemble : là où le contenu est géré et comment il est présenté à l'utilisateur.
Qu'est-ce que l'entreprise y gagne ?
Vitesse réelle, pas perçue. Le frontend génère du HTML pur côté serveur. Pas de PHP qui interprète à chaque requête, pas de plugins qui chargent des scripts inutiles. Le navigateur reçoit exactement ce dont il a besoin, rien de plus.
Sécurité par conception. Le CMS où l'on édite le contenu n'est pas exposé sur internet. Il n'y a pas de /wp-admin à attaquer. La surface d'attaque est réduite de manière drastique.
Flexibilité totale. L'équipe design peut modifier n'importe quel composant visuel sans toucher à la base de données du contenu. Et l'équipe éditoriale peut publier sans se soucier du rendu.
Scalabilité. Servir un site en 7 langues depuis un seul frontend avec un cache multiniveau est viable. Avec WordPress et WPML, chaque langue multipliait la complexité.
Astro + Payload CMS : pourquoi cette combinaison
Nous avons évalué plusieurs options. Next.js, Nuxt, Remix pour le frontend. Strapi, Directus, Sanity pour le CMS. Nous avons choisi Astro et Payload pour des raisons très concrètes.
Astro génère du HTML statique ou rendu côté serveur sans envoyer de JavaScript au navigateur par défaut. Si une page n'a pas besoin d'interactivité, l'utilisateur reçoit du HTML et du CSS purs. Le résultat : 0 milliseconde de Total Blocking Time. Zéro. Le thread principal du navigateur reste libre.
Payload CMS est un CMS headless sur PostgreSQL avec une API REST propre et un typage complet en TypeScript. Contrairement à Strapi ou Sanity, Payload s'auto-héberge : nos données sont dans notre base de données, pas dans un SaaS externe. Pour une agence qui gère des données clients, c'est non négociable.
La combinaison résout un problème réel : du contenu géré de manière professionnelle, présenté avec un Lighthouse de 97 et 0 ms de blocage dans le navigateur, sans dépendances externes ni vendor lock-in.
Le processus : 35 jours, 230 commits
Ce n'a pas été un projet de six mois. Du premier commit le 10 janvier 2026 à la version en production, il s'est écoulé 35 jours. 230 commits. Une équipe réduite avec des objectifs clairs.
Phase 1 : structure et composants (semaines 1-2)
Nous avons défini l'architecture modulaire : 14 composants de section réutilisables (hero, grille de services, processus par étapes, FAQs, CTAs) qui se combinent comme des blocs pour construire n'importe quelle page de service. Chaque service est défini par un fichier de configuration par langue, sans toucher au code.
La décision la plus importante a été de n'utiliser aucun framework JavaScript côté client. Pas de React, pas de Vue, pas de Svelte. Du Astro pur avec une islands architecture pour les rares composants nécessitant de l'interactivité (comme le chatbot). Le résultat : un bundle JS proche de zéro pour 95 % des pages.
Phase 2 : multi-langue (semaine 3)
Nous sommes passés de 3 langues (espagnol, anglais, catalan) à 7 (en ajoutant l'allemand, le français, le néerlandais et le portugais). Cela a impliqué :
- Un système centralisé de traductions pour toute l'interface, géré depuis un seul fichier.
- Un hreflang correct avec fallback désactivé pour éviter que Google n'indexe du contenu non traduit.
- Des URLs propres par langue sans trailing slash (1 001 URLs indexées dans Google Search Console, toutes cohérentes).
Un détail qui nous a coûté des heures : la regex de détection de langue dans les URLs. Un pattern incorrect matchait /ca à l'intérieur de /casos-de-exito, cassant les routes en catalan. Cela semble trivial, mais sur un site de plus de 2 000 pages, un bug de ce type est catastrophique pour le SEO.
Phase 3 : migration du contenu et nettoyage (semaine 4)
Nous avons migré l'intégralité du blog de WordPress vers Payload CMS. Mais il ne s'agissait pas d'un simple transfert : nous en avons profité pour réaliser un audit impitoyable du contenu.
- 243 articles toxiques supprimés (contenu de faible qualité, non pertinent ou obsolète)
- 199 doublons WPML dépubliés (versions en anglais et catalan qui étaient des copies non traduites de l'espagnol)
- 31 pages thin content supprimées avec des codes 410 dans nginx
- 3 paires d'articles dupliqués consolidés avec des redirections 301
- 885 titres raccourcis à moins de 60 caractères
- 333 meta descriptions ajustées à moins de 160 caractères
Ce nettoyage était délibéré. La Helpful Content Update de Google pénalise au niveau du site entier. Avoir 200 pages de mauvaise qualité tire vers le bas les 700 bonnes.
Phase 4 : SEO et performance (semaine 5)
Audit de la hiérarchie des headings sur les 2 114 pages du site : 0 erreur, 0 avertissement. Chaque page possède une structure sémantique correcte, du H1 au H4.
Nous avons mis en place un système de cache à 4 couches (Payload CMS, Redis SWR, nginx SSR et Cloudflare CDN) avec purge ordonnée. L'ordre compte : si vous purgez Cloudflare mais que Payload a encore son ancien cache, nginx re-cache immédiatement des données obsolètes. Cela semble évident une fois écrit, mais nous l'avons appris en déboguant pourquoi les changements n'apparaissaient pas en production.
Le rôle de l'IA
Il serait malhonnête de ne pas le mentionner : nous avons utilisé l'IA comme outil de développement tout au long du processus. Pas pour générer du code à l'aveugle, mais comme un partenaire de programmation qui nous a aidés à auditer plus de 2 000 pages, détecter des incohérences SEO à grande échelle et automatiser des tâches répétitives comme la normalisation des titres en 7 langues.
L'IA n'a pas conçu l'architecture ni pris de décisions métier. Mais elle a considérablement accéléré l'exécution, en particulier lors des phases d'audit et de nettoyage de contenu.
Résultats : les chiffres
Performance (Lighthouse)
Les scores Lighthouse sur le site en production :
- Performance : 97/100 (mobile et desktop)
- Accessibilité : 100/100
- Bonnes pratiques : 100/100
- SEO : 100/100
Core Web Vitals
- LCP (Largest Contentful Paint) : 2,2 secondes — validé (seuil Google : < 2,5 s)
- TBT (Total Blocking Time) : 0 milliseconde — validé (seuil : < 200 ms)
- CLS (Cumulative Layout Shift) : 0 — validé (seuil : < 0,1)
Un TBT de 0 milliseconde signifie que le navigateur ne se bloque à aucun moment. Un CLS de 0 signifie que rien ne bouge pendant le chargement de la page. Ces chiffres ne sont pas théoriques : ce sont des mesures réelles sur le site en production.
Impact sur les moteurs de recherche
Le nettoyage du contenu a produit un effet attendu : moins d'impressions totales (nous avons supprimé des centaines de pages), mais une meilleure qualité sur ce qui reste.
- CTR : +27,8 % (de 0,17 % à 0,22 %)
- Position moyenne : +9,3 positions (de 50,6 à 41,3)
- Position moyenne sur mobile : +13,6 positions (de 36,9 à 23,3)
Moins de volume, plus de qualité. Les pages qui restent se positionnent mieux et convertissent davantage. C'est la bonne stratégie quand la priorité est d'attirer des clients, pas d'accumuler des visites vides.
Échelle
- 2 114 pages auditées et fonctionnelles
- 7 langues depuis une seule base de code
- ~1 600 articles de blog publiés (712 ES, 406 EN, 407 CA, 33 DE/FR/NL, 10 PT)
- Déploiements sans interruption avec rollback automatique
Ce que cela signifie pour nos clients
Ce site n'est pas seulement notre vitrine. C'est la démonstration concrète de ce que nous faisons.
La même architecture headless qui fait tourner kiwop.com — séparation du frontend et du CMS, cache multiniveau, multi-langue natif, performance PageSpeed 97+ — est exactement ce que nous déployons dans les projets de nos clients.
Si votre site actuel :
- Met plus de 3 secondes à charger sur mobile
- Dépend de WordPress avec 20 plugins pour fonctionner
- Présente des problèmes de sécurité récurrents
- Ne s'adapte pas bien à plusieurs langues ou marchés
- Accumule de la dette technique qui freine chaque évolution
Il existe une alternative éprouvée. Pas théorique : vous êtes en train de la voir en ce moment même.
