En résumé. En un an, j’ai changé deux fois d’outil : de ChatGPT à Claude, et de Make à n8n. La première migration m’a pris une heure. La seconde, plusieurs semaines par petits bouts, pour au moins six scénarios reconstruits à la main. La différence ne venait pas des outils. Elle venait de l’endroit où vivait ma logique de travail : mes prompts étaient documentés dans Notion, mes automatisations n’existaient que dans Make.
Longtemps, j’ai cru que ce genre d’écart s’expliquait par la qualité des outils. C’est faux. La différence tenait à un seul facteur, et je ne l’avais même pas décidé consciemment.
C’est de ça que je veux parler, parce que la plupart des TPE que j’accompagne sont exactement dans la situation où j’étais, sans le savoir.
Un workflow IA portable, c’est quoi ?
Un workflow IA portable est un processus de travail dont les éléments essentiels (prompts, briefs, données, étapes de validation) existent en dehors de l’outil qui les exécute. Vous pouvez changer de modèle ou de plateforme sans reconstruire votre méthode.
À l’inverse, un workflow enfermé est un processus dont la logique n’existe que dans l’interface. Le jour où l’interface change, la logique disparaît avec elle.
| Workflow portable | Workflow enfermé | |
|---|---|---|
| Où vit la logique | Dans un document | Dans l’outil |
| Coût d’un changement d’outil | Faible | Reconstruction complète |
| Transmissible à un tiers | Oui | Seulement en montrant l’écran |
| Exemple typique | Prompts archivés dans Notion | Scénario d’automatisation no-code |
Formulé ainsi, ça paraît évident. Dans les faits, presque personne ne travaille comme ça. Moi compris, à moitié.
Deux migrations, deux résultats opposés
Voici les deux cas, avec les chiffres réels.
ChatGPT vers Claude : une heure
Le passage d’un modèle à l’autre s’est fait sans douleur. Mes prompts, mes structures de prompts, mes techniques éprouvées : tout était archivé dans Notion. Je les ai relus, ajustés à la marge, et j’ai repris le travail.
Je voudrais vous dire que j’avais anticipé. Ce serait faux. Quand j’ai commencé à documenter mes prompts dans Notion, je n’avais aucune intention de changer d’IA. Je le faisais pour une raison bien plus banale : je perdais mes bonnes formulations dans des historiques de conversation impossibles à retrouver. J’ai créé cette base pour arrêter de réécrire les mêmes choses.
Ce n’était pas de la stratégie. C’était du confort. Et c’est ce qui m’a sauvé.
Make vers n8n : plusieurs semaines
Au moins six scénarios à reconstruire, entièrement à la main, étalés sur plusieurs semaines par petits bouts entre deux missions.
La raison est technique et vaut pour tout le monde. Make exporte ses scénarios sous forme de blueprints JSON, un format qui lui est propre. n8n, de son côté, importe et exporte ses propres workflows en JSON. Les deux fichiers portent la même extension et n’ont rien à voir : ni les mêmes modules, ni les mêmes formats de données, ni la même logique de branchement. Des convertisseurs tiers existent, mais ils produisent un brouillon à revérifier, pas une migration. Concrètement, vous rouvrez chaque scénario et vous le redessinez.
Ce qui m’a frappé, ce n’est pas la durée. C’est de constater que je ne savais plus vraiment pourquoi certains scénarios étaient construits comme ça. La logique était dans les modules. Elle n’était écrite nulle part.
Le scénario que je n’ai jamais remonté
Un des six n’a jamais été reconstruit : mon automatisation de veille. Pendant la migration, je me suis rendu compte qu’une IA comme Claude fait désormais ce travail directement, sans chaîne d’automatisation intermédiaire.
C’est le seul bénéfice inattendu de l’histoire. En m’obligeant à ouvrir chaque scénario, la migration m’a servi de tri. Une partie de ce que j’avais automatisé n’avait plus lieu d’être, et je ne m’en serais jamais aperçu si l’outil n’avait pas changé.
La différence n’était pas l’outil. C’était l’endroit où vivait la logique.
Mes prompts vivaient dans Notion. Ils étaient donc portables : un document, du texte, transposable partout. Mes automatisations, elles, vivaient dans Make. Pas dans une documentation, pas dans un schéma. Dans l’outil. Modules, mappings, conditions, connexions : la logique métier était dessinée à l’intérieur d’une interface propriétaire.
Le réflexe qui m’a sauvé d’un côté, je ne l’avais jamais appliqué de l’autre. Sans raison particulière. Juste parce que documenter un prompt m’était utile au quotidien, alors que documenter un scénario ne me servait à rien. Jusqu’au jour où si.
C’est ça, la vraie leçon. Ce n’est pas « documentez tout, on ne sait jamais ». C’est : regardez où vit la logique de votre travail. Si elle ne vit que dans un outil, elle appartient à cet outil.
Trois questions à vous poser cette semaine
Vous n’avez pas besoin d’un audit ni d’une refonte. Vous avez besoin de dix minutes et de trois réponses honnêtes.
1. Si votre outil principal fermait demain, que perdriez-vous exactement ? Pas « je devrais m’adapter » : quoi, concrètement. Vos prompts ? Vos scénarios ? Votre historique de décisions ?
2. Où vivent vos prompts qui fonctionnent ? Si la réponse est « quelque part dans une conversation, je les retrouverai », ils ne sont pas à vous. Ils sont à l’outil.
3. Pouvez-vous expliquer votre processus à quelqu’un d’autre sans ouvrir l’application ? Si la réponse est non, votre processus n’est pas documenté. Il est simplement exécuté.
Ce que j’ai changé depuis
Je n’ai pas de méthode miracle à vous vendre, et je ne vais pas prétendre avoir tout compris avant les autres. J’ai eu de la chance sur un côté, pas sur l’autre.
Ce que j’ai changé : mes automatisations sont désormais décrites dans un document avant d’être construites. Entrées, étapes, sorties, conditions. Un texte, pas un schéma dans une interface. Construire le scénario devient une exécution, pas une conception.
Ça prend vingt minutes de plus au départ. Ça m’aurait fait gagner plusieurs semaines. C’est aussi le premier réflexe que je fais installer en formation IA : décrire le processus avant de le construire.
Questions fréquentes
Peut-on importer directement un scénario Make dans n8n ?
Non. n8n ne propose pas d’import natif des scénarios Make. Les deux plateformes utilisent des formats JSON incompatibles : blueprints côté Make, workflows côté n8n. Des convertisseurs tiers existent, mais leur résultat doit être vérifié et corrigé nœud par nœud. Prévoyez une reconstruction, pas une conversion.
Faut-il éviter les outils no-code comme Make ou n8n ?
Non. Le problème n’est pas l’outil, c’est de confondre l’outil avec le processus. Utilisez ce que vous voulez, mais gardez une description de votre logique métier ailleurs.
Comment documenter un workflow sans y passer des heures ?
Trois lignes suffisent au départ : ce qui entre, ce qui se passe, ce qui sort. Un document texte, un Notion, un Google Doc. La forme importe peu, l’extériorisation oui.
Est-ce que ça vaut le coup pour une TPE avec deux ou trois automatisations ?
Justement, oui. C’est le moment où ça coûte quelques minutes. Avec quinze scénarios, c’est un chantier.
Quel outil d’IA choisir aujourd’hui ?
Mauvaise question. Celle qui compte : que se passe-t-il pour vous si vous devez en changer dans six mois ?
Ce qu’il faut retenir
Changer d’outil n’est pas coûteux en soi. Ce qui coûte, c’est de découvrir le jour du changement que votre méthode n’existait nulle part ailleurs que dans l’outil que vous quittez.
Mes prompts étaient dans Notion par hasard. Mes automatisations étaient dans Make par défaut. Les deux situations relevaient de la même absence de décision : l’une a bien tourné, l’autre non.
Vous n’avez pas besoin d’un plan de migration. Vous avez besoin de savoir où vit votre logique de travail. Si vous n’êtes pas sûr de la réponse, c’est probablement qu’elle vit dans un outil que vous ne contrôlez pas.
Si vous êtes dirigeant de TPE en Normandie et que ces trois questions vous laissent sans réponse claire, prenons vingt minutes. Ce n’est pas un audit, c’est une mise à plat.