Stack ops à agents IA — des agents always-on sans engineering

Le stack qu’une petite équipe ops fait tourner quand elle veut des agents qui se déclenchent sur des événements plutôt qu’une fenêtre de chat que quelqu’un doit penser à ouvrir. Gumloop construit et héberge les agents, n8n déplace le travail entre les systèmes et impose le point de validation, Clay fournit les données externes dont un agent a besoin avant de pouvoir décider quoi que ce soit, et Slack est l’endroit où un humain dit oui ou non. Quatre outils, environ $1,1K-$11K par an, aucun ingénieur à l’organigramme.

La distinction qui détermine si vous en avez besoin : ce n’est pas un stack pour automatiser des étapes fixes et connues. Si les étapes ne changent jamais — copier le champ A vers le champ B quand un formulaire se déclenche — n8n seul le fait moins cher et plus fiablement. Ce stack justifie son coût quand l’entrée n’est pas structurée et que la décision demande du jugement au cas par cas : un email inbound qui est peut-être une vraie demande, un CV face à une grille d’évaluation, un NDA avec une clause d’indemnisation non standard, un fil de support qui est peut-être un signal de churn.

Comment les pièces s’emboîtent

Gumloop est la couche agents. Depuis son repositionnement de 2026, le produit met les agents en avant et garde le canvas visuel dessous : les agents tournent en chat, dans Slack, depuis une boîte email d’agent, ou sur des triggers de planification et d’événement, et appellent un workflow du canvas quand une étape doit être répétable plutôt que raisonnée. Le choix du modèle se fait par nœud parmi 35+ modèles, si bien qu’un même agent peut appeler Claude pour extraire une clause et un modèle moins cher pour classifier dans la même exécution. Sa surface de récupération, Brain, indexe Notion, Google Drive, Slack, GitHub, Confluence, Zendesk et Salesforce, et pour Drive et Salesforce elle hérite des permissions de la source — un agent ne renvoie que ce que la personne qui interroge pouvait déjà ouvrir. Gumloop n’est pas votre système de référence : il lit, raisonne et émet.
n8n est la couche d’orchestration et de garde-fous. Chaque passage de relais entre Gumloop et le reste de votre SaaS est un workflow n8n : il reçoit la sortie de l’agent, la confronte aux seuils que vous avez fixés, décide si l’action peut s’exécuter sans surveillance ou requiert un humain, écrit dans le système de référence et rattrape les échecs. C’est aussi là que vit la piste d’audit — le journal d’exécution de n8n est la trace de ce qu’un agent a fait et pourquoi, ce qui compte la première fois que quelqu’un pose la question.
Clay est la couche de données externes. Un agent qui raisonne sur un lead inbound, une candidate ou une contrepartie a besoin de faits que l’événement déclencheur ne contient pas : effectif, financement, stack technique, si ce domaine est déjà client. Clay fait cascader chaque recherche dans sa marketplace de fournisseurs et, depuis le changement de comptage de mars 2026, ne facture qu’en cas de résultat. Sans lui, les agents prennent des décisions assurées sur la seule foi d’une signature d’email.
Slack est la surface de validation et d’audit. Toute action d’agent au-dessus du seuil d’autorité est publiée dans un canal sous forme de message approuver/rejeter avant de s’exécuter. C’est le composant que les équipes sautent, et le sauter est la raison pour laquelle les projets d’agents non surveillés sont éteints au deuxième mois — personne ne voyait ce que la chose faisait.

Passages de relais nommés

Événement → tri. Un email arrive dans une boîte partagée, un formulaire est soumis ou un fichier tombe dans un dossier → l’agent Gumloop extrait les entités, classifie la demande et émet du JSON structuré avec une valeur de confiance.
Entité inconnue → enrichissement. La sortie de Gumloop nomme une entreprise ou une personne absente de votre CRM → n8n déclenche l’exécution de la table Clay → la ligne enrichie revient dans le contexte de l’agent avant qu’il recommande une action.
Recommandation → point de validation. Gumloop renvoie une action recommandée → n8n l’évalue face au seuil (confiance au-dessus de la barre et valeur sous le plafond s’exécute sans surveillance ; tout le reste part vers Slack sous forme de carte de validation, avec le raisonnement énoncé par l’agent en pièce jointe).
Validation → écriture. Un humain clique sur approuver dans Slack → n8n écrit dans le système de référence (CRM, ATS ou CLM) et poste le reçu dans le même fil, pour que la décision et sa conséquence tiennent au même endroit.
Échec → responsable. Une exécution d’agent tombe en erreur, une recherche Clay ne renvoie rien, ou la consommation mensuelle de crédits franchit un plafond → le workflow d’erreur de n8n alerte dans Slack la personne responsable des ops désignée, au lieu d’échouer en silence.

