Traiter de plus gros volumes avec l'augmentation des limites de heap Apex (Winter '27)

Salesforce livre discrètement l'un des changements Apex les plus impactants depuis des années. En Winter '27, la limite de heap synchrone passe de 6 Mo à 10 Mo, et la limite asynchrone bondit de 12 Mo à 25 Mo. Si votre org a déjà avalé un « System.LimitException: Apex heap size too large » à 2 h du matin pendant un batch, celle-ci est pour vous. Voici le playbook pragmatique : ce que change réellement cette évolution, comment s'y préparer, et comment étaler la bascule pour éviter les mauvaises surprises.

Ce qui change concrètement

• Heap synchrone : 6 Mo → 10 Mo (+66 %). S'applique aux triggers, controllers, Apex invocable, endpoints REST/SOAP, exécution anonyme.
• Heap asynchrone : 12 Mo → 25 Mo (+108 %). S'applique au Batch Apex, Queueable, Schedulable, méthodes future, triggers de Platform Events.
• Où : Lightning Experience et Salesforce Classic, toutes les éditions qui exécutent du code Apex personnalisé ou managé.
• Quand : activé automatiquement selon le calendrier Winter '27 pour chaque org.

Confirmez la limite actuelle à l'exécution avec Limits.getLimitHeapSize(). Cet appel indique dans quel régime vous êtes.

Pourquoi ça compte (plus qu'il n'y paraît)

Le plafond 6 Mo / 12 Mo a façonné le design Apex pendant plus d'une décennie. Les équipes ont accumulé :

• Des hacks de micro-batch : découper un job de 8 000 records en trois Queueables chaînés parce qu'un seul faisait exploser le heap.
• De la pagination agressive dans les controllers pour éviter de matérialiser de grandes listes.
• Des requêtes sélectives qui excluent des champs (rich text, long text, blobs) uniquement pour économiser du heap.
• Des callouts sacrificiels : découper un payload de 5 Mo en quatre plus petits.

Doubler le plafond asynchrone fait tomber une bonne partie de cette complexité. Mais cela démasque aussi des bugs jamais vraiment corrigés, seulement cachés par une limite qui tombait tôt. C'est le risque à cadrer.

Le risque caché : du code qui échouait avant, qui échoue autrement ensuite

La plupart des orgs pensent « plus de heap = moins d'erreurs ». Pas tout à fait. Deux catégories cassent :

1. Les collections qui grossissaient et tombaient tôt consomment 3 à 4× plus de RAM avant d'échouer, exposant des Too many SOQL rows ou CPU time limit exceeded qui étaient masqués.
2. Les hypothèses des packages managés. Une classe Apex managée peut cacher plus agressivement quand elle détecte un heap plus grand. Si vous êtes en limite, l'interaction avec votre code peut se comporter différemment d'une sandbox Summer '26.

Comment se préparer en 4 étapes

1. Inventoriez le code sensible au heap

Cherchez ces motifs dans votre metadata :

• Toute classe qui requête et garde plus de 2 000 SObjects en mémoire.
• Tout Batch Apex avec un scope de 200 qui touche des related lists.
• Tout Queueable qui sérialise un état de plus de 500 Ko.
• Tout champ long/rich text agrégé dans une Map.
• Tout System.debug(JSON.serialize(...)) legacy sur de gros payloads.

Ce sont les chemins dont le comportement change matériellement.

2. Rafraîchissez une preview sandbox sur Winter '27

Les preview sandboxes sont upgradées avant la production. Rafraîchissez-en une, rejouez vos 10 principaux jobs Apex, et comparez les logs à la même exécution en Summer '26. Surveillez :

• Des temps de transaction plus longs (les grandes collections mettent plus de temps à être traitées).
• De nouvelles erreurs CPU-time ou SOQL-rows qui apparaissent quand le heap n'est plus le premier goulot.
• Des régressions sur des packages managés dans les orgs qui font tourner CPQ, FSL, NPSP ou Loyalty.

3. Utilisez le toggle « Enforce the Summer '26 Apex heap limit » avec méthode

Salesforce livre un paramètre : Apex Settings → Enforce the Summer '26 Apex heap limit. Activez-le dans les orgs non-prod quand vous prévoyez de déployer du code d'une sandbox Winter '27 vers une production Summer '26. Il force les anciennes limites pour révéler les régressions avant l'upgrade production.

