Deluge : contourner les limites de 10 s, 30 s et 15 min avec Zoho Catalyst

L'essentiel

Dans Zoho CRM, une fonction Deluge est arrêtée net au bout de 10 secondes si elle part d'un bouton, de 30 secondes si elle part d'un workflow, et de 15 minutes si elle est planifiée. Ces limites ne se négocient pas.

Il existe trois parades, dans cet ordre : optimiser le code, déplacer le travail vers une fonction planifiée qui traite une file d'attente, puis confier les traitements lourds à Zoho Catalyst. Catalyst ne supprime pas toute limite, mais il permet de découper un gros traitement en lots exécutés en parallèle, avec des reprises automatiques.

En bref

• 10 s pour un bouton, 30 s pour un workflow, 15 min pour une fonction planifiée.
• Un appel à un modèle d'IA prend souvent plusieurs secondes : il ne tient pas dans un bouton.
• Avant Catalyst, une file d'attente dans le CRM et une fonction planifiée règlent beaucoup de cas.
• Dans Catalyst, une fonction HTTP répond en 30 s au plus et une fonction Job tourne 15 min au plus : on découpe en lots.
• Catalyst dispose d'un centre de données européen et d'un palier gratuit mensuel.

Les limites exactes de Deluge dans Zoho CRM

La durée maximale dépend de ce qui déclenche la fonction. Au-delà, Zoho l'arrête de force (Zoho).

Déclencheur	Durée maximale
Bouton, règle de validation, liste associée, appel par API REST	10 secondes
Workflow, processus guidé (blueprint), approbation	30 secondes
Fonction planifiée	15 minutes

D'autres plafonds s'appliquent à chaque exécution ou à toute l'organisation :

Limite	Valeur
Lignes exécutées par appel, boucles comprises	200 000
Taille de la valeur renvoyée	10 Mo
Appels invokeurl par jour, pour l'organisation	5 000 000
E-mails envoyés par jour, pour l'organisation	50 000
Crédits de fonctions en Enterprise, sur 24 h glissantes	20 000 plus 500 par licence

Deux précisions utiles. Les fonctions ne sont accessibles directement qu'à partir de l'édition Enterprise ; en Standard et Professional, elles passent par des extensions. Et chaque appel zoho.crm.* fait dans une fonction consomme aussi des crédits d'API, comme nous l'expliquons dans notre guide des limites de l'API Zoho CRM.

Pourquoi vos fonctions dépassent

Le code Deluge est rarement lent en lui-même. Ce qui consomme le temps, ce sont les allers-retours. Six causes reviennent presque toujours :

1. Un appel externe dans une boucle. Un invokeurl par enregistrement, à une demi-seconde chacun : 60 enregistrements suffisent à atteindre la limite d'un workflow.
2. Une lecture CRM par enregistrement. Aller chercher chaque fiche avec un appel séparé au lieu d'une seule requête groupée.
3. Un appel à un modèle d'IA. Une réponse de plusieurs secondes, parfois plus de dix. Placé derrière un bouton, il échoue au hasard selon la charge du service.
4. Un traitement de masse lancé par un workflow. Un import de 5 000 lignes déclenche 5 000 workflows, chacun avec sa propre limite et ses propres crédits.
5. Un service externe lent ou instable. Une API qui répond en 8 secondes un jour de pointe fait tomber un bouton qui marchait la veille.
6. Des boucles imbriquées sur de gros volumes. Elles atteignent le plafond de 200 000 lignes exécutées avant même la limite de temps.

Le symptôme est trompeur : la fonction marche en test, sur trois enregistrements, puis échoue en production, sur trois cents. Testez toujours avec un volume réaliste.

Optimiser avant de déménager

Quatre techniques règlent la majorité des dépassements sans quitter Zoho CRM.

1. Grouper les lectures. Une requête COQL ramène jusqu'à 2 000 lignes en un seul appel. Voir notre guide COQL.
2. Grouper les écritures. Mettez à jour jusqu'à 100 enregistrements par appel au lieu d'un par un.
3. Sortir les données de référence des boucles. Barèmes, grilles de prix, tables de correspondance : lisez-les une fois avant la boucle, pas à chaque tour.
4. Transformer le bouton en file d'attente. Le bouton ou le workflow ne fait plus le travail : il marque l'enregistrement « à traiter ». Une fonction planifiée, qui dispose de 15 minutes, traite ensuite la file par paquets.

La quatrième technique est la plus puissante. Voici son squelette :

// Fonction planifiée, toutes les 15 minutes : traite la file d'attente des affaires.
// Champ personnalisé Statut_traitement (liste de choix) : "A traiter", "Traite".
affaires = zoho.crm.searchRecords("Deals","(Statut_traitement:equals:A traiter)",1,100);
mises_a_jour = list();
for each affaire in affaires
{
	// ... votre calcul, sans appel externe dans la boucle si possible
	maj = Map();
	maj.put("id",affaire.get("id"));
	maj.put("Statut_traitement","Traite");
	mises_a_jour.add(maj);
}
if(mises_a_jour.size() > 0)
{
	paquet = Map();
	paquet.put("data",mises_a_jour);
	// Une seule écriture groupée : 100 enregistrements au maximum par appel
	reponse = invokeurl
	[
		url :"https://www.zohoapis.eu/crm/v8/Deals"
		type :PUT
		parameters:paquet.toString()
		connection:"zoho_crm"
	];
	info reponse;
}

