Ébaucher la WBS et le planning

Ce que l'IA fait bien ici, ce qu'elle fait mal

Ce qu'elle fait bien

• Partir d'un énoncé du périmètre: le modèle rend en quelques minutes un arbre numéroté à corriger.
• Rappeler le travail transversal: sur demande, il ajoute gestion de projet, tests, formation et test d'acceptation (UAT).
• Découper par livrable: quand le prompt l'exige, chaque élément porte un nom de livrable plutôt qu'un verbe.
• Nommer ses hypothèses: le modèle liste ce qu'il a supposé faute d'information.
• Critiquer un arbre fourni: une seconde passe relève recoupements, lacunes et éléments qui décrivent une activité.
• Établir la liste d'activités: le modèle reporte l'identifiant du lot dans chaque activité qu'il propose.

Ce qu'elle fait mal

• Connaître votre projet: sans énoncé du périmètre, le modèle découpe un projet type.
• Respecter les exclusions: un lot exclu revient dans l'arbre quand les projets de ce type le contiennent d'habitude.
• Voir le travail propre au projet: la reprise des anciennes données manque tant que personne ne la nomme.
• Garder la numérotation: relancé, le modèle renumérote l'arbre et rompt le lien entre lot et activité.
• Séparer deux lots voisins: le même travail apparaît sous deux parents avec deux libellés différents.
• Justifier une dépendance: le modèle donne une raison plausible à une dépendance qu'il a inventée.

Déroulé

Le PMBOK Guide définit la WBS comme la décomposition hiérarchique de tout le travail que l'équipe doit accomplir pour livrer le projet (huitième édition, 2.2.1). Dans un projet prédictif, l'énoncé du périmètre, la WBS et son dictionnaire forment la référence de base du périmètre (scope baseline). L'élément le plus bas de l'arbre est le lot de travaux. Selon le PMBOK, le développement de l'échéancier commence par décomposer les lots en activités (2.3). Ce déroulé vaut pour les projets prédictifs et hybrides. Sur un projet agile, le découpage prend la forme d'un backlog: la fiche Décomposition de stories traite ce cas.

La page «L'aide à l'estimation» traite l'estimation des durées et de l'effort. La page «Identifier les risques» traite les risques du projet.

1. Le chef de projet rassemble l'énoncé du périmètre. Selon le PMBOK, l'énoncé décrit le périmètre, les principaux livrables et les exclusions. Le modèle a besoin des trois. Les exclusions comptent autant que les livrables: elles tiennent hors de l'arbre un travail que les projets de ce type contiennent d'habitude. Vous trouverez dans la fiche Modélisation du périmètre comment un modèle aide à tracer la frontière.
2. Le chef de projet choisit l'axe et la profondeur. Il retient un seul axe par niveau: le livrable, la phase ou le composant. Il fixe la profondeur au lot de travaux qu'une seule personne peut porter et que l'équipe peut estimer. La fiche Décomposition fonctionnelle compare les axes et décrit le lot de travaux.
3. Le modèle ébauche l'arbre. Le prompt de l'étape 3 lui donne l'énoncé, l'axe et la profondeur. Le modèle numérote chaque élément, ajoute une branche Gestion de projet et rattache chaque lot à un livrable de l'énoncé. Il liste enfin ses hypothèses. Chaque hypothèse devient une question pour le mandant.
4. Le chef de projet teste l'arbre par la règle des 100 %. Le Practice Standard for Work Breakdown Structures du PMI en fait un principe de la WBS: à chaque niveau, les enfants couvrent tout le travail du parent et rien d'autre. Le chef de projet pose deux questions à chaque parent. Si l'équipe livrait tous les enfants, le parent serait-il livré? Un enfant contient-il un travail que l'énoncé exclut? Il confronte ensuite l'arbre à chaque exclusion de la liste. Un arbre généré résiste mal à ce test. Pris seul, chaque élément est plausible. La lacune se voit au niveau du parent. La fiche Décomposition fonctionnelle décrit les contrôles de forme qu'un modèle fait sur un arbre.
5. Le modèle critique l'arbre corrigé. Le chef de projet ouvre une nouvelle conversation. Le prompt de l'étape 5 demande des questions: les éléments qui se recoupent, le travail qu'aucun élément ne couvre, les éléments qui décrivent une activité, les lots qui demandent deux responsables. Il interdit au modèle de rendre un arbre corrigé. Un arbre réécrit cache ce qui a changé et renumérote les éléments. La page L'autocritique fait réviser la sortie par le modèle après sa critique. À l'étape 5, la critique s'arrête aux questions: le chef de projet corrige lui-même l'arbre. La page Les chaînes de prompts explique pourquoi chaque maillon garde une seule tâche. Vous trouverez dans la fiche Estimation ascendante le même contrôle sur la décomposition qui sert au chiffrage.
6. L'équipe répond aux questions et nomme un responsable par lot. Le modèle peut rédiger les entrées du dictionnaire de la WBS: la description du travail, le livrable, les critères d'acceptation. Le responsable de chaque lot relit son entrée et la corrige. Un lot que deux personnes revendiquent se scinde en deux.
7. Le chef de projet fait approuver la référence de base du périmètre. Le mandant l'approuve. Elle ne change ensuite que par la maîtrise des modifications. Le modèle n'intervient pas dans cette étape. Dès l'approbation, les numéros des lots sont gelés: une version suivante de l'arbre garde les numéros existants et en ajoute.
8. Le modèle propose la liste d'activités. Le prompt de l'étape 8 lui donne les lots de la référence. Le PMBOK compte l'identifiant de l'activité et celui de l'élément de la WBS parmi les premiers attributs d'une activité. Le modèle reporte donc le numéro du lot dans chaque activité. Il place un jalon à la livraison de chaque livrable et propose les prédécesseurs de chaque activité avec leur raison. Il laisse les durées et les dates à l'équipe. Vous trouverez dans les fiches Diagramme de Gantt et Méthode du chemin critique ce que le modèle contrôle sur un planning exporté.
9. L'équipe corrige les dépendances et fixe les durées. L'équipe relit la raison de chaque dépendance proposée, corrige les dépendances et saisit les durées dans l'outil de planification. Les estimations des lots se consolident par l'estimation ascendante.
10. L'équipe s'engage sur le planning. Le mandant approuve la référence de base du planning. Comme la référence de base du périmètre, elle ne change ensuite que par la maîtrise des modifications.

