Automatisation n8n Odoo : 3 workflows prêts à déployer

Un lead arrive par formulaire, un commercial le recopie dans Odoo, oublie de l'assigner, et la relance part trois jours plus tard. Ce type de friction ne vient pas d'un défaut d'Odoo mais de l'absence de couche d'orchestration entre l'ERP et les outils qui l'entourent. n8n occupe exactement cette place : il écoute les événements, transforme les données et écrit dans Odoo sans développement spécifique.

Reste à savoir comment relier concrètement les deux systèmes, quelles actions sont réellement supportées, et où se situent les limites avant de basculer sur des appels API bruts.

Pourquoi associer n8n à Odoo

n8n, un orchestrateur open source facturé à l'exécution

n8n est un outil d'automatisation open source qui s'installe aussi bien en cloud géré qu'en auto-hébergement sur un serveur. Son interface repose sur un canevas de nœuds reliés entre eux, chaque nœud représentant une action : lire une base, appeler une API, filtrer, transformer, écrire. Les nœuds Code permettent d'injecter du JavaScript ou du Python quand le no-code atteint ses limites.

La différence la plus structurante avec les plateformes concurrentes tient au modèle de facturation : n8n compte une exécution par déclenchement de workflow complet, indépendamment du nombre de nœuds traversés. Ajouter des étapes de contrôle, de journalisation ou de gestion d'erreur ne renchérit donc pas l'addition, là où une facturation à la tâche pénalise chaque action supplémentaire. Pour une intégration Odoo, qui enchaîne naturellement lectures, conditions et écritures, cette logique change l'économie du projet.

Ce que les automatisations natives d'Odoo ne couvrent pas

Odoo embarque ses propres règles automatisées, ses actions serveur et son moteur de flux de travail. Elles fonctionnent bien tant que l'on reste à l'intérieur du périmètre Odoo : changer un état, remplir un champ, envoyer un email depuis un modèle existant. Dès qu'il faut interroger un service externe, croiser une donnée avec un tableur ou appeler un modèle de langage, l'approche native impose du code Python côté serveur et une mise à jour de module.

n8n déplace cette logique hors de l'ERP, dans un espace versionnable, testable et visible par des profils non développeurs. L'intégration devient un workflow documenté plutôt qu'une action serveur enfouie dans la configuration technique d'Odoo.

Connecter n8n à Odoo : nœud natif, API et déclencheurs

Nœud Odoo natif, JSON-RPC et bascule vers JSON-2

Le chemin le plus court passe par le nœud Odoo intégré à n8n. Il a été entièrement reconstruit en version 2, livrée avec n8n v2.23 le 27 mai 2026, comme l'indique le changelog officiel de n8n : authentification par clé API pour Odoo 19 et supérieur, sélecteurs de ressources recherchables et mapping dynamique des champs lors de la création ou de la mise à jour. Les workflows construits avec la version 1 du nœud restent fonctionnels, ce qui évite une migration en urgence.

Sous le capot, le nœud dialogue avec l'API externe JSON-RPC d'Odoo, disponible depuis la version 8 sur l'endpoint /jsonrpc. Ce protocole est déprécié à partir d'Odoo 19 au profit de JSON-2, qui expose chaque méthode sur une route POST /json/2/<model>/<method> avec une clé API en bearer token. Les intégrations lancées aujourd'hui ont tout intérêt à prévoir cette bascule, plusieurs nœuds communautaires gérant déjà JSON-2 avec attente de disponibilité d'Odoo et retries différenciés selon qu'il s'agit d'une lecture ou d'une écriture.

Webhooks entrants et exécutions planifiées

Deux familles de déclencheurs couvrent la quasi-totalité des besoins. Le webhook expose une URL que n8n écoute en permanence : un formulaire web, une plateforme e-commerce ou une action serveur Odoo y envoient une requête, et le workflow démarre dans la seconde. Côté Odoo, un webhook sortant se configure via une action automatisée qui appelle cette URL au changement d'état d'un enregistrement.

Le déclencheur planifié répond aux besoins de synchronisation et de contrôle : balayer les factures échues chaque matin, comparer des stocks toutes les heures, purger des doublons la nuit. La fréquence mérite d'être calibrée avec soin, car un workflow qui tourne toutes les cinq minutes génère plusieurs milliers d'exécutions mensuelles et peut saturer un quota cloud sans apporter de valeur supplémentaire.

Configurer les credentials Odoo dans n8n

La connexion commence toujours dans Odoo, pas dans n8n. Créez un utilisateur technique dédié, nommé explicitement, avec les seuls droits nécessaires aux modèles manipulés, puis générez une clé API depuis ses préférences de compte. Cet utilisateur isole les actions automatiques dans les journaux et permet de couper l'accès sans toucher aux comptes des collaborateurs.

