Comment héberger n8n sur un VPS Hostinger : automatisation B2B sans coût par tâche

La réponse courte

Héberger n8n sur un VPS, c'est faire tourner l'outil d'automatisation sur votre propre serveur, avec un coût de machine fixe au lieu d'une facturation à la tâche. Cela se justifie quand le volume pèse déjà sur la facture Zapier (10 000 tâches coûtent 129 US$ par mois au forfait annuel) ou quand les flux ont beaucoup d'étapes par exécution ; à 10 000 crédits, Make Core reste dans la même fourchette que le VPS. L'architecture de production a quatre pièces : n8n dans Docker, PostgreSQL comme base, un proxy inverse (Nginx ou Traefik) et un certificat SSL sur le sous-domaine. Chez Hostinger, les offres KVM vont de 4 Go à 32 Go de RAM, et la documentation de n8n publie elle-même un test avec une instance de 4 Go qui traite jusqu'à 220 exécutions par seconde. La limite cesse d'être la facture et devient le CPU, la mémoire et la personne qui s'occupe du serveur. Quand l'automatisation commence à porter une règle métier critique, l'étape suivante est une intégration sur mesure, pas davantage de nœuds sur le canevas.

1. Pourquoi la facturation à la tâche pèse en B2B

Make et Zapier facturent le travail que le flux exécute. Sur Zapier, selon la page officielle des tarifs lue le 12 octobre 2026, « a task is counted whenever Zapier successfully completes a unit of work for you » : chaque action terminée compte, tandis que les déclencheurs et les filtres ne comptent pas. Sur Make, chaque action de module consomme un crédit. n8n Cloud facture autrement : par exécution du workflow entier, « regardless of complexity », comme le dit la page des tarifs de n8n.

En exploitation B2B, la différence apparaît vite. Un flux qui reçoit une commande, interroge l'ERP, met à jour le CRM, émet la facture dans le système fiscal et prévient le commercial a cinq actions. Lancé 2 000 fois dans le mois (exemple hypothétique), cela fait 10 000 tâches sur Zapier et au moins 10 000 crédits sur Make. Sur n8n, ce sont 2 000 exécutions. Sur votre VPS, le nombre d'exécutions n'entre pas dans la facture : il entre dans l'usage du CPU et de la mémoire.

Le deuxième problème est ce qui se passe quand la limite est dépassée. Sur Zapier, avec la facturation à la tâche activée, le dépassement coûte 1,25 fois le tarif de base au forfait annuel et 2,5 fois au mensuel, et l'usage s'arrête en arrivant à 3 fois le prix de l'abonnement. Avec l'option désactivée, les automatisations s'arrêtent à la limite jusqu'au cycle suivant. Sur Make, sans crédits, « your scenarios won't continue to run ». Pour qui automatise la facturation ou le service client, s'arrêter le 25 du mois coûte plus cher que l'écart entre les offres.

Si votre doute est encore entre automatiser avec un outil prêt et construire un système, la page systèmes sur mesure et intégrations explique où chaque approche s'arrête.

2. Combien coûte chaque voie, côte à côte

Les chiffres ci-dessous ont été lus sur les pages officielles le 12 octobre 2026. Les unités ne sont pas les mêmes (tâche, crédit, exécution, serveur), et c'est exactement le point : seul le VPS ne grandit pas avec le volume.

Sources : pages officielles des tarifs de Zapier, de Make, de n8n et des VPS Hostinger.

Trois remarques avant de décider sur le seul tableau. D'abord, le prix promotionnel de Hostinger est le total du plan divisé par les mois souscrits, et le renouvellement tous les 2 ans se paie au prix plein ; prévoyez le coût sur le prix de renouvellement. Ensuite, la page d'hébergement n8n de Hostinger annonce des « workflows et exécutions illimités », mais la limite pratique est le matériel : un flux lourd sur une petite machine cale avant qu'un quota n'intervienne. Enfin, la licence payante Business de n8n, même en auto-hébergement, additionne les exécutions de toutes les instances au quota souscrit, selon la page des tarifs de n8n ; le coût fixe vaut pour la version auto-hébergée standard que n8n maintient sur GitHub.

