En gestion de projet, une dépendance désigne une relation entre deux éléments de travail dans laquelle l’un ne peut progresser sans que l’autre ait atteint un certain état. La notion s’applique aussi bien aux tâches d’un planning (la fondation avant les murs) qu’aux relations entre équipes (l’équipe A attend un composant de l’équipe B) ou aux liens avec l’extérieur (un contrat fournisseur, une autorisation réglementaire). Cette universalité explique pourquoi les dépendances constituent, dans la majorité des projets, la première cause de retard, devant les erreurs d’estimation et les changements de périmètre: une tâche prête à démarrer reste bloquée parce qu’un livrable amont n’a pas été produit, qu’une validation externe se fait attendre ou qu’un système technique dont personne n’avait formalisé le besoin n’est pas disponible.
Pourquoi les dépendances échappent au radar
La plupart des projets identifient leurs dépendances techniques de manière naturelle, parce qu’elles découlent de la logique du travail: on ne peut pas tester ce qui n’a pas été construit. En revanche, les dépendances organisationnelles et les dépendances externes sont souvent implicites, connues de quelques personnes sans être documentées ni communiquées.
Les outils de planification classiques, comme le diagramme de Gantt, modélisent les dépendances entre tâches mais pas celles entre équipes ou organisations. Les réunions de projet se concentrent sur l’avancement plutôt que sur les conditions de réalisation. Les membres de l’équipe, pris dans l’exécution quotidienne, n’ont pas toujours le réflexe de signaler une dépendance tant qu’elle ne pose pas encore de problème, c’est-à-dire tant qu’il est encore temps de la traiter. Le backlog (la liste ordonnée des éléments de travail à réaliser) lui-même recense rarement les liens de dépendance entre ses items de manière explicite.
Le résultat est un biais systématique: les projets sous-estiment leurs dépendances au moment de la planification et les découvrent au moment de l’exécution, lorsque les options de traitement sont plus limitées et plus coûteuses.
Trois catégories, trois niveaux de risque
Toutes les dépendances n’ont pas le même impact ni la même difficulté de gestion. La Scrum Alliance propose une classification en trois niveaux qui s’applique au-delà du contexte agile.
Les dépendances intra-équipe lient des tâches ou des livrables au sein d’une même équipe. Elles sont les plus simples à gérer parce que l’information circule naturellement et que le chef de projet dispose d’un levier direct pour réordonner le travail ou réaffecter les ressources. Un bon découpage du travail, où chaque lot est aussi indépendant que possible, réduit considérablement ce type de dépendances.
Les dépendances inter-équipes apparaissent dès qu’un projet mobilise plusieurs équipes sur un même produit ou programme. L’équipe qui développe l’interface utilisateur dépend de celle qui construit l’API, la rénovation du bâtiment A dépend du déménagement temporaire géré par l’équipe logistique. Ces dépendances requièrent des mécanismes de coordination explicites: points de synchronisation réguliers, ambassadeurs désignés entre équipes ou réunions de type Scrum of Scrums (réunion de synchronisation inter-équipes) dans un contexte agile. Sans ces mécanismes, chaque équipe optimise son propre planning sans visibilité sur les contraintes qu’elle impose aux autres.
Les dépendances externes, les plus risquées des trois catégories, lient le projet à des acteurs sur lesquels le chef de projet n’a qu’une influence limitée: fournisseurs, clients, organismes de régulation, autres départements de l’entreprise fonctionnant selon leur propre calendrier. Une recommandation claire s’impose: ne jamais démarrer une phase de travail avec une dépendance externe non sécurisée. Sécuriser signifie obtenir un engagement formel (date, livrable, niveau de service) et prévoir un plan B si cet engagement n’est pas tenu.
De l’identification au traitement: le cadre Éliminer, Atténuer, Gérer
Une fois les dépendances identifiées et classées par catégorie, la question centrale devient celle de leur traitement. Trois stratégies sont possibles, par ordre de préférence.
La première consiste à éliminer la dépendance en restructurant le travail. Si une équipe dépend systématiquement d’un spécialiste externe pour valider ses livrables, former un membre de l’équipe à cette compétence supprime la dépendance à la source. Si deux modules techniques sont fortement couplés et génèrent des blocages récurrents, revoir l’architecture pour les découpler est un investissement qui se rentabilise rapidement. L’élimination est la stratégie la plus efficace mais aussi la plus exigeante, parce qu’elle demande souvent de modifier l’organisation du travail ou la structure des équipes.
La deuxième stratégie vise à atténuer l’impact de la dépendance sans la supprimer. Diversifier les fournisseurs pour un composant critique, constituer un stock tampon de livrables intermédiaires ou décaler l’ordre des tâches pour éviter qu’une dépendance ne se trouve sur le chemin critique: ces mesures réduisent la probabilité ou la gravité d’un blocage sans éliminer le lien sous-jacent.
La troisième stratégie, gérer activement, s’applique aux dépendances qu’on ne peut ni supprimer ni atténuer. Il s’agit alors de mettre en place un suivi rigoureux: identifier un responsable pour chaque dépendance critique, définir des indicateurs d’alerte précoce, planifier des points de contrôle réguliers et documenter des procédures d’escalade en cas de retard. Ce cadre en trois niveaux, décrit par Lucid, transforme une liste de risques passifs en un plan d’action structuré.
Intégrer la gestion des dépendances au quotidien du projet
La gestion des dépendances n’est pas un exercice ponctuel réalisé en début de projet puis oublié. De nouvelles dépendances apparaissent à chaque changement de périmètre, à chaque nouvelle intégration technique, à chaque ajout d’un acteur externe. Les projets qui gèrent bien leurs dépendances intègrent cette dimension dans leurs rituels réguliers.
En contexte prédictif, cela passe par une colonne dédiée dans le registre des risques (le document central où sont consignés tous les événements incertains susceptibles d’affecter le projet), avec un suivi systématique lors des comités de pilotage. En contexte agile, la rétrospective offre un moment naturel pour analyser les dépendances qui ont causé des blocages pendant l’itération et identifier des actions correctives. Le référentiel Atlassian suggère également d’intégrer l’examen des dépendances dans le refinement du backlog, de manière à ce que les items les plus dépendants soient traités en priorité.
L’enjeu n’est pas d’éliminer toutes les dépendances, ce qui serait irréaliste, mais de passer d’une posture réactive, où l’on découvre les blocages au fil de l’eau, à une posture proactive où chaque dépendance significative est identifiée, classée et traitée avant qu’elle ne devienne un obstacle. Cette transition constitue l’un des marqueurs les plus fiables de la maturité d’un chef de projet.