Pour commencer par… le commencement (à savoir la personne ou la société qui est à l’origine du produit ou service), reprenons notre idée du “tout le monde il est beau, tout le monde il est gentil” évoquée dans notre article dédié à la sécurité (“Sécurité des objets connectés: un “must”). Comment s’assurer que le fournisseur ou que le développeur de telle ou telle appli, de tel ou tel code, a sécurisé sa solution? Qu’elle ne contient pas de brèche, de porte dérobée, etc.? Comment lui faire confiance?

La réponse ne tient pas uniquement au sérieux, à l’honnêteté ou au penchant “appât du gain” de l’auteur. Il y va aussi de sa capacité à procurer une solution qui soit sécurisée. Or, pour le faire, il lui faut consentir une somme de moyens – en temps et en finances – loin d’être négligeable.

Prenons l’exemple d’un équipement domestique connecté et des applis auxquelles on peut les coupler. Christophe Châtillon, patron de Tapptic, témoigne: “Quand on développe une appli, on doit mener de plus en plus de tests. Rien que sur le sol européen, on dénombre environ un millier de devices Bluetooth qui peuvent potentiellement se connecter à l’appli. Il faut tout tester, multiplier les use cases. Chez Tapptic, nous avons constitué un catalogue de quelque 450 terminaux différents. S’y ajoute le fait qu’au moins trois versions d’OS doivent être testées [iOS, Android, Windows]. Le budget explose si on veut bien le faire…”

Et les tests automatiques, réalisés par des logiciels et autres robots de test, ne suffisent pas à la tâche. La main et l’oeil de l’homme sont de plus en plus sollicités. “Il faut compter de 300 à 400 tests par application.”

Des tiers de confiance?

Qui croirait que tous les développeurs, concepteurs, éditeurs et intégrateurs sont scrupuleux et procèdent à tous ces tests? “Une multitude d’applis non testées existent déjà”, avertit Christophe Châtillon. “Tant qu’elles ne se connectent pas [à Internet], ce n’est pas grave mais…” Un “mais” qui prend encore un aspect plus inquiétant quand on se rappelle que nombre de systèmes et d’infrastructures sont hébergées dans des “clouds” en dehors du territoire européen et de sa protection réglementaire. “C’est déjà la jungle”, prévient-il. “Et on ne l’imagine même pas…”

Comment, dès lors, faire confiance ou confier les vérifications nécessaires? Philippe Drugmand, responsable du département R&D au CETIC, estime qu’un “label ne suffira pas. Il faudrait sans doute un organe de certification des applis. Le mieux serait de définir une méthodologie afin de vérifier systématiquement tous les scénarios, pour analyser qui fait quoi et accède à quoi. Mais c’est hyper-complexe…”

Des interrogations en cascade

Un livre, sans doute, n’y suffirait pas tant la liste des points à prendre en considérable est vaste. Quelques petits exemples?

Dès l’instant où une solution est est assortie d’une licence individuelle, le fournisseur est censé être responsable des mises à jour et apports de correctifs. Mais qu’en est-il réellement à une époque où tout rime avec SaaS et cloud?

Quid des durées de garantie? Si le système n’est couvert que pendant deux ans, qu’advient-il ensuite?

Quid si le client, pour une raison ou une autre, “refuse” les mises à jour? Prend-il ses responsabilités, en est-il conscient?

Quid aussi lorsqu’un système n’est plus supporté par le fournisseur? Ce dernier n’est alors plus responsable de ce qui pourrait arriver à la solution. “Voyez ce qui s’est produit, récemment, avec l’arrêt du support de Windows XP”, rappelle Loïc Bar de The Smart Company.

De même, qu’advient-il de la sécurité et des responsabilités si un fournisseur décide de ne plus supporter tel ou tel protocole?

Pourra-t-on imposer une “transparence” optimale pour la manière dont les fournisseurs devront avertir ou informer les utilisateurs des mises à jour de microcodes ou d’applis auxquelles ils procéderont?

