IoT – Le passage d’un proto à un produit industriel.

Beaucoup de personne sont persuadée que le fait d’avoir un prototype qui commence à donner des résultats équivaut à avoir un produit fini à 80%…

Je vous le dis tout de suite : Il n’en est rien !

Les «Non Informaticiens/Vendeurs/Manager/Casse couille » [ Biffer la(les) mention(s) inutile(s) ] ont tendances à croire que le boulot est terminé par ce qu’ils ont entre leurs mains un prototype qui réponds aux besoins principaux et ce, de façon toute relative. (Oui, il y a encore quelques bugs,… Mais 90% du boulot est fait…)

Pour la plupart, ils ne comprennent pas (ou tendent à l’oublier) la démarche initiale d’un POC : Celui-ci vise à réduire les risques, à valider certains choix technologiques ou fonctionnelles plutôt que d’autre… Bon nombre de vendeur prenne cela pour argent comptant et en profite pour vendre votre « bidouillage cérébrale » comme étant LA nouvelle 7èm merveille du monde… (Oui, il y a encore quelques bugs,… Mais 95% du boulot est déjà fait…)

Quand on en vient à annoncer qu’il faut passer du temps pour transformer ce prototype en véritable produit, il ne réalise pas l’effort qu’il reste à fournir pour arriver à ce but. Cette phase est nécessaire pour réduire les risques liés à la phase d’industrialisation. En effet, produire quelques exemplaires d’un système embarqué, ou en produire des centaines de milliers d’exemplaires, ce n’est pas tout à fait la même chose : une série de nouveaux facteurs liées à la production de masse doivent entrer en ligne de compte. ( Oui,il a encore quelques bugs,… Mais 95% (1.500.000 pièces ) ont déjà été livré à travers le monde 8-/ )

Bien définir les spécifications et réaliser un mode d’emploi permet dans un premier temps de mettre en évidence certaines failles dans le produit : on peut, par exemple, le comparer à ce qui existe déjà sur le marché et prendre des dispositions si sur le papier il est déjà obsolète par rapport à la concurrence. Il ne faut pas oublier qu’a ce stade, ce produit doit encore être développé et produit, ce qui peut prendre plusieurs mois.  On peut aussi confronter “la réalité techniques” à la demande initiale voulue par le client. Bon nombre de projet ont dû être arrêté avant la fin du développement pour cause de problème lié à des éléments techniques qui n’ont pas été pris en compte dès le départ.

L’exemple qui me vient en tête étant la création d’un système audio embarqué qui à nécessité le travaille d’une équipe d’une dizaine d’ingénieur durant 8 mois, qui a dû être arrêté pour un problème d’autonomie. Sur le papier, le système devrait permettre d’enregistrer de la voix durant 8 heures. Au final, le système réalisé tenait à peine 1 heure… (Oui, il a encore quelques bugs,… )

La phase d’industrialisation nécessite de prendre pas mal de précaution, et de prévoir tous les cas d’utilisation du produit final. Les outils de test intégré ou pas au firmware ne doivent pas être sous estimé, ainsi que les outils de configurations, les procédures de test,… En effet, programmer et configurer 10 unités ou protos, ne demande pas la même infrastructure que de gérer un flux de plusieurs centaines d’unité par jour. Des outils spécialisés doivent être développés afin d’automatiser cette phase. La gestion des retours, le support sont autant de point qui doivent être étudié avec soin. Et nécessite le cas échéant des ressources non négligeables (Rédaction de doc, Support téléphonique, Formation de personnelle (ouvrier/ingénieurs), Gestion de forum, Mise à jours correctif de firmware,… )

Quelques autres points intéressants à aborder lors d’un prochain articles : 

Quid de la sécurité au niveau de nos cher petite machine ? As-t-on sécuriser l’accès à l’upgrade du firmware, les données exportées sont elles critiques ? Nécessite-t-elle d’être cryptée ?

Quid de l’abonnement pour des système nécessitant la connexion à un réseau GSM ? La bande passante est assez large/ bien la calculer avant…