Pourquoi Penasihat Hosting est passé de WordPress à Next.js 16

Ce projet a débuté en novembre 2025 et s’est achevé en janvier 2026. En termes de calendrier, deux mois pour une migration comme celle-ci est relativement rapide, d’autant plus que je travaillais dessus tout en m’occupant des projets clients chez Harun Studio.

La partie intéressante est la suivante : la migration n’a pas eu lieu car WordPress a échoué.

Avant le déménagement, PenasihatHosting.com semblait déjà convaincant sur WordPress. Du référencement, de la gestion de contenu, de la stabilité à la personnalisation légère avec une pile comme GeneratePress et GenerateBlocks, c’était toujours une configuration très réalisable. J’utilisais également WordPress presque tous les jours depuis environ 10 ans, il n’y avait donc aucun problème fondamental qui me faisait sentir que je devais « échapper » à WordPress.

Le tournant est venu de l’orientation produit.

Penasihat Hosting ne voulait plus se contenter d’être un blog d’évaluation régulier. L’orientation a été modifiée vers un écosystème d’hébergement plus large : critiques, répertoires d’hébergement, contenu wiki, articles de blog, guides et pages d’outils tels qu’un calculateur de disponibilité, un outil de recherche DNS, un vérificateur SSL, etc. À ce stade, je pensais que les besoins à long terme pour les 5 à 10 prochaines années seraient beaucoup plus faciles à gérer avec une pile plus flexible.

Bref résumé et points à retenir

Si votre site Web WordPress évolue au-delà d’un site de contenu standard et commence à ressembler davantage à une plate-forme de produits, commencez par une consultation gratuite afin que la pile que vous choisissez corresponde réellement aux 5 à 10 prochaines années.

Le point de départ : WordPress était en fait déjà bon

Je tiens d’abord à préciser cela, car les histoires de migration sont souvent simplistes à l’extrême, comme si s’éloigner de WordPress signifiait automatiquement que WordPress était mauvais. Ce n’est pas vrai.

La pile WordPress précédente chez Penasihat Hosting était déjà assez saine :

• GeneratePress comme thème.
• GenerateBlocks en tant que constructeur.
• ACF pour certaines données structurées.
• Extraits personnalisés pour les éléments qu’il était plus approprié de gérer dans le code.
• Quelques plugins de support tels que NinjaFirewall, AntiSpam Bee et d’autres utilitaires en quantité raisonnable.

Le problème n’était donc pas « WordPress est lent », « WordPress est mauvais » ou « WordPress n’est pas fiable ».

Le vrai problème était le suivant : le produit en cours de construction s’éloignait de plus en plus de la forme d’un site Web typique.

Une fois que la cible devient une plate-forme d’hébergement avec des répertoires de fournisseurs, des catégories, des centres de données, des promotions, des plans, du contenu wiki, du contenu de blog et des pages d’outils interactifs, la logique métier commence à devenir beaucoup plus complexe. À ce stade, j’ai senti que forcer tout à continuer à croître dans WordPress augmenterait également les frais généraux à long terme : plus de travail manuel, plus de compromis architecturaux et plus de domaines qui donneraient l’impression que “ça marche, mais ça ne semble pas naturel”.

Pourquoi ai-je choisi Next.js 16 ?

Après avoir envisagé plusieurs options, j’ai choisi Next.js 16.

Pas parce que je suis un développeur inconditionnel de Next.js. En fait, l’inverse est plus proche de la vérité : j’apprends encore et je n’ai pas passé autant d’années à vivre à plein temps dans l’écosystème React/Next. Mais pour les besoins de Penasihat Hosting, Next.js semblait être le meilleur compromis entre flexibilité, productivité et avenir à long terme du produit.

Les principales raisons :

1. Une pile pour le frontend et le backend Je pourrais créer l’interface publique, les itinéraires dynamiques, les actions du serveur, le CMS d’administration et une logique plus personnalisée au sein d’un seul écosystème.

