Lire le message d’erreur complet : c’est la clé du diagnostic
Quand un scénario Make.com affiche une erreur « quota exceeded », la première réaction est souvent de chercher une solution miracle. Dans ma pratique, je vois des dirigeants perdre des heures à modifier leur abonnement ou à supprimer des modules au hasard. Ne touchez à rien avant d’avoir lu l’intégralité du message d’erreur. La suite du texte contient presque toujours le nom du service concerné et la métrique dépassée.
Ne vous arrêtez pas au texte « quota exceeded for »
Le message affiché par Make.com est tronqué volontairement. Cliquez sur le détail de l’erreur dans l’onglet History. Vous y verrez la mention complète, par exemple : « Quota exceeded for quota metric ‘Read requests’ and limit ‘100 requests per minute’ ». C’est cette phrase qui oriente tout le diagnostic. Sans elle, vous cherchez une aiguille dans une botte de foin.
Identifier le service tiers : API Google, SMTP ou boîte aux lettres
L’erreur peut venir de trois couches différentes : l’API d’un fournisseur (Google Sheets, Gmail), le serveur SMTP qui envoie vos emails, ou la boîte aux lettres du destinataire. Chaque couche a ses propres messages. Un message qui contient « quota exceeded for mailbox » n’a rien à voir avec un quota API. Prenez le temps de repérer le nom du service inscrit dans l’erreur. Vous saurez alors si vous devez vérifier la configuration du module, les limites de votre compte serveur, ou simplement contacter votre client pour lui demander de vider sa boîte mail.
Décoder les codes HTTP : 429, 403, 550, 552
Les codes HTTP sont vos meilleurs amis. Ils donnent une indication fiable et immédiate. Voici comment je les analyse quand je reçois des messages d’erreur de mes clients :
| Code | Signification | Action rapide |
|---|---|---|
| 429 | Dépassement de quota API temporaire | Espacer les requêtes, attendre la réinitialisation |
| 403 | Accès refusé, permission manquante | Vérifier les droits du compte connecté |
| 550 | Rejet SMTP par le serveur destinataire | Vérifier l’adresse email et la réputation du serveur |
| 552 | Boîte mail du destinataire pleine | Contacter le destinataire, réduire la taille des fichiers |
Un code 552 suivi de « mailbox full » ne nécessite aucune modification de votre scénario. Le problème vient de la boîte aux lettres du destinataire. Dans ce cas, un simple appel téléphonique règle tout.
Résoudre le problème selon la cause : mes correctifs directs
Une fois la cause identifiée, l’action devient simple. Voici les correctifs que j’applique concrètement selon l’origine du dépassement.
Quota API Google (Sheets, Gmail) : espacer les requêtes et réduire les lots
Le scénario type : vous lisez 3 000 lignes dans Google Sheets pour les traiter une par une. L’API Google plafonne à 100 requêtes par minute pour de nombreux comptes. Résultat : l’erreur apparaît au bout de quelques secondes. La solution que je recommande est double. D’abord, ajoutez un module Sleep entre chaque itération, même 500 millisecondes suffisent. Ensuite, réduisez la taille des lots en filtrant les données en amont, par exemple en ne traitant que les lignes modifiées depuis la dernière exécution. Vous pouvez aussi consulter la limite exacte de votre quota dans la console Google Cloud. Mais souvent, espacer les requêtes résout le problème sans aucun changement de plan.
Quota SMTP : vérifier la limite d’envoi et la configuration du serveur
Les serveurs SMTP imposent des plafonds stricts. OVH limite à 200 messages par heure, Gmail à 500 par jour (parfois moins), Free à 50 emails par jour. Si votre erreur indique « exceeded for Mail quota » ou « limit of 200 messages per hour », le problème vient de votre serveur d’envoi. Vous pouvez configurer un autre serveur SMTP dans Make.com, ou réduire le volume d’envoi. Ne changez pas de plan Make.com pour autant : le quota dépend de votre fournisseur SMTP, pas de Make. Si vous envoyez en masse, utilisez un service dédié comme SendGrid ou Mailgun, que je configure dans mes solutions pour les clients qui dépassent régulièrement les limites.
Boîte mail pleine : le correctif côté destinataire et côté pièces jointes
L’erreur peut être trompeuse. Parfois, le message d’erreur concerne la boîte du destinataire, pas la vôtre. Le serveur SMTP renvoie alors un code 552. Vérifiez d’abord si l’adresse email est correcte. Ensuite, demandez au destinataire de supprimer des messages ou d’augmenter la taille de sa boîte aux lettres. Pensez aussi au volume des pièces jointes : un fichier de 15 Mo peut faire échouer l’envoi si la boîte destinataire est presque pleine. Si vous avez besoin d’envoyer régulièrement des fichiers lourds, utilisez un lien de téléchargement plutôt qu’une pièce jointe. Dans tous les cas, attendez quelques minutes avant de relancer, sinon l’erreur persistera.
Éviter la récidive : les réglages Make.com que je configure systématiquement
Un correctif immédiat ne suffit pas. Pour éviter de revoir ce message d’erreur, je mets en place trois réglages dans tous les scénarios que je supervise.
Moduler le module Schedule et ajouter des modules Sleep
Le module Schedule est souvent réglé à la minute par habitude. C’est inutile dans la plupart des cas. Une exécution toutes les 15 minutes suffit largement pour traiter des données non critiques. J’ajoute aussi un module Sleep de 2 à 5 secondes après chaque requête vers une API. Ce simple réglage réduit considérablement le risque de dépassement, surtout avec Google Sheets ou Gmail. Vous pouvez voir cela comme une respiration entre chaque appel.
Filtres et modules Resume : traiter uniquement les nouvelles données
Pourquoi relire 10 000 lignes à chaque exécution ? Utilisez des filtres pour ne traiter que les nouvelles lignes, par exemple en vérifiant une colonne « Traité » ou la date de mise à jour. Le module Resume est aussi très utile : il permet au scénario de continuer après une erreur au lieu de tout arrêter. Je configure toujours un gestionnaire d’erreurs qui rejette silencieusement les éléments en échec et poursuit le traitement. Vos collègues vous diront merci, et vous aussi.
Surveiller les logs et anticiper la date de réinitialisation du quota
Le tableau de bord de Make.com affiche la consommation de votre quota en temps réel. Je vérifie toujours cette jauge avant de lancer un scénario massif. Certaines limites se réinitialisent toutes les minutes, d’autres toutes les 24 heures. Attendez au moins 10 minutes après une erreur 429 avant de réessayer. Cela évite d’accumuler les erreurs et de prolonger inutilement le blocage. Pour finir, activez les notifications par email sur les échecs de scénario. Vous serez prévenu immédiatement en cas de nouveau dépassement, sans avoir à consulter les logs manuellement.
Avec ces réglages, l’erreur « quota exceeded » devient un événement rare et gérable. Prenez le temps de lire le message d’erreur complet, d’identifier le service concerné, puis appliquez le correctif adapté. Vous économiserez des heures de frustration et surtout, vous garderez la main sur vos automatisations.
