La documentation minimale qui rend un SI transmissible

14 novembre 2026

Illustration originale — La documentation minimale qui rend un SI transmissible

Imaginez une situation illustrative. Lundi matin, la responsable de l’exploitation annonce son départ sous trois semaines. Elle seule sait pourquoi la facturation doit précéder une synchronisation ERP, quel prestataire rappeler en cas d’échec et quelle manipulation évite de doubler les écritures. Les sauvegardes sont au vert et les contrats existent. Pourtant, le SI n’est pas transmissible : sa continuité dépend d’une mémoire individuelle. Pour le DSI, la décision n’est pas de « tout documenter ». Elle consiste à rendre explicites, dans le temps disponible, les connaissances sans lesquelles une autre personne ne pourrait ni exploiter, ni arbitrer, ni reprendre le contrôle.

Documenter pour permettre une décision, pas pour remplir un référentiel

Une documentation utile répond à une question opérationnelle : que doit savoir un successeur pour agir sans deviner ? L’accumulation de procédures, de captures d’écran et de diagrammes non datés crée parfois davantage d’incertitude qu’elle n’en résout. Le minimum couvre les objets qui engagent l’entreprise : services critiques, applications, données, infrastructures, fournisseurs, accès privilégiés, changements en cours et continuité. Pour chacun, il faut identifier le responsable métier, le responsable IT, la criticité, les dépendances majeures et la prochaine décision attendue. Cette logique transforme la documentation en instrument de gouvernance. Elle évite qu’un comité valide une migration sans connaître un contrat bloquant, ou qu’un RSSI traite une vulnérabilité sans mesurer le processus métier interrompu.

Commencer par les parcours dont l’arrêt coûte immédiatement

La première étape consiste à sélectionner quelques parcours vitaux : encaisser, facturer, produire, expédier, payer ou servir les clients. Le DSI demande quelles applications, interfaces, données, équipes et prestations rendent chacun possible. Ce travail révèle les dépendances que l’inventaire technique masque : un fichier déposé manuellement, un certificat renouvelé par une seule personne, un compte administrateur détenu par un intégrateur, une reprise nocturne jamais formalisée. Il faut résister à la tentation de cartographier tout le patrimoine au même niveau. Un composant secondaire peut attendre ; une interface discrète qui bloque la facturation exige une fiche exploitable. La priorité découle de l’impact métier et de la difficulté de reprise, non de la visibilité technologique.

Constituer un dossier minimal par service critique

Le dossier minimal suit une structure stable. Il décrit la finalité du service, ses utilisateurs, ses heures sensibles, son propriétaire métier et son responsable technique. Il recense les composants et flux indispensables, les contacts, les engagements de service, les contrats associés et les coûts nécessitant un arbitrage. Il précise où sont gérés les accès sans jamais recopier de secrets. Il indique les sauvegardes, les modalités de restauration, le plan de reprise, la dernière date de test et les écarts connus. Enfin, il présente les incidents récurrents, les changements prévus et les décisions ouvertes. Ce dossier n’explique pas chaque écran. Il doit permettre à un professionnel compétent de comprendre la situation, retrouver la bonne preuve et mobiliser le bon acteur.

Faire produire la preuve par ceux qui détiennent le savoir

La documentation échoue lorsqu’elle devient le chantier solitaire d’un PMO ou d’un nouvel arrivant. Le détenteur du savoir doit démontrer qu’une autre personne peut l’utiliser. Une méthode efficace associe entretien court, rédaction structurée, revue par le propriétaire métier puis exercice de reprise. Le remplaçant exécute une opération représentative, retrouve un contrat, explique une dépendance ou déroule un scénario d’incident à partir du dossier. Chaque hésitation signale une lacune concrète. Le DSI arbitre alors entre correction immédiate, risque accepté temporairement et action planifiée. Cette épreuve vaut davantage qu’une validation formelle : elle mesure la capacité réelle de transmission. Elle révèle aussi les délégations ambiguës, les droits excessifs et les prestations dont personne ne contrôle vraiment la sortie.

Mesurer la transmissibilité sans fabriquer un faux score

Quelques indicateurs suffisent s’ils conduisent à l’action. Le premier est la part des services critiques dotés d’un propriétaire métier et d’un responsable IT nommés. Le deuxième est la proportion de dossiers revus selon leur criticité. Le troisième suit les procédures critiques testées par une personne autre que leur auteur. On peut ajouter le nombre de dépendances sans remplacement, de comptes privilégiés sans responsable, de contrats sans réversibilité comprise et de plans de reprise sans preuve de test exploitable. Ces mesures ne doivent pas être agrégées dans une note rassurante. Un seul service vital sans procédure de restauration peut peser davantage que vingt fiches parfaitement renseignées sur des outils accessoires.

Éviter les trois pièges qui rendent la documentation décorative

Le premier piège est l’exhaustivité : le programme s’enlise avant d’avoir sécurisé les connaissances urgentes. Le deuxième est l’obsolescence silencieuse : personne ne sait qu’un document est faux parce qu’aucun propriétaire ni déclencheur de mise à jour n’est défini. Le troisième est la confusion entre documentation et maîtrise. Une procédure peut exister sans que les accès soient disponibles, le fournisseur joignable ou la restauration fonctionnelle. Chaque document critique doit donc porter un responsable, une date de revue, un événement de mise à jour et une preuve de test. Il faut conserver les décisions, pas seulement l’état final. Lors d’un audit ou d’une crise, comprendre pourquoi une exception a été acceptée est souvent aussi important que connaître la configuration actuelle.

Arbitrer entre vitesse, profondeur et risque assumé

Le dirigeant IT doit finalement choisir où investir l’effort. Tout documenter retarde la réduction des risques ; ne documenter que les gestes techniques laisse les arbitrages invisibles. La bonne décision consiste à fixer un seuil minimal commun, puis à approfondir selon la criticité et la dépendance humaine. Un service essentiel porté par un expert unique exige une transmission testée, même si son architecture est simple. Une plateforme industrialisée peut se satisfaire d’une documentation plus légère si les responsabilités, preuves et mécanismes de reprise sont clairs. Cette approche rejoint la gouvernance pragmatique défendue dans Révolution Numérique ! : relier les choix technologiques aux enjeux de contrôle, de résilience et de dépendance. Un SI devient transmissible non lorsqu’il est entièrement décrit, mais lorsqu’un changement de personne ne transforme plus chaque décision en enquête et chaque incident en pari.