Cycle en V hybride : Spécification et Conception (partie 2)

Avant d'aller plus loin, je vous recommande la lecture de la partie 1.

‍

Dans cet article sur mon processus personnel d'Ingénierie Systèmes, nous allons traiter des étapes 4 à 6 sur le chemin bleu. D'autres articles suivront pour les étapes suivantes et celles en parallèles repérées par des lettres.

Il est à noter qu'on considère pour ce Cycle en V un système à "3 étages", comme présenté dans ma vision cubique d'un Système :

• Le niveau Système : on considère le Système en boîte noire. On sait ce qu'il doit faire, pas comment il le fait.
• Le niveau sous-système : en boîte blanche. On commence à s'intéresser au "comment" seront réalisées les fonctions de notre Système
• Le niveau élément : le plus bas niveau, le plus détaillé. La composition du Système (logicielle, matérielle, opérationnelle) n'a plus aucun secret.

Selon la complexité du Système qu'on cherche à concevoir, ou même l'organisation de l'Entreprise dans laquelle on travaille, on peut avoir à créer des niveaux supplémentaires.

Partie 2 : Début de descente du V

Nous avons un Besoin clair et complet de la volonté du Client pour son Produit (la Spécification Technique de Besoin). Nous avons également le Plan de Validation qui va en face.

Nous attaquons donc l'étape 4. Elle a plusieurs noms dans la littérature et selon les Entreprises : Conception Générale, Spécification, Spécification Générale, Conception Préliminaire etc. Je préfère le terme Spécification Générale, c'est ce terme que j'utiliserai par la suite.

Spécification Générale

Le but du jeu est ici de transformer les exigences du Besoin en exigences Systèmes. On parle de déclinaison des exigences. On doit prendre les exigences du Besoin 1 par 1 et se demander "qu'est-ce que cela signifie pour mon Système?".

Reprenons notre trottinette :

• Besoin : "Avec la trottinette, l'utilisateur doit pouvoir aller de 0 à 100km/h en X secondes sur une route plate"
• Déclinaison vers les exigences Système : "La trottinette doit pouvoir supporter un utilisateur de masse X kg à l'arrêt", "[...] de masse X kg à 100km/h", "La trottinette doit avoir une capacité d'accélération de X m/s²", "la trottinette doit pouvoir s'interfacer avec une route", "La trottinette doit résister aux chocs et vibrations rencontrés sur une route de type X", etc.

Lors d'une déclinaison, très souvent l'exigence mère donne plusieurs exigences filles. C'est normal, on détaille l'exigence mère en allant plus loin, davantage vers la technique. Notez également que dans une exigence Système le Système devient le sujet de la phrase. Ce qui n'était pas le cas dans l'expression de Besoin, où une partie prenante était le sujet.

Remarque : Il est très tentant de dire ici d'emblée que la trottinette doit avoir des roues (pour l'interface à la route). Cela dit le Besoin ne le précise pas... Le client pourrait sûrement se satisfaire d'un autre moyen ? Une bonne pratique est de laisser ouvert ce genre de choix le plus loin possible dans la conception, pour ne pas se fermer de portes et saisir toute bonne idée innovante qui pourrait apparaître.

En bref, on transforme toutes les exigences et on les complète pour rentrer dans le monde technique et scientifique de notre projet.

On passe d'une liste de X exigences de Besoin à une liste de 3X exigences Systèmes (rapport 3 estimé au pifomètre, mais cela donne une bonne idée). Cette nouvelle Spécification doit s'accompagner de ce qui permettra de vérifier que tout est OK sur l'autre versant du cycle en V : son Plan d'Intégration et Vérification. Il va définir comment intégrer le Système complet à son environnement, tester que l'assemblage des sous-systèmes 2 à 2 est OK in fine, et que le tout est bien fonctionnel au niveau de performance et dans les conditions attendues.

