ACS - Antoine Connect Systems
LAB

Pourquoi j'ai reconstruit mon site avec Astro (et abandonné Odoo)

Mon site tournait sur Odoo. Avant ça, j’avais envisagé WordPress. Les deux avaient le même problème : je passais plus de temps à gérer l’outil qu’à m’occuper de mon contenu.

En janvier 2026, j’ai tout repris de zéro avec Astro. Le résultat : un site qui charge en moins de 25 millisecondes, que je peux modifier en quelques minutes, et qui ne me coûte qu’un hébergement mutualisé. Voici comment j’en suis arrivé là.

Le problème avec les CMS classiques

WordPress, Odoo, Wix — ces outils sont pensés pour tout faire. Et c’est justement le souci. Pour un site vitrine de consultant, on se retrouve avec un système de gestion de base de données, un back-office complet, des dizaines de plugins à maintenir et des mises à jour de sécurité régulières. Tout ça pour afficher cinq pages et quelques articles.

Concrètement, sur Odoo, chaque modification passait par une interface d’administration complète. Le moindre changement de texte demandait de se connecter, naviguer dans les menus, éditer, publier. Le temps de chargement des pages dépassait la seconde — pas catastrophique, mais loin d’être optimal pour un consultant qui vend de l’expertise IT.

Et surtout : je dépendais d’un outil que je ne maîtrisais pas complètement. Pour quelqu’un dont le métier est de conseiller des PME sur leurs choix technologiques, c’était un peu gênant.

Astro : un générateur de sites statiques

Astro fait une chose et la fait bien : il transforme des fichiers texte en pages web. Pas de base de données, pas de back-office, pas de serveur d’application. Le résultat est un ensemble de fichiers HTML, CSS et JavaScript qu’on dépose sur n’importe quel hébergement.

Pour les profils techniques : Astro utilise une architecture en “îlots” (islands architecture). Le HTML est généré au build, et le JavaScript n’est chargé que là où il y a de l’interactivité. Dans mon cas, j’utilise Svelte pour les composants dynamiques (formulaire de contact, navigation mobile) — le reste est du HTML pur. Zéro JavaScript inutile côté client.

Pour les non-techniques : imaginez un site web qui fonctionne comme un livre imprimé. Les pages existent déjà, le serveur n’a qu’à les distribuer. Pas de calcul à faire à chaque visite, pas de base de données à interroger. C’est pour ça que c’est rapide.

Bref, pour un site vitrine/blog, c’est le top.

Les résultats concrets

Les temps de chargement parlent d’eux-mêmes. Chaque page du site se charge en moins de 25 millisecondes. Pour donner un ordre de grandeur, un clignement d’œil dure environ 300 millisecondes — le site est chargé 12 fois avant que vous ayez fini de cligner.

Au-delà de la vitesse pure, il y a un impact direct sur le référencement. Google favorise les sites rapides, et un site statique bien construit coche toutes les cases : temps de réponse minimal, pas de ressources bloquantes, contenu immédiatement lisible par les moteurs de recherche.

Côté sécurité, un site statique n’a tout simplement pas de surface d’attaque. Pas de formulaire de connexion admin à forcer, pas de base de données à injecter, pas de plugins vulnérables. Pour un consultant en cybersécurité, la cohérence entre le discours et la pratique compte.

Et surtout, le score LightHouse qui parle de lui-même : Scores Lighthouse du site ACS

Mon workflow au quotidien

C’est là que ça devient intéressant pour le quotidien. Quand je veux publier un article — comme celui que vous lisez — voici ce que je fais :

  1. J’ouvre mon éditeur de code et je crée un fichier Markdown (un format texte simple, lisible par un humain)
  2. J’écris mon contenu, sans me soucier de la mise en page
  3. Je lance une commande pour voir le résultat en local
  4. Quand c’est bon, je lance le build et j’envoie les fichiers sur l’hébergement

Tout l’article tient dans un fichier texte. Pas d’interface d’administration, pas de clic dans des menus. Je peux écrire depuis n’importe quel poste connecté à mon réseau, avec n’importe quel éditeur de texte.

Pour les curieux : le site est développé sur un conteneur LXC de mon serveur Proxmox, accessible en SSH. VS Code s’y connecte à distance, ce qui me permet de travailler depuis n’importe quel poste sans rien installer localement. Le déploiement en production se fait par un simple transfert FTP vers l’hébergement Infomaniak.

À qui ça s’adresse ?

Astro n’est pas la solution universelle. Si vous avez besoin d’un e-commerce, d’un espace client avec authentification ou d’un back-office pour une équipe de rédacteurs, un CMS reste pertinent.

En revanche, pour un site vitrine, un blog d’entreprise ou un portfolio de projets, les générateurs de sites statiques comme Astro sont difficiles à battre. Performance, sécurité, coût de maintenance — tous les voyants sont au vert.

Et si vous vous demandez si cette approche pourrait convenir à votre entreprise, c’est exactement le genre de question qu’on peut explorer ensemble lors d’un premier échange.


Cet article fait partie de L’Atelier, où je partage mes retours d’expérience et réflexions sur les choix technologiques du quotidien.