Quelles précautions le commanditaire d’une appli doit-il prendre? Que doit-il exiger du développeur? Comment peut-il contrôler l’assurance-qualité?

Quid de la “propriété” des algorithmes et d’une législation qui s’applique réellement à cette “intelligence” embarquée?

Quid de l’entreprise? Comment peut-elle veiller à sa sécurité, avec cette multitude d’objets et d’équipements connectés, implantés par elle-même pour ses besoins opérationnels ou introduits dans ses murs par ses collaborateurs, clients, visiteurs…? A qui incombe la responsabilité en cas de vol, perte, infraction de vie privée, contamination de systèmes? L’analyse de l’origine de la faute – ou de la faille – sera un élément-clé pour déterminer les responsabilités mais les observateurs estiment que la conscientisation et la répartition des rôles touchera tout le monde – du simple utilisateur jusqu’au directeur IT, sans parler du chef d’entreprise.

“Savoir c’est pouvoir”

La prise de conscience des risques commence – idéalement – par la compréhension de ce qui se trame au sein ou entre la multitude des objets connectés de notre quotidien.

Mais qui, parmi les citoyens lambda, en est capable?

En la matière, invité à faire un exposé lors d’un atelier Internet des Objets organisé récemment par Technobel, Technofutur TIC et le Cefora, Bruno Schröder, chief technology officer chez Microsoft Belgique, a ré-enfourché l’un de ses dadas préférés. A savoir qu’il est plus que jamais nécessaire que l’utilisateur ait un minimum de conscience et de compréhension de ce que font les algorithmes. Histoire de ne pas être les jouets de tireurs de ficelles aux intentions peu ou prou malveillantes ou indésirables.

C’est tout l’enjeu de l’apprentissage de la programmation – aussi élémentaire soit-elle – et de sa réintroduction dans les cursus scolaires – sans oublier la masse des conso-nautes.

“Il s’agit de comprendre un minimum ce qui se passe [au niveau des algorithmes]. Il est dès lors important d’investir dans l’enseignement de la programmation à l’école. C’est là un enjeu fondamental parce que c’est, pour le citoyen, le moyen de retrouver le contrôle.”

Or, en la matière, en dépit de premières initiatives, encore rares, trop ponctuelles et modestes, l’enseignement en Belgique est à la traîne. “Seulement 4% de nos étudiants apprennent à programme”, soulignait Bruno Schröder. “Aux Etats-Unis, le score est de 50% et les autorités et observateurs estiment que c’est un véritable scandale que ce ne soit pas plus…”

Que dit la loi?

D’un point de vue légal, la situation n’est pas forcément claire. Toutefois, estime Philippe Laurent du cabinet juridique MVVP (Marx Van Ranst Vermeersch & Partners), le fait que l’IT – via les logiciels embarqués, les applis et les algorithmes – se retrouve intégrée dans des produits remet la législation concernant la responsabilité de produits défectueux au centre du jeu. Celle qui s’applique par exemple aux voitures mais qui n’avait pas trouvé sa place dans le registre des ordinateurs classiques.

Aujourd’hui que l’IT s’embarque dans le moindre objet, on pourrait donc en revenir aux anciennes règles, assorties de l’une ou l’autre disposition particulière, et au principe de base qui est “qui casse paie”. La “casse” pouvant être un dysfonctionnement, un bug. Mais il s’agira de déterminer la responsabilité de chacun dans la survenance d’un “bug”. Exemple dans le domaine des voitures connectées: les responsables potentiels sont le constructeur, l’équipementier, le propriétaire du véhicule, le développeur de l’appli, voire le prestataire qui organise et orchestre le réseau (dans le scénario de voitures pilotées automatiquement et s’échangeant des données entre elles sur leur position, leur vitesse…).

