La prochaine vague d’IoT ne portera pas sur davantage d’appareils. Elle portera sur un contexte plus intelligent — et les référentiels MCP se trouvent au cœur de ce changement.

Model Context Protocol : le maillon manquant pour les plateformes IoT de nouvelle génération

Pourquoi l’IoT se heurte à un mur de contexte

Depuis dix ans, la croissance de l’IoT se mesure en chiffres bruts : plus de capteurs, plus de passerelles, plus de services cloud. Pourtant, la plupart des organisations admettent en privé que leur infrastructure « intelligente » repose encore sur des tableaux de bord fragiles, des intégrations manuelles et un patchwork de scripts.

Le problème n’est pas seulement la connectivité ou le stockage. C’est le contexte.

Un capteur de vibration connaît « 12,2 mm/s » mais pas si cette valeur est normale pour ce moteur.
Un compteur intelligent connaît « 3,8 kW » mais pas si cela fait partie d’un processus critique qui ne doit jamais être interrompu.
Un nœud trafic urbain connaît « comptage véhicules = 213 » mais pas qu’un match de football vient de se terminer à proximité.

Les plateformes IoT modernes se noient dans les données et manquent de contexte structuré, partageable et exploitable par des machines. C’est le fossé que le Model Context Protocol (MCP) est conçu pour combler.

MCP ne remplace pas votre pile IoT. Il fournit aux humains et aux modèles un langage commun et une manière disciplinée de dialoguer avec cette pile. Et le véritable pouvoir apparaît une fois que vous gérez ce langage via des référentiels MCP.

Bref rappel : qu’est‑ce que MCP, au juste

Sans jargon, Model Context Protocol est une façon de définir, exposer et récupérer le contexte pour des agents et applications intelligents :

Le contexte signifie : schémas, outils, connecteurs en direct, politiques, métadonnées, concepts métier — tout ce dont un modèle a besoin pour agir de façon sensée.
Il se concentre sur des interfaces structurées (outils, ressources, prompts, modèles) qui peuvent être cataloguées, versionnées et réutilisées.
Il fonctionne sur un protocole simple, indépendant du transport — ainsi des serveurs MCP peuvent être déployés à côté de vos appareils, passerelles ou API cloud.

Pensez à MCP comme faisant pour l’IoT piloté par des modèles ce qu’OPC UA a fait pour les appareils industriels : une grammaire partagée au lieu de centaines d’intégrations ad hoc.

Là où l’IoT historiquement reliait des appareils à des applications, MCP relie le contexte à l’intelligence.

Référentiels MCP : le nouveau plan de contrôle du contexte

Le protocole seul ne suffit pas. Le véritable principe organisateur est le référentiel MCP : un endroit où vos outils, schémas et ressources MCP sont définis, versionnés, audités et partagés.

Pour l’IoT, vous pouvez considérer un référentiel MCP comme :

Un catalogue de capacités : « lire vibration du moteur », « pousser une mise à jour de firmware », « simuler la consommation d’énergie ».
Une bibliothèque de modèles métier : jumeaux numériques, hiérarchies d’actifs, taxonomies d’alarmes, politiques edge.
Une clôture politique autour de qui ou quoi est autorisé à utiliser quelles capacités, avec quels paramètres.

Au lieu de disperser la logique dans des tableaux de bord, des fonctions serverless et des scripts de notebook, vous la regroupez progressivement dans des référentiels MCP où :

Les agents edge et cloud peuvent la découvrir par nom.
Les ingénieurs humains peuvent la lire, la revoir et l’améliorer.
Les équipes de gouvernance peuvent comprendre ce que « l’intelligence » est réellement autorisée à faire.

Pour les plateformes IoT de nouvelle génération, les référentiels MCP deviennent un nouveau type de plan de contrôle — moins axé sur les routes réseau, plus sur les opérations signifiantes.

Comment MCP s’intègre dans la pile IoT classique

Pour voir pourquoi cela compte, il est utile de superposer MCP aux couches IoT habituelles :

Couche des appareils
Capteurs, actionneurs, passerelles, automates programmables (PLC). Ils parlent fieldbus, Modbus, OPC UA, MQTT, LoRaWAN, Zigbee — choisissez.
Couche de périphérie
Serveurs on‑prem, PC industriels ou passerelles edge exécutant des charges conteneurisées, runtimes de fonctions ou analyses locales.
Couche cloud / données
Bases de séries temporelles, lacs de données, plateformes de streaming, moteurs de règles, plateformes de jumeau numérique, backends serverless.
Couche application & intelligence
Tableaux de bord, centres de contrôle, moteurs d’optimisation, modèles ML et, de plus en plus, des systèmes à base d’agents pilotés par de grands modèles.

