Automatisation avec Make : 3 cas réels de PME en 2026

La question qu'on nous pose le plus souvent en cadrage n'est pas "est-ce que Make fonctionne", mais "à quoi ça ressemble concrètement chez une boîte comme la mienne". C'est une bonne question, parce que la documentation officielle et les tutoriels montrent presque toujours des exemples de démonstration : un formulaire qui remplit une ligne de tableur, un message Slack quand un email arrive. Ce sont des exercices, pas des systèmes en production. Une PME qui construit son premier scénario sur ce modèle découvre en général deux ou trois semaines plus tard les vrais sujets : les crédits qui filent plus vite que prévu, les exécutions qui échouent en silence, les données mal formatées qui polluent le CRM.

Cet article détaille trois scénarios Make réellement déployés dans des PME françaises, avec le nombre de modules, la consommation de crédits observée et surtout ce qui a cassé au premier mois. Les cas sont anonymisés et légèrement recomposés pour préserver la confidentialité des entreprises concernées, mais les volumes, les architectures et les problèmes rencontrés sont ceux du terrain.

Ce qui a changé chez Make en 2026, et pourquoi ça change vos calculs

Avant les cas, un point de contexte que beaucoup de PME ratent parce qu'il est passé sans bruit. Le 27 août 2025, Make a remplacé son unité de facturation historique, l'opération, par le crédit. La conversion s'est faite à parité, une opération égale un crédit, et les prix des plans n'ont pas bougé. Sur le papier, rien ne change.

Dans les faits, si. Le modèle en crédits permet de facturer différemment selon le type de module exécuté, ce que le modèle en opérations ne permettait pas. Un module standard coûte toujours un crédit : déclencheur, filtre, routeur, requête HTTP, formatage de données. Mais l'exécution de code JavaScript ou Python via le module Make Code coûte deux crédits par seconde d'exécution, et les modules IA natifs consomment un nombre variable de crédits selon le modèle appelé, les tokens traités, le nombre de pages d'un document ou la taille d'un fichier. La documentation officielle de Make sur l'usage des crédits pour les agents IA détaille ce calcul.

La conséquence pratique pour une PME est directe : un scénario qui traite du texte avec un modèle de langage n'a plus un coût prévisible à l'avance. Vous pouvez estimer sa consommation, vous ne pouvez plus la garantir. Cela ne disqualifie pas les modules IA, mais cela impose une chose : les isoler dans un scénario dédié, avec son propre suivi de consommation, plutôt que de les noyer au milieu d'un flux critique. Les trois cas ci-dessous illustrent chacun une facette de ce compromis.

Cas 1 : le cabinet de conseil qui a supprimé sa relance client manuelle

Une société de conseil en organisation, une douzaine de consultants, facturation au forfait et à la journée. Le problème initial n'était pas la facturation elle-même, gérée proprement dans Pennylane, mais tout ce qui gravitait autour : vérifier chaque lundi quelles factures étaient arrivées à échéance, retrouver le bon interlocuteur chez le client, rédiger une relance, la personnaliser, l'envoyer, noter qu'elle avait été envoyée. Une demi-journée par semaine pour l'assistante de direction, entièrement consacrée à du travail sans valeur ajoutée.

Le scénario Make construit compte neuf modules. Un déclencheur planifié tous les matins en semaine, une lecture des factures impayées depuis l'outil comptable, un filtre sur la date d'échéance dépassée, un routeur qui oriente selon l'ancienneté de l'impayé (rappel courtois à 7 jours, relance ferme à 30 jours, alerte interne à 60 jours), une recherche du contact facturation dans le CRM, la construction du corps de message depuis un modèle, l'envoi via la messagerie professionnelle, l'écriture d'une note dans le CRM, et un récapitulatif quotidien posté dans le canal Slack de la direction.

Le volume observé : entre 15 et 40 factures traitées par jour ouvré selon la période du mois, ce qui donne une fourchette de 2 700 à 7 200 crédits mensuels. Largement dans l'enveloppe du plan Core, avec de la marge pour d'autres scénarios.

Ce qui a cassé au premier mois : le routeur envoyait des relances sur des factures déjà réglées. La cause était bête et fréquente : la synchronisation du statut de paiement entre la banque et l'outil comptable prend jusqu'à 48 heures, et le scénario lisait donc un état obsolète. La correction a tenu en un module supplémentaire, une vérification du solde réel avant envoi, plus une règle de sécurité qui bloque toute relance sur une facture dont le statut a changé dans les trois derniers jours. Le principe général à retenir : ne jamais déclencher une action visible par le client sur la base d'une donnée dont vous ne maîtrisez pas la fraîcheur. Ce sujet est traité plus largement dans notre guide sur l'automatisation des relances de factures impayées.

