Agents IA Make : fonctionnement, outils et coût réel

Trois lignes sur une facture Make, à la fin d’un mois où un agent a tourné : les opérations de l’agent lui-même, les opérations de chaque outil qu’il a appelé, et les jetons consommés par le modèle. La première ligne se calcule de tête. La deuxième surprend, parce qu’un agent appelle plus d’outils qu’on ne l’imagine. La troisième dépend d’un choix que tu fais en trois secondes au moment de la configuration, et qui peut diviser la note par trois.

La nouvelle application Make AI Agent (New) a été publiée le 2 février 2026 puis présentée publiquement le 11 février. Elle est disponible sur tous les plans avec le fournisseur IA de Make, mais elle reste en bêta ouverte : Make prévient que les fonctions et les tarifs peuvent encore changer. Les connexions personnalisées à OpenAI, Anthropic ou Gemini demandent un plan payant. Ces points viennent de l’introduction officielle de Make AI Agent (New) ; l’annonce de Make détaille aussi le canvas et les plus de 3 000 applications disponibles.

Ce guide construit un agent complet, puis pose le calcul des crédits ligne par ligne, avec les chiffres de la documentation officielle et des hypothèses de volume affichées pour que tu refasses le calcul avec les tiens. Tu sauras à la fin quand un agent mérite son coût, et quand un scénario classique fait le même travail pour trois fois moins cher.

Ce qu’un agent Make fait qu’un scénario ne fera jamais

Un scénario Make suit le chemin que tu as tracé. Tu poses les modules dans un ordre, tu branches tes conditions, et l’exécution emprunte exactement les routes prévues. C’est la force de l’outil : le comportement est prévisible, reproductible, et tu peux le lire sur le canvas sans le lancer.

Un agent renverse ce rapport. Tu lui donnes un objectif, une boîte à outils, et il décide lui-même lesquels appeler, dans quel ordre, et quand s’arrêter. Le même message entrant peut produire deux parcours différents selon son contenu. Là où tu écrivais la partition note par note, tu deviens le producteur qui laisse le musicien improviser sur une grille : le beatmaker pose le tempo et les accords, le rappeur choisit son flow. Le résultat gagne en souplesse et perd en prévisibilité.

Make a compris que cette perte de contrôle est le vrai frein à l’adoption, et la nouvelle génération d’agents répond avec un panneau de raisonnement qui montre en temps réel comment l’agent réfléchit et quels outils il appelle. Les décisions cessent d’être une boîte noire, elles deviennent une trace que tu relis après coup. C’est ce qui rend le débogage possible, et c’est le point qui manquait le plus à la première version.

Par défaut, un agent ne réutilise pas la conversation précédente : si le champ Conversation ID reste vide, Make génère un nouvel identifiant à chaque exécution. Cette séparation a du bon : elle évite de traîner un historique inutile. Elle a une conséquence pratique immédiate : tout le contexte utile doit entrer dans l’exécution en cours, par les entrées, les fichiers ou les outils.

Pour créer une continuité, renseigne Conversation ID avec un identifiant stable, puis règle Maximum conversation history, le nombre de réponses précédentes conservées. Avec un historique, chaque élément rappelé augmente le contexte et donc les jetons traités. La référence actuelle du module Run an agent documente ces deux champs.

Le test en trois questions avant de construire un agent

Cette souplesse a donc un prix en prévisibilité et en crédits, ce qui pose la seule question qui vaille avant d’ouvrir Make : ton problème mérite-t-il un agent. Trois questions suffisent à trancher, et elles se répondent par oui ou par non.

La première : la tâche demande-t-elle un jugement. Classer une réclamation client selon son urgence réelle demande un jugement. Copier une ligne de formulaire vers un tableur n’en demande aucun.

La deuxième : l’entrée est-elle non structurée. Un email libre, un PDF, une note vocale transcrite sont non structurés. Un webhook qui envoie toujours les mêmes six champs ne l’est pas.

La troisième : le chemin varie-t-il selon le contenu. Si certaines demandes réclament trois appels d’API et d’autres un seul, le chemin varie. Si toutes suivent la même séquence, il ne varie pas.

Compte tes oui, puis suis le schéma jusqu’à sa sortie. Il est moins flatteur pour l’agent que les démonstrations que tu as vues passer.

