Gestion de projet

Pourquoi un support informatique à un seul niveau coûte plus cher qu'il n'en a l'air

Illustration abstraite de niveaux de support filtrant des tickets

« Mettons tout le monde au même niveau de support. » L'idée revient régulièrement, au nom de la simplicité : une seule équipe, un seul point d'entrée, plus de doute sur qui traite quoi. Sur le papier, c'est lisible. Dans les faits, c'est l'inverse qui arrive.

Sans filtre, les demandes les plus simples occupent les profils les plus chers. Les experts finissent par répondre à des questions de mot de passe pendant qu'un incident sur le réseau attend trois jours. On parle ici du support informatique, l'équipe qui aide les collaborateurs quand leur ordinateur ou leurs outils posent problème. Chaque demande enregistrée s'appelle un « ticket ».

Un support qui tient la route repose sur quatre niveaux, ni plus ni moins.

Les quatre niveaux, et ce que chacun doit filtrer

Niveau 0 : l'utilisateur se dépanne seul. Une foire aux questions, une base de connaissances, un portail où l'on trouve la réponse soi-même. Bien construit, ce niveau absorbe 30 à 40 % des tickets avant qu'ils n'atteignent une personne, sans coût récurrent une fois en place.

Niveau 1 : le premier contact. Une assistance généraliste qui règle les cas courants : mot de passe à réinitialiser, imprimante en panne, accès à un logiciel. Il lui faut des consignes claires, un délai de réponse garanti et l'objectif de résoudre la majorité des cas sans passer la main.

Niveau 2 : l'expertise technique. Administration des systèmes, réseau, sécurité. Les incidents complexes, les réglages avancés, les diagnostics de fond. Ces profils ne devraient pas passer leurs journées à expliquer comment changer la police d'un document.

Niveau 3 : les éditeurs et l'ingénierie. Les défauts du logiciel lui-même, les évolutions de fond, l'intervention de l'éditeur (l'entreprise qui a créé le logiciel). Rarement sollicité, mais indispensable quand le niveau 2 atteint ses limites. C'est lui qui protège l'architecture du système d'information.

Chaque niveau arrête ce qui ne le concerne pas. Sans cette séparation, le support ressemble à un entonnoir posé à l'envers : les demandes les plus simples remontent jusqu'aux profils les plus qualifiés, qui n'ont plus le temps de traiter les problèmes de fond.

Le coût caché : perdre la maîtrise technique

Le risque ne s'arrête pas à la mauvaise répartition du travail. Quand le premier niveau se réduit à suivre un script, sans marge de manœuvre et sans bouton « réparer automatiquement », le diagnostic s'arrête net. À moyen terme, c'est plus grave qu'un ticket mal orienté : la compétence technique disparaît peu à peu.

Un technicien qui ne cherche plus la cause du problème, seulement la procédure existante, n'est plus capable de traiter ce qui sort du cadre prévu. On le voit sur des demandes pourtant élémentaires. Livrer un poste sans l'environnement standard habituel peut se heurter à un « on ne sait pas faire, il n'y a pas de procédure », alors que l'opération est basique pour qui comprend le fonctionnement du système et pas seulement l'interface qui l'automatise.

C'est ce qui s'est produit lors d'une mission de migration à grande échelle dans le secteur bancaire, sur plusieurs milliers d'ordinateurs répartis à l'international. Une demande simple, livrer un poste avec un système vierge, sans l'environnement habituel du client, s'est heurtée à un support de premier niveau incapable de sortir de sa procédure. Faute de bouton prévu dans l'outil d'automatisation, la demande restait bloquée. Ce support avait pourtant été formé, des années plus tôt, à de vraies compétences techniques. Avec le temps, ce savoir s'était dilué dans le processus, remplacé par des scripts qui ne couvraient que les cas prévus à l'avance.

Un bon processus organise le travail, il ne remplace pas la compréhension de ce qu'il automatise. La différence se voit le jour où la situation sort du chemin prévu.

Ce que font les organisations qui y arrivent

Quatre pratiques reviennent dans celles où le support tient dans la durée.

  • Un engagement de service (un « SLA », pour service level agreement) propre à chaque niveau, plutôt qu'un objectif global flou qui ne responsabilise personne.
  • Des règles d'escalade écrites, qui disent quand passer la main au niveau suivant, et pas seulement connues d'une personne dans l'équipe.
  • Un suivi chiffré par niveau, pour mesurer l'efficacité de chaque filtre plutôt qu'une performance globale qui cache les déséquilibres.
  • Une base de connaissances de niveau 0 mise à jour à partir des tickets les plus fréquents du niveau 1, au lieu d'être écrite une fois puis abandonnée.

Le niveau unique reste tentant parce qu'il semble plus simple à organiser. Il finit pourtant par surcharger les profils essentiels, démotiver les techniciens réduits à exécuter, et frustrer les utilisateurs eux-mêmes. C'est l'inverse de ce qu'on cherchait.

Damien JEAN-BAPTISTE Fondateur, Thrill Strategy

Un chantier similaire chez vous ?

Décrivez votre contexte, nous verrons ensemble par où commencer.

Parlons-en