> 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/fonctionnalites-dia/ai-penalty.md).

# Pénalité de l’IA

myCoreAI équilibre plusieurs objectifs concurrents à chaque cycle d’optimisation — confort des occupants, efficacité des équipements et coût d’exploitation. Chaque résultat indésirable entraîne une pénalité, et myCoreAI sélectionne le plan candidat avec la pénalité totale la plus faible sur l’horizon d’optimisation.

Cette page décrit comment ces priorités sont ordonnées.

## Comment fonctionne le système de pénalités

À chaque cycle, myCoreAI évalue de nombreux plans de consignes candidats sur un horizon de 72 heures, prévoit le résultat de chacun à l’aide du modèle du bâtiment, additionne les pénalités et sélectionne le plan au coût le plus faible. Seule la première heure est transmise au système de gestion technique du bâtiment (BMS) ; l’horizon restant garantit que la décision actuelle conduit à une trajectoire cohérente.

Les pénalités n’ont pas toutes le même poids, et plusieurs dépendent de la saison, de l’heure de la journée ou de l’occupation.

## Priorité 1 — Confort

Les pénalités de confort dominent. myCoreAI les pondère bien au-dessus de toute composante d’énergie ou de coût, de sorte qu’il accepte une consommation d’énergie plus élevée plutôt que de laisser le confort sortir des bornes de confort.

Les pénalités de confort couvrent :

* **Température intérieure** hors des bornes de confort
* **Niveaux de CO₂** au-dessus de la limite configurée

Pour les bâtiments dont des regroupements de capteurs sont configurés, myCoreAI évalue le confort par groupe (généralement un groupe par circuit de chauffage ou de refroidissement) plutôt que par capteur individuel.

## Priorité 2 — Comportement de l’unité de traitement d’air

Pour chaque unité de traitement d’air (AHU), myCoreAI choisit entre chauffage, refroidissement ou ventilation seule en fonction de la température extérieure et de la saison.

| Saison        | Rôle de l’AHU                                  | Pénalité                                                                                     |
| ------------- | ---------------------------------------------- | -------------------------------------------------------------------------------------------- |
| Hiver         | Chauffage via l’AHU                            | Élevée — déconseillé sauf si le confort l’exige ou **Chauffage avec ventilation** est activé |
| Été           | Refroidissement gratuit via l’AHU              | Faible — encouragé avant le refroidissement mécanique                                        |
| Toute l’année | Fonctionnement du ventilateur / de la pression | Faible constante — décourage une ventilation inutile                                         |

## Priorité 3 — Source de chauffage

myCoreAI attribue une faible pénalité aux circuits de chauffage primaires (généralement le chauffage urbain via les radiateurs) et une pénalité élevée au chauffage basé sur l’AHU. Ce classement produit la logique hivernale ci-dessus.

Un terme de lissage décourage les changements rapides d’heure en heure des consignes de chauffage. Le **Changement maximal du circuit de chauffage** paramètre dans les réglages IA limite la vitesse à laquelle les consignes peuvent évoluer.

## Priorité 4 — Source de refroidissement

Les sources de refroidissement portent de faibles pénalités, ordonnées selon le coût et l’impact environnemental : refroidissement gratuit via la ventilation, puis refroidissement urbain, puis refroidissement mécanique.

## Modulation du prix de l’énergie

Lorsque [myLoadshift](/myrspoven-docs/myrspoven-docs-fr/fonctionnalites-dia/loadshift.md) est actif, myCoreAI multiplie les pénalités liées à l’énergie par le prix spot variable dans le temps et déplace la consommation vers les heures les moins chères. Les pénalités de confort ne sont pas modulées par le prix.

## Mise en pratique

myCoreAI évalue chaque plan candidat sur :

1. Pénalités de confort — élevées, généralement nulles lorsque le confort est maintenu
2. Pénalités d’utilisation des équipements — modérées, dépendantes de la saison et de la température
3. Pénalités de lissage — faibles, maintiennent une exploitation stable
4. Pénalités liées au coût — faibles, favorisent l’énergie la moins chère lorsque les autres contraintes sont satisfaites

Le plan au coût total le plus faible est envoyé.

## Exemple concret

Un bureau chauffé par réseau de chaleur un après-midi doux de février : la température extérieure est de 6 °C, les capteurs intérieurs se situent au milieu de la plage, et le tarif dynamique du chauffage urbain chute fortement entre 13 h et 15 h. Avec myLoadshift actif, myCoreAI augmente légèrement l’alimentation des radiateurs pendant la fenêtre bon marché afin de précharger l’inertie thermique du bâtiment, puis laisse le système dériver pendant le pic de prix du début de soirée. Les pénalités de confort restent à zéro tout au long du processus. Ce mouvement est entièrement dicté par le terme de coût, limité par le plafond de lissage du circuit de chauffage.

## Interprétation d’un comportement inattendu

Lorsque les consignes semblent contre-intuitives — alimentation des radiateurs inchangée par temps doux, AHU fonctionnant plus chaud que prévu — une pénalité de priorité supérieure est généralement active : un capteur de confort proche de sa limite, ou le terme de lissage empêchant une baisse rapide.

Pour orienter myCoreAI vers des économies d’énergie plus agressives, ajustez les paramètres IA : élargissez les min/max adaptatifs, activez AI Freedom, ou augmentez les décalages hors heures ouvrées.


---

# 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/fonctionnalites-dia/ai-penalty.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.