Pourquoi cette combinaison

Chaque outil occupe une couche et les couches ne se recouvrent pas : Gumloop raisonne, Clay fournit les faits, n8n route et contrôle, Slack tient l’humain. Cette séparation est ce qui rend le stack débogable par quelqu’un qui n’est pas ingénieur — quand quelque chose casse, il y a exactement un endroit où ça a cassé.

Deux fusions méritent d’être nommées, car les deux sont parfois justes. n8n seul peut faire tout ce que fait Gumloop ; son nœud AI Agent relie n’importe quel modèle à des outils et de la mémoire, et auto-hébergé il est gratuit. Ce que vous payez à la place, ce sont des heures de construction et l’exigence que quelqu’un sache déboguer un webhook en échec à 18h. Gumloop seul peut appeler des API directement et sauter n8n. Ce que vous perdez, c’est le point de validation — logique d’approbation, seuils, reprises et routage d’erreur se dispersent dans des agents individuels au lieu de tenir dans une couche qui les impose, ce qui va très bien avec deux agents et devient ingérable à dix.

Gumloop est ici la couche agents par défaut, et non un produit d’assistant facturé au siège, parce que son plan inclut des sièges illimités et facture à des crédits mutualisés : laisser toute l’équipe ops construire sur les mêmes agents ne coûte rien de plus, et une file partagée est précisément la raison d’être de ce stack.

Coût réel

Fourchettes annuelles pour une équipe ops de 3 à 10 personnes, d’après les pages tarifaires des éditeurs consultées le 2026-09-06 :

Gumloop : ~$450-$3 000/an. Pro coûte $37/mois avec 20 000 crédits, sièges illimités, 5 exécutions de workflow simultanées, 25 conversations d’agent simultanées et un serveur MCP hébergé ; le curseur de crédits monte jusqu’à 1,5 M/mois. Il n’y a plus de plan gratuit — il a été retiré le 2026-07-30 au profit d’un essai Pro de 14 jours. Enterprise (mise en file des requêtes, RBAC, SCIM/SAML, journaux d’audit, VPC, hébergement MCP sur mesure) est uniquement sur devis.
n8n : ~$0-$800/an. La Community Edition auto-hébergée est gratuite ; prévoyez $20-40/mois de VPS. Dans le cloud, Starter coûte €20/mois en facturation annuelle pour 2 500 exécutions et Pro €50/mois pour 10 000. La facturation se fait à l’exécution de workflow quel que soit le nombre d’étapes, et les utilisateurs sont illimités sur tous les plans. Business, à €667/mois en facturation annuelle, ajoute 40 000 exécutions et le déploiement auto-hébergé ; en dessous de 20 salariés il passe à 50% de remise via le plan startup de n8n, la seule remise de ce stack à laquelle une équipe de cette taille est réellement éligible.
Clay : ~$0-$5 400/an. Un plan gratuit est revenu, avec 100 data credits et 500 actions par mois — de quoi piloter, pas de quoi exploiter. Launch coûte $185/mois ($167 en facturation annuelle) pour 3 000 data credits et 15 000 actions ; Growth coûte $495/mois ($446 en facturation annuelle) pour 6 000 et 40 000. La facturation tourne sur deux compteurs — data credits pour les recherches chez les fournisseurs et actions pour les exécutions IA et les intégrations — un stack d’agents qui appelle Clay à chaque trigger brûle donc les deux.
Slack : ~$450-$1 800/an. Pro coûte $7,25/utilisateur/mois en facturation annuelle ($8,75 au mois) ; Business+ coûte $15/utilisateur/mois en facturation annuelle. Seules les personnes qui valident ont besoin d’un siège payant.