Cas 2 : le e-commerçant qui a réconcilié stock, commandes et service client

Un distributeur spécialisé, environ 25 salariés, une boutique en ligne sous Shopify doublée d'une activité de vente au téléphone gérée dans un logiciel métier ancien sans API publique moderne. Le point de friction : le stock affiché en ligne ne tenait pas compte des ventes téléphoniques, ce qui produisait plusieurs surventes par semaine, donc autant de clients mécontents et de remboursements à traiter.

Ce cas est intéressant parce qu'il illustre la vraie limite de Make en PME : le logiciel métier n'avait pas de connecteur natif. La solution est passée par une exportation automatique quotidienne au format CSV déposée sur un espace de stockage, que Make lit et transforme. Ce n'est pas élégant, mais c'est ce qui existait, et cela a fonctionné.

Le montage compte deux scénarios distincts, séparation volontaire. Le premier, cinq modules, lit le fichier exporté, le convertit, agrège les quantités par référence produit et met à jour le stock Shopify par lots. Il tourne trois fois par jour. Le second, sept modules, écoute les nouvelles commandes en ligne, vérifie la disponibilité réelle, et en cas d'anomalie crée un ticket dans l'outil de support avec le détail du conflit plutôt que de laisser passer la commande.

La consommation mensuelle : environ 4 500 crédits pour le premier scénario, dont l'essentiel vient du traitement par lots des références produit, et environ 2 800 pour le second. Le pilotage du budget crédits est venu d'un réglage précis : le regroupement des mises à jour par lots de 50 références au lieu d'un module par référence, ce qui a divisé la consommation du premier scénario par un facteur significatif. C'est l'optimisation la plus rentable qu'on connaisse sur Make, et la plus souvent oubliée.

Ce qui a cassé au premier mois : rien de spectaculaire, mais un silence. Un jour, l'exportation quotidienne du logiciel métier n'a pas eu lieu, un blocage interne côté serveur. Make a lu le fichier de la veille sans broncher, parce qu'il était toujours là, et a donc appliqué un état de stock vieux de 24 heures. Aucune erreur remontée, aucun signal. La correction : un contrôle de la date de dernière modification du fichier en entrée de scénario, et une alerte immédiate si elle dépasse un seuil. Un scénario qui réussit sur une mauvaise donnée est plus dangereux qu'un scénario qui échoue franchement.

Cas 3 : l'agence B2B qui qualifie ses leads entrants avec un module IA

Une agence de services B2B, une trentaine de personnes, entre 60 et 120 demandes entrantes par mois via formulaire de contact et boîte générique. Le problème n'était pas le volume brut, gérable à la main, mais la dispersion : les demandes arrivaient dans trois endroits différents, personne n'avait de vue consolidée, et les demandes hors cible mangeaient autant d'attention que les vraies opportunités.

