Chapitre 1 · 4 h
Recueil des besoins
Besoins fonctionnels et non fonctionnels ; entretien avec le client ; rédaction d'un cahier des charges simple ; les critères d'un besoin bien formulé — vérifiable, non ambigu.
Le chapitre 2 l'a montré : l'erreur la plus coûteuse est celle qu'on commet au tout début, en comprenant mal ce que le logiciel doit faire. Le bloc III attaque donc cette première étape, la plus décisive : recueillir les besoins et les écrire sans ambiguïté. C'est là que se fixe le cap du projet — et c'est là que naissent, ou non, les malentendus qui exploseront plus tard.
Ce chapitre apprend à distinguer les types de besoins, à les recueillir auprès du client, et surtout à reconnaître un besoin bien formulé : vérifiable et non ambigu. C'est la compétence qui sépare un cahier des charges utile d'une liste de vœux pieux.
Besoins fonctionnels et non fonctionnels
Un besoin décrit une attente du client. On les range en deux familles, et confondre les deux fait rater la moitié du travail.
Un besoin fonctionnel dit ce que le logiciel doit faire — une fonction offerte à un utilisateur : « emprunter un livre », « ajouter un ouvrage », « envoyer un rappel ». C'est le plus visible, celui auquel on pense spontanément.
Un besoin non fonctionnel dit comment il doit le faire — une propriété de la façon dont les fonctions sont rendues : performance (« répondre en moins de 2 s »), sécurité (« mots de passe chiffrés »), disponibilité, ergonomie, capacité, portabilité.
| Besoin fonctionnel | Besoin non fonctionnel | |
|---|---|---|
| Répond à | que fait le logiciel ? | comment le fait-il ? |
| Exemple | « l'utilisateur peut emprunter un livre » | « une recherche répond en moins de 2 s » |
| Risque | oubli d'une fonction | souvent oublié entièrement |
Le piège est que les non fonctionnels sont souvent oubliés au recueil — et ce sont eux qui coûtent le plus cher à rattraper. On ne « sécurise » pas ni on n'« accélère » pas un logiciel après coup sans le refondre : ces qualités doivent guider la conception dès le départ. Les recenser explicitement est un réflexe à prendre.
L'entretien avec le client
Les besoins ne tombent pas du ciel : on va les chercher auprès du client, et c'est un exercice délicat. Le client sait ce qu'il veut faire, rarement ce que le logiciel doit faire — et il tient souvent pour évident ce qui ne l'est pas pour vous.
Quelques principes pour un entretien utile :
- Poser des questions ouvertes d'abord (« décrivez-moi une journée type »), fermées ensuite pour préciser (« combien d'utilisateurs en même temps ? »).
- Faire préciser les mots vagues : « rapide », « simple », « beaucoup » ne veulent rien dire tant qu'on ne les a pas chiffrés (voir plus bas).
- Chercher les cas limites et les exceptions : que se passe-t-il si le livre est déjà emprunté ? si l'utilisateur n'existe pas ? Le client décrit spontanément le cas nominal ; les ennuis viennent des autres.
- Reformuler et faire valider : « si je comprends bien, vous voulez… » — c'est le seul moyen de débusquer un malentendu à froid, quand il coûte 1 et non 100 (chapitre 2).
La difficulté est plus humaine que technique : écouter, ne rien supposer, oser les questions qui paraissent bêtes. C'est exactement le genre de faille qui a coûté le Mars Climate Orbiter.
Quiz · 1 question
Parmi ces besoins, lequel est NON fonctionnel : « l'utilisateur peut réserver un livre », « le système chiffre les mots de passe », « le bibliothécaire consulte les emprunts en cours » ?
- « l'utilisateur peut réserver un livre » — une action utilisateur
- « le système chiffre les mots de passe » : c'est une propriété (sécurité) de la façon dont le logiciel fonctionne, pas une fonction offerte à un acteur — une propriété de sécurité
- « le bibliothécaire consulte les emprunts en cours » — une action bibliothécaire
Réponse : « Réserver un livre » et « consulter les emprunts » sont des FONCTIONS offertes à un acteur : des besoins fonctionnels. « Chiffrer les mots de passe » ne décrit aucune fonction visible de l'utilisateur — c'est une PROPRIÉTÉ (de sécurité) de la manière dont le logiciel se comporte : un besoin non fonctionnel. Ces derniers sont souvent oubliés au recueil et coûtent cher à rattraper, car on ne sécurise pas un logiciel après coup sans le refondre.
Le cahier des charges
Le résultat du recueil se consigne dans un cahier des charges : le document qui fixe, par écrit et validé par le client, ce que le logiciel doit faire. À votre niveau, il reste simple — quelques pages — mais il structure tout le reste :
- une description du contexte et des objectifs ;
- la liste des acteurs (qui utilise le logiciel, chapitre 5) ;
- les besoins fonctionnels, un par un, numérotés ;
- les besoins non fonctionnels ;
- les contraintes (délais, technologies imposées, budget).
Son rôle n'est pas administratif : c'est le contrat partagé entre le client et l'équipe, la référence à laquelle on reviendra pour trancher les désaccords (« ce n'était pas dans le cahier des charges ») et pour vérifier, à la fin, qu'on a bien livré ce qui était demandé (les tests de recette, bloc V). Dans votre projet de semestre, vous le rédigez juste après ce bloc.
Un besoin bien formulé : vérifiable et non ambigu
Voici le cœur du chapitre, et sa compétence centrale. Un besoin n'a de valeur que s'il est vérifiable et non ambigu — c'est-à-dire si l'on peut, à la fin, dire objectivement s'il est satisfait ou non.
Comparez :
✗ « Le système doit être rapide. »✓ « Une recherche par titre répond en moins de 1 s pour 95 % des requêtes, jusqu'à 10 000 ouvrages. » ✗ « L'interface doit être conviviale. »✓ « Un nouvel utilisateur réussit à emprunter un livre en moins de 3 minutes, sans aide, lors d'un test avec 5 personnes. »« Rapide », « convivial », « beaucoup », « robuste » sont inexploitables : deux personnes les comprennent différemment, et surtout on ne pourra jamais les tester. Un besoin dont on ne peut pas écrire le test de recette n'est pas un besoin, c'est un vœu. On le rend vérifiable en le chiffrant et en précisant les conditions : quoi exactement, mesuré comment, dans quel contexte, avec quel seuil.
Le critère décisif, à retenir : si vous ne pouvez pas imaginer le test qui dira « oui, c'est satisfait » ou « non », le besoin est mal formulé. L'exercice vous fait transformer des vœux en besoins testables.
Quiz · 1 question
Pourquoi le besoin « le logiciel doit être facile à utiliser » est-il mal formulé, et comment le corriger ?
- Il n'est pas mal formulé : la facilité d'utilisation est un objectif légitime — objectif légitime suffit
- Il est ambigu et non vérifiable : « facile » n'a pas de sens objectif et on ne peut pas le tester. On le corrige en le rendant mesurable, par exemple « un nouvel utilisateur accomplit la tâche X en moins de N minutes sans aide » — ambigu et non testable
- Il est trop précis : il faudrait le rendre plus général pour couvrir tous les cas — trop précis
Réponse : « Facile à utiliser » est un vœu, pas un besoin : « facile » n'a pas de sens objectif (chacun l'entend à sa façon) et rien ne permet de vérifier s'il est atteint. La facilité d'utilisation est un objectif légitime, mais tel quel il est inexploitable. On le rend VÉRIFIABLE en définissant un critère observable et mesurable — un temps, un taux de réussite, un nombre d'erreurs lors d'un test utilisateur. Règle : si aucun test ne peut dire « satisfait ou non », le besoin est mal formulé.
À vous
L'exercice muscle les deux réflexes du chapitre. D'abord, classer les besoins en fonctionnels et non fonctionnels — pour ne pas oublier ces derniers. Ensuite, et surtout, réécrire des besoins flous (« rapide », « convivial », « beaucoup ») en besoins vérifiables : chiffrés, conditionnés, testables.
C'est l'exercice qui prépare directement votre cahier des charges : chaque ligne que vous y écrirez devra pouvoir devenir, plus tard, un test qui répond par oui ou par non.
Exercice de code
Distinguez les besoins fonctionnels des non fonctionnels, puis réécrivez des besoins flous (« rapide », « convivial », « beaucoup ») en besoins vérifiables et non ambigus. Un besoin dont on ne peut pas écrire le test n'est pas un besoin, c'est un vœu.
Point de départ
// Un besoin FONCTIONNEL dit ce que le logiciel DOIT FAIRE (une fonction).
// Un besoin NON FONCTIONNEL dit COMMENT il doit le faire : performance,
// sécurité, ergonomie, disponibilité... des propriétés, pas des fonctions.
const BESOINS = [
{ texte: "L'utilisateur peut emprunter un livre", type: "fonctionnel" },
{ texte: "Une recherche répond en moins de 2 secondes", type: "non-fonctionnel" },
{ texte: "Le bibliothécaire peut ajouter un ouvrage", type: "fonctionnel" },
{ texte: "Les mots de passe sont stockés chiffrés", type: "non-fonctionnel" },
{ texte: "Le système envoie un rappel avant la date de retour", type: "fonctionnel" },
];
// ── À VOUS (1) : classer ────────────────────────────────────────────────────
function classer(texte) {
// à compléter : renvoyer "fonctionnel" (une action/fonction offerte) ou
// "non-fonctionnel" (une qualité : vitesse, sécurité, ergonomie...).
// Indice : cherche des mots de qualité (secondes, chiffré, disponible...).
return "?";
}
console.log("Classement :");
for (const b of BESOINS) {
const r = classer(b.texte);
console.log((r === b.type ? " ok " : " ✗ ") + r.padEnd(15) + " | " + b.texte);
}
// ── (2) Un besoin BIEN FORMULÉ est VÉRIFIABLE et NON AMBIGU ──────────────────
// Ces besoins-ci sont inexploitables : on ne saura jamais dire s'ils sont
// satisfaits. À VOUS de dire POURQUOI chacun est mauvais, puis de le réécrire.
const FLOUS = [
"Le système doit être rapide.",
"L'interface doit être conviviale.",
"Le logiciel doit gérer beaucoup d'utilisateurs.",
];
// Remplir 'reecritures' : pour chaque flou, une version MESURABLE.
const reecritures = [
// "Une page se charge en moins de 1 s pour 95 % des requêtes.",
];
console.log("\nRéécritures proposées :");
reecritures.forEach((r) => console.log(" " + r));
Solution
function classer(texte) {
// Marqueurs d'un besoin NON fonctionnel : une propriété mesurable ou de
// qualité (temps, sécurité, disponibilité, capacité...).
if (/secondes?|chiffr|disponib|sécuris|rapide|charge|% /.test(texte)) return "non-fonctionnel";
return "fonctionnel"; // sinon, c'est une action offerte à un acteur
}
const reecritures = [
// « rapide » -> quoi, mesuré comment, dans quelles conditions ?
"Une recherche par titre renvoie ses résultats en moins de 1 seconde pour 95 % des requêtes, jusqu'à 10 000 ouvrages.",
// « conviviale » -> un critère observable, testable auprès d'utilisateurs.
"Un nouvel utilisateur réussit à emprunter un livre en moins de 3 minutes sans aide, lors d'un test avec 5 personnes.",
// « beaucoup » -> un nombre.
"Le système supporte 200 utilisateurs simultanés sans que le temps de réponse dépasse 2 secondes.",
];
// ── Ce que l'exercice enseigne ──────────────────────────────────────────────
//
// 1. FONCTIONNEL vs NON FONCTIONNEL : le premier dit ce que le logiciel FAIT
// (emprunter, ajouter, envoyer un rappel) ; le second dit une PROPRIÉTÉ de
// la façon dont il le fait (vitesse, sécurité, ergonomie, capacité). Les
// non fonctionnels sont souvent oubliés au recueil — et coûtent le plus
// cher à rattraper (on ne « sécurise » pas un logiciel après coup sans le
// refondre).
//
// 2. Un besoin BIEN FORMULÉ est VÉRIFIABLE et NON AMBIGU. « Rapide »,
// « convivial », « beaucoup » sont inexploitables : deux personnes les
// comprennent différemment, et on ne pourra jamais TESTER s'ils sont
// satisfaits. Un besoin dont on ne peut pas écrire le test de recette
// (bloc V) n'est pas un besoin, c'est un vœu.
//
// 3. On rend un besoin vérifiable en le CHIFFRANT et en précisant les
// CONDITIONS : quoi exactement, mesuré comment, dans quel contexte, avec
// quel seuil. « Rapide » devient « moins de 1 s pour 95 % des requêtes,
// jusqu'à 10 000 ouvrages ».
//
// 4. C'est le cœur du cahier des charges : chaque ligne doit pouvoir se
// transformer, plus tard, en un test qui répond par oui ou par non. Un
// besoin mal formulé au départ, c'est l'erreur amont la plus chère du
// chapitre 2.
Ce que la suite en fait
Les besoins sont recueillis et bien formulés. Reste à les structurer pour passer vers le code : qui utilise le logiciel, pour quoi faire, avec quels objets et quelles interactions ? C'est le rôle de la modélisation.
Le chapitre 5 introduit UML — mais avec parcimonie, comme le veut le niveau : trois diagrammes utiles (cas d'utilisation, classes, séquence) maîtrisés valent mieux que neuf survolés. Le diagramme de cas d'utilisation, notamment, dérive directement des acteurs et des besoins fonctionnels que vous venez d'apprendre à recueillir.
À retenir
Flashcards · 4 cartes
- Quelle est la différence entre un besoin fonctionnel et un besoin non fonctionnel ?
- Un besoin FONCTIONNEL dit ce que le logiciel DOIT FAIRE — une fonction offerte à un acteur (« emprunter un livre »). Un besoin NON FONCTIONNEL dit COMMENT il le fait — une propriété : performance, sécurité, ergonomie, disponibilité, capacité (« répondre en moins de 2 s »). Les non fonctionnels sont souvent oubliés au recueil et coûtent le plus cher à rattraper, car ils doivent guider la conception dès le départ.
- Qu'est-ce qui caractérise un besoin BIEN formulé ?
- Il est VÉRIFIABLE et NON AMBIGU : on peut dire objectivement, à la fin, s'il est satisfait ou non. Le critère décisif : pouvoir imaginer le test qui répond « oui » ou « non ». « Rapide », « convivial », « beaucoup » sont des vœux inexploitables ; on les rend vérifiables en les CHIFFRANT et en précisant les conditions (quoi, mesuré comment, dans quel contexte, quel seuil).
- À quoi sert le cahier des charges, au-delà d'un document administratif ?
- C'est le CONTRAT partagé entre le client et l'équipe : la référence validée qui fixe ce que le logiciel doit faire (contexte, acteurs, besoins fonctionnels numérotés, besoins non fonctionnels, contraintes). On y revient pour trancher les désaccords et pour vérifier, à la fin, qu'on a livré le demandé (tests de recette). Un besoin mal écrit ici est l'erreur amont la plus chère (chapitre 2).
- Quels sont les principes d'un bon entretien de recueil des besoins ?
- Questions ouvertes d'abord, fermées ensuite pour préciser ; faire chiffrer les mots vagues (« rapide », « beaucoup ») ; chercher les cas limites et exceptions (que se passe-t-il si… ?) que le client oublie ; reformuler et faire valider (« si je comprends bien… »). La difficulté est humaine : écouter, ne rien supposer, oser les questions qui paraissent évidentes — c'est là que naissent les malentendus coûteux.