Pour les prestataires de services managés, la documentation n’est pas un simple « plus » : c’est le produit. Avec Trupeer, vous pouvez gagner des heures sur la rédaction de la documentation MSP en commençant par des modèles de documentation MSP gratuits, en les personnalisant avec vos directives de marque, puis en transformant la documentation client en visites vidéo que n’importe quel technicien peut utiliser.

Qu’est-ce que la documentation MSP, et en quoi est-elle différente ?

La documentation MSP correspond à tout ce qu’un prestataire de services managés consigne pour faire fonctionner la technologie d’autres organisations : inventaires des actifs, schémas réseau, identifiants, runbooks, chemins d’escalade, particularités propres au client, ainsi que les rapports et les revues que le client consulte.

Deux éléments la rendent structurellement différente de la documentation informatique interne, et presque tous les modèles ignorent les deux.

Vous documentez des environnements que vous ne possédez pas. Le client a un droit sur une partie de ce que vous écrivez et n’en a pas sur le reste, et cette ligne compte sur le plan commercial, contractuel et le jour où la relation prend fin.

Et vous documentez la même procédure sur plusieurs environnements à la fois. Une équipe interne rédige un seul runbook de restauration de sauvegarde. Un MSP en rédige un, puis doit le maintenir exact sur trente ou quarante environnements qui diffèrent de façons que personne ne se rappelle entièrement.

Le deuxième problème est celui qui grignote silencieusement la marge d’un MSP : c’est là que cette page commence. Pour la version dédiée à un seul environnement, notre modèle de documentation IT couvre le cas général.

Pourquoi quarante copies d’un runbook sont le vrai problème

Presque tous les MSP commencent de la même façon. Construisez un bon ensemble de runbooks. Onboardez un client. Copiez les runbooks dans le dossier ou l’espace du client afin que l’ingénieur qui traite le ticket ait tout au même endroit. Répétez.

C’est une intuition raisonnable, mais elle produit une catastrophe lente. Après quatre ans avec une trentaine de clients, vous avez plus d’un millier de documents, dont la plupart sont des quasi-doubles, et aucune façon de savoir quelle copie est à jour.

L’échec ne vient pas du fait que les documents sont mauvais. Chaque copie était correcte au moment où elle a été créée. Le problème, c’est que les améliorations de la méthode doivent désormais être appliquées trente fois, et qu’elles ne sont appliquées que cinq ou dix fois avant qu’on ne vous tire sur quelque chose d’urgent.

Ce que font ensuite les ingénieurs est la partie coûteuse. Une fois qu’un technicien s’est fait avoir deux fois par un runbook qui ne correspondait pas à l’environnement, il cesse de lire les runbooks. Il travaille alors à partir des principes de base, ce qui est plus lent, moins cohérent et totalement invisible dans vos reporting, car le ticket se clôture toujours.

Ainsi, la structure de documentation d’un MSP doit permettre de mettre à jour la norme à un seul endroit. Tout ce qui suit découle de cela.

Comment personnaliser ce modèle dans Trupeer

Étape 1 : Ouvrir la section Modèles

Accédez à la section Modèles depuis la navigation principale.

Étape 2 : Sélectionner et ouvrir un modèle

Cliquez sur n’importe quel modèle avec lequel vous souhaitez travailler pour l’ouvrir.

Étape 3 : Développer l’affichage du modèle

Si nécessaire, développez l’affichage du modèle pour voir clairement la mise en page complète et les détails.

Étape 4 : Modifier le modèle

Cliquez sur Modifier pour commencer à apporter des changements au modèle sélectionné.

Dans l’éditeur, vous pouvez :

• Ajouter de nouvelles sections

• Définir ou mettre à jour des règles de mise en forme

• Ajouter un logo et ajuster sa position ainsi que les paramètres associés

Étape 5 : Enregistrer votre modèle personnalisé