Le scénario compte onze modules et intègre un appel à un modèle de langage. Un déclencheur sur la boîte générique et un second sur le formulaire, un module de normalisation qui ramène les deux sources à un format unique, un appel au modèle qui classe la demande selon quatre critères (secteur, taille estimée, nature du besoin, niveau d'urgence exprimé), un routeur qui oriente vers trois destinations selon le score, la création de la fiche dans le CRM avec les champs préremplis, une notification au commercial concerné, et une réponse automatique d'accusé de réception adaptée au type de demande.

C'est ici que le nouveau modèle de facturation se fait sentir. Les dix modules classiques consomment environ 1 200 crédits par mois pour 110 demandes. Le module IA, lui, consomme un volume variable selon la longueur des messages entrants, avec un écart de plus du simple au double entre un mois de messages courts et un mois où plusieurs prospects ont envoyé des cahiers des charges complets en pièce jointe. La ligne de conduite retenue : plafonner la longueur du texte envoyé au modèle en tronquant au-delà d'un seuil raisonnable, ce qui n'a pas dégradé la qualité du classement puisque l'essentiel de l'information utile se trouve dans les premières lignes.

Ce qui a cassé au premier mois : le modèle produisait parfois une sortie légèrement hors format, un champ manquant ou une valeur inattendue, ce qui faisait échouer le module suivant. La correction n'a pas été de changer de modèle mais d'ajouter un module de validation entre les deux, avec une valeur par défaut et une mise en file d'attente humaine quand la sortie n'est pas exploitable. Le principe est le même que pour n'importe quel système comportant une part d'incertitude : ne jamais laisser une sortie non contrôlée alimenter directement une écriture en base. Le sujet est développé dans notre article sur l'évaluation de la fiabilité d'un agent IA en PME.

Les trois erreurs de conception qui font grimper la facture

Les trois cas partagent les mêmes pièges, et ils reviennent dans presque tous les audits qu'on mène sur des comptes Make existants.

Un module par élément au lieu d'un traitement par lots. C'est de loin le premier poste de gaspillage. Un scénario qui itère sur 200 lignes de tableur avec une action unitaire consomme 200 crédits par exécution. Le même travail regroupé en lots via les modules d'agrégation en consomme une fraction. Sur un scénario qui tourne plusieurs fois par jour, l'écart annuel se compte en centaines d'euros.

Un déclencheur trop fréquent sur une source qui bouge peu. Un scénario planifié toutes les cinq minutes sur une boîte email qui reçoit trois messages par jour consomme un crédit à chaque passage à vide, soit environ 8 600 crédits par mois pour rien. Passer à un déclencheur événementiel quand le connecteur le permet, ou espacer la planification, règle le problème en trente secondes de réglage.

Des scénarios monolithiques qui mélangent tout. Un gros scénario de quarante modules qui fait la facturation, la relance et le reporting est plus difficile à déboguer, plus coûteux à rejouer en cas d'échec, et impossible à mettre en pause partiellement. Trois scénarios de quinze modules coûtent le même prix en fonctionnement normal, mais bien moins cher en incident, puisque vous ne rejouez que la partie concernée.

Quand Make n'est pas le bon outil

Il faut être honnête sur les limites, parce que la mauvaise décision se paie sur plusieurs années.

Si votre volume mensuel de crédits vous positionne durablement sur un plan à plusieurs centaines d'euros, le calcul économique bascule vers un orchestrateur auto-hébergé, dont le coût est celui d'un serveur et non celui du volume traité. Si vous avez une contrainte réelle de localisation des données, secteur santé, données sensibles, exigence contractuelle d'un donneur d'ordre, l'hébergement des exécutions chez Make devient un sujet de conformité à instruire sérieusement, pas une case à cocher. Et si votre besoin réclame de la logique métier fine, des boucles conditionnelles complexes ou du traitement de données volumineuses, l'éditeur visuel finit par coûter plus d'efforts qu'il n'en fait gagner.

En dehors de ces trois cas, et pour la très grande majorité des PME françaises qui commencent à structurer leurs opérations, Make reste le meilleur rapport entre vitesse de mise en œuvre et robustesse. Le vrai facteur de réussite n'est pas l'outil : c'est le choix du processus à automatiser en premier, et la discipline de conception qui évite les trois erreurs ci-dessus. Pour cadrer ce premier choix, notre guide sur par où commencer l'automation ops en PME donne la méthode de tri que nous appliquons en démarrage de mission.

Par quoi commencer chez vous

Si vous devez retenir une seule chose des trois cas, c'est que le scénario qui apporte le plus de valeur n'est jamais le plus impressionnant techniquement. C'est celui qui supprime un travail répétitif que quelqu'un fait aujourd'hui à la main, sur une donnée dont vous maîtrisez la fraîcheur, avec un résultat vérifiable. Les trois entreprises citées ont commencé exactement là, et aucune n'a construit son premier scénario en visant plus de dix modules.

La méthode de démarrage tient en quatre points. Listez les tâches récurrentes qui consomment plus de deux heures par semaine à quelqu'un dans l'équipe. Écartez d'emblée celles qui demandent un jugement métier à chaque passage, elles viendront plus tard. Sur celles qui restent, vérifiez que les outils concernés disposent d'un connecteur Make natif, sinon la première brique du projet sera une exportation de données et non une automatisation. Puis construisez le scénario le plus simple qui produise un résultat visible, et surveillez ses exécutions pendant deux semaines avant d'en ajouter un deuxième.

Vous pouvez aussi comparer votre situation aux dix cas d'usage IA chiffrés en PME que nous avons documentés, pour repérer le processus le plus proche du vôtre. Et si vous préférez faire ce tri avec quelqu'un qui a déjà vu les impasses, vous pouvez nous contacter pour en discuter sur vos propres flux, pas sur ceux d'une PME type.