2. Une solution plus naturelle pour un hybride de logique de contenu et d’application Penasihat Hosting n’est pas qu’un blog. Il comporte des zones très riches en contenu, mais il comporte également des parties qui se comportent davantage comme une couche d’application : répertoires, filtrage, comparaisons et divers outils utilitaires.

3. Une meilleure base pour les futures pages d’outils Pour des fonctionnalités telles qu’un calculateur de disponibilité, une recherche DNS, un vérificateur SSL, un générateur .htaccess, un générateur robots.txt et d’autres outils, Next.js semble plus propre et plus flexible que de tout forcer dans un plugin WordPress et un modèle de création de pages.

4. Une bien meilleure adaptation aux flux de travail assistés par l’IA Avec une pile moderne comme Next.js, TypeScript et des composants modulaires, le développement avec l’IA semble beaucoup plus productif. De nombreuses tâches manuelles sont réduites par rapport à l’ancien flux de travail consistant à jongler avec PHP, les extraits de code, les hooks, le CSS et le comportement des plugins.

Donc, si la question est : « Next.js est-il réellement mieux adapté que WordPress pour un cas comme celui-ci ?

Ma réponse est : oui, pour un projet comme Penasihat Hosting, c’est le cas.

Si vous créez uniquement un profil d’entreprise, un blog régulier ou un site Web au contenu simple, WordPress reste un choix très rationnel. Mais pour une plateforme évoluant vers un écosystème de produits avec de nombreuses relations de données personnalisées et des outils interactifs, Next.js semble plus naturel.

J’ai appris en construisant, pas après être devenu un « expert »

Je ne suis pas un développeur Next.js qui a passé des années à vivre entièrement dans cette pile. Mais je ne partais pas non plus de zéro.

Avant ce projet, j’avais déjà construit plusieurs choses avec Next.js, notamment :

• L’application interne de Harun Studio,
• ImageTools.pro, que j’ai construit avec Next.js et l’aide d’IA,
• Pixstack.app, que j’ai ensuite vendu sur Flippa.

Cela signifie que je n’étais pas encore un vétéran, mais j’avais suffisamment de bases pour savoir que ce projet était réaliste à construire tout en apprenant plus en profondeur.

Et honnêtement, c’est l’une des raisons pour lesquelles le moment de cette migration semblait opportun : l’IA pour le codage est devenue beaucoup plus fiable. Je pourrais me concentrer sur l’architecture, la validation, le raffinement et le contrôle qualité, tandis qu’une grande partie du travail répétitif pourrait être accélérée par des outils tels que Cursor, Codex et des flux de travail plus matures, axés sur l’invite d’abord.

L’ancienne pile contre la nouvelle pile

La pile WordPress précédente

Comme la plupart de mes projets WordPress, l’ancienne pile d’hébergement Penasihat a été construite avec une approche légère :

• GénérerPresse
• Générer des blocs
• ACF
• extraits personnalisés
• un ensemble raisonnable de plugins de sécurité et d’utilitaires

C’était toujours une bonne pile WordPress. Encore une fois, le véritable problème n’était pas la qualité de l’ancienne pile, mais le fait que le produit avait dépassé la forme d’un site WordPress typique.

La nouvelle pile Next.js

La nouvelle architecture est construite autour de ces composants principaux :

• Next.js 16 avec App Router
• Réagissez 19
• TypeScript
• Tailwind CSS 4
• Prisma ORM
• PostgreSQL
• PM2 pour exécuter l’application sur un VPS
• Cloudflare R2 pour le stockage et la sauvegarde d’images
• Upstash pour la limitation du débit et certaines charges de travail liées aux sessions
• Renvoyer pour le formulaire de contact et la newsletter
• Umami Analytics pour l’analyse

J’ai choisi de gérer ce site Web sur un VPS de Singapour, qui est très proche du public principal en Indonésie. Pour moi, c’est une combinaison confortable : je garde toujours le contrôle du serveur, les performances semblent rapides pour le marché indonésien et je ne dépends pas de trop de tiers pour l’hébergement principal et la base de données.

Le CMS interne : pourquoi ai-je créé le mien ?

