Combien de personnes clés peuvent se faire renverser par un bus avant que le projet ne s'arrête ?

Il arrive qu’un projet dispose de toutes les compétences nécessaires et qu’il dépende pourtant de quelques personnes pour continuer à avancer.

Sur le papier, tout semble en place; rôles définis, responsabilités attribuées, compétences identifiées et analyses documentées. Et pourtant, lorsque le projet rencontre un imprévu, change de phase ou perd l’un de ses protagonistes, il devient parfois difficile de retrouver l'historique des décisions, de reconstituer le détail des activités réalisées ou de rétablir des relations indispensables à sa poursuite.

Cette dépendance peut venir du savoir détenu par une personne, de sa capacité à l'utiliser dans le bon contexte ou de son rôle d’interface entre différentes compétences. Une personne devient critique lorsque son absence empêche une activité clé de fonctionner.

Elle constitue alors un point de dépendance.

Le facteur Bus désigne le nombre minimal de personnes dont l’indisponibilité pourrait interrompre, ralentir fortement ou désorganiser un projet.

Le facteur Bus ne concerne pas seulement les experts

On pense spontanément à l’expert qui maîtrise une technologie spécifique. Pourtant, dans les projets complexes, la dépendance la plus forte n’est pas nécessairement liée à l'expertise la plus pointue.

La personne la plus difficile à remplacer est souvent celle qui,

• connaît l’histoire du projet et le motif des décisions prises,
• sait où retrouver les informations non répertoriées,
• connaît les bons interlocuteurs et sait quand leur transmettre une information,
• facilite les échanges entre plusieurs domaines d’expertise et bénéficie de la confiance des partenaires,
• sait débloquer une situation administrative ou institutionnelle.

Cette personne n’est pas forcément le chef de projet. Il peut s’agir d’un spécialiste technique, d’un professionnel métier, d’un partenaire externe ou d’un représentant institutionnel dont le rôle n’apparaît pas clairement dans l’organigramme. Elle joue souvent un rôle discret mais déterminant pour traduire les besoins d’un domaine à un autre ou maintenir le lien avec un partenaire clé.

Le facteur Bus peut donc se situer n’importe où dans l’écosystème du projet.

Le cas de R3PO

Il y a quelque temps, nous avons analysé les personnes critiques d’un projet que nous avons nommé R3PO, cette évaluation a mis en évidence cette fragilité, invisible dans les outils classiques de gestion de projet.

R3PO est un robot de rééducation physique destiné aux patients alités. Le projet mobilisait une trentaine de compétences interdépendantes, réparties entre près de 35 métiers, du soudeur au directeur de centre hospitalier universitaire, et articulait ingénierie, physiothérapie, recherche, partenaires techniques et environnement clinique.

Le prototype fonctionnait, les lettres d’intention étaient signées et les compétences technico-médicales étaient réunies.

Puis le contexte a changé. Des membres de l’équipe ont évolué vers d'autres fonctions et les échanges interdisciplinaires se sont raréfiés. Chacun est progressivement revenu à ses priorités et à son propre référentiel. La dynamique d’innovation s’est affaiblie et les expertises ont recommencé à fonctionner en silos.

Le projet n’avait pas perdu ses compétences : il avait perdu une partie de sa capacité à les rendre opérationnelles dans le contexte du projet.

Ce que les outils de projet ne montrent pas

Un organigramme, une matrice RACI ou un tableau de compétences décrivent ce qui est formellement défini. Ils ne montrent pas ce qui permet réellement de faire fonctionner cet ensemble : les connaissances tacites, l’historique des arbitrages, le réseau relationnel et la capacité à mobiliser les bons acteurs.

Le risque ne vient donc pas du manque de compétences disponibles, mais de l’incapacité à les rendre opérationnelles dans le contexte du projet.

Lorsque le backup est à l’extérieur du projet

La situation se complique lorsqu’une compétence indispensable est détenue par une personne extérieure au projet.

Même si cette personne est identifiée comme le backup naturel d'un collaborateur critique, disposer de son savoir-faire théorique ne garantit pas sa mobilisation. Il faut qu'elle soit disponible, qu'elle accepte d'intervenir et qu'elle comprenne le contexte informel (habitudes de travail, historique, enjeux d'interface) pour reprendre l'activité.

Dans le cas de R3PO, la poursuite du projet dépendait de la décision d’un tiers externe d'engager les essais cliniques. Son accord débloquait la situation ; son refus ou son indisponibilité mettait le projet en attente pendant plusieurs mois.

Le facteur Bus concerne autant la personne qui détient une compétence clé que celle dont la décision conditionne l'accès à cette compétence.

