Fin du drag-and-drop ? Quelques réflexions sur l'avenir de Make, Zapier et n8n face à l'IA
« Est-ce que ça vaut encore le coup de payer des centaines d'euros par mois pour des scénarios Make ou Zapier, alors qu'il suffit de demander à une IA d'écrire le script d'intégration et de l'héberger pour beaucoup moins cher ? »
C'est une interrogation très pragmatique. Derrière l'usage du « no-code », une transition technique de fond s'opère. Pour les acteurs historiques de l'automatisation comme pour ceux des CMS, cela représente un défi stratégique majeur.
Voici quelques réflexions sur les limites du modèle économique actuel et l'émergence d'une nouvelle approche.
En résumé : La vraie question n'est plus « quel outil no-code choisir » mais « faut-il encore payer Make ou Zapier alors qu'une IA peut écrire le script d'intégration et l'héberger pour beaucoup moins cher ». Ce qui change : un Zap n'est qu'un bout de code déguisé, et l'IA sait désormais générer ce code et le déployer en serverless, là où ces plateformes facturaient surtout l'interface visuelle. Ce qui résiste encore : la gestion de l'authentification (OAuth 2.0) et le rafraîchissement des tokens, que les outils d'automatisation gèrent très bien. n8n, en open-source auto-hébergeable, tente de faire le pont entre l'approche visuelle et l'orchestration par IA.
L'architecture sous-jacente : une surcouche au Serverless
Pour comprendre l'évolution en cours, il faut analyser techniquement des outils comme Zapier, Make ou Workato. Leur innovation s'est toujours située davantage sur l'interface que sur l'infrastructure.
Sous le capot, ils utilisent exactement la même mécanique que les serveurs classiques des développeurs. Leur seul coup de génie a été de cacher cette machinerie (le code, les serveurs, les requêtes) derrière une belle interface visuelle. Un « Zap », ce n'est finalement rien d'autre qu'un bout de code informatique déguisé avec des blocs à glisser-déposer pour être utilisable par n'importe qui.
Cette abstraction était indispensable pour permettre à des profils non-techniques de créer des flux de données. Aujourd'hui, l'IA manipule couramment le langage des API et le vôtre, ce qui remet en question la nécessité absolue de cette surcouche visuelle.
Le modèle économique face à la réalité des coûts du Cloud
Le modèle d'affaires des leaders actuels repose sur la facturation à la « tâche » ou à l'« exécution ». Historiquement, les entreprises acceptaient ce surcoût lié à l'interface, car l'alternative (mobiliser des ressources de développement) s'avérait plus onéreuse et moins flexible.
L'IA générative vient modifier cet équilibre. Observons la structure des coûts pour un volume de 100 000 tâches par mois (ex : traitement de webhooks de paiement) :
- Via une plateforme d'automatisation classique : ce volume nécessite un abonnement avancé, représentant un budget mensuel allant de 300 € à 500 € selon les plans.
- Via du Serverless pur (AWS Lambda / Cloudflare) avec du code généré par IA : 100 000 requêtes se situent largement dans les quotas gratuits de ces fournisseurs cloud (dont la facturation réelle se chiffre ensuite en centimes).
Ces plateformes traditionnelles s'appuient sur une abstraction de l'infrastructure pour revendre de la puissance de calcul avec des marges très importantes. La capacité de l'IA à générer du code d'infrastructure vient réduire cet avantage concurrentiel.
La prochaine étape : l'approche « Prompt-to-Flow »
Si le modèle basé sur l'exécution montre ses limites à grande échelle, le marché va logiquement se restructurer. Face à l'écart grandissant entre le coût facturé et le coût réel de l'infrastructure, une nouvelle génération d'outils devrait émerger.
Ces nouveaux acteurs se démarquent des interfaces visuelles complexes sur plusieurs axes :
- La transition vers le textuel : au lieu d'assembler des dizaines de modules, l'utilisateur décrit son intention : « Connecte mon Stripe à mon HubSpot. Si le paiement dépasse 1000 €, crée un ticket VIP sur Zendesk, sinon mets à jour le statut du contact ». L'IA se charge de générer et maintenir le code backend sous-jacent.
- Une facturation alignée sur l'infrastructure : ces outils tendent vers une facturation basée sur la ressource réellement consommée (le temps de calcul), en y ajoutant le coût d'usage du modèle d'IA, offrant une alternative plus rationnelle pour les gros volumes.
- Une réversibilité facilitée : les modèles actuels comprennent très bien la logique des exports JSON de Make ou Zapier. Il devient techniquement possible d'automatiser la traduction d'un scénario visuel en code serverless pur, réduisant ainsi la dépendance technique (le vendor lock-in).
Ce qui protège encore le modèle actuel (et le positionnement de n8n)
Ces plateformes historiques sont profondément ancrées dans les processus des entreprises et bénéficient d'une forte inertie. Les migrations prennent du temps.
De son côté, n8n adopte un positionnement intéressant. Avec son modèle open-source (qui permet l'auto-hébergement pour lisser les coûts) et son intégration native de nœuds « Code » et « Agents IA », la plateforme tente de faire le pont entre l'approche visuelle classique et l'orchestration par LLM.
Cependant, il reste un rempart majeur qui justifie l'utilisation de Make ou Zapier : la gestion de l'authentification (notamment OAuth 2.0). Gérer les flux de connexion sécurisés avec des écosystèmes fermés (Microsoft, Salesforce) et assurer le rafraîchissement continu des tokens de sécurité reste complexe dans un script isolé. Les plateformes no-code excellent dans la gestion de cette complexité.
Lorsque les nouveaux outils basés sur l'IA intègreront nativement des gestionnaires d'authentification OAuth fiables, l'un des principaux arguments de rétention des outils traditionnels disparaîtra.
Le choix de l'interface d'assemblage devient secondaire ; l'enjeu principal est la structuration de la donnée et le choix de l'hébergement le plus adapté.
C'est cette approche hybride que nous mettons en place chez Talyco pour les infrastructures data de nos clients. On choisit l'outil en fonction du besoin réel (prototypage rapide, authentification complexe ou flux intensif) plutôt que par habitude.
Ce sujet prolonge directement mes réflexions sur la fin du drag-and-drop côté site web (WordPress, Webflow, Wix). Même mouvement de fond : on passe du geste à l'intention, et la valeur se déplace de l'assemblage manuel vers l'architecture et la structuration de la donnée.
Questions fréquentes
Faut-il arrêter de se former à Make ou Zapier ?
Comprendre la logique algorithmique de ces outils reste pertinent (boucles, conditions, structure de données). En revanche, maîtriser l'interface spécifique d'un outil devient moins prioritaire que d'apprendre à lire une documentation d'API.
Qui assure la maintenance du code si l'on migre vers du Serverless ?
C'est le défi que relèvent les nouveaux acteurs du marché. Plutôt que de fournir uniquement du code, ils proposent des environnements capables de détecter les changements d'API et de proposer des ajustements automatiques via des agents IA, limitant ainsi l'intervention manuelle.
Pourquoi l'IA facilite-t-elle l'accès au Serverless ?
Auparavant, le déploiement sur une infrastructure cloud exigeait une bonne maîtrise technique (gestion d'environnement, ligne de commande, syntaxe parfaite). Aujourd'hui, les modèles de langage peuvent générer la logique métier, structurer le déploiement et guider l'utilisateur pas à pas, abaissant considérablement la barrière à l'entrée.
Je construis le produit et l'infra data de Talyco. J'écris ici sur la tech, l'IA et ce que ça change concrètement.