Du site HTML au WordPress personnalisé : une étude de cas exportimportdept.com

Le 9 mars 2026, Mas Bagus de PT Milenial Solusi Internusa, ou MSI Freight, m’a contacté pour discuter de son site Web de profil d’entreprise à l’adresse exportimportdept.com.

La demande initiale n’était pas simplement de créer un nouveau look. MSI souhaitait un site Web mieux adapté au marketing et au référencement.

Le site Web devait également être plus facile à gérer pour l’équipe interne sans dépendre d’un développeur pour des modifications petites ou moyennes.

Mon plan initial était de reconstruire le site Web avec GeneratePress et GenerateBlocks.

Cependant, lors d’une réunion en ligne, l’équipe MSI m’a montré le site HTML qu’elle avait elle-même conçu et développé.

À ce moment-là, l’orientation du projet a changé. Je n’ai pas eu besoin de créer un nouveau concept visuel à partir de zéro. Au lieu de cela, j’ai transformé le design HTML en WordPress avec un thème personnalisé et des blocs personnalisés.

Le résultat fut 13 pages basées sur le site HTML tout en préservant son design.

Derrière ces pages se trouvaient un système de contenu WordPress, la migration de 32 articles et 346 301 règles de redirection pour maintenir la continuité des anciennes URL.

Bref résumé

Condition de départ : la conception existait déjà, mais le workflow n’était pas prêt

MSI disposait déjà d’un site Web contenant des informations sur les services, un portfolio, des articles, des photos, des vidéos et une page de contact.

Le problème était que le site Web n’était pas encore prêt à servir de base à long terme pour le marketing et le référencement.

Certaines des références disponibles étaient également des sauvegardes frontales. Je ne partais pas d’un code source complet et d’une base de données pouvant être simplement transférés.

Pour cette raison, la reconstruction a dû commencer par une lecture de la structure et de la conception visuelle existantes.

Dès nos premières discussions, le besoin de MSI était clair : les visiteurs devaient comprendre plus facilement leurs services de transport de fret.

L’équipe interne devait également mettre à jour le contenu sans demander l’aide d’un développeur à chaque fois que quelque chose changeait.

L’ancien suivi des sites Web ne distinguait pas non plus clairement les prospects Web des autres activités, telles que les actions locales dans Google Maps.

Le nouveau site Web devait donc rendre les interactions telles que WhatsApp, les appels téléphoniques et les formulaires plus faciles à mesurer.

Pourquoi le plan GeneratePress a-t-il changé ?

GeneratePress et GenerateBlocks restaient des choix raisonnables pour un site Web de profil d’entreprise qui avait besoin d’une base légère et flexible.

C’est pourquoi c’était mon plan initial.

Cependant, le site HTML que l’équipe MSI m’a montré contenait déjà la direction visuelle souhaitée.

La page d’accueil comportait une section héros avec une photo du conteneur, un grand titre, les couleurs de la marque bleu et orange, un panneau de suivi des expéditions et des informations sur le bureau en bas.

Si j’avais continué avec une approche basée sur des modèles et tout repensé depuis le début, il y avait un risque que le résultat final s’éloigne de la conception déjà approuvée par MSI.

Il y aurait également un travail supplémentaire pour réinterpréter la disposition, l’espacement, les composants et la hiérarchie visuelle.

C’est pourquoi j’ai recommandé un thème personnalisé adapté au site HTML.

La décision n’était pas due au fait que GeneratePress ou GenerateBlocks étaient mauvais. C’est parce que les exigences du projet étaient déjà plus spécifiques que le simple choix d’un thème tout fait.

Portée finale : 13 pages basées sur le site HTML

Pour la portée finale, j’ai construit 13 pages basées sur la structure du site HTML fournie par l’équipe MSI.

Ce numéro faisait référence aux pages principales qui faisaient partie du site Web, et pas simplement au nombre d’enregistrements qui apparaîtraient plus tard dans la base de données WordPress.

Au-delà de ces pages, le site Web avait également besoin de plusieurs types de contenu afin que la gestion du contenu ne revienne pas au HTML brut.

