Accueil/Ressources/Architecture
Architecture7 min de lecture

Quand écrire de l'Apex — et quand y renoncer.

Un cadre de décision pour les équipes Salesforce qui choisissent entre configuration, Flow, Apex, LWC et services externes.

Points clés
  • Utilisez la configuration pour les règles métier simples et transparentes.
  • Utilisez Apex lorsque la complexité, le contrôle transactionnel ou la testabilité l'exigent.
  • Renoncez lorsque Salesforce n'est pas le bon environnement d'exécution.

La mauvaise question est « Salesforce peut-il le faire ? »

La bonne question est de savoir si Salesforce doit porter cette logique. Une règle visible du client, auditable et proche des données CRM a sa place dans Salesforce. Un traitement à fort volume de calcul, une transformation de données ou une intégration de longue durée ont souvent leur place ailleurs.

Quand la configuration l'emporte

La configuration s'impose lorsque la logique est simple, portée par le métier et facile à inspecter. Validations, écrans guidés, routage basique et approbations standard ne doivent pas devenir du code simplement parce qu'un développeur est disponible.

Quand Apex est le choix le plus sûr

Apex se justifie lorsque les règles exigent des frontières transactionnelles, un traitement en masse, des tests fiables, des services de domaine réutilisables ou une gestion d'erreurs maîtrisée. Le code complexe de revenus, d'orchestration et d'intégration est souvent plus sûr en Apex que dans un labyrinthe de flows.

Quand renoncer

Certains besoins sont le signal qu'il faut un service externe : traitement documentaire lourd, transformations batch massives, recherche complexe, streaming d'événements ou logique partagée entre plusieurs systèmes. Une bonne architecture, c'est aussi savoir dire non à la plateforme quand elle n'est pas le bon outil.

Besoin de cela dans votre org ?

Confiez la partie difficile à une équipe d'ingénierie Salesforce senior.

Parler de ce pattern avec nos ingénieurs