MCP insère une couche d’interface de contexte entre (3) et (4) et s’étend vers (2) :

À la périphérie, des serveurs MCP encapsulent les API locales des appareils, les limites de sécurité et les contraintes spécifiques au site en tant qu’outils et ressources MCP.
Dans le cloud, des serveurs MCP encapsulent les magasins de données, les API de jumeau numérique, les systèmes de ticketing et les modèles de prévision.

Les agents, copilotes et services de plus haut niveau cessent de fouiller des bases brutes ou des API ad hoc et parlent plutôt à des outils définis par MCP tels que :

get_asset_status
predict_failure_risk
schedule_maintenance_window
apply_control_change (derrière des politiques strictes)

Ce niveau d’indirection est ce qui rend l’automatisation IoT à la fois plus sûre et plus facile à faire évoluer.

Des appareils au contexte : pourquoi MCP compte pour l’IoT

1. L’IoT a besoin d’une manière uniforme d’exposer les capacités

Actuellement, chaque plateforme IoT, et souvent chaque équipe, invente ses propres conventions :

Différents noms pour des concepts similaires (assetId vs equipment_id).
Différentes sémantiques d’erreur et unités.
Différents schémas d’authentification.

MCP favorise des outils uniformes et découvrables :

Chaque opération a un nom, un schéma JSON, des sémantiques claires.
Les outils et ressources peuvent être parcourus et documentés dans le référentiel.
Le même client MCP peut parler à de nombreux backends IoT différents, tant qu’ils exposent des interfaces conformes MCP.

Cela signifie qu’ajouter un nouveau parc éolien, un entrepôt ou une ligne d’assemblage ne nécessite pas un nouveau mode d’emploi pour vos agents ; vous étendez le référentiel MCP à la place.

2. Il rapproche les connaissances métier lisibles par un humain de la périphérie

L’IoT fonctionne non seulement sur les données, mais aussi sur les connaissances tacites :

« Cette ligne chauffe lorsque l’humidité dépasse 80 %. »
« Ne jamais redémarrer les deux pompes en même temps. »
« Ce capteur dérive après 18 mois. »

Les référentiels MCP peuvent contenir :

Des catalogues de règles et des arbres de décision.
Des notes de sécurité, des procédures opératoires standard (SOP), des parcours d’escalade.
Des explications, pas seulement des équations.

Ce contexte peut être mis à disposition sous forme de :

Ressources en lecture seule (bases de connaissances, documents SOP, descriptions d’actifs).
Outils qui codent des garde‑fous (par ex. vérifications de plages sûres, règles de séquençage).
Politiques indiquant quels outils nécessitent une approbation humaine ou une vérification en plusieurs étapes.

La périphérie cesse d’être un exécuteur aveugle de commandes et devient un négociateur conscient du contexte.

3. Il résout le problème du « plusieurs modèles, une usine »

À mesure que les organisations adoptent plusieurs modèles d’IA — prévision, détection d’anomalies, optimisation, modèles de langage — elles risquent de construire des univers parallèles de logique.

Les référentiels MCP permettent à tous les modèles de partager :

Les mêmes définitions d’actifs et taxonomies.
Les mêmes unités, conventions de nommage et états de santé.
Le même catalogue d’opérations pouvant provoquer des effets de bord.

Au lieu que plusieurs modèles apprennent les mêmes choses en dialectes légèrement différents, ils héritent d’un substrat conceptuel commun.

Schémas concrets : référentiels MCP dans les architectures IoT

Parcourons quelques modèles de référence qui reviennent dans les déploiements IoT de nouvelle génération.

Modèle 1 : périphérie consciente du jumeau numérique avec MCP

Imaginez une usine de fabrication avec une plateforme de jumeau numérique moderne dans le cloud et un contrôle sensible à la latence en périphérie.

Une architecture pratique :

Edge MCP Server
- Encapsule passerelles, proxys PLC, namespaces OPC UA.
- Connaît les IDs locaux d’actifs, canaux d’alarme, interdictions de sécurité.
- Expose des outils comme read_sensor, set_parameter, acknowledge_alarm.
Cloud MCP Server
- Encapsule les API de jumeau numérique, les données historiques, les systèmes de gestion de travail.
- Expose des outils comme get_asset_model, query_history, create_work_order.

Un référentiel MCP partagé contient :

