Un cahier des charges doit décrire des exigences, c’est-à-dire un énoncé formel de ce que l’on attend du système à venir. Il ne doit pas indiquer de solution. L’exercice est loin d’être simple !
En effet, dans un cahier des charges on exprime :
- le pourquoi : motivations, objectif du système, bénéfices,
- le qui : les acteurs concernés, en particulier les futurs utilisateurs,
- le quoi : ce que le système doit apporter pour atteindre l’objectif,
- une partie du comment : les contraintes, mais sans indiquer de solution.
- Une partie du quand : délais de livraison,
- Une partie du où : périmètre géographique et organisationnel d’utilisation.
En d’autres termes, on doit décrire le service attendu de la part du système ou du fournisseur et l’usage qui sera fait du produit. On peut y ajouter des contraintes d’usage, et même des contraintes techniques, mais on ne doit pas y indiquer de solution.
La distinction entre description d’une exigence et description d’une solution, déjà très subtile pour des produits manufacturés, devient un vrai casse-tête dans le monde de l’immatériel. Voyons déjà ce que ça donne pour un produit manufacturé.
Prenons un exemple …
Un exemple provenant du monde industriel illustrera notre propos. Le maître d’ouvrage est un distributeur de produits pour fumeurs. Il constate que les briquets qu’il propose dans ses magasins sont trop chers, trop encombrants, et tombent souvent en panne. Il passe un appel d’offres pour diversifier son catalogue. Voici trois formulations différentes des exigences de cet appel d’offres :
- « Un briquet fiable, peu encombrant et peu coûteux ».
- « Un dispositif de faible encombrement, fiable et peu coûteux, permettant d’allumer une cigarette ».
- « Un dispositif de faible encombrement, fiable et peu coûteux permettant de faire du feu ».
Un briquet n’était pas la seule manière possible de satisfaire la clientèle. En utilisant le mot « briquet » dans le cahier des charges, la première formulation induit déjà une partie de la solution et bride la réponse du fournisseur au point de priver le client de la possibilité d’une solution originale.
Avec la deuxième formulation, le cahier des charges n’indique ni n’induit de solution mais une fonction (allumer une cigarette) et deux contraintes (fiable et peu coûteux). Le candidat fournisseur peut proposer un briquet, une boite d’allumettes, un allume-cigare d’automobile, ou toute autre dispositif, spécifique aux fumeurs de cigarettes.
Avec la troisième formulation, la formulation n’indique pas de solution, mais une fonction (faire du feu) et deux contraintes (fiable et peu coûteux). Le candidat fournisseur peut proposer un briquet ou une boite d’allumettes, mais pas un allume-cigare.
Que peut-on en déduire ?
Ce simple exemple, que l’on pourrait décliner à l’infini, permet de mettre en lumière plusieurs points :
- Si on ne connaît pas le qui, le quoi et le pourquoi, inutile d’aller plus loin. Avant d’indiquer d’éventuelles contraintes, il est nécessaire de connaître l’objectif, le périmètre et les parties prenantes du système à l’étude.
- Il est difficile d’exprimer des exigences sans induire de solution a priori.
- Une même exigence fonctionnelle peut donner lieu à des solutions très différentes.
- L’expression de l’exigence fonctionnelle (ce que le système doit faire) peut être aisée à formuler. En revanche, l’expression des exigences de qualité ou de performance (parfois appelées « non-fonctionnelles ») demande beaucoup de soin dans sa formulation : que signifient « fiable » et « peu coûteux » ?
- Sans exprimer de solution, il est souvent nécessaire d’exprimer des contraintes d’environnement ou des contraintes d’interface : l’objet doit tenir dans une poche, dans la main, ou être alimenté en énergie par l’automobile.
Qu’en est-il du logiciel ?
Nous avons pris ici un exemple dans le monde de l’industrie manufacturière. Qu’en est-il du logiciel ?
Les objets physiques sont tributaires des contraintes liées aux matériaux utilisés (acier, bronze, laiton, matières plastiques. Avec le logiciel, le seul matériau à notre disposition, le logiciel, est homogène, et également invisible, inodore et impalpable. De ce fait, aucune contrainte n’est évidente.
Alors que les exigences implicites d’un objet manufacturé comme un briquet sont peuvent être sous-entendues (le dispositif ne devrait pas s’enflammer spontanément dans la poche de l’utilisateur, ni blesser celui qui le manipule), la fiabilité, la sécurité et l’utilisabilité du logiciel sont des contraintes invisibles, mal maîtrisées, et rarement évidentes. Et c’est à la maîtrise d’ouvrage de les expliciter dans le cahier des charges. Sans contraintes explicites, il n’y a pas de qualité du logiciel.
© Yves Constantinidis Consultant, 2023