Pourquoi Zapier désactive un Zap tout seul (et comment le réactiver)

Les deux seuils qui coupent un Zap automatiquement

Zapier documente la règle sur deux pages d’aide différentes, avec une formulation légèrement différente à chaque fois. En les recoupant, la règle réelle est celle-ci : la désactivation se déclenche quand, sur une fenêtre glissante de 7 jours, un Zap a été exécuté plus de 20 fois et qu’au moins 95 % de ces exécutions se sont soldées par une erreur. Le seuil de volume (20 exécutions) évite qu’un Zap tout juste activé et qui échoue une fois sur un seul essai soit coupé par excès de prudence.

Sur un compte Team ou Enterprise, franchir ce seuil déclenche d’abord un e-mail au titulaire du compte et un délai de grâce — 24 heures en Team, 72 heures en Enterprise — avant la coupure effective. Les comptes Free et Professional n’ont pas ce délai : la coupure est immédiate. Zapier propose aussi, sur les plans Professional, Team et Enterprise (pas Free), une option « ignorer le taux d’erreur » qui maintient le Zap actif malgré des échecs répétés — à activer en connaissance de cause, puisqu’elle supprime aussi le délai de grâce.

Ce qu’aucune source ne dit isolément : la coupure sans erreur visible

La documentation officielle explique bien le seuil des 95 %, mais elle explique aussi, dans le même souffle, que trois statuts de run — halte volontaire, mise en attente, erreur gérée — sont conçus pour ne jamais déclencher la coupure. Mis bout à bout, cela veut dire qu’un Zap qui semble mort sans qu’aucune erreur n’apparaisse dans son historique n’a, la plupart du temps, pas touché le seuil 95 %/20 exécutions : il est simplement resté « en attente » (compte déconnecté, quota de tâches épuisé) ou arrêté volontairement par un step de recherche sans résultat.

Le forum officiel Zapier documente un troisième cas que la page d’aide sur la désactivation ne mentionne pas : des Zaps sur compte payant, sans aucune erreur visible dans l’historique, qui repassent sur « off » juste après avoir été réactivés. Dans un fil de discussion resté sans réponse définitive, un partenaire Solution Zapier avance la piste la plus documentée dans ce genre de cas : une limite propre à l’application connectée elle-même — par exemple un plafond d’abonnements webhook — qui bloque le Zap sans jamais remonter comme une erreur dans les journaux de Zapier, puisque le blocage se produit du côté de l’app tierce. Ni Zapier ni l’app tierce ne l’affichent clairement : c’est un angle mort qui n’est écrit sur aucune des deux documentations séparément, et qui explique pourquoi certains utilisateurs contactent le support sans qu’aucune des causes officielles ne corresponde à leur cas.

Comment Tooli vérifie : je pars de la documentation officielle de l’outil, jamais d’un forum isolé pris pour argent comptant. Ici, les deux pages d’aide Zapier citées se recoupent sur le seuil 95 %/20 exécutions ; le cas du Zap qui coupe sans erreur visible reste, lui, un signalement communautaire non tranché par Zapier — je le présente comme tel, pas comme une règle officielle.

Comment réactiver un Zap coupé, dans l’ordre

1. Identifier le vrai statut du dernier run

Avant de chercher une erreur, ouvrez l’historique du Zap et regardez le statut exact du dernier run : « Erreur » n’est pas la même chose qu’« En attente » ou « Halte volontaire ». Un Zap « en attente » n’a pas été désactivé par le seuil 95 % — il attend une reconnexion, un quota de tâches disponible, ou la fin d’une protection anti-flood.

2. Lire le code HTTP de l’erreur avant d’agir

Un code 401 signale presque toujours un jeton d’accès expiré ou révoqué : il suffit de déconnecter puis reconnecter le compte de l’application concernée. Un code 429 indique que la limite de requêtes de Zapier ou de l’application a été dépassée — la solution documentée est d’espacer les déclenchements, pas de relancer en boucle. Un code 500 isolé se résout souvent tout seul en rejouant le run (« Replay ») ; s’il se répète sur chaque exécution, la page de statut de Zapier et celle de l’application connectée permettent de vérifier une panne en cours avant d’aller plus loin.