Grégorio Matias se montre plus sceptique, estimant qu’il y a encore, à l’heure actuelle, “deux poids, deux mesures”. Si les constructeurs ont tout intérêt à fournir des équipements qui optimisent la sécurité physique (lisez: corporelle) des utilisateurs et consommateurs [pensez à la sécurité des voitures et de leurs équipements, celle de l’électro grand public…], le domaine des produits électroniques, dans leur composante “immatérielle” (les microcodes et applications), ne donne pas encore lieu à une législation contraignante, estime-t-il.

Faudra-t-il, de plus, attendre que le cap de l’intégrité physique des personnes soit franchi (par exemple, un hacking de device de voiture qui provoque un accident mortel) avant qu’on prenne les choses réellement au sérieux? Pourtant, rappelle Loïc Bar, ce genre de scénario s’est déjà produit… via pilotage à distance d’un éclairage domestique. Un hacker s’est amusé à pirater les prises électriques connectées d’un particulier et à faire s’allumer à répétition les luminaires. Résultat? Un incendie s’est déclaré.

Résultat du flou législatif: un manque d’anticipation des risques ou de réactivité de la part des fabricants lorsqu’un problème surgit. Il évoque, en guise d’exemple, la vulnérabilité des systèmes embarqués automobiles, que des chercheurs et hackers ont réussi à pirater et contrôler. Notamment le système de frein de certains modèles Toyota. “Quels autres constructeurs ont mis leur microcode à jour? Quels usagers ont exigé que le constructeur le fasse?”

Evoquant les remous récents suscités par le virus Heartbleed, “sans doute beaucoup plus sérieux que Stuxnet”, il met en garde: “nous sommes en face d’un vide juridique alors que le problème ou le risque touchera demain un maximum de personnes…”

La question des responsabilités se corse évidemment dès l’instant où il y a piratage. Le hacker pourrait évidemment être pointé du doigt (mais quant à le “coincer”…) mais ce pourrait également être le cas de l’auteur de la faille qui lui a permis de s’attaquer à l’objet. Toute cette zone nébuleuse, touchant à la fois à la sécurité et à la vie privée, n’a pas encore été intégrée dans les textes de loi mais le devra. Impérativement.

Qui est propriétaire de quoi?

Si le propriétaire de l’objet est clairement identifié, qu’en est-il du code? Philippe Laurent prend un exemple dans le domaine des smartphones. “Samsung vend des appareils et est le fabricant du matériel mais l’OS, lui, c’est de l’open source (Android), dans la galaxie Google, développé par d’autres personnes. On se retrouve donc avec une multitude de développeurs à l’origine de multiples composants…”. Qui est “propriétaire” – et donc responsable – de quoi?

Quid, par ailleurs, de la “propriété” des données – même si, comme le souligne Philippe Laurent, on ne peut pas parler, en la matière, de “propriété”. “Le concept de propriété des informations n’existe pas dans le domaine juridique. Si une personne lésée peut exercer un droit de suite sur une voiture qui a été volée, les choses sont différentes en cas de vol de données, ou de faillite de la société qui les hébergeait dans son data center. Si le curateur revend le serveur où se trouvaient les données pour 500 euros, la notion de la valeur des données, elle, est absente.”

Qui assurera la sauvegarde de ces données avant que le matériel soit revendu ou parte à la casse? Seul conseil à donner aux utilisateurs: vérifier soigneusement ce que prévoit le contrat. A vos loupes, donc, pour les “petites lettres” pour vos micro-objets…

Toujours en matière de “propriété” – ou dirons-nous, de “détention” – de données, le cas de Nest (mais on pourrait l’extrapoler à bien d’autres acteurs) est significatif. L’objet (le capteur, le thermostat connecté) est bien la propriété de l’utilisateur (à moins qu’il ne le loue un jour à son distributeur d’électricité). Mais les données, elles, sont exclusivement entre les mains de Nest. Parce qu’il y va de son business model et de l’intérêt même de collecter des données domotiques (analyse d’une masse de données, venant de multiples consommateurs, afin de dégager des tendances, statistiques…) afin de les revendre à ceux qui y trouvent de l’intérêt (gestionnaires de réseaux électriques, prestataires de services et consommateurs).