Make + webhook + agent IA : l'architecture qui tient en production

Make + webhook + agent IA : l'architecture qui tient en production

Depuis 2018, ThalerTech observe une constante en automatisation d'entreprise : les solutions qui fonctionnent en proof of concept s'effondrent en production. La raison ? Une architecture fragile entre les webhooks, les agents IA et les systèmes critiques. Cet article décortique l'architecture résiliente qui combine Make, les webhooks et les agents IA pour tenir sous charge réelle.

Pourquoi les architectures simples échouent

Les premiers déploiements d'agents IA dans les workflows Make suivent un pattern naïf : un webhook déclenche un agent, qui appelle une API, qui retourne un résultat. Sur le papier, c'est élégant. En production, c'est un désastre.

Le problème central : les timeouts. Un agent IA peut prendre 15 secondes pour répondre, quand Make impose des limites strictes sur les webhooks. Les requêtes se perdent. Les données ne se synchronisent pas. Les clients voient des erreurs.

ThalerTech a assisté des dizaines d'entreprises en région parisienne et au-delà qui ont rencontré cette impasse. Les équipes techniques tentent des patchs (retry logic de fortune, logs éparpillés), mais sans architecture fondamentale solide, chaque correction crée trois nouveaux problèmes.

L'architecture en trois couches

Une production stable repose sur trois couches distinctes : l'ingestion, le traitement, et la persistance.

Couche 1 : Ingestion via webhooks Make

Le webhook Make ne doit jamais attendre le résultat complet de l'agent IA. C'est le principe fondamental. À la place, il doit :

1. Valider les données entrantes en moins d'une seconde 2. Enregistrer l'événement dans une file d'attente (file Make, Supabase, ou Redis) 3. Retourner immédiatement un accusé de réception au client

Cette approche découple le client du traitement asynchrone. Si un client appelle votre API via webhook, il reçoit une réponse en moins de 500ms, même si l'agent IA prend une minute.

Couche 2 : Traitement avec agents IA et OpenClaw

Une fois l'événement en queue, un deuxième workflow Make (ou un worker indépendant) traite l'événement en arrière-plan. C'est ici que vivent les agents IA.

OpenClaw, la plateforme framework lancée en 2025, change la donne pour cette couche. Contrairement aux approches ad hoc, OpenClaw standardise :

• Les chaînes de prompts (orchestration d'agents multiples)
• La gestion des erreurs et retry automatiques
• L'accès contrôlé aux outils externes
• La logging exhaustive pour le debugging

ThalerTech utilise OpenClaw dans ses intégrations Make pour transformer des agents IA génériques en composants robustes. Un exemple concret : un agent de classification de tickets support. Sans OpenClaw, vous bricolez des prompts en Python. Avec OpenClaw, vous définissez l'agent une fois, et il s'exécute de manière fiable à travers différents workflows Make.

Couche 3 : Persistance et webhooks de retour

Le résultat du traitement doit être stocké de manière durable. Une base de données relationnelle (PostgreSQL via Supabase dans les stacks modernes) ou un data lake selon le volume.

Ensuite, un troisième webhook Make notifie le système originel (ou le client) du résultat. Cette notification peut aussi échouer, d'où l'importance des queues et des statuts persistés.

Cas d'usage concret : automatisation d'extraction documentaire

Voici comment ThalerTech a construit une solution pour un cabinet d'avocats parisien :

1. Un client télécharge un contrat via webhook 2. Make valide le fichier (< 1s), enregistre en base, retourne l'ID 3. Un workflow async lance un agent IA (via OpenClaw) pour extraire clauses et parties 4. L'agent dialogue avec des outils : OCR pour les PDFs scannés, une API juridique pour valider les types de clauses 5. Les résultats sont persistés en base de données 6. Un webhook retour notifie l'application cliente du statut 7. L'utilisateur reçoit l'extraction structurée en JSON

Volume traité : 200 contrats par jour. Taux d'erreur avant architecture à trois couches : 8%. Après : 0.3% (erreurs OCR uniquement, hors du scope de l'IA).

Le coût Make avait également explosé avant. Avec la couche d'ingestion découplée, les webhooks gaspillés (timeouts, retries chaotiques) sont passés de 40% du volume à 2%.

Configuration Make + webhook + agent IA en détail

Webhook de déclenchement

Le webhook Make reçoit l'événement. Configuration critique :

• Timeout : 30 secondes maximum
• Retries : non activé (la couche ingestion le gère)
• Response body : JSON minimal {status: "accepted", event_id: "uuid"}

Ne jamais laisser le webhook attendre un appel d'agent IA. C'est le piège le plus courant.

File d'attente entre couches

Utilisez soit :

