Migrer de Make.com vers n8n : la méthode complète (avec Claude Code)

TL;DR : Les outils d'automatisation visuels comme Make.com fonctionnent bien jusqu'à un certain seuil de complexité. Au-delà, ils deviennent un frein. Cet article documente la méthode que j'ai construite pour migrer des workflows Make vers n8n en utilisant Claude Code et le MCP n8n, et pourquoi la migration est une opportunité de ré-architecturer, pas de reproduire. En fin d'article, un guide pas à pas pour reproduire la démarche.

Quand l'outil visuel atteint ses limites

Le scénario qui a déclenché cette méthodologie, c'est un workflow Make.com chez un client e-commerce (suivi de commandes de réparation, B2C et B2B). Deux ans d'ajouts progressifs, et le résultat : 120 modules, 26 routers imbriqués, le workflow dupliqué par langue, 23 envois d'email câblés en dur vers des templates Brevo.

Le scénario Make.com avant migration : 120 modules répartis sur 26 routers. Chaque branche gère une combinaison statut / livraison / langue.

Le scénario fonctionnait. Mais il ne pouvait plus évoluer. Ajouter un nouveau statut de commande impliquait de recâbler des dizaines de branches, et les routeurs imbriqués rendaient la logique illisible.

Le problème n'était pas Make en soi, mais l'inadéquation entre l'outil et la complexité atteinte. Make ne permet pas de reconverger des branches après un routeur, ce qui force la duplication des actions en aval. Pas de bloc de code pour écrire de la logique structurée. Pas de versionnage, donc pas de retour en arrière possible. Et une tarification à l'opération où chaque branche exécutée consomme du budget, même si elle n'aboutit à rien.

C'est un schéma classique : l'outil visuel low-code fonctionne bien pour les cas simples, mais au-delà d'un certain seuil, l'absence d'abstraction (fonctions, variables, boucles) devient un frein structurel.

Reproduire ou ré-architecturer ?

Face à une migration, trois approches possibles.

La reproduction 1:1. Transposer chaque module Make vers un nœud n8n. On change d'outil sans résoudre le problème. 120 modules deviennent 120 nœuds, la dette technique voyage avec.

La refonte progressive. Migrer les workflows simples en 1:1, restructurer les complexes une fois stabilisés dans n8n. En théorie, ça réduit le risque. En pratique, c'est du double travail : migration puis refonte. Et les workflows simples cachent peu de dette, l'effort porte sur les complexes de toute façon.

La refonte radicale. Traiter la migration comme une opportunité de conception. Analyser l'export Make pour extraire la logique métier, puis reconstruire en n8n avec une architecture optimisée.

J'ai choisi la troisième. La communauté n8n converge vers le même constat : migrer d'un outil à un autre sans repenser l'architecture, c'est une opportunité gâchée. L'absence de passerelle d'export entre Make et n8n force de toute façon une reconstruction manuelle.

Ce qui a rendu l'option viable économiquement : l'IA compresse le temps de développement suffisamment pour que le projet passe dans le budget d'un forfait client. Claude Code analyse un fichier JSON de 8 Mo à ~80%. Les 20% restants (cas particuliers métier, sémantique des champs, connaissance du processus) nécessitent l'humain. 80% de compréhension automatique + refonte = le point rentable.

Le système de migration

L'environnement de migration repose sur quatre briques qui travaillent ensemble.

L'instance n8n sur Railway : Postgres, Redis, un service principal et un worker. Tout est en ligne en quelques minutes.

n8n auto-hébergé. Déployé sur Railway en une dizaine de minutes. L'auto-hébergement est nécessaire pour le MCP, les instances n8n cloud ne donnent pas le même niveau d'accès programmatique. Coût fixe serveur, pas de tarification à l'opération.

Claude Code + le fichier JSON. Le point de départ de chaque migration est l'export Make en JSON. Claude Code l'analyse pour cartographier la complexité : combien de routeurs, combien de branches, quels services connectés, où sont les duplications. Il produit ensuite une cartographie des flux de données. L'humain complète avec la connaissance métier.

Le MCP n8n. Le MCP (Model Context Protocol) donne à Claude un accès direct à l'instance n8n. Au lieu de décrire un workflow que l'humain construit manuellement, Claude construit directement : créer un workflow, ajouter des nœuds, câbler les connexions, valider la structure, déclencher un test. Claude passe de conseiller à constructeur. La boucle de retour passe de minutes à secondes.

