Qu’est-ce qu’une demande ?
Une demande, c’est quand un utilisateur veut quelque chose de nouveau ou de différent. Rien n’est en panne, mais il a un besoin.
Exemples :
- “Je voudrais un accès au dossier Finances.”
- “On peut m’installer Teams ?”
- “J’ai besoin d’un PC portable pour le télétravail.”
Ce n’est pas un incident (rien ne dysfonctionne) ni un changement (pas de modification d’infrastructure). C’est une demande de service.
Pourquoi distinguer demandes et incidents ?
Parce qu’on ne les traite pas de la même façon :
| Incident | Demande | |
|---|---|---|
| Nature | Quelque chose est en panne | Quelque chose est souhaité |
| Urgence | Souvent élevée | Généralement planifiable |
| Objectif | Restaurer le service | Fournir un service |
| Priorité | Selon l’impact | Selon la politique interne |
Mélanger les deux, c’est risquer de traiter “je veux un deuxième écran” avant “plus personne n’a accès aux mails”.
Le catalogue de services
Idéalement, les demandes possibles sont définies dans un catalogue de services :
- Ce qu’on peut demander
- Qui peut le demander
- Quel est le délai standard
- Quelle est la procédure d’approbation (si nécessaire)
Exemple de catalogue simplifié :
| Demande | Délai | Approbation |
|---|---|---|
| Nouveau compte utilisateur | 1 jour | Manager |
| Accès VPN | 2 jours | Manager + IT |
| Installation logiciel standard | 1 jour | Aucune |
| Installation logiciel spécifique | 5 jours | Manager + IT |
| Nouveau poste de travail | 5-10 jours | Manager + Budget |
Les étapes de traitement d’une demande
1. Réception et enregistrement
Comme pour les incidents : tout doit être tracé. Même les petites demandes.
Informations à collecter :
- Qui demande ?
- Quoi exactement ?
- Pour quand ? (besoin réel, pas “le plus vite possible”)
- Pourquoi ? (ça aide à proposer la bonne solution)
2. Validation
Certaines demandes nécessitent une approbation :
- Le manager valide-t-il ?
- Y a-t-il un budget ?
- Est-ce conforme à la politique de sécurité ?
“Je voudrais les droits administrateur sur mon PC” → probablement non.
3. Réalisation
Une fois validée, la demande est réalisée selon la procédure standard (si elle existe) ou de manière ad hoc.
Astuce : si une demande revient souvent et n’a pas de procédure, c’est le moment d’en créer une.
4. Clôture et communication
- Informer l’utilisateur que c’est fait
- Vérifier que ça correspond au besoin
- Documenter si nécessaire (accès accordés, matériel attribué, etc.)
Les pièges à éviter
Accepter tout sans validation : “Oui oui, je t’installe ça.” Et trois mois plus tard, on découvre un logiciel non licencié sur 50 postes.
Traiter les demandes comme des incidents : Elles passent en priorité haute alors qu’elles pouvaient attendre.
Ne pas tracer : “J’ai donné l’accès à Pierre au dossier RH.” Qui ? Quand ? Validé par qui ? Plus personne ne sait.
Oublier le demandeur : La demande est faite, mais personne ne l’a prévenu. Il relance, vous avez l’impression de faire le travail deux fois.
Demandes récurrentes : automatiser !
Si une demande revient 10 fois par semaine, c’est qu’il faut :
- Soit l’automatiser (script, portail self-service)
- Soit revoir le processus en amont
Créer un compte utilisateur manuellement à chaque embauche, c’est bien. Avoir un workflow automatisé déclenché par les RH, c’est mieux.
En résumé
- Distinguer demande et incident
- Définir un catalogue de services (même simple)
- Valider avant de réaliser
- Tracer systématiquement
- Communiquer avec le demandeur
- Automatiser ce qui peut l’être