Passer d’une infogérance réactive à une infogérance proactive n’est pas une question de « meilleur technicien » : c’est un changement de modèle économique. En mode réactif, l’organisation paie surtout l’imprévu. Les incidents interrompent la production, monopolisent des personnes clés, génèrent des arbitrages de dernière minute (contournements, achats urgents, priorités inversées) et créent un bruit constant qui empêche l’amélioration.

Pour le chiffrer sans inventer de chiffres, partez d’une méthode simple en heures perdues, sur une base mensuelle :

1. Recenser les événements : incidents utilisateurs, indisponibilités applicatives, pannes réseau, lenteurs, échecs de sauvegarde, réinitialisations MFA, etc.
2. Estimer le temps d’arrêt par population : nombre de personnes impactées × durée d’indisponibilité (même si l’activité continue « au ralenti »).
3. Ajouter le temps de gestion : temps passé par l’IT interne, le prestataire, et les managers (coordination, validations, redémarrages, tests).
4. Qualifier le coût indirect : retards de livraison, erreurs liées au stress, re-travail, pénalités contractuelles éventuelles.

La clé est de distinguer le temps de résolution technique du temps d’impact métier : un incident « résolu » en une heure peut avoir un impact sur la journée si la reprise est progressive. Dans une PME de Franche-Comté, cette distinction aide souvent la DAF ou le COO à sortir d’une logique « ticket fermé = problème réglé ».

Enfin, le mode réactif crée un cercle vicieux : faute de capacité planifiée (patchs, nettoyage, standardisation), les causes racines persistent. Le proactif vise précisément à financer du temps de prévention en échange d’une baisse mesurable du bruit opérationnel.

Une infogérance proactive se pilote avec un ensemble d’indicateurs équilibrés. Un bon tableau de bord ne mesure pas seulement la performance du prestataire, mais aussi le niveau de risque, la qualité de l’exploitation et la prévisibilité. Voici 12 KPI utiles en PME, à adapter à votre périmètre (poste, serveur, Microsoft 365, réseau, sauvegardes, sécurité).

• Disponibilité des services critiques : définissez la liste (messagerie, ERP, accès VPN, fichiers) et le mode de mesure.
• MTTR (Mean Time To Repair) : temps moyen de rétablissement, à distinguer par criticité.
• Taux d’incidents récurrents : part des tickets liés à une cause déjà connue (mesure de la lutte contre la répétition).
• Backlog de tickets : volume et âge des tickets ouverts, par catégorie.
• Respect des délais de prise en charge : temps avant première réponse qualifiée (pas seulement un accusé).
• Conformité patch management : couverture des correctifs OS et applications, incluant les exceptions documentées.
• Couverture antivirus/EDR : endpoints protégés et à jour, plus remontée d’alertes exploitables.
• Sauvegardes : succès et test de restauration : taux de jobs réussis et preuves de restaurations testées.
• RPO/RTO observés : écart entre objectifs de reprise et réalité lors d’incidents/exercices.
• Hygiène identité et accès : comptes à privilèges, MFA, comptes orphelins, revues d’accès.
• Exposition phishing : résultats de campagnes de sensibilisation ou d’indicateurs d’alertes (à cadrer avec les RH).
• Dette technique maîtrisée : liste des obsolescences (OS, serveurs, équipements) avec plan de traitement.

L’erreur classique consiste à choisir uniquement des KPI « faciles » (nombre de tickets). Privilégiez des indicateurs qui favorisent la prévention : baisse de récurrence, montée de conformité patch, preuves de restauration, réduction de la dette. Si vous êtes sur un périmètre de maintenance informatique à Belfort, ces KPI donnent aussi un langage commun entre direction, prestataire et utilisateurs.

Pour contractualiser une infogérance proactive, il faut distinguer SLO et SLA.

• SLO (Service Level Objective) : objectif interne de performance, cible de pilotage. Il peut évoluer (amélioration continue).
• SLA (Service Level Agreement) : engagement contractuel, avec périmètre, mesure, responsabilités, et conséquences en cas de non-respect.

