Le terme « feature » désigne, dans les méthodologies agiles et le product management, un bloc fonctionnel qui délivre une valeur métier identifiable. Selon le Scaled Agile Framework, une feature doit pouvoir être terminée en un seul intervalle de planification, généralement moins de deux mois. Cette contrainte de taille est le premier repère concret pour cadrer son usage en contexte professionnel.
Feature, capability, user story : clarifier le vocabulaire projet
La confusion la plus fréquente en entreprise ne porte pas sur la définition d’une feature, mais sur sa frontière avec les niveaux voisins. Dans Azure DevOps, la feature se situe sous l’epic et au-dessus des user stories. Elle représente une capacité distincte qui regroupe plusieurs stories pour former une valeur livrable.
Cette hiérarchie (epic, feature, story) n’est pas qu’un choix d’outil. Elle structure la conversation entre les équipes produit et les parties prenantes métier.
Un courant récent pousse à décorréler la feature de l’unité de conception système au profit de la notion de capability. L’idée : une capability décrit ce que le système « est », tandis qu’une feature décrit ce qu’on « construit ». Une demande de feature qui ne peut pas se composer à partir de capabilities existantes signale une capability manquante à créer. Ce changement de perspective évite d’empiler des fonctionnalités sans architecture cohérente.
- L’epic couvre un objectif stratégique large, souvent sur plusieurs mois ou trimestres.
- La feature traduit cet objectif en capacité livrable dans un cycle de planification court.
- La user story découpe la feature en tâches compréhensibles par un développeur ou un testeur.
Dimensionner une feature : le piège du périmètre trop large
La règle de dimensionnement du Scaled Agile Framework fixe un cadre strict : une feature doit tenir dans un seul Program Increment. Si elle déborde, c’est probablement un epic déguisé.
En pratique, le signe le plus fiable d’une feature mal calibrée est le nombre de user stories qu’elle génère. Au-delà d’une dizaine de stories, la feature devient difficile à suivre, à tester et à livrer de façon incrémentale. Découper tôt évite les effets tunnel en développement.
Trois critères pour valider la taille d’une feature
Le premier critère est la testabilité. Une feature correctement dimensionnée peut être validée par un scénario de test complet, de bout en bout, sans dépendre d’une autre feature non livrée.
Le deuxième critère est l’autonomie de valeur. La feature apporte un bénéfice utilisateur mesurable une fois déployée, même si d’autres features ne sont pas encore disponibles.
Le troisième est la lisibilité pour les parties prenantes métier. Si l’explication du périmètre prend plus de deux minutes en réunion de planification, la feature mérite probablement un redécoupage.
Formuler une feature en contexte professionnel sans ambiguïté
La formulation d’une feature conditionne sa compréhension par toutes les équipes impliquées. Un libellé vague (« améliorer le paiement ») génère des interprétations divergentes entre développeurs, designers et product owners.
Une formulation opérationnelle suit un schéma simple : le bénéficiaire, l’action rendue possible, et le résultat attendu. Par exemple : « L’utilisateur connecté peut enregistrer un moyen de paiement pour régler ses prochaines commandes en un clic. » Ce niveau de précision ne remplace pas les user stories, mais il aligne l’équipe sur le périmètre avant le découpage détaillé.
Erreurs courantes dans la rédaction de features
Nommer une feature par sa solution technique (« intégrer l’API Stripe ») au lieu de son objectif métier (« permettre le paiement par carte ») verrouille les choix d’implémentation trop tôt. L’équipe de développement perd sa marge de manœuvre pour proposer des alternatives.
Regrouper plusieurs bénéfices distincts dans une seule feature (« paiement et gestion des remboursements ») crée un bloc monolithique. Chaque feature ne devrait couvrir qu’un seul flux utilisateur principal.
Feature et dark patterns : la contrainte réglementaire à intégrer
Depuis le 17 février 2024, le Digital Services Act de l’Union européenne s’applique à l’ensemble des plateformes, pas uniquement aux très grands acteurs. Ce règlement interdit les dark patterns, ces interfaces conçues pour manipuler les choix de l’utilisateur.
Concrètement, une feature qui pré-coche une option payante, qui rend la désinscription plus complexe que l’inscription, ou qui ajoute des frais au panier sans consentement explicite peut exposer l’entreprise à des sanctions. En Inde, le CCPA a récemment infligé des pénalités à plusieurs plateformes numériques pour des pratiques similaires.
Cette contrainte change la façon de concevoir une feature en contexte professionnel. Le product owner doit vérifier, dès la phase de définition, que le parcours utilisateur respecte les principes de transparence et de consentement. Ce n’est plus un sujet juridique traité en aval : c’est un critère d’acceptation de la feature elle-même.
- Vérifier que chaque option ajoutée au parcours est désactivée par défaut (opt-in, pas opt-out).
- S’assurer que le flux de désabonnement ou de suppression est aussi simple que le flux d’inscription.
- Documenter la justification métier de chaque élément d’interface ajouté par la feature, pour pouvoir démontrer l’absence de manipulation en cas de contrôle.
Prioriser les features dans un backlog produit
L’ordonnancement des features repose sur un arbitrage entre valeur métier et effort de réalisation. Les techniques de priorisation (WSJF, MoSCoW, Priority Poker) diffèrent dans leur formalisme, mais partagent un principe commun : estimer l’effort au niveau feature avant de découper en stories.
Cette estimation grossière suffit pour ordonner le backlog. Décomposer toutes les features en stories avant d’avoir priorisé revient à investir du temps de découpage sur des éléments qui ne seront peut-être jamais développés.
Quand ne pas créer de feature
Une correction de bug, une tâche de maintenance technique ou une mise à jour de documentation ne sont pas des features. Les mélanger dans le même backlog fausse la visibilité sur la valeur livrée à chaque itération. La plupart des outils de gestion de projet (Azure DevOps, Jira) proposent des types de travail distincts pour cette raison.
Chaque feature ajoutée au produit augmente la surface de maintenance. Un produit avec moins de features bien choisies reste plus lisible et plus stable qu’un produit surchargé de fonctionnalités peu utilisées. La décision de ne pas créer une feature est parfois la meilleure décision produit.
