Module 2Planifier un projet
Chapitre 3 sur 11
Besoins explicites et implicites, contexte, note de cadrage, périmètre, registre des risques et analyse SWOT.
Objectifs
Avec ce chapitre, tu sauras…
Leçon 1
Tout projet commence par l'expression d'un besoin, plus ou moins complète. Selon que le projet est interne (pour sa propre entreprise) ou externe (pour un client), et selon la façon dont le besoin est exprimé, la situation du chef de projet est très différente. Son premier travail : analyser le besoin, le compléter si nécessaire et le reformuler en objectifs et en livrables.
| Notion | Définition | Comment la repérer |
|---|---|---|
| besoin explicite | exprimé clairement, sans ambiguïté, et sur lequel il y a consensus | reformule-le et observe la réaction : « Si je comprends bien, vous voulez… » |
| besoin implicite | non exprimé mais indispensable : le client le considère comme évident ou n'y a pas pensé | observe le contexte, pose des questions ouvertes, regarde les concurrents et les utilisateurs |
| livrable potentiel | le résultat concret qui répond au besoin | associe chaque besoin à un ou plusieurs livrables |
| Besoin explicite | Besoin implicite | Livrable potentiel |
|---|---|---|
| développer la présence en ligne | la clientèle est surtout étrangère : le site doit être multilingue (français, anglais, chinois, russe) | site web multilingue |
| moderniser l'image de marque | conserver le nom et le logo de l'établissement | adaptation de la charte graphique |
| permettre aux clients de réserver en ligne | le personnel doit pouvoir gérer les prix et les réservations dans un back-office | système de réservation et de gestion |
Vidéo · À regarder
FRBien rédiger le cahier des charges d'un site web + Modèle gratuit
Matchfolio · YouTube
Leçon 2
| Axe d'analyse (méthode PESTEL) | Question | Exemple pour Kitab |
|---|---|---|
| Politique | des décisions publiques influencent-elles le projet ? | programme de soutien à la lecture |
| Économique | marché, pouvoir d'achat, concurrence | prix des livres importés, concurrence des grandes plateformes |
| Social |
Leçon 3
| Pour maîtriser le périmètre | |
|---|---|
| écrire noir sur blanc ce qui est inclus et exclu | « l'application mobile n'est pas incluse dans cette version » |
| faire valider le périmètre par le commanditaire | signature de la note de cadrage |
| traiter toute nouvelle demande par une procédure de changement | évaluer l'impact sur les délais et les coûts, puis accepter (avec avenant), refuser ou reporter |
Leçon 4
| Type de risque | Exemples |
|---|---|
| financier | coût supérieur à l'estimation, budget coupé, client qui ne paie pas |
| humain | manque de compétences, absentéisme, démission en cours de projet, conflits |
| temporel | retard d'un sous-traitant ou d'un fournisseur, mauvaise estimation des délais |
| technique | logiciel inadapté, panne, matériel obsolète, technologie mal maîtrisée, faille de sécurité |
Leçon 5
| Cause d'échec (résumé) | Remède |
|---|---|
| manque de visibilité : le planning n'est jamais mis à jour, personne ne connaît les priorités | un diagramme de Gantt ou un tableau de sprint à jour, partagé par toute l'équipe |
| objectifs imprécis : comme construire une maison sans plan | des objectifs SMART validés dès le lancement |
| planning sous-estimé : retard, dépassement de budget, marchés perdus | estimer avec méthode (chapitre 4), garder une marge, gérer les risques |
| aucune visibilité sur la disponibilité des ressources : certains débordés, d'autres inoccupés | des feuilles de temps et un planning des ressources ; rééquilibrer la charge |
Leçon 6
| Positif | Négatif | |
|---|---|---|
| interne (dépend de nous) | Forces (Strengths) | Faiblesses (Weaknesses) |
| externe (dépend de l'environnement) | Opportunités (Opportunities) | Menaces (Threats) |
1Un besoin non exprimé par le client mais indispensable est…
2Ce qui n'est pas compris dans le projet s'appelle…
3L'ajout progressif de fonctionnalités non prévues s'appelle…
4La criticité d'un risque se calcule par…
5Souscrire une assurance est une stratégie de…
6Dans une analyse SWOT, une menace est…
7Le document de référence qui décrit le projet avant son lancement est…
8La démission d'un développeur est un risque…
L'essentiel du chapitre
| achats sur téléphone, paiement à la livraison très répandu |
| Technologique | outils et technologies disponibles | passerelles de paiement marocaines, réseau mobile |
| Environnemental | impact écologique | emballages, livraisons groupées |
| Légal | lois et réglementations | loi 09-08 (données personnelles), droit de la consommation, TVA |
| en agile : un backlog priorisé | une nouvelle demande est bienvenue, mais elle prend la place d'une autre si le délai et l'équipe sont fixes |
| juridique |
| non-respect d'une loi (données personnelles), faillite d'un fournisseur, litige contractuel |
| environnemental | inondation, coupure d'électricité, ou impact négatif du projet sur l'environnement |
| organisationnel | changement de stratégie de l'entreprise, nouveau directeur, crise économique |
| Probabilité ↓ · Gravité → | 1 négligeable | 2 modérée | 3 grave | 4 critique |
|---|---|---|---|---|
| 4 quasi certain | 4 | 8 | 12 | 16 |
| 3 probable | 3 | 6 | 9 | 12 |
| 2 possible | 2 | 4 | 6 | 8 |
| 1 rare | 1 | 2 | 3 | 4 |
| Stratégie | Principe | Exemple |
|---|---|---|
| éviter | supprimer la cause, changer le plan | renoncer à une technologie que personne ne maîtrise |
| réduire (atténuer) | diminuer la probabilité ou l'impact par des actions préventives | former l'équipe, documenter le code, faire des sauvegardes |
| transférer | confier le risque à un tiers | assurance, sous-traitance du paiement à une passerelle certifiée |
| accepter | assumer le risque, avec éventuellement un plan de secours et une réserve (budget, temps) | prévoir 10 % de marge dans le planning |
| Risque (Kitab) | P | G | Criticité | Action | Responsable |
|---|---|---|---|---|---|
| retard de la passerelle de paiement pour ouvrir le compte marchand | 3 | 4 | 12 | lancer la demande dès la semaine 1 ; prévoir le paiement à la livraison en solution de repli | chef de projet |
| départ du seul développeur qui connaît Laravel | 2 | 4 | 8 | binômes, revue de code, documentation | lead développeur |
| catalogue fourni en retard par la librairie | 3 | 2 | 6 | importer d'abord un catalogue partiel | Product Owner |
| fuite de données clients | 1 | 4 | 4 | bonnes pratiques du M108, audit avant mise en ligne | lead développeur |
| mauvaise communication : l'équipe se replie sur elle-même, l'ambiance se dégrade | réunions de suivi régulières, outil collaboratif, écoute, climat de confiance |
Le périmètre validé du site de Kitab comprend : catalogue, recherche, compte client, panier, commande avec retrait en magasin, paiement par carte, back-office libraire. Pour chaque demande arrivée en cours de projet, dis si elle est dans le périmètre et ce que fait le chef de projet : (1) afficher les livres d'un auteur ; (2) une application mobile Android ; (3) la livraison à domicile ; (4) un bouton « mot de passe oublié » ; (5) un blog de critiques littéraires.
Exemple du résumé : l'hôtel Paradis veut développer sa présence en ligne.
Lors des échanges exploratoires (téléphone, visioconférence, réunion, e-mail), sois irréprochable dans la relation et attentif à trois choses : les besoins explicites, les besoins implicites et les livrables possibles. Une question très efficace : « Comment faites-vous aujourd'hui ? » Elle révèle les besoins implicites (l'hôtel gère ses réservations dans un cahier : il faudra reprendre l'historique).
Ce que tu vas voir (5 min) : les chapitres « Pourquoi faire un cahier des charges ? », « La présentation du projet », « L'arborescence et le contenu », « Le design et l'ergonomie », « Les fonctionnalités attendues ». Ces chapitres montrent comment formuler le besoin du client dans un cahier des charges : présentation du projet, arborescence, design et fonctionnalités attendues.
Le contexte d'un projet est l'ensemble des informations qui le caractérisent et lui donnent de la profondeur : son histoire et son origine, l'environnement réglementaire, culturel, économique, concurrentiel et social de l'entreprise, son organisation et ses outils actuels.
Un projet s'inscrit toujours dans un environnement complexe aux éléments interdépendants. Exposer le contexte donne du sens au travail de l'équipe : les développeurs aussi aiment savoir pourquoi ils développent, et ils prennent de meilleures décisions quand ils comprennent le problème.
Le périmètre (scope) est l'ensemble des éléments qui composent le projet : ce qui doit être réalisé (le travail et les livrables) et, tout aussi important, ce qui n'est pas compris dans le projet (le hors périmètre). C'est sur lui qu'on estime la charge de travail, puis qu'on bâtit le planning et le budget. C'est l'un des trois côtés du triangle d'or (chapitre 1).
Tu passes à l'épicerie pour acheter des œufs. Sur le chemin, tu prends des céréales (deux boîtes), une bougie parfumée, des serviettes en papier… Tes bras ne suffisent plus, tu vas chercher un chariot, et tu manques d'oublier les œufs. Cinq minutes prévues, une heure passée ; moins de 50 DH prévus, plus de 1 000 dépensés. Dans un projet, c'est la dérive des objectifs (scope creep) : on ajoute toujours un peu plus de fonctionnalités, jusqu'à dépasser les délais et le budget, et parfois oublier l'essentiel.
Un risque est un événement incertain qui, s'il se produit, a un impact (le plus souvent négatif) sur les objectifs du projet : délais, coûts, qualité. Il faut dresser, dès le démarrage, la liste la plus complète possible des risques, par exemple en brainstorming avec l'équipe.
Une fois les besoins, le contexte, le périmètre et les risques clarifiés, le chef de projet propose une ou plusieurs solutions au commanditaire, avec pour chacune son coût, son délai, ses avantages, ses risques. L'analyse SWOT aide à présenter une solution ou à comparer des options.
Exemple pour la solution « site Laravel développé en interne » de Kitab : forces : équipe formée à PHP, maîtrise du code, coût de licence nul ; faiblesses : petite équipe, pas d'expérience du paiement en ligne ; opportunités : forte croissance des achats en ligne, rentrée scolaire ; menaces : concurrence des grandes plateformes, délais d'obtention du compte marchand.
Rédige la note de cadrage de Kitab : contexte (avec une analyse PESTEL), tableau besoins explicites / implicites / livrables, périmètre inclus et exclu, registre de six risques avec leur criticité, analyse SWOT de la solution retenue, procédure de gestion des demandes de changement.
Un club de sport de Tanger demande « une application web pour que les adhérents réservent leurs cours ». Trouve trois besoins explicites, quatre besoins implicites (pense aux coachs, aux salles, aux abonnements, aux langues, aux téléphones) et les livrables correspondants.
Pour le projet du club de sport, identifie six risques de types différents, évalue leur probabilité et leur gravité (de 1 à 4), calcule leur criticité, classe-les et propose pour chacun une stratégie (éviter, réduire, transférer, accepter) et une action.
Tous ces éléments sont consignés dans la note de cadrage.
Évaluer les risques
On évalue chaque risque selon sa probabilité (de 1, rare, à 4, quasi certain) et sa gravité (de 1, négligeable, à 4, critique). La criticité est leur produit : criticité = probabilité × gravité.
Les risques de criticité élevée (par exemple ≥ 9) sont traités en priorité, ceux de criticité moyenne sont surveillés, les faibles sont acceptés.
Tableau: Traiter les risques