Quelle différence entre GTI et GTR ?

La GTI (garantie de temps d'intervention) fixe le délai maximal avant qu'un technicien commence à traiter un incident. La GTR (garantie de temps de rétablissement, ou de résolution) fixe le délai maximal avant que le problème soit réellement réglé.

Existe-t-il des délais standard par priorité ?

Non. Les correspondances entre priorité et délai relèvent de la politique de chaque équipe, pas d'une règle universelle. Les chiffres publiés sont des exemples.

Mes délais peuvent-ils être plus courts que ceux de l'éditeur ?

Pour la prise en charge, oui : vous pouvez accuser réception vite. Pour la résolution d'un problème qui dépend de la plateforme, non : vous ne pouvez pas promettre plus que ce que l'éditeur vous garantit.

Délai de prise en charge et délai de résolution

Le délai de prise en charge est le temps qui s'écoule avant que quelqu'un commence à traiter une demande. Le délai de résolution est le temps avant que le problème soit réglé. Dans les contrats informatiques, on les appelle souvent GTI (garantie de temps d'intervention) et GTR (garantie de temps de rétablissement, ou de résolution) : « La GTI fixe le délai maximal avant qu'un technicien commence à traiter un incident », et « la GTR fixe le délai maximal avant que ce problème soit réellement résolu » (ELS Conseil, consulté le 15/11/2026).

Les deux ne se confondent pas : une prise en charge rapide « ne garantit pas que le problème soit réglé aussi rapidement ». Cette page traite de l'organisation de ces délais dans votre support. La rédaction de la clause elle-même, dans un contrat de niveau de service, est un sujet juridique à part : faites relire vos engagements par un avocat avant de les signer.

Étape 1 : classer chaque demande par priorité

On ne promet pas le même délai pour un assistant en panne chez tous vos clients et pour une question sur la couleur d'un bouton. La méthode la plus répandue croise deux critères :

l'impact : combien d'utilisateurs ou de clients sont touchés, et à quel point ;
l'urgence : à quelle vitesse la situation fait du tort, et s'il existe un contournement.

Le croisement donne une priorité, souvent de P1 (critique) à P4 (faible). Voici la grille proposée par l'éditeur d'outils de support Jitbit (Jitbit, consulté le 15/11/2026) :

Impact \ Urgence	Élevée	Moyenne	Faible
Élevé	P1	P2	P3
Moyen	P2	P3	P4
Faible	P3	P4	P4

La même source le dit sans détour : les correspondances entre priorité et délai sont « la politique de votre équipe », et non une exigence universelle du référentiel ITIL (un ensemble de bonnes pratiques de gestion des services informatiques).

Étape 2 : associer un délai à chaque priorité

Jitbit donne des délais « indicatifs » par priorité. Ils sont repris ici comme hypothèse de départ, pas comme une norme :

Priorité	Exemple pour un assistant IA (illustration)	Délai indicatif cité par Jitbit
P1 critique	L'assistant ne répond plus, sans contournement	1 à 2 heures
P2 élevée	Réponses très lentes, mais un contournement existe	4 à 8 heures
P3 moyenne	Un défaut limité à une fonction ou à un utilisateur	24 à 48 heures
P4 faible	Demande d'accès, question d'usage	3 à 5 jours ouvrés

Une source française conseille de fixer les délais selon l'importance de ce qui est touché plutôt que de façon uniforme ; elle cite l'exemple d'une GTI de deux heures (ELS Conseil). Pour un assistant, la question à poser est : que perd le client tant que l'assistant ne fonctionne pas ? Un assistant de prise de rendez-vous en panne coûte davantage qu'un assistant d'information interne.

Étape 3 : préciser les heures couvertes

Un délai sans plage horaire ne veut rien dire. « 4 heures » en heures ouvrées, du lundi au vendredi de 9 h à 18 h, n'a rien à voir avec 4 heures 24 heures sur 24. Écrivez :

les jours et heures où le délai court ;
ce qui se passe hors de ces heures (la demande est enregistrée et traitée à la reprise) ;
le point de départ du délai : la réception de la demande, ou sa qualification.

Jitbit recommande de convenir des heures couvertes, des délais et des responsables d'escalade avant de s'en servir dans des engagements envers les clients.

Étape 4 : vérifier la cohérence avec l'éditeur

C'est le point propre à une offre revendue. Votre délai de résolution, pour tout ce qui dépend de la plateforme, ne peut pas être plus court que celui que l'éditeur vous garantit. Prenons une hypothèse : l'éditeur s'engage à prendre en charge un incident critique en 4 heures ouvrées. Si vous promettez à votre client une résolution en 2 heures, vous promettez ce que vous ne maîtrisez pas.

En pratique :

Demandez à l'éditeur ses délais par priorité, par écrit (voir qui fait quoi entre partenaire et éditeur).
Pour ce que vous traitez vous-même (usage, contenu, réglages), fixez vos propres délais.
Pour ce qui remonte à l'éditeur, alignez-vous sur ses délais, en ajoutant le temps de transmission.
Gardez un délai de prise en charge court dans tous les cas : accuser réception et qualifier la demande dépend de vous seul.

Étape 5 : mesurer, puis ajuster

Un délai promis se vérifie. Votre outil de tickets doit dater chaque étape : réception, prise en charge, transmission à l'éditeur, résolution. Si une demande dépasse son délai, c'est un motif d'escalade : la grille d'IT Systèmes cite « le délai prévu est dépassé » parmi les raisons de passer au niveau supérieur. Voir la procédure d'escalade et le choix d'un outil de tickets.