La checklist d'évaluation de sécurité pour les MSP
Les évaluations de sécurité sont l'un des services les plus faciles à vendre pour un MSP et l'un des plus difficiles à délivrer avec une marge. L'économie ne tient que si l'évaluation est standardisée, reproductible et largement automatisée sur les deux périmètres. Voici la checklist, et comment en faire une offre qui passe à l'échelle au-delà d'une poignée de clients.
Pourquoi la plupart des évaluations MSP ne passent pas à l'échelle
La première évaluation se passe bien. Vous connaissez le client, vous passez deux jours dans les portails d'administration, vous écrivez un rapport correct et le client est content. C'est à la dixième que ça casse : chaque évaluation est un peu différente, les constats dépendent de qui a fait le travail, le rapport prend autant de temps à écrire que la revue à mener, et personne ne peut dire si le client A est réellement en meilleure posture que le client B puisqu'ils n'ont pas été évalués pareil.
Trois contraintes doivent être satisfaites pour que ce soit une vraie ligne de service : la constance entre les clients et entre les techniciens, la rapidité, pour que le coût de main-d'œuvre ne mange pas la marge, et un livrable sur lequel le client agit plutôt qu'il ne le classe.
La checklist
Organisée là où le risque se concentre réellement, et non selon le portail dans lequel vous vous trouvez.
Identité et accès — Entra ID
- Imposition de la MFA : couverture pour tous les utilisateurs, et spécifiquement pour chaque rôle privilégié. Notez les groupes d'exclusion — c'est là que la couverture meurt discrètement.
- Authentification héritée : bloquée, après vérification dans les journaux de connexion.
- Nombre d'administrateurs généraux, et accès privilégié permanent ou activable à la demande.
- Jeu de stratégies d'accès conditionnel : stratégies de base présentes, portails d'administration protégés, aucune stratégie laissée en mode rapport seul que tout le monde croit appliquée.
- Comptes de secours : présents, correctement exclus, documentés, surveillés.
- Accès invité et réglages de collaboration externe.
- Libre-service : enregistrement d'applications, consentement utilisateur aux applications tierces, droit d'inviter des externes.
- Comptes dormants, principaux de service inutilisés, identifiants proches de l'expiration.
Collaboration et messagerie
- Transfert automatique vers des destinataires externes — le point le plus rentable de toute cette liste.
- Réglages de partage externe SharePoint et OneDrive, et toutes les surfaces « toute personne disposant du lien ».
- Accès invité et politique de réunion Teams.
- Stratégies Defender : liens sûrs, pièces jointes sûres, anti-hameçonnage.
Journalisation et preuve
- Journal d'audit unifié activé — vérifiez, ne supposez pas.
- Rétention des journaux de connexion et d'annuaire, et export éventuel pour une conservation plus longue.
- Audit des boîtes aux lettres.
Deux périmètres, un seul corpus de preuves
Une organisation qui tourne sous Microsoft n'en exploite rarement qu'un seul des deux. Le tenant cloud et l'annuaire on-premises portent chacun leur part de l'exigence, et un évaluateur qui ne regarde que le premier passe à côté de l'endroit où se trouve l'essentiel du risque.
| Périmètre | Ce qu'il apporte à l'exigence |
|---|---|
| Entra ID & Microsoft 365 | Robustesse de l'authentification, accès conditionnel, rôles à privilèges, consentement applicatif, accès invité, politiques de messagerie et de partage, rétention des journaux d'audit. |
| Active Directory | Appartenance aux groupes privilégiés, comptes de service, délégations ACL, configuration Kerberos, modèles de certificat, approbations, couverture LAPS — et les chemins d'escalade qui les relient. |
La correspondance normative est la même dans les deux, et c'est ce qui fait que les preuves s'additionnent au lieu de rester dans deux piles séparées.
Transformer la checklist en offre
Standardiser avant de passer à l'échelle
Définissez une méthodologie d'évaluation unique et appliquez-la à tous les clients. Dès l'instant où deux techniciens évaluent différemment, vos comparaisons entre clients perdent tout sens et vos rapports cessent de ressembler à un produit. Ancrez la méthodologie sur un référentiel reconnu — les benchmarks CIS sont le choix naturel pour un environnement Microsoft — pour que les constats portent une référence externe plutôt que l'opinion de votre technicien.
Prévoir la variation par client, délibérément
Les clients diffèrent. Certains n'utilisent pas un service ; d'autres ont un contrôle réellement hors périmètre ; d'autres encore ont des exigences plus strictes que le standard. Traitez cela par une baseline documentée par client plutôt que par des arbitrages au fil de l'eau, pour que les exclusions soient visibles dans le rapport au lieu d'être enfouies dans la tête de quelqu'un. Cela évite aussi que des constats sans objet enterrent ceux qui comptent.
Faire du livrable le produit
Le rapport est ce que le client paie. Il lui faut un score qu'il peut suivre dans le temps, des constats classés par gravité plutôt que listés par service, une étape de remédiation pour chacun, et une référence normative pour que la recommandation ne repose pas sur votre seule parole. Le mettre à votre marque compte plus qu'il n'y paraît — c'est votre service, pas la sortie d'un outil.
Vendre la cadence, pas le coup unique
Une évaluation isolée est une transaction. La version récurrente est le métier : réévaluation trimestrielle, avec la tendance du score comme preuve de valeur. Cela résout aussi la conversation gênante où vous livrez des constats sans jamais savoir si quoi que ce soit a été corrigé. Quand le rapport suivant montre un score passé de 54 % à 78 %, la valeur de la mission est évidente — et l'argument du renouvellement aussi.
Garder la frontière de la lecture seule
Évaluation et remédiation sont deux missions distinctes, aux profils de risque différents. Mener une évaluation qui ne peut pas modifier le tenant d'un client est à la fois plus sûr et plus facile à vendre : vous ne demandez pas un accès en écriture à leur système d'identité de production pour leur dire ce qui ne va pas.
L'économie réelle
La variable qui décide de la rentabilité de cette ligne, c'est le nombre d'heures de technicien par évaluation. Une revue manuelle dans une douzaine de portails pour un tenant de taille moyenne représente plusieurs jours, et un travail de plusieurs jours met le service hors de portée des petits et moyens clients que la plupart des MSP servent réellement. Automatiser la collecte et la génération du rapport est ce qui fait passer l'évaluation d'un projet sur mesure à un livrable reproductible — et permet de le proposer à tout le portefeuille plutôt qu'aux trois plus gros comptes.