C’est mardi après-midi ; le chef de projet est en réunion avec le responsable de la conformité, un Product Owner et l’équipe du prestataire chargée de développer un portail patient pour un réseau hospitalier. Le service conformité exige une validation formelle d’un ensemble de contrôles pour une date d’audit fixée. Le Product Owner présente une nouvelle série de modifications demandées par les cliniciens et reçues le matin même ; il s’agit de changements substantiels, et non de simples ajustements de formulation. De son côté, le prestataire réclame un document d’exigences stabilisé pour pouvoir finaliser le développement et les tests. Chaque partie formule une demande légitime, mais ces exigences sont incompatibles entre elles. Chaque semaine, l’équipe fige les exigences pour obtenir la validation, puis les rouvre pour intégrer les retours réels des utilisateurs. La charge de retravail s’accumule, les délais de test sont comprimés et la piste d’audit devient confuse, car les décisions sont remises en question sans que les validations ne soient dûment consignées.
Avant de choisir une méthode de livraison, déterminez quel sera le premier point de défaillance du projet si aucune mesure n’est prise.
Le piège consiste à croire que l’équipe doit choisir entre rapidité et conformité. En réalité, le projet mêle deux types de travail distincts. Une partie nécessite de la traçabilité : il faut pouvoir démontrer comment une exigence a abouti à une conception, puis à une réalisation, à des tests et enfin à une approbation. Une autre partie exige un apprentissage rapide, impliquant de réviser ce qui est construit à mesure que l’on apprend des utilisateurs. Imposer un apprentissage rapide au sein d’un processus d’approbation lourd crée des goulots d’étranglement. À l’inverse, imposer la traçabilité dans un cycle rapide dépourvu de contrôles clairs entraîne des non-conformités lors des audits. Le réflexe du débutant est de demander à chacun de s’aligner et de figer le périmètre. Cela donne une impression de leadership en réduisant les tensions immédiates, mais cela provoque souvent une avalanche ultérieure de demandes de modification lorsque la réalité finit par s’imposer.
Réalité de la gestion de projet Dans un environnement réglementé, la date de l’audit ne se négocie pas. Ce qui se négocie, c’est le périmètre couvert par cette date et la manière dont les modifications transitent par les étapes d’approbation.
Lorsque l’on parle d’Agile ou de modèle en cascade (Waterfall), on fait souvent référence à un ensemble de décisions. Dans le cadre de ce cours, nous allons décomposer cet ensemble en trois leviers pratiques que vous pouvez concevoir de manière délibérée.
Le premier levier est la boucle de rétroaction : il s’agit de la fréquence à laquelle vous recueillez des retours concrets de la part des utilisateurs ou des parties prenantes pour les traduire en modifications de ce que vous construisez. Des boucles courtes favorisent un apprentissage rapide, mais génèrent également un volume accru de modifications à gérer.
Le deuxième levier est l’horizon de planification : il correspond à la durée sur laquelle vous planifiez en détail avant de vous engager dans les phases de réalisation et de test. Un horizon lointain peut accroître la prévisibilité, mais suppose que les exigences restent stables. Un horizon proche accepte l’incertitude, mais exige une implication constante des parties prenantes pour éviter que l’équipe ne travaille sur la base d’hypothèses.
Le troisième levier concerne les points de contrôle : ce sont des étapes où le travail doit satisfaire à des critères définis pour pouvoir se poursuivre. Un point de contrôle peut prendre la forme d’une approbation formelle, d’une revue de sécurité ou d’une étape préalable aux tests. Ces points réduisent les risques, mais alourdissent la gouvernance et augmentent les temps d’attente.
Mettez ces trois leviers en relation avec les résultats du projet et observez les compromis qui en découlent.