Le point d'équilibre sort du tableau. Sur Zapier, 10 000 tâches coûtent 129 US$ par mois en annuel ; le KVM 2 se renouvelle à R$ 77,99, et comme le dollar vaut plus que le real, le VPS revient moins cher sans calcul de change. Face à Make, c'est différent : à 10 000 crédits, Core coûte 9 US$ par mois, dans la même fourchette que le KVM 2, sans serveur à entretenir. À ce volume, Make ne perd pas face au VPS. Le VPS se justifie pour trois profils : qui paie déjà la tranche de 10 000 tâches de Zapier ou plus ; qui fait tourner des flux à nombreuses étapes, parce que chaque action de module consomme un crédit sur Make ; et qui ne peut pas voir l'automatisation s'arrêter quand les crédits sont épuisés. La page de Make n'affiche le prix que pour 10 000 crédits ; pour des volumes plus grands, vérifiez le tableau avant de décider.

Le coût qui n'apparaît pas dans le tableau est celui de l'exploitation : mettre à jour, sauvegarder, lire le journal quand un webhook échoue. La documentation de n8n elle-même prévient : « n8n recommends self-hosting for expert users. Mistakes can lead to data loss, security issues, and downtime. » Ce temps a un prix, le vôtre ou celui de la personne que vous engagez.

Pour vérifier les offres actuelles d'hébergement et de VPS, ouvrez Hostinger via mon lien d'affiliation. Choisissez l'offre selon les ressources dont votre projet a besoin.

3. Architecture de référence pour la production

Le modèle Hostinger « Ubuntu 24.04 avec n8n » livre n8n préinstallé dans Docker et permet de démarrer en quelques minutes. Pour une exploitation B2B qui va dépendre de l'automatisation, l'architecture recommandée a quatre couches.

n8n dans Docker

L'image officielle est n8nio/n8n et elle écoute sur le port 5678. Le conteneur a besoin d'un volume persistant pour le répertoire de données de n8n : même avec une base externe, la documentation dit que les clés de chiffrement et les journaux de l'instance s'y trouvent. Perdre ce volume sans avoir conservé la clé, c'est perdre l'accès aux identifiants enregistrés.

PostgreSQL plutôt que SQLite

Par défaut, n8n enregistre identifiants, exécutions et workflows dans SQLite, un fichier à l'intérieur du volume. Cela convient au test. En production, PostgreSQL facilite une sauvegarde cohérente, supporte davantage d'écritures simultanées et c'est la base que n8n a utilisée dans le test de performance d'instance unique publié dans la documentation. Le changement se fait par variables d'environnement : DB_TYPE=postgresdb et les variables DB_POSTGRESDB_*.

Proxy inverse avec SSL

n8n ne doit pas être exposé directement sur Internet. Le guide officiel Docker Compose utilise Traefik pour émettre et renouveler les certificats TLS et ne rend n8n accessible qu'en HTTPS. Si le VPS fait déjà tourner Nginx pour d'autres sites, Nginx remplit le même rôle : il reçoit le trafic sur le sous-domaine, termine le SSL et le relaie vers le port local de n8n. Les webhooks d'ERP, de passerelle de paiement et de CRM exigent un HTTPS valide, donc cette couche n'est pas optionnelle.

Sous-domaine et URL de webhook

Le prérequis du guide officiel est un domaine ou un sous-domaine avec un enregistrement A pointant vers l'IP du VPS. n8n doit connaître cette adresse pour générer les bonnes URL de webhook : N8N_HOST, N8N_PROTOCOL=https et N8N_WEBHOOK_URL, variable qui existe à partir de n8n 2.30.0 ; dans les versions antérieures, le nom est WEBHOOK_URL. Sans cela, n8n génère des webhooks avec l'adresse interne et le système externe n'arrive jamais jusqu'à lui.

4. Dimensionnement : de combien de RAM et de CPU n8n a besoin

