« 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.
Ce n'est pas la même chose qu'une charge oubliée (travail jamais listé), ni qu'une 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.
Ce n'est pas (encore) le sujet des dépendances « réelles »
Une fois les éléments nommés, reste à identifier les contraintes techniques et métier que seules les équipes détiennent : séquences incompressibles, prérequis d'environnement, interdépendances fines. C'est l'angle de l'article sur les dépendances réelles d'un projet. Ici, le préalable est 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.
