Bases synchronisées Notion : GitHub, Jira et Salesforce

Les bases de données synchronisées Notion importent en continu vos pull requests GitHub, vos tickets Jira et vos comptes Salesforce dans des bases Notion natives, sur lesquelles vous ajoutez vos propres propriétés, vues et automatisations. Reconstruites avec Notion 3.8 le 13 octobre 2026, elles affichent un statut de santé en direct pour chaque synchronisation et sont réservées aux forfaits Business et Enterprise (Enterprise pour Salesforce).

Le sujet est urgent pour une partie des utilisateurs : l’ancienne intégration Jira a cessé de se mettre à jour le 30 octobre 2026, comme les anciennes synchronisations GitHub, Asana et GitLab (centre d’aide Notion), ainsi que l’ancienne version de la synchronisation Salesforce. Si vos bases Jira affichent des données figées depuis quelques jours, ce n’est pas un bug. Ce guide détaille la création d’une base synchronisée, les règles à connaître, la migration depuis l’ancienne intégration et deux cas d’usage concrets.

Bases synchronisées Notion : ce qui change avec la version 3.8

Les bases synchronisées existaient avant Notion 3.8, qui les reconstruit. La première génération, lancée en bêta en 2022, synchronisait déjà Jira, GitHub, GitLab et Asana. Cette ancienne version reposait sur une connexion individuelle, avec un jeton utilisateur que Notion décrit lui-même comme moins fiable.

La nouvelle génération repose sur des « synchronisations gérées » (managed syncs). Notion résume ainsi la nouveauté dans ses notes de version : les bases synchronisées sont « plus rapides, plus fiables » et « fonctionnent comme n’importe quelle autre base Notion », ce qui permet d’y ajouter des propriétés, des vues et des automatisations.

Trois sources sont prises en charge nativement :

Asana et GitLab sortent du périmètre géré. Pour GitLab, Notion recommande de reconstruire la synchronisation avec un Notion Worker, son environnement de code personnalisé ; pour Asana, il renvoie vers son guide de connexion Asana. À mon avis, c’est un recul pour les équipes non techniques qui utilisaient la synchronisation GitLab sans écrire une ligne de code.

Un point de vocabulaire, pour éviter la confusion : une base synchronisée n’a rien à voir avec les blocs synchronisés, qui dupliquent un contenu entre plusieurs pages Notion. Ici, la source de vérité est un outil externe.

Comment créer une base de données synchronisée

Notion propose deux chemins pour créer une base synchronisée : coller un lien dans une page, ou passer par les paramètres de connexion. Le résultat est identique ; le second chemin donne plus de contrôle sur l’historique et les propriétés importées.

Méthode rapide : coller un lien

1. Dans l’outil source, copiez le lien du projet, du dépôt ou de l’espace. Copiez le lien de partage lui-même, pas forcément l’URL de la barre d’adresse.
2. Collez-le dans une page Notion, puis choisissez « Coller en tant que base de données ».
3. Si ce n’est pas déjà fait, connectez votre compte de l’outil source.
4. Pour GitHub, choisissez d’importer les pull requests, les issues, ou les deux.
5. La base apparaît en vue tableau, avec toutes les propriétés de la source ajoutées automatiquement. Elle se remplit en arrière-plan, même si vous quittez la page.

Pour Jira, la commande /jira sync dans une page produit le même effet que le collage d’un lien.

Méthode complète : depuis les paramètres

1. Ouvrez Paramètres, puis Connexions.
2. Ouvrez la connexion GitHub, Jira ou Salesforce depuis le catalogue ou les connexions installées, puis choisissez Database sync.
3. Connectez un compte et terminez l’autorisation.
4. Sélectionnez les dépôts, espaces ou types d’objets.
5. Choisissez la fenêtre d’historique et les propriétés personnalisées à inclure.
6. Cliquez sur Create sync.

Les bases créées par cette méthode apparaissent dans la section Privé de votre barre latérale. Pensez à les déplacer dans un teamspace avant de les partager, et à vérifier les droits au passage.

Choisir la fenêtre d’historique

La fenêtre d’historique est le réglage le plus sous-estimé. Vous pouvez importer tout l’historique disponible, ou seulement les enregistrements modifiés au cours des 30, 90 ou 365 derniers jours.

Cette fenêtre glisse dans le temps, et elle se base sur la date de dernière modification, pas sur la date de création. Une opportunité Salesforce encore ouverte mais non modifiée depuis 91 jours disparaît d’une synchronisation réglée sur 90 jours, avec les valeurs que vous aviez saisies dans vos propriétés Notion. Je recommande de commencer par « tout l’historique » et de réduire seulement si vous atteignez la limite de lignes.

Le statut de santé : lire l’état de chaque synchronisation

Chaque synchronisation affiche désormais un statut en direct, ce qui manquait le plus à l’ancienne version : une synchronisation pouvait s’arrêter sans prévenir. Notion documente six états :

