À propos de ce cours
Toutes les idées ne peuvent pas entrer dans un projet. Cette leçon montre comment fixer, avant de concevoir, ce que le projet couvre et ce qu’il ne couvre pas. Vous apprendrez à reconnaître la dérive du périmètre, à classer les demandes, à formuler un objectif mesurable et à rédiger une fiche de cadrage validée par le commanditaire. Un jeu de rôle vous entraîne à répondre à une demande de dernière minute sans perdre de vue le problème principal.
-
Objectifs
- Définir le périmètre d'intervention d'un projet UX
- Reconnaître et éviter la dérive du périmètre
- Délimiter le périmètre avec six questions: utilisateurs, parcours, canaux, fonctions, contraintes, hors périmètre
- Classer les demandes : dans le périmètre, plus tard, hors périmètre
- Formuler un objectif mesurable
- Rédiger et faire valider une fiche de cadrage
-
Présentation
- Après les personas et les parcours, les idées affluent : chaque douleur appelle une fonction, et chaque personne du projet a sa demande. Si l'équipe accepte tout, le projet s'allonge, le budget explose et le problème principal n'est jamais vraiment résolu.
- Préciser le périmètre d'intervention, c'est décider, avant de concevoir, ce que le projet couvre et ce qu'il ne couvre pas. C'est un accord écrit entre l'équipe et le commanditaire, qui protège le projet et ses utilisateurs.
- Nous continuons avec BiblioCampus: la directrice de la bibliothèque vous demande une version 2 de l'application. Pour les activités, créez le dossier
06-3-perimetre/dans votre dépôt GitHubui-ux-design-bts.
-
Qu'est-ce que le périmètre ?
- Le périmètre (scope) est la frontière du projet : les utilisateurs servis, les parties du parcours traitées, les fonctions conçues, les supports, les limites de temps et de moyens, et ce qui est explicitement exclu.
- Le périmètre ne se décide pas au hasard : il découle du problème prioritaire mis au jour par la recherche, des personas et des parcours.
-
La dérive du périmètre
- La dérive du périmètre (scope creep) est l'ajout progressif de demandes qui n'étaient pas prévues. Chacune paraît petite ; ensemble, elles bloquent le projet :

- Une nouvelle demande n'est pas forcément mauvaise. Le problème est de l'accepter sans décider: sans mesurer son effet sur le délai, sans la comparer au problème prioritaire, sans rien retirer en échange.
-
Les six questions du périmètre
- Pour délimiter un projet, on répond par écrit à six questions :

- La sixième question est la plus souvent oubliée. Écrire ce que l'on ne fait pas évite les malentendus : si la réservation des salles n'est pas écrite « hors périmètre », la directrice peut croire qu'elle est prévue.
-
Classer les demandes
- Chaque demande est placée dans l'une des trois colonnes : dans le périmètre, plus tard (une version suivante) ou hors périmètre (un autre projet, un autre service, ou jamais) :

- Pour décider, posez trois questions : la demande répond-elle au problème prioritaire ? Concerne-t-elle le persona principal ? Tient-elle dans les contraintes ? Trois « non » mènent hors périmètre.
- La colonne « plus tard » rassure : une bonne idée n'est pas perdue, elle est seulement reportée.
-
Fixer un objectif mesurable
- Le périmètre comprend un objectif mesurable: il permettra de savoir, à la fin, si le projet a réussi. « Améliorer la réservation » ne se vérifie pas ; « réserver en moins de 60 secondes, sans aucune réservation en double, avec 90 % de réussite au test » se vérifie.
- Un bon objectif indique un indicateur, une valeur cible et une façon de le mesurer. Il reprend les chiffres de la phase d'exploration comme point de départ.
-
La fiche de cadrage
- Tout le périmètre tient sur une page : la fiche de cadrage. Elle est relue et validée par le commanditaire avant le début de la conception :

- Les hypothèses et risques signalent ce qui n'est pas encore sûr : ici, la disponibilité en temps réel dépend du logiciel du catalogue. Si l'hypothèse tombe, on revient à la fiche.
- La fiche est un document vivant : elle est versionnée sur GitHub, et toute modification passe par un commit qui explique pourquoi le périmètre a changé.
-
Exemple 1 : une demande de dernière minute
- En semaine 3, la directrice demande : « Pouvez-vous ajouter la réservation des salles de travail ? »
- L'équipe consulte la fiche : la demande ne répond pas au problème prioritaire (les déplacements inutiles et les doublons), et elle ajouterait environ trois semaines.
- Elle propose deux options à la directrice : reporter la demande en version 3, ou l'ajouter en retirant la notification « livre prêt ». La directrice choisit le report. La fiche est mise à jour, avec un commit : « Reporte la réservation des salles en version 3 ».
-
Exemple 2 : réduire pour mieux tester
- La dernière étape du parcours, « retirer le livre au guichet », pose aussi problème. Mais le guichet et son logiciel ne changeront pas cette année.
- L'équipe sort donc cette étape du périmètre et le note dans la fiche. Elle concentre ses huit semaines sur les quatre étapes qu'elle peut vraiment améliorer, de la recherche à l'attente.
- Un périmètre plus petit, mais tenu et testé, apporte plus aux utilisateurs qu'un grand périmètre bâclé.

