Make et l'IA : ce que coûtent vraiment vos automatisations

Un scénario Make qui appelle un modèle de langage coûte rarement ce que son auteur avait prévu. Le dérapage vient du compteur de crédits bien plus que de la facture du modèle : une automatisation qui délègue une décision déclenche beaucoup plus d'appels de modules qu'une automatisation qui suit des règles écrites à la main.

Depuis que le crédit a remplacé l'opération comme unité de facturation de la plateforme, chaque brique qui tourne se compte. Un agent qui hésite en compte plusieurs dizaines. Cet article part de ce compteur, parce que c'est lui qui décide si votre automatisation tient en production ou si elle s'arrête au milieu du mois.

Le raccourci que nous appliquons sur les projets tient en une phrase : garder l'IA dans un scénario déterministe tant que les branches restent énumérables, et ne sortir un agent que lorsque l'entrée devient vraiment imprévisible. La suite donne les chiffres qui justifient ce raccourci, et la configuration pour l'appliquer.

Trois façons de mettre de l'IA dans Make, trois factures différentes

Make propose trois régimes distincts, et les confondre est la première source de mauvaise surprise. Le premier régime est le module IA posé dans un scénario classique : vous appelez un modèle à un endroit précis du flux, il rend un texte, le scénario continue. Le deuxième est la boîte à outils maison de la plateforme, avec ses modules d'extraction de contenu et de recherche web, qui évitent de gérer une clé de fournisseur. Le troisième est l'agent, qui reçoit un objectif, choisit lui-même les outils à appeler et boucle jusqu'à estimer qu'il a terminé.

Ces trois régimes ne se remplacent pas. Le module posé dans un scénario reste prévisible : un passage, un appel, un coût connu à l'avance. La boîte à outils accélère la mise en route, au prix d'un contrôle moindre sur le modèle utilisé. L'agent, lui, transforme une dépense fixe en dépense variable, puisque le nombre d'appels dépend de ce que le modèle décide en cours de route.

Le choix se joue sur la nature de l'entrée. Une facture au format toujours identique, un mail de formulaire, un enregistrement créé par votre propre application : la structure est connue, un module IA dans un scénario suffit à en extraire les champs. Une demande client rédigée en texte libre qui peut porter sur dix sujets, un document dont vous ignorez le format, une conversation à plusieurs tours : énumérer les branches à l'avance devient impossible, et l'agent gagne sa place. Make a raison de présenter ces niveaux comme un continuum plutôt que comme trois produits concurrents.

Un quatrième cas existe depuis que la plateforme laisse des systèmes IA externes appeler vos scénarios, mais il déplace la question plutôt qu'il ne la tranche : c'est un agent hébergé ailleurs qui décide quand déclencher votre automatisation, et chaque déclenchement consomme vos crédits.

Ce qu'une automatisation IA consomme réellement, module par module

Chaque module qui s'exécute coûte au moins un crédit, et un module IA coûte ce crédit plus les jetons consommés. La documentation de Make détaille les cas qui surprennent le plus : un module de déclenchement consomme un crédit à chaque passage, même quand il ne rapporte aucune donnée ; un module de recherche consomme un crédit par exécution, même s'il renvoie cinquante enregistrements ; un itérateur consomme un crédit pour découper le tableau, puis les modules suivants en consomment un par élément.

C'est cette dernière règle qui fait exploser les scénarios mal ordonnés. Placer un module IA après un itérateur qui découpe une liste de trente lignes revient à déclencher trente appels de modèle et trente crédits, plus les jetons de chacun. Le même travail fait en un seul appel, avec la liste entière passée au modèle, coûte un crédit et un appel.

La grille tarifaire ajoute un second effet de levier, celui-là invisible dans l'éditeur. Au 3 août 2026, la page tarifs de Make affiche le plan Core à 9 $ par mois pour 10 000 crédits, le plan Pro à 16 $ pour ces mêmes 10 000 crédits et le plan Teams à 29 $. Le nombre de crédits qu'un scénario consomme ne change pas d'un plan à l'autre, mais leur prix triple entre Core et Teams. Une équipe qui monte sur Teams pour les fonctions de collaboration paie donc son automatisation IA trois fois plus cher, à travail rigoureusement identique. Le plan gratuit plafonne à 1 000 crédits par mois, de quoi tester, pas de quoi produire.

