Résumé exécutif

Les connaissances critiques pour l’activité ne doivent pas dépendre de personnes isolées.
Si un administrateur système ou une autre personne clé devient soudainement indisponible, l’absence de documentation, d’accès ou de suppléance peut très rapidement devenir un risque opérationnel majeur.
Les entreprises doivent donc identifier les connaissances critiques détenues par certaines personnes, documenter les processus opérationnels, former réellement les suppléants et sécuriser de manière indépendante les accès administratifs ainsi que les informations d’urgence. L’objectif n’est pas de documenter le plus possible, mais de garantir que l’activité peut se poursuivre même sans une personne clé déterminée.
Le test le plus simple : Imaginez qu’à partir de demain, une personne clé n'est plus joignable pendant trois mois. Pourrez-vous poursuivre l’activité sans devoir lui poser de questions ? Si ce n’est pas le cas, il faut agir.

Il faut demander à notre administrateur système

Dans les entreprises, on entend étonnamment souvent cette phrase ou une phrase similaire.
« Seul Monsieur Meyer le sait. »
« C’est notre comptable qui avait mis cela en place à l’époque. »
« C’est Madame Müller qui s’en occupe. »
Ou, tout simplement : « Aucune idée, c’est toujours l’informatique qui s’en charge. »
À première vue, il n’y a rien d’inhabituel à cela. La répartition du travail fait partie de toute entreprise. Personne ne peut ni ne doit tout savoir. Cela devient problématique lorsque la réponse complète est en réalité :
« Seul notre administrateur système le sait. »
Car il ne s’agit alors plus seulement de spécialisation. Il s’agit d’un risque pour l’entreprise.

Que se passe-t-il lorsque vous ne pouvez plus lui demander ?

Tant que la personne concernée vient travailler chaque matin, cette dépendance passe presque inaperçue.
L’administrateur système connaît les serveurs. Il sait où les mots de passe sont conservés. Il connaît le fournisseur d’accès Internet, le pare-feu, la sauvegarde et les particularités des applications. Il sait pourquoi un certain programme est lancé chaque nuit à 02:15 depuis de nombreuses années – et probablement aussi ce qui se passe s’il ne démarre pas. Tout fonctionne. Il semble donc qu’il n’y ait aucun problème.
Jusqu’au jour où le collaborateur devient indisponible. La phrase apparemment anodine prend alors soudain une tout autre signification :
« Il faut demander à notre administrateur système. »
Seulement voilà : Vous ne pouvez plus le lui demander.

L’administrateur système comme documentation vivante

Dans les petites et moyennes entreprises en particulier, les environnements informatiques se sont souvent développés au fil de nombreuses années. À un moment donné, un collaborateur a commencé à s’occuper de quelques ordinateurs en plus de ses tâches habituelles. Puis un serveur est venu s’ajouter. Et bien d’autres choses encore.
Avec le temps, ce collaborateur finit par détenir un savoir sur l’entreprise qui dépasse largement l’administration système proprement dite.
Il sait par exemple :
  • quel serveur remplit quelle fonction
  • quelles applications dépendent les unes des autres
  • quels utilisateurs techniques sont utilisés
  • où les licences sont gérées
  • quels certificats doivent être renouvelés
  • comment fonctionne la sauvegarde
  • quels systèmes communiquent entre eux pendant la nuit
  • quel prestataire externe doit être appelé en cas de panne donnée
  • et quelles particularités doivent être prises en compte lors des traitements de fin de mois, de trimestre ou d’année
Ce savoir est précieux. Le problème n’est pas l’administrateur système. Au contraire : un collaborateur disposant d’une telle expérience est extrêmement précieux pour une entreprise. Le problème apparaît lorsque ce savoir n’existe que dans la tête de cette personne.
L’entreprise dispose alors certes de systèmes fonctionnels – mais peut-être pas d’un contrôle complet sur ces systèmes.

Le problème ne se limite pas à l’informatique

Ce qui vaut pour l’administrateur système se retrouve dans presque tous les domaines de l’entreprise. Un collaborateur est le seul à savoir comment établir la déclaration mensuelle de TVA. Une collaboratrice connaît toutes les règles particulières applicables aux principaux clients. Le responsable de production sait quoi faire lorsqu’une machine présente une panne bien précise. Un autre collaborateur connaît des accords passés avec un fournisseur il y a douze ans et qui n’ont jamais été correctement documentés.
Et presque chaque entreprise connaît au moins une personne dont on dit :
« Il sait tout, tout simplement. »
Comme compliment, c’est certainement positif. Du point de vue de la gestion des risques, cette phrase devrait toutefois immédiatement déclencher une alarme. Plus le savoir d’une seule personne est important pour la poursuite de l’activité, plus il est important de rendre ce savoir accessible à l’entreprise elle-même.
Il ne s’agit nullement de vouloir rendre les bons collaborateurs interchangeables. Il s’agit de tout autre chose :
L’entreprise doit rester capable d’agir même si une personne clé devient soudainement indisponible.