Une fois toutes les modifications nécessaires effectuées, cliquez sur Enregistrer pour stocker le modèle mis à jour comme le vôtre.

Étape 6 : Aperçu et ajustements fins du modèle

Lorsque vous souhaitez voir à quoi ressemble votre modèle personnalisé, ouvrez l’Aperçu.

Depuis l’écran d’aperçu, vous pouvez continuer à effectuer des ajustements directement si nécessaire, afin de garantir que le modèle s’affiche exactement comme vous le souhaitez.

Avec les modèles de documentation MSP, vous pouvez :

• Gagner du temps sur la rédaction : évitez la page blanche grâce à des structures conçues pour les opérations MSP.

• Réduire le MTTR : une documentation claire aide n’importe quel support technique pour n’importe quel client, rapidement.

• Rester fidèle à votre marque : appliquez votre logo, vos polices et vos couleurs avec le brand kit de Trupeer.

• Onboarder plus vite les techniciens : les nouveaux techniciens montent rapidement en compétence grâce à des documents clairs, basés sur la vidéo.

• Rester prêt pour les audits : des sections intégrées prennent en charge SOC 2, ISO 27001 et les audits clients.

• Toucher des équipes internationales : traduisez les documents MSP en 65+ langues en un clic.

Une excellente documentation MSP est ce qui rend une activité de services managés évolutive. Utilisez ces modèles pour capturer clairement et de manière cohérente chaque client, chaque système et chaque procédure.

Documenter la norme une fois, enregistrer uniquement l’écart

Une bibliothèque de référence. Une copie de chaque document. Versionnée, détenue, et le seul endroit où la méthode existe.

Ensuite, pour chaque client, un court document qui enregistre où ce client diffère de la norme, et rien d’autre. Pas une copie du runbook avec des modifications. Une liste d’exceptions.

Le registre des écarts client est toute l’astuce. Si le client utilise un produit de sauvegarde différent, c’est une ligne. Si son pare-feu est d’un autre fournisseur, c’est une ligne. Si son directeur financier doit approuver tout travail en dehors des horaires, c’est une ligne. Tout ce qui n’apparaît pas dans le registre est standard par définition, ce qui signifie qu’un ingénieur lit deux documents plutôt que de chercher dans un dossier en espérant que la copie qu’il contient est à jour.

Les registres restent petits. En pratique, un client « mature » se situe entre huit et vingt lignes, et l’exercice d’écrire un registre fait généralement remonter trois ou quatre écarts que personne n’avait jamais consignés ailleurs.

Il y a un deuxième avantage qui se révèle plus tard. Une liste courte de tout ce qui n’est pas standard chez un client est un excellent document de vente et de marge. Les écarts, c’est là que votre temps part.

Le registre des écarts client, et ce qu’il contient

Une ligne par écart, cinq champs.

Ce qui diffère. Indiqué par rapport à la norme, donc « la sauvegarde est Datto plutôt que notre Veeam standard » plutôt que « utilise Datto ».

Quel document standard cela affecte. La référence, afin qu’un ingénieur qui lit le runbook puisse être renvoyé ici.

Pourquoi. Préférence client, héritée d’un prestataire précédent, exigence de conformité, contrainte technique. Ce champ détermine si l’écart vaut la peine d’être supprimé.

Depuis quand, et révisé quand. Une date. Les écarts hérités lors de l’onboarding persistent souvent pendant des années, car personne ne les reconsidère.

Effort ou risque. Une courte note sur ce que cela vous coûte. C’est ce qui transforme le registre en document à la fois commercial et technique.

Ajoutez un en-tête indiquant le nom du client, la version de la bibliothèque de référence sur laquelle ce registre s’appuie, et le responsable du compte. Révisez les registres chaque trimestre. Les écarts sans raison et sans coût sont des candidats à la standardisation, et c’est généralement le travail de documentation le plus rentable qu’un MSP puisse réaliser.