Le schéma renvoie vers le scénario classique dès la première réponse négative, et ce n’est pas un hasard. Deux « non » sur trois signifient que tu paierais un modèle de langage pour prendre une décision que trois conditions bien posées prennent gratuitement. Sur ce terrain, les modules If-else et Merge de Make font le travail sans consommer un seul jeton, et leur comportement se lit sur le canvas.

Monter l’agent : le module Run an Agent, champ par champ

Une fois le test passé, la construction commence dans le même canvas que tes scénarios habituels, ce qui est la vraie nouveauté de cette génération. Tu poses ton déclencheur comme d’habitude, puis tu ajoutes le module Make AI Agent (New), opération Run an Agent. À partir de là, tout se joue dans son panneau de configuration.

Deux de ces champs méritent qu’on s’y arrête. Maximum conversation history limite ce que tu traînes du passé, donc une partie directement facturable du contexte. Step timeout ne plafonne pas les jetons, mais évite qu’une étape reste bloquée indéfiniment : la documentation actuelle annonce 300 secondes par défaut et 600 au maximum. Le nombre d’étapes et les jetons consommés se contrôlent après l’exécution dans les métadonnées ; la version actuelle du module ne documente plus les champs « Maximum steps » et « Maximum tokens » montrés par l’ancienne interface.

Deux détails de cet écran méritent ton attention avant d’aller plus loin. Le premier tient au bandeau Beta : ce n’est pas une étiquette oubliée, la documentation confirme que l’application reste en bêta ouverte. Le second est cet avertissement orange : certains modèles ou fournisseurs peuvent imposer leurs propres conditions de compte. Vérifie ce point avant de câbler quoi que ce soit, ça évite de chercher dans le scénario une restriction venue du fournisseur.

Le reste de la configuration se passe ailleurs, dans les outils, et c’est là que se décide la qualité du résultat.

Les outils, là où l’agent gagne ou déraille

Un agent sans outil est un modèle de langage qui bavarde. Ce sont les outils qui lui donnent le droit d’agir, et le sélecteur de Make montre les quatre types disponibles d’un coup d’œil.

La section du haut, réservée aux agents, contient l’essentiel : Scenarios pour appeler un scénario complet, MCP Client pour brancher un serveur externe, Knowledge pour les fichiers de référence, et Make AI Agent pour confier une partie du travail à un autre agent, ce qui ouvre la porte aux architectures à sous-agents. En dessous, la liste des applications rend n’importe quel module utilisable comme outil, de Google Sheets à une requête HTTP.

Le mécanisme de sélection est plus rudimentaire qu’on ne le croit, et c’est capital à comprendre : l’agent choisit ses outils sur leur nom et leur description, rien d’autre. Le contenu de l’outil lui reste invisible, son comportement aussi. Ces deux champs de texte sont donc l’interface entre ton intention et ses décisions. La documentation officielle donne un exemple qui mérite d’être recopié tel quel, parce qu’il contient l’astuce que tout le monde oublie.

Nom :
add customer email to customer contacts table

Description :
This adds a new customer email address to the customer contacts table.
Do not run this if '@' is missing.

La dernière ligne fait toute la différence : elle dit à l’agent quand ne pas appeler l’outil. Un outil décrit uniquement par ce qu’il fait sera appelé dès qu’il ressemble vaguement à la solution. Un outil qui porte sa condition de refus dans sa description se protège tout seul des appels à côté de la plaque. Écris tes descriptions comme des consignes à un stagiaire compétent mais pressé.

Dans la nouvelle application, un module simple s’ajoute directement comme outil sur le canvas. Pour une action complexe, utilise plutôt Scenarios > Call a scenario : le scénario appelé doit accepter les entrées prévues, retourner les sorties utiles et être activé à la demande. Cette distinction est détaillée dans le guide officiel Créer son premier agent. Elle évite surtout de confondre le fonctionnement actuel avec les « module tools » de l’ancienne version, qui créaient automatiquement des scénarios séparés.

Écrire des instructions système qui tiennent en production

Les outils en place, il reste à dire à l’agent comment s’en servir, et c’est le champ Instructions qui porte cette responsabilité. La documentation donne une consigne contre-intuitive : garde tes instructions assez larges pour que l’agent fonctionne sur des situations variées, plutôt que de le verrouiller sur un format unique. Elle prévient dans la même page que les prompts trop longs augmentent le risque de confusion et d’hallucination du modèle.