J’ai préparé des structures pour les services, les éléments de portefeuille, les articles et les calendriers d’import-export en fonction des besoins opérationnels de MSI.

La liste de services contient des champs et des métadonnées qui peuvent être gérés à partir du tableau de bord au lieu du HTML brut.

L’éditeur de service LCL sépare le héros, le prospect, les métadonnées SEO et les paramètres de navigation du modèle frontend.

Cette décision était importante car les pages statiques et le contenu récurrent ont des besoins de gestion différents.

Les pages principales devaient conserver leur mise en page, tandis que les articles, services, éléments de portefeuille et calendriers devaient être ajoutés ou mis à jour régulièrement.

Le portfolio disposait également de son propre éditeur pour les images, les galeries, les catégories et les informations sur le projet.

Les champs du portefeuille permettent à l’équipe d’ajouter un nouveau projet sans reconstruire la mise en page à partir de zéro.

Création du thème personnalisé et des blocs personnalisés

J’ai utilisé le thème personnalisé pour contrôler la base visuelle, les modèles, l’en-tête, le pied de page et les styles qui devaient rester cohérents.

La zone de contenu a ensuite été rendue modifiable grâce à des blocs personnalisés préparés autour de la conception de la page d’accueil.

Dans la démo que j’ai donnée à l’équipe MSI, la page d’accueil commençait avec une zone de contenu vide, ainsi que l’en-tête, le pied de page et l’appel à l’action avant le pied de page.

L’équipe pourrait ensuite ajouter des sections à l’aide des blocs disponibles, modifier le texte, les URL, les photos ou les vidéos, et les réorganiser par glisser-déposer.

La page d’accueil peut être modifiée dans l’éditeur de blocs tandis que le héros, le CTA et le panneau de suivi continuent de suivre la conception convenue.

Il s’agit d’une différence importante entre préserver une conception et préserver le fonctionnement du HTML. Le design est resté la référence visuelle, mais la gestion de contenu s’est transformée en un flux de travail WordPress plus pratique.

Dans la mesure du possible, j’ai également séparé les fonctionnalités du site Web du thème.

Les blocs personnalisés, les types de publication personnalisés, les paramètres du site Web, les formulaires de devis et les fonctionnalités spéciales ont été placés dans une couche fonctionnelle afin qu’ils ne soient pas tous attachés aux fichiers modèles.

La couche fonctionnelle MSI Core gère les CPT, les paramètres, les blocs Gutenberg, les formulaires de devis et les exigences spécifiques au site Web.

Les paramètres globaux, tels que l’en-tête et le pied de page, ont également été créés dans une zone dédiée afin qu’ils n’aient pas besoin d’être modifiés directement dans les fichiers de thème.

Les paramètres globaux couvrent la marque, les adresses des bureaux, le pied de page et d’autres sections utilisées sur le site Web.

L’éditeur de blocs a également été utilisé pour la zone du logo du client et du partenaire. L’équipe MSI pouvait gérer l’ordre des logos, remplacer les images et ajouter du texte alternatif à partir du même éditeur.

Le nuage de logos est géré comme un bloc avec un flux de travail d’images et de texte alternatif plus structuré.

Le compromis était qu’un thème personnalisé nécessitait plus de temps de développement et de contrôle qualité au début.

En retour, MSI a reçu un système qui correspondait mieux à sa conception et ne nécessitait pas un ensemble de remplacements pour forcer un thème générique à suivre le site HTML.

Construire la base du référencement et du contenu

Avant le début du développement complet, j’ai préparé le référencement et la structure du contenu pour le marché indonésien.

Cette recherche ne visait pas seulement à trouver les mots-clés ayant le plus grand volume. Je devais m’assurer que les mots-clés correspondaient aux services de MSI, avaient une intention de recherche claire et pouvaient être transformés en pages utiles.

Méthode de recherche de mots clés

J’ai utilisé Semrush comme source de données principale. La base de données a été définie sur l’Indonésie et l’annexe de base de sélection de mots clés a été envoyée à MSI le 22 juillet 2026.

