Comment envoyer automatiquement vos données Attio vers Google Sheets ou une base SQL ?

Mis à jour le 24/10/2026

Les rapports natifs d'Attio répondent aux questions courantes. Tôt ou tard, pourtant, la direction veut autre chose : la performance de chaque commercial, un funnel complet, ou un tableau de bord qui croise le CRM avec le reste de l'activité. Il faut alors sortir les données d'Attio, vers Google Sheets, Excel ou une base SQL, sans que personne ne les recopie à la main.

Nous suivrons un seul cas tout au long de cet article : une fintech dont nous avons construit le système Attio depuis zéro. L'activité d'appel de l'équipe remonte sur les records du CRM, et la direction voulait mesurer chaque liste d'appel, commercial par commercial, dans la même vue que le reste du funnel.

La réponse courte

Il existe quatre façons d'envoyer automatiquement vos données Attio ailleurs : recopier toute la base à intervalle régulier par l'API (avec n8n, par exemple), envoyer chaque modification au moment où elle se produit avec un workflow Attio, passer par un outil de synchronisation tiers, ou, sur le plan Enterprise, brancher vos outils d'analyse directement sur Attio grâce aux data connectors. La première est gratuite mais lourde dès que le volume grossit, la deuxième consomme un crédit Attio à chaque envoi, et la quatrième supprime la synchronisation elle-même.

Pourquoi ne peut-on pas envoyer seulement ce qui a changé ?

Pour transférer uniquement les changements, il faudrait demander à l'API « donne-moi les records modifiés depuis une heure ». Or l'API d'Attio ne propose pas cette question. Vous pouvez filtrer sur la date de création d'un record (created_at) ou sur la valeur de ses attributs, mais aucune date de modification n'est documentée comme filtre. Vous êtes donc obligé de tout reprendre, ou bien de réagir à chaque modification au moment où elle a lieu.

Ce constat donne trois logiques, qui restent vraies quel que soit l'outil. Soit vous recopiez tout : la destination est une copie jetable, que l'on vide et que l'on réécrit à chaque passage. Soit vous réagissez à chaque événement : chaque modification déclenche un envoi, et la destination met à jour la bonne ligne, ou la crée si elle n'existe pas encore (c'est l'« insert or update », ou upsert). Soit, enfin, vous lisez la source directement, sans copie du tout.

Comment recopier toute la base avec l'API et n8n ?

C'est la méthode que nous avons mise en place en premier chez la fintech. On construit un workflow n8n par objet Attio, nommé d'après le slug de l'objet, et une feuille Google Sheets par objet, dans un dossier « Database » auquel personne ne touche. Les tableaux de bord vivent dans un autre dossier et importent leurs données depuis ces feuilles.

Chaque workflow tient en six étapes :

1. Un déclencheur planifié (Schedule Trigger). La fréquence se règle objet par objet : chez la fintech, l'objet le plus suivi tournait toutes les 30 minutes, les autres toutes les 2 h 30.
2. Une requête HTTP en POST sur api.attio.com/v2/objects/{slug}/records/query, authentifiée par un token API créé dans Attio et stocké une seule fois comme credential dans n8n. En options, des lots de 50 items espacés de 500 ms.
3. Un éclatement de la réponse (Split Out) : un item par record.
4. Une sélection explicite des attributs (Edit Fields). Vos tableaux de bord ciblent les colonnes par leur position : l'ordre des champs est donc un contrat. Une nouvelle donnée s'ajoute tout en bas de la liste, pour arriver à droite sans rien décaler.
5. Deux branches : l'une vide la feuille (opération Clear) en conservant la ligne d'en-têtes, l'autre attend.
6. Une fusion, puis un ajout des lignes (Append) sous les en-têtes.

Deux points méritent votre attention. D'abord, la requête renvoie 500 records par défaut : au-delà, il faut une boucle de pagination (limit et offset), sans quoi les records en trop disparaissent sans aucune erreur, et vos totaux deviennent faux. Ensuite, ce qui coûte, c'est l'appel à l'API, pas le traitement dans n8n. Si vous ne voulez qu'une partie des records, filtrez donc dans le corps de la requête ; filtrer une fois les données arrivées dans n8n ne fait rien gagner.

Cette méthode ne se désynchronise jamais : un record supprimé dans Attio disparaît de la feuille au passage suivant. En revanche, plus le volume grossit, plus il devient lourd de tout transvaser. Le même principe vaut avec Excel, pour lequel n8n propose aussi une opération Clear. Airtable n'en a pas dans n8n : on y passe plutôt par « Create or Update », un upsert sur l'identifiant du record.

Comment envoyer chaque modification avec un workflow Attio ?