Une histoire vraie

Il y a quelques années, nous avons été confrontés à une situation qui pouvait difficilement illustrer plus clairement les conséquences d’une documentation insuffisante. Il s’agissait d’une PME suisse d’environ 200 collaborateurs. Le comptable s’est senti mal, s’est allongé un moment et n’est jamais revenu.
Mais le comptable était bien plus qu’un simple comptable. C’était un collaborateur de l’ancienne école. Présent depuis de nombreuses années dans l’entreprise, fiable, expérimenté et doté d’une connaissance exceptionnelle de la société. Il connaissait la comptabilité. Il connaissait les salaires. Il s’occupait de nombreux processus administratifs. Et, en plus de cela, il était également responsable de parties importantes de l’informatique.
En résumé : Il savait comment fonctionnait l’entreprise.
Le problème était le suivant : Rien de tout cela n’était documenté.
Il existait des processus, mais pas de procédures détaillées. Il existait des programmes, mais presque aucune description. Il y avait des échéances administratives et des dépendances qui avaient toujours été gérées de manière fiable – principalement parce que cette seule personne savait ce qui devait être fait et à quel moment. D’un instant à l’autre, ce savoir n’était plus disponible.

L’activité doit continuer

Notre entreprise a pu mettre très rapidement quatre personnes à disposition afin d’assurer dans un premier temps un fonctionnement d’urgence. Il ne s’agissait pas seulement de remettre quelques ordinateurs en marche. Il fallait notamment poursuivre le traitement des salaires ; les quelque 200 collaborateurs attendaient à juste titre leur salaire. Des paiements devaient être effectués. Les échéances administratives devaient être respectées. Les données devaient être traitées. Les processus métier ne pouvaient tout simplement pas s’arrêter.
La reconstruction a donc commencé. Nous avons analysé des programmes, des fichiers, des impressions, des classements, des échéances et les documents existants. Nous avons parlé avec les collaborateurs afin de déterminer qui connaissait quelles parties d’un processus. Peu à peu, une vue d’ensemble s’est reconstituée. Nous avons établi des procédures détaillées pour les différents domaines. Les processus reconstruits ont été documentés et transmis aux collaborateurs responsables avec les informations nécessaires.
Après environ deux mois, nous avons pu remettre une administration d’entreprise proprement réorganisée. Le fonctionnement reposait à nouveau sur une base de connaissances nettement plus large.
L’entreprise a eu de la chance, car la situation aurait pu être nettement plus grave.
Si, par exemple, des données d’accès essentielles avaient manqué, si des systèmes externes n’avaient plus été accessibles ou si des étapes centrales de traitement n’avaient pas pu être reconstituées, les dommages auraient pu être considérablement plus importants.
Cette expérience permet de dégager un principe très simple : Le savoir nécessaire au fonctionnement d’une entreprise ne doit jamais appartenir exclusivement à une seule personne.
Cela vaut pour le comptable. Pour le responsable de production. Pour le directeur. Et, bien entendu, pour l’administrateur système.

La documentation n’est pas de la bureaucratie

Lorsqu’on demande de documenter, on entend souvent une autre phrase : « Nous n’avons pas le temps pour cela. »
C’est compréhensible. Documenter prend du temps.
Mais peut-être faudrait-il poser la question autrement : Combien de temps avez-vous si la personne concernée n’est plus disponible demain ?
Tout à coup, d’autres questions se posent :
  • Quel fournisseur exploite réellement notre connexion Internet ?
  • Au nom de qui notre domaine a-t-il été enregistré ?
  • Qui dispose de l’accès administrateur à Microsoft 365 ?
  • Comment accède-t-on au pare-feu ?
  • Où se trouve la dernière sauvegarde fonctionnelle ?
  • Qui peut administrer notre système ERP ?
  • Quel traitement doit être lancé à la fin du mois ?
  • Quels certificats arrivent prochainement à expiration ?
  • Quels prestataires doivent être appelés en cas d’incident ?
  • Et que fait exactement ce serveur que plus personne n’ose toucher depuis des années ?
