Choisir son MSP : les 10 questions à poser avant de signer

Qu'est-ce qu'un MSP en 2026, et ce que ce n'est pas

Le sigle MSP (Managed Service Provider) désigne historiquement un prestataire qui exploite tout ou partie du système d'information d'une organisation cliente, avec un engagement de résultat plus que de moyens, et une facturation récurrente (le plus souvent à l'utilisateur ou à l'actif géré). Le terme est issu du marché nord-américain des années 2000 et s'est généralisé en France sur la dernière décennie. Il a aussi été récupéré par à peu près tout le monde : un revendeur qui vend des licences Microsoft 365 avec un contrat de support se qualifie aujourd'hui volontiers de « MSP ».

Pour un dirigeant qui cherche à changer, le problème n'est pas sémantique, il est opérationnel. Cinq profils de prestataires se présentent sous la même étiquette :

• Le dépanneur avec contrat. Modèle réactif : vous appelez quand ça casse, un technicien intervient. Facturation à l'heure ou au forfait light. Pas de supervision, pas de méthodologie documentée, pas de reporting structuré. Adapté à des TPE sans dépendance critique au système d'information.
• Le revendeur de licences déguisé. Le cœur de métier reste la marge éditeur (Microsoft, Adobe, éditeurs ERP). L'infogérance est un service d'appui qui permet d'ancrer le contrat de revente. La profondeur technique sur l'exploitation est souvent limitée.
• L'infogérant classique. Intervention régulière, ticketing, parfois supervision. Structure hiérarchique simple (un ingénieur, quelques techniciens, un dirigeant-commercial). Satisfaisant sur l'exploitation courante, plus fragile sur les incidents majeurs ou les chantiers d'architecture.
• Le MSP structuré régional. Supervision 24/7 active, support N1/N2/N3 documenté, méthodologie référencée (ITIL ou équivalent), certifications éditeurs vérifiables, cellule de crise définie, reporting mensuel. Taille typique : 20 à 150 collaborateurs, proximité géographique, portefeuille de PME-ETI.
• La filiale d'ESN nationale. Plateformes mutualisées, contrats cadres, processus industrialisés. Excellente couverture fonctionnelle, mais en dessous de 200 utilisateurs, votre dossier risque de passer inaperçu dans la masse.

Aucun de ces profils n'est intrinsèquement mauvais. Ils correspondent à des tailles d'entreprise, des niveaux de dépendance au système d'information, et des budgets différents. L'erreur fréquente consiste à les mettre en concurrence directe sur la même grille, sans avoir d'abord identifié lequel correspond à votre profil de risque.

Les quatre archétypes que vous allez rencontrer

Quand une PME de 20 à 80 salariés cherche à changer de prestataire informatique, elle rencontre typiquement deux à quatre MSP en rendez-vous, sur recommandation d'un pair, via un comptable ou un courtier, après quelques recherches en ligne ou un sondage auprès de confrères dirigeants. Au-delà des commerciaux qui défilent, quatre profils types couvrent la quasi-totalité du marché francophone. Les identifier évite de comparer une offre de dépanneur avec une offre d'ESN en pensant qu'elles sont équivalentes parce que le prix est proche.

Cette segmentation est une grille de lecture, pas un jugement. Un dépanneur peut être excellent pour une TPE de moins de 10 personnes qui n'a aucun service en ligne et peut tolérer 48 h d'interruption. Une filiale d'ESN est presque toujours surdimensionnée, et trop rigide, pour une entreprise de 80 personnes avec un SI standard. Le bon choix consiste à aligner l'archétype sur votre profil de risque, pas à chercher « le meilleur MSP du marché ».

Ce qu'il faut avoir clarifié avant de rencontrer le premier prestataire

