Le chiffre est séduisant… Selon les bonnes pratiques ITSM, 65% des tickets devraient être clôturés par le support de niveau 1. Sur le papier, cela ressemble à une cible de bon sens : résoudre au plus près de l’utilisateur, réduire les délais, limiter les escalades et libérer du temps aux niveaux 2 et 3 pour les sujets complexes et du projet.

Sur le terrain : plus simple à dire qu’à faire … Puisque fermer un ticket en N1 ne consiste pas à dérouler un script. Cela suppose de diagnostiquer, d’isoler une cause probable, de prendre une décision d’action ou d’escalade qui tienne la route. Autrement dit, de réfléchir comme un ingénieur, sur un périmètre cadré.

C’est ici que la notion du « Shift Left » prend tout son sens. Pas comme un slogan qui transfère la charge vers le support de proximité, mais comme un choix de conception de la chaîne de support. Pour rappel, le « Shift Left » consiste à déplacer la résolution des tickets le plus en amont possible, au plus près de l’utilisateur en renforçant le Self-service et le Support N1.

Pour qu’une part significative des tickets soit réellement traitable au Niveau 1, il faut investir dans trois fondations :

  • La compétence, via une montée en compétence structurée. 
  • La connaissance, via une base exploitable et correctement maintenue. 
  • L’autonomie, via des accès et des outils qui permettent d’enquêter sereinement. 

Sans ces conditions, le 65% devient un indicateur de frustration, pas de performance.

 

1.D’où vient l’objectif des 65% et pourquoi est-il rarement atteint ?

L’objectif des 65% est souvent présenté comme une référence issue des bonnes pratiques ITIL. L’idée est simple : un support de niveau 1 bien structuré devrait résoudre la majorité des sollicitations courantes, celles qui sont répétitives, maitrisées et standardisables. Cela permet de réduire les délais de traitement, de limiter les escalades mécaniques et de concentrer les niveaux 2 et 3 sur les sujets qui demandent une expertise ou une analyse approfondie.

Le problème est que ce chiffre devient vite une cible hors sol quand on le découple des conditions de réussite.
Dans beaucoup de DSI, le flux de tickets n’est majoritairement pas composé de demandes simples. On y trouve un mélange d’incidents, de demandes, de sujets applicatifs, de problèmes d’identité, de dégradations intermittentes ou bien même du fonctionnement standard non compris/accepté … Le support N1 se retrouve alors face à une variabilité élevée, avec peu de standardisation, donc peu d’industrialisation possible.

Sur le terrain, les causes d’échec sont donc récurrentes :

  • Catalogue de services : des catégories trop larges et un tri initial imprécis, ce qui crée des boucles de réassignation
  • Gouvernance : des règles d’escalade floues ou défensives 🡪 on escalade pour se protéger, répondre à des SLA temporels plutôt que par nécessité 
  • Gestion des connaissances : 
    • Une connaissance dispersée et des réponses qui restent orales, donc impossibles à répliquer à l’échelle
    • Des équipes N2 et N3 qui ne capitalisent pas, ce qui empêche le N1 de monter en autonomie

Enfin, il faut remettre les indicateurs à leur place. Le pourcentage de clôture par le N1 n’a de valeur que s’il sert la qualité de service rendu ! 

Dans certaines DSI, c’est même l’unique boussole, satisfaction utilisateur, délais, stabilité des résolutions, taux de réouverture. Si la qualité se dégrade, atteindre 65% n’apporte rien. Cela prouve seulement que l’on a déplacé le problème.

 

2. L’exigeante montée en compétence du support N1

La montée en compétence du support N1 est généralement le point de bascule.
Tant que le N1 applique des procédures figées, il résout surtout ce qui est évident. Dès qu’un ticket demande un minimum de diagnostic, l’escalade redevient la norme. L’objectif n’est pas de transformer le N1 en N2. L’objectif est de lui donner une capacité d’analyse fiable. Comprendre un symptôme, poser les bonnes questions, vérifier quelques hypothèses simples, et décider d’une action ou d’une escalade argumentée. En clair, faire de l’ingénierie, sur un périmètre cadré.

