Risques opérationnels : bus-factor, processus sans propriétaire

Un incident opérationnel majeur se produit rarement sans signaux d'alerte préalables. Le plus souvent, il résulte d'une combinaison de failles structurelles qui ont été ignorées ou simplement jamais formalisées : un processus critique que seule une personne maîtrise, une procédure dont personne n'assume la responsabilité, une documentation qui n'a pas été révisée depuis deux ans. Pour les DSI et les RSSI de PME et ETI, identifier ces risques avant qu'ils se transforment en incident est un enjeu de continuité opérationnelle — et, de plus en plus, de conformité réglementaire.

Pourquoi les processus métier sont une surface de risque sous-estimée

La gestion des risques opérationnels se concentre souvent sur l'infrastructure technique : disponibilité des serveurs, continuité des accès, résistance aux cyberattaques. C'est légitime. Mais les processus métier eux-mêmes constituent une surface de risque que les organisations évaluent rarement avec la même rigueur.

Un processus est risqué non seulement quand il est mal conçu, mais aussi quand :

• il repose sur la connaissance tacite d'un seul individu,
• aucun responsable identifié ne peut décider de son évolution ou de sa suspension,
• les procédures associées n'ont pas été relues depuis suffisamment longtemps pour refléter la réalité opérationnelle.

Ces trois situations correspondent à des signaux de risque distincts, que nous allons examiner un par un. Ils sont au cœur de la détection automatique de risques proposée par UrbaHive dans son module de cartographie des processus métier.

Le bus-factor ou single point of knowledge : quand tout repose sur une seule personne

Définition

Le terme « bus-factor » (parfois appelé « truck factor ») désigne le nombre minimal de personnes dont la disparition soudaine — accident, démission, arrêt maladie prolongé — paralyserait un processus ou un projet. Un bus-factor de 1 signifie qu'une seule personne détient toute la connaissance nécessaire à l'exécution d'un processus. C'est un risque critique.

Dans le monde des équipes techniques, le concept est bien connu. En revanche, dans les processus métier des PME et ETI, il est rarement mesuré. Or les situations à bus-factor 1 sont fréquentes : le seul comptable qui sait générer un état de rapprochement bancaire dans l'ERP, le responsable de paie qui connaît par cœur toutes les règles de calcul d'astreinte, l'assistante de direction qui gère seule les relations avec trois fournisseurs stratégiques.

Conséquences concrètes

Quand la personne concernée est absente, l'organisation a le choix entre trois options, toutes mauvaises : attendre son retour, confier la tâche à quelqu'un qui ne maîtrise pas le processus et risquer des erreurs, ou solliciter en urgence une prestation externe coûteuse.

Du point de vue de la conformité NIS2, un processus à bus-factor 1 qui supporte un service essentiel est une non-conformité directe aux exigences de continuité opérationnelle de la directive.

Comment le détecter

Dans UrbaHive, chaque étape de processus est associée à un acteur identifié. Le système détecte automatiquement les étapes pour lesquelles un seul acteur est référencé sur l'ensemble du processus et aucun suppléant n'est indiqué. Ces étapes sont signalées comme risques de type « single point of knowledge » dans le tableau de bord de pilotage.

Les processus sans propriétaire : un risque de gouvernance invisible

Qu'est-ce qu'un processus orphelin ?

Un processus sans propriétaire est un processus dont aucun individu ou aucune fonction n'assume formellement la responsabilité : ni la maintenance de sa documentation, ni la décision de le modifier, ni la validation de son bon déroulement au quotidien.

Les processus orphelins apparaissent dans trois situations typiques :

1. Réorganisation : le propriétaire d'un processus change de poste ou quitte l'organisation, et aucun successeur n'est désigné.
2. Création informelle : le processus a été mis en place de façon pragmatique, sans qu'aucune gouvernance formelle ne soit définie autour de lui.
3. Périmètre flou : le processus est à la frontière de deux départements, chacun estimant que l'autre en est responsable.

Pourquoi c'est dangereux

Un processus sans propriétaire ne fait l'objet d'aucune revue, d'aucune amélioration continue et d'aucune alerte en cas de dysfonctionnement. Il dérive progressivement, sans que personne ne s'en aperçoive, jusqu'à ce qu'un incident révèle l'écart entre la procédure théorique et la pratique réelle.

Pour les RSSI, les processus sans propriétaire sont particulièrement préoccupants lorsqu'ils touchent à la gestion des accès, à la gestion des incidents de sécurité ou au traitement des données personnelles. L'absence de responsable rend toute investigation post-incident difficile et toute démonstration de conformité — notamment au titre du RGPD ou de NIS2 — quasiment impossible. Voir à ce sujet notre article sur la cartographie SI et la cybersécurité.

Détection dans UrbaHive

UrbaHive signale automatiquement comme risque tout processus pour lequel aucun propriétaire n'est renseigné dans la cartographie. Cette détection s'effectue au niveau du processus et au niveau de chaque étape, ce qui permet d'identifier les situations où un processus a bien un propriétaire global mais des étapes orphelines.

L'obsolescence documentaire : quand vos procédures ne reflètent plus la réalité

Un problème systémique dans les PME

