ECA est un module puissant. Peut-être même trop puissant pour son propre bien — selon le contexte dans lequel vous l'utilisez.
Qu'est-ce qu'ECA ?
ECA (Event-Condition-Action) est l'un des outils no-code les plus aboutis de l'écosystème Drupal. Son principe est simple : réagir à des événements, évaluer des conditions, déclencher des actions. En pratique, cela lui permet d'intervenir sur une grande variété de comportements Drupal, sans écrire une seule ligne de code.
Historiquement adossé à bpmn.io pour son interface de modélisation, ECA a récemment évolué avec l'arrivée du module modeler, développé en ReactJS par son contributeur principal Jürgen Haas. Cette nouvelle interface apporte notamment la possibilité de visualiser et rejouer l'exécution d'un workflow — une avancée bienvenue.
Mais une interface améliorée ne suffit pas à effacer les difficultés conceptuelles du module. Et la question reste entière : doit-on l'utiliser sur tous les projets ?
Pourquoi ce n'est pas toujours une bonne idée
Avant d'énumérer les arguments, posons le cadre : ECA n'est pas un mauvais outil. Ce qui suit, c'est une liste de situations dans lesquelles il devient un frein plutôt qu'un levier.
Une courbe d'apprentissage réelle, même pour les développeurs : ECA fonctionne par tokens pour transmettre et réutiliser des données entre ses composants. Ce mécanisme, incontournable dès qu'on traite de la donnée, demande un vrai temps d'apprentissage. Contrairement à du code PHP où la logique est explicite, ici tout repose sur un modèle mental différent — et peu documenté en dehors de cas simples.
Un niveau d'abstraction trop bas par défaut : Les événements et actions proposés nativement par ECA sont très granulaires. C'est une force pour la flexibilité, mais c'est aussi un problème : pour les utiliser correctement, il faut maîtriser les concepts internes de Drupal (entités, hooks, cycle de vie des formulaires…). ECA ne simplifie pas Drupal — il l'expose.
Complexité accrue sur les projets avec du développement spécifique : Quand un projet mêle du code personnalisé et des règles ECA, la lisibilité globale en pâtit. Il devient difficile de savoir "qui fait quoi" : est-ce un hook custom ? Un event subscriber ? Une règle ECA ? Cette dispersion du comportement applicatif augmente le coût de maintenance et complique les onboardings.
Des conflits de configuration difficiles à gérer : La configuration ECA est versionnée — en XML avec bpmn.io, en YAML avec modeler (une amélioration notable). Mais dans un workflow git classique, les merge requests sur ces fichiers restent délicates. Les diffs sont peu lisibles, les conflits complexes à résoudre, et la revue de code perd en efficacité.
Des tests fonctionnels obligatoires — et uniquement eux : On ne peut pas écrire de tests unitaires sur des règles ECA. Seuls les tests fonctionnels sont envisageables, ce qui allonge les temps d'exécution et réduit la couverture atteignable par rapport à du code classique.
Rajouter du développement pour éviter d'en faire : Si ECA ne couvre pas nativement votre besoin, il faut soit le "tordre" pour arriver à vos fins, soit développer vos propres plugins ECA. Résultat : vous écrivez du code pour éviter d'écrire du code. L'équation ne tient plus.
Un déploiement qui peut effacer vos configurations : Si votre workflow de déploiement importe automatiquement les fichiers de configuration, toute modification réalisée directement en production — par vous ou votre client — sera écrasée lors du prochain déploiement. Il faut anticiper ce cas en excluant explicitement les configs ECA de l'import, ce qui ajoute une couche de complexité opérationnelle.
Aucun filtrage natif des événements accessibles : Si vous donnez accès à l'interface ECA à un utilisateur non technique, il a accès à l'intégralité des événements et actions disponibles — y compris les plus risqués. Il n'existe pas de mécanisme natif pour restreindre cette liste.
Des performances inférieures au code dédié : L'exécution d'un workflow ECA implique le chargement et le parcours de l'ensemble du moteur de règles. Pour une fonctionnalité donnée, un code PHP ciblé sera systématiquement plus performant.
Exemple concret. En testant Drupal CMS, j'ai constaté qu'une fonctionnalité pourtant native de Drupal ne fonctionnait plus : l'envoi de l'e-mail register_no_approval_required lors de la création d'un compte utilisateur. Après investigation, la cause était une règle ECA intégrée via une recette Drupal CMS — une règle qui court-circuitait silencieusement le comportement par défaut de Drupal. Résultat : peu importe la configuration choisie, chaque création de compte déclenchait le même e-mail "un administrateur a créé un compte pour vous". Ce genre de bug est particulièrement retors à diagnostiquer, justement parce que rien dans le code ne trahit l'existence de cette règle.
Et pourtant, on l'utilise chez IOSAN
Oui. Et on continue. ECA reste un module remarquable — à condition de savoir pourquoi on l'utilise. Chez IOSAN, nous y contribuons d'ailleurs directement :
- ECA Breadcrumbs — gérer des fils d'Ariane dynamiques via ECA
- ECA Expression Language — utiliser des expressions de langage dans les conditions ECA
Ce n'est pas une contradiction : connaître les limites d'un outil, c'est précisément ce qui permet de l'utiliser intelligemment.
Alors, doit-on l'utiliser ?
La vraie question n'est pas "faut-il utiliser ECA ?" mais "dans quel cadre, et pour qui ?"
Cas favorables
- Vous souhaitez donner l'autonomie à un client, webmaster ou éditeur non technique
- La fonctionnalité est clairement délimitée, peu complexe, et toute sa logique restera dans ECA
- Vous souhaitez que la règle puisse évoluer directement en production
Cas à éviter
- Vous êtes développeur et cherchez à éviter d'écrire du code que vous maîtrisez parfaitement
- Le projet est conséquent, avec du développement spécifique en parallèle
- Vous avez besoin de tests fiables, de performances optimales ou d'un code facilement auditable
- Vous utilisez l'IA pour générer ou maintenir du code — les fichiers YML/XML d'ECA sont bien moins exploitables que du PHP
Note sur l'IA. À l'heure où les outils d'assistance au développement se généralisent, il vaut la peine de noter qu'un LLM comprend et génère du PHP bien plus efficacement que de la configuration ECA en YAML ou XML. Si vous intégrez l'IA dans votre workflow de développement, ce point pèse dans la balance.
Conclusion
L'argument principal d'ECA, c'est l'autonomie qu'il offre aux non-développeurs. Si vous souhaitez permettre à votre client de gérer ses propres règles métier sans dépendre d'une intervention technique, c'est précisément le bon outil.
En tant que développeur, ECA n'a de sens que dans un périmètre restreint : des fonctionnalités bien définies, peu complexes, dont la logique est entièrement portée par ECA — et pour lesquelles une évolution directe en production est acceptable.
En dehors de ce cadre, faites confiance à vos compétences. Le code reste, aujourd'hui encore, l'outil le plus lisible, le plus testable et le plus maintenable pour les projets sérieux.
On l'a dit, ECA est un module remarquable. Et au-delà de ses cas d'usage techniques, il joue un rôle bien plus large : il transforme radicalement Drupal. Couplé à Drupal CMS — avec son Marketplace, ses Recipes et son Module Installer — il en fait une solution accessible, sans sacrifier la stabilité, la richesse fonctionnelle ni l'open source. Drupal s'impose face à Wix, Squarespace, Weebly, Jimdo, Shopify ou BigCommerce. Une alternative sérieuse, pérenne, et sans compromis.