J’ai utilisé Semrush pour trouver des variantes de mots clés et examiner les données de volume disponibles. Je traitais toujours le volume comme une estimation du fournisseur, et non comme un nombre absolu garanti de recherches chaque mois.

Après avoir obtenu la liste initiale, je l’ai validée manuellement via la recherche Google et le SERP. J’ai examiné les pages qui apparaissaient, le type de contenu qu’elles utilisaient, leur intention de recherche et si Google affichait plus souvent des pages de service ou des articles pour une requête particulière.

J’ai également comparé les modèles utilisés par les sites Web apparaissant dans les SERP avec des références du secteur. L’objectif n’était pas de copier les concurrents, mais de comprendre à quelles informations il fallait répondre sur des sujets tels que LCL, FCL, le fret aérien, le dédouanement, le PPJK et le fret de projet.

Pour les termes liés à l’importation, à l’exportation et à la réglementation, j’ai recoupé la formulation avec des sources officielles. Cela a permis de garantir que la rédaction ne suivait pas simplement la terminologie utilisée par d’autres sites Web.

J’ai ensuite validé la recherche par rapport au profil de l’entreprise, aux directives de la marque, à la liste de services et aux discussions avec l’équipe MSI. Cela m’a permis de confirmer que les mots-clés sélectionnés représentaient les services réellement proposés par MSI.

Les données de l’ancien site Web et ses rapports d’analyse ont également fourni un contexte. Cependant, je ne les ai pas utilisés comme seule base, car l’ancien suivi enregistrait encore de nombreuses actions locales, telles que l’activité de Google Maps, plutôt que des pistes Web vérifiables.

Des mots clés à la structure des pages

La recherche de mots clés a porté sur la page d’accueil et les 11 services répertoriés dans le profil de l’entreprise. Après cela, j’ai créé une carte de mots clés afin que chaque groupe d’intention ait un propriétaire de page clair.

Pour chaque page, le résultat a été traduit en :

• mots-clés principaux et variantes associées ;
• le titre SEO, H1, et la méta description ;
• recommandations de liens permanents ;
• orientation du contenu basée sur l’intention de recherche ;
• un plan de maillage interne à partir d’articles et autres pages de services.

Cela a empêché la recherche de mots clés de se terminer sous forme de feuille de calcul. Les résultats sont devenus la base du plan du site, de la structure des URL, de la rédaction et du système de liens internes utilisés pendant le développement.

La décision d’utiliser l’indonésien comme langue principale est également issue de ce processus. Les mots-clés transactionnels pertinents utilisaient souvent des termes tels que « jasa », « importation » et « transitaire ».

La recherche initiale a produit 85 variantes de mots clés. Soixante d’entre eux disposaient de données de volume.

Les autres ont dû être traités avec plus d’attention car ils ne disposaient pas de suffisamment de données de volume pour étayer une affirmation sur la demande.

Je n’ai pas non plus forcé tous les mots-clés mentionnés précédemment par un fournisseur antérieur sur le site Web.

Par exemple, MSI avait vu apparaître sur la page d’accueil le terme « jasa LCL murah ». Cependant, la recherche a montré que « jasa import LCL » avait du volume, tandis que l’ajout de « murah » n’avait pas suffisamment de données.

J’ai donc quand même préparé une page de service LCL, mais je n’ai pas inséré le mot « murah » dans la rédaction simplement parce qu’il était apparu dans une revendication de classement.

La structure de la page, le titre, la méta description et les liens internes devaient suivre l’intention et des preuves plus crédibles.

En plus des pages de service, j’ai migré 32 articles de l’ancien site avec leurs images et métadonnées SEO.

Ces articles restaient importants car ils pouvaient devenir des sources de liens internes vers les nouvelles pages du service.

Fonctionnalités prenant en charge les opérations de MSI

L’une des fonctionnalités principales était le formulaire de demande de devis.

Le formulaire utilisait Cloudflare Turnstile pour réduire le spam, l’envoi d’e-mails via Resend SMTP, un e-mail de confirmation pour l’expéditeur et une notification pour l’équipe MSI.