3. Vérifier que le plan couvre bien les fonctions utilisées

Un Zap multi-étapes, un Zap avec des chemins conditionnels (paths), ou un Zap qui utilise une application premium ne tournera pas sur un compte dont le plan ne couvre pas ces fonctions : ses actions restent « en attente » jusqu’à une mise à niveau. Si le compte a atteint son quota de tâches du cycle de facturation, c’est l’ensemble des Zaps du compte qui se met en attente, pas seulement celui qu’on regarde — un symptôme à vérifier avant de chercher une cause isolée. Notre comparatif Zapier, Make ou n8n : comment choisir détaille les seuils de plan de chacun, et notre article sur ce qu’un scénario Make consomme vraiment en crédits montre l’équivalent côté quotas chez ce concurrent.

4. Éviter la prochaine coupure plutôt que de la subir

Deux réglages, documentés par Zapier, réduisent le risque de retomber sur le même seuil : l’Autoreplay, qui retente automatiquement une exécution ayant échoué pour une raison ponctuelle (panne courte, dépassement de délai), et le gestionnaire d’erreur personnalisé, qui déclenche un scénario de secours plutôt que de laisser l’échec compter dans le taux de 95 %. Les deux évitent qu’une panne d’une heure chez un fournisseur tiers fasse basculer tout un flux de travail en « off » du jour au lendemain.

Questions fréquentes

Pourquoi mon Zap s’est-il désactivé sans que j’aie rien changé ?
Le plus souvent parce qu’il a tourné plus de 20 fois sur 7 jours en échouant dans au moins 95 % des cas — le déclencheur automatique documenté par Zapier. Vérifiez l’historique du Zap pour identifier le code d’erreur exact avant de le réactiver.

Mon Zap n’affiche aucune erreur mais reste sur « off », que faire ?
Regardez d’abord si le statut réel est « en attente » (compte déconnecté, quota de tâches atteint) plutôt que « désactivé » : les deux se ressemblent mais ne se réparent pas de la même façon. Si l’historique est réellement vide d’erreurs, la cause vient parfois de l’application connectée elle-même plutôt que de Zapier ; contacter le support des deux services aide à trancher.

Le plan gratuit de Zapier a-t-il un délai de grâce avant la coupure ?
Non. Seuls les comptes Team (24 heures) et Enterprise (72 heures) reçoivent un e-mail d’alerte et un délai avant la désactivation effective. Sur les autres plans, la coupure est immédiate dès que le seuil est atteint.

Notre avis

Avant de rouvrir un ticket support, trois vérifications suffisent dans la grande majorité des cas : le statut exact du dernier run (erreur, en attente, ou halte volontaire), le code HTTP affiché dans les logs, et le quota du plan en cours. Si les trois sont propres et que le Zap coupe quand même sans erreur visible, le blocage est probablement du côté de l’application connectée — un point que la documentation Zapier ne couvre pas, et où seul le support de l’app tierce peut confirmer. Pour un flux critique, l’Autoreplay et un gestionnaire d’erreur personnalisé coûtent quelques minutes à configurer et évitent la plupart des coupures évitables.

Méthode : nous n’avons pas recréé ces pannes nous-mêmes. Ces informations recoupent la documentation officielle d’aide Zapier et un fil de discussion du forum communautaire Zapier, à la date indiquée en tête d’article. Le cas du Zap qui coupe sans erreur visible est présenté comme un signalement communautaire, pas comme une règle documentée par Zapier.

Sources : Zapier — Zap is not running · Zapier — How to troubleshoot errors in Zap workflows · Zapier Community — Zap automatically turning off even though no errors.

Envie de comparer d’autres outils pour votre activité ? Toutes nos recommandations à jour sont sur cette page.