FAQ, Self-Service et Stratégie Shift-Left
1. Contexte et Objectifs
Dans le cadre de la mission Solutech-Horizon, l'enjeu est d'industrialiser le centre de services pour améliorer le MCO (Maintien en Condition Opérationnelle). Concrètement, il s'agit de quitter une gestion artisanale du support, où chaque incident est traité de zéro, pour adopter une approche standardisée reposant sur deux leviers : une base de connaissances structurée et une stratégie dite de "Shift-Left".
Le Shift-Left consiste à déplacer la résolution des incidents "vers la gauche" de la chaîne de support, c'est-à-dire au plus près de l'utilisateur. Plutôt que de faire systématiquement remonter un problème vers un expert (niveau 2 ou 3), on outille les techniciens de proximité, voire les utilisateurs eux-mêmes, pour qu'ils résolvent les cas courants grâce à une documentation claire. Résultat attendu : moins de tickets, des résolutions plus rapides, et des experts libérés pour les vrais problèmes complexes.
2. Besoins identifiés
Automatisation de l'inventaire : Déployer l'agent GLPI sur les serveurs Debian pour obtenir une remontée automatique des actifs, base indispensable d'un MCO fiable.
Standardisation documentaire : Créer une arborescence de connaissances (taxonomie) et un article maître servant de référence, afin de garantir une qualité constante et homogène des procédures, quel que soit le technicien qui les consulte.
Capitalisation (KEDB) : Mettre en place une logique de Known Error Database, c'est-à-dire transformer la résolution d'un incident technique en un article de base de connaissances réutilisable. L'idée est d'apprendre de chaque panne pour éviter qu'elle ne se reproduise sans solution documentée.
Segmentation des accès : Configurer un portail Self-Service restreint et adapté au profil tech-proxi (technicien de proximité), pour qu'il accède uniquement aux fonctions et articles pertinents pour son rôle.
3. Solution technique
Agent d'inventaire : Installation et configuration de glpi-agent sur Linux Debian pour la remontée automatique des actifs vers le serveur GLPI.
Sécurisation des flux : Communication via le protocole HTTPS. Dans le cas d'un certificat auto-signé (environnement de test), gestion via la directive no-ssl-check = 1 côté agent, qui permet à l'agent d'accepter le certificat sans validation par une autorité externe.
Arborescence de savoir : Structuration hiérarchique des connaissances dans GLPI, organisée sous une racine documentaire dédiée (par exemple une catégorie type "PROCEDURES-DEPLOIEMENT"), pour faciliter la recherche et la navigation des techniciens.
4. Réalisation
Installation de l'agent : Configuration du fichier /etc/glpi-agent/agent.cfg avec l'URL cible du serveur GLPI, puis forçage manuel de la remontée d'inventaire via la commande sudo glpi-agent --force.
Simulation d'incident : Pour tester la chaîne de diagnostic, sabotage volontaire de la configuration (saisie d'une IP serveur erronée) afin de provoquer une erreur de connexion visible dans les logs de l'agent. Cette démarche reproduit un incident réel pour valider la procédure de dépannage.
Gestion du ticket : Création d'un ticket d'incident sous l'identité du technicien de proximité (profil tech-proxi), diagnostic par l'analyse du fichier de log /var/log/glpi-agent/glpi-agent.log, puis résolution.
Industrialisation (KEDB) : Publication d'un article de base de connaissances directement à partir de la solution du ticket, afin d'enrichir le patrimoine documentaire et de rendre la procédure réutilisable lors d'un prochain incident similaire.
5. Preuves de réalisation
Capture 1 : Article de base de connaissances (Article Maître)
`
Légende : Article de la base de connaissances détaillant une procédure type (contexte, diagnostic, procédure pas-à-pas, vérification). Cet article maître sert de référence standardisée pour les techniciens et illustre la capitalisation du savoir : une procédure documentée une fois, réutilisable par toute l'équipe.
Capture 2 : Arborescence de la base de connaissances (Taxonomie)
`
Légende : Vue "Parcourir" de la base de connaissances montrant l'organisation hiérarchique par catégories. Cette taxonomie structure le patrimoine documentaire et facilite la recherche, condition essentielle pour qu'une stratégie Shift-Left fonctionne (un savoir introuvable n'est pas utilisé).
Capture 3 : Portail Self-Service
`
Légende : Page d'accueil du portail self-service avec ses fonctions principales (parcourir les articles, signaler un incident, demander un service, créer un ticket, consulter ses tickets). Ce portail incarne le Shift-Left : l'utilisateur trouve lui-même une réponse ou crée une demande cadrée, déchargeant ainsi le support de niveau 2.
Capture 4 : Recherche dans la FAQ (accueil du portail)
`
Légende : Onglet de recherche du portail self-service, présentant les articles classés par "Sujets les plus récents", "Dernières mises à jour" et "Sujets les plus populaires". L'article "Installation de l'agent GLPI sur Debian" y apparaît dans les trois colonnes, prouvant qu'il est publié et directement accessible aux utilisateurs depuis le portail.
Capture 5 : Résultat de recherche par mot-clé
`
Légende : Résultat d'une recherche sur le mot-clé "agent" dans le portail self-service. L'article remonte avec sa catégorie PROCEDURES-DEPLOIEMENT et un extrait de son contenu. Cette capture illustre le Shift-Left en action : le technicien de proximité retrouve seul la procédure par simple mot-clé, sans avoir à ouvrir un ticket auprès du support de niveau supérieur.