Flow
Automatisation déclarative avec une structure claire, des noms cohérents et une documentation.
Développement et automatisation
Flow ou Apex — Une décision éclairée, pas une habitude.
Construction d'automatisations et de développements sur Salesforce avec un choix conscient entre le déclaratif et le code, en fonction de la complexité, des performances et du coût de maintenance — incluant tests, contrôle de version et réduction de la dette technique.
Cartographie des capacités
Ce qui est inclus et dans quel ordre
La carte montre les couches de travail dans ce service, depuis l'infrastructure jusqu'aux capacités que les utilisateurs voient.
Développement et automatisation — Cartographie des capacités
Flow
Automatisation déclarative avec une structure claire, des noms cohérents et une documentation.
Apex
Logique complexe, volumes élevés et tests unitaires réels.
LWC
Interfaces dédiées qui accélèrent le travail quotidien.
Platform Events
Séparation des systèmes via des événements plutôt que des appels directs.
Tests et qualité
Couverture de test significative et non formelle, et revue de code.
Contrôle de version
Sandboxes, déploiement contrôlé et documentation des changements.
Le contexte
Ce qui est vraiment décisif ici
La majeure partie de la dette technique sur Salesforce ne provient pas d'un mauvais code, mais d'une prolifération d'automatisations construites séparément sur le même objet, sans qu'une vision globale soit prise en compte.
La règle pratique est simple : ce qui peut être résolu de manière déclarative et claire sera construit ainsi. Ce qui exige une logique complexe, un volume élevé ou un contrôle précis de l'ordre des opérations est justifié par le code, avec des tests.
Chaque automatisation doit avoir un propriétaire et une documentation. Une automatisation dont personne ne sait pourquoi elle a été construite restera silencieusement dans le système pendant des années et cassera des choses.
Domaines d'intervention
Ce que nous faisons concrètement
Apex
Logique complexe, volumes élevés et tests unitaires réels.
LWC
Interfaces dédiées qui accélèrent le travail quotidien.
Platform Events
Séparation des systèmes via des événements plutôt que des appels directs.
Tests et qualité
Couverture de test significative et non formelle, et revue de code.
Contrôle de version
Sandboxes, déploiement contrôlé et documentation des changements.
Matrice de décision
Les décisions qui déterminent le résultat
| Exigence | Déclarative | Code | Ce qui est décisif |
|---|---|---|---|
| Mise à jour des champs et des conditions | Flow | — | Simplicité et maintenance |
| Logique avec de nombreuses exceptions | Difficile à maintenir | Apex | Nombre de conditions et d'appels |
| Volume élevé d'enregistrements | Peut rencontrer des limitations | Apex personnalisé | Portée du traitement |
| Interface dédiée | Page standard | LWC | Complexité de l'interaction |
| Publication sur plusieurs systèmes | Appels directs | Platform Events | Nombre de consommateurs et tolérance aux pannes |
Mise à jour des champs et des conditions
- Déclarative
- Flow
- Code
- —
- Ce qui est décisif
- Simplicité et maintenance
Logique avec de nombreuses exceptions
- Déclarative
- Difficile à maintenir
- Code
- Apex
- Ce qui est décisif
- Nombre de conditions et d'appels
Volume élevé d'enregistrements
- Déclarative
- Peut rencontrer des limitations
- Code
- Apex personnalisé
- Ce qui est décisif
- Portée du traitement
Interface dédiée
- Déclarative
- Page standard
- Code
- LWC
- Ce qui est décisif
- Complexité de l'interaction
Publication sur plusieurs systèmes
- Déclarative
- Appels directs
- Code
- Platform Events
- Ce qui est décisif
- Nombre de consommateurs et tolérance aux pannes
Mode de fonctionnement
Étapes d'exécution
- 01
Cartographie des automatisations existantes
Qu'est-ce qui s'exécute sur chaque objet et dans quel ordre.
- 02
Décision d'approche
Déclaratif ou code, avec justification documentée.
- 03
Construction
Standardisation des noms, modularité et prévention de la duplication.
- 04
Tests
Scénarios positifs et négatifs, pas seulement couverture.
- 05
Déploiement
Sandbox, revue et fenêtre de déploiement définie.
- 06
Nettoyage
Suppression des automatisations inutiles et réduction de la dette.
28. Questions fréquentes
Foire aux questions
Flow est-il toujours préférable à Apex ?
Non. Flow est préférable lorsque la logique est simple et claire, car il est peu coûteux à maintenir et accessible même à un administrateur. Lorsque la logique est complexe, les volumes élevés ou le besoin d'un contrôle précis de l'ordre des opérations, Apex avec ses tests est le choix le plus sûr.
Combien d'automatisations sont autorisées sur un seul objet ?
Le nombre est moins important que la transparence. Le problème survient lorsque personne ne sait ce qui est exécuté et dans quel ordre. Une norme ordonnée et une documentation sont plus importantes qu'une règle stricte.
Qu'est-ce qui est considéré comme une dette technique dans ce contexte ?
Les automatisations en double, le code sans tests, les champs inutilisés, les autorisations trop larges et la logique sans propriétaire. Tous ces éléments augmentent le risque à chaque changement futur.
Faut-il un outil DevOps ?
S'il y a plus d'un développeur ou un rythme de publication régulier, oui. Dans un petit environnement, un processus Sandbox ordonné et une documentation peuvent suffire au début.
L'étape suivante
Examen de la couche d'automatisation
Nous cartographierons ce qui est actuellement en cours, identifierons les doublons et définirons une norme maintenable.