La tentation de l’externalisation
Quand un commanditaire de projet confie une tâche risquée à un prestataire ou à un chef de projet externe, il s’attend généralement à ce que le problème disparaisse avec la délégation. Le raisonnement paraît logique: si quelqu’un d’autre s’en occupe, la responsabilité suit. Cette croyance est pourtant l’une des sources les plus fréquentes de conflits contractuels, de glissements de périmètre et d’escalades tardives dans les projets.
La gestion des risques n’est pas un transfert ponctuel et définitif. Elle implique un suivi continu, des décisions régulières et une forme de vigilance que le contrat le plus détaillé ne peut pas couvrir intégralement. Or dans beaucoup d’organisations, la délégation d’une tâche risquée est traitée comme si elle transférait l’ensemble du problème, y compris les conséquences d’un éventuel échec. Cette confusion produit des situations où le commanditaire se désengage d’un risque qu’il croit avoir externalisé, tandis que le prestataire découvre progressivement qu’il porte une charge sans disposer des moyens de la gérer.
Responsabilité et imputabilité: deux notions distinctes
Le modèle RACI (Responsible, Accountable, Consulted, Informed) formalise une distinction souvent négligée dans la pratique. La responsabilité opérationnelle, le “R”, désigne la personne qui exécute le travail. L’accountability (imputabilité), le “A”, désigne celle qui rend des comptes sur le résultat final. Ces deux rôles peuvent être portés par des personnes différentes, mais le “A” ne se délègue pas: il reste attaché au commanditaire ou au sponsor du projet, quelle que soit la complexité du montage contractuel.
Quand un maître d’ouvrage transfère une tâche risquée à un prestataire, il délègue la responsabilité opérationnelle. L’imputabilité, elle, ne change pas de main. Si le projet échoue parce qu’un risque mal géré se matérialise, c’est le commanditaire qui devra répondre devant sa direction, pas le prestataire. Le contrat peut prévoir des pénalités financières, mais il ne prévoit pas la perte de crédibilité du sponsor auprès de son comité de direction ni l’impact sur les objectifs stratégiques de l’organisation.
Cette distinction n’est pas abstraite. Elle se manifeste chaque fois qu’un comité de pilotage demande des comptes après un incident: la question n’est jamais “qui exécutait la tâche?”, mais toujours “qui était censé s’assurer que ça fonctionne?”. Celui qui doit répondre est invariablement le porteur de l’accountability, pas l’exécutant opérationnel.
Pourquoi cette confusion persiste
Plusieurs mécanismes expliquent la persistance de ce malentendu. La pression hiérarchique pousse les managers à montrer qu’ils “gèrent” la situation, ce qui se traduit souvent par une délégation rapide vers un tiers perçu comme compétent. Le biais d’optimisme joue également: une fois le risque confié, on tend à sous-estimer la probabilité qu’il se concrétise, comme si la délégation elle-même réduisait l’incertitude.
Il y a aussi un facteur culturel non négligeable. Dans les organisations qui sanctionnent l’échec sans distinguer entre un risque assumé qui se matérialise et une véritable faute de gestion, les managers développent un réflexe d’évitement. Externaliser un risque permet de disposer d’un bouc émissaire si les choses tournent mal, ce qui constitue une stratégie rationnelle dans un environnement punitif, mais désastreuse pour le projet lui-même.
Enfin, la complexité croissante des montages contractuels contribue à l’illusion. Des clauses de transfert de risque, des garanties de performance et des SLA (Service Level Agreements, accords de niveau de service) détaillés donnent l’impression que tout est couvert. Mais ces dispositifs ne couvrent que les dimensions mesurables et contractualisables du risque, pas les conséquences stratégiques ni réputationnelles d’un échec. La distinction entre ce qui est contractualisé et ce qui reste chez le commanditaire est rarement explicitée au moment de la signature.
Le prestataire piégé
Du côté du prestataire qui reçoit cette délégation, la situation est rarement confortable. Il absorbe une responsabilité opérationnelle élargie sans nécessairement disposer de l’autorité, du budget ou des informations nécessaires pour l’exercer correctement. Le commanditaire, pensant avoir transféré le problème, réduit sa propre implication et son soutien au fil du temps, parfois dès les premières semaines.
Le résultat est prévisible: quand le risque se matérialise, le prestataire est mis en cause alors qu’il n’avait pas les moyens de l’éviter. Les renégociations contractuelles tardives, les avenants et les litiges sont souvent le symptôme direct de cette répartition initiale mal posée. Le prestataire aurait pu gérer le risque opérationnel s’il avait reçu les informations en temps voulu, un accès aux parties prenantes internes et des arbitrages rapides. Sans ces conditions, la délégation était viciée dès le départ, et le contrat ne fait qu’encadrer un échec programmé.
Ce que “gérer un risque” signifie vraiment
La norme ISO 31000:2018 définit le risque comme l’“effet de l’incertitude sur les objectifs”. Gérer un risque implique un processus structuré: identifier la menace, évaluer sa probabilité et son impact, choisir une stratégie de réponse, puis maintenir un suivi actif tout au long du projet.
Les stratégies de réponse classiques sont l’évitement, la mitigation, le transfert et l’acceptation. Le transfert contractuel, par exemple via une assurance ou une clause de pénalité, est une réponse parfaitement valide. Mais transférer un risque ne signifie pas cesser de le surveiller. Le commanditaire qui souscrit une assurance pour couvrir un risque de retard ne cesse pas pour autant de suivre le calendrier du projet, et le sinistre éventuel ne compense pas la perte d’un avantage concurrentiel lié au timing. Le transfert est un outil de répartition, pas un outil d’élimination.
Le rôle irréductible de la direction
Dans les projets à forte incertitude, la direction doit accepter qu’une part de risque résiduel lui revient, quels que soient les dispositifs de délégation et de transfert en place. Le PMBOK (Project Management Body of Knowledge, référentiel du PMI) insiste sur le principe de stewardship: le sponsor de projet est le gardien de l’investissement et ne peut pas se défausser de cette fonction, même lorsqu’il mandate un tiers pour l’exécution.
Concrètement, cela signifie que la direction doit rester informée des risques majeurs, participer aux décisions de réponse pour ceux qui dépassent l’autorité du chef de projet, et accepter que certains risques résiduels sont le prix à payer pour les bénéfices attendus du projet. Une organisation qui comprend cette distinction entre risque accepté et faute de gestion crée un environnement où les chefs de projet osent identifier les vrais risques plutôt que de les dissimuler ou de les transférer précipitamment. Cette transparence est elle-même un facteur de réduction du risque global, parce qu’elle permet une allocation plus juste des ressources de surveillance et d’intervention.
Poser la bonne question dès le départ
Avant de déléguer un risque, le commanditaire devrait se poser une question simple: “Si ce risque se matérialise malgré la délégation, qui devra expliquer l’échec?” Si la réponse est “moi”, alors l’imputabilité n’a pas été transférée et le niveau d’implication doit rester proportionnel à l’enjeu. Le contrat avec le prestataire définit les obligations opérationnelles, pas les conséquences stratégiques d’un échec. Reconnaître cette limite dès la phase de planification permet de calibrer correctement le suivi, le soutien au prestataire et les mécanismes d’escalade, au lieu de découvrir trop tard que personne ne tenait réellement le risque en main.