Le développement de produit 9.0

Thomas
Thomas
Feb 2 · 11 min read

Cet article n’a pas d’autre but, comme 95% des autres articles visibles de nos jours sur les réseaux sociaux : enfoncer des portes ouvertes (super…), scrapper de la data sur google (oh Woah), en tirer une satisfaction intellectuelle (frimeur), synthétiser ma pensée sur un sujet (il serait temps), me faire marrer (le plus important), faire marrer mes potes (sacré Hubert), vendre quelque chose discrètement et subtilement (coquin) et très éventuellement vous apprendre quelques petits trucs au passage (on sait jamais).

Avant de vous expliquer notre méthode chez Possible Future, passons en revue ce qui existe pour développer un produit industriel. Et y a pas 2000 façons de faire les choses.

Les anciens vont vous parler du traditionnel ….

Cycle en V

Image for post
Image for post
Oh yeah ! Le cycle en V, ça fait rêver ! Sympas ces WordArt des années 95 en tout cas

Ce que j’en ai retenu de 4 ans de développement de voitures en une phrase très longue :

On part du besoin client, on en déduit une cible de produit, on développe, on prototype, on test, on s’accroche pour maintenir la cible du triptyque “qualité/coût/produit”, on demande des modifications aux fournisseurs, ils te disent “Ok, voilà la facture”, tu fais semblant de négocier, ils font semblant d’accepter, on résout les crises les unes après les autres, jalon après jalon, et à la fin on arrive à un produit vendable, avec de la crasse enfouie sous le paillasson, des relations plus ou moins tendues au sein des équipes, entre les donneurs d’ordres et les fournisseurs, et une série d’améliorations/réductions de coûts à effectuer pendant toute la durée de vie du produit.

Côté donneur d’ordre, on passe son temps… À donner des ordres à ses fournisseurs. Attention à la frustration qui peut naitre quand on passe son temps à envoyer des mails et mettre à jour des indicateurs sans savoir ce qu’il se passe dans le monde réel.

Côté fournisseur, on passe son temps… À recevoir des ordres de ses donneurs d’ordres. Attention à la frustration qui peut naître quand les besoins évoluent tout le temps, qu’il faut donner des informations idiotes, ou faire des tests absurdes qui ne correspondent pas au monde réel.

Image for post
Image for post
Des relations maître-esclaves usantes pour tout le monde.

C’est long, ça coute cher et ça nécessite du temps pour maîtriser les standards, les technologies et connaître les fournisseurs pertinents. C’est assez peu pertinent pour développer rapidement des produits éloignés du cœur de métier d’une entreprise.

Et oui ! Car une fois le contrat signé, avec un joli cahier des charges très complet, on fige les spécifications, on lance des investissements de centaines de milliers d’euros pour “lancer les moules”, rien à voir avec un quelconque concours breton 🧐. Derrière la marge de manœuvre du donneur d’ordres fond comme neige au soleil.

On se retrouve alors avec la très fameuse “Inversion de marge de manœuvre”, célèbre théorie que connaît par cœur tout industriel digne de porter ce nom

Image for post
Image for post
L’évolution de la marge de manoeuvre au cours du temps dans un projet. Par Pierre-Louis C.

Et donc fatalement, dans un monde où le dieu marketing règne en maître sur ta 2ème story instagram, avec des tendances, envies et besoins qui évoluent à toute vitesse, ben ça pose problème !

Et du côté du numérique ?

Le genre de dessins qui ressort si tu tapes Spotify et Agile sur le net.
Le genre de dessins qui ressort si tu tapes Spotify et Agile sur le net.

Vous me voyez venir, vous la connaissez aussi, tout le monde ne jure plus que par elle, parce que Spotify, une entreprise de 4.000 personnes, a réalisé un CA de plus de 6Md d’euros en 2019 c’est grâce à elle, c’est la méthode AGILE !

(Soit 1.5M€ de CA par employé. En comparaison, Renault est à 0.3M€ de CA par employé, 5 fois moins)

(Pas sûr que ce ratio veuille dire quoi que ce soit, mais ça fait hyper classe)

Tu as forcément vu ce genre de diagramme, en cours ou en formation, donc je vais pas m’appesantir sur les concepts de PO ou de “Le client au centre de nos Post-its (superbe antonomase) lors de nos sprints de 2 semaines pour sortir une nouvelle feature”, l’idée c’est d’itérer beaucoup plus régulièrement le besoin client, et donc les cahiers des charges associés à des fonctionnalités dont on veut pouvoir mesurer avec des chiffres et des stats la pertinence en permanence !

Dès 2008, Renault commence également à employer du développement Scrum (Pourquoi cet anglicisme ? Suis un peu ! Parce que ça fait hyper classe) à la DSI et, victime de la mode, ne parle plus que d’Agilité dans toutes les directions en 2019, avant que je ne quitte l’entreprise.

Alors oui, c’est très sympa de faire du prototypage rapide, de la stéréolithographie, des simulations numériques à base d’éléments finis et autres écoulements de fluide turbulents.