La documentation des processus vieillit mal. Les organisations documentent leurs processus lors de projets de certification (ISO 9001, ISO 27001), de migrations ERP ou de préparations d'audit — puis ne les mettent plus à jour. Douze mois plus tard, les procédures écrites ne correspondent plus aux pratiques réelles, les applications référencées ont changé, et les acteurs impliqués ont évolué.

Une étude du Gartner estime que 60 à 80 % de la documentation de processus perd sa valeur opérationnelle dans les 18 mois suivant sa rédaction si elle n'est pas activement maintenue. Dans les PME et ETI qui n'ont pas de processus de gouvernance documentaire formalisé, cette proportion est probablement plus élevée encore.

Le risque réglementaire associé

Pour les organisations soumises à NIS2 ou à des référentiels sectoriels (santé, finance, défense), une documentation de processus obsolète représente un risque de conformité direct. Les auditeurs s'appuient sur la documentation pour évaluer la maîtrise des risques ; une documentation qui contredit les pratiques observées est un signal d'alarme majeur.

Dans le contexte de l'urbanisation SI, des processus dont la documentation est à jour sont aussi une condition préalable à toute analyse d'impact lors d'une migration applicative ou d'une refonte du SI.

Détection dans UrbaHive

UrbaHive signale automatiquement les processus qui n'ont pas fait l'objet d'une revue depuis 12 mois. Ce seuil est paramétrable selon les exigences réglementaires de l'organisation. La détection s'appuie sur la date de dernière modification du processus dans la plateforme, ce qui suppose que les équipes maintiennent leur cartographie à jour — une bonne pratique en soi.

Comment traiter ces risques : de la détection au plan d'action

Identifier un risque est une première étape, mais elle ne suffit pas. Voici une approche structurée pour chaque type de signal :

Bus-factor 1

1. Identifier les processus concernés et estimer leur criticité (volume, impact en cas d'interruption).
2. Mettre en place un binôme : désigner un suppléant formé et documenter le processus de façon suffisamment détaillée pour permettre une reprise en main rapide.
3. Planifier des rotations régulières pour maintenir la compétence du suppléant.

Processus sans propriétaire

1. Attribuer un propriétaire intérimaire dans les 48 heures suivant la détection.
2. Organiser une revue rapide du processus pour valider qu'il reflète la réalité et mettre à jour les acteurs impliqués.
3. Inscrire la revue dans le calendrier de gouvernance annuel.

Documentation obsolète

1. Planifier une revue avec les parties prenantes du processus.
2. Mettre à jour les étapes, les acteurs et les applications liées dans la cartographie.
3. Définir une fréquence de revue adaptée à la criticité du processus (annuelle, semestrielle, trimestrielle).

Le score d'optimisation (/100) calculé par UrbaHive intègre ces dimensions de risque pour prioriser les actions. Le dashboard de pilotage permet de suivre l'évolution des risques dans le temps et de mesurer l'efficacité des actions correctives.

Conclusion

Le bus-factor, les processus sans propriétaire et l'obsolescence documentaire sont trois signaux de risque opérationnel qui n'apparaissent dans aucun monitoring technique, mais qui peuvent avoir des conséquences aussi sévères qu'une panne serveur ou une intrusion. Pour les DSI et RSSI de PME et ETI, les identifier et les traiter est une condition de résilience opérationnelle et, de plus en plus, une exigence réglementaire.

Commencez gratuitement sur UrbaHive et détectez automatiquement les risques cachés dans vos processus métier grâce à l'éditeur de processus.

FAQ

Q : Le bus-factor s'applique-t-il uniquement aux processus techniques ou informatiques ?

R : Non. Le concept s'applique à tout processus dans lequel la connaissance opérationnelle est concentrée sur un seul individu, qu'il s'agisse de processus financiers, RH, commerciaux ou logistiques. Les processus métier des PME sont souvent plus exposés que les processus techniques, précisément parce qu'ils sont moins documentés.

Q : Comment convaincre le management de traiter ces risques, souvent perçus comme non urgents ?

R : L'argument le plus efficace est celui de la continuité opérationnelle : demandez combien coûte une journée d'interruption du processus concerné. Si la réponse dépasse le coût de la mise en place d'une documentation et d'un suppléant, l'arbitrage est simple. En contexte NIS2 ou ISO 27001, la dimension réglementaire ajoute un argument supplémentaire.

Q : Quelle est la fréquence de revue recommandée pour les processus critiques ?

R : Pour les processus supportant des services essentiels ou réglementés, une revue semestrielle est recommandée. Pour les processus courants, une revue annuelle est un minimum. UrbaHive signale automatiquement les processus qui dépassent le seuil de 12 mois sans revue.

Q : Un processus peut-il avoir plusieurs propriétaires ?

R : Oui, mais cela peut diluer la responsabilité. Une bonne pratique est de distinguer le propriétaire métier (qui décide des règles et des évolutions) du responsable opérationnel (qui supervise l'exécution au quotidien). L'essentiel est qu'au moins une personne soit identifiée comme décisionnaire.

Q : UrbaHive peut-il détecter les risques liés à des applications critiques sans suppléant technique ?

R : Oui. UrbaHive lie les processus aux applications qui les supportent. Si une application est référencée comme seul support d'une étape critique et qu'aucune redondance n'est documentée dans la cartographie applicative, ce risque peut être remonté dans le tableau de bord.