Une bonne documentation répond à ces questions avant l’urgence, et pas seulement lorsqu’elle survient.
La documentation présente encore un autre avantage : celui qui décrit proprement un processus est obligé de le remettre en question. C’est souvent à ce moment-là que des dépendances inutiles, des responsabilités peu claires ou des faiblesses techniques deviennent visibles.
La documentation n’est donc pas seulement une mesure de sécurité. Elle constitue également une occasion de vérifier et d’améliorer les processus existants.
Ce n’est pas de la bureaucratie inutile. Cela fait partie d’une gestion professionnelle de l’entreprise.

Mais la documentation seule ne suffit pas

Un classeur portant l’étiquette « Documentation IT » ne constitue pas encore une préparation aux situations d’urgence. La documentation doit être à jour. Elle doit être compréhensible et elle doit être disponible en cas d’urgence.
Un guide de restauration parfait, stocké exclusivement sur le serveur qui vient précisément de subir une panne totale, n’a qu’une utilité pratique limitée. Les mots de passe ne doivent évidemment pas non plus être inscrits sans contrôle dans la documentation. Les accès critiques nécessitent une gestion réglementée des mots de passe et un accès d’urgence clairement défini.
Toutes les informations ne doivent toutefois pas être accessibles à tous les collaborateurs. Les mots de passe, les secrets d’affaires et les autres informations sensibles nécessitent une protection appropriée. En revanche, les instructions de travail et les descriptions de processus doivent être accessibles aux personnes qui travaillent avec elles et en assument la responsabilité. Pour les informations particulièrement protégées, il faut néanmoins garantir que les personnes autorisées peuvent y accéder en cas d’urgence.
Sécurité et disponibilité ne sont pas contradictoires. Les deux doivent être organisées.
L’objectif réel n’est donc pas : « Nous devons documenter le plus possible. »
Mais plutôt : Un suppléant autorisé doit pouvoir, à l’aide des informations disponibles, poursuivre l’exploitation ou faire intervenir de manière ciblée les spécialistes appropriés.

Faites le test des trois mois

Pour la direction et le management, il existe un exercice de réflexion très simple. Imaginez la situation suivante : votre administrateur système termine sa journée ce soir et n’est plus joignable pendant trois mois. Ni par téléphone ni par un autre moyen.
Que se passe-t-il demain matin ?
  • Quelqu’un peut-il accéder à tous les systèmes nécessaires ?
  • Quelqu’un connaît-il les problèmes actuellement ouverts ?
  • Quelqu’un sait-il quelles tâches doivent être effectuées quotidiennement, chaque semaine, chaque mois et chaque année ?
  • Peut-on créer, modifier et désactiver des utilisateurs ?
  • Peut-on restaurer une sauvegarde ?
  • Les interlocuteurs externes sont-ils connus ?
  • Quelqu’un sait-il quand les licences, certificats et contrats arrivent à expiration ?
  • Un nouvel administrateur système peut-il comprendre comment l’environnement est structuré ?
Si vous devez répondre « Non » ne serait-ce qu’à une seule de ces questions, il faut agir. C’est encore plus évident lorsque la réponse est : « Notre administrateur système le sait probablement. »