L’une des décisions les plus audacieuses de ce projet, et que je suis très heureux d’avoir prise, a été de créer un CMS interne.

Techniquement, je comprends pourquoi cela ressemble à plus de travail. WordPress vous offre déjà Gutenberg, un éditeur visuel, un énorme écosystème de plugins et un flux de publication beaucoup plus mature. Mais pour moi personnellement, un éditeur très convivial pour les débutants n’était pas indispensable, car je suis développeur et je suis déjà à l’aise avec MDX.

Le but n’était donc pas de construire un CMS généraliste comme WordPress. Je voulais seulement créer un CMS adapté à mon propre flux de travail.

La structure interne que j’ai construite comprend :

• un tableau de bord d’administration,
• gestion des articles de blog,
• gestion des catégories,
• gestion des prestataires,
• des insignes,
• des widgets,
• et des formulaires structurés pour l’hébergement des données d’annuaire.

Pour l’édition de contenu, j’ai utilisé un éditeur MDX basé sur CodeMirror, doté d’une barre d’outils pour insérer les éléments fréquemment utilisés. Ce n’est pas aussi convivial que Gutenberg pour les débutants, mais il correspond beaucoup mieux à mon flux de travail.

D’un autre côté, les catégories ne sont plus traitées comme une taxonomie superficielle. J’ai construit une zone de gestion des catégories plus sérieuse car les catégories de ce projet jouent un rôle important dans la structure de l’annuaire et dans la navigation plus large des produits.

Les principaux avantages :

• Je n’ai créé que les fonctionnalités d’administration vraiment nécessaires,
• le workflow de publication est devenu plus ciblé,
• les données de contenu et les données d’annuaire vivent dans un seul système,
• et je n’ai pas à supporter le poids d’un gros CMS pour des besoins finalement très spécifiques.

Du blog d’évaluation à un écosystème d’hébergement plus large

C’est probablement la raison commerciale la plus importante derrière la migration.

Auparavant, Penasihat Hosting était fortement associé à une page d’accueil qui fonctionnait bien pour des mots clés tels que “meilleur hébergement” et des termes associés. Après le pivot, la page d’accueil n’était plus positionnée comme la seule page de destination pour ce mot-clé.

La page d’accueil agit désormais davantage comme une passerelle vers l’écosystème plus large, qui comprend :

• héberger des répertoires,
• des avis,
• des guides,
• du contenu wiki,
• hébergement de promotions,
• informations sur le centre de données,
• et des pages outils.

Il s’agit d’un changement majeur dans l’architecture de l’information, et il a naturellement des conséquences.

La page qui servait auparavant de centre pour le mot-clé « meilleur hébergement » a été déplacée vers /hosting-terbaik. Pour le moment, cette page se situe toujours autour du rang n°11, et je considère qu’il s’agit d’une phase de transition normale. Mon objectif actuel est de renforcer les liens internes et d’aider Google à comprendre que l’intention du mot clé n’est plus liée à la page d’accueil, mais à la page /hosting-terbaik.

Pour moi, il est important de l’expliquer honnêtement : s’il y a une baisse du trafic, ce n’est pas uniquement à cause de la migration technique, mais aussi à cause d’un changement de stratégie produit et d’architecture de mots clés.

Migration de contenu, redirections et protection SEO

Dans une migration comme celle-ci, la partie la plus sensible n’est généralement pas le choix de la conception ou de la pile, mais la continuité SEO.

De ce fait, j’ai gardé plusieurs principes :

1. Si une ancienne URL est toujours pertinente, conservez-la.
2. Si une URL change, ajoutez une redirection 301.
3. Gardez les URL canoniques cohérentes sans barres obliques finales.
4. Gérez correctement le plan du site et les robots.
5. Gérez sérieusement les métadonnées de chaque page.
6. Améliorez les liens internes pour refléter la nouvelle intention du mot clé après le pivot.

Pour les redirections, j’ai choisi de les placer directement dans Nginx, pas dans Cloudflare Rules ou dans la configuration de redirection Next.js. Pour moi, c’est plus rapide, plus flexible et plus facile à gérer directement sur le VPS.

