Flow
Automation déclarative avec une structure claire, une nomenclature cohérente et une documentation.
Développement et Automatisation
Implémentation vs Développement. Choix éclairé à l'ère de l'IA
Construction d'automatisations et développement sur mesure sur Salesforce avec un choix délibéré entre le déclaratif et le code, en fonction de la complexity, de la performance 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
Développement et Automatisation — Cartographie des Capacités
Flow
Automation déclarative avec une structure claire, une nomenclature cohérente et une documentation.
Apex
Logique complexe, volumes élevés et tests unitaires réels.
LWC
Interfaces personnalisées qui optimisent le travail quotidien.
Platform Events
Découplage des systèmes via des événements plutôt que des appels directs.
Tests et qualité
Couverture de tests significative, pas seulement formelle, et revue de code.
Contrôle de version
Environnements de test (sandboxes), publication contrôlée et documentation des changements.
Contexte
Ce qui détermine réellement le résultat
La majeure partie de la dette technique sur Salesforce ne provient pas d'un mauvais code, mais d'une accumulation d'automatisations construites séparément sur le même objet, sans que personne n'ait une vue d'ensemble.
La règle pratique est simple : tout ce qui peut être résolu de manière déclarative et claire doit être construit ainsi. Ce qui exige une logique complexe, un volume élevé ou un contrôle précis de l'ordre d'exécution se justifie en code, avec des tests.
Chaque automatisation a besoin d'un responsable et d'une documentation. Une automatisation dont personne ne comprend le but restera des années dans le système et causera des problèmes silencieusement.
Ce que nous faisons
Domaines d'intervention
Apex
Logique complexe, volumes élevés et tests unitaires réels.
LWC
Interfaces personnalisées qui optimisent le travail quotidien.
Platform Events
Découplage des systèmes via des événements plutôt que des appels directs.
Tests et qualité
Couverture de tests significative, pas seulement formelle, et revue de code.
Contrôle de version
Environnements de test (sandboxes), publication contrôlée et documentation des changements.
Matrice de Décision
Les décisions qui déterminent le résultat
| Exigence | Déclaratif | Code | Ce qui décide |
|---|---|---|---|
| Mise à jour de champs et conditions | Flow | — | Simplicité et maintenabilité |
| Logique avec de nombreuses exceptions | Difficile à maintenir | Apex | Nombre de conditions et d'appels |
| Volume élevé d'enregistrements | Peut atteindre des limites | Apex optimisé | Échelle du traitement |
| Interface personnalisée | Page standard | LWC | Complexité de l'interaction |
| Publication vers plusieurs systèmes | Appels directs | Platform Events | Nombre de consommateurs et tolérance aux pannes |
Mise à jour de champs et conditions
- Déclaratif
- Flow
- Code
- —
- Ce qui décide
- Simplicité et maintenabilité
Logique avec de nombreuses exceptions
- Déclaratif
- Difficile à maintenir
- Code
- Apex
- Ce qui décide
- Nombre de conditions et d'appels
Volume élevé d'enregistrements
- Déclaratif
- Peut atteindre des limites
- Code
- Apex optimisé
- Ce qui décide
- Échelle du traitement
Interface personnalisée
- Déclaratif
- Page standard
- Code
- LWC
- Ce qui décide
- Complexité de l'interaction
Publication vers plusieurs systèmes
- Déclaratif
- Appels directs
- Code
- Platform Events
- Ce qui décide
- Nombre de consommateurs et tolérance aux pannes
Comment nous travaillons
Étapes de livraison
- 01
Mapper les automatisations existantes
Ce qui est exécuté sur chaque objet et dans quel ordre.
- 02
Décider de l'approche
Déclarative ou code, avec justification documentée.
- 03
Construire
Convention de nommage, modularité et prévention de la duplication.
- 04
Tests
Scénarios positifs et négatifs, pas seulement couverture.
- 05
Publication
Environnement de test, revue et fenêtre de publication définie.
- 06
Nettoyage
Éliminer les automatisations redondantes et réduire la dette.
Continuez à explorer
Services et guides associés
Questions fréquentes
Développement et Automatisation — questions courantes
Flow est-il toujours meilleur qu'Apex ?
Non. Flow est préférable lorsque la logique est simple et claire, car sa maintenance est économique et accessible aux administrateurs. Pour une logique complexe, des volumes élevés ou un contrôle précis de l'ordre d'exécution, Apex avec des tests est l'option la plus sûre.
Combien d'automatisations peuvent exister pour un même objet ?
Le nombre importe moins que la transparence. Le vrai problème commence quand personne ne sait ce qui est exécuté et dans quel ordre. Un modèle organisé et documenté pèse plus qu'une règle rigide.
Qu'est-ce qui est considéré comme de la dette technique dans ce contexte ?
Des automatisations dupliquées, du code sans tests, des champs inutilisés, des permissions trop larges et une logique sans responsable. Tout cela augmente le risque de tout changement futur.
Avons-nous besoin d'un outil DevOps ?
Oui, dès qu'il y a plus d'un développeur ou un rythme constant de publications. Dans un petit environnement, un processus discipliné de sandboxes et de documentation peut être suffisant au début.
Prochaine étape
Analysez votre couche d'automatisation
Nous cartographierons ce qui est actuellement exécuté, identifierons les duplicatas et définirons une norme que votre équipe pourra réellement maintenir.
Prochaine étape
Analysez votre couche d'automatisation
Nous cartographierons ce qui est actuellement exécuté, identifierons les duplicatas et définirons une norme que votre équipe pourra réellement maintenir.