Utilise modèles, validations, solutions et base de connaissances

L’idée reçue

« Un modèle automatise le traitement et un article KB peut être publié dès qu’un ticket est résolu. »

Le modèle standardise la collecte. La validation autorise une décision. La solution prouve le résultat. La connaissance exige une relecture, un périmètre et un propriétaire.

01Utilise le modèle pour améliorer l’entrée

TPL_ACCESS
Type : demande
Obligatoire : demandeur, catégorie, cible, propriétaire métier
Validation : manager

TPL_NETWORK
Type : incident
Obligatoire : demandeur, actif, impact, description
Validation : non

Le modèle peut préremplir, masquer ou rendre obligatoire un champ. Il ne remplace pas la qualification du technicien.

02Relie modèle et catégorie

catégorie REQUEST_ACCESS
→ TPL_ACCESS
→ SUPPORT_N1
→ SLA_STANDARD
→ connaissance Accès

Dans GLPI, un modèle associé à une catégorie peut remplacer celui défini ailleurs. Documente la priorité des sources de configuration.

03Calcule une validation

TCK-002,ticket,MANAGER_100,MANAGERS,1,1,0,GRANTED
CHG-001,change,CAB_66,CAB,3,2,1,GRANTED

Le lab calcule :

TCK-002 : 1 / 1 = 100 % → accordé
CHG-001 : 2 / 3 = 66 % → accordé au seuil 66

Une validation réelle peut cibler une personne, un groupe ou plusieurs membres d’un groupe selon la configuration.

04Gouverne les refus et absences

Avant envoi
- destinataire légitime
- informations suffisantes
- délai de réponse
- règle en cas d'absence

Après réponse
- décision et commentaire
- identité du valideur
- date
- effet sur le cycle de vie

Supprimer une demande de validation ne doit pas être confondu avec changer le résultat déjà calculé.

05Écris une solution complète

situation initiale
cause ou demande traitée
étapes réalisées
résultat du test
impact résiduel
instruction au demandeur
éléments liés

Une solution peut être proposée puis approuvée ou refusée selon le workflow. Un refus doit permettre de reprendre le traitement.

06Distingue solution et clôture

SOLVED
- solution proposée
- approbation ou délai éventuel

CLOSED
- cycle terminé selon la politique

ASSIGNED après SOLVED
- solution refusée ou traitement à reprendre

Les permissions d’approbation de solution dépendent de la version et des profils configurés.

07Capitalise après revue

Le lab produit quatre candidats :

TCK-001,Réseau,Coupure réseau siège,REVIEW_BEFORE_PUBLICATION
TCK-002,Accès,Accès ERP pour nouvelle recrue,REVIEW_BEFORE_PUBLICATION
TCK-004,Réseau,Latence récurrente agence,REVIEW_BEFORE_PUBLICATION
TCK-006,Support,Bourrage imprimante,REVIEW_BEFORE_PUBLICATION

Avant publication :

retirer données personnelles et secrets
rendre la procédure générique
indiquer prérequis et versions
ajouter validation et rollback
nommer un propriétaire
fixer une date de revue
choisir visibilité et catégorie

08Utilise le lien connaissance

Une catégorie de ticket peut pointer vers une catégorie de base de connaissances. Une solution peut également être transformée en contenu de connaissance. Ce lien réduit la répétition seulement si les articles restent maintenus.

09Valide le lot

column -s, -t "$lab/output/approval-evaluation.csv"
column -s, -t "$lab/output/knowledge-candidates.csv"
bash module3-glpi-service-desk-sla.sh validate "$lab"

Projet du lot 3

Présente le service desk PME

Fournis catégories, modèles, matrice de priorité, acteurs, cycles, SLA/OLA, escalades, problème, changement, validations, solutions et candidats KB. Explique ce que le lab prouve et ce qui exige encore une instance GLPI réelle.

✓Lot 3 terminé

Tu sais organiser un service desk traçable, mesurer les engagements, gouverner les validations et transformer les solutions en connaissance sans publication automatique.