Découper une app métier en tranches livrables (et ne plus jamais faire de tunnel)

Le tunnel de trois mois est le meilleur moyen de rater une application métier. On cadre, on développe, on montre à la fin. Et à la fin, l'utilisateur dit la phrase qui coûte cher : « ah, mais nous on ne fait pas comme ça. » Voici le découpage qu'on utilise pour éviter ça. Rien de révolutionnaire, mais quelques règles précises qui changent le résultat.

La règle de la tranche verticale

Une tranche livrable traverse toute la pile : base de données, logique, interface. Elle est utilisable de bout en bout par un vrai utilisateur. C'est l'inverse du découpage par couche, où l'on fait « toute la base » puis « toute l'API » puis « tout le front ». Ce découpage-là ne produit rien de testable avant la fin.

❌ Semaine 1 : le schéma complet de la base
❌ Semaine 2 : toutes les routes API
❌ Semaine 3 : tous les écrans

✅ Semaine 1 : créer une commande et la voir dans une liste - écran compris
✅ Semaine 2 : la modifier et changer son statut
✅ Semaine 3 : la recherche et les filtres

Après la première semaine, quelqu'un peut ouvrir l'outil et faire quelque chose de réel. C'est là que remontent les vrais retours.

Le format de spec qui tient en un fichier

Chaque tranche a un fichier. Toujours la même structure, et elle sert autant à l'équipe qu'à l'assistant de code.

# Tranche 03 - Changement de statut d'une commande

## Ce que l'utilisateur peut faire
Ouvrir une commande, passer son statut de "en préparation" à "expédiée", et voir qui l'a changé et quand.

## Règles métier
- Seuls les rôles `préparateur` et `admin` peuvent changer un statut.
- Un retour en arrière est interdit sauf pour `admin`.
- Chaque changement écrit une ligne dans `commande_historique`.

## Hors périmètre (important)
- Pas de notification e-mail (tranche 07).
- Pas d'export (tranche 09).

## Fini quand
- [ ] Un préparateur change un statut et voit l'historique se remplir.
- [ ] Un commercial n'a pas le bouton.
- [ ] Un retour en arrière est refusé avec un message clair.

La section Hors périmètre est celle qui fait le plus de travail. Elle empêche le glissement de périmètre, qui représente couramment 30 à 50 % de charge supplémentaire sur un projet mal tenu. La section Fini quand évite l'autre classique : le désaccord sur ce que « terminé » veut dire.

Pourquoi ce format marche bien avec un assistant de code

On travaille avec Claude Code au quotidien. Ce format de fichier est celui qui donne les meilleurs résultats, pour une raison simple : un assistant échoue surtout quand le contexte est implicite. Les règles métier écrites noir sur blanc (« un retour en arrière est interdit sauf admin ») produisent du code correct du premier coup. Les mêmes règles laissées dans la tête du chef de projet produisent du code plausible et faux.

Le « Hors périmètre » a un effet secondaire utile : il empêche l'assistant d'anticiper. Sans cette section, il ajoute spontanément une notification e-mail parce que ça semble logique - et vous héritez d'un code que personne n'a demandé, ni relu.

Un point sur lequel on ne transige pas : les critères de « Fini quand » deviennent des tests avant d'être considérés comme validés. Environ 45 % du code généré par IA contient au moins une vulnérabilité selon les analyses publiées en 2026. Ce chiffre ne condamne pas l'outil, il rappelle juste où mettre la relecture humaine.

L'ordre des tranches n'est pas neutre

On classe toujours dans cet ordre :

• La tranche qui prouve l'usage. Celle qui, si elle ne convainc pas, invalide le projet entier. Elle passe en premier, quand le budget est encore intact.
• Les tranches à risque technique. Intégration avec un système existant, import de données sales, API tierce mal documentée. Jamais à la fin.
• Le confort. Filtres, exports, tableaux de bord. Utiles, mais aucun projet ne meurt de leur absence en semaine 4.

L'erreur fréquente est de commencer par l'authentification et l'administration des comptes, parce que c'est « la base ». C'est trois semaines avant de montrer quoi que ce soit d'intéressant. Une authentification minimale suffit largement au départ.

Ce que ça change concrètement

Le bénéfice n'est pas la vitesse brute. C'est que l'erreur de cadrage se paie en une semaine au lieu de trois mois. Sur une app métier standard, ça donne une première version utilisable en 6 à 10 semaines, avec des retours utilisateurs dès la deuxième. Et surtout : le jour où le client dit « nous on ne fait pas comme ça », il le dit assez tôt pour que ça ne coûte presque rien.

On détaille les étapes complètes d'un projet, les délais et les budgets réels ici : créer une application sur mesure.