Un prestataire informatique, ce n’est pas “quelqu’un qui dépanne”. C’est un acteur qui met (ou non) votre activité à l’abri des pannes, des pertes de données, des incidents de sécurité et des blocages opérationnels. Le bon choix se joue rarement sur la promesse commerciale : il se joue sur la capacité à exécuter, à documenter, à prouver, et à assumer les moments difficiles.
Angle éditorial retenu
Vous allez sélectionner un prestataire sur des preuves d’exécution (outillage, process, traçabilité, reporting, tests, clauses), pas sur des mots. La structure ci-dessous suit cette logique : évaluer, sécuriser, piloter, et sortir proprement si nécessaire.
1) Clarifier vos besoins sans tomber dans la “liste de courses”
Plus votre besoin est décrit en termes d’impacts métier (ce qui doit fonctionner), plus vous évitez les devis incomparables et les promesses vagues. C’est aussi le meilleur moyen d’aligner direction, équipes et prestataire sur des priorités claires dès le départ.
1.1 Cartographier ce qui doit être “sans surprise”
Quand on lance un appel d’offres, le piège est de décrire uniquement des outils (Microsoft 365, firewall, sauvegarde) au lieu de décrire ce qui ne doit jamais s’arrêter : facturation, production, caisse, accès aux dossiers, téléphonie, accès distant, etc. Sur le terrain, les entreprises qui choisissent bien sont celles qui expriment d’abord leurs flux critiques et leurs temps de tolérance à l’arrêt. Cela permet de trier vite les prestataires qui “réparent” de ceux qui savent construire un service robuste.
Livrables attendus dès le départ
- Périmètre : sites, utilisateurs, postes, serveurs, SaaS, imprimantes, réseau, Wi-Fi, téléphonie.
- Criticité : ce qui doit être rétabli en priorité, et en combien de temps (même approximatif).
- Contraintes : horaires, saisonnalité, applicatifs métier, budget, interne disponible ou non.
1.2 Choisir le modèle : régie, forfait, infogérance, MSP
Le mot “prestataire informatique” recouvre des réalités très différentes. Un technicien en régie peut être excellent pour absorber du volume, mais insuffisant si vous attendez de la supervision proactive, du patch management, des politiques de sécurité et des rapports réguliers. À l’inverse, une infogérance forfaitaire sans gouvernance peut devenir une boîte noire : vous payez, mais vous ne savez pas ce qui est réellement fait.
| Modèle | Quand c’est pertinent | Risque typique |
|---|---|---|
| Régie / au temps | Besoins ponctuels, projets, renfort temporaire, petit parc stable | Peu de proactivité, coûts qui dérivent, dépendance à une personne |
| Forfait support | TPE/PME qui veut lisser le budget sur des incidents “classiques” | Périmètre flou, exclusions, tickets ralentis quand la charge monte |
| Infogérance | Vous attendez supervision, maintenance, documentation, changements maîtrisés | “Boîte noire” si pas de reporting, pas de SLA mesuré, pas de gouvernance |
| MSP (service managé) | Besoin d’industrialisation : outils RMM, patching, conformité, sécurité | Standardisation trop rigide si vous avez des contraintes métier fortes |
Le Conseil Pro
Si votre priorité est la continuité et la sécurité, demandez dès l’entretien : “Comment prouvez-vous ce que vous faites chaque mois ?” Un prestataire solide sort un exemple de rapport (anonymisé), des indicateurs et un calendrier de tâches récurrentes.
2) Évaluer la fiabilité : 12 preuves plus fortes que n’importe quelle promesse
Ici, l’objectif est simple : remplacer le “on est bons” par du vérifiable. Plus vous exigez des preuves, plus vous réduisez le risque de dépendre d’une personne, d’un discours ou d’une organisation improvisée.
2.1 La capacité à diagnostiquer et à prioriser en incident
Un prestataire “performant” n’est pas celui qui répond “vite” par réflexe : c’est celui qui sait qualifier (impact, cause probable, contournement), prioriser (production avant confort) et communiquer (qui fait quoi, à quel rythme). Dans un incident réel, la différence se voit dans les 30 premières minutes : questions utiles, escalade, hypothèses, et points d’avancement programmés. C’est aussi là que la maturité de l’outil de ticketing et des procédures d’astreinte fait toute la différence.
2.2 L’outillage de supervision et de gestion de parc
Sans supervision et automatisation, on travaille “à l’aveugle” et la proactivité devient un slogan. Un bon prestataire peut expliquer ce qu’il surveille (disques, sauvegardes, services, sécurité), comment il alerte, et ce qui est automatisé (patchs, inventaire, scripts). Pour comparer deux offres, exigez un exemple de tableau de bord et demandez comment ils gèrent les faux positifs : c’est souvent là qu’on voit l’expérience.
2.3 La documentation et la gestion des changements
Les environnements qui “tiennent” dans le temps ont une documentation à jour : schémas, inventaire, procédures de reprise, et historique des changements. Sur le terrain, les pires crises arrivent quand personne ne sait ce qui a été modifié la veille. Exigez une approche de “change management” même simplifiée : demande, validation, exécution, retour arrière, compte-rendu, et mise à jour documentaire.
2.4 La sécurité prouvable : accès, MFA, traçabilité, coffre-fort
Un prestataire fiable ne vous demande pas “le mot de passe admin” par e-mail. Il met en place un modèle propre : comptes nominaux, MFA, élévation temporaire, journalisation, et séparation des rôles. Le vrai test est simple : peut-il prouver qui s’est connecté, quand, et pourquoi ? Pour aller plus loin sur la conformité, notamment la gestion des données personnelles et les obligations associées, vous pouvez vous référer au RGPD (Règlement Général sur la Protection des Données Personnelles).
À éviter
Les accès partagés (“admin”, “support”, “it”) et les mots de passe stockés dans un fichier Excel. C’est confortable… jusqu’au jour où vous avez un départ, un litige, ou un incident sécurité : tout devient non traçable et juridiquement fragile.
2.5 Les sauvegardes et la capacité de restauration
Beaucoup “font des sauvegardes”. Peu savent prouver qu’ils peuvent restaurer vite, proprement, et sans surprise. Le critère sérieux : fréquence, rétention, externalisation, et surtout tests de restauration réguliers avec compte-rendu. Dans un ransomware, la sauvegarde est inutile si personne n’a déjà répété la restauration, ni défini l’ordre de redémarrage des services.
2.6 Le support : SLA, canaux, astreinte, escalade
Le SLA n’a de valeur que s’il est mesuré et reporté. Un prestataire sérieux distingue l’accusé de réception (vous n’êtes pas ignoré) du temps de rétablissement (vous reprenez le travail). Il documente aussi l’escalade (niveau 1/2/3, éditeur, opérateur) et les conditions d’astreinte si votre activité ne s’arrête pas à 18h.
| Preuve à demander | Ce que ça démontre | Signal d’alerte si absent |
|---|---|---|
| Exemple de rapport mensuel (anonymisé) | Pilotage, transparence, métriques et actions | Service “invisible”, impossible à challenger |
| Procédure d’escalade | Gestion des crises, responsabilité claire | Incidents qui stagnent, dépendance à une personne |
| Journalisation / traçabilité des accès | Sécurité, auditabilité, conformité | “On ne sait pas qui a fait quoi” |
| Preuve de tests de restauration | Résilience réelle, pas théorique | Sauvegarde potentiellement inutilisable en crise |
3) Entretiens et questions qui révèlent le niveau réel
L’entretien n’est pas un moment “sympa” : c’est un test de maturité. La bonne approche consiste à faire parler le prestataire sur sa manière de travailler, puis à vérifier qu’il peut montrer des éléments concrets (exemples, rapports, procédures, tickets anonymisés).
3.1 Questions “techniques” que même un non-spécialiste peut poser
Les meilleures questions sont celles qui obligent à décrire une méthode, pas une opinion. Si la réponse ressemble à un slogan (“on est réactifs”, “on est experts”), vous n’avez rien appris. Si la réponse décrit un enchaînement (outil → procédure → preuve → reporting), vous tenez un prestataire structuré.
- Accès : “Vos techniciens se connectent-ils avec des comptes nominatifs et MFA ?”
- Restauration : “Quand avez-vous fait votre dernier test de restauration chez un client similaire ?”
- Patchs : “Comment validez-vous une mise à jour avant déploiement large ?”
- Incidents : “À quelle fréquence envoyez-vous des points de situation en cas de panne bloquante ?”
- Sortie : “Quelle est votre procédure de réversibilité si on arrête dans 12 mois ?”
3.2 Détecter les signaux faibles avant la signature
Un signal faible n’est pas forcément “un gros drapeau rouge”, c’est un cumul de petites choses : flou sur le périmètre, discours très commercial, refus de montrer un exemple de reporting, ou difficulté à nommer un interlocuteur responsable. Dans la majorité des environnements où ça dérape, on retrouve une cause commune : tout reposait sur une personne, sans process ni documentation. Vous voulez un prestataire qui sait fonctionner même quand un technicien est absent.
Alerte
Refus de parler de réversibilité, ou réversibilité “au temps passé” sans estimation : c’est souvent le signe que la sortie sera douloureuse. Un prestataire confiant accepte de cadrer la remise des accès, la documentation et le transfert de service.
4) Contrat, SLA et réversibilité : la partie qui vous protège vraiment
Le contrat n’est pas un document “administratif” : c’est votre filet de sécurité quand il y a un incident, un désaccord, ou un changement de contexte (croissance, déménagement, cyberattaque). Plus vous rendez les engagements mesurables, plus la relation devient saine, car chacun sait ce qui est attendu.
4.1 Définir un SLA utile, pas décoratif
Un SLA sérieux sépare les niveaux de criticité (bloquant, dégradé, mineur) et prévoit deux métriques : réponse et rétablissement. Il précise aussi les horaires de couverture, les canaux (téléphone, portail, e-mail), et l’escalade. Si le document ne dit pas comment on mesure et comment on vous reporte ces indicateurs, vous êtes sur de l’affichage.
4.2 Clauses de responsabilité et zones grises
Beaucoup de contrats de services IT relèvent d’une obligation de moyens : le prestataire s’engage à mettre en œuvre des moyens raisonnables, pas à garantir un résultat parfait. Ce n’est pas “mauvais” en soi, mais cela impose d’être précis sur le périmètre, les livrables, la sécurité, et la preuve de réalisation. Sur certains dossiers, je recommande de demander un exemple de clauses types et de les confronter à un acteur expérimenté du marché, par exemple Atixit, afin de comparer la clarté des engagements et la manière dont la réversibilité est cadrée.
4.3 Réversibilité : comment vous récupérez vos clés
La réversibilité, c’est le plan de sortie : restitution des accès, transfert de la documentation, inventaire, sauvegardes, et accompagnement du repreneur. Sans cette clause, vous risquez un départ “en apnée” : mots de passe manquants, configurations non documentées, services SaaS administrés par le prestataire, factures qui continuent. Une réversibilité bien cadrée rend paradoxalement la relation plus saine, car elle enlève la peur du verrouillage.
| Élément | Ce qui doit être écrit | Pourquoi c’est critique |
|---|---|---|
| Restitution des accès | Liste des comptes, transfert admin, coffre-fort, révocation des accès prestataire | Sécurité + continuité après départ |
| Documentation | Schémas, inventaire, procédures, historique des changements | Reprise sans “trou noir” |
| Données & sauvegardes | Localisation, format, durée de conservation, effacement contrôlé | Éviter la perte et les litiges |
5) Méthode de sélection en 7 étapes avec scoring
Une sélection solide doit produire des éléments comparables : mêmes preuves demandées, mêmes questions, et un scoring simple. Le point important est d’impliquer tôt la personne qui “subit” l’IT au quotidien (référent interne, office manager, responsable de site), car ce sont eux qui voient très vite si le support tient la route.
5.1 Procédure simple qui tient en deux semaines
Quand on structure le choix, on évite la décision “au feeling” et on aligne les parties prenantes (direction, référent interne, métiers). Une bonne méthode n’a pas besoin d’être lourde : elle doit juste produire des éléments comparables d’un prestataire à l’autre. L’objectif est de sortir avec un candidat clair et un plan de transition cadré.
- Définir le périmètre : parc, sites, services, responsabilités.
- Fixer 5 priorités : continuité, cybersécurité, budget, délais, confort utilisateur.
- Demander 4 preuves : rapport mensuel, escalade, gestion des accès, test restauration.
- Entretien opérationnel : avec le futur responsable technique, pas seulement le commercial.
- Mini-audit d’entrée : inventaire, risques, quick wins, chiffrage transition.
- Négocier contrat & réversibilité : SLA mesurable, livrables, sortie.
- Plan de transition : accès, documentation, calendrier, point J+30.
5.2 Grille de scoring pragmatique
Vous pouvez scorer chaque prestataire sur 100 points pour éviter les discussions sans fin. Les critères les plus “payants” sont ceux qui se vérifient : preuves, process, sécurité et pilotage. Le prix vient après, car un prix bas sur un service mal cadré se transforme souvent en coût caché (temps perdu, incidents, urgences facturées).
Check-list scoring (exemple)
- Process & preuves (30) : rapport mensuel, change management, escalade, documentation.
- Sécurité (25) : MFA, comptes nominatifs, traçabilité, sauvegardes testées.
- Support & SLA (20) : rétablissement, astreinte, communication incident.
- Compétences & couverture (15) : M365, réseau, sauvegarde, postes, multi-sites.
- Prix & lisibilité (10) : périmètre, exclusions, coût de transition, options.
6) Pilotage après signature : le vrai facteur “performance”
Beaucoup de relations se dégradent non pas parce que le prestataire est “mauvais”, mais parce que le pilotage n’existe pas : pas de rythme, pas d’indicateurs, pas de priorités partagées. Avec un minimum de gouvernance, vous transformez le support en service, et le service en amélioration continue.
6.1 Reporting mensuel et comité court
La performance se maintient avec un rituel simple : un reporting mensuel lisible et un comité de 30 à 45 minutes. Vous devez y voir : tickets (volumétrie, récurrences), incidents majeurs, patching, sauvegardes, sécurité, et une petite roadmap (prochaines actions). Dans les structures efficaces, ce comité sert aussi à arbitrer : qu’est-ce qu’on améliore maintenant, qu’est-ce qu’on reporte, et pourquoi.
6.2 Indicateurs qui comptent vraiment
Un indicateur utile déclenche une décision. Le “nombre de tickets” seul ne dit rien ; en revanche, les tickets récurrents par cause, le taux de respect de SLA, la disponibilité des services critiques et les résultats de tests de restauration apportent une lecture opérationnelle. Pour structurer cette gouvernance, certaines entreprises s’appuient sur des acteurs qui proposent un accompagnement cadré et des rituels de suivi, par exemple Weodeo, afin d’obtenir un pilotage lisible et une feuille de route cohérente.
7) Cas concrets : ce que je regarde selon votre contexte
À périmètre égal, la “bonne” infogérance n’est pas la même pour une TPE sans référent interne et une PME multi-sites. Les priorités changent, les points de fragilité aussi : l’idée est de caler vos exigences sur vos contraintes réelles, pas sur un modèle générique.
7.1 TPE sans référent IT interne
Ici, l’enjeu est la simplicité et la disponibilité. Je privilégie un prestataire qui standardise (poste “golden”, M365 bien verrouillé, sauvegarde simple mais testée) et qui communique clairement. Le risque principal n’est pas la sophistication, c’est l’abandon silencieux quand la charge augmente : le reporting mensuel devient votre garde-fou.
7.2 PME avec applications métier et contraintes fortes
Vous avez besoin d’un prestataire capable de travailler avec des éditeurs, de gérer des changements sans casser la prod, et de documenter proprement. Dans ces environnements, la gestion des changements et les plans de retour arrière valent de l’or. Le bon prestataire ne “touche pas en direct” un vendredi soir sans filet : il anticipe, planifie, et sait revenir en arrière proprement.
7.3 Multi-sites et télétravail
La performance dépend énormément du réseau, de l’identité (SSO/MFA) et d’une gestion de parc cohérente. Je regarde la capacité à superviser à distance, à standardiser les configurations, et à traiter les incidents “réseau” avec méthode (diagnostic, logs, opérateurs). Sans cela, vous empilez des solutions et la latence devient votre quotidien.
8) FAQ ciblée
Les questions reviennent souvent au moment de comparer deux devis : budget, preuve de proactivité, certifications, et “comment je garde la main”. Ces réponses sont formulées pour vous aider à décider sans jargon, tout en gardant un niveau d’exigence réaliste.
8.1 Combien coûte un “bon” prestataire informatique ?
Le coût dépend surtout du périmètre (nombre d’utilisateurs, multi-sites), du niveau de service (astreinte, proactivité) et de la sécurité (MFA, EDR, sauvegarde immuable, etc.). Un budget faible peut tenir si votre environnement est standardisé et stable, mais il devient fragile si vous attendez une vraie résilience. Le bon réflexe : comparer des offres sur un périmètre identique et exiger la liste des exclusions, pour éviter les “surprises” au fil des tickets.
8.2 Comment vérifier qu’un prestataire est réellement “proactif” ?
Demandez un exemple de rapport mensuel, la liste des tâches récurrentes (patching, vérif sauvegardes, supervision), et un exemple d’incident géré avec chronologie (anonymisé). Un prestataire proactif sait aussi vous dire ce qu’il a empêché d’arriver : saturation disque évitée, sauvegarde en échec corrigée avant la crise, parc mis à niveau sans interruption. S’il ne peut montrer aucun livrable, la proactivité est probablement déclarative.
8.3 Dois-je exiger des certifications ?
Les certifications peuvent aider, mais elles ne remplacent pas les preuves d’exécution. Une équipe certifiée peut être mal organisée ; une petite équipe très structurée peut être excellente. Utilisez les certifications comme un signal secondaire, et concentrez votre décision sur : process, sécurité, reporting, tests, gouvernance et réversibilité.
À retenir
Un prestataire fiable se reconnaît à sa capacité à prouver : supervision, tickets, escalade, sécurité, sauvegardes testées, documentation, reporting. Le reste (discours, promesses) doit venir après, et se verrouiller contractuellement.