Chez tous les fournisseurs, le schéma d’un déploiement IoT tient en trois cases : capteur, cloud, dashboard. Le schéma n’est pas faux. Sur une plateforme correcte, la plomberie est la partie facile.
Ce que le schéma rate, c’est le temps. Un déploiement réel est une suite d’étapes ingrates liées par un ordre de dépendances, et la plupart des équipes qui débutent les prennent à l’envers : le dashboard d’abord parce que c’est amusant, le matériel ensuite parce que c’est là que le projet devient concret, les utilisateurs en dernier parce que quelqu’un se souvient, une semaine avant la mise en production, que le personnel du client doit pouvoir se connecter. Chaque inversion coûte des semaines.
Voici un déploiement type, déroulé dans l’ordre : un intégrateur système installe des capteurs de température et d’ouverture de porte dans 40 chambres froides réparties sur 6 sites, pour un distributeur alimentaire. Remplacez les chambres froides par des cuves ou des compteurs, les phases ne changent pas.
Cadrage et critères d’acceptation (semaines 1 à 2)
“Nous voulons surveiller les chambres froides” est un souhait, pas un cadrage. Un déploiement a besoin d’une définition écrite de ce qui compte comme terminé. Ici : température toutes les 10 minutes, porte ouverte plus de 5 minutes signalée, alarme au-delà de 5 C pendant 20 minutes, notification push au responsable de site et e-mail au responsable des opérations, une page par site avec l’historique de chaque chambre.
Deux semaines paraissent longues pour un document. Le temps se passe à attendre : le responsable des opérations et le prestataire de maintenance ne sont pas d’accord sur qui traite les alarmes, et personne ne tranche avant que vous posiez la question par écrit. Sauter cette étape reporte ces deux semaines à la mise en production, où elles coûtent plus cher. Plus de détails dans le guide de planification pour chefs de projet non techniciens.
Visite technique et test de connectivité (semaines 2 à 3)
Une chambre froide est une boîte en métal avec une porte isolée. La radio n’aime pas ça. Avant de commander 40 capteurs, il faut savoir, chambre par chambre, si un gateway LoRaWAN placé dans le couloir atteint bien l’intérieur, porte fermée, et si ce gateway est alimenté et dispose d’une liaison réseau.
Une personne, deux capteurs de test, un gateway, une journée par site. La visite réécrit la liste de matériel : deux sites ont besoin d’un second gateway, un autre n’a aucun signal cellulaire dans le local technique. Le découvrir maintenant coûte une semaine ; le découvrir pendant la mise en service coûte un déplacement de plus par site. Les chiffres sont dans la portée réelle du LoRaWAN.
Approvisionnement du matériel (semaines 3 à 8) et configuration de la plateforme (semaines 3 à 5), en parallèle
Les capteurs et les gateways arrivent en quatre à six semaines. Les équipes qui débutent attendent. Les équipes expérimentées construisent toute la partie plateforme pendant ce délai, sans le moindre matériel sous la main. C’est le plus gros gain de planning du projet.
Sur TagoIO, l’ordre est le suivant :
- Créez un Device avec le Connector du modèle de capteur et le Network de l’opérateur LoRaWAN. Le Connector décode les octets du fabricant en température, état de porte et niveau de batterie.
- Passez un uplink d’exemple tiré de la fiche technique dans le Payload Parser et vérifiez qu’il produit bien les noms de variables que votre dashboard et vos alertes utiliseront. Les conversions d’unités et les renommages se font dans le Parser maintenant, une fois pour toutes.
- Fixez la convention de tags avant que quoi que ce soit d’autre existe : site, chambre,
asset_type, client. Dashboards, alertes, règles d’accès et rapports filtrent tous là-dessus. - Construisez un Blueprint Dashboard qui résout les Devices par tag. Un seul dashboard couvre les 40 chambres et toutes celles qui viendront. Envoyez des données simulées au Device de test pour que les widgets aient quelque chose à afficher.
Deux semaines pour un ingénieur. Quand le matériel arrive, la plateforme est terminée, pas commencée.
Mise en service du matériel et discipline des tags (semaines 8 à 10)
L’installation prend le temps qu’elle prend : un capteur par chambre, les gateways au mur, une étiquette sur tout. Six sites à deux jours chacun, cela fait deux semaines pour un installateur.
C’est côté plateforme que la discipline des tags paie. Pour chaque capteur, créez le Device depuis le même Connector, renseignez les tags de la chambre où il est posé, et vérifiez le premier uplink. La chambre 17 du site 3 apparaît sur le Blueprint Dashboard dès que son Device a les bons tags et un point de données. Personne ne construit de dashboard pendant la mise en service. Si quelqu’un le fait, c’est que la phase précédente a été sautée.
Tenez une fiche de mise en service : EUI de l’appareil, site, chambre, date d’installation, installateur. Quand un capteur se taira au troisième mois, cette fiche transformera un après-midi de recherche en cinq minutes de correction.
Alertes via les Actions, et qui les reçoit (semaine 10)
Les seuils viennent du cadrage ; la semaine passe à se mettre d’accord sur qui reçoit quoi. Créez des Actions déclenchées par la condition sur la variable (température au-dessus de la limite pendant la durée convenue, porte ouverte trop longtemps) qui envoient une notification push aux utilisateurs TagoRUN du site concerné et un e-mail au responsable des opérations. Une Action par type d’alarme, filtrée par tag, couvre toutes les chambres. Ajoutez aussi une Action “appareil muet depuis 2 heures” : une batterie vide est la panne la plus fréquente et elle ne produit aucune donnée, donc aucun seuil ne se déclenche jamais. Les premiers jours, envoyez tout vers vous-même.
Accès des utilisateurs finaux via TagoRUN (semaines 10 à 11)
Les responsables de site ne voient jamais l’Admin de TagoIO. Ils se connectent à un portail TagoRUN à la marque de l’intégrateur, sur le web et via l’application mobile TagoRUN pour que les notifications push arrivent sur leur téléphone. Une règle d’Access Management donne à chaque utilisateur le Blueprint Dashboard limité aux Devices dont le tag de site correspond au sien ; le responsable des opérations reçoit une règle qui couvre les six sites. Créez les utilisateurs une semaine avant la mise en production et faites le tour de l’application avec un responsable de site lors d’un appel. Ses questions deviennent la première page du manuel d’exploitation.
Mise en production et les deux premières semaines (semaines 11 à 13)
La mise en production, c’est un e-mail qui annonce que les alertes partent désormais chez le client. Puis les fausses alarmes commencent.
Tout déploiement en chambre froide donne les deux mêmes semaines : le seuil de 5 C se déclenche chaque fois qu’un chariot élévateur cale la porte pour un réassort, l’alarme de porte sonne pendant le nettoyage planifié, et une chambre est volontairement maintenue plus chaude parce qu’elle stocke des fruits et légumes. Rien de tout cela n’était prévisible depuis le document de cadrage. Les durées des Actions s’allongent, un créneau de nettoyage est exclu, la chambre 22 reçoit son propre seuil via un tag. Dites au client à l’avance que ces deux semaines servent aux réglages, sinon il prendra ce bruit pour une panne du système.
Remise à l’exploitation (semaine 13)
La remise, c’est un document et une réunion : le manuel d’exploitation (ce que veut dire chaque alarme, qui intervient, comment remplacer un capteur et re-taguer son Device), la fiche de mise en service, les seuils en vigueur, et un responsable nommé de chaque côté. Quand le projet est vendu en service géré, c’est ici que démarre l’abonnement mensuel et que s’arrête le budget projet.
Le troisième mois
Au troisième mois, le déploiement est devenu ennuyeux, et c’est le but. Puis arrivent les demandes non prévues.
Le volume de données devient une ligne de coût. Quarante capteurs toutes les 10 minutes, cela fait plus de 5 700 relevés par jour, et l’historique brut ne sert plus au-delà de quelques mois. La Data Retention réglée sur chaque Device plafonne ce volume.
Le client demande un rapport mensuel. Une Analysis planifiée calcule les minutes hors plage et les minutes de porte ouverte par site, puis écrit un résumé pour un widget ou un e-mail. Une journée de code, parce que les tags découpent déjà les données par site.
Le client veut deux sites de plus. L’extension, c’est une visite technique, du matériel, des Devices créés depuis le même Connector avec la nouvelle valeur de site, et des utilisateurs avec une règle pour ce site. Le dashboard, les Actions et le rapport fonctionnent déjà.
Treize semaines jusqu’à la remise, avec le travail sur la plateforme logé dans le délai de livraison du matériel et l’essentiel du calendrier passé à attendre les gens, la radio et les livraisons. Les trois cases n’ont jamais été le problème.