On dé-risque un peu les sujets, on se fait marrer à bricoler des imprimantes 3D dans le fablab du département Open-Innovation qui prennent la poussière…

Mais de là à dire qu’on peut appliquer l’Agile sur du développement de produit hardware en claquant des doigts… On en est clairement pas là.

Car non, on ne sait toujours pas faire une voiture prototype complète sur un sprint de 2 semaines pour pouvoir tester une fonctionnalité, et itérer sur la conception de tous les composants assurant la dite fonctionnalité.

Et donc Jammy, comment on fait pour développer un produit industriel en 2021 efficacement ?

Je ne vais pas vous leurrer, il reste encore un tas de questions auxquelles je n’ai que des embryons de réponse.

Ce qui est sympa en revanche, c’est qu’en ce moment, chez Possible Future, (l’entreprise qui me verse un salaire et compte sur moi pour réfléchir à ces sujets, et mener des projets du mieux possible !), ben j’ai justement pu prendre un peu de temps pour :

  1. Réfléchir aux problèmes dans ces méthodes de gestion de projet.
Image for post
Image for post
“Il n’y a pas de problèmes techniques, il n’y a que des mauvais ingénieurs.” Gabriel T

Exemples de questions que je me pose encore autour du développement de produit : (Et, spoiler alerte, je n’ai pas les réponses)

  1. L’Agile peut-il et doit-il vraiment être utilisé dans des développements de produits industriels ? (En plus des techniques de prototypage rapides)
Image for post
Image for post
Ah les task-forces de fin de projet où on gratte toute la crasse accumulée pendant un projet !!

Voici quelques exemples de réponses qu’on applique lors de nos développements de produits, toujours chez Possible Future, depuis 2016, en essayant de garder ce qu’il y’a eu de bon dans les précédents Et là on pourrait aborder le sujet de la capitalisation des connaissances en entreprise… Sujet ultra intéressant, complexe, et hors-sujet dans cet article.

Pour imager encore plus le propos, je vais me baser aussi sur un exemple purement fictif : la ceinture de sécurité dans une voiture.

Image for post
Image for post
Quel modèle de voiture à votre avis ?

1. Travailler main dans la main.

Les deux chefs de projets sont deux personnes qui, de part et d’autre, se comprennent, sont motivées, et saisissent les enjeux derrière le poncif de l’objectif commun : ”Sortir un produit avec le niveau de qualité, de marge et dans les délais impartis”, en se faisant confiance.

Image for post
Image for post
Tendre vers une gestion de projet en partenariat, à opposer aux relations maître-esclave…

Si un des deux chefs de projet n’est pas à la hauteur de l’enjeu, les équipes autour de lui ne seront pas suffisamment sollicitées, et les problèmes vont poindre le bout de leur nez, à la suite de sujets traités avec trop de légèreté “Boarf, ça sert à quoi de mettre une ceinture dans une bagnole ? Ça coûte une blinde en plus. On verra à la fin du projet s’il reste du budget…”

Si les cultures et les façons de faire des chefs de projet sont trop éloignées, ça peut créer des problèmes également. Je pense à ces projets où d’un côté une culture américaine, ultra orientée “Try and Retry” s’est vue opposée à une culture française “Bon du premier coup”.

Ben forcément, quand on part sur des hypothèses assez faibles américaines avec une confiance beaucoup trop forte, car l’hypothèse sera bonne du premier coup, il n’y a pas à en douter… Ben ça finit pas bien. (Vous connaissez le monde merveilleux des microbes dans les circuits d’eau ? Typiquement…)

Image for post
Image for post
Notre dernier projet en date avec Biotherm : Ça parle de nettoyage de flacon de crèmes, de séchage, de remplissage et de personnalisation.

2. Anticiper et formaliser en début de projet.

Mais de quoi je parle ? De la nécessité, lorsque tout est signé, que tout le monde est sur-motivé, que le donneur d’ordres a fait une super négociation sur son contrat, que le fournisseur est shooté à la dopamine pour avoir remporté le contrat, prendre un moment ensemble autour d’une table.

Un vrai moment, et pas seulement une minuscule réunion de lancement (Aussi appelé “Kick-Off” par tout le monde, sûrement pour faire plus américain, parce que c’est hyper classe…)

Image for post
Image for post
C’est tellement sympa ces anglicismes !

On se pose autour d’une table, et on anticipe ce qu’il va se passer durant le projet, et notamment le partage des responsabilités. On reprend toutes les fonctions du futur produit, les interfaces avec d’autres produits, les fonctionnalités “systèmes” qui l’entourent. “Bon la ceinture, elle doit s’attacher sur le siège. C’est le fournisseur de ceintures, de sièges, ou c’est Renault qui doit s’assurer que l’interface entre les deux casse pas après 5.000km ?”

Rien de bien fou, on appelle ça un RACI. Mais c’est quelque chose que personne ne veut faire au début, car long, fastidieux, et ennuyeux à (vos) souhaits.

Tout ça, c’est surtout pour éviter de débattre pendant des jours et des jours en fin de projet sur “c’est ta faute pas la mienne…” et autres joyeusetés de soulevé de paillasson, quand toute la poussière ressort !!

