Une vertical slice avant de sur-spécifier

Il y a un moment où continuer à préciser une interface que personne n’a encore utilisée devient moins rigoureux que de construire une première version.

La vertical slice est ma réponse à ce moment-là : une version étroite du produit, mais complète de bout en bout, suffisamment réelle pour produire du feedback utile.

Le but n’est pas « coder vite ». Le but est de déplacer les décisions réversibles après le premier contact avec le produit réel, tout en verrouillant suffisamment tôt ce qui serait coûteux ou dangereux à découvrir trop tard.

Une vertical slice n’est pas une couche horizontale

Le contraste le plus simple est celui-ci.

Une progression horizontale ressemble à :

Mission 1 : boilerplate et architecture
Mission 2 : navigation
Mission 3 : base de données
Mission 4 : design system
Mission 5 : premiers écrans
Mission 6 : vrai contenu

Au bout de cinq missions, beaucoup de briques existent, mais personne ne peut encore juger l’expérience complète.

Une tranche verticale ressemble plutôt à :

Un utilisateur peut :
1. arriver sur la vraie interface ;
2. accomplir le parcours principal ;
3. voir un résultat crédible ;
4. retrouver son état si nécessaire ;
5. utiliser le produit sur les écrans réellement visés.

Il peut manquer dix fonctionnalités secondaires. Mais le cœur est observable.

Ce que le mot « verticale » implique

Une tranche utile traverse les couches nécessaires au parcours principal :

• UI ;
• logique métier ;
• données ;
• persistance si elle est réellement nécessaire ;
• erreurs importantes ;
• responsive ;
• validation ;
• un minimum de contenu réaliste.

Elle n’exige pas que chaque couche soit généralisée pour les besoins futurs.

Si la première version n’a besoin que d’une persistance locale, ajouter immédiatement une architecture multi-device « parce qu’on en aura sûrement besoin » n’améliore pas la slice. Cela augmente seulement le nombre d’hypothèses que l’on doit maintenir avant même d’avoir validé l’usage.

Commencer par le résultat observable

Avant de lister les composants, je formule ce que la personne doit pouvoir faire à la fin de la tranche.

Par exemple :

Snackset

« Depuis mon bureau, je peux lancer un exercice court, suivre son tempo, terminer ou arrêter proprement, donner un feedback et retrouver cette session dans mon historique de la journée. »

C’est beaucoup plus utile qu’une todo du type :

• créer ExerciseCard ;
• créer Timer ;
• créer History ;
• ajouter LocalStorage ;
• ajouter les animations.

La première formulation donne un critère de réussite produit. La deuxième décrit une manière possible de construire.

Verrouiller ce qui doit l’être avant de coder

Vertical slice ne signifie pas « aucune spécification ».

Avant l’implémentation, je veux être clair sur les éléments qui seraient coûteux à changer une fois la construction commencée.

Le problème utilisateur

Quel problème ou désir cette slice doit-elle rendre observable ?

Si cette phrase reste floue, produire une interface plus vite ne fera qu’accélérer la confusion.

Les invariants métier

Exemples :

• une réponse privée ne doit jamais apparaître sur le téléphone d’un autre joueur ;
• un quota ne doit pas être dépassé ;
• une action arrêtée doit tout de même créer un historique cohérent ;
• une donnée sensible ne doit pas finir dans le navigateur.

Ces règles méritent d’être décidées avant de « voir ce que ça donne ».

Les contraintes de sécurité et de données

Auth, données personnelles, permissions, paiements ou migration de production ne sont pas de simples détails réversibles.

Une slice peut en réduire le périmètre, mais elle ne doit pas contourner une contrainte importante sous prétexte de prototypage.

Le hors-périmètre

C’est probablement le document le plus utile de la slice.

Dire explicitement ce qui ne sera pas construit évite que chaque détail intéressant étende le chantier.

Exemples :

• pas de multi-device dans la V0 ;
• pas d’édition admin ;
• pas de personnalisation avancée ;
• pas de statistiques historiques ;
• pas de système générique de plugins.

