Spécification et parcours utilisateur

Cette leçon est encore en test : elle s'améliore avec les retours des apprenants. Si quelque chose n'est pas clair, c'est la leçon qu'il faut corriger, pas toi.

À la fin de cette leçon, tu sauras

transformer un besoin en une spécification qui tient en une page ;
décrire le parcours de la personne qui se servira de l’outil ;
fixer une version minimale et des critères vérifiables ;
décider des données de l’outil, et n’en garder que le nécessaire.

Pourquoi ça t’intéresse

Un agent peut construire un outil en quelques minutes. Mais si tu ne sais pas exactement ce que tu veux, il le décidera à ta place : les écrans, les données, ce qui est envoyé où. La spécification est ta commande. Elle tient en une page, elle se discute avant de construire, et elle te servira à vérifier le résultat. C’est le même principe que la fiche projet du module 6, appliqué à un outil.

Avant de commencer


Il te faut	Claude Code (appli ou terminal), en mode Manuel, un dossier de projet vide (par exemple dans `mon-espace-ia/projets`), et le modèle de spécification (ressource)
Coût	L’abonnement de l’agent : Claude Pro au minimum, 18 € par mois hors taxes en facturation mensuelle, ou 15 € par mois hors taxes avec l’abonnement annuel de 180 € payé d’avance ; prix affichés sur claude.com/pricing au 24/10/2026
Durée	60 minutes
Rappel	La spécification décrit les données de l’outil : rien de plus que le nécessaire

Comprendre en 3 minutes

Les parties d’une spécification (modèle dans la ressource) :

Partie	La question
Le problème	Qu’est-ce qui ne va pas aujourd’hui ?
Qui s’en sert	Qui, sur quel appareil, à quel moment ?
Le parcours	Que fait la personne, étape par étape ?
La version minimale	Quel est le plus petit outil qui règle déjà le problème ?
Hors sujet pour l’instant	Qu’est-ce qu’on ne fait pas dans cette version ?
C’est réussi si	Quels critères, vérifiables par oui ou non ?
Les données	Lesquelles, où restent-elles, que ne garde-t-on pas ?

Le parcours se raconte du point de vue de la personne : « J’ouvre le fichier, je vois les livres pas encore rendus, je tape le titre et le prénom… ». Pas « l’application affiche un tableau ».

Les données. La CNIL conseille, avant toute collecte, de réfléchir aux types de données nécessaires et de restreindre la collecte au strict nécessaire. Pour un carnet d’emprunts, un prénom et un titre suffisent : pas d’adresse, pas de téléphone.

Des contraintes simples pour commencer : un seul fichier, qui s’ouvre dans le navigateur, sans compte, sans serveur, sans rien installer, sans rien charger depuis Internet. Tout reste sur ton ordinateur.

Faire ensemble

1Étape 1 : Le besoin, en deux phrases

L’exemple du module : le club de lecture veut savoir qui a emprunté quel livre de sa « boîte à livres », et ce qui n’est pas encore rendu. Écris ton propre besoin en deux phrases, ou garde celui-ci pour t’exercer.

2Étape 2 : Faire proposer la spécification

Ouvre Claude Code sur ton dossier de projet, en mode Manuel, et utilise la demande de la ressource.

Lors de notre essai du 24/10/2026, avec le besoin du club et les sept parties du tableau ci-dessus (le modèle de la ressource ajoute deux rubriques, CONTRAINTES et À DÉCIDER), la spécification a suivi ces sept parties, avec des critères vérifiables (« Je note un emprunt (titre + prénom) en moins de 30 secondes »), marqué « [à décider] » ce qu’il fallait trancher (qui tient le carnet, au bout de combien de jours un livre est en retard), et prévenu d’elle-même que les données resteraient liées à ce navigateur, sur cet ordinateur, d’où une sauvegarde à prévoir. Elle a fini par trois questions.

3Étape 3 : Trancher

Réponds aux questions, et remplace chaque [à décider] par ta décision. Puis relis avec la liste de la ressource :

chaque critère se vérifie-t-il par oui ou non ?
les données sont-elles réduites au nécessaire ?
la version minimale tient-elle en une phrase ?

4Étape 4 : Garder la spécification

Garde specification.md dans le dossier du projet : c’est la référence des leçons suivantes. Note la date en haut.

Faire toi-même

Choisis un vrai petit problème : un suivi, une liste, un calcul qui revient, une page d’informations.
Fais proposer la spécification, avec tes contraintes.
Tranche chaque point, et relis avec la liste de la ressource.
Garde la spécification dans le dossier du projet, datée.

Ressources à télécharger

Modèle de spécification d’un petit outil : les parties, la demande à ton agent, et la liste à relire avant de construire.

Vérifier

C’est réussi si :

ta spécification a ses parties, et plus aucun [à décider] ;
chaque critère se vérifie par oui ou non ;
les données sont réduites au nécessaire, et tu sais où elles restent ;
la version minimale tient en une phrase.

Erreurs fréquentes :

commencer à construire « pour voir », avant la spécification ;
une version minimale qui contient déjà tout ;
des critères flous (« simple », « joli ») ;
garder des données « au cas où ».

Conserver et reprendre

La spécification vit avec le projet : quand tu changes d’avis, change-la d’abord, puis l’outil.
Note ta décision et sa raison dans ton journal (module 5, leçon 3).

Pour aller plus loin

facultatif

Le guide RGPD du développeur de la CNIL : cnil.fr, « Guide RGPD du développeur ».

Mots nouveaux

4 mots expliqués

Mot	Ce que ça veut dire
Spécification	La page qui dit ce que doit faire l’outil, et comment on saura que c’est réussi
Parcours utilisateur	Les étapes, vues par la personne qui se sert de l’outil
Version minimale	Le plus petit outil qui règle déjà le problème
Minimisation des données	Ne collecter que les données vraiment nécessaires