IT, data & développement / /8 min de lecture
Anomalies signalées par mail, demandes d'évolution mêlées aux incidents, développeurs interrompus en permanence : un guide pratique pour organiser la réception, la qualification et le suivi des demandes sur vos applications métier, tout en gardant les utilisateurs informés.
Une application métier en production génère un flux continu de demandes. Un utilisateur ne parvient plus à éditer un bon de livraison, un autre signale un écran qui met trente secondes à s’afficher, une responsable d’agence demande l’ajout d’un champ dans un formulaire, le service comptable s’étonne d’un arrondi dans un export. Dans beaucoup d’entreprises, ces demandes arrivent par tous les canaux à la fois : mail direct au développeur qui a créé l’écran, message sur la messagerie interne, appel au responsable informatique, remarque en réunion. Chacune semble légitime. Ensemble, elles produisent deux effets bien connus : les développeurs passent leurs journées interrompus et n’avancent plus sur les projets, et les utilisateurs ne savent jamais si leur demande a été prise en compte.
Ce guide part de cette situation, typique d’une PME ou d’une ETI qui fait vivre une ou plusieurs applications métier, développées en interne ou par un prestataire. Il décrit comment organiser le suivi de la maintenance applicative pour que les incidents bloquants soient traités vite, que les demandes moins urgentes ne disparaissent pas et que l’équipe technique retrouve du temps de développement.
Le vrai problème : un flux non qualifié qui arrive directement chez les développeurs
Prenons une entreprise de distribution de pièces détachées de cent vingt salariés. Elle utilise un outil de gestion des commandes et des stocks développé sur mesure, maintenu par deux développeurs internes et un prestataire pour les évolutions importantes. Au fil des années, les utilisateurs ont pris l’habitude d’écrire directement au développeur qu’ils connaissent. Celui-ci répond, corrige quand il peut, oublie parfois. Aucune trace n’existe en dehors des boîtes mail.
Quand on reconstitue le flux sur un mois, plusieurs constats apparaissent. Une part importante des demandes ne sont pas des anomalies : ce sont des questions d’utilisation, des problèmes de droits d’accès, des manipulations mal comprises. Une autre part concerne des incidents déjà connus, signalés plusieurs fois par des utilisateurs différents. Les vraies anomalies nouvelles et les demandes d’évolution ne représentent qu’une fraction du total. Pourtant, toutes passent par les développeurs, qui doivent à chaque fois comprendre le contexte, demander des précisions et reproduire le problème.
Le cœur du sujet n’est donc pas la capacité de correction, mais l’absence de filtre entre l’utilisateur et le développeur. Tant que ce filtre n’existe pas, recruter un troisième développeur ne ferait que répartir les interruptions sur trois personnes.
Mettre en place un point d’entrée unique et un formulaire qui fait gagner du temps
La première étape consiste à faire passer toutes les demandes par un outil de tickets. Que ce soit Jira Service Management, GLPI, Zendesk, Freshservice ou un autre, le choix de l’outil importe moins que la règle : une demande non saisie dans l’outil n’existe pas. Cette règle doit être annoncée clairement aux utilisateurs, et respectée par les développeurs eux-mêmes, qui redirigent poliment les sollicitations directes vers le formulaire.
Le formulaire joue un rôle décisif. Un ticket intitulé « ça ne marche pas » oblige à un aller-retour de questions. Un formulaire bien conçu demande d’emblée l’application et l’écran concernés, ce que l’utilisateur essayait de faire, ce qui s’est passé, le message d’erreur exact, une capture d’écran, le nombre de personnes touchées et l’existence ou non d’un moyen de continuer à travailler. Ces quelques champs, qui prennent une minute à remplir, font souvent gagner une demi-heure au moment du traitement.
Il faut aussi distinguer dès l’entrée les grandes natures de demandes : incident (quelque chose qui fonctionnait ne fonctionne plus), question d’utilisation, demande d’accès, demande d’évolution. Ces catégories n’ont pas le même circuit ni les mêmes délais, et les mélanger dans une seule file conduit à traiter les évolutions faciles avant les incidents gênants.
Qualifier avant de transmettre : le rôle du niveau 1
Entre l’utilisateur et le développeur, il faut une étape de qualification. C’est le rôle d’un support de premier niveau, qui n’a pas besoin d’écrire du code mais doit bien connaître l’application et ses usages. Pour chaque ticket entrant, il vérifie que les informations sont complètes et les complète au besoin en contactant l’utilisateur. Il cherche si l’incident est déjà connu et, dans ce cas, rattache le ticket au ticket principal. Il tente de reproduire le problème dans un environnement de test. Il répond directement aux questions d’utilisation à l’aide de la base de connaissances et traite les demandes d’accès selon les règles définies.
Il attribue ensuite un niveau de priorité selon une grille simple, fondée sur deux critères : l’impact (un utilisateur, un service, toute l’entreprise) et l’urgence (existe-t-il un contournement ou le travail est-il bloqué ?). Un incident qui empêche l’ensemble des préparateurs de valider leurs expéditions est critique. Un défaut d’affichage sur un rapport mensuel consulté par deux personnes est mineur. Seuls les tickets qualifiés, reproduits et priorisés parviennent aux développeurs, avec toutes les informations nécessaires.
Dans l’entreprise de distribution évoquée plus haut, ce filtre a un effet direct : une large part des demandes est traitée sans intervention des développeurs, et les tickets qui leur parviennent sont exploitables immédiatement. La mise en place d’un tel niveau 1 peut se faire en interne, en formant un utilisateur avancé, ou avec une ressource externalisée qui connaît l’application et travaille dans l’outil de tickets.
Tenir les utilisateurs informés, même quand la correction prend du temps
Un utilisateur bloqué supporte mieux un délai lorsqu’il sait où en est sa demande. Beaucoup de frustrations naissent non pas de la lenteur de la correction, mais du silence. Chaque ticket doit donc recevoir un accusé de réception indiquant sa priorité et le délai prévisible de prise en charge. Chaque changement de statut, qu’il s’agisse d’une prise en charge, d’une attente d’information, d’une correction en test ou d’une mise en production prévue, doit être visible par le demandeur.
Lorsqu’un contournement existe, il faut le communiquer tout de suite, même si la correction définitive viendra plus tard. « En attendant la correction, vous pouvez éditer le bon depuis l’écran de recherche des commandes » permet à l’utilisateur de reprendre son travail. Pour les incidents qui touchent beaucoup de monde, un message général évite de recevoir cinquante tickets identiques. Enfin, les mises en production qui corrigent des anomalies connues doivent être annoncées avec une note courte, pour que les utilisateurs sachent que le problème est résolu et qu’ils ne gardent pas leurs anciennes habitudes de contournement.
Transformer les tickets en améliorations, et protéger le temps de développement
Un outil de tickets bien tenu devient une source d’information précieuse. En regardant chaque mois les catégories et les écrans les plus sollicités, on repère les défauts récurrents qui mériteraient une correction de fond, les écrans dont l’ergonomie provoque des erreurs d’utilisation et les besoins de formation. Les questions répétées alimentent la base de connaissances, qui réduit à son tour le volume de tickets.
Il est aussi utile de séparer clairement la maintenance corrective des évolutions. Les demandes d’évolution rejoignent un carnet de demandes, arbitré régulièrement avec un représentant métier, selon leur valeur et leur coût. Elles ne doivent pas être traitées au fil de l’eau par le développeur le plus sollicité. De même, l’équipe technique peut réserver des plages fixes à la maintenance, par exemple une personne d’astreinte par semaine sur les tickets pendant que les autres avancent sur les projets. Cette rotation protège le temps de développement et rend le traitement des incidents plus régulier.
Quelques indicateurs suffisent pour piloter l’ensemble : délai de première réponse, délai de résolution par niveau de priorité, nombre de tickets ouverts par ancienneté, et part des tickets résolus au premier niveau. Suivis mensuellement, ils permettent de voir si l’organisation tient ou si un goulet se forme.
Un support applicatif de premier niveau dédié à Madagascar, intégré à votre outil de tickets
Dedicateam met en place des équipes dédiées à Madagascar pour assurer le premier niveau de support sur les applications métier de ses clients : réception et qualification des tickets, reproduction des anomalies en environnement de test, réponses aux questions d’utilisation, gestion des demandes d’accès selon vos règles, tenue de la base de connaissances et information des utilisateurs sur l’avancement. Les corrections, les évolutions et les arbitrages restent chez vos développeurs ou votre prestataire.
Pour ce sujet, nous mettons l’accent sur l’outillage. Avant le démarrage, nous travaillons avec votre équipe technique sur la configuration de l’outil de tickets : catégories, formulaires, grille de priorités, statuts, modèles de réponses, règles d’escalade vers le niveau 2. L’équipe dédiée est ensuite formée à votre application, à partir de sessions avec vos développeurs et d’une documentation construite au fil des premières semaines. Les accès sont limités à ce dont le support a besoin, en particulier sur les environnements de test et les données de production.
L’externalisation informatique à Madagascar permet de disposer d’un support dédié qui travaille sur vos horaires grâce au faible décalage avec la France, et dont la taille peut évoluer avec le nombre d’applications et d’utilisateurs. Cette collaboration à distance fonctionne dans vos outils existants, avec un interlocuteur Dedicateam chargé du suivi de la qualité et des indicateurs.
Notre approche : configurer avec vous un circuit de tickets clair, puis confier la qualification et le suivi des demandes à une équipe dédiée à Madagascar pour que vos développeurs reçoivent des tickets exploitables et que vos utilisateurs sachent toujours où en est leur demande.