Analyse des hypothèses et des contraintes

Objectif

L'analyse vérifie que le plan d'un projet repose sur des faits qui tiendront. Tout projet est conçu sur des hypothèses et dans des contraintes. Elles sont souvent déjà intégrées à la référence de base du périmètre et aux estimations. Une estimation de six semaines pour la spécification suppose trois analystes disponibles. Si deux seulement le sont, le planning est faux depuis sa signature.

L'analyse indique quelles hypothèses deviennent des menaces et quelles contraintes l'équipe peut renégocier. Le registre des risques reçoit une ligne par menace ou par opportunité trouvée. Sur cette base, l'équipe refait une estimation, renégocie une contrainte avec le mandant ou accepte une limite du projet.

Le PMBOK Guide cite aussi la technique pour planifier l'engagement des parties prenantes. L'équipe y teste de la même façon les hypothèses sur la disponibilité ou le soutien d'une partie prenante.

Usage

Quand l'utiliser

• Charte de projet ou business case signé: tester les hypothèses du mandat avant l'atelier d'identification des risques.
• Estimation à engager: lister les hypothèses sous chaque chiffre avant de promettre un budget ou une date.
• Fin de phase: revoir les hypothèses de la phase écoulée avant de libérer la suivante.
• Contexte qui change: une loi en révision ou un fournisseur remplacé rouvre les hypothèses qui en dépendent.
• Interfaces avec des systèmes tiers: vérifier ce que le projet suppose des données, des formats et des délais de chaque propriétaire.
• Plan d'engagement des parties prenantes: tester ce que le plan suppose de leur disponibilité et de leur soutien.
• Équipe répartie sur plusieurs sites: un journal partagé suffit. Chaque propriétaire y vérifie ses hypothèses sans réunion.

Quand ne pas l'utiliser

• Événement déjà survenu: c'est un problème. Il entre au journal des problèmes que tient le suivi des items.
• Recherche d'idées nouvelles: pour renverser une hypothèse et produire des options, passer à la pensée créative.
• Énoncé chiffré à vérifier sur des données: la formulation et test d'hypothèses le tranche sur un échantillon.

Description

Hypothèse, contrainte et journal des hypothèses

Le PMBOK Guide définit l'hypothèse comme un facteur du processus de planification considéré comme vrai, réel ou certain sans preuve ni démonstration. La contrainte est un facteur limitant qui affecte l'exécution d'un portefeuille, d'un programme, d'un projet ou d'un processus. Cette définition dépasse le triangle délai, coût et périmètre. Une loi, un contrat, une norme technique ou une décision du mandant sont des contraintes.

Le BABOK Guide traite le même couple dans le business case. Il y appelle les hypothèses des faits convenus qui peuvent influencer l'initiative. Les contraintes y restreignent les variantes. Pour le BABOK Guide, convenir de ces facteurs et les documenter donne aux parties prenantes des attentes réalistes et une compréhension commune. Une hypothèse convenue reste non prouvée au sens du PMBOK Guide. L'accord partage la croyance sans la vérifier.

Le PMBOK Guide décrit le journal des hypothèses comme le document du projet qui consigne toutes les hypothèses et toutes les contraintes. L'équipe y ajoute les nouvelles. Elle met à jour le statut des existantes ou les clôt. Les contraintes stratégiques et opérationnelles apparaissent dans le business case avant le lancement, puis passent dans la charte de projet. Les hypothèses détaillées naissent pendant le projet lorsque l'équipe définit les spécifications techniques, les estimations, les activités du planning et les risques.

Le processus Lancer le projet ou la phase produit le journal. Les processus de planification, d'estimation et de gestion des risques le lisent et y reportent leurs mises à jour.

En approche classique, HERMES 2022 place les estimations dans le mandat d'exécution et dans le plan de gestion du projet avec leur précision et leurs réserves. HERMES demande de documenter les hypothèses qui fondent ces estimations: la gouvernance exige cette transparence. HERMES ne définit pas de journal des hypothèses. Le journal du PMBOK Guide remplit cette exigence.

D'où viennent les menaces et les opportunités?

Les menaces peuvent venir des hypothèses inexactes, instables, incohérentes ou incomplètes. Les opportunités peuvent venir des contraintes: lever ou assouplir un facteur limitant ouvre un gain. Le processus Identifier les risques reconnaît les risques négatifs et positifs.

Le PMBOK Guide définit la technique sans en donner les étapes. Les étapes qui suivent appliquent sa définition dans l'ordre.

1. Rassembler les hypothèses et les contraintes