Le backup humain ne remplace pas seulement une connaissance

À l'heure de l'intelligence artificielle, recouper des sources hétérogènes et en tirer une synthèse cohérente est devenu quasi instantané — et c'est précisément ce qui rend le facteur Bus plus difficile à voir. Un projet peut se croire résilient simplement parce qu'il retrouve vite ce qu'il cherche, avec une IA capable de reconstruire en quelques secondes le fil d'une décision passée, à partir de comptes-rendus, d'échanges et de notes éparses, ce qui donne l'impression de maîtrise. Une synthèse rapide et cohérente ne peut traiter ce qui n'a jamais été consigné par les protagonistes du projet. Le système ne sait pas ce qu'il ignore : il fournit une fausse idée de la réalité du terrain.

Le risque ne réside donc plus seulement dans l'absence d'outils, mais dans la confiance excessive accordée à un système documentaire. Retrouver une information n'est pas relancer un interlocuteur, décoder une hésitation ou obtenir un arbitrage. Aucun outil, aussi performant soit-il, ne remplace cette capacité d'action.

Transmettre une connaissance ne suffit donc pas.

Il faut pouvoir exercer une réelle capacité d’action sur le terrain. C’est pourquoi le backup le plus fiable est le plus souvent une personne ayant déjà travaillé aux côtés de l’acteur critique, en conditions réelles.

La transmission se fait alors dans l'action, en intégrant non seulement ce qu'il faut faire, mais aussi pourquoi, avec qui et selon quelles modalités.

Quand l’incertitude devient un résultat

Lorsqu’une activité dépend d’un individu, la question n’est pas immédiatement de savoir comment le remplacer, mais d’évaluer si une capacité équivalente existe dans l’organisation.

Une ressource interne peur offrir une meilleure maîtrise des processus et contraintes de l'entreprise ; une ressource externe apporte des réseaux ou des expertises spécifiques. Le choix doit reposer sur la capacité réelle de chaque option à réduire le risque.

Il convient de se demander :

• cette compétence existe-t-elle déjà dans l’organisation et au sein de quel service ?
• la personne est-elle disponible et dispose-t-elle de la légitimité nécessaire pour intervenir rapidement ?
• connaît-elle suffisamment l’historique et les contraintes pour reprendre l’activité dans le délai requis ?

Lorsque les options reposent sur des hypothèses non vérifiées, poursuivre l’analyse des risques ne fait qu’attribuer une fausse précision à des incertitudes. Une analyse rigoureuse doit savoir suspendre la décision lorsque les hypothèses déterminantes n’ont pas encore été vérifiées.

Pour R3PO, l'analyse a permis de cibler le véritable point critique, la négociation avec le tiers externe, et d'isoler les scénarios à valider au préalable.

Sécuriser le projet avant qu’il ne ralentisse

Nous planifions régulièrement les délais, mais évaluons-nous réellement la résilience du projet ? Une démarche d'évaluation peut démarrer par ces questions :

• Quelle activité pourrait bloquer et de quelles connaissances dépend-elle ?
• Qui détient ces connaissances et sont-elles réellement partagées ?
• Qui connaît le contexte d'utilisation et sait mobiliser les interlocuteurs clés ?
• Une autre personne peut-elle reprendre l’activité dans le délai requis, et cette capacité a-t-elle été vérifiée ?

L’expérience R3PO montre que la vulnérabilité réside dans la dépendance du projet à ce qu'une personne sait, relie et mobilise. Cette fragilité ne se révèle souvent que lorsque le projet commence à ralentir.

Plutôt que de demander : "Qui pourrait partir demain ? ",  il est plus constructif de cibler. "Quelles connaissances et savoir-faire indispensables dépendent aujourd’hui d’un seul individu ?" , puis de tester ce qui se passerait réellement en cas d'indisponibilité.

En conclusion : la résilience se vérifie dans l’action

Un projet résilient n’est pas un projet où chacun sait tout, mais une organisation qui conserve sa capacité d’action face aux imprévus.

• La documentation est nécessaire mais insuffisante.
• Un backup n’est opérationnel que s'il a déjà éprouvé la reprise d'activité, la recherche d'informations et la prise de décision.
• Cette résilience doit être testée en conditions réelles : binômage, revues croisées ou simulations de perte de ressources.

La question finale n’est pas seulement :

"Combien de personnes pourraient être absentes avant que le projet ne s’arrête ? "

Elle est surtout :

"Quelles capacité critique disparaît avec elles, et avons-nous réellement vérifié que le projet peut continuer sans ?"