Total : ~$1,1K-$11K/an. Le plancher a baissé depuis la dernière fois que cette page a chiffré le stack, parce que Clay a réintroduit un plan gratuit et que l’auto-hébergement de n8n reste gratuit : un vrai pilote coûte aujourd’hui un abonnement Gumloop et cinq sièges Slack. Le plafond est là où atterrit un stack en production une fois que Clay compte du volume réel.

Budgétez Gumloop sur sa ligne de crédits, pas sur ses $37. Les crédits sont comptés à 1 crédit = $0,005, et une conversation d’agent se facture sur cinq composantes : tokens de chat et de raisonnement, un minimum de 1 crédit par appel d’outil réussi, du compute à 5 crédits par minute de session, des frais d’orchestration de 8% sur ces trois postes, et le coût complet de tout workflow que l’agent déclenche. Le compute seul place une session d’agent de 60 minutes à 300 crédits avant qu’un seul token soit compté. Les workflows du canvas coûtent bien moins — 1 crédit au démarrage plus le coût par nœud, la plupart des nœuds natifs gratuits, sans frais de compute ni d’orchestration — ce qui est la raison concrète de sortir les séquences déterministes de l’agent pour les mettre dans un workflow qu’il appelle.

Les autres coûts cachés sont les habituels : 2 à 4 semaines du temps d’une personne ops pour amener les trois premiers agents à un état que vous laisseriez tourner sans surveillance, la dérive continue des crédits à mesure que les agents deviennent plus bavards, et la taxe de maintenance d’un canvas Gumloop qui dépasse la trentaine de nœuds et cesse d’être lisible.

Ce que ce stack ne remplace pas

Votre système de référence. Rien ici ne stocke l’état des clients, des candidats ou des contrats. Les agents agissent sur votre CRM, votre ATS ou votre CLM ; ils n’en deviennent pas un.
L’engineering, pour tout ce qui est transactionnel. Les mouvements d’argent, le provisionnement et tout ce qui exige une vraie frontière transactionnelle ou un engagement d’uptime relèvent de code testé, pas d’un canvas hébergé.
Un data warehouse. Clay enrichit les enregistrements à la volée. L’analyse historique, l’attribution et le reporting ont toujours besoin d’un endroit où atterrir.
La responsabilité de la décision. Le point de validation ne transfère pas la responsabilité à l’agent. Celui ou celle qui a cliqué sur approuver assume le résultat, et c’est exactement pour ça que le raisonnement doit figurer dans le message Slack et non être enterré dans un journal d’exécution.

Règles de correspondance

Utilisez ce stack quand :

Votre travail ops le plus volumineux commence sous forme de texte non structuré — boîtes de réception, candidatures, tickets, contrats — et quelqu’un lit aujourd’hui l’intégralité.
Vous avez une personne ops à l’aise sur un canvas visuel et capable de lire du JSON, mais vous n’avez pas et n’aurez pas de temps d’engineering.
Le volume est assez élevé pour que le tri humain unité par unité soit un coût réel (environ 100+ éléments par mois) et assez faible pour qu’une erreur soit rattrapable plutôt qu’un incident de conformité.
Vous savez nommer le seuil. Si vous ne pouvez pas dire ce qu’un agent a le droit de faire sans surveillance, vous n’êtes pas prêt à en faire tourner un sans surveillance.

N’utilisez pas ce stack quand :

Les étapes sont fixes et connues. Prenez n8n seul et mettez l’économie ailleurs.
La décision est encadrée par la réglementation — une mesure défavorable envers une candidate, une position juridique, tout ce qui s’accompagne d’une notification légale. Les agents peuvent rédiger et router ; un humain décide, et la piste d’audit doit le montrer.
Personne n’en est propriétaire. Un stack d’agents sans responsable désigné se dégrade en silence : les crédits grimpent, l’authentification d’une intégration expire, et la panne remonte en réclamation client des mois plus tard.
Vous cherchez encore quel est le processus. Les agents opérationnalisent une règle de décision ; ils n’en découvrent pas. Écrivez-la à la main pendant un mois d’abord.

