Le jour où une marque veut partir, elle découvre ce qu’elle possédait vraiment. Avant ce jour-là, la différence entre posséder et louer ne se voit pas : le site s’affiche, le back-office répond, tout va bien. Elle se paie d’un coup, au moment précis où plus personne n’a le temps.
Le loyer qui n’apparaît sur aucune facture
Un site monté sur une plateforme fermée n’est pas à vous. Vous occupez un emplacement. Le jour où le prix monte, où la plateforme change ses règles, retire une fonction ou ferme, vous n’emportez rien d’utilisable. Vos pages vivent dans un format que personne d’autre ne sait lire, et l’export, quand il existe, rend une soupe de balises qu’il faut retaper.
Migrer, c’est tout refaire. Le devis de la migration ressemble au devis du site d’origine, à ceci près qu’on le paie une seconde fois, sans le budget qui allait avec.
Une plateforme fermée devient plus chère à quitter à mesure qu’on s’en sert mieux : chaque article publié, chaque réglage patiemment trouvé augmente le coût de sortie.
Le domaine d’abord, et rien avant
Le nom de domaine est le seul actif que vous possédez vraiment. Tout doit s’y rattacher : le site, les e-mails, l’identité. Un domaine à vous, chez un registrar neutre, et le reste peut bouger sans rien casser.
C’est la première décision d’un projet, et celle qu’on expédie le plus vite, sans doute parce qu’elle coûte quelques euros par an et qu’elle n’a l’air de rien.
Des fichiers, pas une base captive
Le contenu de ce site vit dans des fichiers texte. Chaque note du journal est un fichier Markdown dans src/content/journal/, dont le nom de fichier fait l’URL, sans champ intermédiaire ni identifiant à retrouver. Astro compile l’ensemble en HTML statique.
Il n’y a pas de base de données, donc il n’y a rien à exporter : le dépôt git est le contenu. Avec, en prime, l’historique de chaque phrase. Je peux dire quel jour une formule a changé et ce qu’elle disait avant.
Changer d’hébergeur revient à pointer un domaine ailleurs et à relancer un build. La sauvegarde, c’est le fonctionnement normal : n’importe quelle copie du dépôt est un site complet.
Rien n’est prisonnier, pas même de moi : ce site fait 242 pages, dans 2 langues, à partir de fichiers qui tiennent tous dans un dossier qu’on peut lire avec un éditeur de texte.
Reprendre le site sans me téléphoner
Un client qui dépend de son développeur n’est pas mieux loti qu’un client qui dépend d’une plateforme. Il a changé de propriétaire, c’est tout.
Un site en Astro, en Markdown et en git se reprend par n’importe quel développeur front, sans rien deviner : les décisions se lisent dans les commits, les règles du projet sont écrites dans un fichier à la racine. La question à poser sur un prestataire est donc « qu’est-ce qui se passe s’il n’est plus là ».
C’est aussi pourquoi l’édition passe par Sveltia, un CMS existant, et non par un outil maison. Un outil maison m’aurait rendu indispensable. Très agréable pour moi, très mauvais pour le client, et parfaitement invisible tant que tout va bien.
Ce que la sortie coûte vraiment
Louer reste plus confortable au départ : on démarre en une après-midi, sans décision technique. Pour tester une idée, c’est souvent le bon choix.
Le coût n’apparaît pas au démarrage. Il apparaît à la sortie, et il tombe au pire moment, puisqu’on ne cherche à partir que quand quelque chose ne va plus. Posséder, à l’inverse, demande un choix technique pris au bon moment, et ce choix ne coûte presque rien le premier jour.
Si ce site quittait Netlify demain, tout partirait avec le dépôt sauf trois choses, à refaire : le formulaire de contact, le relais d’authentification de l’admin (netlify/functions/oauth.mjs, 169 lignes) et les en-têtes HTTP de netlify.toml.