Cette nouvelle spécification doit aussi s'accompagner d'une définition d'Architecture Générale : une représentation du Système et de son comportement/utilisation dans son environnement. Cela permet de s'assurer qu'on peut bien s'imaginer un système qui répond à toutes les exigences Système qui portent sur lui (et qu'il n'y a pas d'incohérences dans leur définition, ou de choses impossibles à faire fonctionner). Si à ce stade on n'est pas capable de s'imaginer une trottinette qui fonctionne comme attendu en réponse aux demandes du client, ce n'est pas la peine d'aller plus loin et il y a des décisions à prendre vis-à-vis du Besoin ou de la Spécification Générale.

Premier dérisquage

A ce moment-là, le Système dans son ensemble est caractérisé de manière assez fine (mais toujours en mode boîte noire). Il est judicieux de passer à l'étape 5. Cette étape est un dérisquage. On veut s'assurer que ce Système qu'on est capable de s'imaginer est bien viable. Cela peut se faire via divers moyens, dont les 2 principaux sont :

• Maquettage (quitte à reprendre la maquette faite en phase de Faisabilité et l'arranger selon l'architecture qu'on imagine) et tests en réel
• Modélisation (CAO, jeux d'équations, SysML...) et simulations

Le client peut même être convié, cela permettra de s'assurer qu'on a bien traduit son Besoin et qu'on peut poursuivre sereinement la descente du V.

Exemples :

• Vous arrangez votre trottinette bricolée en phase de Faisabilité pour la rendre cohérente des exigences et de l'architecture que vous lui envisagez à ce stade. Cela répond toujours bien au Besoin ? C'est pratique à utiliser ?
• Il ne vous est pas possible de maquetter physiquement la trotinette spécifiée à ce stade. Si la problématique principale porte sur la résistance mécanique de cette trottinette lorqu'une personne de 100kg roule à 100km/h sur une route cabossée, alors vous pouvez vous contenter de faire un modèle éléments finis et voir si votre architecture préliminaire à des chances de répondre à ce Besoin (ou de casser au bout de 3 min).

Conception Système

Arrive l'étape 6. Elle aussi a plusieurs noms : Conception détaillée, Conception, Spécification Détaillée, ... Je choisis Conception.

Il va s'agir ici de décliner à nouveau nos exigences, cette fois-ci du Système vers les Sous-Systèmes. En se posant pour chaque exigence Système la question "Comment?" :

• Exigence Système : "La trottinette doit pouvoir supporter un utilisateur de masse X kg à l'arrêt"
• Exigence Sous-Système : "La trottinette doit disposer d'un châssis capable de supporter Xkg", "La trottinette doit avoir des amortisseurs de course max Xmm", "Les amortisseurs doivent s'interfacer au châssis de telle façon" etc.

Ceci est à faire pour toutes les exigences : celles plutôt orientées matériel, celles plutôt logiciel etc.

NOTA : Pour passer d'une exigence Sous-Système à Système (chemin inverse) la question à se poser est "Pourquoi?"

Ce n'est pas juste un exercice de style. Chaque déclinaison induit des choix sur le Système et c'est comme cela qu'il se construit pas à pas. Il est nécessaire de conserver une justification de chaque Exigence car c'est souvent là qu'est le savoir-faire de l'Ingénieur qui a réalisé la déclinaison (et par extension de l'Entreprise). Ici on aurait pu choisir de doter l'utilisateur de bottes spécifiques, maintenues en lévitation magnétique par un élément intégré au mât de la trottinette... Ou bien d'opter pour un dispositif où l'utilisateur est suspendu à un harnais plutôt que les pieds posés sur le châssis... C'est pour le moment de la science-fiction mais cela reste une déclinaison possible, et un choix Système associé.

Idem que précédemment, en face de ce nouveau lot d'exigences, qui grossit à vu d’œil, une Architecture Détaillée doit être mise sur pied. Et une Allocation doit être clarifiée : telle exigence sera portée par tel sous-système etc. On vient "projeter" les exigences sur les éléments (matériel, logiciel, ...) de l'architecture qui vont les réaliser.

Le Plan d'Intégration et de Vérification Détaillée correspondant doit également être écrit pour mettre des tests en regard de chaque exigence. Grâce à lui on viendra, lors de la remontée du V, tester chaque sous-système 1 par 1 pour s'assurer que tout est OK, et tester leur intégration entre eux. Les tests peuvent être simples ("Vérifier visuellement que la trottinette dispose bien d'un châssis") ou plus complexes ("Vérifier que la course max des vérins est bien respectée en les sollicitant 1500 fois avec appui de X Newtons en tel point").

‍

Pourquoi faire autant de déclinaisons et mettre des tests en face de chaque exigence ? Ne suffit-il pas de savoir ce que doit faire le Système au global, ainsi que les quelques tests de recette Client lors de la livraison? Ensuite opère la magie de l'expertise de nos équipes métier? 

• Pour votre client, oui, ce niveau de détail est suffisant.
• Pour vous, par contre, qui construisez le Système depuis 0 ou presque, il est important de savoir comment vous allez vous y prendre. Il est nécessaire de maîtriser chaque recoin de votre Produit puis de tester que chaque sous-système répond bien selon l'attendu avant de le mettre à côté de son voisin et de voir si l'ensemble des 2 répond également bien. Si cela n'est pas fait, le risque est de développer un Système, qu'il ne fonctionne pas au global, mais qu'on ne sache même pas d'où ça vient avec certitude. Et perdre ainsi beaucoup de temps et d'argent sur une mise au point inefficace.
• Le risque est également grand de négliger une Exigence car on n'a pas fait l'exercice de savoir ce que cela impliquait pour notre système, et de comment on allait la réaliser.
• Vous allez arriver rapidement à plusieurs 100aines d'exigences selon la complexité du Système et la Fiabilité qu'on lui veut. Il est impossible pour un expert électronique, logiciel, mécanique, moteur, ou autre, de se rappeler des 178 exigences qu'il doit satisfaire. Le seul moyen est de les écrire. Et pour être sûr qu'elles sont satisfaites, il faut les tester.

Quelques commentaires pour terminer

L'étape 5 s'inscrit elle aussi dans une démarche de Design Thinking : le but est également de se mettre à la place de l'utilisateur pour voir ce qu'il penserait du Système, et/ou de mettre le Système dans son environnement et voir comment il performe.

Il ne faut pas hésiter à modifier les spécifications ou l'architecture qu'on s'était fixées a priori si ce n'est pas satisfaisant. Toutes ces étapes sont séquencées, mais elles sont bien itératives (et récursives). En ce sens, on vient d'ajouter de l'Agile dans la descente du Cycle en V !

Aurélien NARDINI