La deuxième méthode se construit dans Attio lui-même. Un workflow démarre sur le déclencheur « Record updated » de l'objet choisi, puis envoie la donnée : soit avec l'app Google Sheets d'Attio (« Find or create row », puis « Update row »), soit avec un bloc « Send HTTP request » vers l'outil de votre choix. C'est un vrai upsert : la ligne du record est retrouvée et mise à jour, ou créée si elle manque. Notez que ce déclencheur ne réagit pas aux valeurs saisies à la création du record : il faut un second workflow sur « Record created ».

Le problème, ce sont les crédits. Dans Attio, chaque bloc qui écrit dans une app connectée ou qui envoie une requête HTTP consomme un crédit. Les plans incluent 250 crédits par mois sur Free, 1 500 sur Plus et 10 000 sur Pro (octobre 2026). Or chaque modification d'un record déclenche un envoi. Une équipe qui modifie 200 records par jour consomme donc environ 6 000 crédits par mois pour ce seul workflow.

Cette méthode convient très bien à une entreprise qui démarre, dont le CRM est rempli à la main et peu modifié. En revanche, dès qu'un agent IA ou une intégration modifie vos records en permanence, elle montre vite ses limites. Chez la fintech, dont le CRM reçoit en continu les données de la plateforme, de l'outil d'appels et des webinaires, chaque écriture aurait déclenché un envoi, et donc un crédit.

Un outil de synchronisation comme SyncPenguin peut-il faire le travail ?

Les outils de synchronisation tiers qui ont un connecteur Attio sont rares. SyncPenguin en fait partie : il synchronise les contacts d'Attio, dans un sens ou dans les deux, avec d'autres applications (Salesforce, HubSpot, Zoho CRM, Outlook et Office 365, Google Contacts, Notion, Shopify, entre autres). Il est facturé au nombre de flux et de mises à jour synchronisées par mois.

En revanche, d'après sa page Attio, il ne vise ni les tableurs ni les bases SQL. C'est donc une bonne solution pour faire parler Attio avec vos autres logiciels (agenda, contacts, stock), surtout si vous avez plusieurs usages de ce type, mais pas pour alimenter un reporting.

Que changent les data connectors SQL d'Attio ?

C'est la nouveauté la plus importante. Attio annonce qu'il « parle SQL » : les jointures, les calculs et les agrégations s'exécutent directement dans Attio. Les data connectors exposent vos données Attio en direct, sur le protocole PostgreSQL, avec des identifiants en lecture seule. N'importe quel outil capable de se connecter à une base PostgreSQL peut donc lire Attio comme une base : Metabase, Looker, Hex ou dbt, par exemple. Attio résume l'idée ainsi : « Skip the sync and go straight to the source. »

Pour le reporting, l'effet est considérable. Il n'y a plus de copie, donc plus de délai, plus de pagination à surveiller et plus de crédits consommés à chaque modification : vos tableaux de bord lisent la source elle-même. Trois limites demeurent toutefois. SQL n'est disponible que sur le plan Enterprise. L'accès est en lecture seule, avec un seul data connector par workspace. Et si vous voulez croiser Attio avec vos autres outils, il vous faut toujours un endroit où ces données se rencontrent, votre outil de BI ou votre propre base SQL. La direction prise par Attio reste claire : le CRM devient une source de données que l'on interroge, et non plus un logiciel dont on exporte des fichiers.

Quelle méthode choisir ?

Si vous êtes sur le plan Enterprise, branchez vos outils d'analyse directement avec un data connector. Sinon, tout dépend du nombre de modifications : un CRM rempli à la main, avec peu de mouvements, se contente d'un workflow Attio ; un CRM alimenté par des intégrations ou des agents IA passe par une copie complète avec n8n, tant que le volume reste raisonnable. Au-delà de plusieurs dizaines de milliers de lignes, il est temps de construire une base SQL, alimentée par les événements d'Attio.

C'est exactement le chemin qu'a suivi la fintech. La copie complète vers Google Sheets a servi en premier, pour construire les tableaux de bord. Ses données alimentent aujourd'hui une base SQL, synchronisée à chaque modification et à chaque suppression, et reliée à un intranet de pilotage. Nous décrivons ces étapes dans Tableur, CRM, base SQL : comment faire grandir la donnée de votre entreprise ?

Questions fréquentes

Pourquoi ne pas mettre à jour seulement les lignes modifiées avec n8n ?

Parce que l'API d'Attio ne permet pas de filtrer sur une date de modification. Il faudrait donc tout lire de toute façon, et une mise à jour ligne par ligne ne détecterait pas les records supprimés. Tant que le volume le permet, vider puis réécrire reste plus simple et plus sûr.

Existe-t-il un node Attio dans n8n ?

Nous passons par un node HTTP Request générique, qui donne accès à toute l'API d'Attio. Des nodes communautaires existent, mais ils ne sont pas maintenus par n8n.

Comment bien structurer Attio avant d'exporter ses données ?

Un export ne vaut que ce que vaut la structure : si vos données sont rangées au mauvais endroit, vos tableaux de bord le seront aussi. Voir Attribut, liste ou objet custom dans Attio : comment choisir ?