Image for post
Image for post
Un autre projet avec Evian de fontaine connectée, on part d’une feuille blanche jusqu’à l’industrialisation complète du produit !

3. J’ai utilisé deux fois le mot interface.

Et c’est normal, car c’est bien là que se nichent les difficultés dans le développement d’un produit.

D’après le Petit Robert :

n.f. Limite commune à deux systèmes, deux ensembles, deux appareils.

Une zone de flou donc, où chacun peut se défausser sur autrui, où ce n’est jamais sa faute en cas de problème.

Bon cet exemple est sûrement très naïf, car ultra connu des constructeurs automobiles, et donc plus que maîtrisé, mais qui est responsable de la bonne fermeture de l’accroche de verrouillage dans le cliquet de réception ?

Image for post
Image for post
Rah les bagnoles… On adore ça ou pas ?

Pensez à vos interfaces dès le début, et supprimez un maximum de flou autour de ces zones !

4. Travailler au forfait plutôt qu’à l’objectif.

C’est-à-dire ? Ben au lieu de s’engager à sortir la machine de vos rêves en 4 mois pile poil, on va plutôt s’engager à travailler avec une équipe, mois après mois, pour sortir le projet le plus tôt possible.

Côté donneur d’ordres, on va pas se le cacher, ça fait flipper. “Mais attends, ils vont rien glander, et dans 3 ans on y est encore, avec un projet à 5 millions d’euros ?”.

Et c’est là qu’intervient la notion de confiance, et de partenariat, avec des équipes investies, un travail en collaboration ultra étroite, des revues de projets mensuelles où on travaille ensemble sur les objectifs qualité-coût-délais du projet, et où donneur d’ordres et fournisseurs s’impliquent dans la compréhension des sujets en cours et des problèmes en cours de résolution.

Ça nécessite de prendre le temps d’expliquer côté fournisseur, et de s’intéresser côté donneur d’ordres.

Image for post
Image for post
Une relation d’apprentissage, c’est plus agréable pour tout le monde non ?

Il est plus que temps de conclure.

Je n’ai pas parlé ici de notre équilibre “ingénieur/designer/business”, qui nous permet de démarrer nos développements de produits très en amont (Une problématique souvent très large, une opportunité identifiée, une tendance vague…) pour finir en aval avec un produit prêt à être fabriqué en millions d’exemplaires ! (Ou en milliers, ou en centaines, oui ça dépend de la complexité de l’objet…), de toutes les façons dont on travaille… Je risque de me faire taper sur les doigts pour ça.

Alors, si je devais résumer, en quelques phrases, à quoi ça ressemble le développement d’un produit chez Possible Future du point de vue “ingénieur”, voilà ce que je pourrais dire.

“On part du consommateur évidemment, on comprend l’usage, l’identité de marque, le business modèle, la qualité……. Bref tout ce qui est super important pour ne pas passer à coté du sujet (Ça prend du temps si c’est bien fait hein)”

“Groooooos brainstorming pour tout poser par écrit sur les cahiers des charges, les responsabilités, les validations à faire, en ramenant le plus d’experts autour de la table, chez nous, ou chez le donneur d’ordres, etc etc….”

“On fait des maquettes dans tous les sens pour tester toutes les fonctions du produit une par une”

Image for post
Image for post
Petite maquettage au calme avec Denis Lin

“On dessine un premier prototype pas trop dégueu sur nos petits ordinateurs à pomme”

“On le malmène, on le triture dans tous les sens ce premier proto, il finit par casser. Et le pire, c’est qu’on aime ça. On regarde tout ce qu’on devra faire pour qu’il soit certifié, pas risqué et qu’il respecte tout ce que notre client va nous mettre dans les pattes comme standard à respecter, c’est bien normal. Et au passage, un petit test avec des consos… Ça mange pas de pain, et ça nous rassure !! Bah oui, le produit, il a beau être cool et fonctionnel, faut qu’il réponde à un usage…”

“On ressort 2–3 protos, avec des matériaux un peu plus aboutis, un procédé d’assemblage qui ressemble à celui des produits finaux, et on redémarre la maltraitance. Au passage on remet le produit dans les mains de consommateurs, et on voit s’ils trouvent ça toujours aussi cool.”.

Image for post
Image for post
Notre petit atelier, pour les protos c’est le top. Pour les pré-séries on fait assembler ça chez des copains !

“Et puis en avant Guingamp, on lance la pré-série. Des produits qui sont quasi identiques aux produits finaux (des genres de bêtas), qu’on va pouvoir vendre à des consommateurs pour faire un premier test à l’échelle”

Bon…..

Maintenant que vous savez tout…

Image for post
Image for post
La Jamais contente en 1899

Ça vous donnerait pas envie de ressembler au bon Camille, qui a sorti la première voiture dépassant les 100 km/h au 19ème siècle ?

Innover en sortant une nouvelle application ou un énième site web c’est sympa hein.

Mais sortir un nouveau produit physique, et faire rêver tout le monde, est-ce que ce serait pas mieux ?

Possible Future

Sustainable innovation. From ideas to launch

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store