« Une dépendance n'avait pas été anticipée. »
« On ne peut pas démarrer tant que ça n'est pas prêt. »
« Personne n'avait vu que ça bloquait tout. »
Ces constats arrivent souvent au moment du planning ou en pleine exécution. Pourtant, dans la majorité des cas, la dépendance n'est pas apparue en cours de route. Elle existait déjà. Elle était simplement invisible, faute d'éléments suffisamment nommés pour la formuler.
Qu'est-ce qu'une dépendance invisible ?
Une dépendance, c'est une relation d'ordre entre parties du travail : X ne peut pas démarrer (ou se terminer) tant que Y n'a pas produit un résultat attendu. Elle est « invisible » quand personne ne peut encore dire clairement ce qui dépend de quoi, parce que les unités de travail restent trop floues.
À distinguer de la charge oubliée (du travail jamais listé) et de la dérive de périmètre (ajouts et frontières négociables). Ici, le sujet est l'ordre et les liens entre éléments : tant qu'ils ne sont pas identifiés, les relations restent impossibles à poser.
On ne peut pas relier ce qui n'est pas nommé
Une dépendance suppose au minimum deux éléments clairement identifiés. Or, dans beaucoup de projets, le contenu est encore exprimé en blocs macro : « déploiement », « intégration », « livraison », « recette ». Les livrables ne sont pas toujours nommés comme tels. Des briques nécessaires restent engluées dans des ensembles vagues.
Dans ce contexte, les dépendances ne sont pas « oubliées ». Elles sont impossibles à formuler. On ne peut pas dire qu'un livrable dépend d'un autre si aucun des deux n'a été explicitement défini.
Pourquoi le planning les révèle trop tard
C'est souvent au moment de construire le planning que les liens commencent à émerger. Les équipes réalisent que des tâches supposées indépendantes ne le sont pas, qu'une validation est obligatoire avant d'avancer, ou que des livrables doivent sortir dans un ordre précis.
Le problème n'est pas forcément que le planning est mal fait. C'est qu'il devient le premier outil à forcer le détail du travail, alors que le projet est déjà engagé. Trop tard pour structurer sereinement les dépendances sur une base claire.
Signaux d'alerte : les liens sont-ils encore invisibles ?
- Les « tâches » du cadrage sont encore des intitulés macro (« déploiement », « intégration », « mise en prod »).
- Personne ne peut répondre : « X ne peut pas démarrer sans Y » avec des X et Y concrets.
- Le Gantt (ou le premier planning) est le premier endroit où les relations apparaissent.
- Il n'existe pas encore de liste partagée de livrables avant les dates.
- Les blocages surprennent alors que « tout le monde savait » implicitement.
Exemples : quand la relation ne peut pas être posée
Tant que le travail reste en blocs larges, les questions de dépendance restent floues :
- « Module livraison » : trop large pour dire ce qui doit être prêt avant la recette.
- « Intégration » : mélange droits, API, données de test, environnements, sans unités séparées.
- « Recette » : sans préciser jeux de données, comptes de test, ou livrable à valider, le prérequis reste implicite.
Dès que ces éléments sont nommés (livrable jeux de données, paramétrage SSO, environnement UAT, etc.), les liens deviennent discutables et visibles.
Mini-cas : trois blocs, puis les blocages
Avant. Cadrage en trois blocs : Conception, Développement, Recette. Délai annoncé. Pas de liste fine de livrables.
Au planning. « La recette bloque sans jeux de données. » « Le SSO doit être prêt avant l'UAT. » « L'import historique conditionne les tests métier. »
Résultat. Impression que le projet se complexifie. En réalité, les dépendances existaient déjà. Elles n'avaient pas pu être posées faute d'unités de travail nommées.
Le deuxième étage : les contraintes que seules les équipes connaissent
Les dépendances entre ressources et entre tâches figurent parmi les causes d'échec recensées par le PMI, à 26 % et 12 % des projets qui échouent. Source : PMI, Pulse of the Profession 2018, 4 455 praticiens, voir les référentiels du PMI.
Une fois les éléments nommés, une autre couche de dépendances apparaît, et celle-là ne se déduit d'aucun document. Ce sont les contraintes que détiennent les gens qui font le travail.
Un module a besoin d'une configuration particulière. Un test suppose un paramétrage fait la veille. Une intégration attend une stabilisation en amont. Sur un chantier, c'est un temps de séchage qu'on ne comprime pas. Dans un bureau d'études, une note de calcul qui exige des données client validées. Sur une intervention, une autorisation d'accès sans laquelle rien ne commence.
Ces contraintes ne remontent pas d'elles-mêmes. Le cadrage se fait souvent entre une direction et un chef de projet, alors que la connaissance est ailleurs : chez le développeur, le conducteur de travaux, l'ingénieur, le technicien. Personne ne les cache. On ne leur a simplement pas demandé au moment où la question se posait.
Un réseau de dépendances construit seul reste donc partiel, non parce qu'il est mal fait, mais parce qu'il ne peut pas contenir ce que son auteur ignore. C'est la raison pour laquelle la phase de structuration gagne à se faire à plusieurs, y compris avec ceux qui ne participent d'habitude qu'à l'exécution.
Le préalable, lui, reste plus simple : rendre le contenu assez explicite pour que les relations puissent exister sur le papier.
Que faire : nommer avant de planifier
Avant d'optimiser un calendrier ou d'enchaîner des barres, il faut clarifier ce qui doit être produit : livrables, puis unités de travail suffisamment précises. Une WBS ne décrit pas les dépendances. Elle crée les conditions pour qu'elles deviennent visibles.
Ensuite seulement, un réseau de type PERT permet de modéliser les enchaînements sur une base partagée. Sans cette étape, PERT et Gantt reposent sur des hypothèses fragiles.
Synthèse
Les dépendances ne sont pas invisibles parce qu'elles sont complexes. Elles sont invisibles parce que le travail n'a pas été découpé assez concrètement pour révéler les relations. Nommer les éléments avant de figer les dates, c'est éviter de découvrir les blocages au moment où les marges de manœuvre ont déjà disparu. Les rendre visibles suppose un support qui les porte réellement : c'est le rôle d'un diagramme de dépendances, là où une liste de tâches les efface.
