Si vous avez déjà construit un produit IoT de zéro, vous savez que le travail réside rarement dans l’appareil. L’appareil, c’est la partie facile. Le plus dur, c’est tout ce qui doit exister autour : les points d’ingestion, un stockage de séries temporelles capable de survivre à une année d’uplinks toutes les cinq secondes, des parsers de payload pour chaque version de firmware que vous avez livrée, des dashboards que vos clients regarderont vraiment, des règles d’alerte qui préviennent la bonne personne, des comptes utilisateurs, des accès basés sur les rôles, des portails en marque blanche, des journaux d’audit, la conformité régionale, et les dix cron jobs que personne n’a documentés.
Tout construire vous-même, c’est possible. Le maintenir pendant cinq ans sur une centaine de types d’appareils, c’est un autre sport. C’est là qu’une plateforme comme TagoIO prend tout son sens, et c’est là qu’une nouvelle pièce de la stack change la vitesse à laquelle un seul développeur peut avancer : le serveur MCP TagoIO, qui permet à Claude de communiquer directement avec votre compte IoT. Pour un aperçu rapide de ce que cela permet en pratique, consultez Développez vos solutions IoT plus vite avec Claude et le MCP TagoIO.
Le piège du “je vais le construire moi-même”
Tout responsable d’ingénierie IoT connaît cette conversation. La roadmap compte cinquante SKU connectés. Quelqu’un dessine une architecture : un cluster Kafka ici, du Postgres avec TimescaleDB là, Grafana pour les dashboards, Keycloak pour l’authentification, un petit service Node pour parser les payloads, un microservice d’alertes, une interface d’admin par-dessus, le tout assemblé avec Terraform.
Six mois plus tard, l’équipe appareils se dispute encore avec l’équipe plateforme pour comprendre pourquoi l’ingestion perd 0,4 % des paquets lors d’un basculement de région. Le service de dashboards en est à sa troisième réécriture. Personne ne peut répondre à la question “quelle était l’humidité moyenne dans l’entrepôt mardi dernier entre 14h et 16h ?” sans écrire du SQL. Les clients réclament une application mobile à leur marque. L’équipe conformité veut des preuves ISO 27001. Deux ingénieurs démissionnent.
La plateforme était censée être un moyen pour atteindre un but. Elle est devenue le produit.
Une plateforme IoT dédiée vous décharge de ce travail. Provisionnement des appareils, stockage mutable et immuable, parsers de payload, dashboards, actions, scripts d’analyse, portails en marque blanche, multi-région, RBAC, journaux d’audit, et les SDK pour communiquer avec tout cela arrivent comme un seul produit. Vous arrêtez de maintenir de l’infrastructure et vous commencez à livrer des fonctionnalités.
C’est la partie de l’histoire que la plupart des équipes IoT comprennent déjà. La nouveauté, c’est ce qui se passe quand vous posez un assistant IA par-dessus cette plateforme.
Ce qu’est réellement le MCP
Le Model Context Protocol (MCP) est un standard ouvert d’Anthropic qui permet à des assistants IA comme Claude de communiquer avec des systèmes externes via une interface d’outils définie. Au lieu de décrire votre compte IoT dans un long prompt, Claude appelle de vrais outils contre le vrai système : liste ces appareils, récupère ces données, crée cette action, écris ce script d’analyse.
Le serveur MCP TagoIO est un petit programme (ou un endpoint hébergé) qui expose votre compte TagoIO à Claude sous la forme d’un ensemble d’outils typés. Claude lit le catalogue d’outils, choisit le bon pour ce que vous avez demandé, remplit les paramètres et agit. Vous voyez le résultat dans le chat, et le changement apparaît dans votre console d’administration TagoIO.
L’effet concret : la plupart du travail opérationnel que vous faisiez auparavant en cliquant dans l’interface d’admin ou en écrivant des scripts ponctuels, vous le faites désormais en français courant depuis votre IDE.
Configuration en deux minutes
Le serveur MCP TagoIO existe en deux versions. Le serveur distant sur https://mcp.ai.tago.io ne nécessite aucune installation. L’option locale s’exécute via npx si vous le voulez sur votre machine. Les deux s’authentifient avec un Profile Token de votre compte TagoIO sur admin.tago.io/profile.
Pour Claude Code, une seule commande :
claude mcp add-json @tago-io/mcp '{"type":"http","url":"https://mcp.ai.tago.io","headers":{"Authorization":"Bearer YOUR-TAGOIO-TOKEN"}}'Pour Claude Desktop, ajoutez ceci à claude_desktop_config.json :
{
"mcpServers": {
"@tago-io/mcp": {
"command": "npx",
"args": [
"-y",
"mcp-remote",
"https://mcp.ai.tago.io",
"--header",
"Authorization: Bearer YOUR-TAGOIO-TOKEN"
]
}
}
}Redémarrez, et Claude peut désormais atteindre votre compte. Si vous êtes sur EU West ou sur une instance TagoIO dédiée, ajoutez un header x-tagoio-region avec eu-w1 ou l’URL complète de votre API.
Une remarque sur les tokens : le Profile Token accorde un accès complet au compte et c’est le bon choix pendant que vous explorez. Pour la production, passez à un Analysis Token rattaché à une Analysis dont la portée est restreinte. Même serveur MCP, rayon d’impact plus étroit.
Ce que le serveur MCP sait réellement faire
Le serveur actuel (v3) regroupe les outils en une poignée de services. La couverture est assez large pour que l’essentiel du travail quotidien y tienne.
Appareils. device-operations gère la recherche, la création, la mise à jour, la suppression et la configuration. Vous pouvez chercher par nom (la correspondance par wildcard est intégrée), par tag, par connecteur, par network, par état actif. device-data-operations exécute des requêtes avec agrégations : avg, sum, min, max, count, et conditionnelle. Le regroupement temporel va de la minute à l’année. device-delete-data supprime des données d’un appareil quand vous en avez besoin.
Actions. action-operations couvre le CRUD complet sur les Actions TagoIO, les règles qui se déclenchent quand un appareil envoie des données correspondant à une condition. Alertes par email, webhooks, déclencheurs d’analyse, tout y est.
Analysis. analysis-operations lit, écrit et met à jour les scripts Analysis (le code Node.js que TagoIO exécute côté serveur pour vous). Couplé à tagoio-code-search, Claude peut générer du code Analysis avec les bons appels au SDK TagoIO au lieu d’halluciner une forme d’API. tagoio-documentation-search consulte la documentation TagoIO à la demande.
Entities. entity-operations et entity-data travaillent avec les Entities TagoIO, la couche relationnelle pour les données qui ne sont pas des séries temporelles : fiches clients, hiérarchies d’actifs, tables de configuration.
Intégration, profil, utilisateurs RUN. integration-lookup trouve les connecteurs et les networks. profile-lookup et profile-metrics donnent l’état du compte et son utilisation. user-lookup travaille avec les utilisateurs TagoRUN pour les déploiements en marque blanche.
C’est assez de surface pour gérer une flotte, déboguer un appareil, construire une alerte, écrire un script côté serveur et vérifier la santé de votre compte, le tout depuis le même chat.
À quoi ça ressemble en pratique
Quelques exemples de ce qu’un ingénieur IoT peut désormais faire sans quitter son IDE.
Trouver un appareil défaillant.
“Montre-moi tous les appareils du connecteur warehouse-east qui n’ont pas envoyé de données depuis 24 heures et qui sont encore marqués comme actifs.”
Claude appelle device-operations avec operation: lookup, filtre par connecteur, puis vérifie last_input sur chacun. Vous récupérez la liste sous forme de tableau.
Extraire des données historiques sans écrire de SQL.
“Quelle a été la température moyenne et maximale de l’appareil Cold Storage 04 entre le 1er et le 15 novembre, regroupée par jour ?”
Claude appelle device-data-operations avec l’ID de l’appareil, la variable temperature, les agrégations avg et max, le bucket temporel day et la plage de dates. La réponse contient les chiffres. Si vous voulez un graphique, demandez-en un.
Provisionner un nouvel appareil avec un parser.
“Crée un nouvel appareil mutable nommé Boiler Sensor 12, tague-le region:north et type:boiler, attache le connecteur LoRaWAN que nous utilisons pour la ligne de chaudières, et configure le parser de payload pour décoder en base64 les quatre premiers octets comme température en dixièmes de degré.”
Claude résout le connecteur via integration-lookup, appelle device-operations avec operation: create, et écrit le parser directement.
Écrire un script Analysis qui prendrait normalement une heure.
“Écris un script Analysis qui s’exécute toutes les heures, examine chaque appareil tagué type:boiler, et si la pression moyenne sur la dernière heure dépasse 4,5 bar, envoie un email à l’équipe ops et crée une Action TagoIO avec l’appareil signalé comme at-risk.”
Claude récupère la forme du SDK via tagoio-code-search, rédige le script, et le crée via analysis-operations. Vous relisez le code dans le chat et vous le livrez.
Auditer avant une démo client.
“Liste toutes les Actions du compte, regroupe-les par type de déclencheur, et dis-moi lesquelles ne se sont pas déclenchées depuis 30 jours.”
action-operations en lookup, puis profile-metrics pour recouper l’activité. Cinq secondes de travail qui demandaient autrefois une revue manuelle de trente minutes.
Aucun de ces exemples n’est une démo. Ce sont les mêmes opérations que les équipes IoT font déjà chaque semaine, compressées de clics-et-onglets à une phrase.
Pourquoi la plateforme sous-jacente compte toujours
Le serveur MCP est impressionnant, mais il découle d’un point plus important : il fonctionne parce que TagoIO dispose déjà d’API typées pour chaque concept qui compte en IoT. Appareils, données, actions, analyses, entities, utilisateurs, connecteurs, networks. Le serveur MCP est une fine couche qui expose ces API à une IA. Si vous aviez construit votre propre plateforme, vous devriez maintenant aussi construire votre propre serveur MCP par-dessus vos propres services internes non documentés. C’est encore un trimestre de travail avant que l’IA ne vous aide en quoi que ce soit.
C’est le point à prendre au sérieux quand on planifie un produit IoT. La décision sur la plateforme fixe le plafond de la vitesse à laquelle tout le reste peut avancer, y compris l’outillage IA qui sera standard d’ici deux ans. Une base de données cloud généraliste plus une pile de microservices n’offre à un assistant IA aucun endroit propre où se brancher. Une plateforme IoT dédiée, si.
Vous n’avez pas besoin d’une IA pour justifier TagoIO. La plateforme IoT full-stack tient debout par elle-même : dashboards, RBAC, mobile, multi-région, le tout, simple à démarrer et abordable à grande échelle. Mais une fois que vous ajoutez Claude par-dessus via le MCP, le travail quotidien de pilotage d’une flotte cesse de ressembler à de l’ops et commence à ressembler à une conversation. C’est ça, le vrai changement.
Essayez-le
Si vous avez déjà un compte TagoIO, générer un token et connecter Claude prend environ deux minutes. Si vous n’en avez pas, l’offre gratuite suffit pour voir la boucle de bout en bout avec quelques appareils de test.
Le serveur MCP TagoIO est open source sur github.com/tago-io/mcp-server. La documentation couvre chaque IDE et outil IA qui prend en charge le MCP aujourd’hui : VS Code, Cursor, Windsurf, Claude Code, Claude Desktop, JetBrains, Gemini CLI, Amazon Q, OpenAI Agents, Warp, Kiro. Choisissez-en un, collez la configuration, pointez Claude vers votre flotte, et demandez-lui quelque chose que vous auriez normalement fait à la main.
Construisez le produit, pas la plateforme.