La documentation de n8n ne publie pas d'exigence minimale de mémoire. Ce qu'elle publie est plus utile : ce qui fait monter la mémoire, et un test de référence. Sur la page des erreurs de mémoire, n8n dit qu'il « doesn't restrict the amount of data each node can fetch and process » et liste les facteurs qui pèsent : volume de JSON, taille des fichiers binaires, nombre de nœuds dans le workflow, usage du nœud Code, exécutions manuelles (n8n copie les données vers l'interface) et workflows qui tournent en même temps.

Le test de performance publié dans la documentation a utilisé une seule instance avec 4 Go de RAM, n8n en mode main et PostgreSQL, et a enregistré jusqu'à 220 exécutions de workflow par seconde. Cela montre que 4 Go font tourner n8n avec de la marge pour des flux légers. Cela ne montre pas le comportement avec de grands tableurs, des PDF ou des appels à des modèles d'IA, là où la mémoire explose.

Source des spécifications et des prix : page officielle VPS de Hostinger. La colonne de profil est ma recommandation à partir des facteurs de mémoire de la documentation n8n, pas une mesure.

Pour une exploitation B2B avec PostgreSQL sur le même serveur, le KVM 2 est le point de départ sensé : la base et le proxy consomment aussi de la mémoire, et la marge évite qu'un flux avec pièce jointe fasse tomber les autres. La FAQ de Hostinger décrit le KVM 2 de la même façon, comme une puissance suffisante pour des applications de taille moyenne comme n8n.

Avant de monter d'offre, ajustez le flux. La documentation de n8n recommande de découper le traitement en lots (l'exemple officiel remplace 10 000 lignes par exécution par 200), d'éviter le nœud Code quand un nœud natif suffit, de ne pas tester un gros volume en exécution manuelle et de découper le workflow en sous-workflows qui renvoient peu de données au principal. Si une erreur de heap apparaît encore, la variable NODE_OPTIONS avec l'option --max-old-space-size augmente la mémoire disponible pour Node.

Quand un serveur ne suffit pas, n8n monte en charge en queue mode : le test multi-instance de la documentation utilise des instances séparées pour les webhooks et les workers, avec Redis. Hostinger propose un modèle de VPS spécifique pour n8n en queue mode.

Si ce dont vous avez besoin, c'est que n8n parle à votre ERP, votre boutique ou votre CRM, c'est de l'intégration sur mesure (webhook, file). Décrivez les systèmes et ce que vous voulez automatiser.

Parler du projet

5. Pas à pas sur un VPS Hostinger

Le chemin ci-dessous suit le guide officiel Docker Compose de n8n, avec PostgreSQL et un proxy devant. Si vous avez utilisé le modèle prêt de Hostinger, les étapes de DNS, de proxy et de validation restent valables.

5.1 Pointez le sous-domaine

Dans le panneau de votre domaine, créez un enregistrement A pour le sous-domaine (par exemple n8n.suaempresa.com.br) avec l'IP du VPS. Vérifiez qu'il a propagé :

dig +short n8n.suaempresa.com.br

La réponse doit être l'IP du VPS. Tant que ce n'est pas le cas, le certificat SSL n'est pas émis.

5.2 Vérifiez Docker et générez les secrets

Le guide officiel demande Docker Engine et Docker Compose installés. Ensuite, créez le dossier du projet et générez la clé N8N_ENCRYPTION_KEY et le mot de passe de la base directement dans le fichier .env, sans afficher les valeurs dans le terminal :

docker --version
docker compose version
mkdir -p ~/n8n && cd ~/n8n
echo "N8N_ENCRYPTION_KEY=$(openssl rand -hex 32)" >> .env
echo "DB_POSTGRESDB_PASSWORD=$(openssl rand -hex 24)" >> .env
chmod 600 .env

Les valeurs n'apparaissent pas dans la sortie du terminal. N'ouvrez le .env que pour copier la clé et le mot de passe dans un coffre de mots de passe, hors du serveur.

5.3 Configurez la base et l'adresse publique

Dans le même dossier, ajoutez au .env les autres variables PostgreSQL. Ce fichier ne va jamais dans un dépôt.

DB_TYPE=postgresdb
DB_POSTGRESDB_HOST=postgres
DB_POSTGRESDB_DATABASE=n8n
DB_POSTGRESDB_USER=n8n

Dans le même fichier, l'adresse publique et le fuseau. Sur une version de n8n antérieure à 2.30.0, remplacez N8N_WEBHOOK_URL par WEBHOOK_URL.

N8N_HOST=n8n.suaempresa.com.br
N8N_PROTOCOL=https
N8N_WEBHOOK_URL=https://n8n.suaempresa.com.br/
GENERIC_TIMEZONE=America/Sao_Paulo
TZ=America/Sao_Paulo

5.4 Démarrez les conteneurs