C’est pour cela que les formations initiales ne suffisent plus. Elles donnent des gestes, rarement un raisonnement. La montée en puissance doit être continue, ancrée dans le réel, avec des retours sur tickets, des cas concrets, et des temps réguliers de partage.

La notion de « Former le formateur », phase directement incluse dans la méthodologie de gestion de projet SI, est souvent la méthode la plus efficace. Les experts N2 et N3 forment des référents N1, qui diffusent ensuite les pratiques et stabilisent un socle commun. Cela évite le goulot d’étranglement des experts et accélère la capitalisation.

Cette dynamique ne tient pas sans une base de connaissances exploitable. Une base utile décrit des symptômes, une séquence de vérifications, des critères de résolution et des critères d’escalade. Elle doit être gouvernée et intégrée au quotidien du support, garantie par des phases de clôture projet efficace.

Enfin, il faut traiter la question des accès. Sans droits adaptés, le N1 reste aveugle.
Le sujet n’est pas de tout ouvrir, c’est de définir un périmètre d’actions autorisées, traçables, sécurisées, qui permette d’enquêter et de corriger sans escalader par défaut.

 

3. Les outils du quotidien pour enquêter

Même avec un N1 compétent et une base de connaissance solide, l’autonomie du N1 échoue si le support reste aveugle. Pour résoudre, il faut enquêter. Pour enquêter, il faut des outils qui donnent du contexte rapidement, sans dépendre systématiquement d’un niveau supérieur.

La CMDB joue ici un rôle central, à condition d’être utile.
Une CMDB n’est pas un inventaire exhaustif. C’est un modèle de donnée dynamique, utilisé pour diagnostiquer. Elle doit permettre d’identifier le service concerné, les composants associés, les dépendances critiques et les équipes responsables. La valeur ne vient pas de la couverture théorique, mais de la fiabilité sur un périmètre ciblé, celui qui génère le plus de tickets et d’impacts.

À côté de la CMDB, le N1 a besoin d’une visibilité opérationnelle.
Monitoring, supervision, observabilité : ce qui est souhaité, c’est l’accès à des signaux forts. Quel service est dégradé ? Depuis quand ? Est-ce que d’autres utilisateurs sont touchés ? Est-ce qu’un changement récent peut expliquer le symptôme ? Sans cette visibilité, le N1 escalade par manque d’information et de maitrise, pas par manque de compétence.

Enfin, il faut penser les outils du quotidien : outils poste de travail, identité, réseau, télédistribution, prise en main, tests de connectivité. Et évidemment, l’intégration avec l’ITSM.
Liens directs entre alertes et tickets, association automatique à un service ou à un composant (le « Configuration Item »), accès immédiat aux articles de connaissance pertinents. Chaque minute passée à chercher l’information est une minute qui pousse vers l’escalade.

Un support N1 efficace, ce n’est pas un support qui clique vite. C’est un support qui voit clair et qui dispose des moyens de vérifier ses hypothèses.

 

Conclusion

L’efficience du support ne se décrète pas et ne peut pas reposer sur le N1 seul. 

Si nous voulons augmenter la part de tickets résolus au 1er niveau sans dégrader la qualité, il faut repenser le modèle. L’ITSM devient est discipline collective. Les équipes Infrastructure et Projet doivent contribuer à la connaissance, à la standardisation, à la traçabilité et à la qualité des changements.
Sans cette contribution, le N1 absorbe la complexité, sans pouvoir la réduire, et la redistribue. 

La qualité du support ne révèle qu’une chose : le niveau de maturité opérationnelle de la DSI … Raison pour laquelle les éditeurs de logiciels mettent autant d’effort sur le Customer Success Management.