La conversion des jetons en crédits dépend ensuite du modèle retenu, et l'écart entre modèles y est plus large que l'écart entre plans. La documentation de l'application Anthropic Claude détaille la table.

Un million de jetons produits par Sonnet 5 revient donc à près de 11 100 crédits, soit environ 10 $ au tarif Core. Le même million produit par Fable 5 en réclame 55 500, soit près de 50 $. Choisir le modèle avant de peaufiner le prompt reste le geste qui rapporte le plus.

Poser un module IA dans un scénario sans payer pour rien

Rien ne doit atteindre le module IA avant d'avoir passé un filtre déterministe, et cette seule règle pèse plus lourd sur la facture que le choix du modèle. Un tri de boîte mail qui appelle le modèle sur chaque message traite aussi les notifications automatiques, les accusés de réception et les relances internes, soit facilement la moitié du volume. Un filtre sur l'expéditeur et sur la présence d'une pièce jointe, posé avant le module, retire ce volume sans consommer un seul jeton.

La séquence qui tient en production compte cinq briques. Un déclencheur qui surveille la source. Un filtre qui ne laisse passer que ce qui mérite une lecture. Un module IA qui reçoit un prompt système court et une consigne de sortie structurée. Un module d'analyse qui transforme cette réponse en champs exploitables. Un routeur qui envoie chaque cas vers sa suite. Demander une réponse en JSON puis la parser évite la cascade de modules de texte qui, chacun, coûte son crédit.

Deux pièges reviennent à chaque audit. Le premier concerne la connexion : le module de prompt simple fonctionne sans configuration, alors que les autres modules exigent de relier votre compte du fournisseur, ce qui change la façon dont les jetons sont facturés. Le second concerne la reprise sur erreur. Un module IA qui échoue et rejoue trois fois consomme trois fois les crédits, y compris quand l'échec vient d'un dépassement de contexte que le rejeu ne corrigera jamais. Limiter le nombre de tentatives et router l'échec vers une file de reprise manuelle revient moins cher qu'une politique de rejeu généreuse.

Pour le reste de la mécanique, du routeur aux agrégateurs, les bases de l'automatisation visuelle restent valables. L'ajout d'un modèle ne change pas la façon dont les données circulent, il change le prix de chaque passage.

Un agent Make décide lui-même de ce qu'il vous coûte

Le nombre d'exécutions d'un agent reste inconnu au moment où vous le mettez en ligne, et c'est la seule chose à retenir avant de le brancher sur du volume. Make donne d'ailleurs sa formule de dimensionnement dans ses bonnes pratiques : pour estimer le plafond d'étapes d'exécution à accorder à un agent, multipliez par dix le nombre maximal d'appels d'outils attendus. Un agent qui dispose de cinq outils se budgète donc à cinquante étapes.

Traduit en crédits, le calcul se lit d'un coup. L'application Make AI Agent consomme un crédit par opération, plus les crédits liés aux jetons. Cinquante étapes, cinquante crédits, avant même de compter les jetons. Sur les 10 000 crédits du plan Core, cela plafonne à deux cents exécutions par mois. Un scénario déterministe de six modules qui traite la même demande en coûte six, soit plus de mille six cents exécutions pour le même budget. Le rapport est de un à huit, et il se creuse dès que l'agent se met à réessayer.

Ce plafond d'étapes reste le seul garde-fou entre un agent qui boucle et une réserve de crédits vidée en une nuit. Un agent mal cadré qui reçoit une demande ambiguë peut appeler le même outil une dizaine de fois avant d'abandonner. Nous posons ce plafond à la moitié de la valeur recommandée au moment de la mise en service, puis nous le relâchons en regardant les exécutions réelles, plutôt que l'inverse.

