FAQ - Self-Service et Stratégie Shift-Left
1. Contexte et Objectifs
Dans le cadre de la mission Solutech-Horizon, l'objectif était d'industrialiser le centre de services pour optimiser le MCO (Maintien en Condition Opérationnelle). L'enjeu est de passer d'une gestion artisanale à une gestion standardisée en mettant en place une base de connaissances structurée et une stratégie de "Shift-Left" (permettre aux techniciens de proximité et utilisateurs de résoudre des incidents grâce à la documentation).
2. Besoins identifiés
Automatisation de l'inventaire : Déploiement de l'agent GLPI sur des serveurs Debian pour une remontée automatique des actifs.
Standardisation documentaire : Création d'une arborescence de connaissances (Taxonomie) et d'un Article Maître pour garantir une qualité constante des procédures.
Capitalisation (KEDB) : Transformer la résolution d'un incident technique en un article de base de connaissances pour éviter la récurrence des erreurs.
Segmentation des accès : Configurer un portail Self-Service restreint pour le profil leo-proxi.
3. Solution technique
Agent d'inventaire sécurisé : Déploiement du glpi-agent sur l'infrastructure Linux Debian pour automatiser la remontée de la configuration matérielle et logicielle.
Sécurisation et conformité des flux : Chiffrement des échanges via le protocole HTTPS (port 443). Pour pallier l'absence d'une autorité de certification (CA) interne en environnement de recette, la directive no-ssl-check = 1 a été temporairement implémentée, avec pour recommandation de production le déploiement d'un certificat signé par une CA d'entreprise.
Cycle de vie des incidents (ITIL v4) : Intégration du processus de gestion des incidents avec la KEDB (Known Error Database). Le statut du ticket passe par les états standardisés : Nouveau > En cours (Assigné) > Résolu > Clos.
Arborescence de savoir (Taxonomie) : Structuration hiérarchique stricte sous la racine SOLUTECH-KNOWLEDGE garantissant l'indexation et la recherche rapide via le moteur de recherche du portail Self-Service.
4. Réalisation
Installation de l'agent : Configuration du fichier /etc/glpi-agent/agent.cfg avec l'URL cible https://172.16.98.138/ et forçage de l'inventaire avec sudo glpi-agent --force.
Simulation d'incident : Sabotage volontaire de la configuration (IP erronée 1.2.3.4) pour générer une erreur 500 Connection timed out dans les logs.
Gestion du ticket : Création d'un ticket d'incident sous l'identité de leo-proxi, diagnostic via l'analyse des logs (/var/log/glpi-agent/glpi-agent.log) et résolution par le compte Admin.
Industrialisation : Publication d'un article de base de connaissances (KEDB) directement depuis la solution du ticket pour enrichir le patrimoine documentaire.
5. Preuves de réalisation
Capture montrant le nom de l'utilisateur en haut à droite et son menu épuré (Profil tech-proxi).
En limitant les accès de "leo-proxi" à sa seule entité (principe du moindre privilège), on évite les erreurs de manipulation sur le reste du réseau. L'interface simplifiée lui permet de trouver ses outils plus vite et de traiter les incidents de proximité sans perdre de temps.
Capture montrant l'accès aux fiches de la base de connaissances sur l'interface de l'utilisateur "leo-proxi".
Capture de l'article d'installation de l'agent Linux tel qu'il apparaît dans la Base de connaissances.
Moins de tickets inutiles : Rendre ce guide accessible en auto-assistance permet aux utilisateurs (ou au Helpdesk) d'installer l'agent en autonomie. Cela désengorge le support de niveau 2, qui ne perd plus de temps sur des tâches répétitives.
Capture du ticket et de se fiche créée automatiquement depuis la résolution de celui-ci (KEDB).
Zéro perte de connaissances : Générer un article dès la clôture du ticket permet de capitaliser immédiatement sur la solution. Si le problème se reproduit, l'équipe n'a pas à chercher à nouveau : la solution est déjà partagée et industrialisée.
Capture de la liste des articles montrant le classement dans l'arborescence (SOLUTECH-KNOWLEDGE > ...).
Recherche instantanée : Une arborescence stricte évite aux techniciens de perdre de l'ordre en période de crise. Trouver la bonne procédure en 3 clics permet de réduire directement le temps de coupure du service pour l'utilisateur.
Capture montrant un nouvel incident lié manuellement à votre article KEDB pour prouver l'efficacité de votre base.
Efficacité prouvée : Cette liaison montre que la solution créée au ticket 1 a permis de résoudre le ticket 2 en quelques secondes, sans refaire de diagnostic. Le service devient standard, fiable et ultra-rapide.
