Synchronisation Airtable : méthode, choix et limites

À quoi sert la synchronisation Airtable ?

Airtable Sync rend les enregistrements d'une source disponibles dans une table d'une autre base. Une vue source définit les données transmises ; la destination les utilise pour son propre travail.

À sens unique, les champs synchronisés se modifient dans la source. Les champs ajoutés localement restent propres à la destination.

Prenons un référentiel clients tenu par les commerciaux. L'équipe opérationnelle peut en avoir besoin pour rattacher ses projets aux bonnes entreprises. Synchroniser ce référentiel évite de recopier les coordonnées à chaque nouveau dossier, tout en conservant un endroit identifié pour les corriger.

Les forfaits payants actuels proposent Sync avec des limites variables. Vérifiez les droits réels de votre espace de travail, notamment s'il utilise une ancienne formule.

Synchronisation, relation entre tables ou intégration ?

Avant de connecter deux tables, clarifiez ce que vous cherchez à obtenir.

Si ventes et delivery suivent un même processus, une seule base avec des interfaces par rôle peut suffire. Créer une base par équipe ajoute des dépendances qui ne sont pas toujours nécessaires.

Des bases séparées restent pertinentes lorsque les applications ont des responsables, des droits ou des cycles d'évolution réellement différents. La question devient alors : quelles données doivent-elles partager, et qui en reste responsable ?

Comment synchroniser deux bases Airtable ?

1. Définir les données à transmettre

Listez les informations utiles à l'équipe destinataire, le responsable de chaque champ et le traitement des dossiers archivés. Préparez une vue source dédiée plutôt qu'une vue personnelle dont les filtres changent au fil de la journée.

Pour un référentiel clients, l'identifiant, la raison sociale, le responsable de compte et le statut peuvent suffire. Les notes commerciales internes n'ont pas automatiquement leur place dans l'application de production.

2. Activer la synchronisation de la vue source

Depuis la vue grille, ouvrez Share and sync, puis Sync data to another base. Activez Allow data in this view to be synced to other bases. Utilisez Sync this view ou transmettez le lien synchronisable à la personne qui configure la destination.

Ces commandes sont décrites dans la documentation du partage de vues Airtable.

3. Créer la table de destination

Dans la base destinataire, utilisez Add or import, choisissez Airtable base, puis sélectionnez la vue source ou son lien. Contrôlez les champs et les réglages avant de créer la table. La personne qui configure cette destination doit y disposer des droits Creator ou Owner.

Commencez avec un petit ensemble de données dont vous pouvez vérifier le résultat. Une connexion établie ne prouve pas encore que le fonctionnement convient aux utilisateurs.

4. Choisir le comportement des suppressions

Vérifiez si les enregistrements devenus indisponibles dans la source doivent être conservés ou retirés de la destination. Leur retrait peut aussi supprimer des informations locales et leurs liens avec d'autres tables. Un enregistrement filtré hors de la vue source est également concerné.

Pour conserver l'historique des projets, transmettre un statut « Archivé » peut être préférable à un filtre qui fait disparaître le client. Cette conservation doit cependant rester cohérente avec les règles d'accès et de conservation des données de l'entreprise.

5. Tester le parcours de l'équipe destinataire

Vérifiez l'arrivée d'un nouveau client, une correction de raison sociale, un archivage et la sortie d'un enregistrement de la vue source. Contrôlez ensuite que l'équipe retrouve le bon client et peut poursuivre son travail.

Faites aussi un essai avec les droits d'un utilisateur ordinaire. Le compte du concepteur ne permet pas de vérifier à lui seul les accès ou les actions disponibles au quotidien.

Exemple : partager les clients entre CRM et delivery

Voici un exemple pédagogique, pas un résultat client revendiqué. Une agence utilise déjà un CRM commercial et une application de delivery séparée, administrée par l'équipe opérationnelle. Les deux équipes doivent reconnaître les mêmes clients, sans maintenir les mêmes informations.

La sélection de clients du CRM est synchronisée vers une table Clients de la base de delivery. La table locale Projets est reliée à ces clients. Le chef de projet choisit une fiche existante au lieu de ressaisir les coordonnées pour chaque mission.

