Les objets connectés, un vrai sujet d'architecture pour Identicar
Publié par Christophe Lagane le | Mis à jour le
Dans le cadre d'une table ronde organisée par MC2I, Thomas Fournier, DSI d'Identicar, livre ses conseils condensés par 15 ans d'expérience dans le développement d'objets connectés.
Face à la rupture technologique proposée par l'Internet des objets (IoT), les entreprises sont aujourd'hui confrontées à un nombre grandissant de questions aussi bien d'ordre stratégique, organisationnel qu'opérationnel. Les organisations doivent-elles changer leur modèle économique?? Comment évaluer les gains?? Avec quels partenaires travailler?? Comment synchroniser les développements logiciels, électroniques, voir mécaniques?? Quels métiers doivent contribuer à la stratégie Internet des objets (IoT)?? Où localiser l'intelligence?? Quelles données traiter?? Comment gérer le cycle de vie des objets. Et quid de l'interopérabilité?? Pour tenter d'y répondre, le cabinet de conseil en Systèmes d'information mc2i Groupe avait invité deux clients, Identicar et GRT Gaz, à venir témoigner de leur retour d'expérience dans le cadre d'une table ronde organisée mardi 14 juin. Nous rapportons aujourd'hui la vision d'Identicar sur ces problématiques.
« D'un point de vue technique, on peut tout faire. Mais pas d'un point de vue réglementaire », annonce d'entrée de jeu Thomas Fournier (photo ci-dessus), DSI du groupe Identicar. Cette PME de 200 collaborateurs qui gravite depuis une trentaine d'années autour des services aux véhicules (gravure, complémentaires de franchise.) développe depuis 15 ans une activité de localisation avec des boîtiers communicants pour, à l'origine, répondre aux problématiques de vol de véhicules. Outre le tracking (avec un relevé toutes les minutes environ), les boîtiers se sont enrichis au fil des versions de fonctionnalités de sortie de zone (avec réception d'un SMS quand la voiture sort d'une zone définie comme le garage par exemple), de couplage à l'ordinateur de bord (pour couper le moteur à distance en cas d'utilisation non autorisée) ou encore d'un accéléromètre (pour détecter les chocs).
Autant d'éléments auxquels l'entreprise a ajouté de l'intelligence et de la mémoire pour faire de la gestion de flotte avec notion de livraison et de l'analyse comportementale du conducteur (ce qui intéresse grandement les assureurs). Des solutions que Thomas Fournier a illustrées en présentant Wetrak. Ce boîtier créé il y a deux ans et un peu plus gros qu'un étui à lunettes (dont 95% du volume est occupé par la batterie) ne nécessite aucune installation. « L'utilisateur le cache où il veut dans sa voiture », précise le DSI.
Veillez à la sécurité
Première remarque sur les développements, la question de la sécurité?: « Ces systèmes embarqués communicants ont potentiellement des failles et sont soumis aux mêmes problématiques que les systèmes d'information. » A savoir les risques de vols de données, d'attaques par déni de service pour bloquer le système (même si « pour nos solutions, nous ne sommes pas trop inquiets car pas très visibles mais c'est un vrai problème »), ou de prise en main à distance (comme l'ont illustré le contrôle à distance d'une Jeep Cherokee l'été dernier). Autant de problématiques qu'il ne faut pas négliger pour protéger les clients.
Autre remarque, l'aspect réglementaire évoqué au début de son intervention. Incontournable (en France en tous cas), il peut constituer une contrainte. « Pour être confome CNIL, il ne faut quasiment rien stocker ou supprimer les données au bout de quelques mois, ce qui est un peu compliqué quand on veut développer des solutions intelligentes à partir de l'historique des données pour déterminer les comportements sur les conducteurs, regrette Thomas Fournier, même s'il reconnaît que cela nous assure du bon contrôle des données utilisées par les différents acteurs du marché. » Et de proposer une parade à cette problématique en mettant « de l'intelligence dans le boîtier pour faire du traitement de données localement afin de récupérer des informations agrégées de manière centralisée ». Ce qui permet in fine de séparer la partie données sensibles de la partie effectivement utilisable. « Mais il n'y a pas de solution miracle », regrette-t-il en évoquant le modèle américain beaucoup moins contraignant (pour le plus grand bénéfice de Google).
Où placer l'intelligence??
Savoir où placer l'intelligence, dans l'objet ou dans le back-office, constitue d'ailleurs une question propre au développement d'un objet connecté. « Il y a un vrai sujet d'architecture, commente Thomas Fournier. Quel traitement je fais en local, en back-office, alors que la mise à jour de firmware de boîtiers disséminés dans la nature peut se révéler délicate?? » Chaque cas est particulier et doit répondre aux besoins de l'entreprise mais la question est à poser en amont de la conception de l'objet. Chez Identicar, « sur Wetrak nous avons choisi de conserver la capture et la communication en local et d'assurer le calcul de position, etc., en back-office. Je pense que c'est une bonne approche en premier lieu mais ce sont des questions qui se posent tout au long du projet et [il faut] se laisser éventuellement la possibilité de rebasculer l'intelligence dans le boîtier parce que c'est plus pertinent. »
D'ailleurs, pour éviter d'avoir à modifier le code «?en dur?», comme le paramètre du nombre de connexions ou de temps d'attente, « il est important de rendre un maximum d'éléments paramétrables dans la configuration du boîtier sinon vous passez votre temps à faire des mises à jour ». Quand à la question des tests, si la phase laboratoire est obligatoire, « je conseille d'aller rapidement sur des phases d'utilisation réelle par les collaborateurs, les partenaires, car un objet qui se connecte très bien en labo où l'antenne GSM est à 50 mètres aura peut-être un comportement différent dans une voiture sur une route des Alpes ». Ce qui nous amène à la question du débogage. « On ne peut pas brancher Visual Studio en mode débug sur un objet [pas de manière triviale, en tout cas] et quand le boîtier ne communique plus, il n'y a plus moyen de récupérer les logs. » A moins de développer un deuxième système de communication en parallèle, il n'y a pas de solution idéale. Pour ses boîtiers, Identicar a mis au point un système de code lumineux émis à partir d'une LED qui permet au client de vérifier son fonctionnement en rapportant ce qu'il voit au fournisseur. Une astuce qui permet d'identifier les boîtiers défectueux sans trop d'investissement en support.
Réunir équipe hardware et software
Sur la question de la production, « il ne faut pas aller trop vite, conseille le DSI, il vaut mieux faire de petites séries pour vérifier le bon fonctionnement du produit. En cas de modification nécessaire, on rate une centaine de boîtiers et pas 1000 ou 2000 ». Dans tous les cas, mieux vaut « essayer de surveiller un maximum de chose » pour s'assurer que le boîtier fonctionne bien une fois lâché dans la nature. « Cela vous permet de vérifier qu'il n'y a pas de problématique de design ni de blocage » avant d'aller plus loin en production. D'autant que, des problèmes de qualité de composants peuvent émerger d'une série à l'autre. « Quelque chose qui fonctionne une fois ne fonctionne pas forcément N fois. »
Enfin, ne pas négliger la problématique propre à la montée en charge. « Sur un déploiement à grande échelle, il faut s'attendre à gérer beaucoup d'informations. S'il est inutile de commencer avec 50 serveurs pour gérer 3 boîtiers, il faut monitorer de près la montée en charge pour savoir comment la répartir, comment assurer la distribution des connexions sur la partie web, etc. Le dimensionnement de l'architecture est un vrai sujet face à la montée en charge. »
Enfin, en matière d'organisation, comme pour n'importe quel projet informatique, Thomas Fournier recommande de mettre en place un groupe de feed-back. « Il faut aller en production vite, utiliser des boîtiers dans la vraie vie par beaucoup de personnes, ce qui permet d'entrer dans une phase d'amélioration continue. » Autre élément important, « la coordination entre le marketing produit et la technique » de manière à éviter les décalages entre les attentes des concepteurs face aux limites techniques (ou financières) des solutions électroniques. « Pour éviter d'avoir des produits infaisables ou trop chers, il faut vraiment que le marketing et la technique travaillent main dans la main. » Même logique de collaboration étroite entre les équipes hardware et software. « La frontière entre ingénierie informatique et matérielle est de plus en plus floue, il faut que les équipes se parlent pour définir à quel endroit mettre de l'intelligence dans le boîtier. Si vous développer d'un côté du hard et de l'autre du soft, quand vous assemblerez les deux, ça ne marchera pas. » Solution?? « Casser la séparation entre informatique et R&D pour faire une seule direction technologique [jusqu'à] rassembler les équipes physiquement. »
Autant de leçons tirées d'une expérience de plus de 10 ans dans la conception d'objets connectés même si « chaque cas est particulier [et qu'il] n'y a pas de solutions miracles ».
Lire également
Le rôle de Chief IoT Officer gagne l'entreprise
9 développeurs de l'IoT sur 10 utilisent l'Open source
Plus d'objets connectés que de smartphones dès 2018