La moitié des changements de prestataire qui tournent mal n'ont pas un problème de choix, ils ont un problème de préparation côté client. Vous pouvez signer avec le MSP le plus structuré du marché, s'il découvre votre système d'information à la signature, les six premiers mois seront pénibles pour tout le monde. Quelques clarifications internes avant le premier rendez-vous suffisent à éviter la plupart des malentendus. Rien de bureaucratique, pas besoin de document formel : avoir les idées claires sur les cinq points suivants suffit.

Ces cinq points n'ont pas à être formalisés dans un beau document. Les avoir en tête avant le premier rendez-vous suffit à écarter les malentendus et les avenants à répétition qui empoisonnent la première année.

Les 10 questions à poser, et comment lire les réponses

La liste qui suit n'est pas un questionnaire à envoyer par mail en attendant une réponse écrite sous 48 h. C'est une grille d'écoute : ces questions se posent en rendez-vous, s'observent dans la qualité des réponses orales, puis se confirment dans le devis et le contrat avant signature. Un MSP structuré répondra avec des exemples concrets et des limites assumées. Un prestataire qui improvise répondra avec des formulations génériques et des superlatifs, et ce contraste suffit souvent à faire le tri dès le premier rendez-vous.

1. Quelle est votre méthodologie de support N1/N2/N3, et quel est le ratio clients par technicien ?

✓ Bonne réponse. Une description claire des trois niveaux (N1 = prise en charge et qualification, N2 = diagnostic et résolution technique, N3 = expertise et escalade éditeur), des rôles documentés dans un référentiel ITIL ou équivalent, et un ratio partagé (typiquement 30 à 80 clients par technicien N1-N2 selon la taille moyenne des comptes).

✗ Mauvaise réponse. « Chez nous tout le monde fait de tout » (= dépanneur sans méthode), ou à l'inverse un discours ultra-process vide de chiffres (« nous sommes certifiés ITIL 4 » sans préciser quels processus sont réellement outillés). Demandez à voir une fiche de procédure anonymisée.

2. Quels engagements de service prenez-vous, et par quels moyens les tenez-vous ?

✓ Bonne réponse. De l'honnêteté sur la distinction entre engagement contractuel et objectif de service. En France, très peu de MSP s'engagent contractuellement avec pénalités dissuasives sur le P1, et c'est structurel, pas un défaut. Aucun MSP ne maîtrise l'opérateur télécom, l'éditeur qui livre un patch défectueux, ou le fournisseur cloud qui subit un incident régional. Un MSP structuré affiche donc des objectifs de service assumés comme tels, puis décrit les moyens opérationnels qui permettent de les tenir : supervision active 24/7 (et non un téléphone d'astreinte dévié sur un technicien qui dort), cellule de crise documentée, procédure d'escalade avec interlocuteurs nommés côté éditeur, historique d'incidents majeurs partagé (même anonymisé), dimensionnement d'équipe proportionné au portefeuille client.