L'utilisateur clique, reçoit immédiatement une confirmation, et le résultat apparaît au passage suivant de la fonction planifiée. Pour aller plus vite, enchaînez plusieurs paquets dans une même exécution, tant qu'elle reste loin des 15 minutes.

Cette approche atteint ses limites quand il faut une bibliothèque que Deluge n'a pas, des appels d'IA par centaines, ou des traitements en parallèle. C'est là que Catalyst devient utile.

Déléguer à Catalyst : le principe

Zoho Catalyst est la plateforme serverless de Zoho : vous y déployez des fonctions en Node.js, Python ou Java, appelées par le CRM ou planifiées (Catalyst).

Soyons honnêtes sur un point : Catalyst a lui aussi des limites. Une fonction HTTP de type Advanced I/O répond en 30 secondes au plus. Une fonction Job tourne 15 minutes au plus, une valeur fixe (Catalyst). Ce que Catalyst apporte est ailleurs :

• Découper et paralléliser. Un traitement de 5 000 enregistrements devient 50 jobs de 100, exécutés dans une file de jobs (job pool).
• Reprendre automatiquement. Chaque job peut être relancé en cas d'échec, avec un nombre d'essais et un délai que vous fixez.
• Utiliser un vrai langage. Bibliothèques npm ou Python, SDK des services d'IA, parsing de fichiers lourds.
• Observer. Journaux d'exécution et suivi des performances, là où Deluge n'offre que peu de visibilité.

Les types de fonctions utiles pour décharger le CRM :

Type	À quoi il sert ici
Advanced I/O	Point d'entrée HTTP appelé par Zoho : il reçoit la demande, découpe le travail et répond tout de suite
Job	Exécute un lot de travail, jusqu'à 15 minutes, avec reprises automatiques
Cron	Lance un traitement à heure fixe ou de façon récurrente
Event	Réagit à des événements configurés dans Catalyst Signals

Un piège pour les entreprises européennes : les fonctions de type Integration ne sont pas disponibles sur le centre de données européen de Catalyst. L'architecture ci-dessous ne les utilise pas.

Exemple : un workflow qui confie un traitement long à Catalyst

Le scénario : un bouton du CRM doit recalculer 2 000 affaires, avec un appel à un service externe pour chacune. Impossible en 10 secondes. Le circuit devient :

1. le bouton envoie la liste des identifiants à Catalyst et rend la main ;
2. une fonction Advanced I/O découpe la liste en lots de 100 et soumet un job par lot ;
3. une fonction Job traite chaque lot et écrit le résultat dans le CRM.

Côté CRM, le bouton en Deluge :

// Bouton : confie le traitement à Catalyst et rend la main tout de suite.
// ids : liste des identifiants à traiter, obtenue par exemple par une recherche groupée.
corps = Map();
corps.put("ids",ids);
entetes = Map();
entetes.put("Content-Type","application/json");
entetes.put("X-Secret",zoho.crm.getOrgVariable("secret_catalyst"));
reponse = invokeurl
[
	url :"https://VOTRE-DOMAINE-CATALYST/server/lanceur/lancer"
	type :POST
	parameters:corps.toString()
	headers:entetes
];
info reponse;
return "Traitement lancé : les affaires seront mises à jour dans quelques minutes.";

Côté Catalyst, la fonction Advanced I/O avec Express :

// Reçoit les identifiants, découpe en lots de 100, soumet un job par lot.
// jobScheduling : instance du composant Job Scheduling, créée comme l'indique le SDK Catalyst.
const express = require('express');
const app = express();
app.use(express.json());
app.post('/lancer', async (req, res) => {
  if (req.get('X-Secret') !== process.env.SECRET_CRM) {
    return res.status(403).end();
  }
  const ids = Array.isArray(req.body.ids) ? req.body.ids : [];
  for (let i = 0; i < ids.length; i += 100) {
    await jobScheduling.JOB.submitJob({
      job_name: `recalcul_${Date.now()}_${i}`,
      jobpool_name: 'traitements_crm',
      target_type: 'Function',
      target_name: 'traiter_lot',
      params: { ids: ids.slice(i, i + 100).join(',') },
      job_config: { number_of_retries: 2, retry_interval: 15 * 60 }
    });
  }
  res.status(202).json({ lots: Math.ceil(ids.length / 100) });
});
module.exports = app;

Côté Catalyst, la fonction Job qui traite un lot :