Partez du docker-compose.yml du guide officiel et ajoutez un service postgres avec son propre volume. Dans le service n8n, conservez le volume de données, pointez env_file vers le .env et ne publiez le port 5678 que sur 127.0.0.1, pour que seul le proxy atteigne n8n.

sudo docker compose up -d
sudo docker compose ps
sudo docker compose logs n8n --tail 50

Les deux conteneurs doivent apparaître comme en cours d'exécution, et le journal de n8n ne doit pas montrer d'erreur de connexion à la base.

5.5 Ajoutez le proxy et le SSL

Si vous utilisez le Traefik du guide officiel, le certificat est émis tout seul au premier accès. Si le VPS a déjà Nginx, créez un site pour le sous-domaine avec ce bloc, qui relaie le trafic et maintient la connexion en temps réel de l'interface n8n :

location / {
    proxy_pass http://127.0.0.1:5678;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
}

Ensuite émettez le certificat et testez l'adresse publique :

sudo certbot --nginx -d n8n.suaempresa.com.br
curl -I https://n8n.suaempresa.com.br

Le curl doit répondre avec le statut 200 en HTTPS, sans avertissement de certificat. Ouvrez l'adresse dans le navigateur et créez le compte propriétaire de l'instance. Dans le pare-feu du VPS, ne laissez ouverts que SSH, HTTP et HTTPS.

6. Exploitation : ce qui maintient n8n en marche

Le faire démarrer est la partie courte. Ce qui sépare une automatisation fiable d'une qui disparaît un vendredi soir, c'est la routine.

Sauvegarde en deux parties. Le dump PostgreSQL garde les workflows, les identifiants chiffrés et l'historique. La N8N_ENCRYPTION_KEY garde la capacité de lire ces identifiants. L'un sans l'autre ne restaure rien. Faites le dump chaque jour hors du VPS et testez la restauration sur une machine propre au moins une fois.

Nettoyage de l'historique d'exécutions. n8n nettoie déjà les anciennes exécutions par défaut : il efface ce qui dépasse 336 heures (14 jours) ou ce qui dépasse 10 000 exécutions conservées, selon la documentation des données d'exécution. Sans cela, la base grossit jusqu'à manquer de disque. Si vous voulez le rendre explicite dans le .env :

EXECUTIONS_DATA_PRUNE=true
EXECUTIONS_DATA_MAX_AGE=336
EXECUTIONS_DATA_PRUNE_MAX_COUNT=10000

Mise à jour avec une fenêtre. Mettre à jour, c'est télécharger la nouvelle image et recréer le conteneur via Compose. Faites-le après la sauvegarde, en dehors des heures où les webhooks des clients arrivent, et lisez les notes de version avant : le seul passage de WEBHOOK_URL à N8N_WEBHOOK_URL montre que le nom d'une variable change entre les versions.

Surveillance minimale. Configurez un workflow d'erreur dans n8n qui prévient l'équipe quand un autre flux échoue, et un moniteur externe qui interroge le sous-domaine de temps en temps. Si le serveur tombe, le moniteur externe est le seul à s'en apercevoir.

Si le même VPS fait tourner d'autres outils, comme des agents d'IA, séparez-les par conteneur et suivez la mémoire totale. L'article sur Claude Code 24/7 sur un VPS Hostinger montre cet autre usage du même type de serveur.

7. Quand n8n ne suffit plus et qu'une intégration sur mesure s'impose

n8n est excellent pour relier des systèmes qui ont déjà une API et un connecteur. Il commence à être le mauvais endroit dans quatre situations.

1. La règle métier habite le canevas. Calcul de prix, politique de crédit ou règle fiscale éparpillés dans des nœuds Code deviennent du code sans test, sans revue et sans versionnement fiable. La règle critique va dans un service propre, et n8n ne fait qu'appeler ce service.
2. Le volume exige de la cohérence. Quand une commande ne peut être traitée deux fois ni se perdre, il faut une file, de l'idempotence et un retraitement contrôlé. On peut monter une partie de cela dans n8n, mais un worker dédié le résout avec moins de pièces.
3. Le système d'en face n'a pas de connecteur. Un ERP ancien, une base locale ou un portail sans API demandent un adaptateur écrit pour ce système. n8n consomme l'adaptateur ; il ne le remplace pas.
4. L'équipe a besoin d'un écran, pas d'un flux. Approbation, contrôle et exception demandent une interface. Si l'automatisation est née pour remplacer un tableur qui se bloque, l'article sur quand remplacer un tableur par un système aide à voir s'il est temps d'avoir un panneau.

