Salesforce Governor Limits : comprendre, anticiper et contourner

Les governor limits sont l'une des premières choses qui surprennent les développeurs qui arrivent sur Salesforce depuis d'autres plateformes. Elles imposent des plafonds stricts sur les ressources consommées par chaque transaction Apex, et les dépasser génère immédiatement une exception qui bloque l'exécution. Comprendre ces limites, c'est comprendre comment Salesforce fonctionne vraiment.

Pourquoi les governor limits existent

Salesforce est une plateforme multi-tenant, des milliers d'organisations partagent la même infrastructure. Pour garantir que le code d'un client ne monopolise pas les ressources au détriment des autres, Salesforce impose des limites par transaction sur chaque type de ressource. Ce n'est pas un bug ni une limitation artificielle, c'est le mécanisme qui rend la plateforme stable à grande échelle.

Chaque fois qu'un trigger Apex se déclenche, qu'un Flow appelle du code Apex ou qu'un batch s'exécute, un compteur de ressources démarre. Quand une limite est atteinte, Salesforce lève une System.LimitException et rollback la transaction entière.

Les limites essentielles à connaître

L'erreur classique : SOQL dans une boucle

C'est l'erreur la plus fréquente sur Salesforce, et elle touche même des développeurs expérimentés qui arrivent d'autres langages. Mettre une requête SOQL à l'intérieur d'une boucle for consomme une requête par itération, et sur 101 enregistrements, c'est terminé.

// SOQL dans la boucle = LimitException dès 101 enregistrements
for (Account acc : trigger.new) {
    List<Contact> contacts = [
        SELECT Id, Email
        FROM Contact
        WHERE AccountId = :acc.Id  // ← une requête par Account !
    ];
    // traitement...
}

// Une seule requête pour tous les enregistrements du batch
Set<Id> accountIds = new Set<Id>();
for (Account acc : trigger.new) {
    accountIds.add(acc.Id);
}

Map<Id, List<Contact>> contactsByAccount = new Map<Id, List<Contact>>();
for (Contact c : [
    SELECT Id, Email, AccountId
    FROM Contact
    WHERE AccountId IN :accountIds  // ← une seule requête
]) {
    if (!contactsByAccount.containsKey(c.AccountId)) {
        contactsByAccount.put(c.AccountId, new List<Contact>());
    }
    contactsByAccount.get(c.AccountId).add(c);
}

DML dans une boucle : même problème

La même erreur existe côté DML. Faire un update ou un insert à l'intérieur d'une boucle consomme une opération DML par itération. Sur 151 enregistrements, la limite est atteinte.

for (Account acc : accountsToUpdate) {
    acc.Description = 'Mis à jour';
    update acc;  // ← un DML par Account !
}

List<Account> toUpdate = new List<Account>();
for (Account acc : accountsToUpdate) {
    acc.Description = 'Mis à jour';
    toUpdate.add(acc);
}
update toUpdate;  // ← un seul DML pour tous

CPU Time : le piège des traitements intensifs

La limite CPU time (10 secondes en synchrone) ne prend en compte que le temps d'exécution Apex pur, pas le temps d'attente des requêtes SOQL ou des appels HTTP. En pratique, elle est rarement atteinte sur du code simple, mais elle devient critique sur :

• Des boucles imbriquées sur de grandes collections
• Des algorithmes de tri ou de calcul complexes
• Des opérations de string manipulation intensives sur de grands volumes
• Du code récursif non maîtrisé

Le contournement principal : passer en asynchrone. Un @future, un Queueable ou un Batchable dispose de 60 secondes de CPU au lieu de 10.

Heap Size : mémoire et grandes collections

La limite heap size (6 MB en synchrone) est souvent atteinte quand on charge de grandes collections en mémoire, par exemple en récupérant tous les champs d'un objet avec SELECT * ou en stockant des listes volumineuses dans des variables statiques.

• Ne sélectionnez que les champs dont vous avez besoin dans vos requêtes SOQL
• Évitez les variables statiques pour stocker de grandes collections
• En batch, utilisez Database.QueryLocator plutôt qu'une liste pour les très grands volumes

Tableau de référence

Stratégies pour travailler avec les limits

1. Toujours coder en mode bulkifié

Chaque trigger Apex peut recevoir jusqu'à 200 enregistrements dans un même batch. Tout le code doit être écrit pour traiter une collection, jamais un seul enregistrement. C'est la règle n°1 du développement Apex.

2. Passer en asynchrone pour les traitements lourds

Quand un traitement risque de dépasser les limites synchrones, il faut le déplacer en asynchrone. Salesforce propose plusieurs patterns :

• @future : pour les opérations simples non chainables (callouts HTTP depuis un trigger…)
• Queueable : pour les opérations chainables avec contexte
• Batchable : pour les traitements sur de grands volumes (jusqu'à 50M d'enregistrements)
• Schedulable : pour les traitements planifiés

3. Surveiller les limits avec la classe Limits

En développement, instrumenter son code avec System.debug(Limits.getQueries()) permet de surveiller la consommation réelle et d'identifier les points chauds avant qu'ils arrivent en production.

Conclusion

Les governor limits ne sont pas un obstacle, ce sont des garde-fous qui forcent à écrire du code performant et scalable. Un développeur Salesforce qui maîtrise les limits écrit naturellement du code bulkifié, pense en termes de collections plutôt que d'enregistrements unitaires, et choisit le bon pattern asynchrone selon le contexte. C'est cette maîtrise qui fait la différence entre un code qui tient en production et un code qui plante dès que le volume augmente.