Tout aussi important, voire plus important que le cahier des charges : le document de concept. Un préalable indispensable.

Dans le cycle de vie du logiciel, préalablement la phase d’expression des besoins, il y a en a une encore plus importante. Son nom change d’une méthodologie à l’autre. On peut l’appeler « étude préalable », « analyse préliminaire », « cahier des charges préliminaire », « vision et portée du produit » (Vision and Scope). Mais le nom le plus exact est celui de concept.

Lors de la phase de concept, il s’agit d’exprimer avec précision et concision : l’objectif, le périmètre et les parties prenantes du système à l’étude. On doit donc répondre à trois questions simples à propos du futur produit :

• Il fera quoi ?
• Il servira à qui ?
• Pour atteindre quel but ?

Il en résulte un document très bref, validé au plus haut niveau hiérarchique, et qui sera utilisé comme fil conducteur à l’expression des besoins du système à l’étude. Il peut en outre comporter des contraintes de coût, de délai, de sécurité, de conformité, d’interfaces, etc.

Pour comprendre ce qu’est un concept bien formulé, on peut prendre l’exemple de la Citroën 2CV. Il a été énoncé en quelques lignes : « Une voiture pouvant transporter deux cultivateurs en sabots, cinquante kilos de pommes de terre ou un tonnelet à une vitesse maximum de 60 km/h pour une consommation de trois litres d’essence aux cent kilomètres. En outre, ce véhicule doit pouvoir passer dans les plus mauvais chemins, il doit être suffisamment léger pour être manié sans problèmes par une conductrice débutante. Son confort doit être irréprochable car les paniers d’œufs transportés à l’arrière doivent arriver intacts. Il devra également être possible de monter à 4 personnes dans la voiture sans quitter son chapeau de la tête. Son prix devra être bien inférieur à celui de notre Traction Avant ».

Ce texte est souvent cité comme « le cahier des charges de la 2CV ». En réalité, il ne s’agit pas d’un cahier des charges, mais d’un énoncé de concept. Il apporte les réponses aux trois questions citées plus haut en indiquant quelques contraintes.

La phase de concept est rarement formalisée en tant que telle dans les méthodologies de développement de logiciel. On la représente rarement dans le cycle en V. Et pour cause : La phase de concept fait partie du cycle de vie du logiciel, mais pas du cycle de développement.

Définir le concept est une opération des plus difficiles. Mais une fois que cette phase est validée, tout devient plus simple et plus clair. Je me souviens d’un des premiers cahiers des charges que j’ai écrits. C’était il y a tout juste vingt ans. Il s’agissait d’élaborer un cahier des charges pour un logiciel de portée nationale, déployée sur cent sites départementaux, et qui devait remplacer une application vieillissante et obsolète qui tournait sur du matériel en fin de vie. De plus, la maîtrise d’ouvrage du projet était partagée entre deux ministères. C’est dire la complexité du projet ! Et voilà qu’on m’envoie écrire le cahier des charges de cette nouvelle application, moi qui n’avais jamais écrit plus de dix pages d’exigences.  Car à l’époque, on n’apprenait pas l’ingénierie des besoins à la fac, et il n’y avait aucun livre sur le sujet, du moins en français (mon ouvrage Définition des besoins pour le logiciel est paru en 2006). Comme m’avait dit un de mes collègues, « tout bon consultant sait faire un cahier des charges ». Pour ma part, j’y mettrais quelques bémols.

Ce qui m’a permis de réussir mon cahier des charges malgré de très fortes contraintes, c’est l’existence, préalablement à ma mission, de l’énoncé du concept, très clairement rédigé et signé au plus haut niveau hiérarchique. Il tenait sur une demi-page (270 mots précisément) suivie de quatre pages de description des différents modules fonctionnels et de contraintes particulières. Je tiens ce texte d’une demi-page pour exemplaire. Cela va sans dire, il répond à ma check-list en 5C : Clair, Correct, Concis, Complet et Cohérent. Mais bien plus que cela : il m’a permis de mener à bien, avec aisance et efficacité, l’expression des besoins pour une application d’envergure nationale et d’élaborer un cahier des charges de 172 pages, pour un client particulièrement exigeant.

Ce qui rend le document de concept si puissant, et à mon avis indispensable, c’est qu’il permet, non seulement de cadrer le projet, mais de le recadrer en permanence tout au long de l’expression des besoins. Il fixe le cap. Chaque fois qu’un représentant des utilisateurs me demandait d’ajouter, lors de l’expression des besoins, une fonctionnalité non prévue initialement, je me référais au document de concept. Et je posais trois questions : Cette exigence …

• est-elle conforme à l’objectif spécifié ?
• s’inscrit-elle dans le périmètre défini ?
• sera-t-elle utile à au moins une des parties prenantes ?

Si l’exigence n’était pas alignée sur le concept, on la mettait dans la catégorie « à faire s’il reste du temps et du budget ». Si elle n’était pas cohérente avec le concept, elle était éliminée.

Quel que soit le nom qu’on donne à cette phase, la définition du concept est indispensable, même dans le cadre d’une démarche agile. Surtout dans le cadre d’une démarche agile ! Le le périmètre du système peut varier, cela ne signifie pas qu’il est inexistant !

Dans un prochain article, je parlerai des différentes techniques que j’utilise pour spécifier avec mes clients le concept d’un produit logiciel. Mais disons-le d’emblée : lors de cette phase il n’y a pas une méthode unique qui marche à tous les coups. Nous sommes dans une phase exploratoire.

© Yves Constantinidis Consultant, MMXXII