Pour le contenu des services et du portefeuille, j’ai utilisé un modèle de données plus structuré au lieu de tout écrire sur une longue page.

L’équipe a pu gérer chaque élément du tableau de bord tandis que les modèles frontaux ont continué à maintenir une cohérence visuelle.

Le tableau de bord rassemble les services, les éléments de portefeuille, les articles et les demandes de devis afin que l’équipe puisse voir son travail principal à partir d’un seul endroit.

Les calendriers d’exportation et d’importation ont également été rendus modifiables à partir du tableau de bord WordPress.

Les informations préalablement préparées dans des fichiers pouvaient être affichées sous forme de tableaux sur le site Web, avec une option de téléchargement PDF pour les visiteurs qui avaient encore besoin du format de document officiel.

L’éditeur de planning fournit des onglets d’exportation et d’importation, un itinéraire, un navire, un voyage, une coupure, ETD, ETA et des fichiers téléchargeables.

Sur le frontend, les données de planification apparaissent sous la forme d’un tableau plus facile à analyser et peuvent toujours inclure le fichier officiel.

Au cours d’un test, les données de planification ont semblé disparaître après avoir été enregistrées.

Je l’ai restauré via les révisions de WordPress, puis j’ai résolu un problème d’échappement dans les données envoyées à l’éditeur.

Ceci est un petit exemple de la raison pour laquelle les révisions et les flux de récupération doivent être traités comme faisant partie du système, plutôt que comme des fonctionnalités facultatives pouvant être ignorées.

Le suivi des expéditions n’a pas été intentionnellement inclus comme fonctionnalité de production dans cette phase.

MSI avait déjà préparé une documentation API et la page d’accueil affichait une zone « à venir », mais la source de données était toujours connectée à une transition ERP et aux systèmes internes.

Construire un plugin de suivi avant que la source de données ne devienne stable ne ferait que créer une refonte.

C’est pourquoi j’ai positionné l’intégration de l’API comme une phase de développement ultérieure, après que l’ERP de MSI soit devenu la source finale de vérité.

Migration : les redirections et les permaliens comptent autant que la conception

La migration du site Web n’est pas terminée lorsque la nouvelle page d’accueil est visible.

Les anciennes URL, articles, plans de site, analyses, courrier électronique et configuration DNS doivent également être vérifiés afin que le déplacement n’interrompe pas un flux existant.

Pour conserver les anciennes URL, j’ai préparé des règles de redirection 346 301 dans Cloudflare.

Ces règles ont été activées lorsque le site Web a été transféré vers l’hébergement MSI et que le processus de lancement était prêt.

Il y avait également un problème classique après la migration : l’URL /artikel/ renvoyait un 404. La cause n’était pas une page manquante, mais les règles de permalien WordPress qui devaient être actualisées.

Je l’ai résolu en vidant ou en enregistrant à nouveau les permaliens WordPress.

La route des articles fonctionnait alors normalement. Cela semble simple, mais cela fait toujours partie de la liste de contrôle d’assurance qualité, car ce problème apparaît souvent après un déménagement d’hébergement ou une modification de la structure d’une URL.

La navigation mobile a également été testée car le menu de service comportait plusieurs niveaux de catégories. Sur des écrans plus petits, le menu donnait toujours accès aux services, aux articles, aux contacts et au CTA principal sans modifier la structure des informations du bureau.

Le menu mobile préserve la hiérarchie des services et le CTA principal dans un espace d’écran plus petit.

Résultats visibles

Les changements du projet peuvent être vus sous plusieurs angles :

Zone	Avant	Après
Source visuelle	Site HTML comme interface	Thème personnalisé suivant le design HTML
Gestion des pages	Dépend de l’implémentation du frontend	WordPress avec blocs personnalisés
Portée de la page principale	Ancien site Web avec une structure limitée	13 pages basées sur le site HTML
Contenu de l’article	Stocké dans l’ancien système	32 articles migrés avec images et métadonnées
Anciennes URL	Doit être remappé	346 règles 301 actives dans Cloudflare
Calendrier export-import	Fichiers et processus manuel	Géré depuis le tableau de bord et affiché sur le site