Les skills cumulatifs. Des skills Claude Code capitalisent les pièges et bonnes pratiques découverts au fil du projet : sélection du bon outil MCP, interprétation des erreurs de validation, schémas d'architecture, syntaxe des expressions n8n, configuration des nœuds par type. Chaque piège documenté pendant une migration fait gagner du temps sur la suivante. La connaissance se capitalise au lieu de se perdre.

Du simple au complexe

L'ordre de migration n'est pas anodin.

Commencer par le workflow le plus simple (dans mon cas, un simple suivi d'erreurs) pour valider la configuration technique : Railway fonctionne, le MCP se connecte, les identifiants sont en place. Passer ensuite à un workflow de complexité moyenne pour valider les intégrations API et les schémas de base. Puis attaquer le plus complexe une fois que l'environnement est rodé.

Sur le projet Goodloop, ça a donné : ERROR (le plus simple, valide la configuration) → LOGX (complexité moyenne, intégrations API) → MAIL1 (le principal, 120 modules) → le reste des workflows en appliquant les schémas déjà stabilisés.

Tous les guides de migration iPaaS convergent sur ce point : commencer par les workflows les moins critiques, monter progressivement. Pas de big-bang.

Chaque migration suit le même cycle : analyser l'export, concevoir l'architecture cible, construire via MCP, documenter, tester de bout en bout, activer.

Les optimisations rendues possibles

Migrer sans ré-architecturer, c'est passer à côté de ce que n8n permet et que Make ne permet pas. Quelques exemples concrets issus du projet.

Remplacer les routeurs par de la logique structurée. Les 26 routeurs imbriqués de Make (qui géraient toutes les combinaisons statut, type de commande, mode de livraison, langue) sont devenus un unique bloc de code JavaScript contenant une table de correspondance. Ajouter une règle = ajouter une entrée dans un objet, pas recâbler des nœuds. Au-delà de 3 branches conditionnelles basées sur des règles métier, le bloc de code est plus maintenable que le routage visuel.

Le même workflow après migration dans n8n : 19 nœuds, un flux lisible de gauche à droite. La logique de routage vit dans un seul bloc de code.

Éviter les doublons dès la conception. Un webhook peut être re-déclenché (nouvelle tentative, re-sauvegarde). Pour éviter les doublons d'emails, chaque envoi crée un enregistrement lié dans Airtable. Avant envoi, le code vérifie si le lien existe déjà. Des liens cliquables dans l'interface pour la traçabilité.

Le monitoring découplé. Un workflow dédié surveille les échecs d'exécution de tous les autres. Indépendant de la logique métier : si un workflow plante, l'alerte n'est pas embarquée dans le workflow qui plante.

Les résultats sur le workflow principal :

Métrique	Make.com	n8n	Réduction
Nœuds	~120	19	84%
Routeurs	26	1 (Code)	96%
Nœuds email	23	1	96%
Updates base de données	29	1	97%

Les pièges à éviter

Quatre points que je sous-estimais au départ.

Les 20% de connaissance métier ne sont pas optionnels. Claude analyse la structure d'un export, identifie les duplications, produit une cartographie des flux. Mais comprendre que "statut 12 avec modification de commande" déclenche un email différent de "statut 12 avec remboursement partiel", ça nécessite la connaissance du processus. L'IA accélère, elle ne remplace pas la compréhension du métier du client.

Le risque destructif de l'IA est réel. Le MCP donne à Claude un accès en écriture à l'instance n8n. Il peut créer, modifier, et supprimer des workflows et des données. Un cas documenté décrit une session où un LLM a supprimé 140 variantes produit en production via MCP. Les garde-fous : exporter le JSON avant toute modification, valider après chaque lot de changements, vérification humaine de chaque opération, instance de développement séparée de la production.

Documenter au fil de l'eau, pas après. Chaque piège MCP, chaque erreur de syntaxe n8n, chaque contournement découvert doit être documenté immédiatement dans un fichier partagé. Sur ce projet, le fichier n8n-lessons.md a évité des heures de redécouverte d'un workflow à l'autre. Les skills Claude Code qui capitalisent ces apprentissages rendent l'accumulation automatique.

Le test de bout en bout reste manuel. L'IA ne gagne pas de temps sur la phase de test. Déclencher le webhook avec des données réelles, vérifier les résultats dans Airtable, Brevo, WooCommerce, surveiller les premières exécutions : c'est de la validation humaine, et c'est non négociable.

Le guide pas à pas

Ce guide détaille chaque étape pour migrer des workflows Make.com vers n8n en utilisant Claude Code et le MCP n8n. Les sections précédentes couvrent le "pourquoi" — ici, c'est le "comment", de l'installation à la gestion du contexte sur la durée.

Le lecteur cible : un builder indépendant qui connaît Make, qui a peut-être déjà touché à n8n, et qui veut intégrer l'IA dans son process de migration. Pas besoin d'être développeur, mais il faut être à l'aise avec un terminal.

1. Ce qu'il faut avant de commencer

Une instance n8n auto-hébergée. Railway est le chemin le plus court : un template prêt à l'emploi, déploiement en dix minutes. Docker en local ou un VPS marchent aussi. L'important : il faut une instance où on peut casser des choses sans stress. n8n cloud fonctionne pour l'usage courant, mais il ne donne pas le même niveau d'accès programmatique — le MCP a besoin de l'API REST complète.
Claude Code installé. C'est le CLI d'Anthropic. On l'installe via npm install -g @anthropic-ai/claude-code et on le lance avec claude dans le terminal.
Un scénario Make.com à migrer. Idéalement, commencer par un simple (moins de 20 modules, logique linéaire). Le complexe viendra après.
Les clés API des services connectés. Airtable, Brevo, WooCommerce, ou tout ce que les workflows utilisent. On en aura besoin pour configurer les credentials dans n8n.
jq installé. Optionnel mais utile pour disséquer les blueprints Make en ligne de commande (brew install jq sur Mac).

2. Installer le MCP n8n et les skills

Le MCP (Model Context Protocol) donne à Claude un accès direct à l'API n8n. Au lieu de décrire un workflow pour que l'humain le construise, Claude crée les nœuds, câble les connexions, valide la structure, déclenche les tests. La boucle de retour passe de minutes à secondes.

Installer le serveur MCP

Le serveur MCP n8n est maintenu par la communauté (czlonkowski/n8n-mcp sur GitHub). Deux façons de l'ajouter :

Option A — via Claude Code directement :

claude mcp add n8n-mcp -- npx -y @czlonkowski/n8n-mcp

Puis configurer les variables d'environnement dans le fichier de config Claude Code (~/.claude/settings.json ou .claude/settings.local.json dans le projet) :

{
  "mcpServers": {
    "n8n-mcp": {
      "command": "npx",
      "args": ["-y", "@czlonkowski/n8n-mcp"],
      "env": {
        "N8N_BASE_URL": "https://mon-instance.up.railway.app",
        "N8N_API_KEY": "n8n_api_..."
      }
    }
  }
}

Option B — via Claude.ai (remote MCP) :

Si on utilise Claude Code connecté à Claude.ai, le MCP peut être configuré comme serveur remote dans les settings de Claude.ai. L'avantage : pas d'installation locale, le serveur tourne côté cloud.

Et le MCP officiel n8n ? Depuis la version 1.88.0, n8n intègre son propre serveur MCP, accessible à https://ton-instance/mcp-server/http. Rien à installer — c'est built-in, avec authentification OAuth2 ou Access Token. Pour l'ajouter à Claude Code :
claude mcp add --transport http n8n-mcp https://<ton-instance>/mcp-server/http \
  --header "Authorization: Bearer <TON_MCP_TOKEN>"
La différence : le MCP officiel expose l'API n8n brute (créer, modifier, lister des workflows). Le MCP communautaire (czlonkowski) ajoute une couche par-dessus : validation de nœuds, recherche dans le catalogue, templates, auto-sanitization. Pour la migration, le MCP communautaire + les skills reste le combo le plus efficace. Mais les deux sont complémentaires — on peut les utiliser en parallèle.

Vérifier que ça marche

Lancer Claude Code dans le terminal et tester :

> Fais un health check de l'instance n8n et liste les workflows existants.

Claude devrait appeler n8n_health_check puis n8n_list_workflows et afficher les résultats. Si ça répond, le MCP fonctionne.

Installer les skills (optionnel mais recommandé)

Les skills sont des fichiers qui encodent les pièges et bonnes pratiques découverts au fil des migrations. Ils évitent de redécouvrir chaque gotcha. Le pack n8n-mcp-skills contient six skills :

n8n-mcp-tools-expert — guide de sélection des bons outils MCP
n8n-validation-expert — interprétation des erreurs de validation
n8n-node-configuration — configuration des nœuds par type et opération
n8n-expression-syntax — syntaxe des expressions n8n (les {{ }})
n8n-workflow-patterns — patterns architecturaux éprouvés
n8n-code-javascript / n8n-code-python — écrire du code dans les Code nodes

Pour les installer, les ajouter dans les plugins activés de ~/.claude/settings.json (voir la doc du pack sur GitHub). Chaque skill se déclenche automatiquement quand Claude travaille sur le sujet correspondant.

Pourquoi les skills comptent : Sans eux, Claude va tomber dans les mêmes pièges que tout le monde — mauvais format de retour des Code nodes, mauvaise syntaxe des expressions, mauvais typeVersion. Avec eux, il démarre avec la connaissance accumulée de dizaines de migrations. C'est la différence entre un stagiaire et quelqu'un qui a déjà fait le boulot.

3. Créer le monorepo de migration

Un seul dossier pour tous les workflows. Pourquoi : un seul CLAUDE.md qui donne le contexte à Claude, des credentials centralisées, des patterns qui s'accumulent d'un workflow à l'autre. Chaque migration enrichit les suivantes.

Structure initiale

ma-migration/
├── CLAUDE.md                        # Contexte projet pour Claude Code
├── shared/
│   ├── credentials.md               # IDs des credentials n8n (pas les secrets !)
│   ├── airtable-schema.md           # Base/table IDs, conventions
│   ├── n8n-patterns.md              # Patterns réutilisables (vide au début)
│   └── n8n-lessons.md               # Pièges découverts (vide au début)
└── workflows/
    └── _template/
        └── README.md                # Checklist de migration

credentials.md stocke les identifiants internes n8n (ex: nmcILmE8dAqXW7ux pour "Mon Airtable"), pas les clés API ni les tokens. Les secrets sont dans n8n lui-même — le fichier ne sert qu'à référencer la bonne credential quand on construit via MCP.

Initialiser :

mkdir -p ma-migration/shared ma-migration/workflows/_template
cd ma-migration && git init

Le CLAUDE.md initial

C'est le fichier que Claude lit au démarrage de chaque session. Il doit contenir :

# CLAUDE.md

## Projet
Migration des workflows Make.com vers n8n pour [nom du client/projet].

## Structure
- `shared/` — credentials, schéma Airtable, patterns, lessons learned
- `workflows/` — un dossier par workflow migré, plus un `_template/`

## Workflows
| Slug | Statut | n8n ID |
|------|--------|--------|
| (à remplir au fur et à mesure) |

## Conventions
- Utiliser les field IDs Airtable, pas les noms (ils peuvent changer)
- Consulter `shared/n8n-lessons.md` avant de construire
- Exporter le JSON après chaque modification significative

Le template de workflow

Le fichier workflows/_template/README.md contient la checklist qu'on copiera pour chaque nouveau workflow. Cinq phases : Setup, Analyse, Design, Build, Activation. Chaque phase a ses tâches à cocher. C'est le garde-fou contre les oublis.

Premier commit

git add -A && git commit -m "Init migration monorepo"

4. Exporter et déposer le blueprint Make

L'export

Le menu d'export dans Make.com : trois points en haut à droite du scénario → Export blueprint.

Dans Make.com : ouvrir le scénario, cliquer sur les trois points en bas à droite du builder, puis "Export Blueprint". On récupère un fichier JSON qui encode toute la logique — modules, routeurs, connexions, paramètres, filtres.

Créer le dossier du workflow

cp -r workflows/_template workflows/mon-workflow
mv ~/Downloads/blueprint.json workflows/mon-workflow/make-blueprint.json

Premier diagnostic avec jq

Avant de lancer Claude, un coup d'œil rapide au JSON permet de mesurer la complexité :

# Combien de modules, et lesquels ?
jq '[.. | .module? // empty] | group_by(.) | map({module: .[0], count: length}) | sort_by(-.count)' \
  workflows/mon-workflow/make-blueprint.json

Sortie type :

[
  { "module": "airtable:ActionUpdateRecord", "count": 12 },
  { "module": "builtin:BasicRouter", "count": 8 },
  { "module": "sendinblue:SendEmail", "count": 6 },
  { "module": "builtin:BasicFilter", "count": 5 },
  { "module": "airtable:SearchRecords", "count": 3 }
]

Ici on voit immédiatement : 12 mises à jour Airtable éparpillées, 8 routeurs, 6 envois d'email. C'est un candidat à la refonte, pas à la reproduction 1:1.

# Combien de routeurs ?
jq '[.. | select(.module? == "builtin:BasicRouter")] | length' \
  workflows/mon-workflow/make-blueprint.json

# Quels services externes ?
jq '[.. | .module? // empty] | map(split(":")[0]) | unique' \
  workflows/mon-workflow/make-blueprint.json

5. Analyser le blueprint avec Claude Code

Ouvrir Claude Code dans le dossier du projet :

cd ma-migration
claude

Puis lancer l'analyse. Exemple de prompt :

Analyse le blueprint Make dans workflows/mon-workflow/make-blueprint.json.

Produis :
1. Un inventaire des modules par type et leur fréquence
2. La liste des routeurs et la logique de chaque branche
3. Les services externes connectés (APIs, bases de données)
4. Les duplications identifiées (modules identiques sur plusieurs branches)
5. Une cartographie du flux de données principal : de l'entrée à la sortie,
   quelles données passent par où

Consulte shared/n8n-patterns.md pour identifier si des patterns connus s'appliquent.

Claude va parcourir le JSON, identifier la structure, et produire un inventaire. Sur un blueprint de plusieurs Mo, ça prend quelques secondes.

Ce qu'on obtient

Un document structuré qui ressemble à ça :

X modules au total, dont Y routeurs
Le flux principal : trigger → lookup → routeur → [branches par statut] → actions
Les duplications : tel module apparaît N fois avec des paramètres quasi identiques
Les services : Airtable (N tables), Brevo (N templates), WooCommerce
Les patterns applicables : "data-driven routing" si >3 branches conditionnelles

Le rôle de l'humain

L'analyse de Claude couvre la structure. Ce qu'elle ne couvre pas : la sémantique métier. "Statut 5 avec mode livraison express" déclenche un email différent de "Statut 5 standard" — ce genre de règle implicite n'est pas dans le JSON, elle est dans la tête du client ou dans une documentation fonctionnelle.

C'est le ratio 80/20 : Claude comprend 80% de la structure, l'humain comble les 20% de sens métier. Ce ratio est ce qui rend la migration économiquement viable.

6. Concevoir l'architecture n8n

Cette étape se fait en plan mode dans Claude Code. Le plan mode empêche Claude de construire quoi que ce soit avant validation humaine. C'est le garde-fou.

Passer en plan mode (taper /plan dans Claude Code), puis :

À partir de l'analyse du blueprint, conçois l'architecture n8n cible pour ce workflow.

Consulte shared/n8n-patterns.md pour les patterns disponibles.

Propose :
- Le nombre de nœuds et leur type
- Le schéma de connexions
- Les choix d'architecture justifiés (routing data-driven vs. nœuds IF, idempotence, etc.)
- Les credentials nécessaires (vérifier shared/credentials.md)
- Une estimation du nombre de nœuds final vs. le nombre de modules Make

La règle de décision

Quand utiliser un Code node "data-driven routing" vs. des nœuds IF/Switch classiques :

Moins de 3 branches conditionnelles, logique simple → nœuds IF/Switch. Plus lisible visuellement, plus facile à maintenir pour quelqu'un qui ne code pas.
Plus de 3 branches, basées sur des règles métier combinatoires → Code node avec table de correspondance. Un objet JavaScript qui mappe les combinaisons (statut, type, langue...) vers les actions. Ajouter une règle = ajouter une entrée, pas recâbler des nœuds.

Le seuil se sent vite : si la logique est illisible à la lecture de l'export Make, c'est qu'il faut simplifier avec du code.

Valider avant de construire

Claude propose un plan. On le relit, on challenge les choix, on ajuste. Quand le plan est validé, on sort du plan mode et on passe à la construction. Pas avant.

7. Construire via MCP

Le plan est validé. Claude construit.

La boucle de construction

La construction ne se fait pas en un seul prompt. C'est itératif :

Construis le workflow dans n8n selon le plan validé.

- Utilise les credentials listées dans shared/credentials.md
- Crée d'abord le workflow vide, puis ajoute les nœuds par lots
- Valide après chaque lot (n8n_validate_workflow)
- Exporte le JSON après chaque étape significative

Claude va :

Créer le workflow (n8n_create_workflow)
Ajouter les nœuds par groupes logiques (n8n_update_partial_workflow)
Câbler les connexions entre nœuds
Valider la structure (n8n_validate_workflow)
Corriger les erreurs de validation
Répéter jusqu'à ce que tout soit propre

Les checkpoints

Après chaque lot de modifications significatif, exporter le JSON :

Exporte le workflow actuel en JSON et sauvegarde-le dans workflows/mon-workflow/n8n-workflow.json

C'est le filet de sécurité. Si quelque chose casse, on peut restaurer.

Les pièges courants

Les gotchas les plus fréquents quand on construit via MCP :

TypeVersion : chaque type de nœud a une version recommandée. httpRequest 4.3, Airtable 2.1, IF 2.3. Utiliser une mauvaise version et les propriétés changent de nom.
Format de retour Code node : le Code node v2 attend [{ json: {...} }] — un tableau d'objets avec une clé json. Oublier le tableau ou la clé et le nœud plante silencieusement.
Expressions n8n : double accolades {{ }}, pas de template literals JS (${}). Écrire {{ $json.field }}, pas ${$json.field}.
Connexions IF : le nœud IF a deux sorties (TRUE index 0, FALSE index 1). Utiliser branch: "true" ou branch: "false" dans les connexions MCP.

Sécurité : Le MCP donne à Claude un accès en écriture à l'instance n8n. Il peut créer, modifier, et supprimer des workflows. Toujours exporter avant de modifier. Vérifier chaque opération. Et si possible, travailler sur une instance de développement séparée de la production.

8. Documenter au fil de l'eau

C'est la partie que tout le monde veut sauter et que personne ne regrette d'avoir faite. Chaque piège découvert et documenté immédiatement fait gagner du temps sur le workflow suivant. La documentation n'est pas un livrable de fin de projet — c'est un outil de travail.

Quoi documenter, et où

Découverte	Fichier cible
Piège MCP ou syntaxe n8n	`shared/n8n-lessons.md`
Pattern architectural réutilisable	`shared/n8n-patterns.md`
ID de credential n8n partagé	`shared/credentials.md`
Nouvelle table/champ Airtable	`shared/airtable-schema.md`
Spécificités du workflow	`workflows/mon-workflow/README.md`
Export JSON du workflow	`workflows/mon-workflow/n8n-workflow.json`

Le README du workflow

Remplir le template copié à l'étape 4 :

Info : ID n8n, trigger, statut
Services connectés : quels services, quelles tables/templates
Architecture : description courte du flux (une phrase + un schéma ASCII si utile)
Notes de migration : choix techniques, workarounds, ce qui a posé problème

Comment le dossier grandit

Après le premier workflow :

ma-migration/
├── CLAUDE.md
├── shared/
│   ├── credentials.md               # 1 credential
│   ├── airtable-schema.md           # 1 base, 2 tables
│   ├── n8n-lessons.md               # 3 gotchas
│   └── n8n-patterns.md              # (encore vide)
└── workflows/
    ├── _template/
    └── mon-premier-workflow/
        ├── README.md
        ├── make-blueprint.json
        └── n8n-workflow.json

Après trois workflows :

ma-migration/
├── CLAUDE.md                         # 3 workflows listés
├── shared/
│   ├── credentials.md               # 4 credentials
│   ├── airtable-schema.md           # 2 bases, 6 tables
│   ├── n8n-lessons.md               # 12 gotchas
│   └── n8n-patterns.md              # 3 patterns identifiés
└── workflows/
    ├── _template/
    ├── workflow-simple/
    │   ├── README.md
    │   ├── make-blueprint.json
    │   └── n8n-workflow.json
    ├── workflow-moyen/
    │   ├── README.md
    │   ├── make-blueprint.json
    │   └── n8n-workflow.json
    └── workflow-complexe/
        ├── README.md
        ├── make-blueprint.json
        ├── n8n-workflow.json
        └── routing-engine.js         # Code node extrait

Le dossier shared/ est devenu une base de connaissances. Les n8n-lessons.md font 12 entrées. Les patterns sont identifiés et nommés. Le troisième workflow se construit plus vite que le premier parce que Claude a accès à tout ce contexte.

9. Tester, activer, basculer

Test de bout en bout

L'IA n'accélère pas cette phase. Il faut déclencher le workflow avec des données réelles et vérifier chaque service en aval :

Le webhook reçoit-il les bonnes données ?
L'email part-il avec le bon template et les bonnes variables ?
La base de données est-elle mise à jour correctement ?
Les cas limites fonctionnent-ils (données manquantes, doublons, statuts inattendus) ?

Claude peut aider à lancer un test via MCP (n8n_test_workflow) et à lire les résultats d'exécution (n8n_executions). Mais l'interprétation des résultats et la validation fonctionnelle restent humaines.

Basculer Make → n8n

Activer le workflow n8n (via MCP ou l'interface n8n)
Désactiver le scénario Make (ne pas le supprimer — le garder comme filet)
Surveiller les premières exécutions dans n8n (onglet Executions)
Si problème, réactiver Make le temps de corriger

Le filet de sécurité

Mettre en place un workflow d'erreurs dès le début : un workflow n8n dédié qui surveille les échecs d'exécution de tous les autres et envoie une alerte (email, Slack, ce qu'on veut). C'est découplé de la logique métier — si un workflow plante, l'alerte ne dépend pas du workflow qui plante.

10. Gérer le contexte sur la durée

La migration d'un seul workflow, ça va. Cinq workflows sur trois semaines, c'est là que la gestion du contexte devient le vrai sujet.

Le CLAUDE.md est un document vivant

Après chaque migration, mettre à jour :

La table des workflows (slug, statut, ID n8n)
Les gotchas spécifiques au projet
Les liens vers les fichiers shared

Claude lit ce fichier à chaque démarrage de session. Un CLAUDE.md à jour, c'est un Claude qui a le contexte dès la première ligne.

L'ordre compte

Commencer par le workflow le plus simple. Il valide la configuration technique (Railway, MCP, credentials). Passer au moyen pour valider les intégrations API. Finir par le complexe, quand l'environnement est rodé et que n8n-lessons.md contient déjà les pièges courants.

Chaque migration enrichit le contexte pour la suivante.

Les skills comme mémoire procédurale

Si les fichiers shared/ sont la mémoire factuelle (quoi), les skills Claude Code sont la mémoire procédurale (comment). Ils encodent les processus : comment valider un nœud, comment écrire une expression, comment structurer un Code node.

La différence en pratique : sans skills, Claude fait des erreurs de syntaxe qu'on corrige manuellement. Avec skills, il sait d'avance que ${} ne marche pas dans les expressions n8n et utilise la concaténation. Le temps gagné est réel.

Le monorepo comme livrable

À la fin du projet, le dossier n'est pas juste un espace de travail — c'est un livrable. Le client récupère :

Les exports JSON de chaque workflow (restaurables)
La documentation de chaque workflow (README)
Les credentials centralisées
Les patterns et lessons learned
Le CLAUDE.md qui permet à n'importe quel développeur de reprendre le projet

Le prochain développeur qui ouvre le dossier peut reprendre le projet sans appeler personne.

Ce que j'en retiens

Migrer n'est pas reproduire. La migration est l'opportunité de ré-architecturer, pas de répliquer la dette.

L'IA comprend 80% d'un blueprint, l'humain comble les 20%. Ce ratio rend viable économiquement des chantiers de refactoring qu'on repousse indéfiniment dans un modèle classique.

Et documenter chaque piège au fil de l'eau est ce qui transforme un projet ponctuel en méthode réutilisable. Les skills et les fichiers d'apprentissages font que le deuxième client coûte moins cher que le premier, le troisième encore moins.

Cet article fait partie de la série "Stack moderne pour builder indépendant". Voir aussi : Obsidian et Claude Code : structurer un knowledge hub freelance.

Un projet digital à lancer ? Discutons de votre projet.

Méthodologie n8n Make.com Claude Code Migration

Un projet en tête ?

Échangeons 30 minutes pour voir comment structurer votre projet digital.

Discutons de votre projet

Article précédent

Obsidian et Claude Code : structurer un knowledge hub freelance