Prompt modèle

Chaque bloc porte le numéro de l'étape qu'il sert.

Étape 3: ébaucher l'arbre

Tu es chef de projet. Tu prépares une première structure de découpage du projet (WBS) pour [PROJET ET ORGANISATION].

<perimetre>
[ÉNONCÉ DU PÉRIMÈTRE]
</perimetre>

<exclusions>
[EXCLUSIONS]
</exclusions>

<livrables>
[LIVRABLES]
</livrables>

<consignes>
1. Découpe le projet par [AXE DE DÉCOUPAGE] jusqu'au niveau [PROFONDEUR]. Garde un seul axe par niveau.
2. Numérote chaque élément: 1, 1.1, 1.1.1.
3. Donne à chaque élément un nom qui désigne le livrable ou le résultat qu'il produit: «Logiciel paramétré».
4. Ajoute une branche Gestion de projet.
5. Laisse hors de l'arbre tout travail que <exclusions> nomme.
6. Pour chaque élément du niveau le plus bas, indique le livrable de <livrables> qu'il sert. Écris «aucun» s'il n'en sert aucun.
7. Après l'arbre, liste une par ligne les hypothèses que tu as faites faute d'information.
</consignes>

• [PROJET ET ORGANISATION] situe le domaine et le vocabulaire attendu.
• [ÉNONCÉ DU PÉRIMÈTRE] reçoit la description du périmètre de l'étape 1.
• [EXCLUSIONS] liste un par ligne les travaux que le projet ne fait pas.
• [LIVRABLES] liste les principaux livrables avec leur numéro. Chaque lot renvoie à l'un d'eux par ce numéro.
• [AXE DE DÉCOUPAGE] nomme l'axe du premier niveau: livrable, phase ou composant.
• [PROFONDEUR] fixe le nombre de niveaux. Une ébauche en compte deux ou trois.

Étape 5: faire critiquer l'arbre

Tu relis une structure de découpage du projet (WBS) écrite par un autre chef de projet.

<perimetre>
[ÉNONCÉ DU PÉRIMÈTRE]
</perimetre>

<exclusions>
[EXCLUSIONS]
</exclusions>

<arbre>
[ARBRE À CRITIQUER]
</arbre>

