Documentation de Notion as Code, produit en alpha fermée, consultée le 3 août 2026 sur l'espace Notion Ambassadors — sans auteur ni date, avec un avertissement recommandant de l'essayer sur un espace de travail neuf et prévenant de changements cassants possibles.

Le principe est l'infrastructure as code appliquée à un espace documentaire : « Instead of having to make individual public API requests, you can describe the final state and we handle updating your workspace to match. » Deux briques : un SDK TypeScript pour décrire l'état voulu, et l'endpoint /v1/infra_as_code pour le déployer.

Instead of having to make individual public API requests, you can describe the final state and we handle updating your workspace to match.

**Notion** — documentation produit publiée sur l'espace public **Notion Ambassadors**. **Aucun auteur nommé , app.notion.com

Le mécanisme qui porte tout est l'indirection par identifiant. Le script ne contient aucun identifiant Notion : il déclare des resourceId choisis par l'auteur. Le premier déploiement retourne une table de correspondance entre ces identifiants logiques et les enregistrements réellement créés ; renvoyée aux appels suivants, elle fait que les mêmes enregistrements sont mis à jour plutôt que recréés.

Trois propriétés en découlent. Le script devient idempotent. Il devient découplé de l'espace de travail — plusieurs tables de correspondance permettent de déployer le même script sur plusieurs espaces. Et comme c'est du code, il admet variables et boucles : l'exemple donné est de construire dix équipes de structure identique en ne changeant que quelques noms.

Le contrat d'API est asynchrone : un POST rend un taskId, que l'on interroge jusqu'à complétion ; la réponse porte les tables de correspondance à persister — l'équivalent d'un fichier d'état.

Deux différences opérationnelles : le produit exige des jetons d'accès personnels et non les jetons de bot habituels, ce qui attribue les actions à une personne plutôt qu'à une intégration ; et la limite de débit tombe à 5 requêtes par minute, un appel étant désormais un lot et non une entité.

Le produit suppose l'agent. Le SDK est présenté comme fait « for you or your coding agent », et le chemin de prise en main consiste à laisser un agent lire le README du SDK. Un descripteur d'état typé est en effet un meilleur outil pour un agent qu'une série d'appels impératifs : l'erreur y est rejouable plutôt que cumulative.

⚠️ Ce qui manque : aucune mention de suppression des éléments retirés du script, aucun mode de prévisualisation avant application, rien sur la concurrence, et aucune date sur une documentation appelée à bouger.