Gestion de parc informatique avec GLPI · Étape 16

Écris des règles d'affectation et de transformation testables

Transforme des besoins métier en critères, actions, ordre d'exécution, cas de test et rollback avant activation.

Durée indicative · ~1 h 35Niveau intermédiairePrérequis conseillé · Leçon 15 — modèles, validations, solutions et base de connaissancesPratique · TP
L’idée reçue

« Une règle simple n’a pas besoin de test. »

Une règle simple peut détourner tous les tickets si son critère est trop large ou si elle précède une règle plus spécifique.

01Décompose la décision

Entrée
- sujet
- domaine de l'expéditeur
- collecteur
- catégorie ou entité existante

Critères
- contient « vpn »
- domaine égal à soria.example

Actions
- catégorie INCIDENT_NETWORK
- groupe INFRA
- priorité P3

Stratégie
- arrêter après la première règle correspondante

Une règle documentée explique aussi ce qu’elle ne doit jamais faire.

02Ordonne du spécifique au général

order,rule_code,match_field,operator,match_value
10,RULE_NET_SUBJECT,subject,contains,vpn
20,RULE_ACCESS_DOMAIN,sender_domain,equals,soria.example
30,RULE_SOFTWARE_SUBJECT,subject,contains,logiciel
90,RULE_FALLBACK,subject,contains,

Le fallback reste dernier. Placé en premier, il masquerait toutes les règles suivantes.

03Comprends les stratégies du moteur

Selon le type de règles, GLPI peut :

- s'arrêter après la première correspondance ;
- appliquer toutes les règles ;
- transmettre le résultat d'une règle à la suivante.

Ne transpose pas automatiquement le comportement d’un moteur à un autre. Vérifie toujours le type de règles concerné.

04Écris les tests avant activation

test_id,subject,sender_domain,expected_rule,expected_group
TEST-001,Vpn indisponible,soria.example,RULE_NET_SUBJECT,INFRA
TEST-002,Demande accès nouvel arrivant,soria.example,RULE_ACCESS_DOMAIN,SUPPORT_N1
TEST-003,Installation logiciel CAO,partner.example,RULE_SOFTWARE_SUBJECT,SUPPORT_N1
TEST-004,Clavier défectueux,partner.example,RULE_FALLBACK,SUPPORT_N1

Chaque nouvelle règle exige au minimum : un cas attendu, un cas voisin qui ne doit pas matcher et un test de fallback.

05Utilise le bouton de test sans confondre test et production

1. désactiver la nouvelle règle ;
2. sauvegarder ou exporter la configuration existante ;
3. tester des valeurs représentatives ;
4. vérifier la règle gagnante et toutes les actions ;
5. activer dans une fenêtre contrôlée ;
6. observer les objets créés ;
7. désactiver immédiatement si le résultat diverge.

Le test intégré démontre la logique sur des entrées données. Il ne prouve pas à lui seul l’absence d’effet de bord en production.

06Exécute le laboratoire

lab=/tmp/soria-glpi-automation-$USER
bash module4-glpi-automation-reporting.sh setup "$lab"
bash module4-glpi-automation-reporting.sh run "$lab"
column -s, -t "$lab/output/rule-test-results.csv"

Les quatre lignes doivent retourner PASS, avec RULE_NET_SUBJECT gagnante pour le cas VPN et RULE_FALLBACK pour le clavier.

07Prépare le rollback

- code de règle et position précédente
- export ou capture de la configuration
- heure d'activation
- tickets impactés depuis cette heure
- procédure de désactivation
- correction des tickets mal affectés
- propriétaire de la décision
Mission

Conçois une règle défendable

Écris la règle, son ordre, quatre tests, les résultats attendus, les métriques d’observation et la procédure pour corriger les objets déjà affectés.

À retenir

Une automatisation fiable n’est pas une règle activée : c’est une décision versionnée, testée, observée et réversible.

Ta progression

Chargement de l’état… Se connecter pour synchroniser.