Demandez aujourd’hui à n’importe quel éditeur IoT s’il prend en charge les assistants IA et la réponse sera un oui assuré. AWS vous renvoie vers Amazon Q et Bedrock. Oracle vous renvoie vers sa OCI IoT Platform. ThingsBoard, Telit et Losant ont chacun une page IA à deux clics de leur page d’accueil. Sur le papier, la question est tranchée.
Mais “prend en charge les intégrations d’assistants IA” va d’un assistant qui vit déjà dans le produit et lit vos vrais appareils, à un tutoriel qui commence par provisionner des fonctions cloud et se termine trois services plus loin. La distance entre ces deux réponses se compte en semaines d’ingénierie, et l’expression qui masque cette distance est “nativement”.
La façon honnête de répondre consiste à définir l’expression d’abord, puis à soumettre chaque plateforme, la nôtre comprise, à la même définition.
Ce que “nativement” devrait vouloir dire
L’expression mérite son nom quand trois choses sont vraies.
Sans code. Vous ne devriez pas avoir à écrire une fonction d’intégration, un gestionnaire de webhook ni un parseur avant que l’assistant voie des données d’appareils. Configurer, oui. Programmer, non.
Sans middleware. Il n’y a rien de plus à héberger ni à surveiller. L’assistant est soit intégré à la plateforme, soit raccordé par une interface que l’éditeur livre, documente et maintient à jour.
Avec permissions. L’assistant opère dans votre modèle d’accès existant. Il démarre avec le moindre accès qui le rende utile, demande avant de modifier quoi que ce soit, et laisse une trace auditable. Un assistant doté d’un accès en écriture silencieux sur des appareils de production n’est pas une fonctionnalité. C’est un rapport d’incident qui attend son horodatage.
Confrontez ce test au marché et l’image se précise vite.
Trois catégories d’“intégration d’assistant IA”
Presque toutes les affirmations que vous lirez tombent dans l’une de trois cases. Elles ne se valent pas, mais chacune est la bonne réponse pour certaines équipes.
1. Serveur MCP maison
Le Model Context Protocol (MCP) est un standard ouvert pour relier des assistants IA à des outils et des données externes. Quand une plateforme livre son propre serveur MCP, tout assistant compatible MCP peut se connecter à votre compte et travailler avec vos données via ce standard. Aucun projet d’intégration sur mesure n’est requis.
La mise en place relève de la configuration et non de la programmation, et l’accès suit les identifiants que vous fournissez : cette catégorie passe donc le test. Oracle a publié un serveur MCP pour sa OCI IoT Platform, et ThingsBoard en maintient un exposant appareils, télémétrie et administration. TagoIO se situe ici aussi. Si l’une de ces plateformes figure sur votre liste, le serveur MCP est la fonctionnalité à évaluer, pas la page marketing IA.
La contrepartie est que vous vous engagez sur le standard ouvert que la plateforme prend en charge, et il faut confirmer ce que le serveur est réellement autorisé à lire et à faire en votre nom.
2. API REST ouverte que vous raccordez vous-même
Beaucoup de plateformes exposent une API REST documentée et rien de spécifique à l’IA par-dessus. AWS possède la boîte à outils IA la plus profonde du secteur : les agents Bedrock atteignent les données IoT, Amazon Q raisonne sur vos ressources cloud, et AWS IoT SiteWise inclut un assistant pour les données industrielles. Ce qu’AWS ne livre pas, c’est un chemin déjà raccordé entre un assistant généraliste et votre parc. Ce chemin, vous l’assemblez : rôles IAM, définitions d’agents, sources de données et la colle entre les deux. Une installation ThingsBoard auto-hébergée sans son serveur MCP aboutit au même endroit.
Cela fonctionne, et pour une entreprise dotée de profils cloud en interne les résultats peuvent être excellents. Vous décidez du périmètre, de l’authentification et du comportement. Cela échoue tout de même au test du sans code, précisément parce que c’est un projet. Quelqu’un doit écrire l’enveloppe, la maintenir quand l’API change, et porter la sécurité des identifiants qu’elle détient. Pour une équipe qui a les bonnes personnes, cette propriété est un atout, pas un fardeau.
3. De l’IA qui n’est pas un assistant conversationnel
La troisième catégorie récolte le plus de marketing et le moins d’examen, et elle se scinde en deux.
Un chatbot intégré vit dans l’interface de la plateforme. Il répond à des questions, résume un dashboard, rédige parfois une requête, tout cela à l’intérieur de ce seul écran. Pour des utilisateurs non techniques, cela peut être réellement utile. La limite est structurelle : vos outils externes ne peuvent pas atteindre cet assistant.
L’autre forme, c’est de l’IA investie ailleurs. La gamme deviceWISE AI de Telit se concentre sur l’intelligence en périphérie et la vision industrielle, ce qui règle un vrai problème mais n’est pas un assistant conversationnel sur votre compte. La voie de Losant passe par son moteur de workflows, où vous branchez des appels à des services d’IA dans des flux que vous concevez. C’est souple, et il est juste de parler de prise en charge de l’IA. C’est aussi une intégration que vous construisez.
Rien de tout cela n’est un reproche à ces plateformes. C’est un rappel : “IA” sur une liste de fonctionnalités peut désigner un assistant conversationnel, de l’inférence en périphérie ou de la plomberie de workflows, et l’étiquette seule ne dira pas laquelle vous achetez.
Comparaison des approches
| Serveur MCP maison | API REST ouverte | Chatbot intégré ou IA en périphérie | |
|---|---|---|---|
| Accès d’un assistant externe | Oui, via un standard ouvert | Oui, après l’avoir construit | Non |
| Effort de construction | Aucun pour la connexion | Colle maison ou enveloppe maison | Aucun |
| Qui restreint les identifiants | La plateforme, par conception | Vous | Sans objet |
| Idéal pour | Les équipes qui veulent un accès IA externe tout de suite | Les équipes de développement qui veulent le contrôle total | Les utilisateurs dans l’interface, ou l’inférence en périphérie |
| Risque principal | Confirmer ce que le serveur peut lire et faire | La maintenance et les identifiants restent à votre charge | Ne sort pas du dashboard |
| Exemple | TagoIO, Oracle OCI, ThingsBoard | AWS IoT Core, piles auto-hébergées | Telit deviceWISE AI, workflows Losant |
Aucune n’est un piège. Un chatbot intégré convient si vos utilisateurs vivent dans le dashboard. Une API que vous raccordez convient si vous avez des développeurs et voulez le contrôle. Un serveur MCP maison est le chemin le plus court vers un accès externe fondé sur un standard. L’erreur est d’acheter l’un en croyant avoir acheté l’autre.
TagoIO voie une : TagoAI, déjà dans l’Admin
TagoIO livre deux voies, pensées pour deux situations différentes.
La première est TagoAI, un assistant intégré à l’Admin TagoIO derrière l’icône en étoile de la barre latérale. Il tient compte du contexte : ouvrez-le depuis une page Analysis ou Dashboard et il sait déjà ce qu’il regarde. Il répond à des questions d’architecture ancrées dans la documentation officielle, inspecte et modifie Devices, Dashboards, Actions et scripts Analysis, génère du code Analysis calé sur vos appareils et formats de données réels, débogue les scripts qui déraillent, et exécute des analyses de données sur votre parc. Il n’y a rien à installer ni à héberger, et c’est précisément ce que devrait signifier intégré.
Le modèle de permissions est la partie à lire deux fois. TagoAI démarre chaque session en lecture seule. Vous élevez sa permission par session quand vous voulez des modifications, il ne modifie jamais rien en silence, il ne peut pas dépasser les permissions de votre propre compte, et chacune de ses actions est consignée dans l’Audit Log. C’est le troisième test, réussi par conception plutôt que par document de politique.
La confidentialité reçoit le même traitement. Les fournisseurs d’IA par défaut opèrent sous des accords qui interdisent l’entraînement sur vos données. Si votre équipe conformité veut davantage de contrôle, vous pouvez apporter votre propre fournisseur : OpenAI, Anthropic, AWS Bedrock, Google Gemini et OpenRouter sont pris en charge, vos clés étant stockées chiffrées dans TagoIO Secrets. Utiliser votre fournisseur supprime aussi la limite mensuelle de prompts. La fonctionnalité peut être désactivée par profil et arrive désactivée par défaut dans la région Union européenne. Le tableau complet sur l’ancrage, les permissions et le choix du fournisseur va plus loin que ce panorama.
Pour le voir tourner sur un vrai compte plutôt que sur une diapositive, le webinaire enregistré AI Meets IoT: A Practical Experience with TagoAI déroule des sessions en direct, y compris les demandes de permission.
TagoIO voie deux : un serveur MCP pour l’assistant que vous utilisez déjà
Beaucoup d’équipes vivent déjà dans Claude ou un autre assistant compatible MCP et n’ont aucune envie de changer de fenêtre. Pour elles, TagoIO publie un serveur MCP officiel, open source sur GitHub, qui relie un assistant externe à votre compte : appareils, données, scripts Analysis et dashboards, le tout via un token que vous restreignez et contrôlez. Il fonctionne avec Claude, ChatGPT, Cursor et Windsurf, et la version 3.0.0 a ajouté la prise en charge HTTP distante, le serveur n’a donc pas à tourner sur votre propre machine.
Les deux voies se complètent, elles ne se concurrencent pas. TagoAI est l’assistant dans l’Admin, conscient de la page où vous êtes. Le serveur MCP amène votre compte TagoIO vers l’assistant auquel votre équipe fait déjà confiance. L’un comme l’autre passe les trois tests, et la plupart des comptes finissent par utiliser les deux.
Une liste de questions à emporter en rendez-vous éditeur
Le marketing des éditeurs ne tracera pas ces distinctions pour vous : apportez vos propres questions.
- Un assistant externe peut-il atteindre mes données ? C’est le premier tri. Si la réponse est “seulement dans notre dashboard”, vous êtes en catégorie trois. Cela peut convenir, mais au moins vous le savez.
- Via quel standard ? Un standard ouvert comme MCP signifie que vos assistants actuels se connectent sans travail spécifique. Une intégration propriétaire vous lie à une relation éditeur.
- L’assistant démarre-t-il en lecture seule, et qu’est-ce qui élève sa permission ? Un accès en lecture à la télémétrie est très différent de la possibilité de créer des scripts, modifier des dashboards ou déclencher des actions. Demandez la liste exacte.
- Où ses actions sont-elles journalisées ? Une piste d’audit fait la différence entre un outil que vous pouvez déployer et un outil que la sécurité refusera.
- Quel modèle d’IA voit vos données, sous quel accord, et pouvez-vous apporter votre propre fournisseur ? Demandez aussi si l’ensemble peut être coupé pour un profil qui ne doit pas y avoir droit.
- Tourne-t-il à distance ou seulement sur ma machine ? Un serveur qui exige un processus local est plus difficile à exploiter en équipe.
Un éditeur doté d’une vraie prise en charge native répond à cela dans sa documentation. Un éditeur doté d’une page marketing y répond dans une proposition de services.
Un court guide de décision par profil d’acheteur
Équipe non technique. Si vos équipes travaillent dans la plateforme et en sortent rarement, un assistant intégré peut suffire sans aucune mise en place. Si vous voulez aussi des réponses depuis l’assistant que vous utilisez ailleurs, cherchez un serveur MCP maison.
Équipe de développement. Si vous avez des développeurs et tenez à contrôler exactement ce qu’un assistant peut faire, les deux voies conviennent, le serveur MCP maison comme l’API que vous raccordez. Prenez le MCP maison pour économiser la construction ; prenez l’API quand vous avez besoin d’un contrôle que le serveur standard ne donne pas, ou quand votre plateforme n’offre aucun serveur MCP.
Intégrateur ou constructeur de solutions. Si vous livrez des solutions IoT à des clients, un serveur MCP maison permet de donner un accès IA à chaque client sans écrire une intégration par projet. Une API ouverte reste importante comme socle, mais c’est la connexion standardisée qui passe à l’échelle entre comptes.
Ce que devient le panorama
Oracle et ThingsBoard prennent en charge nativement les assistants externes via des serveurs MCP. AWS prend en charge à peu près tout, à condition que vous le construisiez. Telit et Losant ont mis leur investissement IA dans l’inférence en périphérie et l’outillage de workflows plutôt que dans des assistants conversationnels. TagoIO livre les deux moitiés : TagoAI intégré à l’Admin, et un serveur MCP open source pour les assistants externes, avec la même discipline de permissions de chaque côté.
Si l’expression générique “intégration d’assistant IA” vous a amené ici, le test à retenir est : sans code, sans middleware, avec permissions. Appliquez-le à nous aussi : commencez gratuitement et appuyez sur l’icône en étoile, ou réservez une démo si vous préférez le voir piloté d’abord.
Ressources
- Qu’est-ce que le Model Context Protocol (MCP) pour l’IoT, l’explication du standard derrière les intégrations natives
- Comment connecter Claude via MCP, un pas à pas
- Comment interroger des données d’appareils IoT en direct avec un assistant IA, le parcours TagoAI
- Documentation MCP de TagoIO
- Tarifs TagoIO