<consignes>
1. Relève les éléments frères dont le travail se recoupe.
2. Pour chaque livrable, relève le travail nécessaire qu'aucun élément ne couvre: préparation, reprise de données, tests, formation, mise en service, test d'acceptation.
3. Relève les éléments qui décrivent une activité au lieu d'un livrable.
4. Relève les éléments qui contiennent un travail que <exclusions> nomme.
5. Relève les lots du niveau le plus bas qui demandent deux responsables.
6. Formule chaque constat comme une question au chef de projet et cite les numéros en cause.
7. Garde l'arbre tel quel. Rends seulement les questions.
</consignes>

• [ARBRE À CRITIQUER] reçoit l'arbre numéroté que le chef de projet a corrigé à l'étape 4.
• Les autres champs reprennent mot pour mot le texte de l'étape 3.

Étape 8: établir la liste d'activités

Tu prépares la liste d'activités d'un projet à partir de sa référence de base du périmètre approuvée.

<reference>
[LOTS DE LA RÉFÉRENCE]
</reference>

<consignes>
1. Pour chaque lot, propose les activités qui produisent son livrable. Donne à chaque activité un identifiant formé du numéro du lot et d'une lettre: 3.4-a, 3.4-b.
2. Pour chaque activité, propose ses prédécesseurs et donne la raison de chaque dépendance en une ligne.
3. Place un jalon à la livraison de chaque livrable.
4. Donne à chaque activité la durée provisoire 1d. L'équipe fixe les durées. N'écris aucune date sauf [DATE DE DÉBUT].
5. Rends d'abord un tableau: identifiant, lot, activité, prédécesseurs, raison de la dépendance.
6. Rends ensuite le même contenu en syntaxe Mermaid gantt. Utilise dateFormat YYYY-MM-DD, excludes weekends et la dépendance after. Remplace les points et les tirets des identifiants par _ et fais précéder chaque identifiant d'activité de a: a3_4_a. Nomme chaque jalon m suivi du numéro de son lot: m3_4.
</consignes>

• [LOTS DE LA RÉFÉRENCE] reçoit les lots approuvés à l'étape 7. Chaque lot porte son numéro, son livrable et son entrée du dictionnaire.
• [DATE DE DÉBUT] donne la date de début du projet au format AAAA-MM-JJ.

Une fiduciaire remplace son logiciel de gestion des mandats. Pour ses lots 3.4 et 3.2, le modèle propose trois activités et un jalon. L'équipe relit la raison de chaque dépendance à l'étape 9.

Essayer avec Mermaid Live Editor

Mermaid Live Editor est l'éditeur en ligne du projet Mermaid. Il dessine un diagramme à partir de son texte. Collez dans le volet de code la sortie Mermaid de l'étape 8. Sans modèle sous la main, collez le texte Mermaid des lots 3.4 et 3.2 de la fiduciaire. Remplacez une durée 1d par 5d: l'éditeur décale les activités qui suivent. Le modèle a écrit les dépendances et l'éditeur a calculé les dates. N'y collez que des exemples inventés.

gantt
    title Fiduciaire, lots 3.4 et 3.2
    dateFormat YYYY-MM-DD
    excludes weekends
    section 3.4 Mandats repris
    Extraction des mandats:a3_4_a, 2026-03-02, 1d
    Contrôle de la reprise:a3_4_b, after a3_4_a, 1d
    Mandats repris:milestone, m3_4, after a3_4_b, 0d
    section 3.2 Collaborateurs formés
    Formation des équipes:a3_2_a, after m3_4, 1d

Exemple

Une fiduciaire lausannoise de 35 personnes remplace son logiciel de gestion des mandats. L'énoncé du périmètre prévoit un logiciel paramétré, la reprise des 1'200 mandats actifs, des collaborateurs formés et l'ancien logiciel désactivé. Il exclut le remplacement du logiciel comptable. Le modèle a rendu un arbre de trois branches. Le chef de projet l'a testé par la règle des 100 %.

Les enfants de la branche Mise en service ne couvrent pas leur parent. Les 1'200 mandats actifs doivent passer dans le nouveau logiciel. Aucun lot ne porte cette reprise. La branche Logiciel contient le lot 2.2 «Migration de la comptabilité», que l'énoncé exclut. Le chef de projet a retiré ce lot et ajouté le lot 3.4 «Mandats repris». Il n'a pas renuméroté la branche Logiciel: le lot 2.3 garde son numéro et la critique le cite tel quel. Il a ensuite soumis l'arbre à la critique de l'étape 5.

