Depuis plusieurs années, nous conseillons des dirigeants dans la manière la plus pertinente d’utiliser les technologies numériques pour mieux gérer ce qui est en général leur deuxième dépense après les salaires : leurs locaux. Force est de constater, ici comme ailleurs, que le désordre et le foisonnement règnent. Comment y voir plus clair dans ce qui ressemble à une tour de Babel ?

Smartbuilding ou tour de Babel ?

« Nous avons 300 clés »

Notre première intervention en smartbuilding a démarré quand un de nos clients nous a demandé de l’aider pour numériser l’accès à ses espaces, dans des bâtiments d’enseignement. Antoine Matta a parfaitement raconté l’histoire dans son article.

Comme de bonne pratique, nous avons démarré par l’inventaire des accès à numériser, et par la structuration, qui a résulté en 3 types :

  • Accès depuis l’extérieur ;
  • Accès de l’intérieur de l’enceinte de l’école à des bâtiments ;
  • Accès à des pièces (classes, bureaux, locaux techniques) à l’intérieur du bâtiment.

Pour chacun de ces trois types, nous avons proposé une pile de technologies, en choisissant comme des bonnes et coruscantes pratiques que nous rappelle régulièrement Jean-Paul Figer :

  • Des standards de l’Internet, W3C, IETF ;
  • Des technologies utilisées par des dizaines, et si possible, des centaines de millions d’utilisateurs ;
  • Des technologies Cloud.

En l’occurrence, nous avons empilé :

  • Google Workspace (déjà présent) avec des Groupes d’utilisateurs pour définir les droits d’accès ;
  • Un SaaS de gestion d’accès ;
  • Des contrôleurs locaux ;
  • Les mêmes badges Mifare Desfire que ceux déjà utilisés pour la cantine et les imprimantes ;
  • Des badgeuses là où nécessaire ;
  • Des portiers video full Internet pour les accès depuis l’extérieur ;
  • Des poignées avec des hubs pour les portes.

Nous avons démarré par un PoC, qui a permis de s’assurer que les performances revendiquées dans les documentations marketing étaient au rendez-vous.

Contrôle d'accès moderne : les conseils

Contrôle d’accès moderne

Les bénéfices pour notre clients ont été nombreux :

  • un coût deux fois moins élevé qu’une proposition d’un serrurier classique ;
  • une praticité de gestion et une sécurité bien plus élevées : il suffit de mettre ou de sortir un compte d’un groupe dans la console de Google Workspace pour activer ou désactiver un badge. Pas besoin de programmer les serrures ou les badges, qui ne contiennent aucune information locale autre que celle qui descend du Cloud ;
  • une robustesse industrielle : les contrôleurs locaux interrogent, le SaaS, qui lui-même interroge en cascade Google Workspace, toutes les 5 minutes pour mettre à jour les droits. Si on a une panne d’internet ou d’un des quelconques maillons, on a un fonctionnement en ilotage, avec comme seul inconvénient la non mise à jour des droits pendant la panne ;
  • des technologies interopérables, non propriétaires, donc durables : si demain un constructeur fournit de meilleures poignées, on les prend, sans avoir à tout changer par ailleurs.

La tour de Babel des technologies : capteurs et actionneurs

La grande difficulté rencontrée par le marché est le zéro et l’infini :

  • zéro : soit il n’y a rien, ou on a l’impression qu’il n’y a rien ;
  • l’infini : soit il y a une offre pléthorique et on ne sait pas quoi choisir tellement il y a de technologies.

Dans ce dernier cas, on ne sait pas quoi choisir : LoRaWAN, Bluetooth, ZigBee, ZWave, Wi-Fi, Matter, Thread… avec, pour ces technologies, parfois des appareils incompatibles entre eux, malgré le fait qu’ils portent le même logo de technologie.

Notre crible de bonnes pratiques (standard, > 100 M utilisateurs…), appliqué à ce besoin, nous conduit à choisir le Wi-Fi, qui certes a des inconvénients, mais qui sont graduellement compensés, par la masse d’offres et d’usages.

De la même manière que l’eau, l’électricité, la ventilation ou l’évacuation des eaux usées, il va falloir que le monde de la construction intègre qu’il faut que chaque endroit d’un bâtiment soit connecté sans fil à l’Internet, et concrètement cela veut dire avoir un câble RJ45 de catégorie 5 ou plus par pièce, pour connecter un point d’accès Wi-Fi, et une (ou plusieurs si le local est étendu) armoire réseau avec des switches PoE, tout cela branché à une box internet très haut débit (même si c’est parfois un face norà escalader). C’est évidemment plus simple à traiter en construction neuve qu’en rénovation, notamment si on doit faire des saignées pour faire passer des câbles qui manquent.

Ecran de smartphone montrant un speedtest avec un débit download de 93,7 Mbps et un débit upload de 21,3 Mbps

Le Wi-Fi à très haut débit symétrique, une utilité identique à l’eau, l’électricité, l’évacuation des eaux usées

La tour de Babel des technologies : apps, protocole et hyperviseur

La guerre des technologies fait aussi rage dans les couches d’interface homme-machine : Tuya, eWeLink, Smart Life, Apple Homekit, Google, Amazon Alexa, l’open source Home Assistant, les apps Netatmo, Shelly, autres application de constructeur, etc. La liste est longue comme un jour sans pain.

Peut-on admettre, parce qu’on a choisi un type d’appareil, d’accepter une adhérence qui oblige d’utiliser le Cloud et l’app du constructeur ?

Car cette captivité que cela crée vis-à-vis de ce constructeur, a des inconvénients majeurs :

  • Ergonomie : faut-il avoir n apps parce qu’on a choisi des capteurs et des actionneurs auprès de n constructeurs ?
  • Intégration : comment faire pour actionner un éclairage dans une technologie X, si le capteur de présence et de luminosité est dans une technologie Y, et que les deux Cloud et app ne se parlent pas ?
  • Pérennité : que se passera-t-il si un jour le constructeur ne maintient plus son Cloud / son app ? Le capteur et l’actionneur devront-ils partir à la poubelle et être remplacés ?

Je le rappelle, nous utilisons des standards, notamment de communication. En IoT, il y en a un qui est MQTT, et si capteurs et actionneurs s’en servent, peu importe le Cloud et l’app du constructeur, on pourra toujours utiliser capteur ou actionneur pendant des années, 5 à 10 en général, avant que l’électronique ne rende l’âme.

Autre standard à utiliser : l’hyperviseur. Nous avons jeté notre dévolu sur Home Assistant, qui permet de consolider quasi toutes les technologies de capteurs et d’actionneurs en une seule app : l’open source Home Assistant, pour lequel nous avons écrit un article dans notre Blog.

Notre rôle d’architecte : éviter les adhérences, maintenir les degrés de liberté

Notre travail consiste, en finalité, à rendre service aux entreprises avec les technologies. Pour que ce soit efficace, performant, pas cher et durable, nous déployons des principes éprouvés dans des centaines de contexte, et faisons ainsi bénéficier nos clients des apports des technologies. Eux n’ont pas cette connaissance et ni le temps ni l’intérêt de l’acquérir. C’est l’essence de notre métier.

Nous avons résolu ce problème de tour de Babel dans le smartbuilding en faisant le choix des standards, qui évitent les adhérences donc d’être emprisonnés dans l’univers technologique d’un constructeur, en sélectionnant les gagnants du marché sanctionnés par des centaines de millions d’utilisateurs, et en assemblant tout cela, depuis l’intention stratégique, jusqu’à la mise en oeuvre opérante sur site.