En 1997, une équipe de 50 développeurs devait livrer un système bancaire complet en 15 mois. Résultat : 2 000 fonctionnalités opérationnelles livrées, dans les délais. Le secret de cette performance tient en trois mots : feature by feature.
Une approche qui bouscule l’ordre habituel de développement logiciel et qui, vingt-cinq ans plus tard, reste d’une pertinence redoutable sur les grands projets.
Origine et principes du Feature-Driven Development
Jeff De Luca est le père de cette méthode. En 1997, il conçoit le Feature-Driven Development (FDD) pour répondre à un défi concret : piloter le développement d’un système bancaire de grande envergure à Singapour, avec une équipe de 50 personnes et une contrainte de 15 mois.
Le projet est un succès. Les 2 000 fonctionnalités sont livrées, fonctionnelles, dans les temps.
L’ampleur du défi attire l’attention. Un second projet suit rapidement, encore plus massif : 18 mois, 250 développeurs, même méthode. Le modèle prouve alors qu’il tient à l’échelle.
La formalisation théorique arrive en deux temps. En 1999, Peter Coad, Eric Lefebvre et Jeff De Luca publient Java Modelling in Color with UML, premier ouvrage à décrire FDD.
En 2002, Palmer et Felsing approfondissent la méthode dans A Practical Guide to Feature-Driven Development, qui reste aujourd’hui la référence de base pour quiconque souhaite mettre en œuvre l’approche.
Le principe fondateur reste simple : organiser tout le travail autour de fonctionnalités concrètes et livrables, plutôt qu’autour de phases techniques ou de sprints génériques.
Chaque fonctionnalité a une valeur métier directe, mesurable, et s’exprime selon un format précis : « action – résultat – objet ». Par exemple : « calculer le total d’une commande client ».
Comment fonctionne concrètement le développement fonctionnalité par fonctionnalité?
FDD repose sur 5 activités de base, exécutées dans un ordre défini. Les deux premières – développer un modèle global et construire la liste des fonctionnalités – sont réalisées en amont, une seule fois.
Les trois suivantes – planifier par fonctionnalité, concevoir par fonctionnalité, construire par fonctionnalité – forment le cœur du cycle itératif.
Environ 75 % de l’effort total se concentre sur les deux dernières activités : « Design by Feature » et « Build by Feature ». C’est là que le travail réel prend forme, fonctionnalité après fonctionnalité.
Chaque fonctionnalité traverse 6 jalons séquentiels. Les trois premiers (Domain Walkthrough, Design, Design Inspection) appartiennent à la phase de conception. Les trois suivants (Code, Code Inspection, Promote to Build) constituent la phase de construction.
Ce découpage a une conséquence concrète : au moment où un développeur commence à écrire la première ligne de code, la fonctionnalité est déjà considérée comme complète à 44 % – Domain Walkthrough à 1 %, Design à 40 %, Design Inspection à 3 %.
La règle de livraison est stricte : une fonctionnalité doit être complète en 2 à 10 jours. Si une feature dépasse ce seuil, elle est découpée. Ce rythme court garantit une progression mesurable en permanence et évite les effets tunnel qui paralysent tant de projets.
FDD s’adapte aux grandes équipes là où Scrum atteint ses limites
Scrum est conçu pour des équipes réduites. Le guide officiel recommande 9 personnes maximum par équipe Scrum. Au-delà, la coordination devient difficile, les cérémonies s’alourdissent, et le modèle montre ses coutures.
FDD n’a aucune restriction de taille d’équipe. La méthode est précisément pensée pour les contextes où Scrum ne passe plus à l’échelle. Les équipes de 15 à 50 développeurs sur des systèmes d’entreprise complexes en tirent le plus de valeur. Le premier projet de Jeff De Luca en est la preuve historique.
Les secteurs bancaire, gouvernemental et télécom ont adopté FDD pour une raison précise : leurs fonctionnalités sont clairement définissables, stables dans le temps et livrables de façon incrémentale.
Un système de traitement de virements, un module de déclaration réglementaire, un outil de facturation – autant de cas où chaque fonctionnalité a des contours nets, ce qui correspond exactement au cadre que FDD exige.
Qu’est-ce que le package by feature dans l’architecture du code?
L’approche feature by feature ne concerne pas seulement la gestion de projet. Elle se prolonge dans l’architecture même du code, sous la forme d’un design pattern appelé « package by feature ».
Le principe : organiser la base de code en packages regroupant toutes les classes nécessaires à une fonctionnalité donnée, plutôt que par couche technique (controllers, services, repositories).
Une fonctionnalité « gestion des commandes » regroupe dans le même package le contrôleur, le service, le modèle et le repository qui lui sont associés.
Cette organisation produit des packages à haute cohésion et faible couplage. Elle permet d’utiliser les modificateurs d’accès package-private plutôt que public, ce qui renforce l’encapsulation et limite les dépendances involontaires entre modules.
Un développeur qui travaille sur une fonctionnalité n’a plus besoin de naviguer à travers cinq répertoires différents : tout ce dont il a besoin se trouve au même endroit.
Quand choisir l’approche feature by feature plutôt qu’une autre méthode agile?
Le choix entre FDD, Scrum et SAFe dépend de trois critères : la taille de l’équipe, la complexité fonctionnelle du projet, et la durée de livraison attendue.
- Scrum convient à une équipe de moins de 9 personnes, sur un produit dont les priorités évoluent fréquemment. Le backlog est fluide, les sprints de 2 à 4 semaines laissent de la marge pour pivoter.
- FDD s’impose dès que l’équipe dépasse 15 personnes et que les fonctionnalités sont suffisamment stables pour être découpées en 2 à 10 jours de travail. C’est le choix naturel pour les projets bancaires ou gouvernementaux de grande envergure.
- SAFe cible les organisations qui coordonnent plusieurs équipes agiles. Dans ce cadre, une feature doit être complétable par un Agile Release Train en moins de 2 mois d’effort total – une contrainte de granularité qui guide directement le découpage fonctionnel.
Un cas concret : une DSI qui déploie un système ERP sur 18 mois avec 40 développeurs a tout intérêt à opter pour FDD. Scrum créerait une friction organisationnelle importante à cette échelle. SAFe serait pertinent si plusieurs trains agiles tournaient en parallèle.
FDD offre ici la structure juste : des fonctionnalités bien découpées, un suivi à la granularité de la feature, et une progression visible semaine après semaine.
Ce qui distingue FDD en fin de compte, c’est qu’il rend la progression du projet visible à tout moment – pas à la fin d’un sprint, pas lors d’une release. À chaque fonctionnalité livrée, l’avancement est réel, mesurable, et directement lié à de la valeur métier.
C’est ce que les grandes organisations cherchent quand elles ont cessé de croire aux rapports de statut « tout va bien ».