La mémoire de conversation ajoute sa propre dérive. Un agent qui conserve tout l'historique d'un fil renvoie ce fil au modèle à chaque tour, donc les jetons d'entrée grossissent à chaque échange, et la facture avec eux. La plateforme permet de borner le nombre de messages conservés, cinq par exemple, et cette borne pèse davantage sur le coût qu'un changement de modèle. La méthode pour faire tenir un agent IA en production détaille le reste de ces réglages.

Votre clé de fournisseur ou celle de Make

Les deux voies facturent un crédit par opération, la différence porte uniquement sur les jetons. Avec le fournisseur intégré, les jetons sont convertis en crédits selon la table du modèle, et tout apparaît sur une seule facture. Avec votre propre connexion, l'opération reste comptée en crédits et les jetons sont facturés directement par le fournisseur, à son tarif public. Le catalogue OpenAI affiche par exemple un modèle d'entrée de gamme à 0,25 $ le million de jetons d'entrée et 2,00 $ le million de jetons de sortie.

Le point de bascule arrive plus tôt qu'on ne l'imagine. Pour un usage occasionnel, la simplicité du fournisseur intégré l'emporte largement, et personne ne devrait perdre une demi-journée à créer un compte de fournisseur pour trois cents appels par mois. Pour un scénario qui tourne des milliers de fois, la comparaison se refait modèle par modèle, et la clé maison redevient souvent gagnante. Elle ouvre en plus l'accès aux modèles que la plateforme n'a pas encore intégrés.

La clé maison apporte un second bénéfice, invisible sur la facture Make. Elle vous rend le journal du fournisseur, donc la consommation réelle appel par appel, là où le compteur de crédits agrège tout. Sans cette granularité, diagnostiquer un scénario qui consomme trois fois trop revient à deviner. C'est le raisonnement qui structure aussi le pilotage des coûts LLM à l'échelle d'une entreprise : la mesure par appel précède toujours l'optimisation.

Un dernier point mérite d'être tranché avant la mise en ligne, celui des données. Faire transiter des informations personnelles par un module IA relève du même régime qu'un sous-traitant ordinaire, quelle que soit la voie retenue, et la documentation de Make recommande d'ailleurs de limiter l'accès de l'agent aux seules données dont il a besoin. Nous appliquons cette minimisation en amont, dans le scénario, en ne transmettant que les champs utiles plutôt que l'enregistrement complet. La question de l'hébergement de l'IA en France se règle au cadrage, pas après le premier incident.

Les réglages à figer avant d'ouvrir la vanne

Quatre réglages suffisent à rendre une automatisation IA prévisible, et ils se posent avant la première exécution réelle. Le plafond d'étapes d'exécution vient en premier, calculé avec la formule de Make puis divisé par deux pour la mise en service. Le nombre maximal de jetons de sortie arrive ensuite : il borne le coût par appel, avec la réserve que la documentation signale elle-même, une valeur trop basse produit des réponses tronquées. La longueur d'historique conservée par le fil vient en troisième, parce qu'elle pilote les jetons d'entrée. Le filtre déterministe en amont ferme la marche, et reste le plus rentable des quatre.

La surveillance suit, et la plateforme ne la fera pas à votre place. Un scénario planifié qui compare la consommation de crédits du jour à celle de la veille, puis alerte au-delà d'un écart fixé, coûte quelques crédits quotidiens et évite de découvrir le problème par un arrêt de service en pleine semaine. Nous branchons cette sonde sur les mêmes canaux que les alertes techniques du client, jamais sur une boîte mail que personne ne relit.

Le nommage des outils mérite une attention disproportionnée à sa taille apparente. Un agent choisit ses outils sur la seule foi de leur nom et de leur description, donc deux outils appelés « rechercher » et « chercher » produisent des allers-retours inutiles, chacun facturé. Make en fait une condition pour les outils partagés avec des systèmes IA externes, et le conseil vaut tout autant en interne. Un scénario branché comme outil doit par ailleurs être actif et programmé en exécution à la demande, avec ses entrées et ses sorties déclarées une par une, nom, description et type, sinon l'agent ne sait pas s'en servir.

Quand Make cesse d'être le bon endroit pour votre IA

