La cartographie de projet consiste à rendre visibles les relations importantes d’un projet : le lien entre les travaux et un résultat, les dépendances entre livrables, les personnes qui contribuent et les décisions encore nécessaires. Le terme ne désigne pas un diagramme universel. Choisissez la carte en fonction de la question à résoudre.
Une carte de projet est utile lorsque les personnes savent lister des tâches, mais ne peuvent pas expliquer comment elles s’articulent. Elle peut aussi révéler que deux équipes utilisent le même nom de projet tout en visant des résultats différents. La carte rend ce désaccord visible avant qu’un échéancier détaillé ne lui donne une fausse apparence de certitude.
Choisir la carte à partir de la décision
| Question | Carte utile | Ce qu’elle ne remplace pas |
|---|---|---|
| Pourquoi faisons-nous ce travail ? | Carte des résultats et des livrables | Les preuves que le résultat compte |
| Que faut-il accomplir avant autre chose ? | Carte des dépendances | Un échéancier et un plan de ressources tenus à jour |
| Qui doit contribuer ? | Carte des parties prenantes ou des rôles | La participation réelle et l’acceptation des responsabilités |
| Comment le travail avance-t-il dans le processus ? | Carte de processus ou de flux de travail | L’observation des exceptions et des pratiques réelles |
| Qu’est-ce qui entre dans les limites du projet ? | Carte du périmètre | Un processus de décision sur les changements |
Ne réunissez pas toutes les vues sur une seule toile. Un diagramme avec des dizaines de types de flèches peut être moins utile qu’un petit ensemble de dossiers liés. Commencez par la question qui crée de l’incertitude.
Définir le résultat avant de cartographier les livrables
Décrivez le changement visé en une phrase. Distinguez ensuite les résultats des productions. Un formulaire, un service ou un rapport livré est une production. Une évolution utile de ce qu’une personne peut accomplir est un résultat qui doit être étayé par des preuves.
Les conseils de découverte de GOV.UK recommandent de comprendre le parcours utilisateur plus large ainsi que les équipes ou services autour du problème. Ce contexte aide à définir les limites d’un projet ; il ne prescrit pas l’atelier de cartographie décrit ci-dessous.
Demandez quelles productions pourraient raisonnablement contribuer au résultat. Si un flux de travail n’a aucun lien clair, il peut s’agir d’un travail de soutien indispensable, d’une hypothèse non testée ou d’un périmètre inutile. Signalez ce lien avant de décider de le conserver ou de le supprimer.
Créer une première carte de projet en cinq passages
- Placez le résultat en haut. Indiquez le groupe concerné et le signal que vous examinerez.
- Ajoutez les principaux livrables. Décrivez des résultats observables plutôt que des activités comme « travailler sur l’intégration ».
- Reliez les dépendances. Précisez ce qu’un élément attend d’un autre.
- Ajoutez les responsables et les décisions. Montrez qui coordonne chaque résultat et quel choix reste ouvert.
- Signalez l’incertitude. Distinguez les relations confirmées des hypothèses qui nécessitent des preuves.
Évitez d’ajouter des dates au premier passage, sauf si elles constituent une véritable contrainte. Une date annoncée trop tôt peut orienter la discussion avant que le périmètre et les dépendances soient compris. Ajoutez le calendrier quand les relations seront assez claires pour l’étayer.
Exemple détaillé : modification de compte en libre-service
Exemple hypothétique : une équipe veut permettre aux clients d’effectuer un changement courant de compte sans transfert vers l’assistance. Sa première liste de tâches contient la conception de l’interface, des travaux d’API, le contenu d’aide, l’analytique et une annonce de lancement.
La carte des résultats révèle des travaux manquants. L’API dépend d’une décision sur les personnes autorisées à demander le changement. Le contenu d’aide dépend de la compréhension des exceptions. La préparation de l’assistance exige de savoir quels cas resteront hors du libre-service.
L’équipe trace explicitement trois relations :
| Résultat | Dépend de | Décision ou preuve nécessaire |
|---|---|---|
| Parcours de changement de compte utilisable | Règle d’autorisation | Confirmer qui peut effectuer le changement |
| Parcours clair pour les exceptions | Cas non pris en charge identifiés | Examiner des cas limites représentatifs |
| Mesure du résultat | Événement de réalisation défini | Convenir de ce qui constitue une tâche terminée |
Cela modifie le plan immédiat. Au lieu de commencer tous les flux en même temps, l’équipe clarifie d’abord l’autorisation et examine les exceptions. L’exploration de l’interface peut continuer, mais reste provisoire.
La carte ne prouve pas quelle mise en œuvre est la meilleure. Elle montre quelles décisions influencent plusieurs travaux et méritent donc d’être traitées tôt.
Donner un sens aux flèches de dépendance
Indiquez sur chaque flèche la contribution attendue : décision, données, environnement, revue, interface ou capacité opérationnelle. « Équipe B » ne décrit pas une dépendance. « L’équipe B confirme la règle de propriété du compte » le fait.
Pour les dépendances externes, notez si la contribution a été demandée ou acceptée. Votre carte ne peut pas créer un engagement au nom d’une autre équipe. Nommez un contact, la dernière date utile et la conséquence d’un changement de contribution.
Distinguez une dépendance logique d’un ordre préféré. Deux éléments peuvent être planifiés à la suite parce que la même personne s’en occupe, sans que l’un exige techniquement l’autre. Cette différence compte lorsque l’équipe examine des options.
Animer un atelier de cartographie de projet de 45 minutes
Commencez par cinq minutes de lecture silencieuse du dossier. Pendant dix minutes, demandez aux participants d’écrire séparément les principaux livrables. Comparez les listes avant de les relier : les différences peuvent révéler une hypothèse de périmètre non résolue.
Consacrez quinze minutes au dessin et à l’étiquetage des relations. Réservez dix minutes à la remise en question des hypothèses aux conséquences les plus importantes, puis cinq minutes à l’attribution des prochaines étapes de collecte de preuves ou de décision.
Gardez un espace pour les détails qui ne changent pas l’objectif de la carte. Une décomposition complète de la mise en œuvre peut être faite plus tard dans le système de livraison de l’équipe. L’atelier doit aboutir à une prochaine décision plus claire, pas uniquement à une toile plus grande.
Invitez une personne qui exploitera le résultat à examiner la carte. Demandez ce qui pourrait échouer dès le premier jour après le lancement. Cela peut révéler des travaux d’assistance, de surveillance, de transfert et de maintenance absents d’une vision centrée sur la livraison.
Transformer la carte en plan tenu à jour
Choisissez un emplacement de référence et consignez la date et la personne responsable. Reliez les livrables au suivi du travail plutôt que de copier chaque tâche sur le diagramme. Conservez les décisions importantes dans un journal avec leur justification et leur responsable.
Mettez la carte à jour lorsqu’une limite, une dépendance ou une hypothèse change. Une carte utilisée uniquement au lancement devient une image historique. Une carte maintenue aide à expliquer pourquoi le plan actuel diffère de l’original.
Utilisez une rétrospective agile pour examiner la coordination de l’équipe autour de la carte. Demandez quelle dépendance est apparue trop tard ou quel livrable personne ne pouvait relier au résultat. Recueillez les observations dans un format de rétrospective simple, puis testez une amélioration avec le processus de suivi des rétrospectives.
Erreurs qui rendent les cartes de projet trompeuses
Cartographier uniquement les départements. Une étiquette de département peut masquer la décision, l’information ou le service réellement nécessaire. Nommez la contribution.
Traiter la carte comme un échéancier. Les relations facilitent la planification, mais ne déterminent ni la durée, ni la disponibilité, ni la fiabilité d’une date.
Présenter toutes les hypothèses comme des faits établis. Utilisez des libellés explicites et listez les étapes de collecte de preuves. La mise en forme ne doit pas effacer l’incertitude.
Inclure tous les détails possibles. Gardez la carte centrée sur la question. Si les lecteurs ne repèrent pas la prochaine décision, séparez les vues ou retirez les détails qui appartiennent ailleurs.
Foire aux questions
La cartographie de projet est-elle la même chose qu’une carte mentale ?
Une carte mentale peut aider à générer des idées autour d’un sujet. Une carte de projet nécessite généralement des relations explicites — contribution, dépendance, responsabilité ou périmètre — pour soutenir les décisions de livraison.
Une carte de projet peut-elle remplacer un plan de projet ?
Elle peut soutenir et simplifier la planification, mais ne remplace pas l’échéancier, les décisions sur les ressources, la gestion des risques ou les dossiers de gouvernance requis. Utilisez-la pour expliquer les relations dont ces documents dépendent.
Que faut-il cartographier en premier lorsque le projet n’est pas clair ?
Commencez par le problème, le groupe concerné et le résultat visé. Si ces éléments font débat, examinez-les avant de créer une carte détaillée de livrables supposés.