Risque lié aux personnes clés : lorsque la connaissance du système repose sur une seule personne

Le risque lié aux personnes clés dans le domaine informatique se développe insidieusement. Une panne du système peut généralement être réparée, mais la situation est bien plus grave lorsqu’une seule et unique personne sait comment le système fonctionne. Ce n’est que lorsque cette personne tombe malade, démissionne ou est tout simplement injoignable parce qu’elle est en vacances que le problème devient visible, et c’est alors qu’un secteur dont personne n’aurait auparavant soupçonné la vulnérabilité se retrouve paralysé.

Comment naît un risque lié aux personnes clés dans le secteur informatique

Le « facteur bus » est un indicateur simple mais efficace. Il indique le nombre de personnes qui devraient être absentes pour qu’un service de l’entreprise soit paralysé. Plus ce chiffre est faible, plus l’organisation est vulnérable face à la maladie, à un départ ou simplement à des congés prolongés.

Les monopoles de connaissances vont bien au-delà des données d'accès. Ils englobent les configurations, les dépendances système et les solutions de contournement non documentées, mises en place au fil des années, qu'une seule personne ne peut même plus expliquer entièrement à un moment donné, comme SAC explique (SAC, 2026). Ceux qui pensent qu’un gestionnaire de mots de passe suffit à résoudre le problème sous-estiment la quantité d’informations qui se trouve en réalité uniquement dans l’esprit d’une personne.

La pénurie de main-d'œuvre qualifiée aggrave encore cette situation. Selon Bitkom L'Allemagne manque d'environ 109 000 spécialistes en informatique, ce qui explique que le processus de recrutement soit particulièrement long (Bitkom, 2025). Lorsqu'une entreprise perd un collaborateur clé, il lui est rarement possible de recruter à court terme une personne disposant de compétences comparables, même si le budget nécessaire est disponible.

Où le risque est-il le plus élevé dans la pratique ?

Dans le domaine informatique, le risque lié aux personnes clés se présente le plus souvent sous trois formes. La première est celle d’une personne qui a mis en place seule, il y a des années, un système central et qui, depuis lors, est la seule à en connaître tous les recoins. La deuxième concerne le petit service informatique où, pour des raisons de coûts, aucune véritable relève n’a jamais été prévue. La troisième concerne un système acheté à l’extérieur dont la maîtrise repose entièrement sur un seul interlocuteur au sein de l’entreprise, alors que le prestataire d’origine a changé depuis longtemps.

Dans les projets que nous prenons en charge, on observe un schéma récurrent. Ce sont justement les collaborateurs les plus fiables qui sont le moins souvent remplacés, car ils résolvent généralement les problèmes eux-mêmes avant même que quiconque ne se rende compte qu’il y en avait un. C’est précisément cette fiabilité qui masque le risque, jusqu’à ce que la personne soit effectivement absente et que personne ne sache par où commencer.

D’un point de vue économique, le risque est rarement pris en compte dans les calculs. Une panne au niveau de la production ou de la logistique est rapidement chiffrée en euros par heure, tandis qu’un arrêt de plusieurs jours d’un système interne, dont personne d’autre n’est responsable, n’apparaît sur aucune liste de risques tant qu’il ne s’est pas réellement produit. Cela apparaît particulièrement clairement au cours des premières semaines suivant une acquisition, lorsqu’une nouvelle équipe doit soudainement s’appuyer sur des systèmes déjà bien établis. Cet article explique comment organiser cette phase. Intégration informatique post-fusion : les 100 premiers jours.

Quelles mesures permettent d'augmenter le facteur bus ?

Une gestion rigoureuse des accès est la mesure la plus simple à mettre en place, mais aussi la plus souvent négligée. Les accès doivent être attribués à des rôles plutôt qu'à des personnes, afin qu'un départ ne rende aucun système inaccessible et que personne n'ait à deviner a posteriori quel mot de passe est encore valable et pour quel système.

La documentation opérationnelle est le levier le plus exigeant, mais aussi le plus efficace. Elle n'a pas pour but d'expliquer chaque ligne de code, mais de consigner l'architecture, les principales dépendances et les solutions de contournement connues dont, autrement, une seule personne se souviendrait.

Le travail en binôme permet de partager les connaissances au fur et à mesure, sans avoir besoin de prévoir un moment spécifique pour la documentation. Deux personnes qui travaillent ensemble sur un système développent automatiquement une seconde compréhension de celui-ci, même si aucune des deux n'avait prévu ce transfert de connaissances.

Un manuel d'urgence indique la marche à suivre dans les premières heures d'une panne, lorsque la personne qui serait normalement en mesure de répondre à cette question est justement absente. Un deuxième avis externe, à l'instar de ce qui se passe dans le cas d'une due diligence technique avant une reprise, vérifie de manière indépendante si ces mesures sont réellement efficaces ou si le monopole du savoir n'a été aboli que sur le papier.

Foire aux questions

Comment déterminer son propre « facteur bus » ?

Un exercice simple consiste à se demander, pour chaque système important, qui d’autre que la personne actuellement en charge pourrait le faire fonctionner sans avoir à passer des jours à faire des recherches. Si la réponse se résume à un seul nom, le facteur bus est égal à un. Cet exercice peut être répété individuellement pour chaque système critique ; les résultats varient souvent considérablement. Ceux qui effectuent cet exercice avec objectivité, sans enjoliver la situation, trouvent généralement plus d’un système présentant ce schéma.

Comment tenir des registres sans paralyser l'activité ?

De petits créneaux horaires fixes sont plus efficaces qu’un vaste projet ponctuel de documentation qui, parallèlement aux activités quotidiennes, est rarement mené à bien. Une heure par semaine, consacrée systématiquement aux systèmes les plus critiques, apporte davantage sur plusieurs mois qu’une initiative ambitieuse qui s’essouffle au bout de deux semaines. Il est également judicieux de commencer par le système dont la panne serait la plus coûteuse, et non par celui qui est le plus facile à documenter.

Que faire si la personne démissionne ?

La période de préavis devient la ressource la plus importante ; elle doit être réservée dès le début au transfert de connaissances, et non pas uniquement à la passation des tâches en cours. Des réunions régulières avec le reste de l'équipe, un résumé écrit des principaux enjeux et un test au cours duquel une autre personne effectue une tâche typique sans aide permettent de vérifier si le transfert a effectivement fonctionné. Si le délai est court, il est préférable de limiter le transfert aux deux ou trois systèmes dont la défaillance serait la plus coûteuse, plutôt que de tout traiter de manière uniforme.

Un risque lié aux personnes clés dans le domaine informatique concerne rarement uniquement le service informatique ; il s'étend jusqu'à la production, la logistique et le service client. Il est rarement possible d'évaluer de manière fiable en interne qui détient le monopole des connaissances, car on ne perçoit souvent pas ses propres lacunes. torck met à disposition ses propres équipes de développement basées à Maxhütte-Haidhof, Vienne et Rabat, qui développent et documentent activement les connaissances au fur et à mesure de l'activité, au lieu de se contenter de remettre une simple liste de contrôle. Le partenaire contractuel est la société allemande torck GmbH. Si vous souhaitez faire évaluer votre propre « facteur bus », vous pouvez le faire dans un Premier entretien en discuter.

Prendre rendez-vous