Trois signaux indiquent qu'il faut sortir la logique IA de la plateforme, et le volume se lit le plus facilement. Au-delà de quelques milliers d'exécutions mensuelles avec un agent, le coût par exécution devient le poste dominant du projet, et le rapport de un à huit entre agent et scénario déterministe se paie en clair chaque mois. Deux options existent alors : ramener la logique dans un scénario déterministe en acceptant d'énumérer les branches, ou déplacer l'agent vers une brique hébergée où le coût suit les jetons et non les opérations.

Le deuxième signal est le besoin de tests. Un scénario se teste en le lançant, ce qui suffit tant que la logique reste linéaire. Dès qu'un agent arbitre entre huit outils, valider une modification demande de rejouer une batterie de cas, et l'éditeur n'offre ni versionnement de ces cas ni comparaison de deux variantes sur le même jeu d'entrées. Les équipes qui ont ce besoin finissent par écrire leur harnais ailleurs, puis par y déplacer l'agent lui-même.

Le troisième signal concerne la localisation des traitements. Quand un projet impose que les données restent chez un hébergeur donné, la question se pose au niveau de la plateforme d'orchestration autant qu'au niveau du modèle, et une comparaison entre n8n et Make aide à trancher, puisque n8n propose de se déployer sur votre propre infrastructure quand Make ne s'utilise que depuis ses propres serveurs. Notre position tient en deux lignes : tant que le volume reste modéré et les données peu sensibles, Make gagne sur le temps de mise en oeuvre, et l'arbitrage s'arrête là. Dès que l'un des deux bascule, le calcul change, et mieux vaut le refaire tôt. Une agence Make sérieuse vous le dira avant de démarrer le projet, pas au moment de la facture.

Questions fréquentes sur Make et l'IA

Combien coûte une exécution d'agent sur Make ?

Comptez un crédit par étape d'exécution, plus les crédits liés aux jetons consommés. Make recommande de dimensionner le plafond d'étapes à dix fois le nombre d'appels d'outils attendus, donc un agent à cinq outils se budgète autour de cinquante crédits par exécution. Sur les 10 000 crédits du plan Core, cela représente environ deux cents exécutions mensuelles. Le chiffre réel dépend ensuite de la longueur des réponses et du modèle retenu.

Faut-il utiliser le fournisseur IA de Make ou sa propre clé ?

Le fournisseur intégré évite toute configuration et facture tout en crédits, ce qui convient aux volumes modestes et aux premiers essais. Une connexion à votre propre compte laisse l'opération en crédits mais renvoie les jetons vers la facture du fournisseur, avec en prime l'accès aux journaux détaillés et aux modèles que la plateforme n'a pas intégrés. Le basculement se justifie dès qu'un scénario tourne des milliers de fois par mois.

Peut-on brancher un scénario existant comme outil d'un agent ?

Oui, à trois conditions. Le scénario doit être actif, programmé en exécution à la demande ou déclenché par un webhook, et ses entrées comme ses sorties doivent être déclarées avec un nom, une description et un type. L'agent s'appuie sur ces descriptions pour décider quand appeler l'outil, donc un intitulé vague provoque des appels inutiles, facturés comme les autres.

Un module IA dans un scénario suffit-il pour trier des documents ?

Dans la plupart des cas, oui. Tant que les documents partagent une structure connue et que les branches de traitement restent énumérables, un module IA qui rend une sortie structurée fait le travail pour un crédit plus les jetons, avec un coût stable par document. L'agent devient utile quand le format varie sans prévenir, ou quand la décision impose d'aller chercher une information ailleurs avant de trancher.

Comment repérer un scénario IA qui consomme trop ?

Regardez l'ordre des modules avant de toucher au prompt. Un module IA placé après un itérateur consomme un crédit par élément du tableau, plus l'appel de modèle correspondant, ce qui multiplie la facture par le nombre de lignes traitées. Vérifiez ensuite le nombre de tentatives de rejeu, puis la longueur d'historique conservée par vos agents. Ces trois réglages expliquent la grande majorité des dérives que nous rencontrons sur des scénarios déjà en production.