Important : ce toggle disparaît une fois que toutes les productions sont sur Winter '27. C'est un filet de sécurité transitoire, pas un levier permanent.

4. Mettez à jour votre pense-bête des governor limits

Si votre équipe entretient une fiche des governor limits (ce qu'elle devrait faire), mettez à jour la ligne du heap. Mais n'écrasez pas la valeur : indiquez les deux, avec une note : « Sync 10 Mo / Async 25 Mo à partir de Winter '27 ; conserver 6 Mo / 12 Mo dans le code portable vers des packages managés installés sur des orgs plus anciennes. » La portabilité compte si vous publiez des packages AppExchange.

Réécrire du code pour profiter du gain (avec parcimonie)

Résistez à l'envie de tout réécrire parce que vous avez plus de mémoire. Les refactos les plus sûrs :

• Recompactez les Queueables chaînés qui existaient uniquement pour contourner 12 Mo. Un Queueable unique se monitore et se déboggue plus facilement.
• Élargissez le scope Batch de 200 à 500 ou 1 000 pour les batches I/O-bound. Testez d'abord le CPU time.
• Réduisez les allers-retours SOQL quand vous re-requêtiez pour éviter de garder une grosse liste.

Ne touchez pas à la pagination ni au lazy-loading des composants Lightning. La vraie contrainte là-bas, c'est le temps de réponse, pas le heap.

Timeline de bascule — l'antisèche

• Maintenant : Inventoriez classes et jobs Apex sensibles au heap.
• Fenêtre preview Winter '27 : Rafraîchissez une preview sandbox et rejouez vos jobs Apex principaux.
• Deux semaines avant l'upgrade prod : Déployez le code qui suppose les nouvelles limites derrière le toggle, pour que la non-prod se comporte comme la prod Summer '26.
• Week-end de l'upgrade prod : Monitorez les jobs Apex pendant 72 h. Comparez la consommation heap dans les debug logs.
• Deux semaines après l'upgrade : Retirez le toggle « Enforce Summer '26 » dans les sandboxes.

Notes régionales

• Orgs Hyperforce UE : le changement arrive dans la même vague. Voir notre guide RGPD si votre Apex touche des données personnelles.
• États-Unis & Canada : Winter '27 tombe près de fin de trimestre. Planifiez un release freeze et étalez les déploiements Apex après l'upgrade plateforme.

Où ça s'inscrit dans la vue d'ensemble 2026

L'augmentation du heap n'est qu'une ligne d'une liste plus longue. Voir notre panorama Releases Salesforce 2026 : ce qui compte vraiment et notre playbook migration Flow si votre équipe finit en parallèle sa sortie de Workflow Rules et Process Builder.

Questions fréquentes

Faut-il modifier le code pour les nouvelles limites ?

Non. Le code existant continue de tourner. Les limites sont des plafonds, pas des planchers, et Salesforce les a relevés. Il faut modifier le code uniquement si vous voulez utiliser la marge, ou si des bugs CPU / SOQL cachés remontent quand le heap n'échoue plus en premier.

Les packages managés sont-ils concernés ?

Oui. Les packages managés tournent sous les mêmes limites plateforme. Si vous publiez sur AppExchange, calibrez vos tests sur les anciennes limites 6 Mo / 12 Mo pour que le package s'installe proprement sur les orgs qui les appliquent encore.

Comment vérifier que la nouvelle limite est active ?

Exécutez System.debug(Limits.getLimitHeapSize()); en Apex anonyme. 10 000 000 (sync) ou 25 000 000 (async) : la nouvelle limite est appliquée.

Peut-on désactiver l'augmentation ?

Pas définitivement. Le toggle « Enforce the Summer '26 Apex heap limit » est transitoire, disponible uniquement en sandbox et jusqu'à ce que toutes les productions passent à Winter '27.

Mes erreurs de heap size vont-elles disparaître ?

La plupart, pas toutes. Les requêtes non bornées ou la récursion infinie continueront de heurter le plafond. Le changement donne de la marge, pas l'immunité contre le mauvais code.

Obtenez un check de préparation Winter '27

Notre audit Salesforce inclut un pass par release sur les jobs Apex, Flow et intégrations, et une liste d'actions priorisée pour l'upgrade Winter '27. Réservez un appel de 30 minutes : on vous dit quelles classes Apex changent réellement de comportement chez vous.