Votre scénario Make.com est en échec depuis des heures. Le message d’erreur affiche « quota exceeded » et vous n’avez rien modifié. Je connais ce blocage. Il paralyse des centaines d’automatisations chaque semaine. La bonne nouvelle : la solution se trouve dans le texte exact de l’erreur. Je vous apprends à le décoder pour résoudre le problème par vous-même, sans passer par le support client.
Le message d’erreur ne ment jamais : apprenez à le lire correctement
Avant de toucher à votre scénario, ouvrez les logs et lisez la phrase complète. Dans ma pratique, 70% des erreurs « quota exceeded » ne viennent pas de Make.com. Elles viennent du service que votre module appelle. Le nom de ce service est toujours dans le message. Il faut savoir où regarder.
« Quota exceeded for » : identifiez le client qui renvoie l’erreur
Le message d’erreur mentionne souvent une métrique précise : « Quota exceeded for quota metric ‘Read requests’ ». Cela signifie que l’API Google Sheets a reçu trop de requêtes de lecture en peu de temps. Ce n’est pas Make qui décide de la limite. C’est Google. Prenez le temps de copier le code exact de l’erreur et le nom de l’API. Ce diagnostic vous évite de chercher la panne au mauvais endroit.
Si l’erreur parle de « Read requests per minute », le problème est temporaire. Si elle parle du volume quotidien, le problème durera jusqu’à la réinitialisation. Dans les deux cas, ce n’est pas Make.com qu’il faut reconfigurer.
Code 429 vs code 403 : la différence entre « trop vite » et « interdit »
Le code HTTP est votre premier indicateur. Un code 429 signifie que vous avez dépassé la limite de débit. Un code 403 signifie que le compte connecté n’a pas les permissions suffisantes. Ces deux codes demandent des actions opposées. Pour le 429, vous devez espacer les requêtes. Pour le 403, vous devez vérifier les droits d’accès dans Google Workspace ou dans le service concerné.
| Code | Signification | Action prioritaire |
|---|---|---|
| 429 | Dépassement du nombre de requêtes par minute | Ajouter un module Sleep ou réduire la fréquence |
| 403 | Accès refusé ou permission manquante | Vérifier les droits du compte de service |
| 552 | Boîte mail du destinataire pleine | Contacter le destinataire ou retirer l’adresse |
| 550 5.7.0 | Refus du serveur de réception | Vérifier votre réputation d’expéditeur |
Ce tableau ne remplace pas une analyse complète. Mais il vous oriente vers la bonne couche technique. Vous gagnez un temps précieux.
Vérifiez votre propre quota Make.com dans la colonne « Operations »
Avant d’accuser un tiers, ouvrez le tableau de bord Make. La colonne « Operations » affiche votre consommation mensuelle. Si vous avez atteint 100% de votre plan, l’erreur vient de Make lui-même. Dans ce cas, vous pouvez attendre le début du cycle suivant, passer à un plan supérieur, ou interrompre les scénarios non essentiels.
Je vois souvent des dirigeants baisser la fréquence de leur scénario alors que leur quota Make est simplement consommé. Ils résolvent le mauvais problème. La colonne « Operations » vous donne la réponse en une seconde. Le code 429, lui, se réinitialise souvent au bout d’une minute.
L’angle mort qui ruine vos campagnes : le serveur SMTP et la boîte aux lettres
Vous utilisez Make pour envoyer des emails ? Votre erreur « quota exceeded » peut venir de votre serveur SMTP ou de la boîte du destinataire. Dans ma pratique, c’est la cause la plus fréquente et la moins bien comprise. Voici comment la traiter.
L’erreur 552 (ou 5.2.2) : c’est la boîte du destinataire qui est pleine, pas votre script
Si le message contient « quota exceeded for mailbox » ou « 552 », le problème est côté destinataire. Sa boîte aux lettres est pleine. Votre scénario fonctionne parfaitement. Le serveur de réception refuse simplement les nouveaux messages. Vous devez retirer cette adresse de votre liste ou demander au contact de vider sa boîte. Envoyer plusieurs fois le même mail ne fera que dégrader votre réputation.
Max 200 mails/heure : décrypter la réponse brute de votre serveur SMTP
Certains serveurs SMTP, comme ceux d’OVH ou de Sellsy, limitent l’envoi à 200 messages par heure par compte. L’erreur affiche souvent : « You have exceeded the limit of 200 messages per hour ». Ce n’est pas Make.com qui bloque. C’est votre hébergeur. Vous devez alors espacer vos envois dans le temps ou utiliser un service d’emailing transactionnel dédié.
La configuration du module SMTP dans Make est souvent en cause. Vous branchez un module « Send an Email » et vous oubliez la cadence. Le serveur SMTP, lui, ne pardonne pas.
Pourquoi j’impose un délai automatique entre chaque envoi pour sauver votre réputation
Mon conseil anti-consensus : ne cherchez pas à contourner la limite. Respectez-la. J’ajoute systématiquement un module « Sleep » de 30 à 60 secondes entre chaque envoi. Cela ralentit la campagne, mais protège votre domaine. Pour structurer vos envois, découvrez notre guide complet du cold email en B2B. Une réputation d’expéditeur dégradée vaut bien plus cher qu’un envoi rapide. Les serveurs de réception surveillent le volume. Un pic brutal d’emails déclenche des alertes.
Dans mon expérience, les clients qui acceptent un ralentissement contrôlé obtiennent de meilleurs taux de délivrabilité. Ceux qui forcent l’envoi se retrouvent avec des messages en spam et une boîte mail blacklistée. Le choix est rapide.
Ma checklist pour purger l’erreur et sécuriser vos futurs scénarios
Voici la routine que j’applique avec mes clients TPE/PME. Elle permet de débloquer le scénario et d’éviter la récidive. Suivez les étapes dans cet ordre.
Ajoutez un module « Sleep » correctement configuré pour arrêter le code 429
Le module « Sleep » se place dans la boucle ou juste après l’appel API. Une valeur de 30 secondes suffit pour la plupart des APIs Google. Par exemple, une lecture de 3000 lignes dans Google Sheets peut déclencher un quota exceeded si elle est faite en une seule requête. En ajoutant une pause, vous laissez le temps au serveur de répondre. Pour les envois SMTP, je recommande 60 secondes entre chaque message. Vous divisez le risque d’erreur par dix.
Filtrez les fichiers en amont : ne traitez que les nouvelles lignes de votre Google Sheets
Le piège classique est de relire l’intégralité du fichier à chaque exécution. Votre scénario passe en revue des milliers de lignes inutilement. Cela consomme du quota API et ralentit le traitement. J’utilise un filtre « Nouvelle ligne uniquement » avec une colonne de statut ou une date de traitement. Résultat : le volume de requêtes chute, et le message d’erreur disparaît. Vous pouvez aussi utiliser le module « Search or Update Row » selon vos besoins.
Pensez également à la taille des fichiers. Un fichier de plusieurs milliers de lignes avec beaucoup de colonnes peut déclencher une limite de taille. Dans ce cas, découpez le traitement en plusieurs lots.
La routine de contrôle : 5 points à vérifier dès qu’un scénario affiche un quota exceeded
- La date de réinitialisation du quota. Elle figure dans les paramètres du service.
- La présence d’un module « Sleep » dans la boucle.
- La taille et le volume des fichiers traités.
- Le type de code indiqué : 429 pour un débit, 403 pour une permission.
- Le statut de la boîte du destinataire si un envoi a échoué.
Cette checklist vous évite de perdre une journée sur un faux diagnostic. Vous regardez les bons indicateurs dans le bon ordre.
Une dernière chose : si le problème persiste après ces réglages, vérifiez que vous utilisez bien la bonne adresse d’envoi (« from ») dans votre module. Une adresse mal configurée peut provoquer des erreurs de quota sur le serveur SMTP. Merci de votre lecture. Je vous garantis que ces étapes résolvent 90% des cas que je rencontre dans mes accompagnements.
