Chaque client en a une. Une fonctionnalité évoquée en réunion il y a trois ans, entrée dans un devis, et jamais sortie. Pas parce qu’elle était impossible. Parce que, sur le socle en place, elle coûtait plus cher à maintenir qu’elle ne pouvait rapporter.

Pour Galant Architectes, cabinet d’architecture bruxellois qui régularise des bâtiments depuis 1999, cette fonctionnalité était une carte.

156 projets réalisés, répartis sur les 19 communes de Bruxelles. Écrit comme ça, c’est un chiffre dans une page « à propos ». Personne ne pouvait voir ce que ça représente.

Pourquoi une liste est la mauvaise forme pour un portfolio

Regardez ce que fait vraiment un propriétaire confronté à un problème d’urbanisme. Il ne parcourt pas de l’architecture. Il a peur, il a reçu un courrier de la commune, et il veut savoir une seule chose : est-ce que ce cabinet a déjà réglé ce cas, près de chez lui ?

Une liste de projets répond mal à cette question. On fait défiler, on lit des adresses, on essaie de se souvenir laquelle était dans son quartier.

Une carte y répond avant qu’on ait lu un seul mot.

Ce n’est pas une préférence esthétique. C’est la différence entre une page qui prouve un historique et une page qui se contente de l’affirmer. Plus de vingt-cinq ans de métier dans une liste, ça ressemble à du contenu. Le même travail sur une carte, ça ressemble à une couverture du territoire.

Possible, mais pas raisonnable

L’ancien site tournait sous WordPress, et la carte y existait sous une forme limitée, via un plugin tiers.

Rien, dans la version ambitieuse, n’était techniquement impossible. C’était simplement déraisonnable :

Les données vivaient dans le CMS, donc chaque combinaison de filtres signifiait une requête en base à l’affichage, pour chaque visiteur.
La carte dépendait d’un plugin dont la feuille de route ne nous appartenait pas. Une fonctionnalité nécessaire pouvait arriver, ne jamais arriver, ou arriver derrière une licence supérieure.
Chaque évolution demandait du développement sur mesure, par-dessus un thème, un page builder et une pile de plugins qui devaient continuer à s’entendre après chaque mise à jour.

La carte est donc restée dans le devis, année après année.

C’est la part des plateformes vieillissantes qui n’apparaît jamais dans un rapport. Elle ne se voit ni comme un bug ni comme une page lente. Elle se voit comme des idées qui ne sont jamais construites, parce que le coût de les construire sur le socle actuel n’est jamais justifiable sur le moment.

Changer le socle d’abord

En 2026, nous avons reconstruit le site sur Astro, généré à la compilation et servi en statique depuis Cloudflare Pages. La liste des dépendances de production tient en trois paquets : aucun runtime de framework envoyé au navigateur, et très peu de choses à maintenir à jour.

L’enjeu n’était pas la technologie. L’enjeu était ce que cette technologie rendait abordable.

Quand les projets existent comme données à la compilation au lieu d’être des lignes interrogées à la volée, une carte de l’ensemble n’est plus une fonctionnalité coûteuse. Ce sont les mêmes données, rendues deux fois : une fois en cartes, une fois en points.

La règle : pas une seule URL ne bouge

Avant toute nouvelle fonctionnalité, la migration devait être invisible pour Google. Les positions du cabinet, c’était son activité. Une refonte qui perd discrètement un tiers de ses URLs, c’est une refonte qui coûte des demandes clients.

La règle était donc absolue : chaque page garde son adresse exacte.

206 pages dans le périmètre de migration ont été reconstruites à leur URL d’origine.
3 018 fichiers médias ont conservé leur chemin d’upload initial, jusqu’aux dossiers année et mois créés par WordPress.
Un contrôle de parité automatique tourne avant chaque déploiement. Il compare le title, la meta description, la canonique, la directive robots et le H1 de chaque page générée avec une capture des originaux WordPress, et refuse de publier à la moindre différence.

C’est ce dernier point que nous refaisons sur chaque migration. Une checklist est une promesse. Un contrôle qui bloque le déploiement est une garantie. Le sitemap compte 211 URLs aujourd’hui, les cinq en plus étant des articles publiés depuis.

Sur les principales requêtes examinées, les positions moyennes sont restées proches entre les quatre semaines qui ont précédé la migration et les quatre semaines qui ont suivi. C’est tout l’objectif d’une migration de plateforme : le public ne doit jamais s’apercevoir qu’elle a eu lieu.

Puis la carte, dans une interface que tout le monde connaît déjà

La page projets reprend un schéma que chaque visiteur a déjà utilisé, sur Airbnb ou sur un portail immobilier : les résultats défilent à gauche, la carte reste fixe à droite pendant tout le défilement.

Sous cette surface familière :

156 projets, chacun une vraie carte rendue côté serveur. La liste est entièrement crawlable et les cartes restent lisibles avec JavaScript désactivé. Un portfolio qui n’existe qu’une fois un script exécuté est un portfolio que les moteurs ne peuvent pas compter.
Des filtres par commune, type de bien, tranche de surface et année, plus une recherche libre sur n’importe quelle adresse, avec un compteur de résultats en direct sur chaque option pour que personne ne tombe sur une liste vide.
Un explorateur Leaflet sur mesure avec clustering, à la place du plugin. Les cartes et les points sont construits à partir des mêmes données projet : ils ne peuvent pas se contredire.
Un bouton « Situer » sur chaque carte, qui amène la carte directement à cette adresse.
Une bascule liste ou carte sur mobile, où l’écran partagé ne tient pas.

Deux jours après que le nouveau socle a été prêt, les 156 projets étaient sur la carte.

Nous manions ce chiffre avec prudence, parce que la vitesse d’exécution est la chose la moins intéressante de l’histoire. Ces deux jours n’ont été possibles que parce que le travail de migration qui les a précédés avait déjà mis les données dans la bonne forme.

Ce que ça coûte en performance

C’est la page la plus lourde du site : 156 cartes plus une carte interactive. Mesurée en direct en septembre 2026, elle obtient 93/100 sur mobile et 97/100 sur desktop, avec 100/100 en accessibilité, bonnes pratiques et SEO. La page d’accueil obtient 95/100 sur mobile et 100/100 sur desktop.

Une carte n’est pas gratuite. Elle n’est simplement plus assez chère pour qu’on y renonce.

La leçon à retenir

L’argument habituel en faveur d’un framework moderne, c’est la performance. La vitesse, les Core Web Vitals, un panneau Lighthouse plus vert.

Cet argument est vrai, et il est ennuyeux. La vitesse, c’est le minimum. Toute pile technique sérieuse peut être rendue rapide.

Le vrai retour est ailleurs : un socle où la bonne idée devient assez bon marché pour être construite. Galant n’a pas obtenu un site plus rapide. Galant a obtenu plus de vingt-cinq ans de métier visibles d’un seul regard, et une expertise qui se voit au lieu de se raconter.

Ce qui pose la question que nous poserions à n’importe quel site en place depuis quelques années. Combien d’expertise dort encore dans vos pages, faute d’une fonctionnalité qui était toujours possible, mais jamais raisonnable ?

Si la question résonne, l’étude de cas complète de Galant Architectes contient le reste des chiffres, et notre page migration explique comment nous déplaçons un site sans déplacer ses adresses.