🌳 WBS (Work Breakdown Structure) — Template Word + Excel
Format : Word (DOCX) + Excel + draw.io XML Auteur : Équipe pédagogique ITAG · PMP Pack Mise à jour : 2026
🎯 Description
Template de Work Breakdown Structure (WBS) pour décomposer un projet en livrables hiérarchisés. Conforme PMBOK 7 et compatible avec MS Project, Smartsheet, Asana.
📋 Contenu
Word (.docx)
- 3 niveaux hiérarchiques (Project → Phase → Deliverable → Work Package)
- Code de comptes WBS (1.0, 1.1, 1.1.1)
- Description de chaque work package
- Owner, durée estimée, dépendances
Excel (.xlsx)
- Tableau avec colonnes : ID, parent ID, name, duration, start, end, owner, status
- Vue Gantt simple intégrée
- Formules de roll-up (parent = somme enfants)
draw.io (.drawio.xml)
- Diagramme arborescent (org chart vertical)
- Codes couleur par phase
- Compatible export PNG / SVG / PDF
🧠 Bonnes pratiques WBS
- 100% rule : la somme des enfants = 100% du parent
- Mutually exclusive : pas de chevauchement entre work packages
- Outcome-oriented : chaque WP est un livrable, pas une activité
- 8/80 rule : work package entre 8 et 80 heures
- Convention de nommage stable
💼 Cas d'usage
- Démarrage de projet PMP
- Études de cas examen PMP / CAPM
- Plan détaillé pour mémoire de master
- Référence pour PMO
📄 Template WBS complet
En-tête projet
| Champ | Valeur |
|---|---|
| Nom du projet | [Nom du projet — ex. Développement App SaaS] |
| Chef de projet | [Prénom Nom] · [PMP® / CAPM® / Prince2®] |
| Sponsor | [Prénom Nom] · [Fonction] |
| Date de début | [JJ/MM/AAAA] |
| Date de fin | [JJ/MM/AAAA] |
| Budget total | [X XXX €] / [X XXX CAD$] |
| Version WBS | v[1.0] — [JJ/MM/AAAA] |
WBS hiérarchique — Développement application web SaaS
[NOM DU PROJET]
│
├── 1. Gestion de projet
│ ├── 1.1 Charte de projet
│ ├── 1.2 Plan de management du projet
│ ├── 1.3 Réunions de suivi (weekly/bi-weekly)
│ └── 1.4 Clôture du projet
│
├── 2. Analyse & Conception
│ ├── 2.1 Recueil des exigences (Requirements)
│ ├── 2.2 Architecture technique
│ └── 2.3 Maquettes UI/UX (wireframes + prototype)
│
├── 3. Développement
│ ├── 3.1 Backend (API REST / logique métier)
│ ├── 3.2 Frontend (interface utilisateur)
│ ├── 3.3 Base de données (schéma + migrations)
│ └── 3.4 Intégrations API tierces
│
├── 4. Tests & QA
│ ├── 4.1 Tests unitaires
│ ├── 4.2 Tests d'intégration
│ ├── 4.3 Tests d'acceptation utilisateur (UAT)
│ └── 4.4 Audit de sécurité (SAST / DAST)
│
├── 5. Déploiement
│ ├── 5.1 Infrastructure cloud (provisioning)
│ ├── 5.2 Pipeline CI/CD
│ ├── 5.3 Migration des données
│ └── 5.4 Go-live & bascule DNS
│
└── 6. Formation & Support
├── 6.1 Documentation technique + utilisateur
├── 6.2 Formation des utilisateurs finaux
└── 6.3 Hypercare (30 jours post go-live)Tableau des work packages
| ID WBS | Description du Work Package | Responsable | Durée (j) | Dépendances | Livrable |
|---|---|---|---|---|---|
| 1.1 | Charte de projet | Chef de projet | 3 | — | Document charte signé |
| 1.2 | Plan de management du projet | Chef de projet | 5 | 1.1 | Plan projet validé |
| 1.3 | Réunions de suivi | Chef de projet | Récurrent | 1.2 | CR de réunion hebdomadaire |
| 1.4 | Clôture du projet | Chef de projet | 2 | Toutes phases | Rapport de clôture |
| 2.1 | Recueil des exigences | Business Analyst | 7 | 1.2 | Cahier des charges / User Stories |
| 2.2 | Architecture technique | Architecte | 5 | 2.1 | Dossier d'architecture (DAT) |
| 2.3 | Maquettes UI/UX | UX Designer | 8 | 2.1 | Prototype Figma validé |
| 3.1 | Développement Backend | Dev Backend | 30 | 2.2, 2.3 | API REST documentée (Swagger) |
| 3.2 | Développement Frontend | Dev Frontend | 25 | 2.3, 3.1 | Interface utilisateur fonctionnelle |
| 3.3 | Base de données | DBA / Dev Backend | 5 | 2.2 | Schéma DB + scripts migrations |
| 3.4 | Intégrations API tierces | Dev Backend | 10 | 3.1 | Connecteurs testés et documentés |
| 4.1 | Tests unitaires | Dev / QA | 10 | 3.1, 3.2 | Rapport couverture ≥ 80% |
| 4.2 | Tests d'intégration | QA | 7 | 4.1 | Rapport tests intégration |
| 4.3 | UAT (User Acceptance Testing) | PO + Utilisateurs | 5 | 4.2 | Procès-verbal de recette signé |
| 4.4 | Audit de sécurité | DevSecOps / Pentesteur | 5 | 4.2 | Rapport pentest + remédiations |
| 5.1 | Infrastructure cloud | SysAdmin / DevOps | 5 | 2.2 | Environnement prod provisionné |
| 5.2 | Pipeline CI/CD | DevOps | 5 | 5.1 | Pipeline GitHub Actions / GitLab CI |
| 5.3 | Migration des données | DBA | 3 | 5.1, 4.3 | Données migrées + vérification |
| 5.4 | Go-live & bascule DNS | DevOps + Chef projet | 1 | 5.1, 5.2, 5.3 | Application accessible en production |
| 6.1 | Documentation | Tech Writer / Dev | 7 | 3.1, 3.2 | Manuel utilisateur + doc technique |
| 6.2 | Formation utilisateurs | Chef de projet | 3 | 6.1, 5.4 | Sessions formation animées |
| 6.3 | Hypercare post go-live | Dev + Support | 30 | 5.4 | Journal incidents J+30 |
Règles WBS (rappel)
Règle des 100 %
La somme de tous les work packages d'un niveau doit représenter exactement 100 % du livrable du niveau parent, sans rien oublier ni dupliquer.
Règle 8/80
Chaque work package doit avoir une durée estimée comprise entre 8 heures (1 jour) et 80 heures (10 jours). En deçà : regrouper. Au-delà : décomposer davantage.
Orientation livrables (outcome-oriented)
Les work packages doivent nommer des livrables (un document, un module fonctionnel, un rapport), jamais des actions génériques ("développer", "analyser"). Préférer "Rapport d'architecture v1 validé" à "Faire l'architecture".
Convention de nommage
Format recommandé : [Verbe à l'infinitif] + [Livrable] + [Précision optionnelle]
Exemple : Rédiger le cahier des charges fonctionnel v1.0
Mutually exclusive
Aucun work package ne doit chevaucher un autre. Si deux WP peuvent produire le même résultat partiel, les fusionner ou les redéfinir.
📥 Téléchargement
Télécharger ce template · ← Catalogue Word · Parcours PMP →
ITAG · PMP® / PMBOK® sont des marques du Project Management Institute.