Des schémas pour Asset, Sensor, Alarm, MaintenanceTask.
Des règles partagées sur les plages acceptables, les niveaux de criticité et les calendriers.
Des mappings entre les IDs locaux de l’usine et les IDs globaux du jumeau.

Les agents peuvent désormais :

Demander à la périphérie : « La Pompe‑4 fonctionne‑t‑elle actuellement dans l’enveloppe attendue ? »
Demander au cloud : « Étant donné l’historique de la Pompe‑4 et le modèle d’actif, quelle est sa probabilité de défaillance la semaine prochaine ? »
Déclencher : « Si risque > seuil et charge actuelle faible, créer une demande de maintenance via create_work_order. »

L’astuce est que les deux, périphérie et cloud, parlent le même langage conceptuel — celui encodé dans le référentiel MCP.

Modèle 2 : plateforme IoT industrielle multi‑locataires

Les fournisseurs de plateforme hébergeant des parcs d’usines ou de bâtiments font constamment face à une tension :

Chaque client veut une logique métier personnalisée.
La plateforme a besoin de briques communes pour rester maintenable.

Les référentiels MCP se prêtent naturellement à une conception en niveaux :

Un référentiel MCP global maintenu par la plateforme :
- Outils génériques : requêtes séries temporelles, onboarding d’appareils, routage d’alertes.
- Schémas standards pour la télémétrie, les alarmes et les KPI.
Référentiels spécifiques aux locataires :
- Vocabulaire métier, comme des taxonomies d’équipements personnalisées.
- Automatisations et workflows propres au site.
- Politiques d’approbation et chaînes d’escalade.

Les agents se connectant à l’environnement d’un locataire voient une vue fusionnée :

Fonctionnalités d’infrastructure communes en provenance du référentiel global.
Spécialisation du locataire depuis son propre référentiel.

Cette séparation permet de conserver :

Les mises à jour centralisées et contrôlées.
La personnalisation flexible et isolée.
La gouvernance explicite : qui possède quel contexte.

Modèle 3 : IoT à l’échelle d’une ville avec contexte fédéré

Les villes intelligentes sont un test de résistance pour l’interopérabilité : trafic, éclairage, énergie, eau, sécurité publique et services sociaux sous juridictions séparées.

Au lieu d’essayer d’entasser tout dans une plateforme monolithique, MCP encourage une approche fédérée :

Chaque département ou agence exécute son propre serveur MCP, faisant face à ses systèmes IoT.
Chacun maintient son propre référentiel MCP qui définit :
- Ses actifs (bus, postes électriques, clusters CCTV).
- Ses opérations (reroute_bus, dim_lights, rebalance_load).
- Ses zones de confidentialité et contraintes.
Un broker de contexte inter‑agences agit comme client MCP :
- Découvre les outils et schémas des départements.
- Négocie le partage de données et les permissions d’action.
- Orchestre des agents à l’échelle de la ville.

Lors d’un événement — par exemple une canicule :

Le référentiel MCP énergie connaît les contraintes du réseau.
Le référentiel MCP transport connaît les flux de navetteurs.
Le référentiel MCP santé publique connaît les quartiers vulnérables.

Les agents à l’échelle de la ville agissent en composant des outils MCP à travers les domaines, et non en grattant des API REST à moitié documentées.

_{Photo by Umberto on Unsplash}

À l’intérieur d’un référentiel MCP pour l’IoT

Que contient réellement un référentiel MCP orienté IoT ?

1. Définitions d’outils

Les outils sont les mains et les pieds de vos agents IoT.

Exemples :

get_timeseries
set_setpoint
restart_device
schedule_downtime
simulate_power_profile

Chaque outil inclut :

Un schéma JSON pour les entrées/sorties.
Des sémantiques explicites d’effets de bord.
Des classifications de sécurité optionnelles, comme « lecture seule », « modification réversible », « dangereux ».

Ce vocabulaire explicite est ce qui empêche l’automatisation intelligente de « simplement essayer des choses » en production.

2. Ressources de contexte

Ce sont vos réservoirs de connaissances en lecture seule :

Manuels d’équipement et SOP.
Schémas de câblage et P&ID (référencés via métadonnées ou liens).
Courbes de prix, tarifs des services publics et limites contractuelles.
Taxonomies d’actifs et graphes topologiques.

Elles permettent aux modèles de répondre à des questions comme :

« Quel est le temps de préchauffage recommandé pour cette turbine ? »
« Puis‑je brider ce refroidisseur sans violer les SLA ? »
« Quels capteurs sont en amont de cette alarme ? »

Sans ces ressources, les modèles continuent de réapprendre les règles métier de la manière la plus coûteuse.

