Pourquoi nous avons créé Osprey, notre CMS headless

La plupart des CMS headless imposent un choix : un outil à éditeur visuel qui traite le schéma comme un blob de base de données généré une fois, ou une solution maison où chaque chargement de page appelle le CMS en direct. Nous avons créé Osprey, notre CMS headless, pour vous éviter ce choix : un schéma de contenu versionné comme du code et un site livré sous forme de fichiers statiques. Voici ce que le code fait réellement, pas seulement ce que dit la présentation.

Les schémas sont du code, pas un blob de base de données

Dans Osprey, une collection se définit en TypeScript et vit dans le même dépôt que le reste de l'application. Cela signifie le même contrôle de version, la même revue de code et les mêmes types de bout en bout qu'une équipe applique déjà à son code applicatif, étendus au modèle de contenu. L'interface d'administration est un confort pour éditer les entrées ; elle n'est jamais la source de vérité du schéma.

Le contenu est livré au moment du build, pas à chaque requête

Le loader @osprey/astro récupère les entrées publiées depuis le point d'accès REST public d'Osprey pendant le build et les transmet aux content collections d'Astro, sans qu'une clé API soit nécessaire pour cette lecture publique. Le site livré est du HTML statique pur : Osprey est une dépendance de build, pas de runtime. Si un build s'exécute alors que le CMS est lent ou injoignable, le loader conserve les entrées déjà en cache plutôt que de faire échouer le build.

Privé par défaut, invisible en cas de refus

Une collection n'est exposée sur l'API publique que lorsque sa propre règle access.read admet explicitement un appelant anonyme ; tout le reste reste privé. Une requête visant une collection privée, ou un document non publié, renvoie un 404 plutôt qu'une erreur de permission, de sorte que l'API ne confirme jamais qu'une collection privée existe.

Les métadonnées SEO voyagent avec chaque entrée

Chaque entrée renvoyée par l'API publique porte un objet SEO fusionné : le titre, la description, les balises Open Graph et Twitter et l'URL canonique propres à l'entrée sont prioritaires, et les valeurs par défaut du workspace complètent ce qui manque. La même charge utile inclut la directive robots résolue et les liens hreflang vers chaque traduction publiée de cette page, afin qu'un frontend puisse afficher ses balises meta sans reconstruire cette logique.

Un seul déploiement, plusieurs tenants

Osprey est multi-tenant : un seul déploiement peut servir plusieurs sites, chacun limité à son propre tenant. Sur les routes de contenu public, le tenant à lire est déterminé à partir de l'en-tête host de la requête elle-même, et non d'une valeur fournie par le client, de sorte qu'une requête anonyme ne peut pas lire le contenu d'un autre tenant en envoyant un identifiant différent. Chaque requête base de données exécutée par l'API est limitée en interne au tenant, sans dépendre de la mémoire de chaque gestionnaire.

Une mécanique RGPD, pas seulement une promesse

Osprey embarque un point d'accès de droit à l'oubli qui expurge les données personnelles — soumissions de formulaires, acteurs du journal d'audit, comptes utilisateurs — pour un e-mail ou un identifiant donné, limité à un tenant. Un point d'accès d'export distinct produit un manifeste complet du contenu d'un tenant pour les demandes de portabilité des données. Le gestionnaire de consentement aux cookies intégré ne traite que les cookies strictement nécessaires comme toujours actifs et met par défaut chaque autre catégorie sur refusé jusqu'à ce que le visiteur consente, avec un bouton « tout refuser » du même poids visuel que « tout accepter ». Osprey étant auto-hébergé, une équipe peut aussi le faire tourner entièrement sur une infrastructure européenne ; les garanties dédiées de résidence des données dans l'UE font partie du plan enterprise du produit, pas d'une installation par défaut.

Headless par conception

Osprey stocke le contenu et le sert en JSON ; il n'impose aucune apparence à un site. Une équipe peut construire le frontend en Astro, Next.js ou tout générateur de site statique capable d'appeler une API REST, et n'utiliser Osprey que comme couche de contenu sous-jacente. Les offres actuelles, y compris les formules auto-hébergée et enterprise, sont listées sur la page produit Osprey.

Ce qu'il faut faire

• Définissez votre modèle de contenu sous forme de collections TypeScript et versionnez-le avec le code de votre application.
• Définissez une règle access.read explicite sur chaque collection que vous voulez exposer via l'API publique ; laissez-la absente pour garder la collection privée.
• Ajoutez le loader @osprey/astro, ou appelez directement l'API REST, pour que le contenu soit récupéré au moment du build plutôt qu'à chaque requête.
• Ne définissez des champs SEO par entrée que là où ils doivent différer des valeurs par défaut du site, et laissez ces dernières compléter le reste.
• Utilisez les points d'accès intégrés d'export et de droit à l'oubli pour les demandes de portabilité et d'effacement des données plutôt que d'en construire vous-même.
• Si un hébergement exclusivement européen compte pour votre conformité, hébergez Osprey sur une infrastructure européenne ou renseignez-vous sur les garanties de résidence du plan enterprise.

Sources : page produit Osprey, getosprey.dev.