C'EST QUOI ?
TinaCMS est un CMS headless qui stocke le contenu directement dans un dépôt Git, sous forme de fichiers Markdown, MDX, JSON ou YAML. Il ajoute par-dessus une API GraphQL typée et un éditeur visuel optionnel qui affiche le rendu réel du site pendant l'édition. Aucune base de données propriétaire : les fichiers restent versionnés dans le repo, lisibles et portables même sans Tina.
POURQUOI C'EST INTÉRESSANT ?
- Le contenu vit dans le repo : chaque modification produit un commit. Historique, branches, pull requests, rollback, review : l'outillage Git existant s'applique tel quel au contenu éditorial.
- Éditeur visuel en live preview : le formulaire d'édition est affiché à côté du site réel, et les champs sont cliquables directement dans la page rendue. Suffisamment simple pour un rédacteur non technique, sans passer par le code.
- Schéma typé et API GraphQL : les collections et les champs se déclarent dans
tina/config.ts. Tina génère les types TypeScript correspondants et une API permettant de requêter les relations entre documents avec une notation par points (post.author.firstName). - Agnostique côté framework : Next.js, Astro, Hugo, Jekyll et compagnie. Tina se greffe sur le générateur de site existant plutôt que d'imposer le sien, aussi bien en génération statique qu'en rendu serveur.
- Auto-hébergeable : le projet est publié sous licence Apache 2.0 et le backend peut tourner sur sa propre infrastructure. TinaCloud existe pour la version managée, mais reste optionnel.
- Workflow éditorial : édition sur branche, prévisualisation et validation par pull request avant publication, pour les équipes qui veulent un vrai circuit de relecture.
CAS D'USAGE
- Ouvrir l'édition d'un site statique à des non-développeurs sans quitter le workflow Git
- Documentation produit versionnée, relue et validée par pull request
- Blog ou site marketing dont le contenu Markdown doit rester portable et sans verrou
- Migration depuis un CMS SaaS où le contenu est enfermé dans une base distante
- Site multi-contributeurs où chaque publication doit laisser une trace auditable