Atelier 1.2 - Fonctionnalités, rôles utilisateurs et priorisation

Documents fournis

Pour cet atelier, vous travaillez à partir du brief amendé, relu et précisé avec l’équipe technique afin de mieux cadrer la version 1 du projet.

Télécharger le brief amendé (Format : PDF, 86.7 ko)

Bon à savoir

Le brief amendé ne supprime pas toute réflexion : il clarifie le périmètre, mais il vous laisse encore un vrai travail d’analyse. Votre rôle est maintenant d’identifier les fonctionnalités, de les rattacher aux bons utilisateurs, puis de distinguer ce qui relève du MVP, du recommandé et de l’optionnel.

Objectifs de l’atelier

À l’issue de cet atelier, vous aurez :

repéré les fonctionnalités explicitement demandées dans le brief amendé.
distingué les différents types d’utilisateurs et leurs droits.
séparé les fonctionnalités obligatoires, recommandées et optionnelles.
commencé à structurer le périmètre fonctionnel de la version 1.
produit une base exploitable pour les user stories, le backlog ou le maquettage.

Durée estimée

Entre 2 h et 3 h 30. Cette durée dépend du niveau de détail de votre tri, du nombre d’échanges dans l’équipe et du soin apporté à la justification de vos choix.

Organisation et outils

Vous pouvez travailler seul, en binôme ou en petit groupe. L’important est de produire un résultat clair, relisible et justifiable.

Exemples d’outils possibles :

un tableau avec colonnes « fonctionnalité », « utilisateur », « priorité », « justification ».
un traitement de texte.
un tableur.
un fichier Markdown.
des post-it papier ou numériques pour trier les éléments du brief.

Vigilance

Ne transformez pas encore cet atelier en conception technique. On reste sur le besoin fonctionnel, les rôles et les priorités métier.

Méthode proposée

Étape 1 - Relire le brief amendé en repérant les éléments structurants

Le brief amendé apporte des précisions utiles : il distingue clairement le front-office, les utilisateurs connectés, les rôles du back-office, les fonctionnalités souhaitées et les évolutions possibles.

Pendant votre lecture, relevez notamment :

ce qui est demandé pour la version 1,
ce qui concerne les visiteurs,
ce qui concerne les utilisateurs connectés,
ce qui concerne les rôles internes (contributeur, éditeur, administrateur),
ce qui est recommandé mais non obligatoire,
ce qui relève clairement d’une évolution ou d’une V2,

Étape 2 - Identifier les rôles utilisateurs et leurs droits

Un projet devient plus clair quand on sait qui peut faire quoi. À cette étape, vous devez transformer le brief en rôles lisibles, avec des droits compréhensibles sans vocabulaire technique inutile.

Vous devez au minimum distinguer :

le visiteur : consultation libre des contenus publics,
l’utilisateur connecté : gestion de son propre profil,
le contributeur : gestion de ses propres auteurs et citations,
l’éditeur : gestion des pages de contenu institutionnel,
l’administrateur : gestion des utilisateurs et de l’ensemble des contenus,

Étape 3 - Lister les fonctionnalités

Listez les fonctionnalités en restant au niveau du besoin. Une fonctionnalité doit être formulée de manière claire, centrée sur une action utile pour un utilisateur.

Vous pouvez les classer, par exemple, dans les grandes familles suivantes :

consultation des citations,
consultation des auteurs,
pages de base du site,
gestion du profil,
gestion des citations et des auteurs,
gestion éditoriale des pages,
gestion des utilisateurs,
recherche, filtre et modération,

Étape 4 - Prioriser les fonctionnalités

Toutes les fonctionnalités n’ont pas le même niveau d’importance. Vous devez distinguer ce qui est indispensable pour faire fonctionner une version 1 crédible, ce qui est fortement recommandé, et ce qui pourra être traité plus tard.

Vous pouvez utiliser trois niveaux simples :

Obligatoire : sans cette fonctionnalité, le projet ne répond pas au besoin principal,
Recommandé : la fonctionnalité améliore fortement l’usage ou la qualité du produit,
Optionnel / plus tard : intéressant, mais non indispensable pour une première version,

Étape 5 - Produire une synthèse exploitable

À la fin de l’atelier, votre travail doit pouvoir être réutilisé dans les ateliers suivants. Il ne s’agit pas seulement d’avoir réfléchi, mais de produire un document clair qui servira de base au backlog, aux user stories ou au maquettage.

Votre synthèse doit faire apparaître au minimum :

les rôles utilisateurs retenus,
une liste structurée de fonctionnalités,
un niveau de priorité pour chaque fonctionnalité ou groupe de fonctionnalités,
quelques justifications en cas d’arbitrage ou d’hésitation,

Ce qui est supposé par défaut

Pour avancer sans vous bloquer, vous pouvez partir des hypothèses suivantes, sauf si une autre décision est explicitement prise dans le groupe.

la version 1 doit rester raisonnable et réalisable dans un cadre pédagogique,
les fonctionnalités du front-office public sont prioritaires,
la gestion des rôles doit rester simple et compréhensible,
la modération peut être pensée de manière légère mais crédible,
les évolutions listées en fin de brief relèvent plutôt d’une version 2,
la notion de thème ou catégorie peut être conservée seulement si elle apporte une vraie valeur au projet,

Livrable attendu

À la fin de l’atelier, vous devez avoir :

un tableau ou document listant les rôles utilisateurs et leurs droits principaux.
une liste structurée des fonctionnalités repérées dans le brief amendé.
une priorisation simple des fonctionnalités : obligatoire, recommandé, optionnel / plus tard.
quelques justifications courtes sur vos choix de priorisation.

Critère simple

Si votre document permet à une autre personne de comprendre rapidement qui utilise l’application, ce qu’elle doit permettre et ce qui doit être fait en premier, l’atelier est réussi.

C'est fait