> For the complete documentation index, see [llms.txt](https://docs.kiloiot.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.kiloiot.io/kilo-docs-fr/kilo-iot-server/rules-engine.md).
# Moteur de règles
Moteur de règles BPMN visuel — transformez les données des capteurs en alarmes, actions et enrichissements avec une compilation et un retour arrière sécurisés.
Le moteur de règles est un système d’automatisation visuelle basé sur BPMN (Business Process Model and Notation) pour surveiller les appareils IoT en temps réel. Lorsque les données des capteurs répondent aux conditions que vous définissez, le moteur agit automatiquement — en déclenchant des alarmes, en enrichissant les données provenant d’autres capteurs avant de prendre une décision, et **en envoyant des commandes directement vers vos appareils**.
Cette dernière capacité change ce que signifie l’automatisation ici. Une règle ne se contente plus d’alerter une personne pour qu’elle agisse — elle peut effectuer l’action elle-même, dès qu’une condition est remplie. Un capteur de fuite déclenchait autrefois une alarme et une course vers la vanne d’arrêt ; maintenant, la même règle ferme automatiquement la vanne et déclenche l’alarme lors de la même évaluation. Détecter, décider, agir — de bout en bout, sans intervention humaine. Voir [Exécution de commandes sur les appareils](/kilo-docs-fr/kilo-iot-server/rules-engine/running-device-commands.md).
## Fonctionnement
Les règles sont des workflows BPMN 2.0 : des organigrammes visuels où chaque nœud effectue une tâche spécifique. Vous reliez les nœuds avec des flux (flèches) pour construire la logique. Le moteur exécute une règle déployée lorsque son événement de début reçoit la source sélectionnée : soit une lecture provenant d’un capteur, soit une activation d’une condition de déclenchement enregistrée.
Chaque règle suit un cycle de vie géré :
```
Créer → Modifier → Générer → Déployer → En cours d’exécution → Arrêter
```
Les modifications que vous effectuez dans l’éditeur visuel restent en brouillon jusqu’à ce que vous les génériez et les déployiez explicitement. L’étape de génération valide votre règle — en vérifiant la structure du diagramme, en contrôlant toutes les expressions et en confirmant que chaque chemin est complet. Ce n’est qu’après une génération réussie que vous pouvez déployer la règle pour commencer à traiter sa source sélectionnée, capteur ou déclencheur.
## Ce que vous pouvez construire
Une règle commence par un **Événement de début**. Choisissez **Lecture de capteur** pour l’exécuter chaque fois qu’un capteur sélectionné remonte une mesure, ou **Condition de déclenchement** pour l’exécuter lorsqu’une condition enregistrée devient active pour un ou plusieurs appareils. Un déclencheur peut agir immédiatement ou attendre que la condition reste vraie. Chaque fois que la source sélectionnée se déclenche, la règle s’exécute. À l’intérieur de la règle, vous pouvez :
* **Évaluer des conditions** avec des passerelles exclusives — acheminer le flux vers différentes branches selon des expressions CEL
* **Transformer des données** avec des tâches de script — calculer des valeurs dérivées, classifier des lectures ou préparer des indicateurs pour les décisions en aval
* **Récupérer des données d’autres capteurs** avec des nœuds d’enrichissement — comparer la température intérieure et extérieure, corréler l’humidité avec l’occupation, ou vérifier une lecture de référence avant de décider
* **Déclencher des alarmes** avec des nœuds Définir une alarme — déclencher des définitions d’alarme avec des messages d’intention dynamiques, en lançant des politiques d’escalade et des notifications
* **Agir sur les appareils** avec des nœuds Exécuter une commande — envoyer une commande (fermer une vanne, pousser une consigne, commuter un relais) directement vers un appareil lorsque les conditions sont remplies, afin que la règle contienne le problème au lieu de se contenter de le signaler. Voir [Exécution de commandes sur les appareils](/kilo-docs-fr/kilo-iot-server/rules-engine/running-device-commands.md)
* **Gérer les erreurs avec souplesse** avec des événements d’erreur de bordure — si une étape échoue (par exemple, un capteur est hors ligne pendant l’enrichissement), intercepter l’erreur et la rediriger vers un chemin de repli au lieu d’arrêter toute la règle
Toutes les conditions et les calculs utilisent [CEL](https://cel.dev) (Common Expression Language) — un langage d’expressions sûr et isolé, conçu pour évaluer des conditions. CEL ne peut pas accéder aux fichiers, effectuer des appels réseau ni exécuter des boucles. Il évalue uniquement des expressions à partir des données que vous fournissez.
Cet équilibre est délibéré. La plupart des règles du quotidien sont assemblées en faisant glisser des nœuds sur le canevas et en remplissant des formulaires. CEL apparaît dans des endroits ciblés où la règle a besoin d’une logique précise : conditions des passerelles, tâches de script, messages d’alarme dynamiques, recherches d’enrichissement et mappages d’entrée/sortie. Grâce à CEL, la logique de la règle peut devenir très sophistiquée — conditions imbriquées, classifications de gravité calculées, calculs d’écart entre plusieurs capteurs et chemins de décision dynamiques qui vont bien au-delà de simples alertes de seuil. Vous n’êtes pas forcé d’utiliser des scripts arbitraires, mais vous n’êtes pas non plus limité à de simples conditions du type « si la valeur > X ».
## Sécurité et contrôle
Le moteur de règles est conçu pour des environnements où les changements d’automatisation non gérés ne sont pas acceptables :
* **Verrous de modification** — Une seule personne peut modifier une règle à la fois. Les autres voient qui détient le verrou et quand il expire. Les propriétaires de l’organisation peuvent forcer le déverrouillage si nécessaire.
* **Sauvegarde automatique** — Votre travail est enregistré automatiquement pendant que vous modifiez, avec un retour d’état visible (« Enregistrement... », « Enregistré », « Échec de la sauvegarde automatique »).
* **Historique des versions** — Chaque sauvegarde crée une version. Les versions peuvent être renommées, consultées et restaurées. Si une modification provoque un comportement inattendu, vous pouvez revenir à n’importe quelle version précédente.
* **Génération avant déploiement** — L’étape de génération détecte les erreurs structurelles, les expressions invalides et les connexions manquantes avant que votre règle n’atteigne la production.
* **Artefacts** — Chaque génération produit un artefact nommé avec des horodatages, l’auteur et des commentaires facultatifs. L’onglet Artefacts montre exactement ce qui est déployé dans toutes vos règles.
* **Corbeille et récupération** — La suppression d’une règle la déplace vers la corbeille, pas vers une suppression définitive. Vous pouvez restaurer des règles depuis la corbeille.
* **Sécurité d’urgence** — Le système surveille l’état d’exécution des règles et arrête automatiquement les règles qui rencontrent des erreurs prolongées, évitant ainsi les défaillances en cascade.
## Contenu de la section
| Page | Ce qu’elle couvre |
| ---------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------- |
| [Liste des règles et navigation](/kilo-docs-fr/kilo-iot-server/rules-engine/rules-list-and-navigation.md) | La page principale du moteur de règles — onglets, actions et navigation |
| [Créer des règles](/kilo-docs-fr/kilo-iot-server/rules-engine/creating-rules.md) | Comment créer une nouvelle règle à partir de zéro |
| [Déclencheurs](/kilo-docs-fr/kilo-iot-server/rules-engine/triggers.md) | Conditions enregistrées, temporisation, sélection d’appareils et comment relier un déclencheur à une règle |
| [Éditeur visuel](/kilo-docs-fr/kilo-iot-server/rules-engine/visual-editor.md) | Le canevas BPMN — palette, panneau des propriétés et barre d’outils |
| [Débogage des règles](/kilo-docs-fr/kilo-iot-server/rules-engine/debugging-rules.md) | Exécution pas à pas d’une règle avant son déploiement — points d’arrêt, variables, surveillances, effets secondaires |
| [Référence des nœuds](/kilo-docs-fr/kilo-iot-server/rules-engine/node-reference.md) | Chaque type de nœud avec détails de configuration et exemples |
| [Exécution de commandes sur les appareils](/kilo-docs-fr/kilo-iot-server/rules-engine/running-device-commands.md) | Le nœud Exécuter une commande — faire agir une règle sur un appareil, pas seulement alerter |
| [Référence CEL](/kilo-docs-fr/kilo-iot-server/rules-engine/cel-reference.md) | Types, opérateurs et modèles du langage d’expressions |
| [Verrous de modification et transferts d’équipe](/kilo-docs-fr/kilo-iot-server/rules-engine/edit-locks-and-team-handoffs.md) | Verrouillage, déverrouillage forcé, inactivité et sauvegarde automatique |
| [Historique des versions et restauration](/kilo-docs-fr/kilo-iot-server/rules-engine/version-history-and-restore.md) | Suivi des versions, nommage, consultation et restauration |
| [Générations, artefacts et déploiement](/kilo-docs-fr/kilo-iot-server/rules-engine/builds-artifacts-and-deployment.md) | Génération des règles, onglet Artefacts, déploiement et arrêt |
| [Corbeille et récupération](/kilo-docs-fr/kilo-iot-server/rules-engine/trash-and-recovery.md) | Suppression logique, vue Corbeille et restauration des règles |
| [Modèles d’automatisation](/kilo-docs-fr/kilo-iot-server/rules-engine/automation-patterns.md) | Modèles d’automatisation d’entreprise avec exemples CEL |
| [Dépannage](/kilo-docs-fr/kilo-iot-server/rules-engine/troubleshooting.md) | Erreurs de génération, problèmes courants et limites |
---
# 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 dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.kiloiot.io/kilo-docs-fr/kilo-iot-server/rules-engine.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
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.