// Fonction Job (Node.js 18) : traite un lot, 15 minutes au maximum.
// traiterAffaire() contient votre logique : appel externe, calcul, écriture CRM.
module.exports = async (jobRequest, context) => {
  const ids = String(jobRequest.getJobParam('ids') || '').split(',').filter(Boolean);
  try {
    for (const id of ids) {
      // Marge de sécurité : on s'arrête une minute avant la limite
      if (context.getRemainingExecutionTimeMs() < 60000) {
        throw new Error('Temps presque écoulé');
      }
      await traiterAffaire(id);
    }
    context.closeWithSuccess();
  } catch (erreur) {
    console.log(erreur.message);
    context.closeWithFailure(); // le job sera relancé selon job_config
  }
};

Deux règles rendent ce montage sûr. Chaque traitement doit pouvoir être rejoué sans dommage, puisqu'un job en échec est relancé en entier. Et la taille des lots doit tenir largement dans les 15 minutes : mesurez la durée d'un lot en test, puis gardez une marge d'un facteur trois.

Le code utilise l'appel submitJob documenté par Zoho (Catalyst). Les noms traitements_crm, traiter_lot et lanceur sont à remplacer par les vôtres.

Coût, hébergement et alternatives

Le coût. Catalyst se paie à l'usage, avec un palier gratuit renouvelé chaque mois et des crédits d'essai valables six mois. Dans un exemple publié par Zoho, le palier gratuit couvre 25 000 Go-secondes d'exécution de fonctions par mois (Catalyst). Au-delà, une facturation minimale s'applique, et des alertes de budget permettent de couper le service avant un dépassement. Estimez votre consommation avec le calculateur de Zoho avant de vous lancer : la durée et la mémoire de chaque exécution comptent autant que leur nombre.

L'hébergement. Catalyst propose des centres de données en Inde, aux États-Unis et en Europe (NewsBytes). Pour une PME française dont le CRM est sur le centre européen de Zoho, créez le projet Catalyst au même endroit.

La version 3.0. Lancée le 2 septembre 2026, elle ajoute des compétences pour les assistants de code comme Claude Code et Codex, le support du protocole MCP, et ouvre le code de son SDK et de sa ligne de commande (CXOToday). Notre guide Catalyst détaille ces nouveautés.

Les alternatives. Rien n'oblige à utiliser Catalyst : n'importe quel serveur capable de recevoir un appel HTTP et de faire tourner une file de tâches fait l'affaire, par exemple un serveur PHP chez OVH. Catalyst a pour lui l'intégration native à Zoho et l'absence de serveur à administrer ; un serveur classique, la liberté de langage et de durée d'exécution.

Faire débloquer vos fonctions

Une fonction qui dépasse ses limites se corrige souvent en quelques heures quand il s'agit de grouper des appels, et en quelques jours quand il faut passer à une file d'attente ou à Catalyst. Commencez par mesurer : quel déclencheur, combien d'enregistrements, combien d'appels externes.

Vos fonctions Deluge s'arrêtent à 10 ou 30 secondes ?

SquadNovia identifie ce qui consomme le temps, réécrit la fonction ou la déplace vers une fonction planifiée ou vers Catalyst, et vous livre le code commenté. Une banque de 10 heures couvre la plupart des corrections ; une architecture Catalyst fait l'objet d'un devis.

Banque d'heures ou devis

Questions fréquentes

Peut-on augmenter la limite de 30 secondes d'un workflow ?

Non. La durée dépend du déclencheur et ne se règle pas. Il faut raccourcir la fonction ou déplacer le travail ailleurs.

Une fonction planifiée peut-elle dépasser 15 minutes ?

Non. Pour les traitements plus longs, découpez en paquets traités à chaque passage, ou en jobs Catalyst exécutés en parallèle.

Pourquoi ma fonction marche en test et échoue en production ?

Parce que le volume change tout : trois enregistrements passent sous la limite, trois cents la dépassent. Testez avec un volume réaliste et mesurez la durée par enregistrement.

Un appel à ChatGPT, Claude ou Mistral peut-il partir d'un bouton ?

C'est risqué : une réponse de modèle d'IA prend souvent plusieurs secondes et dépasse parfois dix. Lancez l'appel en arrière-plan et écrivez le résultat dans la fiche quand il arrive.

Faut-il connaître Node.js pour utiliser Catalyst ?

Node.js, Python ou Java. Les fonctions Java et Python se développent avec la ligne de commande et un éditeur externe, pas directement dans la console.

Catalyst garde-t-il mes données en Europe ?

Catalyst dispose d'un centre de données européen. Créez votre projet dans la même région que votre compte Zoho, et notez que les fonctions de type Integration n'y sont pas disponibles.

Sources

Pages consultées le 20 octobre 2026.

• Zoho CRM : limites et quotas des fonctions
• Catalyst : introduction aux fonctions
• Catalyst : fonctions Advanced I/O
• Catalyst : fonctions Job
• Catalyst : soumettre un job, SDK JavaScript
• Catalyst : tarifs
• CXOToday : lancement de Catalyst 3.0
• NewsBytes : Catalyst 3.0 et ses centres de données