Le dessin qui fonctionne en général en B2B est hybride : n8n pour l'orchestration et les intégrations simples, des services propres pour la règle critique et les connecteurs difficiles, le tout sur la même infrastructure que vous contrôlez.

Un prompt prêt pour votre agent

Collez le texte ci-dessous dans l'agent d'IA qui a accès au terminal de votre VPS (en SSH). Il vérifie les prérequis, exécute les étapes de la section 5 dans le même ordre et s'arrête à la première erreur. La connexion au panneau, la création de l'enregistrement DNS et la création du compte propriétaire dans le navigateur restent de votre côté.

Vous allez installer n8n sur un VPS Ubuntu avec Docker, PostgreSQL, un proxy et SSL.

Mes données :
- Sous-domaine : <SOUS_DOMAINE>  (ex. : n8n.suaempresa.com.br)
- IP du VPS : <IP_DU_VPS>
- Proxy : <TRAEFIK_OU_NGINX>

Règles :
- N'imprimez jamais, ne collez jamais dans le chat et n'enregistrez jamais dans un fichier versionné un mot de passe, un jeton, une clé d'API ou un code de connexion.
- Le mot de passe de la base et la N8N_ENCRYPTION_KEY vont uniquement dans le fichier .env du serveur ; dites-moi où ils se trouvent, pas la valeur.
- Montrez chaque commande avant de l'exécuter et arrêtez-vous à l'erreur exacte, avec la sortie.
- N'inventez ni commande, ni version, ni prix. Utilisez seulement les commandes ci-dessous.

Prérequis (à vérifier avant tout) :
1. Exécutez : dig +short <SOUS_DOMAINE>. La sortie doit être <IP_DU_VPS>. Sinon, arrêtez-vous et demandez-moi de créer l'enregistrement A dans le panneau du domaine.
2. Exécutez : docker --version et docker compose version. S'il en manque un, arrêtez-vous et prévenez-moi.

Étapes :
3. Exécutez : mkdir -p ~/n8n && cd ~/n8n. Ensuite, sans afficher les valeurs : echo "N8N_ENCRYPTION_KEY=$(openssl rand -hex 32)" >> .env, echo "DB_POSTGRESDB_PASSWORD=$(openssl rand -hex 24)" >> .env et chmod 600 .env. Ne lancez jamais openssl rand seul et n'affichez jamais le contenu du .env. Rappelez-moi de copier la clé et le mot de passe du .env dans un gestionnaire de mots de passe.
4. Ajoutez au .env : DB_TYPE=postgresdb, DB_POSTGRESDB_HOST=postgres, DB_POSTGRESDB_DATABASE=n8n, DB_POSTGRESDB_USER=n8n.
5. Ajoutez au .env : N8N_HOST=<SOUS_DOMAINE>, N8N_PROTOCOL=https, N8N_WEBHOOK_URL=https://<SOUS_DOMAINE>/, GENERIC_TIMEZONE=America/Sao_Paulo, TZ=America/Sao_Paulo. Si la version de n8n est antérieure à 2.30.0, utilisez WEBHOOK_URL à la place de N8N_WEBHOOK_URL.
6. Construisez le docker-compose.yml à partir du guide officiel Docker Compose de n8n, avec un service postgres et son propre volume ; dans le service n8n, conservez le volume de données, utilisez env_file .env et publiez le port 5678 uniquement sur 127.0.0.1.
7. Exécutez : sudo docker compose up -d, puis sudo docker compose ps et sudo docker compose logs n8n --tail 50. Les deux conteneurs doivent être en cours d'exécution et le journal ne doit pas montrer d'erreur de connexion à la base.
8. Proxy :
   - Si <TRAEFIK_OU_NGINX> est Traefik, utilisez la configuration du guide officiel.
   - Si c'est Nginx, créez le site du sous-domaine avec location / qui relaie vers http://127.0.0.1:5678, proxy_http_version 1.1 et les en-têtes Upgrade et Connection "upgrade". Ensuite exécutez : sudo certbot --nginx -d <SOUS_DOMAINE>.
9. Dans le pare-feu du VPS, laissez ouverts seulement SSH, HTTP et HTTPS.

