La plupart des équipes démarrent une évaluation de plateforme IoT de façon raisonnable. Trois ou quatre candidats retenus, un tableur, et les exigences de chaque partie prenante : SSO et journaux d’audit, alertes et gestion du firmware, un modèle de coûts, un portail pour les clients. Cela a tout l’air d’un travail rigoureux, et pendant les deux premières semaines, c’en est un.
Puis le tableur atteint 80 lignes. Chaque fournisseur coche presque toutes les cases, parce que toute plateforme mature sait stocker de la télémétrie, tracer un graphique et envoyer une alerte. Les différences qui restent tiennent dans des lignes que personne ne peut noter sans avoir utilisé le produit, alors l’équipe programme d’autres démos. Trois mois plus tard, l’évaluation compte un modèle de notation pondérée, quatre présentations de fournisseurs, et aucun appareil qui envoie des données où que ce soit.
La complexité a deux origines, et aucune ne vient des fournisseurs. La première : évaluer des fonctionnalités que vous n’utiliserez pas la première année. La seconde : traiter la décision comme irréversible, ce qui donne l’impression que chaque ligne doit être juste. La plupart n’ont pas besoin de l’être. Seule une poignée d’éléments sera difficile à changer plus tard. Tout le reste relève de la configuration, et la configuration, c’est précisément l’objet d’un pilote.
Les signes que vous compliquez à l’excès
Quelques schémas reviennent dans presque toutes les évaluations à l’arrêt que j’ai vues chez des intégrateurs système et des équipes produit d’OEM.
- La liste d’exigences contient des lignes pour des fonctionnalités dont personne ne sait citer un usage dans les douze prochains mois. Les jumeaux numériques figurent dans le tableur alors que le parc réel se résume à 40 capteurs de température LoRaWAN dans un entrepôt.
- Chaque fournisseur obtient entre 82 et 91 pour cent. Quand l’écart est aussi faible, la notation mesure surtout la qualité de rédaction des fiches techniques.
- Personne dans l’équipe d’évaluation ne s’est connecté à l’un des candidats pendant plus d’une heure.
- Les mots “à l’épreuve du futur” apparaissent dans le document de justification et personne ne sait dire de quel avenir il faut se protéger.
- Un second tour de RFP est évoqué pour “clarifier les réponses” du premier.
- La date de début du pilote a déjà été repoussée au moins deux fois.
Si au moins deux de ces points vous parlent, le tableur ne vous aide plus.
Ce qui est vraiment irréversible
La bonne question pour chaque ligne n’est pas “la plateforme sait-elle faire cela” mais “si nous nous trompons, combien coûtera un changement d’avis dans deux ans ?” La plupart des lignes échouent à ce test. Les types de Widget, les canaux d’alerte, les formats de rapport, les rôles utilisateurs, la disposition des dashboards et l’intégration ERP se configurent et se reconfigurent aussi longtemps que vous utilisez la plateforme. S’y tromper au moment du choix coûte un après-midi plus tard.
Quelques décisions échappent à cette règle, et ce sont elles qui méritent le temps d’évaluation.
Propriété et export des données. Deux ans de télémétrie constituent l’actif le plus coûteux du projet, et pouvoir la récupérer en masse, dans un format exploitable, sans passer par un ticket de support, détermine la force de la position du fournisseur au moment du renouvellement. Vérifiez comment fonctionne l’export des données, si l’API donne un accès brut à tout, et où résident les données. L’article sur la dépendance fournisseur détaille ce qu’il faut tester.
Le comportement des prix au volume de la troisième année. Le prix à 50 appareils ne dit rien. Modélisez la facture au nombre d’appareils et au débit de messages attendus la troisième année, puis repérez quel compteur fait bouger le montant : appareils, points de données, stockage, utilisateurs, ou autre chose. Deux plateformes au même tarif aujourd’hui peuvent varier d’un facteur trois à grande échelle, et changer plus tard implique de migrer les données du paragraphe précédent. La comparaison des prix sur trois ans déroule le calcul.
Qui sont vos utilisateurs finaux. Si les personnes qui consultent les données sont votre propre équipe d’exploitation, la console Admin suffit. S’il s’agit de clients, de locataires ou de techniciens de terrain qui ne doivent jamais voir les sites des autres, la plateforme doit leur présenter un portail à votre marque avec des règles d’accès par utilisateur. C’est de l’architecture, pas de la cosmétique. Sur TagoIO, cette couche s’appelle TagoRUN, avec les politiques d’Access Management ; la construire vous-même après coup est un projet, pas un réglage.
Les appareils et les réseaux que vous avez réellement. Pas ceux que vous ajouterez peut-être en 2028. Si le parc passe par un serveur réseau LoRaWAN précis, des appareils cellulaires qui parlent MQTT ou un ancien gateway Modbus, la plateforme doit décoder ces payloads aujourd’hui.
La surface d’intégration. Votre propre code peut-il tourner dans la plateforme quand une règle dépasse ce qu’un menu permet, et les systèmes externes peuvent-ils dialoguer avec elle dans les deux sens via une API documentée ? C’est la différence entre une plateforme que vous étendez et une plateforme que vous contournez.
La liste s’arrête là. Si un candidat passe, les lignes restantes sont de la configuration que vous vérifierez pendant le pilote, et la configuration n’est pas une raison de laisser l’évaluation ouverte.
Remplacez le tableur par un pilote de deux semaines
Le tableur répond aux questions par la lecture. Le pilote y répond par la pratique, et la pratique va plus vite une fois tranchées les questions difficiles à inverser. Le format qui marche est restreint et borné dans le temps : un cas d’usage qui compte pour l’entreprise, dix à vingt appareils réels de votre parc, un site, un type d’utilisateur, et une date de fin fixée deux semaines plus tard. Écrivez avant de commencer ce que veut dire “ça a marché” : des appareils décodés qui envoient des données, un dashboard que l’utilisateur visé sait lire, une alerte qui se déclenche sur une condition réelle, un export des données collectées que votre équipe peut ouvrir.
Sur TagoIO, ces deux semaines ressemblent souvent à ceci. Jours un et deux : ajouter les appareils via un Connector adapté à votre réseau, ou écrire un Payload Parser si l’appareil n’est pas dans la liste. Jours trois à cinq : construire le dashboard avec les Widgets standards, puis le convertir en Blueprint Dashboard pour qu’une seule disposition serve tous les appareils. Deuxième semaine : une Action qui envoie l’alerte, un script Analysis si la logique demande plus qu’un seuil, et un utilisateur TagoRUN qui se connecte pour ne voir que ses propres données. Le dernier jour, exportez les données et lisez la facture.
Ce que vous apprenez en deux semaines, le tableur ne pouvait pas vous le dire : le temps qu’il faut vraiment pour décoder un nouvel appareil, si l’utilisateur visé comprend le dashboard sans formation, si les compteurs de facturation évoluent comme vous l’avez modélisé, et comment la plateforme réagit quand votre code Analysis lève une erreur à 2 h du matin. Le guide d’achat rassemble les questions à poser aux fournisseurs avant cette étape ; le pilote, c’est le moment où vous cessez de demander et où vous vérifiez.
Quand la bonne réponse est un petit essai, pas un nouveau RFP
Certaines variantes de cette décision n’exigent aucun processus d’achat. Si vous êtes un intégrateur système qui choisit une plateforme pour votre propre activité de services, ou une équipe produit avec quelques centaines d’appareils la première année, un mauvais choix coûte une migration réalisable en un trimestre. Dans ce cas, le poste le plus coûteux de la décision est le temps passé à la prendre.
Un compte gratuit ou d’entrée de gamme chez deux candidats, les dix mêmes appareils connectés aux deux, et deux semaines d’usage réel donneront une réponse plus nette qu’un troisième tour de questionnaires fournisseurs. Construire sur AWS IoT Core ou sur une pile open source reste une réponse légitime pour certaines équipes, et le même test s’applique : connectez les appareils et comptez les semaines jusqu’à un dashboard qui fonctionne.
Décidez ensuite, et notez pourquoi. Les raisons qui compteront dans deux ans sont celles qui sont difficiles à inverser. Tout le reste, vous le changerez au moins deux fois de toute façon.