Le hors-périmètre transforme une grosse idée en tranche testable.

Ce qui doit être réel dans la slice

Certaines équipes construisent une slice entièrement avec des données factices et du lorem ipsum, puis découvrent les problèmes de layout et de compréhension beaucoup trop tard.

Je préfère mettre du vrai contenu assez tôt.

Pourquoi ? Parce que le contenu révèle immédiatement :

• les titres trop longs ;
• les listes qui débordent ;
• les états impossibles à comprendre ;
• les questions ambiguës ;
• les interactions qui prennent trop de temps ;
• les différences entre desktop et mobile.

Le vrai contenu n’est donc pas seulement une finition. C’est un outil de validation de la structure.

L’architecture minimale, pas l’architecture jetable

« Ne pas sur-architecturer » ne veut pas dire accepter n’importe quoi.

Je cherche une architecture petite mais propre :

• responsabilités lisibles ;
• source de vérité identifiable ;
• pas de duplication évidente ;
• tests sur les règles qui comptent ;
• conventions du repo respectées ;
• pas de dette volontaire cachée derrière le mot prototype.

En revanche, je refuse d’abstraire un futur qui n’existe pas encore.

Si une application contient un seul type de contenu, créer immédiatement un moteur générique de blocs n’est pas un signe de qualité. C’est une hypothèse supplémentaire.

Exemple : local-first avant synchronisation

Sur plusieurs petits projets, la première question était : « Est-ce que j’utilise réellement cet outil ? »

Dans ce contexte, un stockage local derrière une petite abstraction peut être une excellente décision de vertical slice.

Il permet de valider :

• le parcours ;
• le modèle de données ;
• les interactions ;
• la fréquence d’usage ;
• le besoin réel de continuité.

Si l’usage montre ensuite que le passage ordinateur → téléphone est central, la synchronisation devient une demande fondée sur une preuve plutôt qu’une feature supposée.

Le point important est de ne pas coder LocalStorage partout en dur. Une petite frontière de repository suffit souvent à garder le choix remplaçable sans construire dès le départ tout le backend futur.

Exemple : Party Game Engine

Pour un jeu multijoueur, une vraie vertical slice n’était pas « construire le moteur de tous les modules ».

Elle devait prouver une boucle plus fondamentale :

• un joueur rejoint ;
• son téléphone envoie une réponse privée ;
• le grand écran observe le bon état ;
• le Director avance ;
• le reveal se synchronise ;
• la session survit suffisamment aux refreshs et reconnexions.

Une fois cette boucle validée, ajouter de nouveaux modules devient beaucoup moins risqué. Avant elle, développer dix mécaniques aurait surtout multiplié les façons de casser une infrastructure encore incertaine.

La slice doit être critiquable

Une première version n’apprend rien si elle est tellement incomplète que toute critique peut être repoussée à « oui, mais ce sera mieux plus tard ».

Je veux donc qu’elle atteigne un niveau où une personne peut dire sincèrement :

• « je ne comprends pas cette étape » ;
• « ce texte est trop long » ;
• « je n’utiliserais pas ça deux fois par jour » ;
• « le reveal est trop lent » ;
• « l’exercice est impossible à suivre sans regarder l’écran ».

C’est exactement ce feedback que la slice cherche à provoquer.

Responsive et états réels ne sont pas du polish

Si le produit cible un téléphone, le téléphone fait partie de la tranche.

Si l’application doit survivre à un refresh, le refresh fait partie de la tranche.

Si une erreur API est courante, l’état d’erreur fait partie de la tranche.

Repousser toutes ces dimensions dans une phase « polish » crée une fausse validation : on juge une expérience qui n’existe que dans les conditions idéales du développeur.

Je ne demande pas de traiter tous les edge cases. Je demande de traiter ceux qui déterminent si le parcours principal est réellement utilisable.

Comment définir le périmètre

J’utilise souvent un brief très court :

Résultat observable

Une ou deux phrases décrivant le parcours que l’on pourra tester.