L'équipe relit le business case, la charte de projet, la référence de base du périmètre et la base des estimations. Elle note au journal chaque hypothèse et chaque contrainte avec sa source et son propriétaire. Beaucoup d'hypothèses sont implicites. Une estimation suppose une équipe, une date de livraison et un rythme de décision que personne n'a écrits. L'analyste les fait dire en entretien à la personne qui a produit le chiffre. L'analyse documentaire les repère dans les contrats et les procès-verbaux.

L'analyste écrit chaque hypothèse comme un fait vérifiable: qui fait quoi, en quelle quantité, pour quand. «Les utilisateurs seront disponibles» ne se teste pas. «Le service de l'urbanisme détache deux personnes deux jours par semaine pour les tests d'acceptation (UAT) dès février» se teste.

Le journal sépare les hypothèses des contraintes parce que la suite diffère. Quelqu'un pose la contrainte: le mandant, le législateur, un contrat. L'équipe tient l'hypothèse pour vraie. Une date annoncée par le mandant passe souvent pour une contrainte. L'équipe demande d'où elle vient. Une décision du Conseil d'État est une contrainte. L'espoir d'un chef de service est une hypothèse à tester comme les autres.

2. Tester chaque hypothèse

Le PMBOK Guide nomme les défauts d'une hypothèse sans les définir. Chacun se teste par une question. Les questions et les exemples du tableau sont une lecture de praticien.

L'analyste vérifie auprès de la source. Un courriel à l'éditeur tranche plus vite qu'une heure de discussion en salle. L'équipe clôt au journal une hypothèse qui passe les quatre tests et y note sa source et la date de la vérification. Une hypothèse qui échoue à un test devient une menace candidate.

L'hypothèse la moins testée est souvent celle de la personne la plus haut placée. Contredire en séance la date du mandant demande une sécurité psychologique que toutes les équipes n'ont pas. L'analyste pose alors la question de la source par écrit, ligne par ligne, à chaque propriétaire.

3. Écrire les menaces au registre

Comme pour toute ligne du registre, l'équipe écrit chaque menace en cause, événement et conséquence. La cause est le défaut constaté. L'événement: l'hypothèse se révèle fausse. La conséquence nomme l'objectif touché.

L'hypothèse H-01 devient la menace R-15: «En raison de l'absence d'engagement écrit de l'éditeur C, sa spécification d'interface peut arriver après le 30 septembre, ce qui retarderait le test d'intégration de six semaines.» Recopier l'hypothèse au registre ne suffit pas. «L'éditeur livre au 30 septembre» décrit le plan. La ligne du registre décrit l'événement qui contredit le plan. La menace reprend la date de l'hypothèse comme déclencheur. Le propriétaire de R-15 agit si la spécification de l'éditeur C manque au 30 septembre.

Les deux lignes se citent l'une l'autre. Quand l'éditeur confirme sa date, l'équipe clôt les deux ensemble. La probabilité et l'impact relèvent de l'analyse des risques et de la matrice probabilité-impact. L'équipe choisit la réponse avec les stratégies de réponse aux risques.

4. Interroger chaque contrainte

Pour chaque contrainte, l'équipe pose une question: peut-on lever ou assouplir la limite? Seule la personne ou l'instance qui a posé une contrainte peut la lever. L'équipe note donc qui l'a fixée et pour quel motif. Le mandant a décidé que toutes les communes basculeraient le même jour pour éviter deux circuits parallèles. L'équipe peut en discuter avec lui. Un plafond voté avec le budget cantonal ne bouge pas avant le budget suivant.

Si la réponse est oui, l'équipe écrit une opportunité au registre: ce que le projet gagnerait si la limite tombait. La contrainte C-01 devient l'opportunité R-19: «Comme 9 communes reçoivent déjà les plans en PDF, elles peuvent ouvrir le dossier numérique trois mois avant les autres si le mandant assouplit la date unique, ce qui donnerait trois mois de retours d'utilisation avant l'ouverture dans les 12 autres communes.» L'analyse des opportunités prend la suite. Si la réponse est non, la contrainte reste au journal comme limite du projet.

Une équipe qui traite toutes les contraintes comme intangibles applique la moitié de la technique.

5. Tenir le journal à jour

Selon le PMBOK Guide, l'identification des risques est itérative parce que certains risques n'apparaissent qu'en cours de projet. Le processus Surveiller les risques met aussi le journal des hypothèses à jour. Chaque ligne du journal porte le statut «ouverte» ou «close». L'équipe revoit le journal à chaque revue des risques et à chaque fin de phase. Elle ajoute les hypothèses nouvelles, clôt celles qui sont confirmées et teste à nouveau celles dont le contexte a changé.

Quand une hypothèse se révèle fausse, l'équipe clôt sa ligne au journal. La ligne du registre passe au statut «réalisé» et l'équipe ouvre un problème au journal des problèmes. Une hypothèse sans propriétaire ni date de vérification reste ouverte jusqu'à la clôture du projet. Personne ne la teste. À la clôture, le journal part aux leçons apprises: les hypothèses tombées montrent ce que le projet suivant doit vérifier en premier.