Liste des actions à entreprendre : les points essentiels

  1. Identifier les personnes clés
    Déterminez, dans tous les domaines importants de l’entreprise, quelles connaissances nécessaires au fonctionnement ne sont détenues que par une seule personne. Une question utile est : « Qu’est-ce qui ne fonctionnerait plus si cette personne était indisponible pendant trois mois à partir de demain ? »
  2. Identifier les processus critiques
    Documentez les processus indispensables au fonctionnement de l’entreprise. Il peut notamment s’agir des salaires, des paiements, de la facturation, de la production, des achats, des sauvegardes et des traitements IT centraux.
  3. Définir des suppléants
    Pour chaque tâche critique, au moins une deuxième personne doit être désignée. Une suppléance inscrite dans l’organigramme ne suffit pas. Cette personne doit disposer des connaissances et des autorisations nécessaires.
  4. Documenter l’environnement système
    Les serveurs, applications, réseaux, services cloud, interfaces ainsi que les connexions internes et externes doivent être décrits de manière compréhensible. Il faut également pouvoir identifier les dépendances entre systèmes et les services externes nécessaires au fonctionnement.
  5. Sécuriser les accès administratifs
    Aucun accès critique pour l’entreprise ne doit dépendre exclusivement du compte personnel ou du savoir d’un seul collaborateur. Cela vaut en particulier pour les fournisseurs, les domaines, les services cloud, les pare-feux et les applications centrales.
  6. Gérer les mots de passe de manière professionnelle
    Les mots de passe critiques n’ont leur place ni sur des Post-it ni dans des tableaux Excel non chiffrés. Utilisez une solution appropriée de gestion des mots de passe et définissez un accès d’urgence réglementé.
  7. Recenser les partenaires externes et les contrats
    Documentez les fournisseurs concernés, les éditeurs de logiciels, les partenaires de maintenance et les spécialistes. Cela comprend les interlocuteurs, les numéros de client, les informations contractuelles, les canaux de support et, le cas échéant, les délais de réaction convenus.
  8. Créer des procédures d’exploitation
    Les tâches récurrentes et critiques doivent être décrites de manière à ce qu’un suppléant qualifié puisse les exécuter. Les traitements quotidiens, de fin de mois et de fin d’année ainsi que les situations d’incident typiques sont particulièrement importants.
  9. Tester la sauvegarde et la restauration
    « Nous faisons une sauvegarde tous les jours » n’est pas une réponse suffisante. Ce qui compte, c’est de savoir si cette sauvegarde peut réellement être restaurée. Des tests réguliers de restauration font partie de la préparation aux situations d’urgence.
  10. Conserver les informations d’urgence de manière indépendante
    Les informations les plus importantes doivent rester accessibles même lorsque le réseau, les serveurs ou les services cloud centraux sont indisponibles. La protection des données et le contrôle des accès doivent bien entendu rester garantis.
  11. Vérifier régulièrement les documentations
    Une documentation obsolète peut être plus dangereuse que l’absence de documentation, car elle donne un faux sentiment de sécurité. Les responsabilités et les intervalles de contrôle doivent donc être clairement définis.
  12. S’exercer réellement au scénario d’urgence
    Le test le plus révélateur est simple : pendant un exercice, l’administrateur système ne doit pas aider. Confiez une tâche concrète à un suppléant qualifié et vérifiez s’il peut l’exécuter uniquement à l’aide des informations disponibles. Chaque question nécessaire révèle une lacune dans la documentation ou dans les connaissances.

La sécurisation du savoir relève du management

La responsabilité de ce sujet ne repose pas uniquement sur l’administrateur système. Bien entendu, un administrateur système doit documenter correctement ses systèmes. Mais la décision de sécuriser systématiquement les connaissances critiques de l’entreprise relève en définitive du management. Si, pendant des années, un administrateur système gère seul tous les systèmes tout en consacrant chaque minute disponible aux problèmes des utilisateurs, aux projets et aux incidents, il ne faut pas s’étonner que la documentation reste incomplète.
La documentation prend du temps. Le transfert de connaissances prend du temps. La formation d’un suppléant prend également du temps. Mais ce temps n’est pas improductif.
Ce temps est un investissement dans la sécurité opérationnelle de l’entreprise.
Un suppléant doit aussi réellement assurer la suppléance de temps à autre. Une personne qui figure depuis cinq ans dans l’organigramme « pour les urgences », mais qui n’a jamais restauré elle-même une sauvegarde, administré un utilisateur ou exécuté un traitement de fin de mois, n’est que très partiellement préparée à une véritable situation d’urgence. Un bon administrateur système ne devrait donc pas être évalué en fonction du nombre de tâches qu’il est le seul à savoir exécuter.
Au contraire : Un administrateur système professionnel met en place des structures qui permettent à l’exploitation de se poursuivre même sans sa présence immédiate.
Cela ne le rend pas moins important. Cela démontre son professionnalisme.

Du savoir individuel au savoir de l’entreprise

Aucune entreprise ne peut documenter l’ensemble des connaissances de ses collaborateurs. Ce ne serait ni possible ni utile. Mais une limite claire doit être fixée lorsqu’il s’agit de connaissances critiques pour l’activité.
La question décisive est la suivante : L’entreprise a-t-elle besoin de ce savoir pour pouvoir continuer à fonctionner ?
Si la réponse est oui, ce savoir doit être mis à la disposition de l’entreprise sous une forme appropriée.
Peut-être êtes-vous vous-même la personne qui détient dans sa tête une part importante du savoir de l’entreprise. Dans ce cas, la même question s’applique à vous : L’activité peut-elle se poursuivre si vous devenez indisponible pour une période prolongée à partir de demain ?
Cette question ne se pose pas uniquement en cas d’urgence. Lors d’une succession d’entreprise, d’une vente ou d’une transmission, on constate également très rapidement quelle part du savoir appartient réellement à l’entreprise – et quelle part n’existe que dans la tête de certaines personnes. Une bonne documentation ne crée donc pas seulement de la sécurité. Elle facilite également une future transmission de l’entreprise.