Must-have

Les capacités sans lesquelles le résultat n’existe pas.

Out

Ce qui est explicitement différé.

Invariants

Les règles qui ne doivent pas être contournées pendant l’implémentation.

Preuves attendues

Build, tests, smoke manuel, responsive, données réalistes ou métriques nécessaires pour considérer la slice terminée.

Cette structure suffit généralement à lancer une grosse première passe sans écrire une spécification exhaustive.

Quand une vertical slice est une mauvaise idée

Elle n’est pas adaptée à toutes les situations.

Je l’utilise moins volontiers lorsque :

• une migration de production nécessite d’abord un inventaire précis ;
• les règles de sécurité doivent être établies avant toute interface ;
• plusieurs systèmes externes imposent des contrats non négociables ;
• le domaine métier est encore trop ambigu pour savoir quel parcours construire ;
• l’erreur coûte beaucoup plus cher qu’une semaine de discovery supplémentaire.

Media Kit V2 est un bon contre-exemple : réimplémenter rapidement une slice de la V1 avant d’avoir distingué comportements intentionnels et accidents historiques aurait donné une fausse impression de progrès.

Dans ce cas, l’audit est la bonne première slice de connaissance avant la slice produit.

La deuxième passe est plus importante que la première

La vertical slice n’est pas un objectif final. Sa valeur vient de ce qu’elle change la nature des discussions suivantes.

Avant :

« Est-ce qu’on devrait mettre ça à gauche ou à droite ? »

Après :

« Sur le vrai écran, cette information n’est pas vue avant l’action ; changeons la hiérarchie. »

Avant :

« Peut-être qu’on aura besoin d’un compte. »

Après :

« Trois tests ont montré que les utilisateurs passent réellement du desktop au mobile pendant une même journée ; la synchronisation devient utile. »

La deuxième passe part d’observations, pas seulement d’imagination.

Les anti-patterns fréquents

La slice qui ne traverse rien

Un beau dashboard avec des boutons inactifs n’est pas une vertical slice. C’est une maquette implémentée.

Le « prototype » qui justifie la dette

Créer une architecture illisible pour aller vite revient souvent à déplacer l’effort dans la passe suivante. Une tranche courte peut rester propre.

Le boilerplate qui devient le produit

Auth, Stripe, base et navigation peuvent donner une impression de progression alors que le parcours principal reste absent.

Le faux contenu

Le lorem ipsum masque les problèmes précisément là où le vrai produit sera contraint : libellés, densité, exceptions et variation des données.

L’absence de gate

Si personne ne sait ce que la slice doit prouver, elle devient simplement « la première version » et continue à grossir indéfiniment.

Checklist avant de lancer

• Le résultat observable tient-il en deux phrases ?
• Le parcours traverse-t-il réellement l’interface, la logique et les données nécessaires ?
• Le hors-périmètre est-il explicite ?
• Les invariants coûteux à violer sont-ils connus ?
• Le contenu utilisé est-il assez réaliste pour tester la mise en page et la compréhension ?
• Le device principal fait-il partie du test ?
• Les validations attendues sont-elles définies ?
• Les décisions réversibles sont-elles laissées suffisamment ouvertes ?

Checklist avant de déclarer la slice terminée

• Le parcours principal fonctionne-t-il de bout en bout ?
• Les états importants peuvent-ils être reproduits ?
• Le build et les tests disponibles passent-ils ?
• Le responsive réel a-t-il été regardé ?
• Les défauts découverts ont-ils produit des décisions concrètes ?
• L’état du repo permet-il à une nouvelle session de reprendre sans la conversation précédente ?

Ce que la méthode optimise

La vertical slice n’optimise pas seulement la vitesse de livraison. Elle optimise la vitesse d’apprentissage fiable.

Construire trop peu ne donne rien à juger. Construire trop large transforme des hypothèses en architecture avant qu’elles aient rencontré le réel.

La bonne tranche se situe entre les deux : assez complète pour être critiquée, assez étroite pour rester facilement corrigible.