La documentation des credentials Odoo de n8n décrit deux méthodes d'authentification, par clé API ou par mot de passe, la première étant recommandée, et quatre champs à renseigner : Site URL, Username, API key et Database name. Elle précise aussi un point qui bloque beaucoup de projets en phase de cadrage : l'API externe n'est accessible que sur un plan Odoo Custom, ni sur le plan One App Free, ni sur le plan Standard. Les erreurs de connexion les plus fréquentes viennent ensuite d'un nom de base erroné, d'une URL incluant un chemin superflu ou d'un utilisateur technique dépourvu du droit de lecture sur le modèle ciblé.

Actions supportées et recours au HTTP Request node

Le nœud natif expose un ensemble d'opérations CRUD sur quatre ressources : Contact (get, get many, create new, update), Opportunity (create, get, get many, update), Activity et Custom Resource, cette dernière ouvrant le CRUD sur n'importe quel modèle Odoo. Le filtre Domain Filter accepte un objet JSON que l'API convertit en tuple Python, ce qui reproduit la syntaxe de recherche native d'Odoo directement dans l'interface de n8n.

Tout ce qui sort du CRUD passe par le HTTP Request node : confirmer une commande, valider un transfert de stock, poster une écriture comptable, écrire dans le chatter. Ces méthodes métier s'appellent par le service object de l'API, au même titre que search_read, create, write ou unlink. Des nœuds communautaires encapsulent déjà ces appels de méthode, le suivi du chatter et l'introspection de schéma, utiles quand on ne veut pas maintenir soi-même la couche HTTP.

Trois workflows n8n Odoo à déployer

Du lead entrant à l'opportunité CRM qualifiée

Le workflow démarre sur un webhook alimenté par le formulaire du site. n8n normalise les champs, vérifie l'existence du contact dans Odoo avec une opération Contact get many filtrée sur l'email, puis crée ou met à jour la fiche. L'opportunité est ensuite créée dans le pipeline CRM avec la source, le montant estimé et le commercial attribué selon une règle de routage portée par un nœud Switch.

Un email de suivi part dans la foulée, et une notification atterrit dans le canal commercial. L'attribution automatique mérite une porte de sortie : si aucune règle ne correspond, le lead va dans une file par défaut plutôt que de rester orphelin.

De la commande confirmée à la facture envoyée

Ici, le déclencheur est une action automatisée Odoo qui appelle n8n à la confirmation d'une commande de vente. Le workflow déclenche la création de la facture via un appel de méthode, puis sa validation, deux opérations qui relèvent du HTTP Request node et non du CRUD standard. Le PDF est récupéré via le rapport Odoo correspondant, en binaire, prêt à être attaché.

L'envoi se fait par email ou via l'API WhatsApp Business Cloud selon le canal préféré du client, information stockée dans un champ personnalisé de la fiche partenaire. Un garde-fou s'impose : vérifier que la facture est bien passée à l'état comptabilisé avant d'envoyer quoi que ce soit, sous peine de transmettre un brouillon.

Relance des factures impayées avec garde-fous

Un déclencheur planifié quotidien interroge le modèle des factures clients avec un Domain Filter sur l'état comptabilisé, le solde restant dû et la date d'échéance dépassée. n8n boucle sur les résultats et applique les conditions de filtrage avant tout envoi : montant minimal, nombre de jours de retard, absence de litige, et surtout vérification qu'aucune relance n'est partie dans les derniers jours.

Chaque relance envoyée est journalisée dans Odoo, idéalement sous forme de message dans le chatter de la facture ou d'activité planifiée pour le gestionnaire du compte. Sans cette trace écrite côté ERP, personne ne sait si le client a déjà été contacté, et le workflow devient une machine à relancer en double.

Synchroniser Odoo avec le reste des outils

E-commerce, tableurs et bases collaboratives

La synchronisation WooCommerce ou Shopify avec les stocks Odoo suit toujours le même schéma : un webhook de commande crée le document de vente dans Odoo, et un workflow planifié repousse les quantités disponibles vers la boutique. Le point sensible reste l'identifiant de correspondance entre les deux catalogues, généralement la référence interne, qu'il faut imposer comme clé unique dès le départ.

Google Sheets, Airtable et Notion jouent plutôt le rôle de vitrine ou de zone tampon. Un workflow alimente un tableau de bord commercial depuis les opportunités Odoo, ou remonte dans Odoo des données saisies par une équipe terrain. L'écriture doit rester unidirectionnelle sur chaque champ, sinon les deux systèmes finissent par s'écraser mutuellement.

