Adieu CMS : nous avons refait host.it avec Astro, et le marketing fonctionne désormais tout seul

WordPress, Joomla et autres CMS ont rendu le Web accessible à des millions de personnes et continuent d'être des outils adaptés à de nombreux projets. Mais notre site institutionnel avait des besoins différents : la plupart des pages changent lorsque le marketing le décide, et non à chaque requête HTTP.

• 90 % du site n'était pas dynamique. Les pages produits, les listes de prix et le contenu institutionnel n'avaient pas besoin d'être régénérés par le serveur à chaque visite.
• La surface d'attaque n'était pas proportionnée. Le runtime PHP, la base de données, le panneau d'administration et les plugins nécessitent des mises à jour et des contrôles continus, même lorsque le site n'a besoin que d'afficher du contenu.
• Le goulot d'étranglement était organisationnel. Pour éditer une page, des compétences étaient nécessaires en matière de rédaction, de graphisme, de développement et de publication.

Astro est un framework moderne conçu pour les sites orientés contenu. Pendant la construction, transformez les composants, les données et les pages en fichiers HTML prêts à être déployés. Lorsqu'un visiteur ouvre host.it, le serveur n'a pas besoin d'interroger une base de données ou d'exécuter PHP pour composer la réponse.

Zéro JavaScript par défaut

Astro envoie du HTML et du CSS au navigateur. JavaScript n'est ajouté qu'aux composants qui doivent être véritablement interactifs : le visiteur ne télécharge pas une application complète pour lire une page.

Architecture insulaire

Un formulaire, un configurateur ou un widget peut devenir un îlot interactif, chargé en cas de besoin. Le reste de la page reste du HTML statique. Cela réduit le code qui s'exécute dans le navigateur et facilite le contrôle des performances et du comportement.

Composants et contenus validés lors de la phase de construction

Les pages et les composants sont vérifiés avant la publication. Si une donnée nécessaire manque, qu'un lien ne respecte pas le schéma ou que le projet ne se compile pas, le pipeline s'arrête : l'erreur n'est pas découverte par le client en production.

Le résultat : des fichiers statiques prêts pour CDN

Le résultat final est un dossier de fichiers HTML, CSS, JavaScript et image. Il n'y a aucun processus de candidature à démarrer et une session utilisateur n'est pas nécessaire pour afficher une page. Le temps de réponse dépend principalement du réseau et de l'emplacement du nœud CDN, et non du fonctionnement d'une application à chaque visite.

Dire qu'un site est « non vulnérable » serait techniquement incorrect : les référentiels, les pipelines CI/CD, les comptes, les dépendances, les DNS et les CDN restent des composants à protéger. L'avantage concret en est un autre : sur le site public, des classes entières de vulnérabilités applicatives typiques d'une pile dynamique disparaissent.

• Aucun PHP en cours d'exécution. Il n'existe aucun environnement d'exécution public permettant d'exécuter du code côté serveur ou de charger un webshell.
• Pas de base de données pour composer les pages. Il n'y a pas de requêtes exposées à la navigation et donc il n'y a pas d'injection SQL sur le contenu statique.
• Pas de panneau d'administration public. Il n'y a pas de page de connexion CMS permettant la force brute ou le credential stuffing.
• Aucune chaîne de plugins dans le périmètre public. Le visiteur n'interagit pas avec les extensions côté serveur pour être maintenu et mis à jour en permanence.
• Contenu publié de manière contrôlée. Pour modifier le site vous devez passer par le pipeline de build et de déploiement, qui est protégé et suivi.

Le nouveau site est distribué par notre CDN : les pages sont répliquées et servies par des nœuds périphériques proches des utilisateurs. Cela réduit la latence et la charge sur l’infrastructure source.

Cependant, il existe un avantage qui va au-delà de la vitesse. Grâce à la fonctionnalité « toujours en ligne », le CDN peut continuer à servir la copie statique du site même si le serveur d'origine est temporairement inaccessible. Une défaillance de maintenance ou de source ne devrait pas automatiquement entraîner un site hors ligne.

Dans cette architecture l'origine est essentielle pour publier une nouvelle version, mais pas pour générer toutes les pages demandées. Le contenu déjà distribué reste disponible sur le réseau CDN.

Le changement le plus important ne concerne pas seulement l’infrastructure. Auparavant, pour publier une nouvelle page de produit, des interventions distinctes en matière de rédaction, de graphisme, de développement front-end, de révision et de déploiement étaient nécessaires. Aujourd'hui, l'équipe marketing peut gérer l'intégralité du cycle grâce à un pipeline assisté par l'IA.

• Contenu. Rédaction et révision de textes avec structure, référencement, ton de voix et traductions gérés dans le même flux.
• Graphiques. Couvertures et éléments visuels produits dans les formats requis par le système de conception.
• Mise en page. Les pages sont composées avec des composants déjà approuvés : l'IA utilise le système de conception, elle ne le contourne pas.
• Tests automatisés. Les builds, validations et contrôles fonctionnels sont effectués avant la publication.
• Mise en scène et production séparées. Chaque modification est d'abord générée et vérifiée lors de la mise en scène, puis promue en production.

Passer à un site statique n’est pas gratuit et ce n’est pas la réponse universelle. Pour obtenir un résultat fiable, vous avez besoin d'un système de conception solide, d'un pipeline CI/CD avec des environnements séparés, de tests automatiques et d'une stratégie précise pour les parties véritablement dynamiques.

• Formulaires et intégrations. Ils doivent être confiés à des points de terminaison ou à des services dédiés, avec la même attention à la sécurité que n'importe quelle application.
• Outils de recherche et interactifs. Ils peuvent vivre comme des îles, sans transformer l'intégralité du site en une application JavaScript.
• Zones restreintes et données en temps réel. Nécessitent un service backend ou d'application distinct.

Pour les applications avec un contenu personnalisé par utilisateur, le e-commerce avec prix et disponibilité en temps réel ou les portails avec de vastes zones réservées, un CMS ou une application dynamique peuvent rester le bon choix. En fait, nous continuons à en héberger et à en protéger des milliers : il ne s’agit pas d’éliminer la dynamique, mais de l’utiliser uniquement là où elle crée de la valeur.

Le nouveau host.it est plus rapide, mais surtout il est plus difficile à compromettre, plus résilient et plus facile à mettre à jour. Performances, sécurité et autonomie marketing découlent du même choix : créer une seule fois, tester et déployer partout.

Si vous créez des sites pour des clients et souhaitez savoir si ce modèle est adapté à votre portefeuille, parlons-en. Pour organiser des versions contrôlées, vous pouvez en savoir plus sur notre service de préparation et de développement.