La gestion du contenu du projet

Le schéma ci-contre montre les différentes étapes du processus de gestion du contenu. Nous allons, dans cette leçon, décrire ces étapes et les documents associés à chacune d’elles. Commençons par présenter les 6 états successifs dans lesquels va successivement se trouver le produit, à savoir les états Latent, Fonctionnel, Spécifié, Défini, Réalisé, puis enfin Vivant.
– État latent. En tout début de projet le produit n’existe que sous la forme d’un besoin identifié. c’est l’état latent.
– État fonctionnel . A l’issue de l’analyse fonctionnelle qui sera l’objet de la prochaine leçon, le besoin est entièrement et précisément décrit sous la forme du cahier des charges fonctionnel (CDCF). A ce stade on sait précisément …….. Pour lire la suite souscrivez un abonnement PREMIUM ou si vous êtes déjà abonné connectez-vous 

Voici une illustration de ce qui vient d’être décrit de façon un peu théorique. Prenons la construction du pont qui doit franchir un ravin. Les commentaires des dessins parlent d’eux-même. Le concept « pont » passe bien par les six phases de vie : Le constat d’un besoin (état latent). La liste des fonctions à satisfaire (état fonctionnel). Le choix des solutions (état prescrit). La description du produit (état défini). Le pont lui-même (état réalisé). Et enfin le pont en exploitation (état opérationnel).
Voici ci-contre une vision à peine différente de la précédente. Elle apporte deux éclairages supplémentaires : D’abord l’importance des parties prenantes, avec au premier rang le maître d’ouvrage et les futurs utilisateurs du produit. Beaucoup de projets échouent à cause d’une prise en compte insuffisante des attentes de ces acteurs. Toute équipe de projet qui travaillerait sans rencontres fréquentes et ouvertes avec le maître d’ouvrage ou à défaut son représentant irait irrémédiablement à l’échec. Ce phénomène est tellement connu qu’il porte un nom : l’effet tunnel. De même le manque d’attention aux attentes les plus fines des utilisateurs, mêmes non exprimées ou mal exprimées, est toujours lourdement sanctionné. Deuxième aspect à retenir de ce schéma, l’intérêt qu’il y a à réaliser très tôt des maquettes puis des prototypes, seule façon de vérifier que l’on avance bien vers le bon résultat.

De l’approche fonctionnelle au cahier des charges fonctionnel (CDCF)
L’analyse fonctionnelle est une discipline très connue, parfaitement codifiée et documentée, et qui plus est enseignée dans toutes les filières techniques. Nous n’en présenterons ici qu’un bref résumé.
Pour comprendre les termes d’approche fonctionnelle ou d’analyse fonctionnelle il suffit de savoir que ces expressions font référence aux fonctions du produit. Une fonction du produit est un service que doit rendre ce produit. Par exemple un instrument d’écriture doit laisser sur le papier une trace visible. Peu importe à ce stade que cette trace soit due à la présence d’encre ou de graphite dans cet instrument. Le choix entre encre et graphite sera fait plus tard de façon à faire le meilleur compromis entre les différentes fonctions attendues et le coût engendré par ce choix.
L’approche fonctionnelle est une posture intellectuelle très saine, qui consiste, face à un problème, à raisonner d’abord en terme de fonctions pour ne rechercher les solutions que dans un deuxième temps.
L’analyse fonctionnelle (on devrait dire l’analyse fonctionnelle du besoin) est une démarche construite qui vise, pour un produit donné, à identifier et décrire la totalité des fonctions attendues de ce produit. L’analyse fonctionnelle du besoin s’achève par la rédaction du Cahier Des Charges Fonctionnel (CDCF).
Citons pour être complet le cas particulier des produits de série destinés à être commercialisés vers un large public. Dans ce cas l’analyse fonctionnelle du besoin doit être précédée d’une étude de marché, elle-même consignée dans un Cahier des charges marketing (CDCM)
Il existe un vocabulaire spécifique de l’analyse fonctionnelle du besoin. Le tableau ci-contre en montre un petit aperçu. Les définitions données dans le tableau se suffisent à elles-mêmes. Insistons seulement sur un aspect maintes fois constaté par l’auteur de ces lignes à l’occasion de missions de conception de produits innovants : Les petites et grandes catastrophes qui accompagnent le lancement de produits nouveaux sont très souvent dues à l’oubli d’un interacteur (voir la définition du tableau) lors de l’examen du cycle de vie du produit. Voici quelques exemple : Un insecte minuscule qui pénètre dans les détecteurs d’incendie et déclenche des alarmes intempestives rendant l’ensemble de l’installation inutilisable. Dans l’industrie automobile, les perturbations électromagnétiques provenant de la voie ferrée qui déclenchent les airbags des véhicules circulant sur la voie rapide voisine. Industrie automobile toujours, le liquide du lave-glace qui détruit le plastique des objets placés sur le toit du véhicule. Les exemples sont innombrables mais l’explication est toujours la même : les plus petites causes entrainent les plus grands effets.
L’élaboration du cahier des charges fonctionnel (CDCF) a été formalisée en 1991 par l’AFNOR dans la norme NF X 50-151. Le cahier des charges fonctionnel traduit la demande de l’utilisateur, il doit être rédigé dans un langage et avec des termes compréhensibles par celui-ci et par tous les autres acteurs du projet. Le cahier des charges fonctionnel décrit le besoin en terme de fonctions à assurer par le produit. Il est rédigé en termes d’obligation de résultat et ne doit donc pas évoquer les solutions à mettre en œuvre ni les dispositifs qui réaliseront les fonctions. La rédaction du CDCF demande une grande rigueur formelle.
Le CDCF est contextuel : qui dit nouveau projet dit nouveau CDCF, ce qui n’est pas contradictoire avec le fait d’utiliser le retour d’expérience des projets antérieurs pour gagner du temps et éviter des oublis. La rédaction du CDCF devrait toujours être un travail de groupe impliquant toutes les parties prenantes du projet, y compris et surtout les futurs utilisateurs.