Du point de vue de la mise en œuvre, j’ai migré l’ancien contenu avec un mélange d’assistance IA, de saisie manuelle via le CMS et d’affinement progressif de la base de données. Il ne s’agissait pas d’une migration « en un clic et terminée ». Il s’agissait plutôt d’un processus de conservation tout en s’assurant que le résultat final restait propre.

Optimisations techniques que j’ai appliquées

Même si Next.js est déjà rapide par défaut, je ne voulais pas me fier uniquement aux valeurs par défaut du framework.

Certaines des optimisations que j’ai appliquées :

1. Rendu statique d’abord et gourmand en cache

Les pages clés ont été construites avec une approche fortement orientée cache. De nombreuses données stables sont stockées avec des profils de cache de longue durée et invalidées via des balises lorsque des modifications proviennent de la zone d’administration. Cela permet d’alléger les pages marketing tout en permettant des mises à jour contrôlées pour les données qui changent.

2. Composants de prérendu partiel et de cache

J’ai activé les composants de cache afin que les pages puissent bénéficier d’un rendu plus efficace. Pour les blocs en grande partie statiques, cela permet de maintenir des réponses rapides sans que chaque requête se comporte comme une page entièrement dynamique.

3. Gestion des images plus sérieuse

Les images distantes sont limitées aux domaines que je contrôle, tout en utilisant l’optimisation d’image Next.js avec des formats modernes comme AVIF et WebP. Étant donné que l’application fonctionne sur mon propre VPS, je peux maintenir l’optimisation complète des images active sans trop me soucier des coûts de transformation tiers.

4. Redirige Nginx pour les performances et le contrôle

Au lieu d’empiler les redirections à l’intérieur de la couche application, je les ai gérées via Nginx. Pour une migration avec un bon nombre de redirections, cela semblait plus rapide et plus propre.

5. En-têtes de sécurité

J’ai également appliqué des en-têtes de sécurité au niveau de l’application pour des éléments tels que la protection contre le détournement de clics, la prévention du reniflage MIME, la politique de référence, le HSTS, la politique d’autorisations et un CSP plus strict.

6. Limitation de débit avec Upstash

J’utilise Upstash pour limiter le débit dans les domaines les plus exposés aux abus : le formulaire de contact, la newsletter, la connexion administrateur, la recherche, les points de terminaison de l’API et certains outils.

7. Analyses légères et gestion des formulaires

J’utilise Umami pour l’analyse, tandis que le formulaire de contact et la newsletter utilisent Resend. Ce choix permet un développement plus rapide, plus propre et évite de donner l’impression que le système est gonflé.

Résultats mesurables

Pour moi personnellement, le meilleur résultat de cette migration n’est pas seulement un score PageSpeed élevé, mais le fait que le site Web semble désormais rapide et dépasse les Core Web Vitals tout en disposant d’une base beaucoup plus prête à se développer.

Les résultats PageSpeed Insights que j’ai enregistrés :

• Mobile : Performances 97 | Accessibilité 100 | Meilleures pratiques 100 | Référencement 100
• Ordinateur de bureau : Performances 100 | Accessibilité 97 | Meilleures pratiques 100 | Référencement 100

Le plus important :

• Évaluation Core Web Vitals : réussi

Étant donné que le serveur est à Singapour et que les principaux visiteurs se trouvent en Indonésie, l’expérience du monde réel semble également très rapide. Je ne suis donc pas obsédé par l’idée de toujours voir un 100 parfait sur chaque combinaison d’appareils. Tant que les Core Web Vitals passent, les pages semblent rapides et l’expérience utilisateur est cohérente, cela compte bien plus.

Workflow de développement et de maintenance

Mon flux de travail de développement semble désormais beaucoup plus propre :

• développement sur localhost,
• pousser vers GitHub,
• puis déployez sur le VPS à l’aide d’un script de déploiement que j’ai préparé.

Côté maintenance, le travail véritablement courant se résume essentiellement à :

• surveiller la disponibilité du serveur,
• mise à jour lorsque des besoins de développement se font sentir,
• et un suivi opérationnel de base.