Quels documents un MSP a réellement besoin, par catégorie

La plupart des MSP sont solides sur les première et cinquième lignes, mais faibles sur la troisième : c’est exactement l’inverse, car la troisième ligne est ce qui rend la deuxième exploitable.

Deux de ces catégories ont leurs propres modèles, qui valent la peine d’être utilisés directement. Les identifiants et l’inventaire des licences ont leur place naturelle dans notre registre des applications et des identifiants, et les runbooks eux-mêmes suivent la structure de notre modèle IT SOP.

Modèles de documentation MSP gratuits : la bibliothèque de référence à construire

Copiez depuis ici. C’est la bibliothèque de référence minimale, et elle est plus petite que ce que la plupart des MSP s’attendent à avoir.

Pack d’onboarding. Checklist de découverte, audit de site, capture des actifs, capture des identifiants, remplissage initial du registre des écarts, revue du premier mois. Un document, exécuté une fois par client.

Runbooks, un par tâche récurrente. Restauration de sauvegarde, création et désactivation d’utilisateurs, restauration de boîte mail, reconstruction de point de terminaison, réinitialisation de mot de passe, accès VPN, déploiement d’imprimante, renouvellement de certificat, exception de patch. Commencez par les dix tâches qui génèrent le plus de tickets plutôt que d’essayer de tout couvrir.

Escalade et astreinte. Comment un ticket s’escalade, qui est appelé à chaque niveau, ce qui constitue une urgence, et la règle d’autorisation hors horaires.

Incident et changement. Un format de revue post-incident, et un format de méthode de procédure pour les changements planifiés sur l’infrastructure du client.

Rapports destinés au client. Rapport mensuel, revue d’activité trimestrielle, et sortie d’audit de site. Format fixe, données client renseignées.

Pack de offboarding. Ce que le client reçoit, ce que vous conservez, sous quel format, et à quelle date. Rédigé avant d’en avoir besoin.

Modèle de registre des écarts. Les cinq champs ci-dessus.

Copiez ici. Dix à quinze runbooks plus six documents « permanents » constituent une bibliothèque opérationnelle. L’instinct d’écrire d’abord quarante runbooks est la raison pour laquelle la plupart des projets de documentation MSP s’enlisent au deuxième mois.

Documentation MSP interne et externe, et qui en est propriétaire

La distinction que la plupart des guides font est interne versus destiné au client, ce qui est utile pour décider du ton. La distinction la plus importante est la propriété, et elle devient concrète au moment du offboarding.

De manière générale, et cela varie selon le contrat et la juridiction, les données du client appartiennent au client : les inventaires des actifs décrivant son équipement, sa topologie réseau, ses identifiants, ses droits de licence, sa configuration. Vous les détenez en tant que prestataire de services, plutôt que de les posséder.

Votre méthode vous appartient : les runbooks standard, les formats de rapport, vos standards de création, votre modèle de tarification, vos procédures internes. Un client qui part n’a pas droit à votre bibliothèque de runbooks.

Le registre des écarts se situe de façon inconfortable entre les deux, c’est pourquoi il vaut la peine d’en parler explicitement dans votre contrat. Il décrit l’environnement du client, ce qui plaide pour qu’il soit à lui, mais il est rédigé selon vos standards, ce qui plaide pour une version expurgée.

Tranchez cela par écrit dans le contrat de service plutôt qu’au moment du départ. Cette page ne constitue pas un avis juridique et la position varie selon le contrat et la juridiction ; faites donc relire par votre avocat la propriété de la documentation et les clauses de restitution. Le faire une fois coûte une heure. Le faire pendant un offboarding coûte nettement plus cher, comme ci-dessous.

Le MSP avec 1 360 documents et neuf runbooks obsolètes

