Recueil des besoins

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é.

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.

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 :

1✗  « Le système doit être rapide. »2✓  « Une recherche par titre répond en moins de 1 s pour 95 % des requêtes,3     jusqu'à 10 000 ouvrages. »4 5✗  « L'interface doit être conviviale. »6✓  « Un nouvel utilisateur réussit à emprunter un livre en moins de 3 minutes,7     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.

À 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.

// 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));

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