– La spécification technique du besoin (STB) est le document contractuel établi par le demandeur et par lequel il exprime son besoin. Ce document regroupe les spécifications fonctionnelles et les exigences techniques. Une spécification fonctionnelle est la description détaillée de la façon dont une exigence fonctionnelle (correspondant à une fonction du CDCF) doit être prise en compte. Rappelons que les exigences fonctionnelles sont contextuelles c’est à dire qu’elles diffèrent d’un projet à l’autre. A l’opposé une entreprise en position de maîtrise d’ouvrage a toujours des exigences permanentes : par exemple sa charte graphique ou le modèle d’automate programmable qu’elle a choisi comme standard interne. Ces exigences permanentes méritent d’être consignées dans un cahier des charges technique (CDCT) qui lors de chaque projet sera pris « sur étagère » et intégré à la STB. Le CDCT est un document permanent, il est juste enrichi au fil du temps par le retour d’expérience des projets passés.
Voici ce que peut être le plan-type d’une …….. Pour lire la suite souscrivez un abonnement PREMIUM ou si vous êtes déjà abonné connectez-vous 

Le modèle de développement en cascade

Au cours de ces dernières décennies sont apparus des « modèles de développement » successifs, généralement prévus pour s’appliquer au domaine de l’informatique mais qui en pratique s’appliquent également aux projets technologiques, notamment à la conception des produits industriels. Voici une brève présentation des plus connus de ces modèles.

Le modèle en cascade découpe le projet en cinq séquences successives. A l’issue de chaque séquence un document est établi, qui constitue la feuille de route pour la séquence suivante. Ce modèle a l’avantage de la simplicité, mais il amène les différents acteurs à travailler « en silo », chacun appliquant les meilleures pratiques de son métier, sans que quiconque se préoccupe de savoir si le perfectionnisme qui en découle est bien utile ou si au contraire il ne va pas nuire au délai et au coût du projet et amener à produire une solution plus satisfaisante pour les ingénieurs qui l’ont créée que pour les utilisateurs qui auront à vivre avec.

Le modèle de développement en Vé

Le modèle en vé est le modèle de réalisation des systèmes hiérarchisés, c’est à dire décomposables en sous-systèmes, sous-sous-systèmes et ainsi de suite sur plusieurs niveaux. La partie descendante du cycle correspond aux phases de conception. La case inférieure correspond à la réalisation des éléments unitaires. La partie remontante correspond à l’intégration (assemblage). Les lignes horizontales figurent la vie des référentiels de recette, élaborés pendant la phase descendante pour être utilisés pendant la phase montante. Si ce modèle a initialement été imaginé pour le développement d’applications informatiques il s’applique tout aussi bien pour la conceptions de produits industriels comme un avion ou une machine de production.

Le modèle en spirale

Le modèle en spirale convient aux produits destinés à être distribués à un large public, notamment la totalité des logiciels du marché. Comme pour le modèle en cascade il s’applique parfaitement aux produits de série de l’industrie. Il exprime le fait que ces produits sont élaborés par itérations successives avec à chaque itération la production d’un résultat de plus en plus proche du produit final. Ce résultat pourra être dans l’informatique une version alpha puis une version bêta et enfin la version commercialisable. Pour un produit industriel on produira successivement des maquettes (virtuelle puis physique), un prototype, une pré-série et enfin le produit qui sera commercialisé.
– Les quatre quadrants de la spirale correspondent a des activités de nature différente :
1 identification
2 étude
3 réalisation
4 évaluation.

Nous avons vu que le document de référence du processus de gestion du contenu était la STB. Le produit sera réputé conforme lorsqu’il satisfera à toutes les exigences de ce document. Le protocole de recette (ou cahier de recette) définit pour chaque exigence les moyens qui seront mis en œuvre pour en valider la conformité, la procédure qui sera appliquée et le niveau de performance attendu. Le processus de validation se déroule habituellement en deux temps. Une première série de vérifications, appelée vérification de l’aptitude au bon fonctionnement (VABF), a lieu chez le fournisseur. Elle se conclut par la signature par les deux parties en présence (MOE et MOA) du procès-verbal de recette provisoire. La signature de ce document autorise la livraison et la mise en service pour essais du bien ou du logiciel. Vient alors la vérification en service régulier (VSR) qui a lieu dans les conditions normales d’utilisation. Si la recette définitive est signée, le bien ou le logiciel commence sa vie de produit.

Le transfert de propriété du produit

Notons que dans l’intérêt du projet les procès-verbaux (PV) de recette peuvent être signés même si la totalité des exigences ne sont pas satisfaites. Dans ce cas le représentant de la MOA note sur le PV les exigences non satisfaites, sous la forme de « réserves ». Lorsque le fournisseur aura apporté les modifications exigées, il y aura signature d’un procès-verbal de levée des réserves. C’est par ce procès-verbal de levée des réserves que la MOA indique officiellement son acceptation totale du produit dans son état actuel. Au plan juridique comme au plan opérationnel il y a transfert de propriété du produit. Si le contrat prévoit une période de garantie, celle-ci prend immédiatement effet.