Pourquoi fastsite existe

Chaque outil dans la pile d'une petite entreprise est excellent en lui-même. Aucun d'eux ne communique avec les autres, et tous facturent mensuellement. fastsite existe parce que ce schéma a fini par toucher la publication aussi.

Le problème

Mettre des mots sur internet était simple, autrefois. Puis il a fallu un CMS, et le CMS a eu besoin de plugins, et les plugins ont eu besoin d'un pipeline de build, et le pipeline de build a eu besoin d'un runtime, et le runtime a eu besoin d'un hébergement facturé par utilisateur. Quelque part dans tout ça, la vraie mission — écrire quelque chose, le mettre en ligne, le faire charger vite — s'est retrouvée ensevelie sous plusieurs centaines de kilo-octets de JavaScript et une facture mensuelle.

fastsite prend la position inverse. Le contenu entre via une API, un webhook ou MCP. Du HTML statique en sort. Il n'y a pas de runtime à la périphérie, pas de base de données accessible à vos visiteurs, et aucun JavaScript envoyé — le build refuse de publier une page qui ferait perdre un point PageSpeed plutôt que de laisser les performances se dégrader silencieusement.

Qui le développe

fastsite est écrit par Lennart Øster, un développeur au Danemark qui programme depuis 1995 et a fondé sa société, SitePoint Systems, en 1999. La première décennie ressemblait à un parcours classique : conseil pour de grandes entreprises au Danemark, en Suède et au Brésil, développement de logiciels sur mesure pour des gens ayant de vrais problèmes plutôt que vendre des produits à la chaîne.

Il y a environ quinze ans, il a pris le chemin inverse de l'histoire habituelle du fondateur. Ayant déjà dirigé une entreprise avec des employés, il a décidé qu'une structure à une seule personne lui convenait mieux, à lui et à sa famille, et il développe et gère des produits logiciels seul depuis lors. La contrainte s'est avérée être la partie utile : quand on est toute l'équipe, une chose doit vraiment avoir de l'importance avant d'être construite.

Le schéma

Les produits commencent tous de la même façon — par quelque chose dans sa propre pile qui fonctionne mais coûte trop cher.

• Ayant besoin d'une gestion fiable du consentement aux cookies et trouvant les options solides mais coûteuses, il a développé Conzent. Cela est devenu une CMP certifiée à part entière, et en juillet 2026, il est passé entièrement en open source avec une version hébergée pour quiconque ne peut pas ou ne devrait pas faire tourner son propre serveur.
• Rien sur le marché ne correspondait à la façon dont il gérait l'e-mail et le support, alors il a développé cela aussi.
• Puis un CRM, Geniziz, au tarif fixe plutôt que par utilisateur — parce que la tarification par utilisateur pousse silencieusement les petites équipes à rationner qui obtient un accès, ce qui va à l'encontre de l'utilité de l'outil.

fastsite est le même mouvement appliqué à la publication, avec un ajout : il a été conçu dès le départ pour les agents plutôt que d'y être adapté après coup. Le serveur MCP n'est pas une intégration greffée sur un tableau de bord. C'est ainsi que le moteur est censé être piloté.

Ce que cela signifie pour le projet

Honnêteté sur les compromis

Un projet à une seule personne n'est pas la même chose qu'une plateforme financée, et prétendre le contraire serait exactement le genre de chose contre laquelle ce site est censé s'élever. Il n'y a pas de support disponible 24h/24 et 7j/7. Les demandes de fonctionnalités sont pesées en regard des heures disponibles d'une seule personne. Si c'est rédhibitoire pour votre organisation, c'est légitime — et la licence signifie que vous pouvez forker le moteur et le maintenir vous-même plutôt que d'être bloqué.

Ce que vous obtenez en échange : pas de calcul par utilisateur, pas d'enfermement propriétaire, pas de feuille de route pilotée par un deck investisseur, et une base de code suffisamment petite pour qu'une seule personne puisse la tenir dans sa tête.