L’équilibre entre les deux tient dans une structure fixe : le rôle, le périmètre, les règles d’appel des outils, le format de sortie, et les interdits. Voici un jeu d’instructions complet pour un agent de tri de réclamations, à recopier et à adapter dans ses deux premiers blocs.

Tu es l'agent de tri des réclamations d'une boutique en ligne.

CONTEXTE
- Les réclamations arrivent par email, en français, longueur variable.
- Trois catégories existent : livraison, produit défectueux, facturation.
- Un client mécontent qui attend est plus coûteux qu'un ticket mal classé.

TA MISSION
Lire la réclamation, déterminer sa catégorie et son urgence, puis créer
le ticket correspondant avec les outils à ta disposition.

RÈGLES D'APPEL DES OUTILS
1. Appelle toujours "lire_commande" en premier si un numéro de commande
   figure dans le message. Sans ce numéro, ne l'appelle pas.
2. Appelle "creer_ticket" une seule fois par réclamation, jamais deux.
3. N'appelle "rembourser_commande" sous aucun prétexte : le remboursement
   est une décision humaine, tu te contentes de le proposer dans le ticket.

BARÈME D'URGENCE, sans demi-point
- 3 : commande payée non livrée au-delà du délai annoncé, ou produit
      dangereux signalé.
- 2 : produit défectueux, erreur de facturation avérée.
- 1 : demande d'information, insatisfaction sans préjudice matériel.

FORMAT DE SORTIE
Réponds uniquement avec ce JSON, sans texte autour :
{
  "categorie": "livraison" | "produit" | "facturation",
  "urgence": 1 | 2 | 3,
  "numero_commande": "<le numéro trouvé, ou vide>",
  "resume": "<la demande en une phrase factuelle>",
  "action_proposee": "<ce qu'un humain devrait faire, en une phrase>"
}

INTERDITS
- N'invente jamais un numéro de commande absent du message.
- Ne promets aucun délai, aucun geste commercial, aucun remboursement.
- Si le message est incompréhensible, renvoie urgence 1 et explique
  pourquoi dans le champ resume.

Trois choix de ce prompt travaillent directement pour ta facture et ta tranquillité. Les règles d’appel numérotées réduisent les appels d’outils inutiles, donc les opérations facturées. Le barème fermé rend le classement reproductible : deux passages du même email donnent la même urgence. Et l’interdit explicite sur le remboursement pose une barrière que le modèle ne peut pas franchir par excès de zèle, ce qui vaut mieux que de découvrir la générosité d’un agent sur un relevé bancaire.

La grille de crédits, ligne par ligne

L’agent tourne, ses outils répondent, ses instructions tiennent. Reste la question du début, et Make publie la réponse dans sa grille officielle de consommation des agents. Elle distingue deux mondes selon le fournisseur IA choisi dans le champ Connection.

La lecture de ce tableau tient en une phrase : avec ta propre clé API, les jetons sortent du système de crédits Make et te sont facturés directement par ton fournisseur. Make ne compte plus alors que les opérations. Deux types de jetons supplémentaires n’existent d’ailleurs que du côté du fournisseur de Make, ceux de l’embarquement et ceux de la description de fichiers.

Cette phrase vaut de l’argent, alors mettons-la en chiffres. Les hypothèses sont affichées pour que tu refasses le calcul avec les tiennes : 200 exécutions par mois, 3 appels d’outils en moyenne par exécution, environ 2 000 jetons d’entrée et 300 de sortie par exécution.

La partie déterministe se calcule à la main, et c’est celle que personne n’anticipe. Chaque exécution consomme l’opération de l’agent, plus une opération par outil appelé, soit 4 opérations, soit 4 crédits. Sur 200 exécutions, cela fait 800 crédits par mois, et ce chiffre est identique dans les deux mondes. Autrement dit, tu paies déjà 800 crédits avant que le modèle ait écrit un seul mot.

La partie variable dépend du modèle. La grille générale des crédits Make annonce actuellement 904 jetons d’entrée par crédit et 181 jetons de sortie par crédit pour Claude Haiku 4.5. Avec nos hypothèses, cela donne environ 2,2 crédits d’entrée et 1,7 crédit de sortie par exécution, soit près de 800 crédits supplémentaires par mois. Make précise que ces taux peuvent changer avec les modèles disponibles : vérifie la grille au moment de budgéter.

Mises bout à bout, ces deux parties dessinent deux factures très différentes selon le fournisseur que tu as coché au départ.

