Make
Airtable
NotionSYNCHRONISER AIRTABLE ET
Prérequis
- Base Airtable « Missions » avec champs statut, budget, dates
- Base Notion « Projets » avec propriétés alignées (statut, lien client)
- Champ ID partagé (ex. `mission_id` UUID ou slug stable)
- Convention : quel outil est maître pour chaque champ
Airtable excelle pour le reporting chiffré et les vues pivot ; Notion porte la doc narrative, les specs et le handover client. Sans sync structurée, les statuts divergent et le PM perd du temps à recouper manuellement. Make orchestre un flux maître-esclave sur des champs limités et des identifiants stables.
Cadrer le périmètre et le sens de flux
Documentez un tableau « Champs synchronisés » : nom, source maître, fréquence, module Make utilisé. Le statut projet est presque toujours maître côté Airtable pour le reporting.
Stockez l’ID Airtable (`recXXXXXXXX`) en propriété Notion `airtable_record_id`. À l’inverse, un champ Airtable `notion_page_id` permet l’upsert ciblé. Sans ID stable, Make recrée des doublons à chaque run.
Décidez du déclencheur : watch Airtable (modification statut) ou planification horaire pour limiter les opérations Notion.
Construire le scénario Make
Chaîne type : Trigger Airtable « Watch records » (filtre vue « En cours ») → Iterator → Notion « Update database item » avec recherche par `airtable_record_id`.
Pour la création initiale : nouveau record Airtable → Notion « Create page » dans la database Projets + écriture de l’ID retour dans Airtable. Router create vs update via module Search Notion.
Ajoutez un error handler (voir make-gestion-erreurs-reprise) : échec Notion API → ligne table Airtable « incidents sync » + Slack #ops.
Gérer conflits et évolutions de schéma
Si un champ Notion esclave est modifié manuellement, la prochaine sync Airtable écrase — documentez cette règle pour l’équipe. Les champs « libres » côté Notion ne doivent pas être mappés.
Lors d’un renommage de statut Airtable, mettez à jour le mapping Make et les vues Notion le même jour. Versionnez le scénario Make (export JSON dans le repo ou Notion).
Testez avec 3 records de test avant activation prod. Vérifiez les caractères spéciaux dans les titres et les relations Notion.
Erreurs fréquentes
Sync bidirectionnelle du statut : oscillation entre « En dev » et « En recette ».
Absence d’ID : pages Notion dupliquées chaque semaine.
Mapper le corps entier des pages Notion : timeouts et quotas API.
Oublier la désactivation du scénario pendant une migration de base.
Ce qu’il faut retenir
Airtable pilote les KPI ; Notion reçoit les champs utiles au wiki.
ID stable obligatoire ; upsert, pas recreate.
Champs limités ; error handler systématique.
Documentation du mapping maintenue à chaque évolution.
FAQ
Seulement si chaque champ a un propriétaire unique et des règles sans chevauchement. En pratique agence, unidirectionnel par champ est plus sûr.
Webhook ou 15 min pour le statut. Quotidien suffit pour des champs peu volatils (lien livrable, % budget).
Make gère le pacing ; évitez de synchroniser des pièces jointes ou rich text complexes. Liez des URLs plutôt que du contenu lourd.