Erreur quota exceeded sur Make.com : comment la résoudre ?

Comprendre le message « quota exceeded » sur Make.com

Le message d’erreur « quota exceeded » apparaît lorsque Make.com dépasse une limite imposée par un service externe : API, serveur SMTP, boîte mail ou stockage. Résoudre le problème exige d’identifier la vraie source. Ce code ne signifie pas que Make.com est en panne, mais qu’un quota a été dépassé. Vous pouvez éviter les correctifs hasardeux en lisant d’abord le message complet et le code HTTP associé.

Un symptôme générique, pas une panne unique

« Quota exceeded » est un symptôme. Le quota concerné peut être un nombre de requêtes, un volume de mails ou un espace disque. Avant de modifier votre scénario, ouvrez le détail de l’erreur pour voir le service visé.

Lire le code HTTP associé au message d’erreur

Le code HTTP est votre boussole. Il indique la nature du problème et la bonne solution. Retenez-le, car chaque code mène à une action différente.

L’exemple Google Sheets : 3 000 lignes en une seule exécution

Un scénario qui récupère 3 000 lignes dans Google Sheets puis les envoie une par une dépasse vite la limite d’environ 100 requêtes par minute. Le nombre de requêtes est dépassé en quelques secondes, et l’erreur apparaît, souvent dès la phase de test.

Identifier la source grâce aux codes d’erreur

Voici un arbre de diagnostic simple. Il couvre les cas les plus fréquents dans Make.com.

Code 429 : quota API court terme

Le code 429 signifie que vous avez envoyé trop de requêtes dans un court laps de temps. La solution est d’attendre la réinitialisation, de quelques minutes à une heure, puis d’espacer les appels.

Code 403 : permission ou quota long terme

Un code 403 signale un accès refusé. Le compte API peut manquer de droits ou le quota long terme est épuisé. Vérifiez les permissions du compte et les paramètres de l’application connectée.

550 5.2.2 : la boîte mail du destinataire est pleine

Cette erreur SMTP ne vient pas de votre configuration. Le destinataire ne peut plus recevoir de mail car sa boîte dépasse la limite. Vous devez le prévenir et attendre qu’il libère de l’espace.

550 5.4.5 : la limite d’envoi du serveur SMTP est dépassée

Ici, le problème vient de votre serveur SMTP. Vous avez dépassé le nombre de mails autorisés sur une période. Par exemple, OVH plafonne souvent à 200 messages par heure. Il faut attendre ou augmenter la limite chez l’hébergeur.

552 : espace disque plein côté destinataire

L’erreur 552 apparaît quand la boîte du destinataire n’a plus assez d’espace pour les fichiers. Si vous envoyez une pièce jointe lourde, le serveur refuse. Réduisez les fichiers volumineux ou utilisez un lien de téléchargement.

Utiliser le tableau de bord pour suivre sa consommation

Le tableau de bord Make.com contient la colonne Operations. Elle affiche votre consommation et la date de réinitialisation. Utilisez ces informations pour savoir combien de temps attendre avant un prochain envoi.

Tableau suivant : codes, sources et solutions

Résoudre le problème sur votre scénario

Une fois la source identifiée, appliquez les correctifs suivants. Ils résolvent la majorité des erreurs « quota exceeded » dans Make.com.

Espacer les exécutions avec le module Sleep

Le module Sleep met l’exécution en pause. Ajoutez une pause de 500 millisecondes entre deux appels API pour réduire le risque de dépassement. C’est le premier correctif à essayer.

Filtrer les données pour ne traiter que les nouvelles entrées

Retraiter 3 000 lignes alors que seulement 50 sont nouvelles consomme inutilement. Utilisez un filtre sur la date de modification ou le statut pour réduire le nombre de requêtes. Cette optimisation règle une grande partie des problèmes.

Fractionner les gros traitements en plusieurs paquets

Pour un volume important, découpez-le en paquets de 100 ou 200 enregistrements. Traitez un paquet, faites une pause avec le module Sleep, puis reprenez. Le traitement est plus long, mais il ne dépasse plus la limite.

Ajouter un module Resume pour relancer automatiquement

Le module Resume capture l’échec et relance le scénario après un délai. Si l’exécution échoue à cause du quota, il attend puis recommence. Vous pouvez ainsi éviter une surveillance constante.

Le cas Gmail : « User rate limit exceeded »

Avec Gmail, cette erreur survient après plusieurs envois groupés. La limite de messages par utilisateur est atteinte. La seule solution est d’attendre la remise à zéro, généralement sur 24 heures glissantes. Inutile de réécrire le scénario.

Vérifier le serveur SMTP et ses paramètres

Si votre scénario utilise le serveur SMTP d’un hébergeur, contrôlez le port, l’authentification et la limite d’envoi par heure. Une erreur 550 peut aussi venir d’une réputation d’IP dégradée. Contactez l’hébergeur avant de tout reconfigurer.

Nettoyer la liste de contacts avant un envoi en masse

Supprimez les adresses invalides et les boîtes pleines avant de relancer. Ce simple nettoyage évite les échecs en cascade, notamment avec les erreurs 552.

Ne pas relancer en boucle et attendre la réinitialisation

Ne relancez jamais le scénario en boucle, car chaque tentative consomme des opérations et aggrave le quota. Attendez la réinitialisation, puis corrigez avant de relancer. Les durées typiques vont de quelques minutes à 24 heures selon le service.

Prévenir l’erreur à l’avenir

Pour éviter que l’erreur ne revienne, adoptez ces bonnes pratiques.

Tester en phase de test, surveiller le tableau de bord et calculer les limites

Testez avec un petit volume avant de lancer en production. Surveillez le tableau de bord une fois par jour pour repérer les pics de consommation, et mettez en place un routeur d’erreur qui vous prévient par email. Enfin, calculez les capacités réelles : nombre de requêtes par minute, mails par heure, capacité du serveur SMTP. Vous pourrez ainsi dimensionner vos scénarios en connaissance de cause, à l’instar de notre guide pour automatiser la synchronisation Notion et Google Calendar.