Les techniques voisines

En français, le mot «hypothèse» désigne aussi l'énoncé que teste la statistique. La formulation et test d'hypothèses confronte un énoncé chiffré à un échantillon de données. L'analyste vérifie l'hypothèse de planification auprès de sa source: un éditeur, un service, un contrat.

La pensée créative connaît le renversement des hypothèses. Elle part aussi d'une liste d'hypothèses, inverse chacune et discute les idées que l'inversion produit. L'analyse des hypothèses et des contraintes cherche si une hypothèse tiendra et quel risque suit si elle tombe.

Le PMBOK Guide range la technique dans le processus Identifier les risques aux côtés de l'analyse SWOT, de l'analyse des causes racines, du brainstorming et des listes de contrôle. Le brainstorming produit des risques à partir de l'expérience des participants. L'analyse des hypothèses et des contraintes les tire du plan.

Considérations IA

Un modèle de langage lit une charte de projet, un business case et la base des estimations. Il en extrait les hypothèses implicites: les verbes au futur, les dates sans source, les ressources supposées disponibles. Il les réécrit en faits vérifiables et propose pour chacune les questions des quatre défauts. Il compare les documents et signale les incohérences, par exemple un nombre d'analystes qui diffère entre la charte et l'estimation. Il rédige une menace en cause, événement et conséquence à partir d'une hypothèse qui échoue.

Le modèle ne sait pas si une hypothèse est vraie. Il ignore ce que l'éditeur a promis au téléphone et ce que le Grand Conseil votera. L'analyste vérifie l'exactitude auprès de la source et estime la stabilité avec ceux qui connaissent le contexte. Le modèle produit aussi des hypothèses plausibles et génériques qui gonflent le journal. Une ligne proposée y entre quand un propriétaire la reconnaît. Le journal nomme des fournisseurs, des personnes et des engagements contractuels. Il part vers un service d'IA externe si l'organisation l'autorise. Dans une administration suisse, le droit de la protection des données applicable et le lieu d'hébergement en décident.

Exemples

Un canton romand dématérialise les demandes de permis de construire. L'équipe analyse le journal des hypothèses à la fin de l'Initialisation. L'extrait montre le journal après l'analyse.

H-05 et C-02 ne produisent aucune ligne au registre. L'équipe clôt H-05 au journal avec sa source et sa date. C-02 reste ouverte parce qu'elle limite les coûts jusqu'au budget suivant. Un journal analysé garde ces lignes: elles montrent ce que l'équipe a vérifié et ce qu'elle a renoncé à renégocier.

Visualisations

Le journal des hypothèses est un tableau: une ligne par hypothèse ou par contrainte, avec sa source, le résultat de l'analyse, la ligne du registre qu'elle a produite et son statut. Un schéma suit les deux chemins de la technique, des hypothèses aux menaces et des contraintes aux opportunités. Un second montre les statuts d'une ligne du journal jusqu'à sa clôture. Le tableau des défauts donne une question par défaut.

Coût

Outils

Un tableur suffit pour un journal de quelques dizaines de lignes: une colonne par défaut testé, une liste déroulante pour le statut («ouverte», «close»), une colonne pour la référence au registre. Un outil de suivi comme Jira ou Azure DevOps gère hypothèses et risques comme deux types de tickets liés. Il historise chaque changement de statut et notifie le propriétaire. Beaucoup d'équipes tiennent un seul journal pour les risques, les hypothèses, les problèmes et les dépendances. On l'appelle souvent journal RAID. Ce format garde la ligne de l'hypothèse et celle de la menace dans le même fichier. Pour une administration suisse, le lieu d'hébergement des données guide le choix dès que le journal nomme des fournisseurs ou des personnes.

Sources

• Project Management Institute, A Guide to the Project Management Body of Knowledge (PMBOK Guide), 8^e éd., PMI: le processus Identifier les risques et ses outils (§2.7.2.2, Figure 2-49); les outils de la planification de l'engagement des parties prenantes (§2.5.2.2, Figure 2-34); le journal des hypothèses (Section 4, entrée Assumption log); la définition de la technique (Section 5, entrée Assumption and constraint analysis); les définitions de l'hypothèse et de la contrainte (Glossaire).
• International Institute of Business Analysis, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.7 Business Cases: l'élément Assumptions, Risks, and Constraints.
• Chancellerie fédérale, HERMES 2022, Manuel de référence Gestion de projet: les hypothèses qui fondent les estimations (7.4.5.3 Planification de la création de la solution en mode classique, passage «Exactitude de la planification dans le déroulement du projet»).