Côté délais, Notion annonce des changements synchronisés « en quelques minutes ou moins ». Jira Sync s’appuie sur des webhooks, avec une resynchronisation complète au plus une fois par jour lorsque la base est consultée. Salesforce est interrogé toutes les minutes par défaut, ce qui reste un rythme de vérification et non une garantie d’affichage en une minute : les limites de requêtes de l’API Salesforce peuvent retarder l’import.

Une base synchronisée Notion : la source écrit, Notion ajoute le contexte, et une suppression à la source efface aussi vos propriétés maison.

Les 4 règles à connaître avant de construire dessus

Une base synchronisée se comporte comme une base Notion, à quatre exceptions près. Les ignorer, c’est risquer de perdre des données saisies à la main.

1. La synchronisation est à sens unique

Les données circulent de l’outil source vers Notion, jamais l’inverse. Les propriétés synchronisées sont en lecture seule : pour changer le statut d’une issue GitHub ou le montant d’une opportunité, il faut passer par GitHub ou Salesforce.

Seule exception : Jira Sync propose une modification bidirectionnelle sur le forfait Enterprise. Elle exige un accès en modification et une authentification Jira individuelle, et ne fonctionne pas sur mobile.

2. Une suppression à la source supprime la ligne dans Notion

Si un élément est supprimé dans l’outil source, sa ligne et ses propriétés disparaissent de la base synchronisée. Selon la documentation des bases synchronisées, les lignes supprimées passent par la corbeille mais ne peuvent pas être restaurées. Vos propriétés Notion ajoutées sur cette ligne (notes, relations, priorités internes) disparaissent avec elle.

À l’inverse, retirer des droits au compte connecté dans la source arrête les mises à jour futures sans effacer les données déjà importées. Pour Salesforce, un enregistrement purgé avant que Notion ne détecte sa suppression peut rester dans la base.

3. Une propriété homonyme n’est pas synchronisée

Si vous créez une propriété Notion qui porte le même nom qu’un champ de l’outil source, ce champ n’est pas synchronisé. Préfixez vos propriétés maison (par exemple « NF – Priorité » ou « Interne – Notes ») pour éviter tout conflit lors d’un ajout de champ côté Jira ou Salesforce.

Pour Salesforce, les noms des propriétés personnalisées viennent des noms d’API, pas des libellés affichés dans Salesforce. Un champ « Segment client » peut donc arriver sous le nom Customer_Segment__c.

4. Les permissions de la source ne sont pas recopiées

Notion ne réapplique pas les règles de partage de GitHub, Jira ou Salesforce à chaque personne qui consulte la base (le guide Salesforce de Notion le précise noir sur blanc). La synchronisation lit les données avec les droits du compte qui l’a créée, puis ce sont les permissions Notion qui décident de qui voit quoi.

Concrètement, un commercial qui n’a pas accès à certains comptes dans Salesforce peut les voir dans Notion si la base est partagée avec lui. Pour les colonnes sensibles (chiffre d’affaires, marge), les permissions par colonne arrivées dans la même version 3.8 sont le bon complément.

Migrer depuis l’ancienne intégration Jira

Depuis le 30 octobre 2026, l’ancienne intégration Jira ne met plus à jour les bases synchronisées. Elles restent dans votre espace de travail, avec leurs données figées à cette date.

Il n’existe pas de migration en un clic : Jira Sync est une connexion distincte, qui crée de nouvelles bases. Vos vues, filtres, relations et propriétés Notion doivent être reconstruits.

Les étapes ci-dessous suivent la page d’aide Jira de Notion. Le centre d’aide décrit aussi une synchronisation gérée lancée depuis Paramètres → Connexions → Jira → Database sync, sans webhook à configurer ; dans cette version, commentaires et pièces jointes ne sont pas synchronisés. Vérifiez quel parcours votre espace de travail affiche avant de commencer.

Différences entre l’ancienne intégration et Jira Sync

Étapes de migration

1. Inventoriez vos bases legacy : listez les bases Jira existantes, leurs vues, leurs propriétés ajoutées et les relations vers d’autres bases (roadmap, sprints, notes de réunion).
2. Obtenez un jeton administrateur Jira : un propriétaire de l’espace de travail Notion doit faire la configuration initiale avec le jeton d’un administrateur Jira. Notion recommande un jeton sans portée (« Create API token », et non « Create API token with scopes ») avec la date d’expiration la plus lointaine possible. Un compte de service Jira convient, à condition qu’il ait déjà accès aux projets visés.
3. Installez Jira Sync : Paramètres → Importer → Jira Sync, puis Get started. Renseignez l’e-mail de l’administrateur Jira, l’URL du site et le jeton.
4. Créez la synchronisation : choisissez le site Jira, puis Create a new sync. Sélectionnez les espaces et les propriétés à synchroniser.
5. Reconstruisez la couche Notion : recréez vos vues, recopiez vos propriétés maison (en évitant les noms homonymes), puis rebranchez vos relations et automatisations sur les nouvelles bases.
6. Archivez les anciennes bases : une fois la nouvelle base vérifiée, renommez l’ancienne en « Archive Jira legacy » pour éviter qu’un collègue ne consulte des données figées.