L’instantané PageSpeed Insights que j’ai enregistré a enregistré les performances du bureau à 100 et les performances mobiles à 92.

Instantané du bureau : performances 100, FCP 0,5 seconde, LCP 0,6 seconde, TBT 0 ms et CLS 0,001.

Instantané mobile : performances 92, FCP 2,0 secondes, LCP 3,2 secondes, TBT 0 ms et CLS 0.

Pourquoi le score mobile était-il inférieur ? Le héros de la page d’accueil utilisait la vidéo, donc son téléchargement, son décodage et son rendu étaient plus visibles sur les appareils mobiles.

Google Tag Manager et Meta Pixel ont également ajouté des travaux provenant de scripts tiers. Dans le cadre de ce projet, j’ai considéré un score de 92 raisonnable sans supprimer les éléments réellement nécessaires à MSI.

Cependant, PageSpeed Insights est un test en laboratoire utilisant un appareil et un réseau simulés. Un score de 92 ne signifie pas automatiquement que l’expérience réelle est pire qu’une page avec un score de 100.

Avec différents appareils, réseaux, caches et scripts, une page avec un score de laboratoire de 92 peut sembler plus rapide en pratique. C’est pourquoi le numéro doit être lu avec les données des utilisateurs réels lorsque les données de trafic et de terrain sont disponibles.

Le suivi de la préparation doit également être séparé des résultats commerciaux.

GA4, GSC, GTM, Meta Pixel, les événements WhatsApp, les événements téléphoniques et les événements de formulaire aident MSI à collecter des données plus utiles, mais ils ne prouvent pas automatiquement une augmentation des prospects ou des revenus.

Leçons du projet

1. La découverte peut modifier une décision technique

Le plan initial utilisant GeneratePress et GenerateBlocks était basé sur les informations disponibles lors de la phase de proposition.

Après la présentation du site HTML lors de la réunion, la décision la plus raisonnable a été de choisir un thème et des blocs personnalisés.

Pour moi, ce n’était pas un changement de périmètre à éviter. C’était le résultat d’une découverte permettant une mise en œuvre mieux adaptée aux atouts et aux attentes du client.

2. La personnalisation ne signifie pas toujours mieux

Si le design n’existe pas encore ou est encore très flexible, un système de thèmes et de blocs mature peut être un choix efficace.

L’architecture personnalisée a du sens lorsque la conception est déjà spécifique, que le flux de travail d’édition doit être contrôlé et que le résultat visuel doit rester cohérent.

3. La migration nécessite un plan de relance

Les redirections, les permaliens, les révisions et la liste de contrôle d’assurance qualité peuvent ne pas être visibles sur la page d’accueil.

Pourtant, ces détails déterminent souvent si le nouveau site Web peut être utilisé sans perdre l’accès à l’ancien contenu.

4. Les fonctionnalités différées font également partie du succès

Je n’ai pas forcé le suivi des expéditions en production simplement parce que sa zone d’interface utilisateur existait déjà.

Attendre que l’ERP et l’API deviennent plus stables était plus sûr que de livrer une fonctionnalité qui devrait être reconstruite lorsque sa source de données changeait.

Conclusion

Le projet exportimportdept.com montre que la transformation du HTML en WordPress ne nécessite pas de sacrifier la conception existante du client.

Le principal défi consistait à traduire une implémentation visuelle fixe en un système de contenu qui restait flexible.

Avec un thème personnalisé et des blocs personnalisés, MSI a reçu 13 pages HTML pouvant être gérées via WordPress.

Derrière cela se trouvaient une base de référencement, une migration d’articles, des redirections, des formulaires, des calendriers et un suivi préparés pour la prochaine étape du marketing et des opérations.

Si vous possédez déjà un site HTML avec un design que vous souhaitez conserver, je peux vous aider à déterminer quelles parties peuvent être converties en blocs.

Des fonctionnalités plus sûres car le code personnalisé peut être séparé dès le début.

Vous pouvez commencer avec notre service de développement de sites Web ou nous contacter pour discuter d’une conversion de blocs WordPress.