Notifications métier et enrichissement par modèle de langage

Slack et Microsoft Teams absorbent bien les alertes conditionnelles : opportunité au-dessus d'un seuil, commande bloquée en attente de paiement, rupture de stock sur une référence critique. Mieux vaut filtrer sévèrement en amont dans n8n que d'inonder un canal, auquel cas plus personne ne lit les notifications.

Un modèle de langage branché dans le workflow apporte une couche d'analyse avant écriture dans Odoo : scoring d'un lead à partir du message libre, résumé d'un ticket support avant création de la tâche, rédaction d'une description produit à partir des attributs du catalogue. Les architectures qui tiennent dans la durée séparent strictement la partie IA, qui évalue et raisonne, de la logique déterministe de n8n, qui route, journalise et crée les enregistrements. Un parser de sortie structurée impose un schéma JSON strict au modèle, ce qui évite qu'une réponse mal formée ne parte vers l'API Odoo.

Fiabiliser et sécuriser les workflows en production

Erreurs, tests, débogage et documentation

Chaque workflow critique doit pointer vers un workflow d'erreur dédié, qui capture l'exception, l'horodate et prévient un humain sur un canal surveillé. n8n conserve l'historique des exécutions avec le détail des données entrantes et sortantes de chaque nœud, ce qui permet de rejouer un échec sans le reproduire à l'aveugle. La plupart des erreurs Odoo remontent un message explicite : droit d'accès manquant, champ obligatoire absent, contrainte de validation côté modèle.

Testez vos workflows sur une copie d’Odoo avant de les brancher sur la vraie base, surtout ceux qui créent des factures ou des écritures comptables : une fois validées, elles sont difficiles à supprimer. Notez aussi en tête de chaque workflow ce qui le déclenche, les données Odoo qu’il modifie et la personne responsable côté métier : six mois plus tard, vous n’aurez pas à tout redécouvrir.

Credentials et webhooks exposés

Les credentials Odoo sont stockés chiffrés dans n8n et ne doivent jamais être recopiés dans un nœud Code ou un en-tête en clair. Un webhook public reste une porte ouverte sur votre ERP : protégez-le par un en-tête d'authentification, un jeton dans l'URL ou une restriction d'adresses IP, et validez systématiquement le format des données reçues avant de les écrire dans Odoo. La séparation des utilisateurs techniques par usage permet enfin de révoquer une clé compromise sans arrêter toutes les automatisations.

Coût et hébergement d'une intégration n8n Odoo

Cloud géré, auto-hébergement et localisation des données

n8n se décline en offre cloud et en Community Edition auto-hébergée, gratuite au niveau de la licence et livrée avec le canevas, les nœuds Code, les nœuds IA et les workflows d'erreur. Certaines fonctions restent réservées aux offres payantes, notamment le SSO SAML ou LDAP, la gestion fine des rôles et le versionnage Git. Le cloud facture par paliers d'exécutions mensuelles, l'auto-hébergement se limite au coût du serveur, un VPS modeste suffisant pour la plupart des petites équipes.

Pour une instance Odoo contenant des données clients, l'auto-hébergement sur une infrastructure européenne simplifie la conformité RGPD : les flux ne transitent par aucun service tiers et les journaux d'exécution restent sous votre contrôle. Budgétez surtout le temps humain, la connexion technique étant rarement le poste le plus lourd d'un projet d'automatisation Odoo.

Questions fréquentes sur l'automatisation n8n Odoo

n8n fonctionne-t-il avec Odoo Community ?

Oui, et c'est souvent le cas le plus simple : une instance Community auto-hébergée expose son API externe sans restriction commerciale, il suffit de créer l'utilisateur technique et sa clé API. La contrainte concerne Odoo Online, où l'accès à l'API externe est réservé au plan Custom selon la documentation n8n.

Quelle différence avec Zapier ou Make pour connecter Odoo ?

Zapier et Make fonctionnent exclusivement en cloud et facturent respectivement à la tâche et à l'opération, ce qui rend les workflows multi-étapes coûteux à mesure qu'ils se complexifient. n8n s'héberge où vous voulez, facture à l'exécution du workflow entier et autorise du code arbitraire pour transformer les données, un atout décisif face aux structures de données d'Odoo.

Faut-il savoir coder pour automatiser Odoo avec n8n ?

Un premier workflow de création de contact ou d'opportunité se construit sans écrire une ligne de code. Les notions utiles arrivent ensuite : comprendre la structure JSON des réponses, écrire un Domain Filter et formuler un appel de méthode via le HTTP Request node. C'est le moment où quelques heures de montée en compétence sur l'API Odoo rapportent le plus, bien avant tout ajout d'outil supplémentaire.