Une fois la connexion créée, chaque membre doit authentifier son propre compte Jira pour ajouter ou retirer des projets, et ne peut ajouter que les projets auxquels il a accès dans Jira. Le point de vigilance principal reste l’expiration du jeton : s’il expire, la synchronisation casse et des mises à jour peuvent être perdues.

Six étapes pour migrer vers Jira Sync : comptez environ une demi-journée par base complexe.

Cas d’usage 1 : un hub client relié à Salesforce

Notion utilise lui-même ce montage en interne : ses équipes construisent des hubs clients en synchronisant les comptes Salesforce, puis en les reliant aux notes de réunion et aux demandes produit. À mon sens, c’est le cas d’usage le plus parlant de la version 3.8.

Le principe : Salesforce reste la source de vérité commerciale, et Notion devient l’endroit où l’équipe travaille autour du compte. Salesforce détenait 20,7 % du marché mondial du CRM en 2024 selon IDC : pour beaucoup d’équipes, il n’est pas question de le remplacer par un CRM Notion.

Le montage que je recommande :

• Base Comptes (synchronisée) : synchronisez comptes et opportunités dans la même synchronisation, pour que Notion crée automatiquement les relations entre les deux.
• Base Notes de réunion (Notion) : ajoutez une relation vers la base Comptes. Les notes de réunion IA de Notion s’y rangent directement.
• Base Demandes produit (Notion) : chaque demande remontée par un client est reliée à son compte, avec une propriété « Statut produit » maison.
• Propriétés maison sur Comptes : « Interne – Santé du compte », « Interne – Prochaine étape », et un rollup qui compte les demandes produit ouvertes. Le guide des rollups Notion détaille ce calcul.
• Automatisation : quand une opportunité passe à « Closed Won », une automatisation Notion crée la page d’onboarding du client.

Cette approche complète le connecteur IA Salesforce lancé en mars 2026 : le connecteur permet d’interroger Salesforce en langage naturel, la base synchronisée donne une structure persistante sur laquelle construire des vues et des automatisations. Point de vigilance : l’option « Sync all current and future properties » est désactivée par défaut. Cochez les champs personnalisés dont vous avez besoin.

Le hub client Salesforce dans Notion : une base synchronisée au centre, quatre bases et automatisations Notion autour.

Cas d’usage 2 : suivre les PR et issues GitHub dans une roadmap Notion

GitHub compte plus de 180 millions de développeurs selon le rapport Octoverse 2025, dont 36 millions arrivés en un an. Dans les équipes produit, le problème est connu : la roadmap vit dans Notion, l’avancement réel vit dans GitHub, et quelqu’un recopie les statuts à la main chaque semaine.

Avec une base synchronisée, la boucle se ferme :

1. Synchronisez les issues et les PR des dépôts concernés.
2. Activez la correspondance des identités pour relier les comptes GitHub aux profils Notion : la propriété Personne devient filtrable (« Mes PR », « PR de l’équipe front »).
3. Reliez chaque issue à une fonctionnalité de votre base roadmap via une propriété relation.
4. Ajoutez un rollup sur la roadmap : pourcentage d’issues fermées par fonctionnalité, ou nombre de PR encore ouvertes.
5. Affichez le tout en chronologie : la vue Timeline transforme la roadmap en diagramme de Gantt Notion, avec un avancement alimenté par GitHub sans saisie manuelle.

Une automatisation peut ensuite notifier le chef de produit lorsqu’une PR liée à une fonctionnalité prioritaire est fusionnée. Le guide des automatisations Notion détaille les déclencheurs disponibles sur les bases de données.

Ce qu’il manque encore

La version 3.8 règle le problème de fiabilité, pas celui de la couverture. Trois limites pèsent au quotidien :

• Le sens unique : hors Jira Enterprise, impossible de mettre à jour un statut depuis Notion. Pour un flux bidirectionnel, il faut encore passer par Zapier, Make ou Unito.
• Le périmètre Salesforce : pas de leads, de cases ni d’objets personnalisés, ce qui exclut une bonne partie des usages du support client.
• Le prix d’entrée : Business au minimum, Enterprise pour Salesforce. Les indépendants et petites équipes sur le forfait Plus restent sur les intégrations tierces. Le détail des forfaits est dans mon guide des tarifs Notion.

Mon avis

Les bases synchronisées de Notion 3.8 sont la bonne architecture : l’outil métier garde la donnée, Notion apporte le contexte, les relations et les automatisations. Le statut de santé corrige le défaut majeur de la première version, qui pouvait s’arrêter sans que personne ne s’en rende compte.

Si vous utilisiez l’ancienne intégration Jira, la migration n’est plus optionnelle : vos bases sont figées depuis le 30 octobre. Prévoyez une demi-journée par base complexe pour reconstruire les vues et les relations, et profitez-en pour préfixer vos propriétés maison. Pour un premier test, je recommande de commencer par GitHub sur un seul dépôt, avec l’historique complet : c’est la configuration la plus simple et la plus rapide à valider.