Traitement asynchrone à grande échelle : Queueable vs Batchable vs méthodes Future dans l'architecture Salesforce et OmniStudio

Traitement asynchrone à grande échelle : Briser la barrière de la concurrence

Le traitement des données à grande échelle dans Salesforce est un exercice d'équilibriste. Que vous synchronisiez des millions d'enregistrements avec un ERP externe ou que vous exécutiez des calculs lourds en arrière-plan d'une orchestration OmniStudio, vous opérez toujours sous la stricte supervision des Governor Limits.

Lorsque les volumes de transactions explosent, l'exécution synchrone devient votre pire ennemie. Elle entraîne des dépassements de temps CPU (timeouts), dégrade l'expérience utilisateur et provoque la redoutable exception Too many SOQL queries.

Pour construire une architecture véritablement résiliente, vous devez maîtriser les outils asynchrones à votre disposition : Méthodes Future, Batchable Apex et Queueable Apex. Mais savoir les coder ne suffit pas ; un Architecte doit savoir exactement quand utiliser chacun d'entre eux.

Voyons comment gérer une échelle massive sans se faire écraser par les limites de concurrence.

1. Méthodes Future (@future) : Le correctif rapide d'ancienne génération

Les méthodes Future étaient la façon originale d'exécuter de l'Apex de manière asynchrone. Elles sont incroyablement faciles à implémenter — il suffit d'ajouter une annotation — mais elles s'accompagnent de sévères restrictions architecturales.

• Le bon côté : Parfait pour des tâches simples et isolées, comme un appel web (callout) rapide après la mise à jour d'un enregistrement, ou pour contourner l'erreur "Mixed DML" lors de la mise à jour d'objets Setup et non-Setup dans la même transaction.

• Le mauvais côté : Vous ne pouvez passer que des types de données primitifs (Strings, IDs, Integers). Vous ne pouvez pas passer de sObjects.

• L'avertissement de l'Architecte : Les méthodes Future ne peuvent pas être chaînées et vous ne pouvez pas les surveiller facilement. Si vous déclenchez des centaines de méthodes Future depuis un Trigger lors d'un chargement massif de données, vous atteindrez immédiatement la limite Limit Exception: Too many future calls.

Verdict : Utilisez-les avec parcimonie. C'est un couteau suisse, pas un outil de scalabilité d'entreprise.

2. Batchable Apex : Le champion des poids lourds

Lorsque vous devez traiter des millions d'enregistrements, Batch Apex est votre seule véritable option. Il est spécifiquement conçu pour interroger des ensembles de données massifs et les diviser en morceaux (chunks) gérables.

• Comment ça marche : Vous utilisez un Database.QueryLocator qui peut récupérer jusqu'à 50 millions d'enregistrements. La plateforme traite ensuite ces enregistrements par lots (jusqu'à 200 à la fois), en attribuant à chaque lot un nouvel ensemble de Governor Limits.

• Gestion de la concurrence : Salesforce permet l'exécution simultanée d'un maximum de 5 jobs Batch. Si vous en soumettez davantage, ils sont placés dans l'Apex Flex Queue (qui peut contenir jusqu'à 100 jobs en état d'attente "Holding").

• L'inconvénient : Le démarrage de Batch Apex est lent. Il n'est pas conçu pour le traitement en temps quasi réel. C'est un bulldozer asynchrone destiné aux tâches ETL nocturnes, au nettoyage de données et aux recalculs planifiés massifs.

3. Queueable Apex : Le moteur moderne

Introduit comme une mise à niveau massive par rapport aux méthodes Future, Queueable Apex combine la simplicité de @future avec la puissance du Batchable. C'est la référence absolue pour les intégrations et les traitements complexes en temps quasi réel.

• Le bon côté : Contrairement aux méthodes Future, les Queueables vous permettent de passer des types complexes (comme des listes de sObjects ou des classes wrapper personnalisées). Vous obtenez un ID de tâche (Job ID) en retour, ce qui signifie que vous pouvez surveiller l'exécution dans la table AsyncApexJob.

• Le superpouvoir (Le chaînage) : Vous pouvez chaîner les Queueables entre eux. Si le Job A se termine, il peut mettre le Job B en file d'attente. C'est incroyablement utile pour interroger des API externes de manière séquentielle ou contourner les limites de temps d'attente (timeout) des API.

• Transaction Finalizers : Vous pouvez attacher un Finalizer à un job Queueable pour implémenter une logique de rejeu (retry) robuste si le job échoue en raison d'une exception non gérée ou d'un dépassement de limite.

Matrice de décision architecturale

Comment choisir ? Gardez cet aide-mémoire à l'esprit :

1. Avez-vous des millions d'enregistrements à traiter selon une planification ? → Utilisez Batchable. Laissez le QueryLocator faire le gros du travail.

2. Devez-vous traiter une liste dynamique d'enregistrements immédiatement et peut-être enchaîner un autre processus ensuite ? → Utilisez Queueable. Il est plus rapide à initialiser qu'un Batch et gère gracieusement les données complexes.

3. Avez-vous simplement besoin de contourner une erreur Mixed DML avec une seule ligne de code ? → Utilisez Future. Mais ne l'utilisez jamais à l'intérieur d'une boucle.

Verdict Final

À l'échelle de Salesforce, il ne s'agit pas d'écrire un code qui s'exécute rapidement une seule fois ; il s'agit d'écrire un code qui respecte les limites lorsque le système est soumis à une charge intense. En tirant parti de l'Apex Flex Queue et en déléguant les traitements lourds aux Queueables et aux Batches, vous vous assurez que votre logique transactionnelle principale reste simple, directe et propre.

Contact

Contactez-nous pour toute suggestion ou question technique.

Email

andre@theforcejournal.tech

© 2026. Tous droits réservés.