Le schéma rend visible ce que le tableau laissait implicite. Avec le fournisseur de Make, l’agent consomme environ 1 600 crédits par mois, ce qui fait exploser les 1 000 crédits du plan gratuit et occupe 16 % du plan Core à 9 dollars. Avec ta propre clé, la consommation Make tombe à 800 crédits, et les mêmes jetons chez Anthropic coûtent moins d’un dollar au tarif public de Haiku 4.5. La règle qui en découle est simple : dès que ton agent tourne pour de vrai, branche ta propre clé. Le fournisseur intégré est fait pour tester sans créer de compte, pas pour porter ta production.

Ces chiffres restent des estimations construites sur des hypothèses visibles. Le seul chiffre qui vaille est le tien : après une semaine de fonctionnement réel, l’historique de ton organisation Make te donne la consommation exacte, exécution par exécution.

Ce qui fait exploser la facture sans prévenir

Ce calcul suppose un agent qui se comporte bien. Quatre dérives font grimper la note sans qu’aucune alerte ne se déclenche, et elles se préviennent toutes à la configuration.

La boucle d’itérations. Un agent qui n’arrive pas à conclure rappelle ses outils, encore et encore, et chaque tour consomme opérations et jetons. La version actuelle expose les étapes et les jetons dans les métadonnées de sortie : surveille-les sur les premiers runs et simplifie les instructions ou les outils dès qu’une boucle apparaît.

Le prompt qui gonfle. Chaque correction apportée aux instructions ajoute des lignes, et ces lignes repartent à chaque appel. Un prompt qui double de taille double le coût en jetons d’entrée de toutes les exécutions à venir, et la documentation prévient que la longueur augmente aussi le risque de confusion. Les deux effets vont dans le même sens : coupe.

Les données non filtrées. La documentation recommande de filtrer les données avant de les passer à l’agent et de limiter son accès aux seules informations nécessaires. Passer une fiche client complète quand trois champs suffisent multiplie le volume de jetons par dix et expose des données personnelles qui n’avaient rien à faire là.

Les fichiers de connaissance. Un PDF coûte 10 jetons par page en plus des jetons de contenu, du côté du fournisseur de Make. Un manuel de 200 pages chargé « au cas où » se paie à chaque interrogation. Si tu n’utilises que trois pages, charge trois pages.

Ces quatre dérives partagent une même racine : un agent devient cher dès qu’on lui donne plus que le nécessaire. La discipline qui protège ton budget est exactement celle qui améliore ses réponses, ce qui tombe plutôt bien. Mets-le au régime, il réfléchit mieux.

Le test d’une semaine

Tu as maintenant tout ce qu’il faut pour trancher, et la meilleure façon de vérifier un calcul reste de le confronter à la réalité. Voici le protocole, il tient en une semaine.

Monte un seul agent, sur une tâche qui passe le test des trois questions. Donne-lui trois outils au maximum, avec des descriptions qui portent leur condition de refus. Renseigne les trois champs Maximum, même à des valeurs généreuses. Laisse le fournisseur de Make pour les premiers essais, le temps de valider le comportement.

Note ton hypothèse de volume avant de lancer, comme on l’a fait plus haut : nombre d’exécutions attendues par mois, nombre moyen d’appels d’outils. Puis laisse tourner sept jours.

À la fin de la semaine, ouvre l’historique de consommation de ton organisation et compare. Si l’écart avec ton estimation dépasse le double, la cause est presque toujours dans le nombre d’appels d’outils par exécution, que le panneau de raisonnement te montre appel par appel. Bascule alors sur ta propre clé API et refais le calcul.

Cette comparaison entre l’estimation et le réel est le seul exercice qui rende un agent pilotable, et c’est aussi ce qui manque à toutes les démonstrations enthousiastes que tu croiseras. Si tu fais ce test, viens poser tes deux chiffres, l’estimé et le mesuré, dans la communauté lesnocodeurs : quelques dizaines de mesures réelles vaudront mieux que n’importe quel article, celui-ci compris.

Et si le test des trois questions t’a renvoyé vers un scénario classique, tu n’as rien perdu : les dix fonctions inline de Make et les cinq automatisations à monter quand on est freelance couvrent ce terrain sans jamais consommer un jeton. Pour comparer la logique d’agents d’une plateforme à l’autre, l’architecture décrite dans le système multi-agents n8n montre le même principe de spécialisation, avec des contraintes différentes.