Flow ou Apex : comment choisir ?
L'une des questions les plus fréquentes en développement Salesforce — faut-il construire en Flow ou écrire de l'Apex ? Voici un cadre décisionnel pratique.
L’une des questions les plus débattues dans l’écosystème Salesforce : dois-je construire ceci en Flow, ou écrire de l’Apex ? Les deux peuvent automatiser la logique d’affaires, tous deux peuvent interroger et mettre à jour des enregistrements — mais ils ne sont pas interchangeables, et choisir le mauvais outil vous coûtera cher plus tard.
Voici le cadre décisionnel pratique que nous utilisons avec chaque client.
Commencez par Flow — sauf si vous avez une raison de ne pas le faire
La position officielle de Salesforce est « clics avant code », et c’est un bon conseil pour une raison. Flow est :
- Déclaratif — pas de déploiement requis, les administrateurs peuvent le maintenir.
- Visible — tout administrateur certifié peut l’ouvrir et comprendre ce qu’il fait.
- Plus rapide à livrer — pas de classes de test, pas de configuration d’org de développement, pas de cycle de révision de code.
- Plus sûr dans les orgs sans développeur attitré — les clients qui n’ont pas de développeur en contrat peuvent le modifier eux-mêmes.
Si la logique s’intègre dans un Flow sans acrobaties, utilisez Flow.
Quand Apex est le bon choix
Flow a des limites strictes qui comptent en production. Passez à Apex dans ces cas :
1. Vous atteignez les limites de gouverneur
Flow n’est pas sûr pour les volumes par défaut. Un déclencheur sur un seul enregistrement, ça va ; 10 000 enregistrements dans un chargement de données, ça ne va pas. Apex vous donne un contrôle explicite sur la massification des requêtes SOQL et des opérations DML.
2. Logique complexe que Flow ne peut pas exprimer proprement
Les boucles imbriquées, la logique récursive, les algorithmes de tri personnalisés, les références de champs dynamiques — c’est possible en Flow, mais cela devient des configurations impossibles à maintenir. Si vous vous battez contre l’outil, l’outil n’est pas le bon.
3. Appels externes et intégrations
Les Flows peuvent effectuer des appels HTTP, mais ils sont limités aux chemins synchrones et ne peuvent pas gérer les tentatives de reprise, l’analyse des erreurs ou les flux d’authentification correctement. Apex avec @future ou Queueable vous donne un contrôle total.
4. Chemins sensibles aux performances
Un Flow déclenché par enregistrement sur un objet à fort volume (commandes, journaux, événements IoT) peut ajouter une latence significative et atteindre les limites CPU. Apex, écrit soigneusement, est plus rapide.
5. Vous avez besoin de tests unitaires sur la logique
Flow n’a pas de cadre de tests unitaires. Si l’exactitude compte — calculs financiers, logique de conformité, tout ce qui touche à l’argent — Apex vous permet d’écrire des tests déterministes avec des entrées et des sorties connues.
L’approche hybride
Les meilleures orgs Salesforce utilisent les deux. Un modèle courant :
- Flow gère l’orchestration : quand s’exécuter, quels enregistrements traiter, les mises à jour simples de champs et les notifications.
- Apex est appelé par Flow (via des méthodes invocables) pour le travail lourd : requêtes en masse, appels externes, calculs complexes.
Cela vous donne la visibilité de Flow avec la puissance d’Apex. Les administrateurs peuvent lire le flow et comprendre le processus ; les développeurs s’approprient la logique qui doit être testée et optimisée.
Une liste de contrôle décisionnelle rapide
| Question | Si oui → |
|---|---|
| Cela s’exécutera-t-il sur plus de ~200 enregistrements à la fois ? | Apex |
| S’agit-il d’appels HTTP avec des tentatives de reprise ? | Apex |
| A-t-il besoin de tests unitaires déterministes ? | Apex |
| Un administrateur peut-il le maintenir sans aide de développeur ? | Flow |
| S’agit-il d’une simple mise à jour de champ ou d’une notification ? | Flow |
| Est-ce un correctif ponctuel sans complexité future ? | Flow |
La réponse honnête
Il n’y a pas de bonne réponse universelle — cela dépend du volume de votre org, des compétences de votre équipe et de votre modèle de maintenance. Ce que nous évitons toujours : les boucles Flow complexes à plusieurs niveaux sur des objets à fort volume, et Apex qui fait des choses qu’une simple assignation Flow gérerait très bien.
En cas de doute, construisez d’abord en Flow. Si ça commence à faire mal, refactorisez en Apex. Le coût de se tromper est rarement la construction initiale — c’est la maintenance deux ans plus tard.
Vous avez une question d’automatisation spécifique ? Contactez-nous — nous sommes heureux d’examiner votre cas d’utilisation.