Cycle en V hybride : Analyse de Besoin et Faisabilité (partie 1)

Avant de parler de mon cycle en V, vous devez savoir ce qu'est l'Ingénierie Systèmes et plus spécifiquement les grands processus associés. La lecture de mes articles précédents est fortement recommandée.

‍

Ce que vous voyez ci-dessus est mon implémentation personnelle du Cycle en V. Il y a 3 chemins :

• Le chemin bleu : représente le Produit que vous souhaitez concevoir
• Le chemin blanc : le moyen de Production associé
• Le rouge : le moyen de Support associé

Le V tel qu'il est usuellement représenté dans la littérature se situe a peu près entre les étapes 4 et 12. J'ai pensé pertinent d'ajouter plusieurs autres éléments ou de les faire apparaître plus explicitement.

Dans cet article, nous allons traiter des étapes 1 à 3 sur le chemin bleu. D'autres articles suivront pour les étapes suivantes et celles en parallèles repérées par des lettres.

Partie 1 : Activités préalables au V

Vous décidez de vous lancer dans la conception d'un produit, excellent ! Cela peut être soit pour répondre à la sollicitation d'un client, soit pour un besoin interne, soit de l'auto-financé pour répondre à un marché que vous estimez intéressant.

Analyse de Besoin

La première étape (1) est celle que j'appelle la Définition de Besoin Préliminaire. Il s'agit d'exprimer (ou de faire exprimer) le Besoin de son client vu de sa fenêtre :

• "Je souhaite avoir une trottinette électrique me permettant d'aller de 0 à 100km/h en X sec"
• "Si je pouvais avoir un pilotage automatique de ma trottinette ce serait le top"
• "Je veux une trottinette banale pour moins de 200€"
• etc.

Ce client peut être interne ou externe à votre entreprise. L'équipe marketing peut tout à fait être à l'origine du Besoin.

Etude de Faisabilité

Fort de ces demandes client, on peut passer à l'étape 2 qui est celle de la Faisabilité.

Il s'agit de voir si vous êtes capable de répondre à la demande. Si vous êtes certain de l'être car vous êtes un industriel spécialiste de la trottinette, il va s'agir plutôt d'affiner votre planning, de tester des fournisseurs, de lever quelques doutes techniques et business :

• Vous associez (en bricolant - il s'agit simplement de lever des risques) un moteur très performant sur un châssis de trottinette, et vous voyez si vous pouvez effectivement atteindre la performance demandée, sans que le tout ne se détériore.
• Vous fixez au scotch aluminium un système de géolocalisation sur votre trottinette, des caméras infra rouges etc., un algo de guidage qui exploite ces capteurs et vous définit la trajectoire à suivre, un organe de contrôle des moteurs et de la direction, et vous voyez si la trottinette fonce dans un mur ou non.
• Vous faite le tour des fournisseurs pertinents et voyez ce que donnerait le coût d'une trottinette low cost (en prenant soin de compter également les travaux de développement, certification, et autres moyens utilisés... pour définir le prix de revient du bolide)
• etc.

Il s'agit véritablement d'un bricolage à ce stade : on prend des briques maîtrisées par ailleurs, on voit comment le tout fonctionne avec une intégration rapide.

Autre utilité de cette phase de Faisabilité : vous pouvez en faire une véritable Usability Study (Formative Study) qui vous permettra d'orienter vos Spécifications et Conception pour coller au plus proche de ce que vous y aurez appris.

Spécification Technique de Besoin

Etape 3 : la Spécification Technique de Besoin (STB). Vous savez ce que le client attend. Vous avez fait quelques tests pour levers vos doutes sur certains points. Le fait de maquetter une solution à la va-vite vous a également fait apparaître un certain nombre d'éléments que le client ne vous a pas donné (il n'en a pas conscience) ou que vous n'avez pas du tout perçu :