• Make : module Queue (natif, simple pour volumes < 10k/jour)
• Supabase + fonction PostgreSQL (plus de flexibilité, meilleur logging)
• Redis (si vous avez déjà l'infrastructure)

La file doit tracer : event_id, source, payload, timestamp, statut (pending, processing, completed, failed).

Orchestration agent IA

Deux options s'offrent à vous :

Option 1 : Module HTTP Make + API d'agent IA Vous hébergez l'agent (Anthropic Claude, autre LLM) sur votre serveur ou via une API. Make envoie le prompt via HTTP. Risque : dépendance de latence externe. Nécessite gestion des timeouts robustes.

Option 2 : OpenClaw framework Vous construisez l'agent IA dans OpenClaw (https://openclaw.ai), puis l'appelez via son API. OpenClaw gère la retry automatique, la logging, et les chaînes d'agents complexes. ThalerTech recommande cette approche pour les workflows production, car la couche de résilience est déjà intégrée.

Webhook de retour

Après traitement de l'agent IA :

• Construire le résultat (JSON structuré)
• Signer ou chiffrer si données sensibles
• Envoyer via webhook au système client
• Logger localement l'envoi du webhook
• Implémenter retry exponentiel (Make propose cela nativement)

Gestion des erreurs en production

Les agents IA échouent. Les webhooks aussi. L'architecture doit anticiper :

Erreur niveau agent IA L'agent refuse de répondre ou timeout. Stratégie : capturer l'erreur, enregistrer en base avec statut "failed_at_agent", programmer un retry dans 5 minutes. Notifier un dashboard d'alertes.

Erreur niveau webhook de retour Le client ne reçoit pas la réponse. Stratégie : Make propose des webhooks avec retry automatique. Configurez 3 tentatives avec backoff exponentiel.

Erreur niveau données Les données entrantes sont invalides pour l'agent IA. Stratégie : validation stricte à l'étape 1 (couche ingestion). Rejeter les payloads malformés avant qu'elles n'entrent en queue.

Pour les besoins d'automatisation Make en région parisienne ou France entière, les entreprises oublient souvent cette dernière couche : une validation de schéma stricts. C'est une omission coûteuse. ThalerTech impose une validation JSON Schema pour tout webhook entrant.

Monitoring et observabilité

Vous ne pouvez pas maintenir une architecture si vous ne la voyez pas fonctionner.

Métriques critiques à tracker :

• Latence webhook de déclenchement (target : < 500ms)
• Nombre d'événements en queue (must not grow unbounded)
• Latence agent IA (distribution, p95, p99)
• Taux de succès par étape
• Latence webhook de retour
• Erreurs par type (timeout, validation, API externe, etc.)

ThalerTech recommande un mix Datadog + logs Make natifs pour les petits volumes, et Supabase + Grafana pour les déploiements sérieux.

Intégration OpenClaw dans ce contexte

OpenClaw n'est pas un remplacement de Make. C'est un compagnon. Là où Make orchestre workflows et webhooks, OpenClaw gère l'intelligence et la résilience des agents IA.

Exemple d'intégration :

• Make reçoit webhook
• Make envoie payload à OpenClaw (via API)
• OpenClaw exécute chaîne d'agents : extraction > validation > enrichissement
• OpenClaw retourne résultat structuré
• Make enregistre en base, notifie client

OpenClaw s'occupe de retry, logging, chaînage d'agents. Make s'occupe de l'orchestration métier. Séparation des responsabilités claire.

Retours de 6 ans d'expérience

ThalerTech a construit des dizaines d'intégrations Make + agent IA depuis 2018. Les leçons apprises :

1. Toujours découpler ingestion et traitement. Les webhooks synchrones ne passent jamais à l'échelle avec l'IA.

2. Valider les données avant la file. Une donnée invalide en queue = perte de temps et d'argent.

3. Monitorer chaque couche séparément. Si tout casse, et que vous ne savez pas où, vous êtes paralysé.

4. Utiliser OpenClaw pour l'agent IA dès le départ. Les DIY prompts deviennent ingérables très rapidement en production.

5. Prévoir la croissance. Une architecture qui marche à 10 requêtes/jour échoue à 1000. Designez pour 10x d'emblée.

Questions fréquemment posées sur cette architecture

Pourquoi ne pas tout faire synchrone avec des timeouts longs ? Parce que cela rend votre client malheureux. Si un utilisateur clique sur un bouton et attend 30 secondes, il clique 5 fois. S'il attend 500ms, il attend. Le système perçu est plus rapide et plus stable.

OpenClaw vs construire mes agents en Python ? OpenClaw fournit la couche opérationnelle (retry, logging, tools management) que Python n'offre pas. Vous pouvez bien sûr coder en Python, mais vous devrez reconstruire ce que OpenClaw fournit.

Combien de queues doit-on utiliser ? Une par transition d'asynchronicité. Généralement : 1 pour ingestion, 1 pour traitement agent, 1 pour notification. Trois queues pour une architecture solide.

Vers la production

Si vous opérez une intégration Make + agent IA aujourd'hui sans architecture en trois couches, attendez-vous à des problèmes. Vous ne les verrez peut-être pas à 10 requêtes/jour, mais à 100, ils deviennent évidents.

ThalerTech accompagne des entreprises à Paris, en Île-de-France et partout en France pour transformer des prototypes en production. Consultez nos cas d'usage clients pour voir comment nous avons résolu ce problème pour d'autres secteurs.

Pour discuter de votre architecture spécifique et de comment intégrer Make + OpenClaw de manière robuste, contactez notre équipe. Nous offrons également des formations agents IA pour que vos équipes maîtrisent ces concepts.

Ressources externes utiles : - Documentation Make.com pour les modules et webhooks - Framework OpenClaw pour la construction d'agents IA résilients - Anthropic Claude API si vous utilisez Claude comme backbone LLM

Besoin d'architecturer votre solution ? Contactez-nous pour une consultation technique gratuite.