De Ghost à Astro : ce que la refonte de notre site nous a appris
Nous avons migré notre propre site d'un CMS vers un générateur statique, en conservant toutes les URLs. Voici ce que ça a coûté, ce que ça a rapporté, et ce que nous referions autrement.
Sommaire
Ce site tournait sur un système de gestion de contenu classique. Il est aujourd’hui entièrement statique : des pages construites une fois, déposées sur un espace de stockage, servies telles quelles.
Nous racontons rarement nos propres chantiers. Celui-ci mérite une exception, parce qu’il illustre à peu près tout ce que nous conseillons à nos clients — et parce qu’il nous a fait payer deux ou trois choses que nous n’avions pas anticipées.
Le point de départ
Un site vivant : 152 articles, dont 72 hérités de notre marque précédente, 37 fiches de réalisation, 35 fiches de lexique, 35 rubriques, trois auteurs. Rien d’énorme, mais assez pour que chaque décision de migration se multiplie par cent cinquante.
La motivation n’était pas le mécontentement. L’outil faisait son travail. C’étaient les à-côtés qui pesaient : les mises à jour à surveiller, un serveur d’application à maintenir pour publier trois articles par semaine, et l’impossibilité de faire passer le contenu par les mêmes contrôles que le code.
La contrainte, posée avant les maquettes
Une seule, et elle a tout structuré : ne changer aucune adresse de page.
Pas une redirection, pas une exception. Tout ce que les moteurs avaient référencé depuis des années devait rester exactement où il était — y compris les particularités d’un import historique, avec ses identifiants improbables et ses tournures d’un autre temps.
Cette contrainte a un mérite qu’on sous-estime : elle supprime entièrement la question du référencement de l’équation. Il n’y a pas de table de correspondance à écrire, pas de valeur à transférer, pas de surveillance angoissée les semaines suivantes. C’est ce que nous recommandions dans notre article sur la refonte sans perte de référencement, et nous nous l’appliquons.
En pratique, elle s’est traduite par deux réglages précis du générateur : le traitement de la barre oblique finale, et le format des dossiers de sortie. Deux lignes de configuration, une demi-journée de vérification, et le sujet est clos pour de bon.
Ce que nous avons refusé de faire
Réécrire les 72 articles hérités. Ils contiennent le balisage de l’ancien outil : des cartes, des blocs de citation, des intégrations vidéo, tout un vocabulaire de mise en forme propre au système d’origine.
La tentation était forte de tout nettoyer. Nous ne l’avons pas fait. Une feuille de style dédiée prend en charge ces blocs anciens, et ils s’affichent correctement. Le calcul est simple : réécrire cent cinquante articles aurait pris des semaines, introduit des erreurs invisibles, et produit un gain que personne parmi nos lecteurs n’aurait remarqué.
C’est un arbitrage que nous proposons systématiquement à nos clients et qu’ils acceptent rarement, parce qu’on n’aime pas laisser derrière soi quelque chose qu’on sait imparfait. Nous avons décidé de nous l’appliquer.
Tout changer en même temps. Le contenu a migré à l’identique. Le design a suivi. Les textes ont été retravaillés ensuite, article par article, sur plusieurs mois.
Ce que nous y avons gagné
Plus aucune mise à jour de sécurité urgente. Il n’y a plus de code exécuté à la visite : ni interpréteur, ni base de données, ni page d’administration à protéger. Nous avons développé ce point dans notre article sur la surface d’attaque.
Un coût d’hébergement qui ne dépend plus du trafic. Servir des fichiers coûte des centimes, y compris un jour où un article circule beaucoup.
Un contenu versionné. Chaque article est un fichier texte dans un système de versions. On voit qui a modifié quoi, on revient en arrière, on relit une modification avant publication comme on relirait du code. Pour une agence, c’est un confort ; pour la traçabilité éditoriale, c’est un changement de nature.
Des contrôles qui bloquent. C’est le bénéfice le plus inattendu. Puisque le site est construit par une chaîne automatisée, cette chaîne peut refuser de produire. Un texte de publication trop long pour le réseau visé fait échouer la construction. Un contenu incomplet ne peut pas être publié. Ce qui relevait de la vigilance humaine relève désormais de l’outil, et la vigilance humaine se fatigue.
La possibilité d’ajouter des traitements au moment de la construction. Les images de partage, l’indexation de recherche, le maillage automatique vers les fiches de lexique, l’index sémantique de l’assistant : autant de choses qui se calculent une fois, à la publication, plutôt qu’à chaque visite.
Ce que nous y avons perdu
L’édition en ligne. Publier suppose un éditeur de texte, un système de versions et une commande. Il n’y a pas d’interface, pas de brouillon partagé, pas de bouton « publier » depuis un téléphone.
Pour nous, c’est un gain déguisé en perte. Pour une organisation dont les contributeurs ne sont pas techniques, c’est un coût réel, et il faut l’évaluer honnêtement : le statique n’est pas la bonne réponse pour tout le monde. Une association dont trois bénévoles publient à tour de rôle sera mieux servie par un outil en ligne, quitte à en supporter les mises à jour.
Quelques pièges de mise en cache. Le générateur ne rejoue pas l’ensemble des traitements sur des contenus inchangés — ce qui est une excellente idée pour la vitesse, et une source de confusion quand on ajoute une fiche de lexique censée se relier automatiquement aux anciens articles : en local, rien ne bouge tant qu’on n’a pas vidé le cache. La chaîne d’intégration, elle, part d’une copie neuve et n’a jamais eu le problème. Nous l’avons découvert de la manière habituelle, c’est-à-dire en croyant à un bogue pendant une heure.
Ce que nous referions autrement
Décider plus tôt du sort des vieux contenus. Nous avons 29 articles volontairement retirés de l’indexation : des textes anciens, liés à une activité que nous n’exerçons plus, qu’il aurait été dommage de supprimer — des liens pointent dessus — et malhonnête de laisser concourir. Cette décision aurait dû être prise pendant la migration, pas six mois après.
Écrire les contrôles avant le contenu. Nous avons ajouté les vérifications automatiques au fil des incidents. Les poser dès le départ aurait évité deux ou trois corrections publiées dans l’urgence.
Ce qui est transférable
Trois enseignements, valables quel que soit l’outil d’arrivée :
- L’inventaire des adresses est la seule pièce irremplaçable. Tout le reste se refait.
- Le contenu doit devenir une source de vérité versionnée, pas un enregistrement dans une base que personne ne relit.
- Une chaîne de publication doit pouvoir refuser de publier. C’est ce qui distingue une automatisation d’un simple raccourci.
Le reste — le choix du générateur, le nom du langage, la mode du moment — n’a, très franchement, aucune importance.
Retrouvez nos articles en priorité dans vos résultats Google en nous ajoutant à vos sources préférées.
Ajouter aux sources préféréesQuestions fréquentes
Pourquoi quitter un système de gestion de contenu pour un site statique ?
Pour trois raisons mesurables : la disparition des mises à jour de sécurité urgentes, un coût d'hébergement qui ne dépend plus du trafic, et un temps d'affichage qui ne dépend plus d'une base de données. La contrepartie est réelle : l'édition passe par des fichiers et un système de versions, ce qui convient à une équipe technique et pas à tout le monde.
Peut-on migrer sans changer les adresses des pages ?
Oui, et c'est la contrainte à poser avant toute discussion sur les maquettes. Le générateur doit produire exactement l'arborescence historique, y compris ses irrégularités. Cela impose quelques réglages précis — le traitement de la barre oblique finale et le format des dossiers de sortie — mais cela supprime entièrement le risque de perte de référencement.
Que fait-on du contenu hérité de l'ancien système ?
Nous avons choisi de le conserver tel quel, y compris son balisage d'origine, plutôt que de retoucher soixante-douze articles pour une raison esthétique. Une feuille de style dédiée prend en charge ces blocs anciens. Réécrire l'existant aurait consommé des semaines et introduit des erreurs, pour un gain invisible aux lecteurs.
Combien de temps prend une migration de ce type ?
Le transfert du contenu n'est pas le poste principal : il s'automatise. Ce qui prend du temps, c'est l'inventaire des adresses, la reprise des particularités de mise en forme accumulées au fil des années, et les contrôles qui garantissent qu'aucun contenu incomplet ne peut être publié.
Quel est le vrai inconvénient du statique ?
L'absence d'interface d'édition en ligne. Publier suppose un éditeur de texte et un système de versions. Pour une équipe technique, c'est un gain — le contenu devient relisible et réversible. Pour une organisation dont les contributeurs ne sont pas techniques, c'est un coût qu'il faut évaluer honnêtement avant de s'engager.
Le statique empêche-t-il d'avoir des fonctionnalités dynamiques ?
Non, il oblige à les isoler. Notre site est intégralement statique, à l'exception d'un service séparé qui traite les requêtes de l'assistant de recherche. S'il tombe ou s'il est attaqué, le site continue de fonctionner, puisqu'il n'en dépend pas.
