Node Notion v3 dans n8n : migrer vers les Data Sources sans casser vos workflows

Un workflow n8n qui lit ou écrit dans Notion depuis des mois, sans y toucher, peut s'arrêter de fonctionner sans qu'aucune ligne de code n'ait changé de votre côté. La cause n'est pas n8n : c'est Notion qui a fait évoluer en profondeur la structure de ses bases de données, au point de casser la compatibilité de l'ancien node. n8n a répondu avec une v3 du node Notion, compatible avec cette nouvelle API — mais migrer un workflow existant demande de comprendre ce qui a changé, pas seulement de mettre à jour un numéro de version.

Pourquoi vos workflows Notion risquent de casser sans prévenir

Historiquement, une base de données Notion n'avait qu'une seule source de contenu : son identifiant (database_id) suffisait à tout désigner sans ambiguïté. Notion a introduit les bases multi-sources (multi-source databases) : une même base peut désormais regrouper plusieurs sources de données distinctes, chacune avec son propre identifiant. Ce changement, arrivé avec une nouvelle version de l'API Notion, n'est pas rétrocompatible avec l'ancienne façon d'interroger une base par son seul database_id.

Le problème a été signalé publiquement dans le dépôt GitHub de n8n : dès qu'une base Notion passe en multi-source, créer une page, la lire ou écrire une propriété de relation avec l'ancien node échoue silencieusement ou renvoie une erreur, l'intégration restant alors pointée sur une version d'API antérieure incompatible avec ce nouveau comportement. Concrètement, un workflow qui tournait sans problème depuis des mois peut cesser de fonctionner du jour au lendemain, non pas parce que vous l'avez modifié, mais parce que la base Notion sur laquelle il s'appuie a changé de structure côté Notion, hors de votre contrôle direct.

Ce que change l'API Notion en pratique

Trois évolutions méritent une attention particulière lors d'une migration :

