Valide la gouvernance initiale et le catalogue de services

L’idée reçue

« Il faut créer toutes les catégories possibles avant d’ouvrir le service desk. »

Un catalogue trop détaillé dès le départ produit des choix ambigus et des rapports inutilisables. Commence avec peu de catégories, observe les tickets, puis améliore.

01Pars de besoins compréhensibles

category_code,parent_code,name,default_group,service_type
INCIDENT,,Incident,SUPPORT_N1,incident
INCIDENT_NETWORK,INCIDENT,Réseau et connectivité,INFRA,incident
REQUEST,,Demande,SUPPORT_N1,request
REQUEST_ACCESS,REQUEST,Accès et habilitation,SUPPORT_N1,request

Quatre catégories suffisent pour tester la gouvernance. Elles distinguent déjà incident et demande, et orientent le réseau vers l’équipe infrastructure.

02Définis un propriétaire pour chaque règle

Objet                       Responsable
Structure des entités       administrateur GLPI
Lieux                       gestionnaire de parc
Profils et droits           responsable sécurité / plateforme
Groupes de support          responsable support
Catalogue de catégories     responsable service desk
Compte break-glass          responsable plateforme
Architecture et sauvegarde  équipe infrastructure

Sans propriétaire, une donnée devient obsolète même si elle était correcte au départ.

03Évite l’affectation automatique opaque

Avant toute règle automatique, écris :

Entrée
- catégorie
- entité
- demandeur
- actif ou service concerné

Décision
- groupe cible
- priorité éventuelle
- modèle appliqué

Preuve
- ticket de test
- journal de règle
- raison de la décision

Retour arrière
- désactivation de la règle
- traitement des tickets déjà affectés

Le lot 4 automatisera ces décisions. Le lot 1 prépare seulement un catalogue cohérent.

04Exécute le cycle complet

lab=/tmp/soria-glpi-foundations-$USER
script=module1-glpi-foundations.sh

bash "$script" setup "$lab"
bash "$script" status "$lab"
bash "$script" run "$lab"
bash "$script" validate "$lab"
bash "$script" reset "$lab"
test ! -e "$lab"

Le reset refuse un dossier sans marker et ne peut cibler qu’un chemin commençant par /tmp/soria-glpi- ou $HOME/soria-glpi-.

05Comprends les validations

Références
- parents d'entités existants
- lieux rattachés à une entité connue
- utilisateurs liés à des profils et groupes connus

Droits
- demandeur sans privilège d'administration
- un seul compte Super-Admin d'urgence
- compte quotidien distinct

Architecture
- TLS obligatoire
- scheduler système
- sauvegarde chiffrée
- config, data et logs hors webroot

Preuves
- rapport de readiness
- arbre des entités
- matrice de droits
- checksums vérifiables
- absence de valeur ressemblant à un secret

06Pose la gate de passage

Le dossier peut passer à une instance GLPI de lab uniquement si :

[ ] le périmètre est approuvé
[ ] les objets organisationnels ont un propriétaire
[ ] les droits suivent le moindre privilège
[ ] le catalogue initial est court et testable
[ ] l'architecture sépare les données sensibles
[ ] les secrets ont un canal dédié
[ ] les tests d'acceptation sont écrits
[ ] la sauvegarde et le rollback sont prévus
[ ] les limites de preuve sont explicites

07Prépare les preuves du projet PME

01-organisation/
02-architecture/
03-access-matrix/
04-service-catalog/
05-deployment-change/
06-acceptance-tests/
07-backup-restore/
08-evidence/

Cette structure sera enrichie pendant les lots suivants avec l’inventaire, les tickets, SLA, automatisations et indicateurs.

Projet du lot 1

Défends le socle avant installation

Présente l’organisation, la matrice de droits, le catalogue initial, l’architecture et le plan de changement. Explique ce que ton dossier prouve réellement, ce qui reste à tester sur une instance GLPI et quelle condition empêcherait le déploiement.

✓Lot 1 terminé

Tu sais cadrer le service, structurer l’organisation, concevoir l’architecture, préparer un changement réversible et poser une gate de gouvernance avant l’inventaire réel.