Modélise entités, lieux, groupes, profils et utilisateurs

01Distingue les objets d’organisation

Entité
- sépare un périmètre administratif ou opérationnel
- porte des règles et des droits
- peut avoir des sous-entités

Lieu
- décrit une position physique
- peut être hiérarchique : site, bâtiment, étage, salle

Groupe
- rassemble des personnes pour une responsabilité
- support N1, infrastructure, support local

Profil
- définit ce qu'un utilisateur peut faire
- demandeur, technicien, gestionnaire de parc, administrateur

Le groupe répond à « qui traite ? ». Le profil répond à « que peut-il faire ? ». L’entité répond à « dans quel périmètre ? ».

02Lis la hiérarchie proposée

lab=/tmp/soria-glpi-foundations-$USER
bash module1-glpi-foundations.sh run "$lab"
cat "$lab/output/entity-tree.txt"

Résultat attendu :

ROOT | SORIA Distribution
  ROOT -> HQ | Siège Orléans
  ROOT -> AGENCY | Agence Tours

La racine permet une vue globale. Les sous-entités isolent les opérations locales lorsque cela est nécessaire.

03N’utilise pas les entités sans raison

Créer une entité pour chaque service, étage ou équipe augmente :

- les règles de transfert ;
- les droits récursifs ;
- la duplication des catégories ;
- la complexité des rapports ;
- le risque d'affecter un objet au mauvais périmètre.

Crée une entité seulement lorsqu’il existe un besoin durable de séparation : responsabilité, visibilité, règles, budget ou exploitation distincte.

04Construis les lieux

location_code,entity_id,name
ORL-HQ,HQ,Siège Orléans
ORL-SRV,HQ,Salle serveurs Orléans
TOU-AG,AGENCY,Agence Tours

Un lieu doit rester stable même si l’utilisateur ou le matériel change. Évite les libellés ambigus tels que Bureau 1 sans site ni étage.

05Sépare groupes et profils

group_code,entity_id,name,role
SUPPORT_N1,HQ,Support niveau 1,ticketing
INFRA,HQ,Équipe infrastructure,asset-and-ticket
LOCAL_TOURS,AGENCY,Support local Tours,ticketing

profile_code,scope,admin,assets,tickets,all_tickets
TECH_N1,ENTITY,false,true,true,true
ASSET_MANAGER,ENTITY,false,true,false,false
REQUESTER,SELF,false,false,false,false

Un technicien peut appartenir à plusieurs groupes tout en conservant le même profil. Ne crée pas un profil différent pour chaque équipe si les droits sont identiques.

06Observe la matrice générée

column -s, -t "$lab/output/access-matrix.csv" 2>/dev/null \
  || cat "$lab/output/access-matrix.csv"

Le lab vérifie notamment que le demandeur ne possède aucun droit d’administration, de gestion d’actifs ou de traitement global des tickets.

07Réserve le Super-Admin

admin-breakglass,ROOT,SUPERADMIN,,administration exceptionnelle

Le compte d’urgence n’est pas un compte quotidien. Une gouvernance correcte prévoit :

- identité nominative ou procédure de coffre ;
- usage exceptionnel ;
- journalisation ;
- revue après utilisation ;
- compte technicien distinct pour les opérations courantes.

08Contrôle les références

Le lab refuse :

- une sous-entité dont le parent n'existe pas ;
- un lieu associé à une entité inconnue ;
- un utilisateur lié à un profil ou groupe absent ;
- deux codes identiques ;
- plusieurs comptes Super-Admin non justifiés.

Ces contrôles représentent une discipline de migration et d’import. Une interface graphique n’empêche pas les incohérences conceptuelles.