✗ Mauvaise réponse. Des chiffres contractuels pompeux sans description des moyens derrière (« garantie P1 < 30 min » quand la supervision est en heures ouvrées et que l'astreinte est un portable partagé), ou des pénalités symboliques masquant l'absence totale de moyens (« pénalité de 50 € par tranche de 30 min au-delà du SLA » sur un contrat à 8 000 €/mois).

3. Quelle est votre procédure en cas d'incident majeur ?

✓ Bonne réponse. Une procédure écrite, testée, avec cellule de crise, canaux de communication (pont de conférence dédié, point de situation toutes les 30 min à 1 h), escalade prédéfinie vers les éditeurs sous contrat, et un rapport d'incident post-mortem systématique. Demandez à voir un rapport d'incident anonymisé, c'est la preuve la plus lisible qu'une procédure existe vraiment.

✗ Mauvaise réponse. « On mobilise nos meilleurs éléments » (formulation vide), ou « on a déjà géré plein de crises » sans aucun exemple concret.

4. Comment se passe la sortie si l'un de nous met fin au contrat ?

✓ Bonne réponse. Une clause de réversibilité claire : restitution de la documentation technique complète (inventaire, schémas, procédures, mots de passe transférés selon procédure sécurisée), accompagnement du prestataire entrant sur X jours prévus au contrat, aucune donnée captive. Un MSP mature ne rechigne pas à parler de sortie : il sait que la vraie question est « pourquoi vous partiriez ? », pas « comment je vous retiens ? ».

✗ Mauvaise réponse. Un silence gêné, des frais de sortie disproportionnés, une clause de « restitution sur devis », ou la découverte tardive que votre domaine Microsoft 365 est hébergé sur le compte Microsoft du prestataire, pas sur le vôtre. Ce dernier point est un indicateur quasi binaire de dépendance captive : une fois installé chez lui, vous n'en sortez plus sans tout perdre.

5. Qui fait quoi chez vous, et quels sont vos sous-traitants ?

✓ Bonne réponse. Une organisation lisible : équipe interne dimensionnée, éventuels sous-traitants identifiés nommément (supervision externalisée, expertise pointue ponctuelle, centre d'appels tiers), pays d'intervention précisé pour chaque niveau. La sous-traitance en soi n'est pas un problème, l'opacité sur la sous-traitance en est un. Si vous signez avec un prestataire de 15 personnes qui annonce une supervision 24/7, posez-vous la question de savoir où se trouvent réellement les yeux sur vos alertes à 3 h du matin.

✗ Mauvaise réponse. « Tout est fait en interne » alors que l'équipe fait 15 personnes (structurellement impossible en 24/7), ou « on a des partenaires » sans jamais les nommer.

6. Comment documentez-vous notre SI, et y avons-nous accès de notre côté ?

✓ Bonne réponse. Un outil centralisé et versionné (outil de gestion documentaire type Confluence, IT Glue, HaloPSA, Hudu ou équivalent), une cartographie tenue à jour à chaque changement, des procédures documentées par service critique, et un accès en lecture côté client. La documentation est un actif qui doit vivre, et ne pas rester captive chez le prestataire.

✗ Mauvaise réponse. « Dans la tête de notre technicien principal », « dans nos mails et nos tickets », ou une documentation hébergée uniquement chez le prestataire sans accès côté client. Ce dernier point est l'indicateur le plus fiable d'une relation captive : le jour où vous voulez partir, vous repartez sans rien.

7. Quelle politique recommandez-vous pour une sauvegarde de secours hors de votre infogérance ?

✓ Bonne réponse. Une réponse honnête : il est sain que le client conserve une copie de sauvegarde hors du périmètre opéré par le MSP, pour couvrir le cas où le MSP lui-même serait victime d'une compromission (ransomware propagé, compromission d'un compte d'administration). Un MSP mature soutient cette démarche, documente le dispositif, et ne la perçoit pas comme une défiance. Une copie froide côté client, une sauvegarde immuable, ou une sauvegarde hébergée chez un tiers indépendant répondent à ce besoin.

✗ Mauvaise réponse. « Pas besoin, tout est dans notre cloud », formulation qui fait abstraction du scénario pourtant documenté où le prestataire lui-même devient vecteur de compromission. Les cas publics des trois dernières années ont illustré ce risque, notamment sur le marché des MSP américains et européens.

8. Comment gérez-vous les accès à privilèges, les vôtres sur notre SI ?

✓ Bonne réponse. Une chaîne d'imputabilité intacte : chaque technicien dispose d'un compte nominatif dans l'outil d'accès (RMM moderne, bastion ou solution PAM), protégé par MFA, depuis lequel les sessions vers votre SI sont journalisées et attribuables à une personne physique (qui s'est connecté, quand, sur quel service, combien de temps). Que le compte technique sur le serveur lui-même soit partagé (souvent un « admin MSP » documenté et géré dans un coffre-fort de mots de passe) ou nominatif est un choix d'implémentation, ce qui compte est la traçabilité de bout en bout. S'ajoutent : gestion centralisée des mots de passe administrateur, rotation documentée, procédure écrite de suppression de compte au départ d'un collaborateur, et un engagement explicite de restitution intégrale des accès en fin de contrat, y compris les comptes d'urgence (« break-glass ») que vous n'utilisez jamais.

✗ Mauvaise réponse. Pas d'outil d'accès traçable (connexions RDP/SSH directes depuis les postes des techniciens), un compte admin partagé sans journalisation intermédiaire, ou l'incapacité de produire sur demande un journal du type « qui s'est connecté, quand, sur quoi » pour une semaine donnée. C'est cette rupture d'imputabilité qui disqualifie un prestataire sur un SI sensible, pas la convention de nommage du compte sur le serveur.

9. Pouvez-vous me présenter un cas client comparable, vérifiable ?

✓ Bonne réponse. Un cas client documenté avec contexte métier, choix techniques, problèmes rencontrés et résultats mesurables. Idéalement, la possibilité d'échanger directement avec le responsable informatique du client, ou son dirigeant si la structure est trop petite pour avoir une fonction dédiée, sous accord préalable. Taille, secteur, contraintes comparables aux vôtres.

✗ Mauvaise réponse. « On a plein de clients satisfaits » sans nom, « on a des références dans votre secteur » sans possibilité de les rencontrer, ou la présentation de logos de grands comptes qui étaient en fait un dossier ponctuel il y a cinq ans. Un cas client non vérifiable équivaut à pas de cas client.

10. Quand avez-vous testé une restauration complète pour la dernière fois, chez un client comparable ?

✓ Bonne réponse. Une date précise, un périmètre décrit (pas juste un fichier, une VM, une base, un service métier complet), un rapport d'exercice, et idéalement une fréquence de tests programmée (trimestrielle ou semestrielle selon la criticité). Un prestataire qui mène des exercices PCA/PRA chez ses clients est structurellement plus solide qu'un prestataire qui « fait tourner les sauvegardes toutes les nuits ».

✗ Mauvaise réponse. « Les sauvegardes remontent tous les jours », qui n'est pas une réponse à la question. Tourner ne veut pas dire restaurer, et restaurer un fichier ne veut pas dire restaurer un service.

Six pièges commerciaux récurrents

Au-delà des 10 questions, certaines tournures dans les échanges commerciaux méritent d'être identifiées pour ce qu'elles sont, des signaux d'alerte qui n'apparaissent pas toujours dans une grille formelle.

Décrypter un devis d'infogérance, les points rouges

À la lecture d'un devis et de sa proposition commerciale, souvent 2 à 5 pages dans le monde PME, parfois une simple page avec un total mensuel, certains points méritent une attention frontale avant toute comparaison de prix. Ils disent plus sur la posture réelle du prestataire que le montant affiché.

• Devis trop flou par poste. Un devis sérieux, même court, sépare au minimum : postes utilisateurs (incluant/excluant stockage et sauvegarde), serveurs physiques et virtuels, services cloud (Microsoft 365 par utilisateur, éventuel hébergement), sécurité (pare-feu managé, EDR, MFA), sauvegarde (volumes gérés), supervision, téléphonie. Une ligne unique « infogérance globale 2 500 € HT/mois » est un signal d'opacité : vous ne saurez jamais ce qui est inclus ni ce qui bascule en avenant dès qu'un besoin nouveau apparaît.
• Inclusions et exclusions asymétriques. Vérifiez systématiquement la liste des exclusions. Si les inclusions tiennent en 2 lignes et les exclusions en 30, le périmètre réel est beaucoup plus étroit qu'il n'y paraît. Les exclusions typiques à négocier : changements majeurs d'architecture, incidents liés à un éditeur tiers, assistance utilisateur au-delà d'un certain volume, interventions sur site au-delà d'une distance.
• Clauses de révision tarifaire. Indexation annuelle sur un indice (SYNTEC le plus fréquent en France), modalités de révision en cas de variation de périmètre, plafond de révision. Une clause « révision annuelle à discrétion du prestataire » est inacceptable sur un contrat de 3 ans.
• Pénalités SLA réellement engageantes. Une pénalité SLA n'est pas un argument marketing, c'est une somme que le prestataire accepte de perdre. Si le plafond annuel de pénalités est inférieur à un mois de facturation, l'engagement est symbolique.
• Durée d'engagement et clause de sortie. 3 ans est standard en infogérance PME-ETI pour amortir l'onboarding. Au-delà, exigez une clause de sortie anticipée avec préavis de 3 à 6 mois. Méfiez-vous des reconductions tacites pluriannuelles sans fenêtre de sortie.
• Propriété des équipements et des données. Si le prestataire fournit du matériel en location ou des licences en revente, clarifiez l'état des lieux à la sortie : matériel restitué, racheté à valeur résiduelle, ou laissé ? Licences cédées ou bloquées ? Ces sujets se règlent à la signature, pas au départ.

Les 90 premiers jours, signaux faibles à surveiller

La qualité d'un MSP se révèle davantage dans l'onboarding que dans la plaquette commerciale. Trois jalons méritent une attention particulière.

Trois signaux faibles cumulés à 90 jours annoncent presque systématiquement une déception à 18 mois : documentation jamais reçue, rotation rapide des interlocuteurs côté prestataire, et premier incident significatif traité dans l'improvisation. Mieux vaut activer une clause de sortie anticipée dans les 12 premiers mois, coûteuse mais lisible, que subir un contrat de 3 ans qui se dégrade lentement.

Six mois après la signature, les sept questions de recalage

Même un bon choix de départ mérite un point de contrôle structuré à mi-année. Sept questions suffisent à identifier si la relation est sur une trajectoire saine ou en train de se dégrader.

1. Les revues de service se tiennent-elles, avec un rapport écrit et partagé à l'avance ? Une revue improvisée sans document est une réunion commerciale, pas un pilotage.
2. Les incidents majeurs donnent-ils lieu à un rapport post-mortem ? Si chaque incident « se tasse » sans document écrit, vous n'êtes pas dans un cadre d'amélioration continue.
3. Recevez-vous des recommandations proactives ? Un MSP qui se contente d'éteindre les incendies ne pilote pas votre SI, il le subit avec vous.
4. La documentation technique est-elle à jour et accessible côté client ? Cartographie, schémas, procédures, contacts éditeurs. Elle doit vivre.
5. Les accès administrateurs peuvent-ils être audités ? Qui se connecte, quand, sur quoi ? Si la réponse n'existe pas, le risque est assumé, ou ignoré.
6. Les objectifs de service annoncés sont-ils tenus, et, dans le cas contraire, l'écart est-il analysé ? Le non-respect n'est pas grave en soi tant qu'il est analysé. L'absence d'analyse, en revanche, l'est.
7. Si vous deviez changer de prestataire dans 6 mois, pourriez-vous le faire sans catastrophe ? Test mental annuel utile. Si la réponse est « non », vous êtes en dépendance captive, indépendamment de la qualité perçue.

Ce point à 6 mois est aussi l'occasion de rappeler un principe structurel : dans une relation d'infogérance, ce n'est pas la fidélité qui crée la qualité, c'est l'exigence maintenue. Un prestataire qui sait qu'il peut être remplacé conserve une discipline opérationnelle. Un prestataire qui se sent en position captive la perd progressivement.

Sources et références

• ANSSI, Recommandations relatives à l'externalisation de services informatiques
• ExpertCyber, Label d'État porté par Cybermalveillance.gouv.fr (annuaire officiel des prestataires labellisés)
• CNIL, Guide du sous-traitant (article 28 RGPD), exigences contractuelles imposables à un prestataire
• ISO/IEC 27001:2022, Annexe A chapitre 5 (Politique organisationnelle) et chapitre 8 (Exploitation)
• AXELOS / PeopleCert, Référentiel ITIL 4 (cadre de gestion des services informatiques)