Un projet IOT, bien plus qu’une histoire d’objets !

Dans l'inconscient collectif, les projets IoT sont souvent réduits à un enjeu matériel, à la fois dans l'approche méthodologique mais également dans leur dimensionnement. En réalité, l'objet est la partie émergée de l'iceberg

Un projet IOT, bien plus qu’une histoire d’objets !

Le capteur, partie émergée de l’iceberg

Dans l’inconscient collectif, les projets IoT sont souvent réduits à un enjeu matériel,à la fois dans l’approche méthodologique mais également dans leur dimensionnement. En réalité, l’objet est la partie émergée de l’iceberg car pour voir le jour, un projet IoT s’appuie également sur :

  • Un réseau de télécommunication qui doit être adapté au cas d’usage (bande passante, fréquence d’émission, portée, coût, etc.)
  • Une plateforme numérique qui va gérer l’acquisition, le traitement, le stockage et la mise à disposition des données
  • Une interface et un traitement pour valoriser les données collectées (application mobile ou web, tableau de bord d’aide à la décision, etc.

Le schéma ci-après illustre un exemple simplifié d’architecture de projet IoT utilisant les réseaux LPWAN (bas débit longue portée) avec ses différents modules :

  • Le backend LPWAN (Sigfox, LoRa privé ou public) va se charger de l’acquisition des données brutes en provenance des capteurs et de leur redirection vers la plateforme IoT
  • La plateforme IoT assure le décodage des trames, l’historisation des données et intègre un module d’API pour échanger les données avec des systèmes tiers
  • Les SI tiers, comme les bases open data ou les logiciels client qui pourraient enrichir ou bénéficier des données collectées
  • Les applications métiers développées spécifiquement pour le projet, comme l’application mobile servant à l’alerting des agents ou le tableau de bord de visualisation des indicateurs de satisfaction
  •  

Cette complexité technique nécessite d’avoir une approche plus holistique du projet, en intégrant les spécificités du cas d’usage, afin de choisir les briques technologiques les plus adaptées. Ces choix vont conditionner le business model et les perspectives de ROI.

 
Intégrateur ou solution maker ?

L’approche prospective est également déterminante sur ce type de projet. Certaines entreprises iront naturellement vers des « solutions makers » pour mettre en place une verticale répondant strictement au besoin, adressant ainsi le sujet via un angle technique, pratique et cloisonné. Mais quelle sera leur réflexion lorsque le département adjacent voudra mettre en œuvre un autre cas d’usage ? :

  • Rechercher un nouveau « solution maker » répondant au besoin
  • Réaliser des développements spécifiques de la solution actuelle pour accueillir le nouveau cas d’usage

Ces 2 scénarios présentent des inconvénients à court terme :

  • La multiplication des fournisseurs, des contrats et des risques associés
  • Les développements spécifiques sont souvent redoutés par les solutions makers, les rendant ainsi très onéreux
  • Le manque d’interopérabilité entre les différentes applications
  • L’absence d’un référentiel et d’une nomenclature pour la gestion des données

Les solutions construites sur mesure ou assemblées par intégrateur nécessitent certes un investissement plus conséquent, tant financier que dans la définition de la solution « métier », mais elles assurent une meilleure scalabilité et évolutivité. De plus, ce sont des socles techniques propices pour capitaliser sur le cas d’usage initial, trouver des gains indirects et assurer ainsi un ROI global sur le projet.

 

Le calcul de ROI, un exercice souvent mal abordé

L’enjeu « économique » des projets, incarné par la notion de rentabilité, joue un rôle déterminant dans le lancement et les choix initiaux. Cette rentabilité est généralement soutenue par un business model établi en début de projet pour justifier l’investissement. Le ROI estimé prend en compte des perspectives de gains assez concrètes : création d’un nouveau produit ou service monétisable, gain de productivité, réduction des coûts logistiques …

Malheureusement, les calculs s’arrêtent souvent aux coûts matériels (CAPEX) et logiciels (OPEX) et omettent ainsi les coûts d’exploitation liés à l’intégration de ces nouveaux dispositifs connectés. En effet, si je dois faire intervenir un technicien une fois par trimestre pour réparer, remplacer ou décommissionner un capteur, quel est l’impact sur mon ROI initial ? Existe-t-il toujours ?

Pour pallier cela, il existe deux pistes de réflexion :

  • Prendre en compte ces coûts d’exploitation dès la construction du business model et travailler à les minimiser (limiter aux déplacements spécifiques, anticiper les interventions, etc)
  • Étudier les sources de ROI indirectes. En effet, si l’investissement initial est justifié par le cas d’usage métier, il est souvent possible de valoriser le projet autrement : décliner le cas d’usage sur un autre métier, monétiser les données collectées, créer un service payant pour les clients finaux, etc.

Cette deuxième piste peut être illustrée par un projet mené par Visian pour Machine Pagès, une PME française qui produit des machines-outils pour le secteur du packaging alimentaire.

Visian a accompagné initialement Machine Pagès dans la connexion de ses machines à une plateforme Cloud afin de pouvoir superviser en continu, prévenir les pannes et conseiller les clients. Une application mobile a ensuite été développée pour permettre aux clients finaux, les responsables d’usine, de consulter l’état des machines à tout moment.

Ce service a été valorisé dans une offre de support 2.0 vendue en complément des machines. On est donc parti d’un projet « technique » avec un ROI autour de l’optimisation des coûts d’exploitation (réduction des déplacements) pour atterrir sur un projet « marketing » à travers la monétisation d’un nouveau service.

Guillaume Giroult

Les 5 piliers du cadrage data

e cadrage n’est pas une formalité.

C’est une assurance projet.

Trop souvent, on le réduit à une phase “administrative” avant le vrai démarrage.
Mais le cadrage, c’est le moment où tout se joue :
les hypothèses, les décisions, les risques, les priorités, la vision commune.

Lire la suite »

Le socle data : construire les fondations d’une performance durable

On parle beaucoup de data mesh, de cloud, ou d’intelligence artificielle.
Mais derrière ces concepts, un principe essentiel reste trop souvent oublié : la solidité du socle data.

Ce socle, c’est l’ensemble des fondations techniques, méthodologiques et organisationnelles qui permettent à une entreprise de collecter, fiabiliser, gouverner et exploiter ses données dans la durée.
Sans lui, les projets se succèdent, les outils se multiplient, mais la valeur créée reste limitée.

Un socle data solide, c’est ce qui distingue une organisation réellement data-driven d’une organisation simplement data-busy.
Chez Visian, nous le concevons autour de cinq piliers qui structurent toute démarche pérenne

Lire la suite »

Data Observability : voir, comprendre et anticiper ce qui se passe dans vos données

Dans de nombreuses entreprises, les données sont devenues le moteur de la décision, de la performance et de l’innovation.
Mais comme tout moteur, elles doivent être surveillées.
Pas seulement sur la qualité de ce qu’elles contiennent, mais aussi sur la manière dont elles circulent, se transforment et vivent au quotidien.

C’est précisément le rôle de la Data Observability : permettre de comprendre en continu la santé du système de données, de détecter les incidents avant qu’ils ne deviennent visibles, et de restaurer la confiance dans la donnée.

Lire la suite »

Data Mesh & Data Products : la DSI est-elle encore aux commandes ?

Beaucoup voient le Data Mesh comme une revanche des métiers sur la DSI.
Fini le centralisme, place à la décentralisation.
Mais si on pousse un peu plus loin la réflexion, une question essentielle surgit :

Quel est le rôle de la DSI dans une organisation orientée Data Mesh ?
A-t-elle encore un rôle à jouer ? Ou est-elle condamnée à devenir une simple équipe de support ?

Lire la suite »

The Concorde Fallacy : quand un projet IT continue de voler droit dans le mur

L’histoire du Concorde est fascinante :
Une prouesse technologique. Un avion supersonique d’avant-garde.
Mais aussi… un désastre économique.
Et pourtant, malgré des signaux d’alerte très clairs, les investissements ont continué pendant des années.

Pourquoi ?
Parce qu’il avait déjà coûté trop cher pour qu’on accepte de l’abandonner.

Ce mécanisme psychologique porte un nom : la Concorde Fallacy, ou biais des coûts irrécupérables (sunk cost fallacy en anglais).
Et il est omniprésent dans les projets IT.

Lire la suite »

DOC API versus Data Contracts

L’essor du data mesh et de ses principes fondamentaux a fait émerger de nouveaux besoins en matière de gouvernance des données. Dans une architecture où chaque domaine est responsable de ses propres produits de données, le risque de désalignement augmente. Les data contracts se présentent comme une solution structurante : des accords explicites qui formaliseront les échanges entre les producteurs et les consommateurs de données, et ce, d’une manière compatible avec la vision décentralisée du data mesh.

Lire la suite »
Logoblanc_carrérouge

Rejoindre Visan

contact@visian.fr

01 41 37 41 37

Suivre sur linkedin

Localisation

22 rue du président Wilson

92300 Levallois Perret