Un prestataire répond à un incident en dix minutes, puis le logiciel de gestion reste indisponible pendant plusieurs heures. L’entreprise découvre que le délai mis en avant concernait la prise en charge, sans engagement équivalent sur le rétablissement. Cette différence peut exister dans une offre parfaitement expliquée comme dans un devis ambigu. Pour comparer une infogérance, il faut identifier les étapes de traitement, le périmètre couvert et les dépendances. Le contrat devient utile lorsqu’il décrit ce qui se passe sur un incident concret.
En bref : prise en compte, diagnostic, contournement et rétablissement sont des étapes distinctes ; les engagements doivent être rapprochés de leurs conditions et responsables.
Nommer les étapes et leurs résultats attendus
La prise en compte peut signifier que le ticket a été reçu ou qu’une personne commence effectivement à le traiter. Le devis doit lever cette ambiguïté. Une notification automatique rassure sur la transmission, mais ne dit pas quand une investigation aura lieu. L’entreprise doit savoir quels événements sont mesurés et comment elle peut les retrouver dans le suivi d’incident.
Un contournement peut permettre de reprendre une partie du travail avant la correction complète. Il doit être décrit avec ses limites et ses éventuelles conséquences sur les données. Le responsable métier doit pouvoir décider si cette solution temporaire convient. Confondre contournement et rétablissement définitif peut masquer une dette technique ou des opérations qui devront être reprises.
Le rétablissement doit correspondre au service attendu. Un serveur qui répond au réseau n’est pas nécessairement une application accessible avec des données cohérentes. Les critères de retour doivent être précisés pour les systèmes critiques. Cette définition permet de discuter les engagements sur un résultat compréhensible, plutôt que sur une action technique choisie par défaut.
Définir la priorité avec le métier et les horaires
Un incident touchant une personne et un arrêt complet ne mobilisent pas les mêmes moyens. La grille de priorité doit intégrer l’impact et les solutions disponibles. Elle ne doit pas dépendre uniquement du vocabulaire employé dans le ticket. Un formulaire structuré peut aider à recueillir les informations nécessaires à cette qualification.
Les plages de service doivent être rapprochées des horaires réels de l’entreprise. Une équipe qui travaille tôt, tard ou le week-end doit examiner ce qui se passe en dehors de la couverture standard. Il faut savoir si l’astreinte existe, quels incidents peuvent la déclencher et comment la contacter. Un numéro disponible ne décrit pas forcément un niveau d’intervention identique à toute heure.
Les conditions de départ du délai doivent être connues. Le prestataire peut avoir besoin d’un accès, d’informations ou d’une validation du client pour avancer. Ces dépendances doivent être organisées avant l’incident. La procédure doit identifier les personnes capables de fournir une autorisation ou de confirmer un retour de service lorsque le contact principal est absent.
Dessiner les frontières entre les prestataires
Le système peut dépendre d’un éditeur, d’un hébergeur, d’un opérateur et d’un infogérant. Une panne située à une frontière peut devenir une série de renvois si personne ne coordonne le diagnostic. Le devis doit préciser qui pilote l’incident et comment les autres acteurs sont sollicités. L’entreprise ne devrait pas découvrir cette organisation au moment où son activité est bloquée.
Le périmètre doit être suffisamment détaillé : postes, réseau, applications, comptes, sauvegardes et équipements particuliers. Un inventaire incomplet rend les engagements difficiles à interpréter. Les exclusions doivent être compréhensibles, notamment lorsque le prestataire gère l’infrastructure mais pas le logiciel métier. Le responsable doit savoir comment une modification du parc actualise ce périmètre.
Les accès administratifs doivent être maîtrisés et documentés. Le prestataire a besoin de moyens d’intervention, mais l’entreprise doit conserver une capacité de reprise conforme à son organisation. La sortie de contrat mérite la même préparation : remise des informations, transfert des outils et traitement des comptes. La continuité ne concerne pas uniquement les pannes ; elle concerne aussi un changement d’intervenant.
Ces engagements doivent être rapprochés de l’ensemble de la prestation. Notre guide pour choisir un prestataire d’infogérance cloud complète cette lecture des délais par celle des moyens et des responsabilités du service.
Vérifier les engagements avec un exercice de table
Un exercice fictif peut suivre un incident depuis le signalement jusqu’au retour de l’activité. Qui ouvre le ticket ? Comment la priorité est-elle décidée ? Qui valide un redémarrage ou une restauration ? Quelles informations sont communiquées à la direction ? Ce scénario révèle les trous dans le dispositif sans demander de provoquer une panne réelle.
Le compte rendu doit rendre visibles les étapes et les temps, avec les informations manquantes ou les attentes externes. Un taux moyen ne permet pas toujours de comprendre un incident important. Les bilans doivent regarder les problèmes récurrents, les corrections durables et les actions restant à la charge du client. La relation gagne à examiner le service, plutôt qu’à compter seulement les tickets clos.
Comparer les offres consiste donc à rapprocher coût, couverture, moyens et obligations respectives. Un engagement très court sur un périmètre réduit ne se compare pas directement à une prise en charge plus large. Le choix devient plus clair lorsque chaque proposition est confrontée aux systèmes dont l’entreprise dépend et au fonctionnement qu’elle souhaite retrouver après un incident.