Thornbury IT a géré des services managés pour trente-quatre clients avec vingt-deux collaborateurs, dont neuf ingénieurs. À chaque onboarding, ils copiaient leur ensemble de runbooks dans l’espace du nouveau client, ce qui, à la quatrième année, représentait environ quarante documents par client et environ mille trois cent soixante au total.

Le problème s’est révélé lors d’un incident. Un ingénieur a exécuté une restauration de sauvegarde échouée pour un client en suivant le runbook de restauration de ce client, qui faisait référence à une convention de nommage d’un job Veeam. Le client avait changé de produit de sauvegarde quatorze mois plus tôt. Le runbook standard avait été mis à jour. La copie dans le dossier de ce client ne l’avait pas été.

Ils ont ensuite échantillonné les runbooks de restauration de douze clients. Neuf différaient de la norme actuelle, et cinq de ces neuf différences étaient simplement obsolètes plutôt que délibérées.

Le coût mesurable se trouvait dans le temps de traitement. Le temps moyen de traitement de niveau deux dans l’ensemble de l’entreprise était de quarante-sept minutes. Pour les clients dont les runbooks étaient obsolètes, il était de soixante et onze minutes, car les ingénieurs de ces comptes avaient cessé de faire confiance à la documentation et devaient la reconstituer à chaque fois.

Par ailleurs, un client avait quitté l’entreprise en troisième année et avait demandé sa documentation. Thornbury a envoyé le dossier du client, qui contenait ses propres runbooks standard mélangés avec l’inventaire des actifs et les identifiants du client. Personne n’avait jamais tracé la frontière. Le débat sur ce à quoi le client avait droit a duré six semaines et a impliqué les avocats des deux cabinets.

La reconstruction a pris un mois de travail pour une seule personne. Une bibliothèque standard, une seule copie, versionnée. Par client, uniquement un registre des écarts. La longueur médiane des registres était de onze lignes.

Mille trois cent soixante documents sont devenus quarante documents standard et trente-quatre registres, soit soixante-quatorze au total. Le temps de traitement de niveau deux s’est stabilisé à quarante-quatre minutes sur tous les comptes. Et le pack de offboarding a été défini dans le contrat à partir de ce moment-là : le client reçoit l’inventaire des actifs, les identifiants, les schémas et son registre des écarts, et Thornbury conserve la bibliothèque standard.

Existe-t-il des modèles de documentation MSP gratuits sur GitHub ?

Oui, et ils valent le coup d’être consultés avec des attentes réalistes.

Vous y trouverez des dépôts communautaires de collections de runbooks, des bibliothèques de scripts PowerShell avec documentation intégrée, des frameworks de documentation basés sur markdown, et parfois une structure complète de documentation publiée par un MSP dans le cadre d’une démarche de recrutement ou de marketing. En recherchant des runbooks MSP ou de la documentation IT avec markdown ou docs-as-code, vous trouverez la plupart de ces ressources.

Ce qui est réellement utile dans ces dépôts, c’est la structure et la couverture : la liste des runbooks qu’un MSP compétent maintient constitue une bonne checklist pour la vôtre. Ce qui est rarement utile, c’est le contenu, car les runbooks sont spécifiques à une pile d’outils, et une procédure de restauration pour le produit de sauvegarde et le RMM de quelqu’un d’autre ressemble davantage à un exemple travaillé qu’à un modèle.

Deux précautions. Vérifiez la licence avant d’incorporer quoi que ce soit dans une bibliothèque de documentation commerciale, car les licences permissives sont fréquentes mais pas universelles. Et n’adaptez jamais un dépôt qui contient de vrais identifiants clients, des détails réseau ou tout ce qui ressemble à des identifiants, car cela apparaît dans des dépôts publics plus souvent que ce qui devrait.

L’approche docs-as-code elle-même, c’est-à-dire le markdown dans le contrôle de version, est une option légitime pour un MSP et elle résout élégamment le problème de la copie unique. Son point faible est que, sous pression, les ingénieurs ne s’engagent pas à maintenir un dépôt ; l’adoption devient donc le facteur limitant plutôt que l’outillage.

