Découper une fonctionnalité en tâches livrables
Ayoub
Tech Lead
En bref
Comment découper une fonctionnalité en tâches de développement ?
En tranches verticales qui traversent toutes les couches et produisent chacune quelque chose de démontrable, plutôt qu'en couches horizontales — base, puis service, puis interface. Chaque tranche doit être livrable en un à trois jours et apporter une valeur observable, même minime. Un découpage horizontal donne l'illusion d'avancer pendant des semaines sans que rien ne soit vérifiable.
« Cette fonctionnalité, c’est trois semaines. » C’est la réponse que je reçois le plus souvent quand je demande une estimation, et c’est presque toujours le signe qu’elle n’a pas été découpée.
Une tâche de trois semaines a deux défauts : on ne sait pas où elle en est avant la fin, et on découvre les mauvaises surprises trop tard pour réagir.
Le piège du découpage horizontal
Le réflexe naturel est de découper par couche technique :
- Créer les tables
- Écrire les services
- Exposer l’API
- Faire l’interface
C’est logique, c’est confortable, et c’est un piège. Pendant les trois premières étapes, rien n’est démontrable. Le métier ne peut rien valider. Et surtout, une erreur de compréhension faite à l’étape 1 ne sera découverte qu’à l’étape 4, quand tout est construit dessus.
Ce découpage a un autre défaut, plus insidieux : il donne l’impression d’avancer. « La base est finie, on est à 25 % » — sauf qu’on ne sait pas si le quart réalisé est le bon.
Le découpage vertical
Une tranche verticale traverse toutes les couches et produit quelque chose qu’on peut montrer.
Prenons un exemple concret : « permettre au client de suivre l’avancement de son dossier ». Découpé verticalement :
Tranche 1 — Afficher le statut brut du dossier sur une page, sans mise en forme, pour un utilisateur déjà connecté. Traverse tout, se démontre, et vérifie que la donnée existe et qu’on sait la récupérer.
Tranche 2 — Afficher l’historique des changements de statut. Ajoute une notion nouvelle et révèle immédiatement si l’historique est réellement conservé — question qu’un découpage horizontal aurait posée trois semaines plus tard.
Tranche 3 — Notifier par e-mail à chaque changement.
Tranche 4 — Mettre en forme, rendre lisible sur mobile.
Chaque tranche est livrable en un à trois jours. Chacune peut être montrée. Et si le budget s’arrête après la tranche 2, ce qui a été livré fonctionne — alors qu’un découpage horizontal arrêté à 50 % ne donne rien d’utilisable.
Photo : rawpixel — licence CC0.
Les questions qui aident à découper
Quand une tâche paraît insécable, quatre questions la fendent presque toujours.
Peut-on la faire pour un seul cas d’abord ? Un seul type d’utilisateur, un seul format, un seul canal. Les autres suivront et coûteront moins cher, la structure étant en place.
Peut-on la faire sans les cas d’erreur ? Le chemin nominal d’abord, les cas limites en tranche suivante. À condition d’être explicite : la tranche 1 n’est pas livrable en production telle quelle.
Peut-on la faire sans interface ? Beaucoup de fonctionnalités peuvent être exposées d’abord par une commande ou une API, testées par le métier, puis habillées ensuite.
Peut-on la faire à la main d’abord ? C’est la question la plus efficace. Un traitement qu’un opérateur déclenche manuellement une fois par jour peut suffire pendant un trimestre — et pendant ce temps, on apprend si l’automatisation vaut le coup.
La bonne taille d’une tranche
Ma règle : un à trois jours de développement.
En dessous, la coordination coûte plus que la tâche. Au-dessus, on retombe dans le problème initial : plus de visibilité, et des surprises tardives.
Un signe fiable qu’une tranche est trop grosse : on ne sait pas dire précisément quand elle sera finie, seulement « en fin de semaine, sans doute ». Une tranche bien taillée a une fin évidente — soit ça marche et c’est démontrable, soit non.
Photo : domaine public (CC0).
L’objection classique
« Découper en tranches verticales fait retoucher plusieurs fois les mêmes fichiers, c’est du travail en double. »
C’est vrai, et c’est un coût réel — de l’ordre de 10 à 15 % dans mon expérience.
Il est très largement compensé par ce qu’il évite : les fonctionnalités construites sur un malentendu, découvertes à la recette. Une semaine de développement jetée coûte bien plus que les quelques heures de retouches.
Et ce surcoût diminue avec un code bien structuré. Si retoucher une couche est douloureux, le problème n’est pas le découpage — c’est le couplage.
Photo : domaine public (CC0).
Les tranches qui ne se voient pas
Toutes les tâches ne produisent pas quelque chose de visible. Migration technique, montée de version, refonte interne : rien à démontrer au métier.
Je les découpe quand même, avec un autre critère : chaque tranche doit laisser le système dans un état livrable. On doit pouvoir s’arrêter à la fin de n’importe laquelle et mettre en production sans rien casser.
Concrètement, sur une migration : faire cohabiter l’ancien et le nouveau, basculer un usage, observer, basculer le suivant, puis supprimer l’ancien à la fin. C’est plus long qu’une bascule d’un bloc, et c’est ce qui permet de s’arrêter à tout moment — y compris quand une urgence commerciale tombe au milieu, ce qui arrive toujours.
Une migration menée d’un seul tenant est un pari sur le fait que rien ne viendra la perturber pendant trois semaines. Ce pari se perd souvent.
L’estimation devient un sous-produit
Un effet que je n’avais pas anticipé : quand une fonctionnalité est découpée en tranches d’un à trois jours, l’estimation cesse d’être un exercice de divination.
Six tranches de deux jours, c’est douze jours. On peut se tromper d’une tranche ; on ne se trompe plus d’un facteur trois — ce qui arrive régulièrement sur une estimation globale de « trois semaines ».
Et quand le découpage est difficile à faire, c’est en soi une information : cela signifie qu’on ne comprend pas encore assez le sujet pour l’estimer. Mieux vaut le dire à ce moment-là qu’au bout de la deuxième semaine.
Découper ce qui semble indivisible
Il existe toujours des cas où le découpage vertical paraît impossible : une reprise de données, un moteur de calcul, une refonte d’authentification.
Trois angles fonctionnent presque à chaque fois.
Par sous-ensemble de données. Reprendre d’abord les clients actifs, puis l’historique. Chaque lot se vérifie et se livre indépendamment.
Par cas d’usage. Traiter d’abord le cas nominal, qui représente 80 % du volume, et laisser les cas particuliers en traitement manuel pendant quelques semaines. Cela met le cœur du système à l’épreuve du réel bien plus tôt.
Par profondeur de règle. Un moteur de calcul se livre d’abord avec la règle générale, puis avec les dérogations. La version intermédiaire est utilisable, à condition d’afficher clairement ce qui n’est pas encore couvert.
Le point commun de ces trois angles : chaque tranche produit quelque chose d’observable. Tant qu’on ne trouve pas cet angle, c’est généralement qu’on n’a pas encore compris la fonctionnalité.
Ce que ça change au quotidien
Le point de suivi devient factuel. Au lieu de « on avance bien », on dit « les tranches 1 et 2 sont en préproduction, tu peux les voir ». Personne ne discute une démonstration.
Et le métier peut changer d’avis à moindre coût. Après avoir vu la tranche 2, un client nous a dit une fois que la notification par e-mail — la tranche 3 — ne servirait à rien, et qu’il préférait un filtre dans la liste. Nous avons économisé quatre jours et livré quelque chose d’utile.
Ce genre d’arbitrage est impossible quand tout arrive à la fin.