Dans les transformations agiles à l’échelle, notamment avec le framework SAFe, on parle souvent de Feature et d’Enabler-Feature. Mais quelle est la différence entre les Features et les Enablers ? Pourquoi est-ce important de bien les distinguer dans un backlog ? Et surtout, quels types de développement se cachent derrière chacun ?
En bref
Une Feature est un besoin et non une solution. C’est un usage, une fonction ou une action que l’utilisateur peut réellement faire grâce à une solution co-construite. La feature a une valeur visible pour l’utilisateur final (qu’il soit client externe ou utilisateur interne).
Une Enabler-Feature est une « feature » technique, non directement visible du client, mais essentielle pour permettre, sécuriser ou accélérer le développement de fonctionnalités métier. Une sorte de levier technique ou exploratoire.
Ce qu’elles ont en commun
Ces deux éléments sont au même niveau de backlog dans SAFe, avec des propriétés identiques en termes de gestion :
- Elles sont toutes deux planifiables dans un PI (Program Increment).
- Elles vivent dans le Program Backlog (et non dans les Team Backlogs).
- Elles comportent une description claire, des critères d’acceptation, une estimation WSJF.
- Elles peuvent toutes être découpées en User Stories confiées aux équipes agiles pour exécution.
Quels types de développements selon les éléments de travail ?
Que ce soit une Feature ou une Enabler-Feature, du développement est souvent nécessaire. Mais le type de travail attendu varie fortement selon l’intention.
Voici une synthèse des types de livrables et de développements associés à chaque type de Feature :
1. Feature fonctionnelle
- Frontend : interface utilisateur, écrans, interactions
- Backend : logique métier, API
- Tests automatisés : validation fonctionnelle
- Stockage : persistance des données
Exemple : visualisation d’équipements dans l’interface, création d’une alerte fonctionnelle, visualiser mon portefeuille.
2. Enabler – Infrastructure
- DevOps / CI-CD : scripts de déploiement, pipelines
- Scripting : automatisation d’opérations
- Monitoring : outillage, supervision, logs centralisés
Exemple : Mettre en place des dashboards Grafana pour le suivi des performances des concentrateurs, développer un script de rollback automatique en cas d’échec de mise à jour
3. Enabler – Conformité
- Backend / Sécurité : chiffrement, structuration des logs, gestion des rôles
- Tests QA : audit de conformité, couverture légale
- Reporting : journalisation, alerting, traçabilité
Exemple : mise en conformité des logs applicatifs, intégration d’un protocole sécurisé comme TLS.
4. Enabler – Architecture
- Refactoring technique : séparation de responsabilités, modularisation
- Backend / Standardisation : design d’API, création de composants partagés
- Conventions DevOps : normes de développement, définition de pipelines
Exemple : refonte du module de supervision, définition d’une stratégie de test E2E.
5. Enabler – Exploration
- Prototypage rapide : maquettes fonctionnelles, POC, démo interne
- Spike technique : test de framework, validation de faisabilité
- Documentation : rapport d’analyse, critères de choix, recommandations
Exemple : prototype d’application mobile, évaluation d’un nouveau protocole de communication.
| Critère | Feature | Enabler-Feature |
|---|---|---|
| Finalité | Fonction métier attendue | Préparation technique, conformité ou exploration |
| Valeur utilisateur | Directe et visible | Indirecte mais nécessaire |
| Démo | Visible et testable par l’utilisateur | Démo technique ou preuve de faisabilité |
| Exemples | Configuration seuil, visualisation équipements | Banc de test, migration infra, logs normés |
| Impact si ignorée | Le besoin métier n’est pas couvert | Les features futures seront bloquées ou risquées |
Récapitulatif : tableau comparatif Feature vs Enabler-Feature
En conclusion
💡 Ce n’est pas parce qu’un utilisateur ne “voit” pas un enabler qu’il n’est pas essentiel. Un système robuste, évolutif et conforme repose justement sur ce qu’on ne voit pas… mais qui structure tout.
Une Feature, c’est ce que le client attend. Une Enabler-Feature, c’est ce que l’équipe doit faire pour que la Feature soit possible, maintenable, fiable, conforme ou testable.
Ils sont complémentaires. Ensemble, ils structurent le travail à faire tout en allant au-delà des exigences exclusivement fonctionnelles.
Ne pas investir dans les Enablers, c’est risquer d’avancer sans base technique solide. C’est aussi laisser de côté les exigences non-fonctionnelles (NFR), comme :
- les performances,
- la résilience,
- la sécurité,
- l’évolutivité,
- l’observabilité,
- ou encore la conformité.
Les NFR doivent être prises en compte dès la planification. Nous créons et structurons itérativement nos produits au fil des releases que nous mettons en production avec ce qui est prêt. Ces micro-releases doivent permettre de confirmer l’atteinte des exigences fonctionnelles ou non-fonctionnelles au fur et à mesure. Les oublier ou prévoir de les valider à quelques semaines de la mise en production de la version du produit est une erreur stratégique. Pour poursuivre ce sujet je vous invite à faire un tour sur l’article Tour d’horizon des non-functional requirements.