3. Schémas métier et ontologies

L’IoT adore les schémas sur mesure. Les référentiels MCP encouragent la montée vers des modèles explicites et partagés :

Entités centrales : Asset, Location, TelemetryPoint, Alarm, WorkOrder.
Relations : « alimente », « commande », « est_sauvegarde_de ».
Machines d’état pour les cycles de vie : mise en service, exploitation, maintenance, mise hors service.

Avec cela en place :

Les agents comprennent que deux appareils différents partagent le même rôle.
Les analyses restent cohérentes entre usines et géographies.
Les migrations et changements de fournisseur deviennent moins pénibles.

4. Politiques et garde‑fous

Pour l’IoT, les garde‑fous ne sont pas une décoration optionnelle ; ce sont des équipements de survie.

Les référentiels MCP peuvent encoder :

Qui (ou quel agent) peut utiliser quels outils.
Quelles plages sont acceptables pour quels paramètres (par ex. limites de température par type d’actif).
Quelles actions nécessitent une approbation humaine ou des vérifications multi‑facteurs.
Quel niveau de journalisation est obligatoire pour chaque opération.

Cette couche politique transforme MCP d’une abstraction astucieuse en quelque chose en qui les équipes opérationnelles peuvent avoir confiance.

Préoccupations IoT : latence, fiabilité et sécurité

Dès que MCP rencontre la réalité industrielle, trois questions remontent à la surface.

MCP ajoute‑t‑il trop de latence ?

Les boucles de contrôle en temps réel à la périphérie doivent rester rapides et déterministes. La réponse est : ne pas router le contrôle dur en temps réel via MCP.

Au lieu de cela :

Gardez les boucles de rétroaction serrées à l’intérieur des PLC et des contrôleurs RTOS.
Utilisez MCP pour configurer et superviser ces éléments :
- Ajustement des paramètres.
- Changements de mode (manuel/automatique/maintenance).
- Mises à jour d’horaires et diagnostics.

Les agents n’ont pas besoin de réponses à la milliseconde pour décider s’ils doivent planifier une maintenance la semaine prochaine. MCP concerne la coordination, pas le motion control.

Et si le réseau ou le cloud tombe ?

MCP s’entend bien avec l’autonomie graduée :

Les serveurs MCP en périphérie peuvent mettre en cache localement politiques et schémas.
La logique critique peut résider entièrement en périphérie, les modèles cloud agissant en tant que conseillers lorsque disponibles.
Si le cloud disparaît, les agents se dégradent gracieusement vers :
- Des règles fixes.
- Des modèles entraînés localement.
- Des modes sûrs autonomes encodés dans le référentiel.

L’idée est de traiter les référentiels MCP comme source de vérité, pas comme un point unique de défaillance en temps d’exécution.

Comment MCP interagit‑il avec les normes de sécurité ?

Les environnements industriels vivent sous IEC 61508, ISO 13849 et un empilement d’exigences sectorielles. MCP est un bon ajustement parce que :

Il rend les intentions auditables :
- « Quels outils peuvent changer la vitesse de ligne ? » devient une requête, pas une chasse au trésor dans le code.
Il permet la segmentation :
- Les chemins critiques pour la sécurité peuvent être exposés en lecture seule aux agents généraux.
- Seuls des composants fortement validés ou des workflows avec humain dans la boucle peuvent invoquer des outils à fort impact.
Il supporte des contrats testables :
- Les définitions d’outils et les politiques peuvent être validées par rapport aux contraintes réglementaires.

Autrement dit, MCP ne certifie pas magiquement votre système, mais il facilite la collecte des preuves et réduit le rayon d’impact.

Construire une plateforme IoT alimentée par MCP : feuille de route pratique

Si vous avez déjà une pile IoT existante — réseaux d’appareils, historique, tableaux de bord, un peu de ML — comment évoluer vers MCP sans tout reconstruire ?

Étape 1 : encapsuler, pas remplacer

Commencez par des serveurs MCP qui encapsulent vos API existantes :
- Requêtes séries temporelles.
- Inventaire d’actifs.
- API d’alerte.
Choisissez un domaine restreint et significatif — par ex. systèmes d’air comprimé ou boucles d’eau glacée.

Exposez un premier jeu d’outils MCP :

get_telemetry(asset_id, metric, time_range)
list_alarms(asset_id, since)
get_asset_metadata(asset_id)

Donnez ensuite à un seul agent l’accès via MCP et observez combien l’orchestration devient plus simple.

Étape 2 : créez votre premier référentiel MCP