Dans un contrat d’infogérance, écrivez d’abord ce que couvre le service : inventaire des services, plages horaires, canaux de contact, prérequis côté client (accès, référents, validation des changements). Ensuite, formalisez des SLA limités mais solides, et complétez par des SLO plus ambitieux dans le plan de progrès.

Pièges fréquents à éviter :

• SLA sans définition de la mesure : « disponibilité » sans préciser l’outil, la fenêtre, ni les exclusions (maintenance planifiée, panne opérateur, indisponibilité causée par un tiers).
• Temps de réponse confondu avec temps de résolution : une réponse rapide ne signifie pas un rétablissement rapide.
• Absence de criticité : un poste utilisateur et un ERP ne se gèrent pas de la même manière. Définissez des classes (critique, majeur, mineur) avec règles de qualification.
• Exclusions trop larges : si tout est « hors périmètre », le contrat devient une assistance au coup par coup.
• Pas de gestion des changements : sans calendrier et procédure, les mises à jour deviennent des risques.

Pour rendre le contrat lisible par une direction, utilisez une annexe « catalogue de services » et une annexe « indicateurs et reporting ». Inspirez-vous des principes ITIL (gestion des incidents, problèmes, changements) et des exigences d’un système de management de services (ISO/IEC 20000) pour structurer responsabilités, preuves et amélioration continue.

Enfin, prévoyez un mécanisme d’arbitrage : quand un indicateur est en écart, quel est le plan d’action, qui valide, quel délai, et quelle priorisation budgétaire.

Un bon reporting mensuel sert à décider, pas à « prouver qu’on a travaillé ». Il doit tenir en quelques pages et parler à la direction (risque, continuité, coût) tout en restant actionnable pour l’IT. L’objectif : faire converger incidents, prévention et plan de progrès.

Voici un modèle simple, à reprendre tel quel et à adapter.

Structure recommandée

• Page 1 : Synthèse Direction

- État des services critiques (tendance) - Incidents majeurs et impact métier - Points de risque (sécurité, obsolescence, sauvegardes) - Décisions attendues (budget, arbitrage, validation)

• Page 2 : Opérations IT

- Détails KPI (tickets, MTTR, patch, sauvegardes) - Analyse de récurrence (causes racines) - Changements réalisés et à venir

• Page 3 : Plan de progrès

- Actions, propriétaire, échéance, statut - Gains attendus (qualitatifs) et dépendances

Exemple de tableau (extrait)

Le champ « À définir » n’est pas un vide : il force à documenter la méthode de calcul et la source (outil de supervision, console M365, solution de sauvegarde). Dans une organisation multi-sites, par exemple entre Montbéliard et un autre site, un reporting standardisé évite les débats interminables sur « qui a raison » et recentre la discussion sur les actions.

Les 90 premiers jours déterminent la trajectoire : soit l’infogérance reste un centre de support, soit elle devient un pilotage structuré. L’objectif n’est pas de tout refaire, mais de sécuriser les fondamentaux, d’obtenir des mesures fiables, puis d’industrialiser.

Jours 1 à 30 : stabiliser et rendre observable

• Cartographie minimale : inventaire des équipements, services critiques, dépendances, comptes administrateurs.
• Supervision et alerting : définir ce qui doit alerter (disponibilité, sauvegardes, capacité disque, certificat expirant) et qui reçoit quoi.
• Hygiène sécurité : MFA, suppression/rotation des comptes à privilèges non maîtrisés, baseline antivirus/EDR.
• Sauvegardes : vérifier la cohérence, la rétention, et planifier au moins un test de restauration documenté.
• KPI version 0 : même imparfaits, commencer à mesurer avec une méthode explicite.

Jours 31 à 60 : réduire la récurrence

• Analyse des incidents récurrents : regrouper par cause, prioriser les causes racines.
• Standardisation postes : modèles, politiques, déploiement d’outils, réduction des variantes.
• Patch management : calendrier, fenêtres, validation, traitement des exceptions.
• Gestion des changements : registre des changements, validation, communication aux utilisateurs.

