Un projet complexe n'a pas besoin d'un outil complexe — il a besoin d'être découpé correctement. Les sous-projets servent exactement à ça : réduire un ensemble difficile à suivre en morceaux qu'on peut regarder un par un, sans perdre la vue d'ensemble.
Un exemple concret
Prenons un projet de déploiement d'un nouvel outil dans une organisation avec plusieurs services. Plutôt qu'une liste unique de dizaines de tâches mélangées, la hiérarchie en sous-projets permet de refléter la structure réelle du travail :
Chaque service avance à son rythme, avec son propre responsable et ses propres échéances — sans que ça brouille la vue d'ensemble du projet parent, ni que les tâches d'un service polluent le tableau d'un autre.
Sans limite de profondeur
✗ Hiérarchie à un seul niveau
Oblige à aplatir artificiellement les structures complexes — un sous-projet qui a lui-même des composantes distinctes ne rentre pas dans le modèle.
✓ Profondeur illimitée
Les sous-projets s'imbriquent sur plusieurs niveaux, pour refléter fidèlement l'organisation réelle du travail.
Voir le détail sans perdre la vue globale
L'intérêt d'une bonne hiérarchie n'est pas seulement d'organiser — c'est de pouvoir naviguer entre les deux niveaux de lecture : le détail d'un sous-projet quand on y travaille, et la vue globale du projet parent quand on présente l'avancement à quelqu'un qui n'a pas besoin de tous les détails.
La bonne question n'est pas "combien de sous-projets créer", mais "est-ce que cette structure reflète vraiment qui fait quoi". Un découpage trop fin complique inutilement ; un découpage trop plat mélange tout. Le bon niveau, c'est celui où chaque sous-projet correspond à une responsabilité clairement identifiable.