• database_id ne suffit plus pour interroger ou créer une page dans une base multi-source : il faut désormais désigner une data source précise (data_source_id), une base pouvant en contenir plusieurs.
• Le champ archived qui indiquait qu'une page était supprimée est renommé in_trash — tout node Code ou toute expression n8n qui filtre encore sur archived cesse de fonctionner correctement sans lever d'erreur visible, ce qui en fait un piège particulièrement sournois.
• Le type de bloc transcription est remplacé par meeting_notes ; un workflow qui génère ou lit ce type de bloc spécifique (transcription de réunion synchronisée depuis Notion, par exemple en aval d'un pipeline comme celui décrit dans notre guide sur la transcription et le résumé de réunions avec Whisper) doit être mis à jour en conséquence.

Ce qu'apporte la v3 du node Notion dans n8n

Face à ces changements, n8n n'a pas simplement corrigé la compatibilité : le node Notion a été revu en profondeur.

• Une nouvelle ressource Data Source (opérations Get et Search) permet de lister et sélectionner explicitement la bonne source de données dans une base multi-source, plutôt que de deviner un identifiant.
• Des opérations de lecture et d'écriture en markdown pour les pages et les blocs, qui évitent de reconstruire manuellement la structure de blocs Notion bloc par bloc pour un simple contenu texte.
• Le support des blocs au format JSON brut, utile pour les types de blocs avancés que l'éditeur visuel du node ne couvre pas.
• Le téléchargement de fichiers attachés aux pages d'une base directement depuis le node, sans détour par un appel HTTP Request séparé.
• Un constructeur de blocs réorganisable, qui simplifie la composition de pages complexes avec plusieurs types de blocs imbriqués.
• Le Notion Trigger peut désormais surveiller une data source précise plutôt qu'une base entière — pertinent si une seule des sources d'une base multi-source doit déclencher le workflow.

Migrer un workflow existant sans casser la production

La migration se joue en quelques étapes, dans l'ordre :

1. Repérer les nodes concernés. Cherchez dans vos workflows tous les nodes Notion (opération, trigger) et tout node Code ou expression qui référence archived ou le type de bloc transcription.
2. Vérifier si vos bases sont multi-sources. Si toutes vos bases Notion n'ont qu'une seule source, le risque immédiat est faible ; si l'une d'elles est passée en multi-source, le node doit être reconfiguré avec la bonne data source avant que le workflow ne casse en production.
3. Mettre à jour le node vers la v3 et resélectionner explicitement la ressource Data Source plutôt que de laisser l'ancien identifiant de base en place — la v3 ne devine pas automatiquement laquelle des sources utiliser.
4. Tester en environnement de développement avant de déployer, en suivant le même principe que celui détaillé dans notre guide sur la séparation des environnements dev/prod dans n8n : un workflow Notion modifié mérite une exécution de test complète avant de remplacer la version en production.
5. Versionner le changement, pour pouvoir revenir en arrière rapidement si un cas limite avait été oublié — voir notre guide sur la sauvegarde et le versionnement des workflows n8n avec Git.

Où ça compte le plus : RAG et publication éditoriale

Deux familles de workflows Notion sont particulièrement exposées. D'abord, la synchronisation d'une base de connaissances Notion vers une base vectorielle pour un assistant RAG — décrite dans notre guide RAG avec Notion — où une base de documentation interne passée en multi-source peut faire disparaître silencieusement des pages entières de l'index si le node continue d'interroger l'ancienne source par défaut. Ensuite, un calendrier éditorial piloté depuis Notion, comme celui présenté dans notre article sur la planification de contenus avec Notion et les réseaux sociaux, où une page qui ne remonte plus dans le trigger passe simplement inaperçue jusqu'à ce qu'une échéance de publication soit manquée. Si votre besoin de départ est encore la connexion initiale de Notion à n8n, notre guide de connexion Notion couvre l'authentification et les opérations de base, sur lesquelles ce guide de migration vient se greffer.

Ce n'est pas un cas isolé — pourquoi tester avant de déployer

Ce genre de rupture n'a rien d'exceptionnel dans l'écosystème des API tierces. Une étude de Xavier, Brito, Hora et Valente, présentée en 2017 à la conférence SANER (« Historical and impact analysis of API breaking changes: a large-scale study », voir sur Google Scholar), a analysé plus de 9 000 versions de 317 bibliothèques Java réelles et près de 260 000 projets clients : près de 28 % des changements observés dans ces API cassaient la compatibilité ascendante, souvent motivés par l'ajout de nouvelles fonctionnalités ou une simplification de l'API plutôt que par un choix arbitraire. Le cas Notion s'inscrit dans cette logique — une évolution nécessaire pour permettre les bases multi-sources, au prix d'une rupture pour les intégrations qui s'appuyaient sur l'ancienne structure. La conclusion pratique reste la même quelle que soit l'API concernée : ne jamais supposer qu'une intégration tierce restera figée indéfiniment, et prévoir un test en environnement de développement avant chaque mise à jour de node qui touche à une source de données externe.

Pièges fréquents

• Oublier le Notion Trigger : on pense à migrer les nodes d'action, mais le trigger repose sur le même identifiant de base et casse silencieusement de la même façon.
• Ne pas partager la nouvelle data source avec l'intégration : comme pour l'intégration interne classique, chaque data source doit être explicitement connectée dans Notion, sans quoi l'API renvoie une liste vide même après une migration réussie du node.
• Filtrer encore sur archived dans un node Code : le renommage en in_trash ne lève pas d'erreur, la condition devient simplement toujours fausse — un bug silencieux, le plus difficile à repérer sans test explicite.
• Migrer un workflow de production sans base de test : une base Notion dupliquée pour les essais évite de découvrir un cas limite directement sur les données réelles.

Pour aller plus loin

Cette migration touche particulièrement les workflows de synchronisation documentaire, exactement le type de brique fournie dans le Pack Assistant RAG (119 €), dont le workflow de synchronisation Notion vers base vectorielle bénéficie directement des nouvelles opérations markdown de la v3. Si votre pipeline documentaire combine plusieurs sources (Notion, Google Drive, SharePoint), le Bundle FlowKit Complet (269 € au lieu de 347 € pris séparément) réunit l'ensemble des packs pour couvrir la chaîne complète, de l'ingestion à l'alerte de conformité.