Alimentez‑le avec :

Schémas clairs pour Asset, TelemetryPoint, Alarm.
Documentation pour chaque outil, y compris les cas limites.
Un premier lot de ressources de contexte : SOP, notes de sécurité, contraintes opérationnelles.

Appliquez des pratiques de revue de code régulières au référentiel :

Pull requests.
Changelogs.
Petits bancs de tests.

C’est là que l’IoT rencontre la discipline de l’ingénierie logicielle.

Étape 3 : ajoutez une automatisation à forte valeur et faible risque

Cherchez un cas d’usage avec :

Une vraie valeur business.
Un rayon d’impact limité.
Des métriques de succès claires.

Exemples :

Maintenance suggestive : proposer des fenêtres de maintenance plutôt que de les exécuter.
Tri des alarmes : regrouper les alarmes liées et proposer des causes racines.
Optimisation énergétique : générer des propositions avant d’appliquer des consignes.

Reliez l’automatisation via des outils et politiques MCP de sorte que :

Toutes les actions puissent être expliquées avec des références aux ressources du référentiel.
Les marges de sécurité soient explicites et applicables.
Les opérateurs humains puissent interroger et affiner ce que fait l’automatisation.

Étape 4 : standardiser et étendre

Une fois le modèle éprouvé dans un coin, commencez à étendre :

Ajoutez des serveurs MCP à d’autres usines ou unités.
Refactorez progressivement la logique dupliquée des scripts et tableaux de bord dans le référentiel MCP partagé.
Faites évoluer des standards de schéma entre équipes.

Le but final n’est pas un monolithe global unique, mais un réseau de référentiels MCP qui partagent une ossature commune tout en permettant des nuances locales.

Écosystèmes de fournisseurs et MCP dans l’IoT

Les grands fournisseurs IoT et industriels gravitent autour d’idées similaires sous différentes étiquettes : « couches de données sémantiques », « jumeaux numériques », « APIs copilote d’automatisation ».

MCP apporte quelques avantages spécifiques à cet écosystème :

Il est centré sur les modèles : conçu dès le départ pour l’interaction avec des agents intelligents, pas seulement des tableaux de bord.
Il est ami des référentiels : tout est pensé pour être versionné et gouverné.
Il est orienté interopérabilité : il ne cherche pas à posséder toute la pile, seulement le pont de contexte.

Dans un scénario idéal :

Les passerelles seraient livrées avec des serveurs MCP optionnels exposant les capacités dans une forme standard.
Les plateformes IoT cloud fourniraient des adaptateurs MCP recouvrant leurs services de données et jumeaux.
Les éditeurs indépendants publieraient des outils et schémas compatibles MCP pour des workflows spécialisés (par ex. types de pompes spécifiques ou chimie de process).

Cet écosystème rendrait les intégrations IoT moins proches de la plomberie personnalisée et plus proches de l’assemblage avec un catalogue de composants bien compris.

Un modèle mental : MCP comme le « lexique d’opérations » de l’IoT

Il aide de garder une métaphore simple en tête.

Les plateformes IoT traditionnelles vous donnent :

Un annuaire (appareils et endpoints).
Un écouteur (flux de télémétrie).
Un central téléphonique (règles de routage et tableaux de bord).

Les référentiels MCP ajoutent :

Un lexique d’actions signifiantes (« redémarrer ce convoyeur dans ces conditions »).
Une grammaire des relations (« ce réservoir alimente ces réacteurs »).
Un système de normes (« ne dépassez jamais cette pression ; consignez toujours ce changement »).

Une fois que vous possédez ce lexique, vous pouvez inviter des modèles dans la conversation sans leur donner un accès brut et dangereux à chaque fil.

Ils négocient avec le lexique. Ils débattent des normes. Ils appellent les outils dont vous avez choisi la sémantique, pas ceux qui sont simplement présents.

C’est le changement discret mais décisif derrière MCP pour les plateformes IoT de nouvelle génération : passer de la simple collecte de données à la curation du contexte en tant qu’actif de première classe.

Et à mesure que prolifèrent agents, modèles et automatisations, ce contexte soigné — le corps vivant de vos référentiels MCP — pourrait s’avérer plus précieux que n’importe quel modèle individuel que vous y brancherez.

Liens externes

MCP: A New Layer for Interacting with IoT Data How MCP simplifies tool integration across cloud, edge, and real … MCP Integration and IoT Platform: The Conversational Revolution Unlocking Industrial IoT with Litmus MCP Server Bridging LLMs and IoT Systems Through Model Context Protocol