Savoir détenu par des personnes externes

Il en va de même pour le savoir détenu par des partenaires externes – qu’il s’agisse de spécialistes individuels ou de grands fournisseurs de solutions. Dans les projets externalisés en particulier, il convient donc de définir clairement dès l’attribution du mandat quelle documentation doit être produite, quel niveau de qualité elle doit atteindre et à quel moment elle doit être remise. Ces exigences ne doivent pas être vérifiées uniquement à la fin du projet, mais pendant toutes ses phases.
Même les grands fournisseurs ne protègent pas automatiquement contre les dépendances à certaines personnes. Si un spécialiste important quitte une équipe de projet, un savoir précieux peut être perdu ou devoir être reconstitué au prix d’efforts considérables. La situation devient particulièrement problématique lorsque des décisions importantes, des configurations ou des relations techniques ne sont connues que de quelques membres de l’équipe de projet.
La valeur d’une bonne documentation apparaît au plus tard lors d’un changement ultérieur de fournisseur. Une solution correctement documentée peut être reprise et poursuivie par un nouveau partenaire. Si cette base manque, il faut d’abord reconstituer ce qui avait été mis en place à l’origine et pourquoi certaines décisions avaient été prises. Cela coûte du temps et de l’argent et augmente en même temps le risque opérationnel.
La documentation doit donc constituer un élément contraignant de la réception du projet.
Les composants critiques ne doivent être considérés comme terminés que lorsque la documentation correspondante est complète, à jour et compréhensible. Il est également judicieux de lier contractuellement certains jalons et validations de paiement à la remise de la documentation convenue. Il ne suffit pas de vérifier qu’un document existe et qu’il a été formellement approuvé. Ce qui compte, c’est de savoir si une personne compétente peut réellement comprendre, exploiter et, si nécessaire, reprendre la solution à l’aide de ces documents.
Si l’entreprise ne dispose pas elle-même des compétences nécessaires pour cette évaluation, il peut être judicieux de faire contrôler la documentation par un spécialiste indépendant. Ce contrôle ne doit pas seulement vérifier la présence de tous les documents et signatures requis, mais surtout si leur contenu est complet, compréhensible et techniquement exploitable.
Le même principe vaut donc pour les prestations fournies par des tiers : Au final, le savoir nécessaire au fonctionnement doit être disponible dans l’entreprise – et ne doit pas rester au sein de l’équipe de projet ou chez le fournisseur.

Demandez à votre administrateur système

Peut-être devez-vous effectivement poser une question à votre administrateur système. Mais cette fois, pas : « Comment fonctionne ce système ? »
Demandez-lui : « Que se passera-t-il chez nous si, à partir de demain, vous n’êtes plus joignable pendant trois mois ? »
Un bon administrateur système pourra probablement vous citer spontanément quelques points. Écoutez attentivement. Car cette conversation pourrait bien être le point de départ du travail de documentation le plus important de votre entreprise.
Et si, lors de l’une des prochaines questions, quelqu’un répond à nouveau : « Il faut demander à notre administrateur système », votre question suivante doit être : « Et où cela est-il documenté au cas où nous ne pourrions plus le lui demander ? »

Pour aller plus loin

Si vous souhaitez approfondir les thèmes de la continuité d’activité, de la préparation aux situations d’urgence et de la sécurisation des processus critiques, vous trouverez des informations complémentaires dans les sources suivantes :
  • BSI – BSI-Standard 200-4 : Business Continuity Management
    Norme pratique pour la mise en place et l’exploitation d’un système de management de la continuité d’activité.
    www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/BSI_Standards/standard_200_4.pdflien externe
    Commentaire : aucune version française ni anglaise du BSI-Standard 200-4 actuel n’a été trouvée ; le lien renvoie donc à l’original allemand.
  • ISO – ISO 22301:2019 : Systèmes de management de la continuité d’activité
    Norme internationale pour la mise en place, l’exploitation et l’amélioration continue d’un système de management de la continuité d’activité.
    www.iso.org/fr/standard/75106.htmllien externe
  • Office fédéral de la cybersécurité OFCS – Plan d’urgence pour les PME suisses
    Guide pratique suisse pour préparer les petites et moyennes entreprises aux urgences cyber et informatiques.
    www.bacs.admin.ch/fr/26-notfallkonzept-frlien externe

Cet article est une traduction de l’original allemand et a été réalisée à l’aide de l’intelligence artificielle. Il a fait l'objet d'une relecture attentive.

L’original allemand: "Da müssen Sie unseren Administrator fragen"