Jours 61 à 90 : contractualiser l’amélioration

• SLO cibles : fixer des objectifs réalistes et progressifs.
• SLA finalisés : engagements sur services critiques, mesure et preuves.
• Roadmap dette technique : obsolescences, priorités, budget, dépendances.
• Rituels : comités mensuels, format de reporting, décisions attendues.

Ce plan doit rester pragmatique : chaque action doit avoir un propriétaire, une preuve et un effet attendu sur un KPI. C’est aussi le bon moment pour cadrer les limites (tiers applicatifs, opérateurs, matériel en fin de vie) et éviter que le prestataire ne soit tenu responsable de ce qu’il ne maîtrise pas.

Dans une PME, la promesse réaliste d’une infogérance proactive n’est pas « zéro incident », mais une exploitation prévisible, des incidents moins fréquents, et un risque mieux maîtrisé. Pour éviter les attentes irréalistes, projetez des résultats par horizon, en reliant chaque amélioration à des KPI.

À 3 mois : visibilité et premiers gains

• Observabilité : supervision en place, inventaire exploitable, reporting mensuel stabilisé.
• Sauvegardes maîtrisées : preuves de réussite, documentation des restaurations testées.
• Réduction du bruit : premières causes récurrentes traitées (imprimantes, profils, DNS/DHCP, saturation stockage), avec baisse du taux de répétition.

À 6 mois : industrialisation

• Patch management régulier : calendrier connu, exceptions tracées, moins d’urgences.
• Gestion des changements : moins d’effets de bord, meilleure communication.
• Identités et accès : revues d’accès, comptes admin encadrés, MFA généralisé selon périmètre.
• Documentation vivante : schémas, procédures de reprise, runbooks.

À 12 mois : pilotage et arbitrages budgétaires plus simples

• Dette technique pilotée : plan pluri-trimestre, décisions d’investissement justifiées par le risque et la continuité.
• SLA/SLO pertinents : engagements tenus et revus, indicateurs qui guident les priorités.
• Sécurité opérationnelle : alertes triées, processus d’escalade, exercices (restauration, comptes compromis) documentés.

Attention : la stabilisation dépend de facteurs non techniques (discipline de validation, disponibilité des référents, gestion des prestataires applicatifs). Dans certains contextes, notamment avec des sites répartis entre Alsace et d’autres zones, la standardisation et la gouvernance (qui décide quoi) sont aussi importantes que les outils.

Utilisez cette checklist pour cadrer rapidement une infogérance proactive, avant même de négocier un contrat.

Périmètre et responsabilités

• Définir les services critiques (liste courte) et leurs dépendances.
• Documenter ce qui est inclus et exclu (matériel, applicatifs, opérateurs, cloud).
• Nommer des référents côté client (validation, escalade, arbitrage).

Mesure et preuves

• Définir la source de vérité pour chaque KPI (outil, console, export).
• Exiger des preuves : rapports de sauvegarde, logs de patch, tickets, comptes rendus.
• Distinguer impact métier et résolution technique.

SLA / SLO

• Formaliser des classes de criticité et un mode de qualification.
• Écrire séparément : délai de prise en charge, délai de rétablissement, fenêtres de maintenance.
• Prévoir un mécanisme de revue des objectifs (SLO) et des engagements (SLA).

Exploitation et prévention

• Mettre en place la supervision et l’alerting (qui reçoit quoi, quand).
• Planifier le patch management (calendrier, exceptions, validation).
• Vérifier les sauvegardes et organiser des tests de restauration.
• Encadrer les comptes à privilèges et la revue des accès.

Gouvernance

• Tenir un reporting mensuel avec décisions attendues.
• Maintenir un plan de progrès (actions, responsable, échéance, statut).
• Traiter la récurrence via une approche causes racines (problème, pas seulement incident).

Si vous cochez moins de la moitié de ces points, votre contrat risque d’acheter surtout de la réactivité. Si vous cochez la majorité, vous créez les conditions d’une baisse durable des interruptions et des coûts cachés.