Une première version peut contenir peu de fonctionnalités et demander beaucoup de travail. Ce n’est pas forcément un problème. Le plus important est de choisir ce qu’une personne pourra vraiment accomplir avec.
« Une application pour les coachs » donne une direction. « Un coach prépare une séance et son athlète la retrouve sur son téléphone » donne un parcours à construire.
Partir du parcours
Prenons ce deuxième exemple. Le coach doit créer une séance, l’attribuer à la bonne personne et savoir qu’elle est disponible. L’athlète doit pouvoir la consulter. Il faut donc penser aux deux côtés de l’échange.
Une belle page de création ne suffit pas si personne ne retrouve ensuite la séance. À l’inverse, ce parcours peut déjà être utile sans messagerie, sans statistiques avancées et sans bibliothèque de programmes.
Qu’est-ce qu’une personne peut faire jusqu’au bout avec cette version ?
C’est la question que je garderais visible pendant le développement. Elle permet de discuter du périmètre avec un exemple concret, plutôt qu’avec une liste de modules.
Choisir ce qui attend
Pour chaque ajout, je regarde s’il est nécessaire au parcours choisi. Une notification peut être importante si l’athlète ne sait autrement pas qu’une séance l’attend. Un tableau de bord très détaillé peut attendre si aucune donnée n’a encore été produite.
La réponse dépend du contexte. Une fonction secondaire dans un produit peut être indispensable dans un autre. Je préfère noter ce que l’on reporte et pourquoi, plutôt que de le laisser disparaître dans une conversation.
Soigner les cas ordinaires
Pour une séance, on peut écrire une règle de lecture assez petite pour être discutée. Le coach voit son brouillon. L’athlète concerné voit la séance publiée. Les autres comptes n’y ont pas accès.
type Session = {
coachId: string;
athleteId: string;
published: boolean;
};
// authenticatedId doit venir de la session vérifiée côté serveur.
export function canReadSession(
session: Session,
authenticatedId: string | null,
) {
if (!authenticatedId) return false;
if (session.coachId === authenticatedId) return true;
return session.published && session.athleteId === authenticatedId;
}
Cette fonction ne remplace pas l’authentification. L’identifiant doit venir de la session vérifiée sur le serveur, jamais d’un champ envoyé par le navigateur. La requête en base doit elle aussi respecter ces droits. La règle suppose ici un coach et un athlète par séance. Un fonctionnement en équipe demanderait d’autres règles explicites.
Un compte qui n’a encore rien créé, une connexion qui coupe, un formulaire envoyé deux fois. Ce sont des situations normales. Une petite version doit aussi expliquer ce qui se passe dans ces moments-là.
Réduire le périmètre ne dispense pas de protéger les données, de vérifier les accès ou de rendre les actions compréhensibles. Ces sujets font partie du parcours. Ils ne deviennent pas moins importants parce que le produit débute.
Observer avant d’ajouter
Une fois le parcours utilisable, on peut le mettre entre les mains de quelques personnes concernées. Regarder où elles hésitent apporte souvent une question plus précise que « quelle fonctionnalité faut-il ajouter ? ».
Peut-être qu’il manque une étape. Peut-être qu’un mot est mal choisi. Peut-être que le problème de départ n’était pas celui qui comptait le plus. Une première version sert aussi à découvrir cela avant de construire la suite.