Logiciel de documentation MSP et le problème de verrouillage fournisseur

Les plateformes de documentation conçues pour les MSP sont excellentes sur ce qui est difficile à construire soi-même : relations structurées entre actifs, intégration avec votre RMM et PSA, gestion des identifiants avec une piste d’audit, et séparation par client avec des permissions.

Le compromis, c’est que votre documentation est façonnée par leur modèle de données, et la récupérer ensuite sous une forme exploitable est souvent pire que ce que le processus de vente laisse entendre. L’export signifie généralement un ensemble d’enregistrements plutôt que les documents lisibles que vos ingénieurs utilisent réellement.

Deux questions valent la peine d’être posées avant de s’engager. Pouvez-vous exporter tout, y compris les relations et les pièces jointes, dans un format qui resterait utilisable si vous n’aviez jamais acheté un autre produit. Et pouvez-vous maintenir un document standard unique applicable à tous les clients, ou le modèle impose-t-il une copie par client, ce qui réintroduit exactement le problème dont parle cette page.

Cette deuxième question élimine plus de produits que vous ne l’imaginez. Lorsqu’une plateforme impose des copies par client, conservez la bibliothèque standard en dehors, dans quelque chose de plus simple, et utilisez la plateforme pour les données d’environnement client, c’est-à-dire ce pour quoi elle est réellement faite. Notre modèle de base de connaissances couvre la structuration de cette bibliothèque standard, quel que soit l’endroit où elle vit.

Que devient la documentation lorsqu’un client quitte ?

Le offboarding est là où la qualité de la documentation devient visible, généralement pour des personnes déjà mécontentes.

Définissez le pack dans le contrat. Une position raisonnable est que le client reçoit son inventaire des actifs, ses schémas réseau, son inventaire des licences, des identifiants transférés de manière sécurisée, son registre des écarts, ainsi que toute documentation pour laquelle il a payé en tant que livrable. Vous conservez vos runbooks standard, vos formats de rapport et vos procédures internes.

Fixez un calendrier et un format dans la même clause, car « la documentation sera fournie » est là que les litiges commencent. Trente jours et un format spécifié sont la norme.

Faites la remise des identifiants via un processus approprié plutôt qu’un tableur, et consignez ce qui a été transféré et quand, car cet enregistrement protège les deux parties si quelque chose est consulté plus tard.

Lorsque le départ correspond à un transfert vers un autre prestataire plutôt qu’à un traitement en interne, une remise structurée coûte considérablement moins cher qu’un « dump » de documents, et notre SOP de transfert de connaissances explique comment en exécuter une.

Puis-je obtenir des modèles de documentation MSP en PDF ?

Le PDF convient à deux de ces éléments et ne convient pas aux autres.

Adapté aux documents destinés au client : le rapport mensuel, la revue trimestrielle, la sortie d’audit de site. Ce sont des instantanés d’un moment, et les figer est correct ; ils doivent aussi porter votre image de marque.

En revanche, ce n’est pas adapté aux runbooks, au registre des écarts et à l’inventaire des actifs, qui évoluent tous et doivent tous être consultables. Une bibliothèque de runbooks en PDF est une version plus lente du problème de l’exemple ci-dessus, car un PDF ne peut pas dire à un lecteur qu’il est obsolète.

Pour la bibliothèque standard, utilisez ce que vos ingénieurs consulteront réellement sous pression, et conservez une seule copie. Pour les livrables destinés au client, générez le PDF à partir de cette source plutôt que d’en maintenir une version séparée.

Comment garder la bibliothèque standard à jour pour chaque client

Toute la structure dépend du fait que la bibliothèque standard soit réellement maintenue, et la raison pour laquelle elle ne l’est généralement pas est qu’une mise à jour d’un runbook implique que quelqu’un capture l’écran, recadre et réécrive des étapes pour un outil qu’il sait déjà utiliser.