La critique a trouvé l'archivage, que ni l'ébauche du modèle ni le chef de projet n'avaient prévu. Chaque client doit conserver ses livres et ses pièces comptables pendant dix ans (art. 958f CO). La fiduciaire les garde pour son compte. Une partie se trouve dans l'ancien logiciel. Le lot 3.5 les garde lisibles une fois ce logiciel désactivé. La critique n'a rien réécrit: chaque modification de l'arbre porte une décision du chef de projet.

Vérifier le résultat

• L'arbre repose-t-il sur un énoncé du périmètre écrit qui nomme les exclusions?
• À chaque niveau, les enfants couvrent-ils tout le travail de leur parent?
• Chaque élément reste-t-il hors des exclusions?
• La branche Gestion de projet figure-t-elle dans l'arbre?
• Chaque lot nomme-t-il un livrable plutôt qu'une action?
• Chaque lot renvoie-t-il à un livrable de l'énoncé?
• Chaque lot a-t-il un seul responsable?
• Chaque hypothèse du modèle a-t-elle reçu une réponse?
• Les numéros des lots sont-ils restés les mêmes depuis l'approbation de la référence?
• Chaque activité porte-t-elle le numéro d'un lot de la référence?
• L'équipe a-t-elle vérifié la raison de chaque dépendance?
• Les dates viennent-elles de l'outil de planification?

Limites et risques

La WBS décrit l'organisation du projet. Le dictionnaire nomme le responsable de chaque lot. Ces noms sont des données personnelles. Quand le chef de projet envoie ces noms à un service d'IA, le fournisseur agit comme sous-traitant: l'art. 9 LPD exige un contrat ou une base légale. Si le fournisseur traite les données hors de Suisse, l'art. 16 soumet cette communication à une décision d'adéquation du Conseil fédéral ou à des garanties. L'arbre porte aussi des noms de fournisseurs et des montants qu'une clause de confidentialité peut couvrir. Le chef de projet remplace les noms par des rôles avant d'envoyer l'arbre. Il utilise le service que son organisation a évalué. La page «La LPD et les données confidentielles» traite ce cadre.

Un arbre plausible paraît complet. Sarim et ses coauteurs ont demandé à des modèles de langage les tâches de projets logiciels connus. Les listes ressemblent de près aux listes de référence. Les auteurs mesurent cette ressemblance avec un indicateur qu'ils ont conçu pour le logiciel. Ils n'ont mené aucune évaluation humaine formelle. Leurs projets sont décrits publiquement. Le travail propre à votre projet ne l'est pas. L'archivage de la fiduciaire, par exemple, n'est décrit nulle part. Le test des 100 % reste donc au chef de projet. Vous trouverez le cas général dans la fiche Décomposition fonctionnelle.

Ordonner des actions reste un point faible des modèles. Valmeekam et ses coauteurs testent des modèles sur des problèmes de planification au sens de l'IA: trouver la suite d'actions qui mène à un but. Un problème type demande d'empiler des blocs dans un ordre donné. Un modèle de raisonnement y progresse nettement sans résoudre tous les problèmes. Le chef de projet ne demande donc au modèle que des dépendances candidates et leur raison.

La responsabilité reste au chef de projet. Il répond de la référence qu'il soumet au mandant et du planning sur lequel l'équipe s'engage. Il conserve les prompts, les réponses du modèle et les réponses aux questions. Le mandant et l'équipe retrouvent chaque modification de l'arbre avec sa raison.

Techniques liées

• Décomposition fonctionnelle: la règle des 100 %, le lot de travaux et les contrôles de forme qu'un modèle fait sur un arbre.
• Modélisation du périmètre: la frontière du projet, d'où partent l'énoncé et les exclusions.
• Estimation ascendante: le chiffrage des lots et leur consolidation.
• Diagramme de Gantt: la liste d'activités au format d'import et les dates que le modèle calcule mal.
• Méthode du chemin critique: les dépendances et la marge que l'outil calcule.
• Décomposition de stories: le découpage d'un backlog sur un projet agile.
• Carte heuristique: une ébauche de l'arbre sous forme de carte.
• Les chaînes de prompts: un appel par tâche et un contrôle entre deux appels.
• L'autocritique: la critique d'une sortie suivie de sa révision par le modèle.