Si vous développez sur Salesforce Sales Cloud, vous avez forcément été confronté à cette question : dois-je coder en Apex, construire un Flow, ou utiliser un Process Builder existant ? En 2026, la réponse est plus claire que jamais — mais elle nécessite quand même de comprendre les forces et limites de chaque outil.
Langage de programmation propriétaire Salesforce (syntaxe Java-like). Incontournable pour la logique complexe, les intégrations et les traitements en masse.
Outil déclaratif no-code/low-code. Devenu très puissant depuis 2022. C'est le choix par défaut de Salesforce pour l'automatisation.
Déprécié officiellement par Salesforce. Plus aucun nouveau développement ne devrait l'utiliser. Migration vers Flow recommandée.
🚨 Process Builder est déprécié. Salesforce a annoncé sa fin de support. Si vous avez encore des Process Builders en production, planifiez leur migration vers Flow dès maintenant. Salesforce ne précise pas de date exacte mais la direction est claire et irréversible.
Apex reste indispensable dans ces situations :
Dès que votre automatisation implique plusieurs conditions imbriquées, des boucles complexes, des calculs avancés ou une logique qui dépasserait les capacités déclaratives de Flow, Apex est la bonne réponse. Un Flow trop complexe devient vite illisible et impossible à maintenir.
Apex est conçu pour traiter des lots de 200 enregistrements à la fois (gouverneur limits Salesforce). Si vous importez ou modifiez des milliers de records via des jobs batch (Batchable, Schedulable), Apex est obligatoire. Un Flow de type Record-Triggered peut gérer du bulk, mais avec des limites bien plus strictes.
Pour appeler une API externe depuis un déclencheur Salesforce — envoyer une requête REST à un système tiers, recevoir une réponse et agir en conséquence — Apex est la solution native. Les Flow peuvent faire des callouts via des actions invocables, mais c'est souvent une surcouche sur du code Apex de toute façon.
Salesforce impose une couverture de code de 75% minimum pour déployer en production. Les Apex triggers et classes doivent être couverts par des tests unitaires — c'est une contrainte mais aussi une garantie de qualité que Flow n'offre pas nativement.
Les Apex Triggers (before insert, after update…) restent le meilleur moyen de gérer des logiques précises sur le cycle de vie des enregistrements Salesforce, notamment quand les conditions sont multiples et les effets de bord à maîtriser.
Flow Builder est devenu l'outil de référence de Salesforce pour l'automatisation no-code. Il couvre aujourd'hui la majorité des cas d'usage :
Les Record-Triggered Flows remplacent avantageusement les Workflow Rules et Process Builders. Création d'une tâche, envoi d'un email, mise à jour d'un champ, notification — tout cela se fait en Flow sans écrire une ligne de code.
Les Screen Flows permettent de construire des assistants pas-à-pas directement dans l'interface Salesforce. Qualification d'un lead, prise de commande, processus de validation — ce type de Flow améliore significativement l'expérience utilisateur.
Les Scheduled Flows permettent de déclencher des automatisations à une heure ou une fréquence donnée. Remplacent les Scheduled Apex dans de nombreux cas simples.
Flow peut être appelé depuis Apex, depuis un autre Flow, depuis une page Lightning ou depuis une API. C'est un excellent point d'orchestration pour des processus qui mêlent actions automatiques et interactions utilisateur.
💡 Bonne pratique : préférez Flow à Apex dès que le cas d'usage le permet. Un Flow est plus facile à maintenir par un administrateur Salesforce, plus visible dans l'interface et plus rapide à modifier sans déploiement.
| Situation | Outil recommandé | Pourquoi |
|---|---|---|
| Mise à jour automatique d'un champ | Flow | Record-Triggered Flow, no-code |
| Envoi d'email automatique | Flow | Action standard disponible |
| Calcul complexe multi-objets | Apex | Logique métier avancée |
| Import de 50 000 records | Apex Batch | Gouverneur limits |
| Appel API externe | Apex | HTTP Callout natif |
| Assistant guidé utilisateur | Flow | Screen Flow dédié |
| Planification hebdomadaire | Flow | Scheduled Flow |
| Logique de validation complexe | Apex | Before trigger + tests |
| Processus existant en Process Builder | Flow | Migration obligatoire |
En 2026, la ligne est claire : Flow pour tout ce qui est standard et déclaratif, Apex pour la complexité et les contraintes de volume. Process Builder n'a plus sa place dans un développement Salesforce moderne. Si vous avez encore des doutes sur quel outil choisir pour un cas d'usage précis, l'arbre de décision ci-dessus couvre 90% des situations rencontrées sur le terrain.
If you develop on Salesforce Sales Cloud, you've inevitably faced this question: should I code in Apex, build a Flow, or use an existing Process Builder? In 2026, the answer is clearer than ever — but it still requires understanding the strengths and limitations of each tool.
Salesforce proprietary programming language (Java-like syntax). Essential for complex logic, integrations and bulk processing.
Declarative no-code/low-code tool. Has become very powerful since 2022. Salesforce's default choice for automation.
Officially deprecated by Salesforce. No new development should use it. Migration to Flow is recommended.
🚨 Process Builder is deprecated. Salesforce has announced end of support. If you still have Process Builders in production, plan their migration to Flow now. Salesforce hasn't specified an exact date but the direction is clear and irreversible.
Apex remains essential in these situations:
As soon as your automation involves multiple nested conditions, complex loops, advanced calculations or logic that exceeds Flow's declarative capabilities, Apex is the right answer. An overly complex Flow quickly becomes unreadable and impossible to maintain.
Apex is designed to process batches of 200 records at a time (Salesforce governor limits). If you're importing or modifying thousands of records via batch jobs (Batchable, Schedulable), Apex is mandatory. A Record-Triggered Flow can handle bulk, but with much stricter limits.
To call an external API from a Salesforce trigger — send a REST request to a third-party system, receive a response and act accordingly — Apex is the native solution. Flows can make callouts via invocable actions, but these are often just a wrapper around Apex code anyway.
Salesforce mandates 75% minimum code coverage to deploy to production. Apex triggers and classes must be covered by unit tests — this is a constraint but also a quality guarantee that Flow doesn't natively offer.
Apex Triggers (before insert, after update…) remain the best way to handle precise logic on the Salesforce record lifecycle, especially when conditions are multiple and side effects need to be controlled.
Flow Builder has become Salesforce's reference tool for no-code automation. It now covers the majority of use cases:
Record-Triggered Flows advantageously replace Workflow Rules and Process Builders. Creating a task, sending an email, updating a field, sending a notification — all of this can be done in Flow without writing a single line of code.
Screen Flows allow building step-by-step wizards directly in the Salesforce interface. Lead qualification, order intake, approval process — this type of Flow significantly improves user experience.
Scheduled Flows allow triggering automations at a given time or frequency. They replace Scheduled Apex in many simple cases.
Flow can be called from Apex, from another Flow, from a Lightning page or from an API. It's an excellent orchestration point for processes mixing automated actions and user interactions.
💡 Best practice: prefer Flow over Apex whenever the use case allows it. A Flow is easier to maintain by a Salesforce administrator, more visible in the interface and faster to modify without deployment.
| Situation | Recommended tool | Why |
|---|---|---|
| Automatic field update | Flow | Record-Triggered Flow, no-code |
| Automatic email sending | Flow | Standard action available |
| Complex multi-object calculation | Apex | Advanced business logic |
| Importing 50,000 records | Apex Batch | Governor limits |
| External API call | Apex | Native HTTP Callout |
| Guided user assistant | Flow | Dedicated Screen Flow |
| Weekly scheduled task | Flow | Scheduled Flow |
| Complex validation logic | Apex | Before trigger + tests |
| Existing Process Builder to evolve | Flow | Mandatory migration |
In 2026, the line is clear: Flow for everything standard and declarative, Apex for complexity and volume constraints. Process Builder has no place in modern Salesforce development. If you still have doubts about which tool to choose for a specific use case, the decision tree above covers 90% of situations encountered in the field.
Je peux vous accompagner sur le développement, l'architecture et la montée en compétences de vos équipes. Réponse sous 24h.I can support you on development, architecture and team upskilling. Reply within 24 hours.
Parlons de votre projet →Let's talk →