> 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/debugging-rules.md).
# Déboguer les règles
Déboguez une règle d’automatisation Kilo IoT avant le déploiement — nœuds d’étape, variables observées, vérifiez les expressions par rapport au contexte de test.
Une règle qui semble correcte sur le canevas peut quand même se comporter d'une manière inattendue — une passerelle envoie le flux vers la mauvaise branche, une expression est évaluée sur une structure de données que vous n'aviez pas anticipée, une variable contient autre chose que ce que vous aviez supposé. Le mode débogage vous permet de le découvrir *avant* que la règle soit déployée en production, en exécutant la règle pas à pas et en inspectant exactement ce qui se passe à chaque nœud.
Le mode débogage est un débogueur interactif intégré à l'éditeur visuel. Vous fournissez à la règle une charge utile de test, puis vous suivez son exécution nœud par nœud — en marquant des pauses où vous voulez, en observant les variables changer, en vérifiant les expressions et en décidant comment chaque effet de bord est traité. C'est la différence entre déployer une règle et *espérer*, et déployer une règle que vous avez réellement vue s'exécuter.
## Démarrer une session de débogage
1. Ouvrez la règle dans l' [éditeur visuel](/kilo-docs-fr/kilo-iot-server/rules-engine/visual-editor.md).
2. Dans la barre supérieure de l'éditeur de règles, cliquez sur **Définir le contexte** pour ouvrir l’onglet **Démarrer la session de débogage** panneau. (La barre supérieure comporte également un **Démarrer le débogage** bouton, raccourci **F12**.)
3. Le panneau vous demande de **fournir les variables de contexte initiales** — l'entrée sur laquelle la règle s'exécutera. Il s'ouvre avec une ligne déjà ajoutée, nommée `value`, et chaque ligne est un **Nom** et un **Valeur**:
* **Nom** est le nom de variable que votre règle attend (par exemple `value`, `temperature`, `status`).
* **Valeur** est la lecture de test. Elle peut être un nombre, `vrai` / `faux`, `null`, du texte ou du JSON — le panneau l'interprète pour vous.
4. Cliquez **Ajouter une métrique** pour ajouter d'autres variables de contexte ; supprimez toute ligne supplémentaire dont vous n'avez pas besoin.
5. Cliquez **Charger et démarrer**. La règle se charge et se met en pause, prête pour la première étape.
Le contexte initial remplace ce qu'un appareil enverrait en production. Réglez-le sur les valeurs que vous voulez tester — le cas limite, le seuil, la mesure que vous soupçonnez de poser problème.
### Nommez chaque variable exactement comme votre règle y fait référence
Les règles lisent le contexte via `vars`, donc nommez chaque ligne pour qu'elle corresponde aux expressions de votre règle. Une condition de passerelle écrite `vars.RH > 70` a besoin d'une ligne nommée **`RH`** — `humidité` ou `value` ne fera pas l'affaire. Si une condition fait référence à un nom que le contexte ne contient pas, la règle s'arrête à cet élément lorsque vous l'atteignez.
Copiez les noms de vos conditions de passerelle plutôt que de les taper de mémoire, et vérifiez l'orthographe avant de commencer.
Deux lignes que vous n'avez pas besoin d'ajouter :
* Le panneau s'ouvre avec une ligne nommée `value`, ce qui convient aux règles démarrées par **Lecture du capteur**. Une règle de production démarrée par **Condition de déclenchement** ne reçoit pas `vars.value`, donc supprimez ou renommez cette valeur de test pour qu'elle corresponde au contexte de déclenchement.
* Le débogueur fournit `sensor_id` automatiquement. En production, il provient du capteur sélectionné ou du signal de déclenchement, selon la source de démarrage.
## La session démarre en pause
Le chargement d'une session n'exécute pas la règle. Il ouvre le diagramme, place l'exécution sur l'événement de départ et vous attend — **rien ne s'exécute tant que vous n'appuyez pas sur Exécuter ou sur l'un des contrôles d'étape**.
Lorsque la session est chargée, vous verrez le canevas passer en lecture seule, la barre d'outils de débogage apparaître en bas de l'éditeur, le panneau de débogage s'ouvrir à droite avec vos variables initiales, et un contour bleu sur l'événement de départ. Le contour bleu indique que la session est active et en attente.
Si le diagramme semble immobile, appuyez sur **Exécuter (F10)** pour continuer jusqu'au premier point d'arrêt ou jusqu'à la fin, ou sur **Passer par-dessus (F9)** pour avancer d'un élément à la fois.
## Les contrôles de débogage
Une fois une session chargée, une barre d'outils de débogage flotte au-dessus du bas du canevas avec cinq contrôles. Elle ne se trouve pas dans la barre d'en-tête à côté de Enregistrer et Compiler — regardez en bas du diagramme.
* **Exécuter (F10)** — exécute la règle jusqu'à ce qu'elle atteigne un point d'arrêt ou se termine.
* **Passer par-dessus (F9)** — exécute le nœud suivant puis s'arrête, en affichant son résultat.
* **Entrer dans (F8)** — entre dans le nœud suivant et inspecte ses éléments internes — ses entrées, scripts et sorties — plutôt que seulement son résultat.
* **Exécuter en ignorant les points d'arrêt (F11)** — exécute jusqu'à la fin sans s'arrêter. Cela désactive tous les points d'arrêt et les laisse désactivés pour le reste de la session ; réactivez-les depuis l'onglet Points d'arrêt lorsque vous en avez à nouveau besoin.
* **Arrêter (F12)** — met fin à la session de débogage.
**F12 fonctionne aux deux extrémités d'une session :** appuyez dessus pendant l'édition pour commencer le débogage, puis à nouveau pendant le débogage pour l'arrêter.
Les contrôles d'étape sont disponibles pendant que la session est en pause. Ils sont grisés lorsque la règle s'exécute, lorsqu'une boîte de dialogue d'effet de bord attend une réponse, et après l'échec du chargement d'une règle. Arrêter reste disponible tout le temps.
## Ce que signifient les marqueurs sur le canevas
Les éléments peuvent porter trois marques différentes pendant une session :
| Marqueur | Signification |
| -------------------------------------------- | -------------------------------------------------------------------------------------------------- |
| **Contour bleu** | L'endroit où l'exécution se trouve actuellement. La prochaine étape s'exécute ici. |
| **Petit point rouge** au-dessus de l'élément | Un point d'arrêt. Un point plein est activé ; un anneau vide est un point que vous avez désactivé. |
| **Contour rouge** | L'élément qui a provoqué la plus récente erreur. Il disparaît à l'étape réussie suivante. |
Un contour rouge n'est ni un point d'arrêt ni la position actuelle — il marque l'élément qui a échoué, et l'expression sur cet élément est celle qu'il faut examiner. Voir [Lorsqu'un nœud échoue](#when-a-node-fails).
## Points d'arrêt
Un point d'arrêt suspend l'exécution sur un nœud précis, afin que vous puissiez inspecter l'état exactement au point qui vous intéresse.
* **Définir un point d'arrêt** — cliquez sur un nœud sur le canevas pour y activer ou désactiver un point d'arrêt. Ouvrez l' **Points d'arrêt** onglet du panneau de débogage pour tous les voir ; l'en-tête de l'onglet indique un compteur. Pendant une session, chaque clic sur le canevas ajoute ou retire un point d'arrêt, alors cliquez à nouveau sur un élément pour en supprimer un que vous n'aviez pas voulu.
* **Activer ou désactiver** — chaque point d'arrêt possède un point indicateur rouge. Cliquez dessus pour désactiver le point d'arrêt sans le supprimer, puis le réactiver plus tard.
* **Points d'arrêt conditionnels** — créez d'abord un point d'arrêt simple, puis cliquez sur **Définir la condition** sur celui-ci et saisissez une expression CEL. Le point d'arrêt suspend alors l'exécution *uniquement* lorsque cette expression est vraie — par exemple, uniquement lorsque `vars.value > 30`. Un point d'arrêt conditionnel est marqué d'un badge **Conditionnel** . Voir [Référence CEL](/kilo-docs-fr/kilo-iot-server/rules-engine/cel-reference.md) pour la syntaxe des expressions.
Les points d'arrêt conditionnels sont la manière de déboguer un problème intermittent : laissez la règle s'exécuter normalement et arrêtez-la seulement sur la lecture qui déclenche le comportement incorrect.
## Inspection des variables
La **Variable** onglet du panneau de débogage affiche l'état de la règle à l'étape actuelle, en deux sections :
* **Modifications** — les variables qui ont été ajoutées ou modifiées depuis la dernière étape, mises en évidence pour que vous puissiez voir en un coup d'œil ce que le nœud que vous venez d'exécuter a réellement fait. Les variables supprimées sont affichées barrées.
* **Toutes les variables** — l'ensemble complet des variables actuelles avec leurs valeurs.
Pendant la pause, vous pouvez aussi **modifier** l'état directement : modifier la valeur d'une variable, ajouter une nouvelle variable ou en supprimer une. Cela vous permet de pousser la règle dans une branche que vous voulez tester sans avoir à redémarrer la session avec une entrée différente.
Lorsque vous utilisez **Entrer dans** sur un nœud, l'onglet Variable affiche aussi une carte de détails de l'élément avec les **Entrées**, **Scripts**, et **Sorties** — le fonctionnement interne de l'étape, pas seulement son résultat final.
## Expressions à surveiller et Évaluer
La **Surveiller** onglet garde un œil sur les expressions pendant l'exécution de la règle :
* **Ajouter une surveillance** — saisissez une expression CEL et elle est réévaluée automatiquement à chaque étape, afin que vous puissiez suivre une valeur dérivée (par exemple, `vars.value - vars.threshold`) sans fouiller dans la liste des variables.
* **Évaluer** — saisissez une expression CEL ponctuelle et évaluez-la immédiatement par rapport à l'état actuel. Utile pour vérifier une logique — « que renverrait cette condition de passerelle maintenant ? » — sans l'ajouter à la règle.
Les deux utilisent le même [CEL](/kilo-docs-fr/kilo-iot-server/rules-engine/cel-reference.md) que vous écrivez ailleurs dans la règle, et les deux lisent l'état de la règle via `vars` — une surveillance sur une variable nommée `RH` s'écrit `vars.RH`. Une expression qui ne se compile pas est rejetée au moment où vous l'ajoutez, donc utilisez l'onglet Surveiller pour essayer une condition avant de la coller dans une passerelle.
## Effets de bord
Certains nœuds font plus que transformer des données — ils envoient des notifications, déclenchent des alarmes ou appellent d'autres systèmes. Lorsque l'exécution de débogage atteint un nœud avec un effet de bord, une **Effet de bord** boîte de dialogue s'affiche et vous demande comment le traiter. Trois options :
* **Exécuter — exécute le gestionnaire réel.** L'effet de bord se produit réellement, exactement comme dans une règle déployée : une alarme est déclenchée et ses destinataires sont notifiés, et une commande est envoyée à l'appareil physique.
* **Ignorer — variables inchangées.** L'effet de bord est ignoré et les variables de la règle restent telles quelles.
* **Simuler — fournir une réponse simulée.** Vous fournissez une réponse de remplacement au format JSON et la règle continue comme si le gestionnaire l'avait renvoyée. La réponse doit être un JSON valide — si ce n'est pas le cas, la simulation n'est tout simplement pas appliquée.
**Exécuter est sélectionné à l'ouverture de la boîte de dialogue**, alors modifiez la sélection avant de cliquer sur Appliquer si vous ne voulez pas que l'action se produise réellement. C'est ce qui vous permet de déboguer une règle qui envoie des alertes sans réellement appeler un ingénieur d'astreinte : choisissez **Ignorer** ou **Simuler** pendant que vous testez la logique, et **Exécuter** seulement lorsque vous voulez spécifiquement vérifier la livraison réelle.
Deux choses à prévoir une fois que vous avez répondu :
* **Votre réponse est réutilisée pour ce nœud.** Si l'exécution atteint à nouveau le même nœud plus tard dans la session, la boîte de dialogue ne réapparaît pas et votre choix précédent est appliqué. Choisir **Exécuter** envoie donc également réellement à chaque passage ultérieur. Commencez une nouvelle session pour être à nouveau interrogé.
* **Annuler replace l'exécution en arrière.** Fermer la boîte de dialogue sans choisir renvoie juste avant le nœud et le laisse non exécuté. Passez à l'étape suivante et la boîte de dialogue réapparaît.
## Lorsqu'un nœud échoue
Si un nœud produit une erreur pendant l'exécution, le nœud en échec est entouré de rouge sur le canevas, afin que vous puissiez voir exactement quel nœud a échoué sans parcourir une grande règle. Une **récupérable** erreur laisse la session de débogage en pause et chargée — vous pouvez inspecter les variables, ajuster l'état et continuer — tandis qu'une **irréversible** erreur met fin à la session.
La plupart des erreurs proviennent d'une expression sur le nœud en échec. Ouvrez ses propriétés et vérifiez trois choses :
1. **Chaque nom qu'elle utilise existe dans l'onglet Variables.** `vars.RH > 70` échoue si rien nommé `RH` a été défini comme contexte initial ou produit par un nœud précédent. Sur une passerelle, cela arrête la règle à la passerelle — elle ne la dirige pas vers la branche par défaut.
2. **La `vars.` le préfixe est présent.** `RH > 70` n'est pas la même chose que `vars.RH > 70`.
3. **L'expression renvoie le bon type.** Une condition de passerelle doit produire `vrai` ou `faux`.
Collez l'expression dans **Évaluer** sur l'onglet Surveiller pour la tester sur l'état actuel.
## Cycle de vie de la session
Une session de débogage dure **30 minutes**, mesurées à partir de son démarrage — le fait de parcourir la règle pas à pas ne prolonge pas cette durée. Vous verrez un avertissement peu avant son expiration, et une notification si elle expire, se ferme (avec la raison) ou perd sa connexion. Commencez une nouvelle session pour continuer le débogage.
Les points d'arrêt sont liés aux éléments du diagramme que vous avez chargé, donc recharger l'éditeur peut les supprimer. Une notification vous indique combien il y en a, afin que vous puissiez les rajouter.
Si le démarrage d'une session échoue, la plate-forme exécute à ce moment-là le nombre maximal de sessions de débogage. Réessayez dans un instant.
## Conseils
* Déboguez les cas limites, pas le chemin heureux — réglez le contexte initial sur la valeur de seuil, le champ manquant, la mesure hors plage.
* Copiez les noms des variables depuis vos conditions de passerelle lorsque vous renseignez le contexte initial, au lieu de les taper de mémoire.
* Utilisez un point d'arrêt conditionnel pour attraper un problème intermittent : exécutez la règle normalement et arrêtez-vous seulement sur la lecture qui le déclenche.
* Modifiez une variable au milieu de la session pour forcer la règle dans une branche précise plutôt que de redémarrer avec une nouvelle entrée.
* Laissez les effets de bord activés **Ignorer** ou **Simuler** pendant que vous itérez sur la logique ; basculez sur **Exécuter** seulement pour une vérification complète délibérée.
* Une fois qu'une règle se débogue correctement, compilez-la et déployez-la — voir [Compilations et déploiement](/kilo-docs-fr/kilo-iot-server/rules-engine/builds-artifacts-and-deployment.md).
## Voir aussi
* [Éditeur visuel](/kilo-docs-fr/kilo-iot-server/rules-engine/visual-editor.md) — Le mode de débogage du canevas fonctionne sur
* [Référence CEL](/kilo-docs-fr/kilo-iot-server/rules-engine/cel-reference.md) — Syntaxe des expressions pour les points d'arrêt conditionnels et les surveillances
* [Compilations et déploiement](/kilo-docs-fr/kilo-iot-server/rules-engine/builds-artifacts-and-deployment.md) — Déployez une règle une fois qu'elle se débogue correctement
* [Dépannage](/kilo-docs-fr/kilo-iot-server/rules-engine/troubleshooting.md) — Erreurs de compilation et problèmes d'exécution
---
# 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/debugging-rules.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.
