# Life-NOC — Probe Model v1 ## 1. Objet Ce document définit le **modèle canonique de sonde** de Life-NOC. L’objectif est de séparer clairement : - la **nature du suivi** - la **source des données** - la **métrique calculée** - les **seuils** - la **traduction en états Life-NOC** Ce modèle doit permettre de faire coexister : - des suivis encore **mockés** - des suivis **réels** - des intrants provenant de sources variées - une évolution progressive du système, sans casser l’existant --- ## 2. Principes de design ### 2.1 Stabilité d’abord Le dépôt existant doit rester fonctionnel et déployable pendant toute l’introduction des sondes réelles. Aucune migration brutale ne doit être exigée. --- ### 2.2 Une sonde par nature de calcul, pas par item Les services Life-NOC ne doivent pas reposer sur une multitude de scripts ad hoc. Ils doivent être des **instances paramétrées** d’un petit nombre de types de sondes génériques. Autrement dit : - un item décrit **quoi mesurer** - la sonde décrit **comment l’évaluer** --- ### 2.3 Les sources de données sont multiples Life-NOC doit pouvoir recevoir des données à partir de plusieurs mécanismes : - saisie manuelle - MQTT - fichiers - API - commandes locales - valeurs dérivées MQTT est un **mécanisme de transport**, pas une mémoire durable. --- ### 2.4 L’ambiguïté technique est critique Dans Life-NOC, l’impossibilité de conclure techniquement ne doit pas être interprétée comme un état neutre. Une erreur de lecture, de parsing ou d’accès à la donnée doit produire un état **CRITICAL**, afin de forcer la correction de la sonde ou de sa source. --- ## 3. Sémantique des états Life-NOC Life-NOC utilise la sémantique suivante : - **UNKNOWN** : pas encore dû, pas encore à faire - **OK** : actionnable maintenant - **WARNING** : il faut se presser - **CRITICAL** : en retard, anormal, ou impossible à évaluer Cette convention diffère volontairement de l’usage classique de Nagios/Icinga. Dans Life-NOC : - le vert n’exprime pas l’absence de travail - il exprime le **bon moment pour agir** - le gris `UNKNOWN` signifie que l’item n’est pas encore dans sa fenêtre d’action --- ## 4. Taxonomie des sondes v1 Le modèle conceptuel v1 couvre cinq types de sondes. ### 4.1 `elapsed_time` Mesure le **temps écoulé** depuis un événement ou une exécution précédente. #### Exemples - revue quotidienne - revue hebdomadaire - inspection trimestrielle - test détecteurs - vérification sauvegardes #### Donnée de base - date de dernière exécution #### Métrique typique - jours écoulés #### Logique générale Plus le temps écoulé augmente, plus l’item devient dû. --- ### 4.2 `elapsed_distance` Mesure une **distance écoulée** depuis un événement passé. #### Exemples - kilométrage depuis vidange - kilométrage depuis entretien pneus - kilométrage depuis vérification freins - kilomètres depuis changement de courroie #### Données de base - compteur courant - compteur lors de la dernière exécution #### Métrique typique - kilomètres écoulés #### Logique générale Plus la distance écoulée augmente, plus l’item devient dû. --- ### 4.3 `current_value` Mesure une **valeur instantanée** comparée à des seuils. #### Exemples - tension batterie - température - humidité - espace disque libre - charge électrique - niveau de tension #### Donnée de base - valeur actuelle observée #### Métriques typiques - volts - pourcentage - degrés - gigaoctets - watts #### Logique générale L’état dépend d’un positionnement par rapport à un ou plusieurs seuils. --- ### 4.4 `remaining_quantity` Mesure ce qu’il **reste** d’un stock, d’une réserve ou d’une autonomie. #### Exemples - nourriture chats restante - réserve d’eau - vitamines restantes - carburant restant - consommables #### Donnée de base - quantité restante #### Métriques typiques - jours d’autonomie - litres - unités - kilogrammes - pourcentage #### Logique générale Plus la quantité restante diminue, plus l’item devient critique. --- ### 4.5 `days_until_due` Mesure le **temps restant avant une échéance fixe**. #### Exemples - permis de conduire - carte d’assurance maladie - passeport - assurances - échéance fiscale - rendez-vous #### Donnée de base - date d’échéance #### Métrique typique - jours restants #### Logique générale Plus on approche de la date, plus l’item entre dans la fenêtre d’action, puis dans l’urgence. --- ## 5. Sources de données Le modèle distingue le **type de sonde** de la **source de données**. ### 5.1 Sources conceptuellement prévues - `manual_date` - `manual_counter` - `manual_value` - `mqtt` - `file_json` - `file_text` - `csv` - `api` - `command` - `derived` ### 5.2 Sources v1 à faible risque Pour l’implémentation initiale, seules les sources suivantes sont retenues : - `manual_date` Les autres sources sont **réservées** au modèle, mais non implémentées dans la première tranche. --- ## 6. Schéma canonique d’un item Chaque item peut, à terme, porter une description de sonde structurée. Exemple canonique : ```yaml probe: type: elapsed_time source: type: manual_date value: "2026-03-10" metric: unit: days thresholds: unknown_lt: 5 ok_gte: 5 warning_gte: 7 critical_gte: 10 policy: on_error: critical ```` --- ## 7. Règles générales de seuils ### 7.1 Cas où la métrique augmente avec l’urgence Exemples : * jours écoulés * kilomètres écoulés Ordre d’évaluation recommandé : 1. `critical_gte` 2. `warning_gte` 3. `ok_gte` 4. sinon `unknown` --- ### 7.2 Cas où la métrique diminue avec la gravité Exemples : * quantité restante * tension minimale * autonomie restante Ordre d’évaluation recommandé : 1. `critical_lt` 2. `warning_lt` 3. `ok_gte` 4. sinon `unknown` --- ### 7.3 Cas où la métrique est une échéance future Exemples : * jours avant expiration * jours avant rendez-vous * jours avant renouvellement Ordre d’évaluation recommandé : 1. `critical_lt` 2. `warning_lt` 3. `ok_lt` 4. sinon `unknown` --- ## 8. Politique d’erreur La politique d’erreur par défaut de Life-NOC est : ```yaml policy: on_error: critical ``` Cela signifie que les situations suivantes doivent produire `CRITICAL` : * donnée absente * donnée invalide * parsing impossible * source inaccessible * seuils incohérents * type de sonde non supporté * unité non supportée * configuration incomplète Cette règle vise à éviter que des erreurs techniques demeurent invisibles. --- ## 9. Coexistence avec le modèle mocké Le dépôt actuel repose sur une preuve de concept **mockée**. L’introduction du modèle de sonde ne doit pas casser cette base. ### Règle de compatibilité * si un item **ne définit pas** de bloc `probe`, il continue de fonctionner selon la logique mock existante * si un item **définit** un bloc `probe`, il peut être pris en charge par la nouvelle sonde générique, selon les types réellement supportés par le moteur Cette compatibilité permet une migration progressive, item par item. --- ## 10. Portée de l’implémentation initiale Le **modèle conceptuel v1** couvre cinq types de sondes. Cependant, afin de préserver la stabilité du dépôt, l’**implémentation initiale** est volontairement limitée à : * `probe.type = elapsed_time` * `source.type = manual_date` * `metric.unit = days` Tous les autres types restent **documentés mais non encore codés**. Cette décision est volontaire. Elle permet : * de garder le dépôt stable * de valider la mécanique sur un seul cas simple * de faciliter le débogage * de réduire le risque de régression --- ## 11. Exemple complet ```yaml revue: - name: revue-hebdomadaire-priorites date: "2026-03-10" notes: Revoir les priorités de la semaine probe: type: elapsed_time source: type: manual_date value: "2026-03-10" metric: unit: days thresholds: unknown_lt: 5 ok_gte: 5 warning_gte: 7 critical_gte: 10 policy: on_error: critical ``` Interprétation : * moins de 5 jours depuis la dernière revue : `UNKNOWN` * à partir de 5 jours : `OK` * à partir de 7 jours : `WARNING` * à partir de 10 jours : `CRITICAL` --- ## 12. Positionnement architectural Le modèle de sonde Life-NOC s’inscrit dans une architecture à quatre couches : 1. **définition** * schéma des sondes * règles * seuils * unités 2. **acquisition** * MQTT * saisie manuelle * fichiers * API * commandes 3. **persistance** * mémoire durable des valeurs utiles * dates * compteurs * provenance 4. **évaluation** * calcul de métrique * comparaison aux seuils * retour d’état vers Icinga --- ## 13. Conclusion Le modèle de sonde v1 donne à Life-NOC un cadre formel pour sortir progressivement du mock sans compromettre la stabilité du système. Il permet de : * figer la taxonomie des suivis * uniformiser les méthodes d’évaluation * préparer l’intégration de sources de données réelles * conserver une migration graduelle et réversible