Comment résoudre l’erreur quota exceeded sur Make.com ?

Ce que le message d’erreur « quota exceeded » veut vraiment dire

Pourquoi votre scénario s’arrête brutalement : lire le message complet avant tout

Quand un scénario Make.com plante, on regarde le titre de l’erreur. C’est une erreur. Le message complet contient le nom du module, le code HTTP et le service concerné. Prenez trente secondes pour ouvrir les détails de l’exécution. Vous y verrez un indice décisif : le quota dépassé vient-il de Google, d’un serveur SMTP ou de la boîte du destinataire ?

Les trois familles de quotas : API, serveur SMTP et boîte mail pleine

Dans ma pratique, je classe les erreurs en trois familles. Le quota API, d’abord : le fournisseur limite le nombre de requêtes par minute ou par jour. Le quota SMTP, ensuite : votre hébergeur plafonne le volume d’e-mails sortants sur une heure. Le dernier est plus vicieux : la boîte du destinataire est pleine, et Make.com affiche une erreur qui ressemble à un problème d’envoi.

Le piège des petits volumes : comment 5 mails déclenchent un quota dépassé

« J’ai envoyé à peine 5 e-mails et j’ai l’erreur ». Je l’entends souvent. Le volume n’est pas en cause : c’est le nombre de connexions ou la fréquence d’appels qui dépasse la limite. Un scénario qui boucle sur 3 000 lignesGoogle Sheets peut ainsi consommer 100 requêtes en une minute. Le quota est dépassé, même si vous n’avez envoyé que quelques messages.

Comprendre le code HTTP : 429, 403, 550, 552

Le code réglé est votre meilleur ami. Un 429 signale un dépassement de requêtes sur une courte période : il faut attendre. Un 403 indique une limite long terme ou une permission refusée. Le 550 5.7.0 correspond souvent à un plafond SMTP chez l’hébergeur. Enfin, le 552 révèle une boîte mail saturée. Voici un tableau de synthèse :

Diagnostic express : identifier le service fautif en 2 minutes

Vérifier le module en erreur et son code exact dans les logs du scénario

Ouvrez l’historique des exécutions, puis cliquez sur le module en rouge. Le message d’erreur brut contient toujours le code. Notez-le avant de chercher une solution. C’est le réflexe que j’enseigne à tous les dirigeants que j’accompagne.

Tester la limite API avec un appel manuel : l’exemple Google Sheets

Pour savoir si l’API est vraiment saturée, utilisez un module HTTP avec une méthode GET sur l’endpoint concerné. Si vous obtenez un 429, le fournisseur confirme le blocage. Avec Google Sheets, vous pouvez aussi consulter le rapport des quotas dans la console Google Cloud de votre compte.

Tester le serveur SMTP et les blocages du fournisseur (OVH, Gmail)

Si l’erreur mentionne SMTP, testez l’envoi manuellement dans votre boîte mail ou via une commande Telnet. Chez OVH, le plafond est souvent fixé à 200 messages par heure et par adresse. Chez Gmail, la limite est plus généreuse, mais les pièces jointes peuvent déclencher un refus. Notez la réponse du serveur SMTP : elle est souvent explicite.

Utiliser le tableau de bord Make.com pour surveiller la consommation

Votre tableau de bord Make.com affiche la colonne Operations et le nombre de requêtes consommées sur la période. Cette donnée vous permet de comprendre si le problème vient de votre scénario ou d’une limite globale du plan. Le compteur se réinitialise chaque mois, mais les quotas des fournisseurs, eux, suivent leur propre rythme.

Le cas des fichiers temporaires et des corbeilles : un faux quota fréquent

Une erreur quota exceeded peut aussi venir d’un espace de stockage saturé. Vérifiez la corbeille de votre Google Drive, les fichiers temporaires générés par vos modules et les pièces jointes accumulées. Dans plusieurs cas, j’ai résolu le problème simplement en vidant une corbeille oubliée.

Les correctifs immédiats pour résoudre le problème et relancer les envois

Ajouter un module Sleep/attente : quelques minutes peuvent suffire

Pour un quota API courte durée, insérez un module Sleep de 60 secondes avant l’appel. Votre scénario ralentit, mais il ne plante plus. C’est une solution temporaire idéale pour faire repartir une automatisation en production. Découvrez par exemple comment automatiser la relance des factures impayées.

Configurer un gestionnaire d’erreurs avec nouvelle tentative automatique

Make.com permet de brancher un module Error handler sur une route. Utilisez-le pour relancer automatiquement l’opération après un délai. Le backoff exponentiel fonctionne bien : après 1 minute, puis 2 minutes, puis 4 minutes, et ainsi de suite. Vous évitez de rester bloqué pendant des heures.

Filtrer les nouvelles lignes pour ne plus traiter tout l’historique

Un scénario qui reprend tout l’historique consomme un nombre de requêtes énorme. Ajoutez un filtre sur une date ou sur un champ statut pour ne traiter que les nouvelles données. Cette simple condition réduit souvent la charge de 90 %.

Découper les traitements en lots pour rester sous la limite de requêtes

Au lieu de traiter 3 000 lignes en une fois, découpez-les en lots de 100 ou 200. Vous pouvez même utiliser un module de répétition qui patiente entre chaque lot. C’est moins rapide, mais plus fiable.

Vider la boîte mail pleine du destinataire ou de l’expéditeur (code 552)

Le code 552 ne concerne pas votre configuration. La boîte du destinataire est pleine. Prévenez la personne concernée ou configurez une alerte pour identifier les adresses problématiques. Vous pouvez également utiliser un vérificateur d’e-mails avant chaque envoi pour filtrer les adresses invalides ou saturées.

Attendre la réinitialisation du quota : 10 minutes, une heure ou un jour

Certains quotas se réinitialisent en 10 minutes, d’autres en une heure ou par jour calendaire. Inutile d’insister avec des essais répétés. Programmez une nouvelle tentative avec une date de reprise, ou relancez manuellement le scénario après le délai indiqué.

Comment éviter que l’erreur ne revienne : réglages préventifs et surveillance

Limiter le nombre de runs simultanés pour ne pas saturer l’API

Dans les paramètres de votre scénario, réduisez le nombre maximal d’exécutions en parallèle. Une limitation stricte évite les pics de requêtes et protège l’ensemble de vos automatisations.

Ajouter une condition « nombre de requêtes » avant chaque appel

Vous pouvez utiliser un module Data Store pour stocker le nombre de requêtes déjà envoyées. Avant chaque appel, vous comparez ce compteur à la limite connue. Si la valeur est dépassée, le scénario attend. Cette approche demande un peu de configuration, mais elle est efficace.

Passer en phase de test avec des filtres sur les nouvelles données

Quand vous modifiez un scénario, activez le mode de traitement partiel avec un filtre qui limite à quelques nouvelles lignes. Vous validez le fonctionnement sans consommer tout le quota des fournisseurs.

Surveiller la colonne Operations du tableau de bord et les dates de reset

La meilleure prévention reste un suivi régulier. Consultez chaque semaine votre tableau de bord Make.com, la colonne Operations et les dates de réinitialisation annoncées par les fournisseurs. Vous saurez quand réduire temporairement les volumes.

Pour résoudre le problème de quota dépassé, tout est une question de méthode. Lisez le code, identifiez le service concerné, appliquez le correctif adapté. Pour aller plus loin dans le diagnostic, la méthode des 5 pourquoi vous aidera à trouver la cause racine. Et surtout, ne laissez jamais un scénario sans filet de sécurité.