n8n : quels outils peut-on connecter, et comment ?
CRM, messagerie, comptabilité, bases de données… Les trois façons de connecter vos outils avec n8n, ce qui bloque vraiment, et la checklist à valider avant de se lancer.
« Est-ce que n8n se connecte à nos outils ? » C'est la première question que pose presque toute équipe avant d'automatiser quoi que ce soit. La réponse courte : dans la grande majorité des cas, oui. La réponse utile, c'est de savoir comment, car le niveau d'effort n'est pas le même d'un outil à l'autre.
Cet article explique les trois façons de connecter un outil avec n8n, ce qui peut réellement poser problème, et les questions à vérifier avant de lancer un projet.
Les trois façons de connecter un outil
1. Le nœud natif : le plus simple
n8n propose des nœuds dédiés pour de nombreuses applications courantes : messagerie (Gmail, Outlook), tableurs (Google Sheets), messagerie d'équipe (Slack), bases de connaissances (Notion), bases de données (PostgreSQL, Airtable), CRM (HubSpot, Pipedrive, Salesforce), paiement (Stripe), e-commerce (Shopify), ou encore des services d'IA comme OpenAI.
Un nœud natif sait déjà s'authentifier et exposer les actions classiques : lire une ligne, créer un contact, envoyer un message. On le configure dans l'éditeur visuel, sans écrire de code. La liste à jour des nœuds disponibles est dans la documentation officielle de n8n, et elle évolue régulièrement : c'est la référence à consulter, plus fiable qu'une liste figée dans un article.
2. Le nœud HTTP Request : toute API, même sans nœud dédié
Quand un outil n'a pas de nœud natif, mais qu'il expose une API (la plupart des logiciels SaaS récents le font), le nœud HTTP Request permet de l'appeler directement. Il gère les méthodes courantes (GET, POST, PUT, DELETE), les en-têtes, la pagination et plusieurs modes d'authentification : clé d'API, jeton Bearer, OAuth 2.0.
C'est typiquement la voie utilisée pour un outil métier de niche ou un logiciel de comptabilité ou de banque qui propose une API mais pas de nœud : on lit la documentation de l'API, on construit les requêtes, et on obtient le même résultat qu'avec un nœud natif, avec un peu plus de travail de configuration.
3. Les webhooks et le code : pour relier ce que les connecteurs ne couvrent pas
Deux autres briques complètent le tableau :
- Le nœud Webhook permet à un outil externe d'envoyer des données à n8n au moment où quelque chose se produit (un formulaire soumis, un paiement reçu), plutôt que d'interroger l'outil à intervalles réguliers.
- Le nœud Code permet de transformer les données en JavaScript quand les nœuds standards ne suffisent pas : reformater une date, fusionner deux listes, appliquer une règle métier spécifique.
C'est ce qu'on appelle une intégration sur mesure : relier des outils entre eux avec la logique propre à votre activité, là où un simple « quand A arrive, fais B » ne suffit pas.
Quelle méthode pour quel type d'outil ?
| Type d'outil | Exemples | Méthode habituelle |
|---|---|---|
| Messagerie | Gmail, Outlook | Nœud natif |
| Tableurs et bases | Google Sheets, Airtable, PostgreSQL | Nœud natif |
| CRM | HubSpot, Pipedrive, Salesforce | Nœud natif |
| Paiement et facturation | Stripe, Pennylane, Qonto | Nœud natif ou API via HTTP Request, selon l'outil |
| Outil métier récent | Logiciel sectoriel avec API | HTTP Request |
| Outil qui prévient en temps réel | Formulaires, plateformes de paiement | Webhook |
| Logiciel ancien, sans API | ERP ou outil interne ancien | Export de fichiers, base de données, voir ci-dessous |
Cette répartition est indicative : la disponibilité d'un nœud natif change avec le temps, et il faut la vérifier outil par outil au moment du cadrage.
Ce qui bloque vraiment
Dans les projets d'automatisation, le problème est rarement « n8n ne sait pas faire ». Il se situe plutôt ailleurs :
- L'outil n'a pas d'API. Certains logiciels anciens n'exposent rien. On passe alors par ce qu'ils savent faire : exports de fichiers (CSV, dépôt sur un serveur), accès direct à leur base de données quand c'est autorisé, ou envoi d'e-mails structurés qu'on peut lire. Ce sont des solutions de contournement : elles marchent, mais sont moins robustes qu'une API.
- Les droits d'accès. Une API demande souvent un compte avec les bonnes permissions, voire une option à activer par l'éditeur. Il faut quelqu'un qui peut les accorder.
- Les limites d'appels. Beaucoup d'API limitent le nombre de requêtes par minute ou par jour. Un workflow qui traite 10 000 lignes d'un coup doit être pensé pour lisser ses appels.
- La qualité des données. Un champ vide, un numéro de téléphone mal formaté ou un doublon dans le CRM provoquent plus d'erreurs que n'importe quelle limite technique. Mieux vaut le découvrir avant de mettre en production, avec un test sur vos données réelles.
Cinq questions à vérifier avant de se lancer
- Quels outils sont concernés, et qui en est administrateur chez vous ?
- Chacun expose-t-il une API ou un connecteur ? Une recherche dans la documentation de l'éditeur suffit souvent à répondre.
- Quel est le volume de données à traiter par jour ou par mois ?
- Quelles données sont sensibles (données personnelles, bancaires) et où doivent-elles rester ? Le sujet est détaillé dans notre article sur l'hébergement de n8n et des données.
- Que doit-il se passer si une étape échoue ? C'est la question qu'on oublie le plus, et elle fait l'objet d'un article à part : que se passe-t-il quand un workflow n8n échoue.
En résumé
n8n se connecte à une très grande partie des outils utilisés en entreprise, via un nœud natif, l'API de l'outil ou un webhook. Le vrai travail consiste à vérifier, outil par outil, ce qui est possible, à anticiper les limites (droits, volumes, qualité des données) et à prévoir les cas d'erreur.
C'est précisément l'objet de l'audit : cartographier vos outils et vos processus, et vous dire ce qui est automatisable rapidement, ce qui demande plus de travail, et ce qui ne vaut pas la peine.