Un projet Salesforce qui fonctionne parfaitement en phase pilote peut se gripper une fois déployé à l'échelle. La cause est rarement fonctionnelle : elle tient aux limites techniques de la plateforme, les fameuses « governor limits », auxquelles s'ajoutent des quotas d'appels API et des plafonds de stockage. Ces plafonds sont documentés mais peu visibles au moment de signer. Comprendre leur logique permet d'éviter les mauvaises surprises quand les volumes de données, d'utilisateurs et d'intégrations augmentent.

Pourquoi Salesforce impose des limites

Salesforce est une architecture multi-tenant : des milliers d'organisations partagent la même infrastructure. Pour éviter qu'un traitement mal optimisé d'un client ne dégrade les performances des autres, la plateforme applique des quotas stricts sur presque toutes les opérations. Ces limites ne sont pas négociables au cas par cas : elles sont inscrites dans le fonctionnement même de la plateforme et, pour certaines, dans le contrat d'abonnement.

On distingue deux grandes familles. Les governor limits encadrent l'exécution du code et des automatisations (nombre de requêtes SOQL, lignes traitées, temps CPU, appels imbriqués). Les limites contractuelles concernent les ressources achetées : appels API quotidiens, volume de stockage de données et de fichiers, nombre d'automatisations actives.

Les governor limits qui font trébucher le code

Ces limites s'appliquent par transaction. Elles sont invisibles tant que les volumes restent faibles, puis se déclenchent brutalement lorsqu'un traitement porte sur des milliers d'enregistrements. Les plus fréquemment rencontrées :

  • Requêtes SOQL par transaction : un plafond limite le nombre d'interrogations de la base. Placer une requête dans une boucle est la première cause de dépassement.
  • Lignes retournées par requête : une seule requête ne peut ramener qu'un nombre borné d'enregistrements, ce qui impose de paginer les traitements de masse.
  • Opérations DML (création, mise à jour, suppression) : plafonnées elles aussi, elles obligent à regrouper les écritures plutôt qu'à les enchaîner.
  • Temps CPU par transaction : les automatisations complexes (Flows en cascade, triggers imbriqués, code Apex lourd) peuvent dépasser le temps alloué.
  • Callouts externes : le nombre d'appels sortants vers d'autres systèmes dans une même transaction est également borné.

Le point critique : ces limites sont indépendantes de l'édition achetée. Payer plus cher n'augmente pas le nombre de requêtes SOQL par transaction. La seule réponse est une conception adaptée aux volumes (traitement par lots, patterns « bulkifiés », automatisations asynchrones).

Un déploiement validé sur un jeu de test de quelques dizaines d'enregistrements ne prouve rien. Beaucoup de dépassements de governor limits n'apparaissent qu'à partir de plusieurs milliers de lignes traitées en une seule opération. Exigez des tests de charge représentatifs des volumes réels avant la mise en production.

Les appels API : le plafond que l'intégration ignore souvent

Chaque organisation Salesforce dispose d'un quota d'appels API sur 24 heures glissantes. Ce quota dépend de l'édition et du nombre de licences. Or, dès qu'on connecte Salesforce à d'autres systèmes — ERP, e-commerce, outil marketing, middleware — chaque synchronisation consomme ces appels.

Le calcul est vite dépassé. Une synchronisation bidirectionnelle qui interroge Salesforce toutes les cinq minutes, multipliée par plusieurs flux et plusieurs objets, peut épuiser le quota quotidien avant la fin de journée. Une fois le plafond atteint, les intégrations s'arrêtent jusqu'à réinitialisation, avec des conséquences directes sur la fraîcheur des données côté métier.

Les leviers pour rester dans l'enveloppe :

  • Privilégier les API en masse (Bulk API) pour les gros volumes plutôt que des appels unitaires répétés.
  • Adopter une logique événementielle (Platform Events, Change Data Capture) plutôt que du polling systématique.
  • Filtrer à la source pour ne synchroniser que les données réellement modifiées.
  • Suivre la consommation via les outils natifs de monitoring avant d'atteindre le seuil.
24 h
fenêtre glissante de calcul du quota d'appels API
2
grandes familles de limites : techniques et contractuelles
0
gain sur les governor limits en montant d'édition

Stockage et automatisations : les plafonds qui montent avec le temps

Deux autres plafonds se remplissent silencieusement au fil des mois. Le stockage de données est calculé sur la base d'un volume alloué par licence, chaque enregistrement consommant une taille standardisée quel que soit son contenu réel. Le stockage de fichiers (pièces jointes, documents) suit une logique distincte. Un historique de plusieurs années, des logs conservés sans politique de purge ou des documents lourds peuvent saturer l'espace disponible.

Côté automatisations, le nombre de règles actives, de Flows et de processus est également encadré. Une organisation qui accumule les automatisations sans les rationaliser rencontre à la fois des limites de nombre et des risques de conflit d'exécution.

La réponse relève de la gouvernance de données : politique d'archivage, purge programmée, externalisation des documents volumineux, et revue régulière des automatisations obsolètes.

Comment cadrer ces limites avant de signer

Ces contraintes ne sont pas un défaut de la plateforme : elles sont documentées et prévisibles. Le vrai risque est de les découvrir en production. Quelques réflexes de cadrage protègent le projet :

  • Estimer les volumes cibles : nombre d'enregistrements par objet à trois ans, débit des synchronisations, taille des documents. Les limites doivent être dimensionnées sur la cible, pas sur le pilote.
  • Cartographier les intégrations et leur consommation d'appels API avant de choisir l'architecture des flux.
  • Demander une revue d'architecture à l'intégrateur, incluant les patterns de traitement de masse et la stratégie asynchrone.
  • Prévoir le monitoring de la consommation dès le lancement, pas après le premier incident.

Ce sont précisément les questions qui distinguent un prestataire qui a déjà géré des déploiements à l'échelle d'un prestataire qui n'a fait que des pilotes. Un intégrateur solide anticipe ces plafonds dans son chiffrage et sa conception ; il ne les traite pas comme des imprévus.

Ce qu'il faut retenir

Les governor limits, les quotas d'appels API et les plafonds de stockage ne se contournent pas à coups de budget : ils se cadrent par la conception. Un projet qui monte en charge doit être pensé pour les volumes réels dès la phase de spécification. La question à poser n'est pas « est-ce que ça marche ? » mais « est-ce que ça tient à trois ans, avec dix fois plus de données et de flux ? ». C'est un critère de sélection déterminant pour choisir l'équipe qui vous accompagne.

Un projet Salesforce à cadrer ?

Trouver le bon intégrateur Salesforce

Mise en relation gratuite · sans engagement · qualification par la donnée publique