-
Activité 1 : dans ou hors du périmètre ?
- À l'aide de la fiche de cadrage de BiblioCampus, classez ces demandes :
- a) afficher le nombre d'exemplaires libres ;
- b) payer une amende en ligne ;
- c) prolonger un prêt depuis « Mes prêts » ;
- d) proposer des livres numériques ;
- e) rendre le formulaire utilisable au clavier.
- Vérifier : a) dans ; b) hors ; c) dans ; d) plus tard ; e) dans.
- À l'aide de la fiche de cadrage de BiblioCampus, classez ces demandes :
-
Activité 2 : classer les demandes de CantineCampus
- Voici les demandes notées pendant la réunion avec le gestionnaire du restaurant. Classez-les dans un tableau à trois colonnes et justifiez chaque choix :

- Vérifier : les demandes qui réduisent l'attente ou informent avant de venir (commander à l'avance, menus, affluence, allergènes) sont dans le périmètre ; la gestion des stocks et la livraison en salle sont hors périmètre ; chaque choix cite le problème prioritaire ou une contrainte.
-
Activité 3 : répondre aux six questions
- Rédigez, pour CantineCampus, une réponse courte à chacune des six questions du périmètre.
- Vérifier : les utilisateurs sont vos personas ; les étapes renvoient à votre parcours ; la rubrique « hors périmètre » contient au moins trois éléments.
-
Activité 4 : réécrire des objectifs
- Rendez ces objectifs mesurables : « réduire l'attente » ; « une application facile » ; « plus de clients satisfaits ».
- Vérifier : chaque objectif contient un indicateur, une valeur cible et une façon de le mesurer, par exemple « attente moyenne inférieure à 8 minutes entre 12 h et 13 h, mesurée par observation ».
-
Activité 5 : hypothèses et risques
- Listez trois hypothèses dont dépend votre projet CantineCampus (par exemple : « le logiciel de caisse peut recevoir des commandes »). Pour chacune, indiquez comment la vérifier et ce que vous ferez si elle est fausse.
- Vérifier : chaque hypothèse a une action de vérification et une solution de repli.
-
Activité 6 : rédiger la fiche de cadrage
- Rédigez la fiche de cadrage de CantineCampus dans
projet-cantinecampus/02-definir/fiche-cadrage.md, avec toutes les rubriques de l'exemple. - Vérifier : la fiche tient sur une page ; quelqu'un qui ne connaît pas le projet comprend ce qui sera fait, pour qui, et ce qui ne sera pas fait.
- Rédigez la fiche de cadrage de CantineCampus dans
-
Activité 7 : jeu de rôle
- Par deux : l'un joue le gestionnaire qui demande « un jeu concours pour attirer les étudiants » ; l'autre répond avec la fiche de cadrage, sans dire « non » sèchement, en proposant des options.
- Vérifier : la réponse s'appuie sur le problème prioritaire, propose au moins deux options (reporter, échanger contre une autre fonction) et se termine par une décision notée dans la fiche.
-
Activité 8 : déposer votre travail sur GitHub
- Regroupez vos réponses dans
06-3-perimetre/README.md, puis envoyez le tout :
- Regroupez vos réponses dans
git add 06-3-perimetre projet-cantinecampus/02-definir
git commit -m "Ajoute la fiche de cadrage du projet CantineCampus"
git push
- Vérifier : la fiche de cadrage s'affiche sur GitHub ; si vous l'avez modifiée après le jeu de rôle, l'historique montre un commit qui explique le changement.
-
Erreurs fréquentes
| Erreur ou réflexe | Pourquoi c'est un problème | Ce qu'il faut faire |
|---|---|---|
| Accepter chaque demande au fil de l'eau | Dérive du périmètre : retards et projet dilué | Faire passer chaque demande par la fiche de cadrage |
| Ne pas écrire ce qui est hors périmètre | Le commanditaire croit que tout est prévu | Une rubrique « hors périmètre » explicite |
| Un objectif vague : « améliorer l'expérience » | Impossible de dire si le projet a réussi | Un indicateur, une valeur cible, une mesure |
| Définir le périmètre par les fonctions seules | On oublie pour qui et pour quelle étape | Répondre aux six questions |
| Refuser sèchement une demande | Le commanditaire se sent ignoré | Proposer des options : reporter, échanger, chiffrer |
| Cacher les hypothèses | Le projet s'écroule si l'une d'elles est fausse | Les écrire, avec une vérification et une solution de repli |
| Viser trop large pour faire plaisir | Rien n'est terminé ni testé | Un périmètre plus petit, mais tenu |
-
À retenir
- Le périmètre fixe ce que le projet couvre, et ce qu'il ne couvre pas.
- Il découle du problème prioritaire, des personas et des parcours.
- Six questions : utilisateurs, parcours, canaux, fonctions, contraintes, hors périmètre.
- Chaque demande est classée : dans le périmètre, plus tard ou hors périmètre.
- Un objectif mesurable permet de juger la réussite.
- La fiche de cadrage est validée par le commanditaire et versionnée.
Dire « pas maintenant » à une bonne idée, c'est dire « oui » au problème que vos utilisateurs vous ont confié.