Étapes qui sont les miennes (prévenez-moi quand vous y arrivez) :
- Créer l'enregistrement A dans le panneau du domaine.
- Ouvrir https://<SOUS_DOMAINE> dans le navigateur et créer le compte propriétaire de l'instance.
- Copier la N8N_ENCRYPTION_KEY et le mot de passe de la base depuis le .env vers un gestionnaire de mots de passe.

Validation finale :
- Exécutez : curl -I https://<SOUS_DOMAINE>. Il doit répondre avec le statut 200 en HTTPS, sans erreur de certificat.
- Exécutez : sudo docker compose ps. n8n et postgres en cours d'exécution.
Ne dites que vous avez terminé que lorsque les deux validations sont passées. Remettez-moi un résumé de ce qui a été fait et de l'emplacement de chaque fichier.

Questions fréquentes

Combien coûte l'hébergement de n8n ?

Le coût principal est le VPS. Sur la page officielle de Hostinger, lue le 12 octobre 2026, le KVM 1 (4 Go de RAM) revient à R$ 29,99/mois et se renouvelle à R$ 59,99/mois ; le KVM 2 (8 Go) revient à R$ 43,99/mois et se renouvelle à R$ 77,99/mois, avec un renouvellement tous les 2 ans. Ajoutez le domaine, que vous avez probablement déjà, et le temps de maintenance. En comparaison, n8n Cloud Starter coûte 20 euros par mois au forfait annuel avec 2 500 exécutions, selon la page des tarifs de n8n.

De combien de Go de RAM n8n a-t-il besoin ?

La documentation de n8n ne fixe pas de minimum. Le test de performance qu'elle publie a utilisé une instance de 4 Go de RAM avec PostgreSQL et a atteint 220 exécutions par seconde. En pratique, 4 Go suffisent pour des flux légers ; avec PostgreSQL et un proxy sur la même machine et des fichiers au milieu du flux, 8 Go donnent de la marge. La consommation monte avec le volume de JSON, les fichiers binaires, le nœud Code et les workflows simultanés.

Puis-je utiliser le modèle n8n de Hostinger en production ?

Oui, comme point de départ. Le modèle « Ubuntu 24.04 avec n8n » livre n8n déjà installé dans Docker. Avant d'y poser un processus client, vérifiez quelle base il utilise, passez à PostgreSQL s'il est en SQLite, configurez le sous-domaine avec SSL, les variables de webhook et la sauvegarde avec la clé de chiffrement.

SQLite ou PostgreSQL ?

SQLite est le défaut de n8n et sert à tester. Pour la production, PostgreSQL : sauvegarde cohérente pendant que n8n tourne, meilleure coexistence avec des exécutions simultanées, et c'est la base du test de performance d'instance unique de la documentation. Il évite aussi le problème de SQLite, qui ne rend pas l'espace disque sans lancer VACUUM.

n8n sur mon VPS a-t-il une limite d'exécutions ?

Pas du côté de la facturation. La limite devient la capacité de la machine : CPU, mémoire et disque. L'exception est la licence payante Business de n8n qui, même en auto-hébergement, additionne les exécutions de toutes les instances au quota souscrit, selon la page des tarifs de n8n.

Conclusion

Héberger n8n sur un VPS Hostinger remplace une facture qui grandit avec le volume par un coût fixe de serveur. Cela se justifie face à Zapier dans la tranche des 10 000 tâches et pour les flux à nombreuses étapes ; face à Make Core à 10 000 crédits le prix est à égalité, et l'avantage est de ne pas s'arrêter quand le quota est épuisé. Le prix de cela, c'est l'exploitation : PostgreSQL, proxy avec SSL, sauvegarde avec la clé de chiffrement et mise à jour avec une fenêtre. Commencez au KVM 2 si la base et le proxy restent sur la même machine, ajustez les flux avant de monter d'offre et sortez la règle métier critique du canevas. Quand l'automatisation se met à porter la facturation, le stock ou le service client, elle mérite le même soin qu'un système sur mesure.

Si ce dont vous avez besoin, c'est l'intégration et des flux automatisés de systèmes sur mesure, avec votre ERP, votre boutique ou votre CRM qui se parlent par webhook et par file, décrivez les systèmes et ce que vous voulez automatiser.

Parler du projet