> For the complete documentation index, see [llms.txt](https://docs.myrspoven.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.myrspoven.com/myrspoven-docs/myrspoven-docs-fr/integrations/overview.md).

# Aperçu

myCoreAI fonctionne à partir des données opérationnelles des bâtiments et des données de fournisseurs externes. Les intégrations transmettent ces valeurs à Myrspoven et, lorsque le système connecté prend en charge le contrôle, renvoient de nouvelles valeurs de consigne au bâtiment.

Ce chapitre couvre les options d’intégration disponibles et les exigences du côté du bâtiment.

**Exploitation technique :** confirmer quels signaux myCoreAI doit lire et, le cas échéant, quelles consignes il peut écrire.\
**Intégrateurs :** définir le périmètre de l’API, du protocole, du composant edge, de l’accès réseau et de la passation de mise en service.\
**Gestionnaires d’actifs :** comprendre quelles sources de données sont utilisées et comment les données d’énergie, de capteurs, IoT et météorologiques sont ingérées.

## Modèles d’intégration

Les intégrations Myrspoven utilisent deux modèles principaux.

### Myrspoven s’intègre à des API externes

Dans ce modèle, Myrspoven est responsable de l’écriture et de la maintenance du code d’intégration. myCoreAI se connecte au système externe, lit les valeurs configurées et écrit de nouvelles valeurs de consigne en retour lorsque le système connecté prend en charge le contrôle.

Les intégrations BMS et SCADA prises en charge comprennent des connecteurs de plateforme dédiés et des intégrations basées sur des protocoles :

* **Web Port**
* **Siemens Building X**
* **Ouman**
* **Fidelix Analytics**
* **ProptechOS**

Ces intégrations prennent en charge à la fois la lecture des données BMS et l’écriture de nouvelles valeurs de consigne.

Les plateformes nommées ne constituent pas la limite complète de ce qui peut être connecté. Web Port est une couche passerelle avec prise en charge de pilotes pour de nombreux protocoles de terrain et types d’appareils, ce qui permet à Myrspoven de s’intégrer à une gamme plus large de configurations locales BMS et d’automatisation que ne le suggère la seule liste des fournisseurs. Voir [Prise en charge des pilotes Web Port](https://kiona.com/products/web-port/driver-support) et [Web Port](/myrspoven-docs/myrspoven-docs-fr/integrations/overview/bms-integrations/web-port.md).

Myrspoven prend également en charge des intégrations plus petites en lecture seule pour les données de capteurs, IoT, d’énergie, météorologiques et environnementales :

* **Yggio**
* **EcoGuard**
* **PropEye**
* **Mestro**
* **Metry**
* **Radonova**
* **OpenMeteo**
* **AirThings**

La plupart des intégrations de ce modèle sont basées sur HTTP/REST. Myrspoven prend également en charge des intégrations basées sur MQTT lorsque cela convient mieux au système externe.

### Des fournisseurs externes s’intègrent à Myrspoven

Dans ce modèle, le fournisseur externe est responsable de l’envoi des valeurs à Myrspoven. Le fournisseur utilise l’API IA Myrspoven pour envoyer des valeurs depuis un BMS ou un autre fournisseur de données, et pour récupérer de nouvelles valeurs de consigne lorsqu’elles sont disponibles.

Ce modèle est utilisé lorsque la partie externe possède la connexion au BMS ou à la plateforme de données et peut exposer les valeurs requises via l’API IA Myrspoven.

En pratique, Myrspoven peut intégrer des bâtiments via :

* Des intégrations dédiées de fournisseurs, telles que Siemens et Schneider.
* Des intégrations basées sur des protocoles via Web Port et son écosystème de pilotes.
* Des partenaires externes qui fournissent des données et des consignes via l’API IA Myrspoven.

## Sommaire

* [**Intégrations BMS**](/myrspoven-docs/myrspoven-docs-fr/integrations/overview/bms-integrations.md) — intégrations BMS et SCADA, périmètre lecture/écriture, couverture des protocoles et exigences de connexion.
* [**Données d’énergie**](/myrspoven-docs/myrspoven-docs-fr/integrations/overview/energy-data.md) — options pour ingérer les données de consommation, y compris la récupération depuis le BMS, Mestro, Metry et le téléversement manuel. Une résolution plus élevée améliore les résultats d’optimisation.
* [**API tierces**](/myrspoven-docs/myrspoven-docs-fr/integrations/api.md) — API de fournisseurs et de plateformes utilisées pour l’ingestion de données et la récupération des consignes.

## Exigences côté bâtiment

Les exigences dépendent du modèle d’intégration et de la source de données. Un projet typique peut nécessiter :

* Un accès à l’API externe, au BMS, au système SCADA ou au fournisseur de données qui détient les valeurs requises.
* Un accès en lecture et en écriture au BMS lorsque myCoreAI est configuré pour optimiser et contrôler les consignes.
* Des identifiants d’API ou une méthode d’authentification convenue pour les fournisseurs tiers en lecture seule.
* Un serveur virtuel dans le réseau du bâtiment lorsqu’un composant edge sur site est utilisé.
* Un accès réseau sortant depuis ce serveur vers le cloud Myrspoven. L’edge ne nécessite aucune ouverture de pare-feu entrante.
* Un point de contact technique pour la mise en service et le mappage des signaux.

La liste des signaux, la propriété des données et le périmètre des consignes sont convenus lors d’une étude technique et ne changent pas sans configuration explicite.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.myrspoven.com/myrspoven-docs/myrspoven-docs-fr/integrations/overview.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