• Des règlementations techniques à suivre
• Des systèmes avec lesquels vous devez être en interface (si le client veut un pilotage automatique, il faut quelque part un moyen pour lui de dire à la trottinette qu'il veut passer dans ce mode-là - un bouton ? une app sur smartphone?)
• Des environnements de sollicitations diverses qui vous pénalisent (températures d'utilisation de la trottinette qui vont jouer sur la sensibilité de la cellule d'acquisition infrarouge etc.)
• Un besoin de calibration de vos capteurs avant d'utiliser le pilote automatique
• Une difficulté d'intégration entre votre moteur dopé et le reste du châssis
• Le fait que l'utilisation envisagée par le client de la trottinette ne lui convient finalement plus maintenant qu'il a vu ce que cela impliquait
• Qu'il est nécessaire de respecter la directive RGPD car pour votre pilote automatique vous vouliez implémenter de la détection de visages humains pour prioriser le fait de rentrer dans un mur plutôt qu'un piéton en cas d'urgence. Et que pour une raison X ou Y vous vouliez utiliser un code déjà prêt chez vous qui en plus de faire de la détection fait aussi de la reconnaissance et exploite une base de données de visages quelque part dans le sombre internet. Et que couplé avec une géolocalisation vous avez in fine un moyen de savoir qui était où et à quel moment (pour ceux qui croisent le chemin de votre trottinette du futur)... OK, je suis allé la chercher loin celle-là, mais vous comprenez l'idée !

Ces éléments apparus lors du prototypage + le Besoin préliminaire initial vous permettent de rédiger un Besoin bien plus complet que la simple expression en étape 1.

Le client doit valider cette Spécification Technique de Besoin pour que tout le monde soit assuré au maximum de partir dans la bonne direction pour le produit dont vous allez accoucher à la fin. Concrètement, il s'agit d'une liste d'exigences sur le Produit, du type : "Avec le Système, la partie prenante A doit pouvoir effectuer l'action B en conditions C et avec le niveau de performances D".

Enfin, cette STB doit s'accompagner de son plan de Validation. Pour chaque exigence, il faut définir le test qui permettra d'affirmer que oui, l'exigence est bien remplie comme souhaitée. Le client doit également signer cette partie là, que je recommande de mettre dans un document à part :

• "Passer en mode pilote automatique sur la trottinette et lui demander de faire le parcours du point A au point B. Ne pas toucher le guidon. Le test est réussi si l'utilisateur est bien parti de A et est arrivé à B, en moins de X sec...".

Pourquoi préparer cette Validation aussi tôt ? Cela permet d'une part d'être d'accord avec le client sur la recette qu'il fera à la fin (qui conditionne peut-être le paiement du projet...), et d'autre part cela aiguille les développements de manière pertinente puisqu'on en sait encore plus sur l'objectif à atteindre.

Quelques commentaires pour terminer

Vous remarquerez qu'à ce stade, on est plutôt restés dans le haut du niveau Système (on n'est pas allé en profondeur dans le détail de ce dernier). A part pour l'étape 2, qu'on a bien dû creuser un peu pour assembler les quelques éléments utiles à nos tests de Faisabilité. Mais l'objectif est bien de limiter cette descente dans le détail d'où le petit V que fait l'étape 2 dans mon schéma.

On peut dire qu'on est restés à un niveau "Client" c'est à dire avec un système en boîte noire. On n'a pas encore commencé la descente du V ! On est simplement arrivés à sa pointe supérieur gauche (un Besoin bien clair), et on a préparé sa pointe supérieure droite (la Validation du Système).

On a déjà fait un peu (beaucoup) de Design Thinking, puisqu'on a fait une maquette et on l'a mise (en conditions contrôlées car prototypage) entre les mains du client qui a pu nous faire ses retours. Et entre nos mains évidemment, pour identifier les éléments auxquels on n'avait pas pensé a priori.

Aurélien NARDINI

‍

‍