Peut-on utiliser Notion comme backend de site web ?
Vous avez vu les démos : quelqu’un construit un site portfolio entièrement propulsé par Notion, le déploie sur Vercel, et prétend n’avoir aucun coût d’abonnement. L’attrait est évident : votre client met à jour le contenu dans un outil qu’il connaît déjà, et vous évitez complètement la surcharge de WordPress.
Mais peut-on réellement utiliser Notion comme backend pour des sites web en production ? La réponse est oui, avec des réserves importantes. Cet article détaille l’architecture, les compromis techniques réels, et les cas où cette approche est pertinente par rapport aux situations où elle s’effondre.
Points clés à retenir
- Notion peut servir de CMS headless léger en associant son API à un frontend personnalisé construit avec des frameworks comme Next.js ou Astro.
- Cette approche fonctionne mieux pour les petits sites de contenu, les portfolios, les prototypes et les MVP où l’expérience d’édition compte plus que la scalabilité.
- Les limites strictes de l’API, les URL de fichiers expirantes, la prise en charge incomplète des types de blocs et les webhooks en mode signal uniquement imposent de réelles contraintes techniques.
- La génération de sites statiques avec un cache agressif est essentielle pour éviter une dépendance à l’exécution sur la disponibilité de Notion.
- Si votre projet nécessite un trafic élevé, des données relationnelles complexes, des mises à jour en temps réel ou des garanties strictes de disponibilité, choisissez plutôt un CMS headless dédié.
Ce que signifie réellement « Notion comme backend »
Tout d’abord, distinguons deux choses différentes : Notion Sites (leur fonctionnalité de publication intégrée) et l’utilisation de l’API Notion comme couche de données pour votre propre frontend.
Notion Sites vous permet de publier n’importe quelle page en un clic. C’est simple mais limité : vous êtes bloqué avec le style et la structure de domaine de Notion.
Utiliser Notion comme CMS headless est différent. Vous construisez un frontend personnalisé (généralement avec Next.js, Astro ou similaire), récupérez le contenu depuis l’API Notion, et le rendez comme vous le souhaitez. C’est l’architecture qui propulse des sites comme l’exemple du portfolio de chanteur d’opéra : des pages statiques avec des sections dynamiques extraites d’une base de données Notion en backend.
L’architecture typique
Un site web propulsé par Notion suit généralement ce schéma :
- Le contenu réside dans des bases de données Notion (articles de blog, événements, éléments de portfolio)
- Votre serveur ou processus de build appelle l’API Notion pour récupérer ce contenu
- Une couche de rendu transforme la structure de blocs de Notion en HTML
- La génération statique ou l’ISR met en cache le résultat pour ne pas solliciter Notion à chaque requête
Des bibliothèques comme react-notion-x gèrent l’étape de rendu, convertissant les types de blocs Notion en composants React stylisés. Vous obtenez des encadrés, des blocs de code, des tableaux et des accordéons sans avoir à construire chacun vous-même.
Où cela fonctionne bien
L’utilisation de l’API Notion pour les sites web excelle dans des scénarios spécifiques :
Petits sites de contenu et portfolios. Le calendrier d’événements d’un musicien, la galerie de projets d’un freelance, ou le tableau d’offres d’emploi d’une startup. Les mises à jour de contenu sont peu fréquentes, et la personne qui met à jour ne veut pas apprendre un nouveau CMS.
Prototypes et MVP. Lorsque vous avez besoin de quelque chose en ligne rapidement et que votre modèle de contenu est simple, Notion élimine complètement le backend. Vous pouvez valider une idée avant d’investir dans une infrastructure appropriée.
Outils internes et documentation. Les équipes utilisant déjà Notion peuvent exposer certaines pages en externe sans migrer le contenu.
La véritable proposition de valeur : votre client non technique édite le contenu dans un outil qu’il utilise déjà quotidiennement. Aucune formation requise.
Discover how at OpenReplay.com.
Où cela se complique
Voici où les comparaisons Notion vs CMS traditionnels deviennent honnêtes :
Les limites de taux sont strictes. L’API Notion vous limite à environ 3 requêtes par seconde. Pour la récupération au moment du build, cela signifie qu’un site de 500 pages prend des minutes à reconstruire. Pour la récupération à l’exécution, vous avez besoin d’un cache agressif.
Les URL de fichiers expirent. Les images et fichiers hébergés dans Notion renvoient des URL temporaires (généralement valides pendant une heure). Vous devez soit les proxifier via votre propre serveur, soit les télécharger et les ré-héberger pendant le build.
Certains types de blocs ne sont pas pris en charge. L’API ne renvoie pas tout ce que vous voyez dans Notion. Les blocs synchronisés, certains embeds et certaines vues de base de données peuvent s’afficher incorrectement ou pas du tout.
Les webhooks sont en mode signal uniquement. Les webhooks Notion vous indiquent que quelque chose a changé mais n’incluent pas les données réelles. Vous devez toujours récupérer à nouveau le contenu après avoir reçu une notification.
Pas de requêtes relationnelles. Contrairement à une vraie base de données, vous ne pouvez pas faire de jointures entre bases de données Notion efficacement. Les modèles de contenu complexes deviennent pénibles.
Notion peut tomber en panne. Si vous récupérez à l’exécution et que l’API de Notion est indisponible, votre site casse. La génération statique avec des fallbacks atténue cela, mais c’est toujours une dépendance que vous ne contrôlez pas.
Quand choisir autre chose
Évitez Notion comme backend si vous avez besoin de :
- Sites à fort trafic nécessitant des réponses constantes inférieures à 100 ms
- Données relationnelles complexes (produits avec variantes, catégories imbriquées)
- Mises à jour de contenu en temps réel sans délais de rebuild
- Garanties strictes de disponibilité
- Volumes de contenu importants (milliers de pages)
Pour ces cas, des plateformes CMS headless dédiées ou une simple base de données avec une interface d’administration vous serviront mieux.
Conclusion
Notion fonctionne comme CMS headless léger pour les petits sites, outils et MVP où l’expérience d’édition compte plus que la scalabilité. L’architecture est simple : récupération au moment du build, cache agressif, et gestion des particularités de l’API avec une bibliothèque de rendu.
Ne le confondez simplement pas avec une base de données de production. Connaissez les limites de taux, prévoyez les URL expirantes, et ayez un chemin de migration prêt si votre projet dépasse ses capacités.
FAQ
Notion renvoie des URL de fichiers temporaires qui expirent généralement après une heure. La solution la plus fiable consiste à télécharger toutes les images pendant votre étape de build et à les servir depuis votre propre hébergement ou un CDN. Alternativement, vous pouvez mettre en place un proxy côté serveur qui récupère et met en cache les images à la demande, en les rafraîchissant avant leur expiration.
Notion n'est pas adapté au e-commerce. Il manque de requêtes relationnelles nécessaires pour les produits avec variantes, n'a pas de support transactionnel, et ses limites de taux rendent les mises à jour d'inventaire ou de prix en temps réel impraticables. Un CMS headless dédié ou une base de données associée à une interface d'administration est un bien meilleur choix pour toute boutique.
Si vous récupérez le contenu à l'exécution, votre site cassera lorsque l'API Notion sera indisponible. L'atténuation standard consiste à utiliser la génération de sites statiques pour que les pages soient pré-construites et servies depuis un CDN. L'Incremental Static Regeneration avec des fallbacks stale-while-revalidate aide également en servant du contenu en cache tout en tentant de rafraîchir en arrière-plan.
Vous pouvez implémenter une file d'attente de requêtes avec des délais pour rester dans la limite d'environ trois requêtes par seconde. Mettre en cache localement les réponses de l'API entre les builds pour ne récupérer que les pages modifiées aide également considérablement. Pour les très grands sites, envisagez une couche de données intermédiaire qui se synchronise depuis Notion selon un calendrier plutôt que d'interroger l'API au moment du build.
Understand every bug
Uncover frustrations, understand bugs and fix slowdowns like never before with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.
