IT, data & développement / /8 min de lecture
Messages Teams, appels directs, couloir, courriels : quand les demandes d'assistance arrivent par tous les canaux, voici comment une petite équipe informatique peut canaliser le flux, trier ce qui relève du premier niveau et protéger son temps pour les projets.
Lundi, 8 h 40, dans une entreprise de logistique de cent vingt salariés répartis sur un siège et deux entrepôts. Le responsable informatique n’a pas encore enlevé sa veste qu’il a déjà reçu quatre messages sur Teams, deux appels sur son portable et une visite au bureau. Une préparatrice ne peut plus se connecter au terminal de l’entrepôt, un commercial n’arrive pas à synchroniser sa messagerie sur son nouveau téléphone, la comptable signale que l’imprimante du deuxième étage imprime des pages blanches, et le directeur financier demande un accès au dossier partagé de la paie pour un nouvel arrivant. Son collègue, seul autre membre du service, est en télétravail et reçoit ses propres sollicitations. Le projet de migration des serveurs de fichiers, prévu depuis trois mois, attendra encore.
Cette scène est familière dans beaucoup de PME et d’ETI dont l’équipe informatique compte deux à cinq personnes. Le problème n’est pas l’incompétence ni la mauvaise volonté des utilisateurs. C’est l’absence de canal, de tri et de répartition. Ce guide part de cette situation pour décrire, concrètement, comment reprendre la main sur l’assistance utilisateur sans y engloutir toute l’équipe.
Commencer par fermer les portes latérales
La première décision est la plus difficile politiquement : faire passer toutes les demandes par un point d’entrée unique. Tant que chaque utilisateur peut interpeller le technicien de son choix par le canal de son choix, il est impossible de prioriser, de répartir la charge ou même de savoir combien de demandes arrivent réellement. L’outil importe moins que la règle. Un service desk comme GLPI, Freshservice, Jira Service Management, ou le module d’assistance déjà inclus dans votre outil de gestion de parc fait très bien l’affaire, avec une adresse de courriel qui crée automatiquement un ticket et, si possible, un formulaire simple accessible depuis l’intranet.
La règle doit être portée par la direction, pas seulement par l’équipe informatique. Dans notre entreprise de logistique, le directeur général l’annonce en réunion : toute demande passe par le portail ou l’adresse dédiée, sauf incident bloquant pour plusieurs personnes, qui justifie un appel à un numéro unique. Pendant quelques semaines, les techniciens répondent aux sollicitations directes par une phrase courtoise : « Je te propose d’ouvrir un ticket, je le prends dès qu’il arrive. » La transition est inconfortable, mais elle est incontournable.
Il faut aussi accepter une exception pour les dirigeants et les situations critiques, sans quoi la règle sera contournée par le haut. Un circuit prioritaire clairement défini vaut mieux qu’une règle rigide que tout le monde enfreint discrètement.
Comprendre ce qui arrive avant de décider qui le traite
Après quatre à six semaines de centralisation, l’équipe dispose enfin de données. C’est le moment de catégoriser les tickets reçus. Dans la plupart des PME, on retrouve les mêmes grandes familles : gestion des comptes et des mots de passe, droits d’accès aux dossiers et applications, messagerie et agenda, postes de travail et périphériques, téléphonie et mobiles, applications métier, réseau et connexion à distance, arrivées et départs de collaborateurs.
L’analyse montre en général qu’une part importante des tickets relève de demandes simples et répétitives : réinitialisation de mot de passe, déblocage de compte, ajout à une liste de diffusion, installation d’un logiciel autorisé, configuration d’un poste pour un nouvel arrivant. Ces demandes ne sont pas difficiles, mais elles sont nombreuses et interrompent sans cesse le travail de fond. Elles représentent souvent plus de la moitié des tickets, pour une part bien moindre du temps de résolution.
Cette analyse révèle aussi les causes récurrentes. Dans l’entreprise de logistique, une bonne partie des appels de l’entrepôt concerne les terminaux de lecture de codes-barres qui perdent leur connexion au réseau sans fil dans une zone précise du bâtiment. Aucun nombre de techniciens ne réglera ce problème ticket par ticket. Il faut un point d’accès supplémentaire. Classer les demandes sert donc autant à les répartir qu’à identifier les corrections durables.
Définir un premier niveau qui résout vraiment
Une fois les familles identifiées, l’organisation classique consiste à distinguer plusieurs niveaux. Le premier niveau reçoit toutes les demandes, qualifie, résout ce qui est documenté et escalade le reste avec un ticket complet. Le deuxième niveau traite les incidents plus techniques, les configurations spécifiques et les problèmes applicatifs. Le troisième niveau, souvent l’éditeur ou un prestataire spécialisé, intervient sur l’infrastructure ou le code.
L’erreur fréquente est de concevoir un premier niveau qui se contente de transmettre. Un premier niveau qui ne résout rien ajoute un intermédiaire et allonge les délais, ce qui décourage les utilisateurs. Pour qu’il soit utile, il faut lui donner à la fois des procédures et des droits : pouvoir réinitialiser un mot de passe dans l’annuaire, débloquer un compte, ajouter un utilisateur à un groupe de sécurité prédéfini, prendre la main à distance sur un poste, relancer un service d’impression. Ces délégations se préparent avec soin, en limitant les droits au strict nécessaire et en traçant les actions.
Le ticket escaladé doit aussi être de qualité. Un bon premier niveau fournit au technicien de deuxième niveau le nom de l’utilisateur, le poste concerné, le message d’erreur exact, les étapes déjà tentées et l’impact métier. Ce travail de qualification, souvent négligé, fait gagner un temps considérable aux profils les plus rares de l’équipe.
Construire la base de connaissances à partir des tickets réels
La base de connaissances est souvent présentée comme un projet à part, que l’on fera un jour. En pratique, elle se construit beaucoup mieux au fil de l’eau, à partir des tickets réellement résolus. La règle peut être simple : chaque fois qu’un problème est résolu pour la troisième fois, une fiche est rédigée. Elle décrit le symptôme tel que l’utilisateur le formule, le diagnostic et la résolution, avec des captures d’écran quand c’est utile.
Ces fiches servent deux publics. Le premier est l’équipe de support elle-même, qui peut ainsi confier davantage de familles de demandes au premier niveau. Le second est l’utilisateur final, pour une partie des fiches seulement : comment configurer sa messagerie sur un nouveau téléphone, comment se connecter au VPN, comment partager un dossier. Une page d’aide bien rangée, accessible depuis le portail de tickets, réduit une partie des demandes, à condition qu’elle soit maintenue. Une base de connaissances obsolète fait plus de mal que de bien, car elle envoie les utilisateurs sur de fausses pistes.
Les arrivées et départs de collaborateurs méritent une attention particulière. Prenons un cabinet d’expertise comptable de quarante personnes qui recrute chaque année plusieurs alternants et collaborateurs en septembre. Sans procédure écrite, chaque arrivée mobilise l’informatique pendant une demi-journée, avec des oublis fréquents : licence non attribuée, accès au logiciel de production manquant, compte de l’ancien collaborateur jamais désactivé. Une liste de contrôle partagée avec les ressources humaines, déclenchée par un ticket dès la signature du contrat, transforme ce moment chaotique en routine.
Mesurer peu, mais régulièrement
Un dispositif d’assistance se pilote avec quelques indicateurs : le nombre de tickets par semaine et par famille, le délai de première prise en charge, le délai de résolution, la part de tickets résolus au premier niveau et le nombre de tickets rouverts. Un court questionnaire de satisfaction envoyé à la clôture donne également une indication utile, à condition de le garder très court.
Ces chiffres servent à trois choses. Ils permettent de repérer les dérives, par exemple une famille de tickets qui explose après une mise à jour logicielle. Ils donnent des arguments objectifs lors des arbitrages budgétaires, quand il faut justifier un renfort ou un investissement. Et ils rendent visible le travail de l’équipe informatique, souvent perçu comme une fonction qui ne se voit que lorsqu’elle échoue. Il faut éviter en revanche de transformer ces indicateurs en objectifs individuels de vitesse, qui poussent à clôturer trop vite des tickets mal résolus.
Un premier niveau d’assistance tenu par une équipe dédiée à Madagascar
Lorsque le volume de demandes simples justifie un premier niveau à part entière mais qu’aucun recrutement local n’est prévu, Dedicateam propose de confier ce premier niveau à une équipe dédiée à Madagascar. L’axe principal de notre accompagnement est ici la composition et l’intégration de l’équipe : des techniciens support francophones recrutés pour votre contexte, rattachés à votre responsable informatique et travaillant dans votre outil de tickets, avec les droits délégués que vous aurez définis. Ils qualifient les demandes, résolvent celles qui sont documentées, préparent les arrivées et départs selon vos listes de contrôle et rédigent les fiches de la base de connaissances.
Avant le démarrage, nous travaillons avec vous sur le périmètre exact du premier niveau, les procédures d’escalade vers votre équipe interne et les délégations de droits sur l’annuaire et les applications. La montée en charge est progressive : l’équipe commence par les familles de demandes les plus simples, puis élargit son périmètre à mesure que les fiches de résolution s’enrichissent. Cette forme d’externalisation informatique conserve la décision technique chez vous, tandis que la sous-traitance porte sur le traitement quotidien du flux.
Le décalage horaire réduit entre Madagascar et la France permet de couvrir vos heures de bureau, et éventuellement une plage élargie en début ou fin de journée. Les accès se font via vos outils de prise en main à distance, avec des comptes nominatifs et une traçabilité complète des actions. Ce support offshore fonctionne comme un prolongement de votre service informatique plutôt que comme un centre d’appels mutualisé.
Notre approche : canaliser et qualifier vos demandes d’assistance, puis confier le premier niveau à une équipe dédiée intégrée à votre service, pour que vos techniciens retrouvent du temps pour les projets.