Points de vigilance

Slack est désormais lisible par des agents, pas seulement par des humains. Le serveur MCP distant de Slack est passé en GA le 2026-02-17 sur mcp.slack.com, avec un OAuth à token utilisateur derrière un flux d’approbation de l’administration du workspace : un client approuvé lit et publie dans les permissions propres de la personne qui s’authentifie. Le canal de validation n’est plus une surface que seuls des humains voient. Garde-fou : gardez les validations dans un canal dédié dont vous pouvez nommer les membres, et approuvez les clients MCP au niveau de l’administration du workspace plutôt que de laisser chacun connecter le sien.
Apporter votre propre clé de modèle augmente les frais de plateforme de Gumloop au lieu de les réduire. Le BYOK sort les tokens de raisonnement de votre solde de crédits mais fait passer l’orchestration de 8% à 16% des crédits de chat, de compute et d’appels d’outils. Garde-fou : faites tourner le même flux dans les deux configurations sur un jeu de test de 10 lignes et lisez d’abord le tableau de bord des crédits — le BYOK ne gagne que si votre tarif modèle négocié bat la refacturation de plus que ces 8% supplémentaires.
Gumloop Pro rejette la concurrence excédentaire au lieu de la mettre en file. Au-delà de 5 exécutions de workflow simultanées, l’API renvoie HTTP 429 et les conversations d’agent échouent ; la mise en file est une fonction Enterprise, donc un lot de 500 lignes lancé en exécutions parallèles perd du travail en silence si rien ne réessaie. Garde-fou : échelonnez les triggers depuis n8n, découpez les gros travaux en sous-flux, et intégrez un retry sur 429 dans tout ce qui appelle l’API.
Le plan gratuit de Clay est un budget de pilote, pas de production. 100 data credits par mois couvrent à peu près une journée de tri réel. Garde-fou : mesurez le taux de réussite de l’étape d’enrichissement pendant le pilote et dimensionnez Launch ou Growth à partir de là, plutôt que de découvrir le plafond quand les agents décident déjà sur des données manquantes.

Variantes courantes

Remplacez Gumloop par Lindy quand le travail porte sur la boîte d’une personne et non sur la file d’une équipe. Lindy facture par utilisateur — Plus à $29,99/mois pour 3 000 crédits, Pro à $99,99 pour 15 000, Max à $199,99 pour 35 000 — avec jusqu’à 5 boîtes connectées et le computer use sur tous les plans, et des crédits mutualisés à l’échelle du workspace. La règle : l’email, l’agenda et les relances d’un dirigeant → Lindy ; une file partagée sur laquelle plusieurs personnes construisent → Gumloop, dont les sièges sont illimités.
Retirez Clay quand les agents ne touchent que des données qui vous appartiennent déjà. Le tri des tickets de support, la revue de contrats et le travail sur les documents internes n’ont besoin d’aucun enrichissement externe, et Clay est la plus grosse ligne retirable du stack. Remettez-le le jour où un agent commence à décider au sujet d’entreprises ou de personnes qui ne sont pas encore dans votre CRM.
Repliez-vous sur n8n seul le jour où vous gagnez quelqu’un qui construit. Si un recrutement technique arrive, le nœud AI Agent absorbe la couche Gumloop et le coût récurrent retombe à un VPS. C’est un vrai recul sur la question de qui peut maintenir — faites-le quand la personne est dans l’équipe, pas quand elle est dans le plan de recrutement.
Remplacez Slack par Microsoft Teams. La surface de validation a la même forme et n8n dispose d’un nœud Teams de premier ordre. Ce que vous perdez, c’est la voie MCP de Slack évoquée plus haut : la lecture du fil de validation côté agent redevient une intégration sur mesure.

Pour les schémas d’agents concrets que ce stack fait tourner, voyez le tri des leads inbound, le tri des demandes de NDA et l’enrichissement de leads avec Clay et Claude. Pour le concept sous-jacent, les agents IA pour les ops explique ce qui sépare un agent d’un script planifié.

Modifier cette page sur GitHub