# Comment cadrer un projet IoT avant d'acheter le moindre matériel

> Une séquence d'étapes qui produit une note de cadrage IoT d'une page avant le premier bon de commande, et comment la valider sur la plateforme avec un appareil simulé.

![Comment cadrer un projet IoT avant d'acheter le moindre matériel](https://tago.io/og/fr/blog/scope-an-iot-project-before-buying-hardware.png)

Le premier réflexe dans un projet IoT est de commander un kit de développement et quelques capteurs. On a l'impression d'avancer, ça coûte peu, et l'équipe a enfin quelque chose à brancher. La plupart des projets démarrent là.

Le problème, c'est que le matériel acheté avant le cadrage décide à votre place. Un capteur LoRaWAN vous engage sur un réseau dont vous n'avez peut-être pas la couverture. Son firmware fige le format du payload et les variables auxquelles vous aurez droit. Son intervalle d'émission par défaut fixe l'autonomie de la batterie, le volume de données et l'allure de votre facture de plateforme pour les trois prochaines années. Le matériel tranche tous ces points d'un coup, et ce sont les choix les plus difficiles à défaire. Renvoyer un kit de développement est facile. Remplacer quatre cents capteurs déjà installés parce que la radio n'est pas la bonne, c'est repartir de zéro.

La parade tient en une séquence d'étapes qui produit une note de cadrage d'une page avant tout bon de commande, puis la valide sur la plateforme avec un appareil simulé. Le matériel vient en dernier, et à ce moment-là vous savez quoi commander.

![Cadrage d'abord, matériel en dernier : sept étapes de cadrage partent de la décision et de qui la prend, passent par les variables, les sites, le nombre d'appareils, les utilisateurs, les intégrations et les critères de recette, puis aboutissent à une note de cadrage d'une page que vous simulez sur un appareil, la commande de matériel n'arrivant qu'à la fin, avec un repère montrant que la plupart des équipes démarrent au contraire par la commande](https://tago.io/images/blog/scope-an-iot-project-before-buying-hardware/scope-first-hardware-last.svg)

## Étape 1 : nommez la décision que les données doivent changer

Tout projet IoT qui se rentabilise change une décision que quelqu'un prend aujourd'hui sans données. Écrivez-la en une phrase, avec un rôle nommé : "le responsable de site décide quelles chambres froides inspecter chaque matin", ou "le chef de maintenance décide quand remplacer les joints de pompe". Si la phrase a besoin du mot "insights", elle n'est pas terminée.

Cette étape commande toutes les suivantes. Une décision prise une fois par jour tolère un capteur qui émet toutes les heures. Une décision qui arrête une ligne de production se compte en secondes. Les équipes qui la sautent finissent avec un dashboard que personne n'ouvre.

## Étape 2 : listez les variables, les unités et l'intervalle d'émission

Partez de la décision et remontez jusqu'aux données minimales : quelles variables, dans quelles unités, à quel intervalle, avec quelle précision. Une température à 0,5 C toutes les 15 minutes, ce n'est ni le même capteur, ni le même budget batterie, ni le même volume de données qu'une température à 0,1 C chaque minute.

L'intervalle est le chiffre qui cache le coût. Un capteur qui émet chaque minute produit 60 fois plus de données qu'un capteur horaire, vide sa batterie en une fraction du temps et pousse un parc vers les paliers supérieurs de la tarification en entrée de données, chez n'importe quelle plateforme. Fixez l'intervalle d'après la décision de l'étape 1, pas d'après la valeur par défaut du capteur.

## Étape 3 : confrontez les sites à la réalité de la connectivité

Listez chaque site qui accueillera un appareil, puis répondez pour chacun : quelle radio l'atteint réellement ? Le LoRaWAN a besoin d'un gateway avec un vrai chemin jusqu'à l'emplacement du capteur, et les sous-sols, les coffrets métalliques et le béton dense amputent largement la portée annoncée sur la fiche technique. Le cellulaire a besoin de la couverture de l'opérateur à l'intérieur du bâtiment, pas dehors. Le Wi-Fi a besoin que la DSI du client dise oui, par écrit, pour un réseau que vous ne contrôlez pas.

Un test de couverture coûte une après-midi et un gateway emprunté. C'est en le sautant qu'un projet spécifié en LoRaWAN finit en cellulaire, à trois fois le coût unitaire. Lisez [Quelle portée le LoRaWAN atteint-il vraiment dans un déploiement réel ?](https://tago.io/blog/lorawan-range-in-the-real-world) avant de supposer un chiffre.

## Étape 4 : comptez les appareils au pilote et à trois ans

Deux chiffres honnêtes : combien d'appareils dans le pilote, et combien si le pilote réussit et se déploie sur trois ans. Le chiffre du pilote dimensionne votre première commande. Le chiffre à trois ans dimensionne tout le reste : quel modèle tarifaire tient debout, et quelles limites de plateforme vous atteindrez en premier (entrée de données, sortie de données, stockage, notifications).

Un modèle tarifaire bon marché à 30 appareils peut être le plus cher à 3 000. [Les modèles tarifaires des plateformes IoT comparés](https://tago.io/blog/iot-platform-pricing-models-compared) passe en revue les différentes formes. Notez le chiffre à trois ans même s'il reste approximatif : une estimation écrite se corrige, une estimation dans la tête de quelqu'un, non.

## Étape 5 : définissez qui sont les utilisateurs et ce qu'ils voient

Séparez ceux qui construisent l'application de ceux qui l'utilisent. Sur TagoIO, les premiers travaillent dans Admin : ils ajoutent des appareils, écrivent des Payload Parsers, montent des Dashboards, configurent des Actions. Les utilisateurs finaux, le responsable de site de l'étape 1, se connectent à un portail TagoRUN à votre marque, sur le web ou dans l'application mobile, et ne voient que ce que leur politique d'Access Management leur ouvre.

Pour chaque rôle, écrivez ce qu'il voit et ce qu'il peut faire : quels sites, quels dashboards, quelles alertes sur son téléphone, et s'il peut modifier les seuils ou seulement consulter. Si un rôle a besoin de notifications push sur le terrain, l'application mobile fait partie du périmètre dès le premier jour, ce qui change la façon de composer les dashboards.

## Étape 6 : listez les intégrations obligatoires

La plupart des projets IoT aboutissent dans un autre système. L'alerte doit devenir un ticket. Les totaux du jour doivent arriver dans l'ERP. Notez chaque intégration avec son sens (entrante ou sortante), son déclencheur (sur événement, sur planification) et son protocole (webhook, API REST, dépôt de fichier). Sur la plateforme, cela devient une Action qui poste vers un webhook, ou une Analysis planifiée qui appelle l'API externe.

Une intégration oubliée est la raison la plus fréquente pour laquelle un pilote abouti ne passe jamais en production : les données étaient bonnes, mais elles n'ont jamais atteint le système qui devait agir dessus.

## Étape 7 : écrivez les critères de recette du pilote

Avant le matériel, mettez-vous d'accord sur ce que veut dire "le pilote a marché". Le taux de livraison des données par appareil. La latence entre l'événement et la notification. La consommation de batterie face à l'autonomie prévue. Et la décision de l'étape 1, réellement prise depuis le dashboard, par la personne nommée, pendant un nombre de semaines fixé.

Des critères écrits maintenant ne coûtent rien. Des critères négociés après un pilote à moitié réussi coûtent cher, parce que chaque partie prenante se souvient d'une promesse différente. Mettez-les dans la note de cadrage, à côté du nom de la personne qui valide.

## Traduisez la note de cadrage en objets de la plateforme, puis simulez le premier appareil

Chaque ligne de la note de cadrage correspond à quelque chose que vous pouvez construire aujourd'hui sur la plateforme, sans un seul capteur en main :

- Les variables et les unités (étape 2) deviennent un Device avec des variables nommées. Son [Connector](https://docs.tago.io/docs/tagoio/devices/adding-devices-with-connectors) ou son Payload Parser décode le payload que le matériel candidat enverra.
- Les sites et la connectivité (étape 3) deviennent le Network de l'appareil et les tags qui regroupent les appareils par site.
- Les utilisateurs et leurs vues (étape 5) deviennent des Dashboards et une [politique d'Access Management](https://docs.tago.io/docs/tagoio/tagorun/access-management) qui ne montre à chaque utilisateur TagoRUN que ses propres sites.
- Les intégrations (étape 6) deviennent des [Actions](https://docs.tago.io/docs/tagoio/actions/defining-actions) avec une condition et une cible webhook, ou une Analysis planifiée.
- Les critères de recette (étape 7) deviennent les seuils d'alerte et les widgets sur lesquels vous jugerez le pilote.

Créez ensuite un appareil, reprenez le payload d'exemple de la fiche technique du capteur candidat, et postez-le via l'API à l'intervalle de l'étape 2. En une heure, vous avez un dashboard qui affiche les données de la décision, une alerte sur votre téléphone via l'application TagoRUN, et un webhook qui appelle un endpoint de test. Vous savez aussi si le payload transporte les variables dont vous avez besoin, si l'intervalle se lit bien sur un graphique, et si l'utilisateur final comprend l'écran.

Commandez le matériel maintenant. Vous achetez sur une spécification que l'équipe a vue fonctionner, et si le premier appareil réel contredit la simulation, vous l'apprenez dès le premier jour, et non au moment du déploiement.

## Ressources

- [Piloter un projet IoT sans profil technique](https://tago.io/blog/planning-an-iot-project-non-technical-pm)
- [Le vrai coût d'un déploiement IoT pour le marché intermédiaire](https://tago.io/blog/true-cost-of-a-mid-market-iot-deployment)
- [Quelle portée le LoRaWAN atteint-il vraiment dans un déploiement réel ?](https://tago.io/blog/lorawan-range-in-the-real-world)
- [Ajouter des Devices avec des Connectors](https://docs.tago.io/docs/tagoio/devices/adding-devices-with-connectors)

[llms.txt](https://tago.io/llms.txt)