Ceci est différent du modèle de maintenance WordPress, qui est presque toujours accompagné d’une liste de contrôle des mises à jour principales, des thèmes, des plugins et de la compatibilité.

Du point de vue des coûts, il est également relativement efficace. Il n’y a pas eu d’augmentation spectaculaire des coûts d’infrastructure en raison de cette migration. Les principaux ajouts concernent davantage les outils de travail comme les éditeurs mensuels d’IA ou les assistants de codage, alors que je contrôle toujours moi-même l’infrastructure de base.

Impact commercial et opérationnel

Après la migration, les effets les plus importants que j’ai ressentis étaient :

• la publication de contenu est devenue plus rapide pour mon flux de travail,
• la maintenance est devenue plus légère,
• la structure du produit est devenue beaucoup plus prête à croître,
• la base des répertoires et des outils est devenue beaucoup plus raisonnable,
• et je me sens beaucoup plus à l’aise pour créer de nouvelles fonctionnalités sans constamment penser aux compromis liés aux plugins.

Pour le SEO, je n’ai pas constaté de dégâts dramatiques causés par la migration technique elle-même. Le mappage d’URL et les redirections 301 ont contribué à maintenir la transition raisonnable.

S’il y a une baisse du trafic, la cause principale est en fait le pivot de la stratégie de contenu et de la structure des mots clés. La page d’accueil, qui était autrefois forte pour le mot-clé « meilleur hébergement », fonctionne désormais comme une passerelle d’écosystème, tandis que l’intention de ce mot-clé a été déplacée vers /hosting-terbaik.

Je vois donc ce déclin davantage comme un effet de repositionnement, et non comme le signe d’un échec de la migration.

Leçons de ce projet

1. Ne migrez pas simplement parce que l’ancienne pile semble moins « cool ». La migration devrait avoir lieu car les exigences du produit ont véritablement changé.

2. WordPress est toujours très puissant pour de nombreux cas d’utilisation. Mais pour une plateforme hybride combinant contenu, répertoires, outils et logique d’administration assez personnalisée, Next.js peut devenir un choix plus naturel.

3. Un CMS personnalisé n’a pas besoin d’être sophistiqué. Parfois, ce dont vous avez besoin n’est pas d’un CMS universel, mais du CMS adapté à votre propre flux de travail.

4. L’IA change l’économie du développement. Des projets comme celui-ci sont désormais beaucoup plus réalistes à exécuter, car l’IA peut supprimer une grande partie du travail manuel qui prenait auparavant du temps et de l’énergie.

5. La migration SEO ne consiste pas seulement à copier du contenu. Ce qui compte le plus, c’est de préserver l’intention, le mappage d’URL, les liens internes, les redirections et la structure de l’information d’une manière que les moteurs de recherche peuvent encore comprendre.

Est-ce que je regrette d’avoir déplacé l’hébergement Penasihat vers Next.js ?

Pas du tout.

En fait, après l’avoir terminé, je suis encore plus certain que c’était la bonne décision quant à la prochaine direction de Penasihat Hosting. Je me sens plus productif, il est plus facile d’intégrer l’IA dans mon flux de travail quotidien, j’ai plus de liberté pour créer des fonctionnalités personnalisées et je me sens plus calme car les fondations sont désormais bien mieux alignées avec la complexité du produit que je construis.

Si Penasihat Hosting était resté juste un blog de critiques régulier, je n’aurais probablement pas fait cette migration.

Mais pour une plateforme qui souhaite devenir un écosystème d’hébergement complet, je pense que cette décision était exactement la bonne.

Vous envisagez de déplacer WordPress vers une pile plus flexible ?

Si votre site Web se développe au-delà d’un site de contenu standard et commence à ressembler davantage à une plate-forme de produits, nous pouvons d’abord vérifier si une migration de pile est vraiment nécessaire ou si le système actuel a simplement besoin d’une architecture plus propre.

Commencez par une consultation gratuite ou consultez notre service de développement de sites Web si vous avez besoin d’une reconstruction sur une base plus facile à faire évoluer.