Cahier des charges d’infogérance : modèle + annexes périmètre (PME)
Par Léo Dugué
Le 26-02-26
Table des matières
Objectif : fournir un modèle de cahier des charge prêt à copier-coller pour consulter 2–3 prestataires, comparer à périmètre identique, et éviter les contrats flous (SLA, sécurité, RGPD, réversibilité).
Contexte visé : PME principalement Microsoft 365 / full cloud, parfois un petit serveur local hérité (Sage/compta, partage local, AD léger).
Un cahier des charges d’infogérance est le document qui fixe :
le périmètre (inclus / hors périmètre),
les niveaux de service (SLA, GTI/GTR),
les exigences de sécurité et de conformité (RGPD / sous-traitance),
les règles de pilotage (reporting, COPIL) et la réversibilité.
vous permet de faire un appel d’offre efficace.
Il sert à comparer les prestataires sur des éléments mesurables, et non des promesses marketing.
Remplir le contexte et l’annexe A avec les informations de votre entreprise.
Envoyer ce cahier des charges d’appel d’offre à 2–3 prestataires, demander une réponse structurée “section par section”, et imposer une offre chiffrée à périmètre identique.
Pour sécuriser davantage : ajouter une grille de scoring, exiger un exemple de reporting, et organiser une mini soutenance (30 min) centrée sur : périmètre, SLA, sécurité, preuves, réversibilité.
Annexe A — Inventaire & contexte technique (ce que l’entreprise fournit aux candidats)
A1. Utilisateurs & usages
Nombre d’utilisateurs : …
Télétravail : ☐ Oui ☐ Non (si oui, % environ : …)
Boîtes partagées / alias : …
Sensibilité data : ☐ Standard ☐ Données RH ☐ Données clients ☐ Données santé (si oui, préciser)
A2. Microsoft 365
Tenant M365 : ☐ oui (admin interne actuel : …)
Licences : … (ex : Business Premium / E3, etc.)
MFA : ☐ partiel ☐ généralisé ☐ inconnu
Gestion terminaux (Intune/MDM) : ☐ oui ☐ non
Defender / sécurité : ☐ oui ☐ non ☐ inconnu
SharePoint/OneDrive : ☐ léger ☐ central (volumétrie approx : …)
Responsabilités (cloud / M365) : la proposition doit expliciter la répartition des responsabilités entre Microsoft (plateforme) et le prestataire / le client (configuration, identités, appareils, données), et préciser qui fait quoi sur : MFA, comptes à privilèges, politiques d’accès, durcissement, sauvegardes, supervision et gestion des incidents, conformément au modèle de responsabilité partagée.
A3. Parc & environnement
Élément
Quantité
OS / version
Criticité
Particularités
PC fixes
…
Windows …
…
…
PC portables
…
Windows …
…
…
Mac
…
macOS …
…
…
Mobiles
…
iOS/Android
…
…
Imprimantes
…
…
…
…
A4. Petit serveur local (Sage / compta) — si présent
RUN : exploitation courante (support, administration, supervision, maintenance)
Projet : changement ou évolution (migration, refonte, déploiement massif)
Si certains besoins relèvent d’un projet, un chiffrage séparé doit être demandé avec : livrables, délais et coût. Sans cette séparation, la comparaison entre prestataires devient impossible car le périmètre RUN (voir guide) n’est pas équivalent.
Le tableau ci-dessous sert de repère. En pratique, dans votre appel d’offre, il doit être envoyé vide aux prestataires afin qu’ils le remplissent (inclus / hors périmètre / options) selon leurs règles réelles.
Domaine
Inclus (RUN)
Hors périmètre (Projet)
Options (si besoin)
Support utilisateurs
Incidents + demandes standard (comptes, postes, mails, imprimantes)
Déploiement massif / changement d’outils
Support étendu / astreinte
Microsoft 365
Admin tenant, comptes, groupes, sécurité de base, bonnes pratiques
Haute : poste bloquant, VPN instable, impression impossible sur un service clé
Standard : lenteur, demandes de paramétrage, ajout imprimante
C3. Escalade & responsabilités
Qui décide d’un “incident majeur” : …
Délai d’escalade : …
Obligation de compte-rendu (RCA / actions préventives) : ☐ oui ☐ non
Annexe D — SLA & KPI (GTI/GTR, disponibilité, pénalités)
Un SLA doit contenir des métriques mesurables, des responsabilités et des conséquences si l’engagement n’est pas tenu. (atlassian.com)
D1. Matrice SLA (exemple à adapter)
Criticité
Exemples
GTI (prise en charge)
GTR (rétablissement)
Horaires
Critique
M365, accès, Sage, cyber
≤ 1h
≤ 8h (ouvrées)
9h–19h
Haute
VPN, poste bloquant
≤ 4h
≤ 24–48h
9h–19h
Standard
demandes non bloquantes
≤ 1 j ouvré
≤ 5 j ouvrés
9h–19h
Variante simple : si une vraie comparabilité est souhaitée, demander aux candidats de proposer leurs GTI/GTR sur ces mêmes niveaux.
D2. KPI à exiger dans le reporting mensuel
% tickets dans le SLA (par criticité)
MTTR (temps moyen de résolution)
Top 10 causes d’incidents + actions correctives
Patch compliance (postes / serveur Sage)
Sauvegardes : succès + test de restauration (date + résultat)
D3. Pénalités / crédits (option)
Demander un mécanisme simple :
si SLA critique non tenu X fois / mois → crédit de service ou réduction partielle (Ce mécanisme peut être préféré à des pénalités “punitives”, tout en créant une conséquence réelle.)
Annexe E — Sécurité : exigences minimales + preuves attendues
E1. Socle sécurité “minimum non négociable”
Ce socle doit être écrit dans l’offre et lié à des preuves. Les guides ANSSI sont de bonnes bases de mesures d’hygiène et de sécurisation de l’administration. (messervices.cyber.gouv.fr)
Identités & accès (M365)
MFA obligatoire (admins + utilisateurs selon périmètre)
comptes admins séparés (pas d’admin au quotidien)
revue périodique des droits (au moins trimestrielle)
À clarifier dans le cahier des charges de l’appel d’offre : la rétention (policies) n’est pas une sauvegarde “au sens opérationnel”. Les politiques de rétention M365 gèrent conservation/suppression, mais ne remplacent pas un plan de restauration indépendant. (learn.microsoft.com)
E2. Preuves attendues
exemple de rapport mensuel (anonymisé)
export KPI SLA (même sur un mois fictif)
preuve “test restauration” (gabarit)
liste comptes admin + date de dernière revue
procédure “incident sécurité” + escalade
Annexe F — Données & RGPD (Article 28 / sous-traitance)
Si le prestataire traite des données personnelles pour le compte du client, un DPA / clauses Article 28 adaptées sont nécessaires (objet, durée, nature du traitement, sécurité, sous-traitants, audits, etc.).
La CNIL met à disposition des clauses contractuelles types et des ressources sur la sous-traitance. (cnil.fr)
À inclure dans le cahier des charges :
F1. Attendus contractuels
DPA conforme RGPD Article 28 (annexé au contrat) (cnil.fr)
liste des sous-traitants ultérieurs (si applicable) + mécanisme d’information
Les travaux CIGREF sur le pilotage de contrats d’infogérance/TMA insistent sur l’importance du pilotage et des conditions de fin de mission. (cigref.fr)
G1. Livrables de sortie à exiger
inventaire à jour (parc, M365, serveur Sage)
liste des accès / rôles admin (et transfert contrôlé)
Faut-il un cahier des charges si l’entreprise est “juste sur M365” ? Oui : M365 simplifie l’infrastructure, mais la sécurité, les identités, les droits, le parc et les processus restent à cadrer (responsabilité partagée). (learn.microsoft.com)
Combien de prestataires consulter ? 2–3 suffisent si le périmètre est clair et la grille de scoring solide.
La rétention M365 remplace une sauvegarde ? Pas automatiquement : la rétention sert à gérer conservation/suppression. Le besoin de restauration doit être clarifié et le mécanisme exigé (outil, tests). (learn.microsoft.com)
Doit-on exiger des pénalités SLA ? Au minimum : un mécanisme de conséquence (crédit de service) + transparence KPI.
Que demander en sécurité sans créer une usine à gaz ? MFA + gestion admins + patching + sauvegardes testées + preuve de pilotage (reporting).
Le RGPD est-il concerné si le prestataire “administre seulement” ? Souvent oui : il peut accéder à des données personnelles (support, logs, mails). Un DPA Article 28 est recommandé. (cnil.fr)
