Besoin de conseil ?
Prendre rdv sur Teams
En cas d’incident, la responsabilité ne se résume pas à “qui a tort ?”. Elle dépend de 4 choses très concrètes :
Objectif de cet article : vous donner une grille de lecture et une checklist actionnable, y compris après un sinistre.
Note : cet article est une information générale, pas un avis juridique. Pour sécuriser vos clauses contractuelles, faites valider par votre conseil.
Le jour où “ça tombe”, vous n’avez pas besoin d’un débat abstrait. Vous avez besoin de répondre à 3 questions, dans cet ordre :
Point clé : si le périmètre est flou, la responsabilité devient floue. Et si aucune preuve n’est prévue (ticketing, rapports, logs), vous n’aurez rien de solide pour trancher — au pire moment.
Pour poser les bases, commencez par notre grand guide : infogérance : tout savoir
Dans la vraie vie, il y a presque toujours 3 acteurs :
Même avec une infogérance “complète”, le client reste généralement responsable de :
Le prestataire est responsable de ce qu’il s’est engagé à faire (et uniquement de cela) : détecter, intervenir, restaurer, documenter, escalader vers les tiers, produire un rapport, etc.
Si vous voulez clarifier précisément ce que couvre l’infogérance (et ce qui est hors périmètre), ce guide est utile : Ce que couvre (ou non) l’infogérance.
Si une partie de votre SI repose sur des services cloud (messagerie, stockage, ERP…), vous êtes dans un modèle de responsabilité partagée : le fournisseur sécurise une couche, et vous (ou votre prestataire) sécurisez le reste.
En pratique : même sur un SaaS, les comptes, les droits d’accès, les configurations et vos données restent un sujet côté client/prestataire (ex. MFA, gestion des rôles, sauvegardes, bonnes configurations).
La meilleure infogérance du monde ne compensera pas un contrat flou. Voici ce que vous voulez voir écrit, clairement :
À lire : Contrat d’infogérance : que doit-il inclure ?
Un SLA utile doit préciser :
À lire: SLA en infogérance : définition, pièges et risques
Le plus efficace pour éviter les zones grises : une matrice RACI (Responsable / Approbateur / Consulté / Informé) sur 8 à 12 scénarios réels : panne réseau, messagerie indisponible, ransomware, restauration de sauvegarde, départ d’un salarié, etc.
À lire : Co-gérance : RACI et partage de responsabilités
À lire: Cybersécurité managée : preuves et reporting
Le “changement de prestataire” n’est pas un scénario théorique. Sans clause de réversibilité (données, admin, docs, délais, coûts), vous prenez un risque.
À lire : Clause de réversibilité en infogérance
Voici une méthode de gestion “PME” qui tient en une page. L’objectif : reprendre le contrôle et éviter les erreurs classiques (panique, décisions non tracées, nettoyage qui détruit des preuves).
Si l’incident implique des données personnelles, le sujet devient aussi RGPD : qui notifie quoi, et quand.
À lire / relier (RGPD et preuves contractuelles) : Infogérance & RGPD : article 28, preuves et obligations
| Situation | Client (PME) | Prestataire d’infogérance | Fournisseur (cloud/opérateur/éditeur) |
|---|---|---|---|
| Messagerie / Microsoft 365 indisponible | Arbitre l’impact & la communication interne | Diagnostique, ouvre/escalade, propose contournements | Rétablit le service (plateforme) |
| Ransomware sur un poste | Décide (priorités, coupures, communication, assurance) | Confinement, restauration, durcissement, rapport | Variable |
| Suppression accidentelle de fichiers | Valide la restauration & le périmètre | Restaure selon la stratégie de sauvegarde | Variable |
| Panne internet (opérateur) | Gère le mode dégradé (priorités) | Coordonne et escalade, fournit preuves/rapport | Rétablit la ligne |
| Suspicion de fuite de données | Décide d’une notification/communication (si nécessaire) | Aide à qualifier, fournit éléments factuels | Variable |
Pour un cas Microsoft 365 (et ce que l’infogérance peut réellement couvrir), vous pouvez aussi relier : Infogérance & Microsoft 365
Pour choisir et comparer un prestataire : Choisir/comparer un prestataire d’infogérance
Si vous voulez éviter les zones grises le jour où ça casse, la bonne démarche est simple : mettre au clair “qui fait quoi” (périmètre + SLA + RACI + preuves) puis l’écrire dans le contrat.
Si vous cherchez un prestataire d’infogérance à Paris : Prestataire d’infogérance à Paris
Et si vous hésitez encore entre maintenance et infogérance (différences, implications, checklist) : Infogérance vs maintenance informatique : différences — Checklist : passer de la maintenance à l’infogérance.
Externaliser ne transfère pas tout. Vous transférez des tâches (exécution), mais vous gardez des responsabilités de décision, de validation et de gouvernance. Le contrat doit préciser le périmètre, les engagements et les preuves.
Le fournisseur est responsable de sa plateforme. Le prestataire peut être responsable du support, de l’escalade, de la coordination et des contournements prévus. Le client reste responsable des arbitrages métier.
Il faut qualifier rapidement si une violation est probable, conserver les éléments factuels, et appliquer vos obligations RGPD : le sous-traitant alerte le responsable de traitement, et le responsable de traitement peut devoir notifier l’autorité dans les délais applicables.
En listant les services “inclus/exclus”, en ajoutant une matrice RACI sur les scénarios réels, et en définissant une procédure d’escalade (y compris vers les tiers).
Souvent non. Les pénalités traitent un manquement de service, mais ne remplacent pas un dispositif de résilience (sauvegardes testées, PRA/PCA, séparation des responsabilités, preuves).
Au minimum : tickets horodatés, rapports d’intervention, journal des actions, reporting mensuel (incidents, correctifs, risques). Sans preuves, vous ne pilotez pas.
La réversibilité. Le jour où vous changez de prestataire, vous voulez récupérer vos accès, votre documentation et vos données sans blocage.
Vous pouvez vous appuyer sur un modèle (périmètre, SLA, RACI, preuves, sécurité, réversibilité) : Cahier des charges infogérance : modèle.