4 Réflexes pour industrialiser ses projets IoT !
Bien que les premiers usages à grande échelle de communications M2M remontent aux années 90 et que le terme “Internet of Things” soit apparu en 1999, l’IoT est encore à la traîne par rapport aux prédictions. En 2011 Forbes prévoyait 50 milliards d’objets connectés dans le monde en 2020, or à l’heure actuelle la quantité est comprise entre 25 et 30 milliards selon des études Forbes et Statista.
Certaines des raisons de ce retard sont évoquées dans un article précédent traitant déjà de l’enjeu de l’industrialisation de l’IoT dès la phase d’idéation, afin de créer une solution qui réponde à un véritable besoin fonctionnel, et de déceler les éventuels points de blocage inflexibles au plus tôt. Il s’agit du cas d’usage, de la donnée et du cycle de vie de la solution dans son ensemble.
Après la phase d’idéation, c’est-à-dire quand on entame le design et le build, il y a également des réflexes essentiels à avoir afin d’aboutir à une solution IoT qui soit passable à l’échelle et maintenable dans le temps, autrement dit, industrialisable. Nous en présentons 4 essentiels pour nous.
1/ NE PAS DÉMARRER “FROM SCRATCH”
Le marché est foisonnant, et même s’il est difficile de s’y retrouver, il a le mérite d’apporter un vaste champ des possibles en termes de technologies et de solutions sur toutes les briques de l’IoT. En témoignent les plateformes IoT dont on en recense plus de 600, et le large spectre des technologies LPWAN (cellulaires, non cellulaires, réseau privé, réseau public …).
Pour les terminaux ou endpoints, il en est de même et il peut arriver que le marché ne propose rien de satisfaisant et que l’on souhaite alors développer son propre module.
Ainsi, pour optimiser le temps de développement (habituellement entre 6 et 18 mois en fonction de la complexité) et réduire la complexité du projet, il est recommandé de partir de modules préexistants.
On pensera par exemple à Generic Node qui proposent une offre de création d’endpoint LoRa personnalisé et agnostique aux opérateurs grâce à un boîtier pré-designé où l’on va sélectionner ses composants et configurer son firmware sans être un expert de l’électronique. On pensera également au module plug-and-play Octave de Sierra Wireless qui permet de connecter au Cloud des modules industriels ModBus ou CAN en quelques semaines à peine et avec des coûts de développement réduits.
2/ BUSINESS CASE AU PLUS TÔT
Il faut estimer au plus tôt possible le Business Case car la rentabilité de la solution est un critère essentiel de validation pour déployer ou non une solution. Fondamentalement, il s’agit de déterminer si oui et quand est-ce que les profits seront plus importants que la somme des dépenses ponctuelles et récurrentes. Le premier enjeu est de cerner toutes les dépenses directes et indirectes. Il n’est pas rare de sous-estimer :
les coûts de développements,
les hors-forfaits de connectivité,
les services Cloud lorsque les volumes de données deviennent importants,
les coûts de maintenance et d’intervention sur le terrain,
les coûts d’exploitation et d’évolution de la solution …
De la même manière, il y aussi souvent des gains indirects qui n’avaient pas été identifiés au départ : une solution de maintenance prédictive permettra de réduire les coûts de maintenance mais augmentera le temps de disponibilité des ressources physiques et humaines, une solution de protection des travailleurs isolés pourra permettre de réduire le montant des primes d’assurances etc.
Après avoir cerné tous les impacts il faut les estimer quantitativement avec un montant nominatif ou un pourcentage quand ce n’est pas évident. Le Business Case peut changer au fur et à mesure du design et des choix associés et il ne faut pas hésiter à le mettre à jour itérativement.
3/ LE DEVICE MANAGEMENT ET L'ÉVOLUTIVITÉ
Dès le départ on aura facilement identifié les besoins et modalités relatives au provisioning et à la connectivité courante des endpoints, ce qui est d’ailleurs globalement couvert par toutes les plateformes IoT. Mais il faut voir au-delà car le Device Management doit permettre beaucoup plus :
l’endpoint et son environnement doivent être modélisables dans la plateforme,
on doit pouvoir collecter des métriques complémentaires comme le niveau de batterie et de signal de l’endpoint,
on doit pouvoir mettre à jour Over-The-Air l’endpoint depuis la plateforme en termes de software, firmware, OS et certificats à des fins de sécurité et d'évolutivité,
le tout de manière scalable et avec des fonctionnalités de groupes et d’automatisation pour la gestion des flottes.
Dans le cas spécifique des objets communicants sur les réseaux cellulaires, l’utilisation de cartes SIM hybrides, permettant de rattacher un même appareil à plusieurs réseaux est en plein essor pour des raisons de résilience et d’évolutivité, et la plateforme associée doit alors permettre de permettre de mettre à jour, ajouter et supprimer les profils réseaux de la carte.
4/ LES MÉTHODES AGILES ET LA COLLABORATION
L’intérêt des méthodes d’innovation, en particulier le Design Thinking, pour la phase d’idéation et de design de la solution se démontre de manière évidente et est déjà décrit dans un article précédent.
Pour la phase de build, les méthodes agiles, notamment SCRUM, prennent à leur tour tout leur sens. Basées sur des hypothèses de timing et de budget contraintes, d’un avancement en itérations, ou sprints, dédiées à des ajustements, et d’une équipe réduite, compétente et autonome, elles permettent alors :
des livraisons régulières de solutions, ou parties de solutions,
avec un contrôle du budget, du planning et du ROI,
une adaptation aux changements avec une communications continue,
pour une solution qui répond aux besoins avec des clients satisfaits.
Pour supporter ces méthodologies, les solutions de développement applicatif low ou no-code se multiplient et s’enrichissent avec l’objectif de permettre la collaboration de toutes les parties prenantes d’un projet IoT, y compris celles qui n’ont pas de compétences de développement comme les métiers souvent. On peut citer la référence Mendix rachetée par Siemens en 2019 dans le but de conserver sa position de leader sur le marché des plateformes IoT avec sa solution MindSphere.
5/ “ET LA SÉCURITÉ" PENSEREZ-VOUS !
Effectivement il s’agit-là aussi d’un réflexe à avoir au plus tôt, mais dont la portée, l’approche et les bonnes pratiques méritent un article à elles seules.
Les réflexions présentées ci-dessus devront intervenir au plus tôt mais cela ne suffit pas. Au sein d'une entreprise, il convient aussi de définir une gouvernance adaptée à celle-ci (organisation, métiers, compétences, objectifs …). Il pourrait y avoir autant de gouvernance et d’organisation que d’entreprises, toutefois la transversalité et la réduction des silos devront être au cœur des réflexions : la mise en place de programmes ou de Business Units dédiés semblent être une bonne pratique dans un premier temps car elles apportent une vision transverse sans bouleverser l’organisation existante.