Les relations entre enregistrements permettent de construire ce modèle dans la base destinataire. Les informations partagées deviennent une référence pour le travail local, sans transformer tous les champs du projet en champs synchronisés.

Prévoyez un identifiant métier si d'autres systèmes doivent également reconnaître le client. Une raison sociale seule constitue une règle de rapprochement fragile : elle peut changer et plusieurs entreprises peuvent porter des noms proches.

L'arrivée d'un client ne doit pas déclencher implicitement la création d'un projet. Cette action doit correspondre à un événement métier, par exemple un engagement accepté. Notre guide des automatisations Airtable explique cette couche d'exécution.

Quand activer une synchronisation bidirectionnelle ?

Le bidirectionnel est utile lorsqu'une équipe doit corriger des champs partagés depuis sa propre base. La synchronisation bidirectionnelle native nécessite Business ou Enterprise Scale et une autorisation de modification des deux côtés.

Limitez les champs modifiables à la responsabilité réelle de l'équipe destinataire. La création et la suppression demandent des réglages supplémentaires ; autoriser la modification ne rend pas toutes les opérations possibles.

Les écritures API dans les champs synchronisés ne sont pas prises en charge par ce mécanisme. Un frontend externe qui écrit via l'API doit donc utiliser un autre parcours d'écriture. Si le delivery consulte seulement le référentiel CRM, un échange à sens unique suffit.

Consolider plusieurs sources avec des définitions cohérentes

La synchronisation multi-source rassemble plusieurs ensembles de données dans une table de destination. Elle est disponible sur les forfaits actuels Team, Business et Enterprise Scale, avec des limites variables.

Elle peut servir à consolider les projets de plusieurs unités opérationnelles. Mais un champ « Livraison » peut désigner une date promise dans une base et une réalisation effective dans une autre.

Définissez les identifiants, les statuts, la correspondance des champs et la provenance avant de considérer l'ensemble comme un tableau de pilotage. Le regroupement de lignes ne démontre pas que deux fiches apparemment similaires représentent la même entité.

Si Sync linked tables est activé pour une synchronisation, Airtable ne permet pas d'y ajouter plusieurs sources. Vérifiez cette compatibilité avant de construire plusieurs bases dépendantes les unes des autres.

Outils externes : vérifier le sens et le parcours d'écriture

Les intégrations natives de synchronisation font entrer les données des outils compatibles dans Airtable à sens unique. Leur disponibilité dépend du connecteur et du forfait. Une modification dans Airtable ne repart donc pas automatiquement vers le calendrier externe.

Google Sheets demande une distinction supplémentaire : son import natif dans Airtable produit une copie ponctuelle. L'automatisation des nouvelles lignes ne maintient pas les modifications ultérieures des lignes existantes.

Pour une connexion continue à un logiciel externe, fixez les règles suivantes avant de sélectionner un outil :

• Quel système fait autorité sur chaque champ ?

• Quel identifiant permet de retrouver le même objet des deux côtés ?

• Comment éviter qu'une mise à jour répétée crée un doublon ?

• Que faire des suppressions et des modifications contradictoires ?

• Comment détecter et reprendre une mise à jour en échec ?

Le guide de l'API Airtable détaille le rôle d'une intégration programmée. La Sync API constitue un mécanisme distinct pour envoyer des données CSV vers Airtable, pas un connecteur bidirectionnel universel.

Diagnostiquer une synchronisation qui ne fonctionne plus

La documentation de dépannage Airtable aide à remonter à la cause. Évitez de remplacer d'emblée une table dont dépendent déjà des relations ou des interfaces.

Régénérer un lien de partage peut affecter toutes ses destinations. Identifiez les bases dépendantes et leurs responsables avant cette opération.

Commencer par un référentiel partagé maîtrisé

Une première synchronisation utile possède un responsable identifié, un périmètre limité, des droits explicites et un comportement de retrait testé. Vérifiez que l'équipe destinataire peut terminer sa tâche réelle, puis étendez le système si d'autres données doivent circuler de la même manière.

Si l'architecture impose des synchronisations circulaires, des recopies répétées ou plusieurs référentiels clients concurrents, réexaminez l'emplacement des données de référence. HyperOps peut vous accompagner pour concevoir et implémenter un outil métier Airtable autour de ces responsabilités.

Questions fréquentes sur la synchronisation Airtable