Trupeer AI supprime la plupart de cela. Un ingénieur effectue la tâche une fois face caméra, et le résultat est un runbook mis en forme avec les étapes et les écrans déjà en place, prêt à être relu plutôt qu’à être rédigé. Une mise à jour de dix runbooks devient une journée au lieu d’un trimestre.

Enregistrez-le. Mettez-le à votre marque. Traduisez-le. Faites-le avec Trupeer.

Pour le contenu destiné au client, l’image de marque compte commercialement, et les brand kits signifient que le rapport et le guide que reçoit un client ressemblent à ce qui vient de vous plutôt que d’un modèle. La documentation et la documentation technique conservent ensemble la bibliothèque standard et les enregistrements de l’environnement client, et le créateur de SOP couvre les runbooks eux-mêmes. Les instructions de configuration se trouvent dans le guide de configuration du modèle de document.

Questions fréquentes

Existe-t-il des modèles de documentation MSP gratuits en PDF ?

Les structures de cette page sont gratuites à copier, et la séparation logique consiste à conserver les runbooks et les registres dans quelque chose de consultable, tout en exportant les rapports destinés au client en PDF. Il n’y a pas de téléchargement réservé et pas de formulaire. Si vous voulez un PDF de la bibliothèque standard pour référence, générez-le à partir de votre copie en direct plutôt que de le maintenir séparément.

Quels sont les meilleurs modèles de documentation MSP gratuits ?

Le meilleur ensemble est le plus petit que vous pourrez maintenir à jour : dix à quinze runbooks couvrant vos volumes de tickets les plus élevés, un pack d’onboarding, un document d’escalade, un format de registre des écarts, et trois formats de rapports destinés au client. Évaluez toute bibliothèque de modèles selon qu’elle sépare la norme de l’exception propre à chaque client, car c’est cette partie qui détermine si elle survit à trente clients.

Où un MSP doit-il conserver sa documentation ?

Les données d’environnement client appartiennent à une plateforme qui s’intègre à votre RMM et PSA et gère correctement les identifiants. La bibliothèque standard appartient à l’endroit où les ingénieurs la consulteront le plus rapidement, ce qui peut être la même plateforme ou quelque chose de plus simple. La question décisive est de savoir si la plateforme vous permet de maintenir un document unique applicable à tous les clients.

Quelle quantité de documentation un nouveau client doit-il recevoir lors de l’onboarding ?

Aucune de votre bibliothèque standard, et toutes les données de son propre environnement. En pratique, le livrable d’onboarding que le client valorise est l’inventaire des actifs, le schéma réseau et un résumé simple de ce que vous avez trouvé et de ce que vous recommandez. Envoyer des runbooks dès l’onboarding est une intuition courante, mais cela donne votre méthode sans retour commercial.

Le client possède-t-il la documentation que nous rédigeons sur ses systèmes ?

Leurs données, généralement oui ; votre méthode, généralement non, et la frontière doit être écrite dans le contrat de service plutôt que débattue au moment du départ. Les inventaires des actifs, les schémas, les identifiants et la configuration décrivent leur propriété. Vos runbooks standard et vos formats de rapport sont votre propriété intellectuelle. Faites relire la clause par votre propre avocat, car la position varie selon le contrat et la juridiction.

Comment empêcher les ingénieurs de sauter la documentation ?

Rendez d’abord la bibliothèque standard digne de confiance. Les ingénieurs sautent la documentation parce qu’elle a déjà été fausse, pas parce qu’ils n’aiment pas la lire. Résolvez le problème de la copie unique, faites converger les temps de traitement, et le comportement change de lui-même. Exiger des mises à jour de la documentation uniquement à la clôture du ticket ne fonctionne qu’une fois que la bibliothèque vaut la peine d’être mise à jour.