Ce qui cède en premier lorsque les limites d'API sont ignorées
Une entreprise qui gère simultanément trois intégrations – une synchronisation ERP nocturne, un Webhook depuis un système de paiement, et un tableau de bord externe qui extrait des données toutes les cinq minutes – ne connaît pas une défaillance progressive. Son fonctionnement est optimal jusqu'à ce qu'elle dépasse un seuil, après quoi chaque appel d'API supplémentaire est rejeté avec le code REQUEST_LIMIT_EXCEEDED jusqu'à la réinitialisation quotidienne. Il n'existe pas d'alerte préventive intégrée ; seule une interface de tableau de bord est disponible, si un processus de surveillance a été mis en œuvre.
Cet échec diffère de la plupart des échecs des projets Salesforce, car il ne dépend pas d'un code de mauvaise qualité ou d'une conception inadéquate. Il résulte d'une accumulation : une nouvelle intégration est toujours développée en fonction de l'état actuel, sans vérifier la consommation quotidienne du budget par les processus existants. En conséquence, la cinquième intégration "casse" les quatre précédentes, bien qu'aucune d'elles n'ait été modifiée.
Cartographie des limites réellement pertinentes
Toutes les limites de Salesforce n'ont pas la même importance pour la planification des intégrations. Celles qui déterminent véritablement l'architecture sont les suivantes :
| Type de limite | Ce qu'elle mesure | Qui est affecté en premier |
|---|---|---|
| Requêtes API journalières | Total des appels REST/SOAP sur 24 heures | Toute intégration synchrone à haute fréquence |
| Lots Bulk API | Nombre de lots ouverts/journaliers | Processus Batch nocturnes alimentant des données historiques |
| Requêtes concurrentes de longue durée | Requêtes s'exécutant plus de 20 secondes simultanément | Rapports volumineux ou Apex synchrone complexe |
| Livraison d'événements de plateforme | Volume d'événements par jour et par abonnement | Architectures basées sur les événements entre Salesforce et des systèmes externes |
| Lignes SOQL par transaction | Lignes récupérées dans une seule transaction (50 000) | Logique Apex exécutant des requêtes dans une boucle |
Ce tableau n'est pas une documentation générique, mais un ordre de priorité. Une organisation planifiant une nouvelle intégration doit en premier lieu examiner les deux premières lignes, car ce sont celles qui sont effectivement bloquées en production. Les autres limites affectent principalement les performances, et non la disponibilité.
Budget d'appels : comment l'établir correctement
L'outil principal pour prévenir les blocages n'est pas la surveillance a posteriori, mais un budget d'API prédéfini pour chaque consommateur. Le principe est le suivant : chaque système externe, chaque utilisateur d'intégration et chaque processus planifié reçoit une allocation définie à partir du quota total, plutôt que de consommer "autant que nécessaire".
L'établissement du budget comprend trois étapes :
- Cartographie des consommateurs – Établir une liste de tous les processus qui appellent l'API : intégrations externes, Apex planifié, Data Loader manuel, outils de BI. Chaque processus doit disposer d'un utilisateur d'intégration distinct afin d'isoler la consommation dans l'Event Monitoring.
- Calcul de la charge, basée sur le volume d'activité et non sur des hypothèses – Déterminer le nombre d'enregistrements traités quotidiennement, le nombre d'appels requis par enregistrement (y compris la récupération des Listes Associées), et ce qui se passe durant les périodes de pointe (fin de trimestre, Black Friday, clôture de mois).
- Allocation d'une réserve – Ne pas distribuer 100 % du quota entre les processus existants. Conserver 15 % à 20 % comme réserve pour les processus d'urgence, les rapports ponctuels et la maintenance – sans cette réserve, le moindre ajout risquerait de pousser l'organisation au-delà des limites.
Pour approfondir la conception de la couche gérant ce budget au niveau de la plateforme, il est recommandé de consulter le Guide d'architecture CRM, qui présente la répartition entre la couche d'intégration et la couche métier.
REST vs Bulk : quand le passage est-il bénéfique ?
L’erreur la plus fréquente consiste à utiliser l’API REST standard pour des transferts de données à volume élevé, car c’est souvent la première à être mise en œuvre et à fonctionner dans une preuve de concept. Le problème survient lorsque le volume de données augmente : REST compte chaque requête (jusqu’à 200 enregistrements dans Composite) comme un appel distinct par rapport au quota, tandis que Bulk API 2.0 traite des lots pouvant atteindre 10 000 enregistrements et est comptabilisée à un coût significativement plus faible par enregistrement.
Une règle empirique pratique : si un seul processus met à jour plus d'environ 2 000 enregistrements en une seule exécution, le passage à Bulk API est presque toujours avantageux, même si cela implique de modifier le code client pour fonctionner de manière asynchrone avec un sondage sur l’état de la tâche plutôt qu'une réponse immédiate. Le coût est une latence plus élevée (quelques minutes au lieu de quelques secondes), ce qui rend Bulk inapproprié pour les processus nécessitant une décision en temps réel, comme la vérification des stocks avant la validation d'une commande.
Retour arrière et nouvelle tentative : prévention de l'auto-submersion
Lorsqu'un appel d'API échoue en raison d'un blocage de limite, la réaction instinctive de la plupart des équipes est de réessayer immédiatement. C'est précisément ce comportement qui transforme un blocage temporaire en une panne persistante : si dix processus essaient de nouveau au même moment, ils enfoncent le système plus profondément dans le blocage au lieu de lui permettre de se rétablir.
Un mécanisme de retour arrière (Backoff) approprié requiert la combinaison de trois éléments :
- Backoff exponentiel - Le temps d'attente entre les tentatives est augmenté de manière exponentielle (par exemple 2, 4, 8, 16 secondes), au lieu de rester constant.
- Jitter - Une légère addition aléatoire au temps d'attente, afin que les processus parallèles ne retentent pas exactement à la même seconde et ne créent pas une nouvelle vague de charge.
- Disjoncteur (Circuit Breaker) - Après un certain nombre d'échecs consécutifs (par exemple cinq), le processus cesse complètement de tenter pendant une durée définie et signale l'incident au système de surveillance, au lieu de continuer à "frapper à la porte".
Sans disjoncteur, un processus exécuté toutes les cinq minutes et échouant de manière constante continuerait à essayer cent fois par jour et à consommer le quota uniquement pour des échecs – ce qui est exactement l'inverse de ce que le mécanisme est censé prévenir. Des détails supplémentaires sur la gestion des erreurs au niveau de l'intégration sont disponibles dans Gestion des erreurs d'intégration Salesforce.
Scénario : Commerce de détail avec trois points d'intégration
Imaginons une chaîne de commerce de détail de taille moyenne, environ 40 succursales, qui exploite Salesforce Service Cloud en conjonction avec un système POS et un système ERP pour la gestion des stocks. Trois intégrations sont actives : une synchronisation des stocks toutes les 15 minutes depuis l'ERP (environ 8 000 références), un Webhook du POS pour chaque transaction échouée (environ 300 par jour), et un tableau de bord externe pour Power BI qui extrait les données de service toutes les heures.
Le mois où le réseau a ajouté un nouveau programme de fidélité, une quatrième intégration a été mise en place : la vérification des points de fidélité en temps réel depuis chaque caisse, ajoutant environ 6 000 appels par jour. En l'espace de deux semaines, la synchronisation des stocks a commencé à échouer vers 14h-15h, l'heure de pointe des caisses. L'équipe a d'abord examiné l'ERP, pensant que le problème venait de là, mais les journaux Salesforce ont montré REQUEST_LIMIT_EXCEEDED précisément dans cette période.
La solution n'a pas été d'acquérir un quota supplémentaire, mais de revoir les priorités : la vérification des points de fidélité a été transférée vers Platform Cache pour les résultats non fréquemment modifiés, réduisant les appels d'environ 70 %, et la synchronisation des stocks est passée de REST à Bulk API avec une exécution toutes les 30 minutes au lieu de 15. Le résultat : même couverture métier, consommation de quota réduite d'environ 45 %, et une réelle réserve pour la croissance future.
Risques et mesures préventives spécifiques
| Risque | Comment il se manifeste concrètement | Mesure préventive |
|---|---|---|
| Nouvelle intégration non vérifiée par rapport au budget existant | Blocage apparaissant uniquement après la mise en production | Exigence de revue de capacité pour toute nouvelle intégration avant le Go Live |
| Réessai sans retour arrière (Backoff) | Blocage temporaire se transformant en panne de plusieurs heures | Backoff exponentiel avec Jitter et Circuit Breaker chez chaque consommateur API |
| Utilisation de REST pour des volumes importants | Un processus unique consomme des dizaines de pour cent du quota quotidien | Passage à Bulk API au-delà d'un seuil de volume prédéfini |
| Absence de séparation des utilisateurs d'intégration | Impossibilité de savoir quelle intégration consomme le quota | Utilisateur d'intégration dédié à chaque système externe, surveillé séparément |
| Absence de réserve dans le budget | Le moindre ajout entraîne un dépassement | Allouer 15 %-20 % du quota en tant que réserve permanente non attribuée aux processus quotidiens |
Liste de vérification avant d'ajouter une nouvelle intégration
- ☐ Connaître le pourcentage du quota journalier consommé actuellement, par utilisateur d'intégration.
- ☐ Évaluer le volume de pointe (non le volume moyen) de la nouvelle intégration.
- ☐ Avoir choisi entre REST et Bulk API en fonction du seuil de volume, et non de la facilité de développement.
- ☐ Disposer d'un mécanisme de Backoff avec Jitter et Circuit Breaker dans le code du consommateur.
- ☐ Avoir défini une alerte lorsque la consommation du quota journalier dépasse 70 %.
- ☐ Avoir examiné la possibilité d'utiliser Platform Cache pour réduire les appels répétitifs.
- ☐ Disposer d'une réserve de 15 % à 20 % du quota non allouée au préalable.
- ☐ Avoir désigné un propriétaire opérationnel qui reçoit l'alerte, et non seulement un journal technique.
Comment surveiller cela au quotidien
Une mesure fiable nécessite la combinaison de trois sources : Event Monitoring (ou Shield Event Monitoring) pour la consommation d'API réelle par utilisateur, les limites Apex dans le code lui-même (Limits.getLimitApiRequests()) pour une vérification locale en temps réel, et le tableau de bord intégré sous les informations de l'entreprise qui affiche la consommation par rapport au quota au niveau de l'organisation. Aucune de ces trois sources n'est suffisante seule : la première montre une tendance, la seconde prévient les défaillances dans un processus unique, et la troisième sert de vue d'ensemble quotidienne pour l'équipe des opérations.
Une métrique à suivre sur le long terme est non seulement la "consommation réelle", mais aussi le "taux de croissance mensuel de la consommation", car c'est ce qui permet de prévoir quand l'organisation atteindra la limite, au lieu de réagir après qu'un blocage se soit produit. Lorsque plusieurs systèmes sont interdépendants, il est pertinent d'examiner également le modèle d'intégration global par rapport à la Connexion de Salesforce aux systèmes ERP, ainsi que la question de l'implémentation – Flow vs Apex – qui influence également l'efficacité des appels, comme détaillé dans Salesforce Flow ou Apex.
Résumé
Les limites d'API de Salesforce ne sont pas un problème à résoudre au moment où il se manifeste, mais une variable à intégrer dès le premier jour dans toute décision d'intégration. Un budget d'appels documenté par utilisateur d'intégration, un choix conscient entre REST et Bulk en fonction du volume, et un mécanisme de "Backoff" pour prévenir l'auto-submersion – ces trois éléments combinés distinguent une organisation qui découvre le problème lorsqu'elle est déjà bloquée, d'une organisation qui anticipe son approche un mois à l'avance et agit en conséquence.