Migration ERP en environnement hybride — Retard et dépassement budgétaire
Une entreprise industrielle de taille intermédiaire lance un projet de migration vers un nouvel ERP couvrant ses sites en France, en Pologne et au Brésil. Le chef de projet a opté pour une approche hybride : une phase prédictive pour le déploiement de l'infrastructure et de la configuration de base, suivie de sprints agiles pour les modules métier. La date de mise en production est contractuellement fixée à 18 mois, sans possibilité de dérogation car elle est liée à une exigence réglementaire de traçabilité financière imposée par les autorités fiscales brésiliennes.nnÀ la fin du sprint 5, lors d'une revue de performance, le chef de projet constate des indicateurs préoccupants : l'équipe a consommé plus de budget que prévu tout en accumulant du retard. Par ailleurs, un consultant externe spécialisé en intégration fiscale brésilienne, identifié comme ressource critique sur le chemin critique, vient de notifier une indisponibilité de trois semaines pour raisons médicales. Un risque similaire avait été évoqué en phase de planification mais aucune réponse formelle n'avait été documentée.nnEn parallèle, l'équipe distribuée sur trois pays signale des difficultés de collaboration croissantes : les documents de spécifications sont échangés par email, générant des conflits de versions, et les membres brésiliens, bien que dans un fuseau horaire partagé avec les Polonais pour une heure par jour, se sentent exclus des décisions techniques prises lors des réunions matinales parisiennes.
Calculez le CPI et le SPI à la fin du sprint 5. Quelle est la situation du projet et quelle action prioritaire le chef de projet doit-il entreprendre concernant la performance ?
CPI = EV / AC = 880 000 / 1 050 000 ≈ 0,84 : le projet dépasse son budget, chaque euro dépensé ne produit que 0,84 € de valeur. SPI = EV / PV = 880 000 / 960 000 ≈ 0,92 : le projet est en retard, seulement 92 % du travail prévu a été réalisé. Le projet souffre d'une double dégradation (EV < AC et EV < PV). Avant toute action corrective (fast-tracking, ajout de ressources), le chef de projet doit identifier les causes racines du retard et du dépassement via une analyse structurée. Le fast-tracking sans diagnostic préalable risque d'amplifier les risques sur les modules d'intégration. Une fois les causes identifiées, un plan d'action ciblé doit être soumis au comité de pilotage, en évaluant les impacts sur la triple contrainte (délai, coût, qualité/périmètre).
L'indisponibilité du consultant fiscal brésilien — une ressource critique sur le chemin critique — n'avait pas fait l'objet d'une réponse documentée lors de la planification. Quelle aurait dû être la démarche correcte, et que doit faire le chef de projet maintenant ?
La démarche correcte en planification aurait été d'inscrire ce risque dans le registre des risques avec une réponse prédéfinie : par exemple, identifier et former une ressource de secours (atténuation) ou contractualiser une clause de remplacement avec le cabinet du consultant (transfert partiel). Un projet bien géré dispose de réponses planifiées pour les risques identifiés, surtout sur le chemin critique. Désormais, face à la matérialisation du risque, le chef de projet doit : (1) ajouter formellement le risque et son occurrence dans le registre des risques, (2) réévaluer les risques connexes avec l'équipe et les parties prenantes, (3) explorer en urgence les options disponibles (autre consultant, travail en parallèle sur des livrables non dépendants, révision du séquencement). L'exigence réglementaire brésilienne étant une contrainte non-négociable, le retard sur cette ressource doit être traité comme prioritaire.
L'équipe distribuée rencontre des problèmes de collaboration liés à la gestion documentaire par email et à des réunions mal adaptées aux contraintes géographiques. Quelles sont les deux actions structurelles que le chef de projet doit mettre en place pour résoudre durablement ces problèmes ?
Premièrement, concernant la gestion documentaire : le chef de projet doit mettre en place un dépôt centralisé avec un système de gestion de versions (ex. SharePoint, Confluence, ou un outil similaire). Cela élimine les conflits de versions, garantit que chaque membre travaille sur la version à jour et assure la traçabilité des modifications — condition essentielle dans un projet à contrainte réglementaire. Deuxièmement, concernant la collaboration de l'équipe distribuée : au-delà du fuseau horaire, le chef de projet doit examiner les besoins virtuels de l'équipe (outils, processus d'interaction, sentiment d'inclusion) et établir un plan de communication adapté au contexte multiculturel, définissant explicitement les canaux, fréquences et responsabilités de communication pour chaque site. Des actions de team building virtuel peuvent renforcer la cohésion. L'exclusion perçue des membres brésiliens des décisions techniques doit être adressée en restructurant les plages de réunions ou en instituant une rotation des horaires de concertation.
Plateforme e-commerce agile — Conflits de backlog et motivation d'équipe
Une start-up de retail lance le développement d'une nouvelle plateforme e-commerce en utilisant Scrum. L'équipe de 7 personnes travaille en sprints de 2 semaines. Le Product Owner, issu de la direction commerciale, modifie fréquemment les priorités du backlog en cours de sprint et a demandé à plusieurs reprises l'intégration de nouvelles fonctionnalités sans passer par le processus de priorisation formelle. Cela a provoqué trois sprints consécutifs terminés avec un taux de complétion inférieur à 60 % et une qualité dégradée des livrables.nnLe Scrum Master constate également une baisse significative de la motivation de l'équipe. Lors de la dernière rétrospective, plusieurs développeurs ont exprimé leur frustration face aux interruptions constantes et au sentiment de ne jamais terminer ce qu'ils commencent. Un développeur senior a publiquement remis en question l'utilité de plusieurs tâches du backlog en réunion d'équipe, estimant qu'elles n'apportaient aucune valeur au client final.nnPar ailleurs, à la 8e itération, le Product Owner insiste pour intégrer en urgence un module de facturation conforme à une nouvelle directive fiscale européenne entrant en vigueur dans 6 semaines, sous peine d'amende. Cette demande arrive en milieu de sprint alors que l'équipe est mobilisée sur le moteur de recommandation produit.
Le Product Owner tente d'intégrer une nouvelle fonctionnalité en milieu de sprint. Quelle est la réponse correcte de l'équipe Scrum, et comment le Scrum Master doit-il gérer structurellement les modifications fréquentes de priorités ?
Selon les principes Scrum, le sprint backlog est verrouillé au démarrage du sprint pour garantir stabilité et prévisibilité. La demande du Product Owner doit être ajoutée au product backlog et priorisée pour les sprints futurs, pas intégrée en cours de sprint. Le Scrum Master doit protéger l'équipe de ces interruptions en rappelant ce principe au Product Owner. Pour résoudre structurellement le problème de modifications fréquentes, le Scrum Master doit demander au Product Owner de prioriser le backlog avec l'équipe lors des séances de backlog refinement, en garantissant une vision partagée et transparente. Cela crée un processus formel de gestion des changements : toute nouvelle demande est ajoutée au backlog, estimée, priorisée collectivement, puis planifiée dans un sprint futur. Cette gouvernance évite la surcharge et restaure la prévisibilité des sprints.
La directive fiscale européenne impose une contrainte réglementaire non négociable dans 6 semaines. Comment le chef de projet doit-il traiter cette exigence par rapport aux autres items du backlog, et quelles sont les conséquences d'un non-respect ?
Les exigences réglementaires obligatoires constituent des contraintes prioritaires absolues en gestion de projet : leur non-respect génère des sanctions financières (45 000 € d'amende dans ce cas), voire des responsabilités légales dépassant tout objectif commercial. Le chef de projet doit donc placer le module de conformité fiscale en tête du product backlog, au-dessus de tout autre développement fonctionnel, y compris le moteur de recommandation. Cette priorisation doit être documentée et validée avec le sponsor et le Product Owner. Si 6 semaines représentent 3 sprints de 2 semaines, le chef de projet doit s'assurer que le module peut être livré dans ce délai, quitte à retirer temporairement d'autres items du backlog pour libérer la capacité de l'équipe. Ignorer cette contrainte pour livrer des fonctionnalités commerciales constituerait une faute grave de gestion.
Face à la baisse de motivation de l'équipe et à la remise en question publique de certaines tâches par un développeur senior, quelles actions le Scrum Master doit-il entreprendre pour restaurer l'engagement et la performance ?
Deux actions complémentaires s'imposent. D'abord, organiser une rétrospective dédiée pour identifier collectivement les causes profondes de la démotivation : les interruptions fréquentes, le sentiment d'inachèvement, la déconnexion perçue entre les tâches et la valeur client sont des signaux sérieux. La rétrospective est l'espace agile conçu précisément pour identifier ces obstacles et co-construire des solutions d'amélioration continue. Ensuite, concernant la remise en question publique par le développeur senior, le Scrum Master doit engager une discussion ouverte avec l'équipe pour examiner les préoccupations soulevées et ajuster le plan si nécessaire. En agilité, la priorité est la valeur client : si des tâches n'apportent pas de valeur réelle, elles doivent être questionnées et potentiellement retirées du backlog. Autonomiser l'équipe pour améliorer ses processus — plutôt que d'imposer une cadence forcée — est le levier agile fondamental pour restaurer durablement la performance.
Projet de construction hospitalière — Clôture chaotique et valeur métier non réalisée
Un établissement hospitalier public mandate un chef de projet pour piloter la construction et l'équipement d'une nouvelle aile de soins intensifs. Le projet, d'une durée planifiée de 24 mois, mobilise des équipes de travaux, des fournisseurs d'équipements médicaux et des équipes informatiques pour l'intégration du système de monitoring des patients. Une approche prédictive classique a été adoptée, avec un plan de management du projet validé en phase d'initialisation.nnÀ l'approche de la clôture, plusieurs problèmes surgissent simultanément. Un fournisseur d'équipements soumet une facture en retard correspondant à des livraisons effectuées au mois 18, ce qui fait augmenter les coûts réels et retarde le transfert aux opérations hospitalières. Par ailleurs, lors de l'atelier de clôture, le directeur médical — sponsor du projet — constate que l'aile a bien été livrée conformément aux spécifications techniques, mais que les équipes soignantes n'ont pas été formées aux nouveaux équipements et que les gains de capacité d'accueil initialement prévus ne sont pas au rendez-vous. Le plan de réalisation des bénéfices n'a jamais été revu depuis sa rédaction initiale.nnEnfin, durant l'exécution, un sous-traitant en génie civil avait identifié oralement un risque structurel lié aux sols argileux, mais ce risque n'avait jamais été formellement inscrit au registre des risques. Des travaux de renforcement imprévus ont finalement été nécessaires, générant un surcoût.
La facture tardive du fournisseur a perturbé la clôture du projet. Quelle pratique de gestion des coûts aurait dû être appliquée tout au long du projet pour éviter cette situation, et que doit faire le chef de projet face à cette situation lors de la clôture ?
Le chef de projet aurait dû appliquer un suivi régulier et continu de tous les travaux et coûts du projet, en comparant systématiquement les coûts réels (AC) aux coûts planifiés, et en réclamant proactivement les factures aux fournisseurs selon l'échéancier contractuel. Un suivi uniquement en fin de projet laisse passer des anomalies de facturation indétectables jusqu'à la clôture. Cette pratique inclut la révision périodique du registre des engagements et des contrats fournisseurs pour s'assurer qu'aucune facture n'est en suspens. Face à la situation actuelle, le chef de projet doit documenter l'écart dans les rapports de clôture, analyser l'impact sur le budget final, et engager une discussion avec le fournisseur pour clarifier les modalités de paiement tout en protégeant les intérêts de l'organisation cliente.
Le sponsor constate que la valeur métier attendue (les 18 lits supplémentaires opérationnels) n'a pas été réalisée malgré la livraison technique conforme. Quel document doit être revu en priorité et quelles leçons structurelles ce cas illustre-t-il ?
Le chef de projet doit revoir en priorité le plan de réalisation des bénéfices avec les parties prenantes. Ce document, distinct du plan de management du projet, définit comment identifier, mesurer et suivre les bénéfices attendus après la clôture. Il précise les conditions de réalisation de la valeur (ici : formation des équipes, mise en service progressive, protocoles opérationnels), les responsables et les indicateurs de mesure. Le fait qu'il n'ait jamais été mis à jour depuis sa rédaction initiale illustre une erreur fréquente : confondre la livraison des livrables techniques avec la réalisation de la valeur métier. Un projet peut livrer tous ses livrables conformément aux spécifications et ne pas générer la valeur attendue si le plan de transition vers les opérations et la gestion du changement organisationnel sont négligés. Le chef de projet aurait dû réviser ce plan régulièrement et s'assurer que les conditions de réalisation des bénéfices (formation, adoption) étaient intégrées dans le périmètre du projet.
Le risque structurel lié aux sols argileux avait été identifié oralement mais n'avait pas été enregistré. Quelles sont les deux défaillances de gestion des risques identifiables dans ce cas, et quelle aurait dû être la démarche correcte ?
Deux défaillances majeures sont identifiables. Premièrement, un risque identifié par un acteur clé (le sous-traitant en génie civil) n'a pas été ajouté au registre des risques, privant l'équipe de la possibilité de planifier une réponse formelle. La gestion des risques est un processus itératif et continu : tout nouveau risque identifié, même oralement, doit être formalisé, analysé et documenté. Deuxièmement, l'absence de réponse planifiée a transformé ce risque en problème réel (surcoût de 340 000 €), illustrant la différence entre un risque (incertitude future) et un problème (fait accompli coûteux). La démarche correcte aurait été : (1) lors de l'identification orale par le sous-traitant, le chef de projet devait immédiatement ajouter ce risque au registre des risques ; (2) réévaluer le risque avec l'équipe technique et les parties prenantes compétentes ; (3) planifier une réponse appropriée — par exemple, une analyse géotechnique complémentaire (atténuation) ou la constitution d'une réserve pour aléas. Cette démarche aurait permis d'anticiper le surcoût et de le budgéter plutôt que de le subir en fin de projet.
Déploiement d'une application RH multi-équipes — Intégration et ressources critiques
Un groupe de services financiers confie à un chef de projet le déploiement d'une application RH centralisée devant remplacer cinq systèmes legacy utilisés dans autant de pays européens. Cinq équipes agiles travaillent en parallèle sur des modules distincts (paie, congés, recrutement, performance, reporting). Les équipes ont été constituées avec des experts fonctionnels locaux dont certains maîtrisent des savoir-faire techniques très spécifiques aux législations nationales.nnÀ mi-parcours du programme, lors de la phase d'intégration des modules, de nombreux problèmes de compatibilité et d'incompatibilités de données surgissent entre les livrables des différentes équipes. Certains champs de données ne respectent pas les formats convenus, des APIs internes ont été modifiées sans notification inter-équipes, et les tests d'intégration révèlent un taux de défauts élevé. La pression sur le calendrier s'intensifie car la date de déploiement en production coïncide avec l'ouverture de la période de paie annuelle.nnPar ailleurs, un expert en droit du travail allemand — dont les validations sont nécessaires pour trois modules sur le chemin critique — est le seul détenteur d'un savoir-faire réglementaire critique. Son absence ou sa surcharge représente un risque identifié de goulot d'étranglement. Un membre de l'équipe a également signalé des difficultés à maîtriser le nouveau système de mapping de données, ralentissant la livraison d'un livrable critique.
Un taux de défauts de 38 % sur les interfaces lors des tests d'intégration à mi-parcours révèle un problème systémique. Quelle pratique préventive aurait dû être mise en place dès le début du programme, et comment le chef de projet doit-il prioriser les actions correctives maintenant ?
La pratique préventive fondamentale qui aurait dû être mise en place est l'intégration continue et fréquente entre les équipes. En faisant intégrer et tester les livrables de manière régulière (idéalement à chaque sprint, voire plusieurs fois par semaine), les incompatibilités auraient été détectées immédiatement plutôt que de s'accumuler jusqu'à la phase d'intégration finale. Des Scrum of Scrums ou une équipe d'intégration dédiée auraient également permis de synchroniser les interfaces entre les cinq équipes. Face à la situation actuelle, le chef de projet doit : (1) utiliser un diagramme de Pareto pour identifier les 20 % de causes génèrant 80 % des défauts d'intégration et concentrer les efforts correctives sur ces causes prioritaires ; (2) imposer un gel des APIs et interfaces partagées, toute modification devant suivre un processus de gestion de configuration formalisé ; (3) organiser des sessions d'intégration intensive inter-équipes dans les prochaines semaines, en priorisant les modules sur le chemin critique liés à la paie (contrainte de la période annuelle).
L'expert en droit du travail allemand représente un goulot d'étranglement critique sur le chemin critique. Quelles stratégies le chef de projet doit-il mettre en place pour gérer ce risque de ressource unique, et comment organiser le partage du savoir-faire dans l'équipe ?
Face à une ressource spécialisée rare et critique sur le chemin critique, la stratégie d'atténuation appropriée est d'identifier et de former des ressources de secours pour réduire la dépendance à un expert unique. Concrètement, le chef de projet doit : (1) organiser des sessions de partage de connaissances entre cet expert et d'autres membres de l'équipe capables d'assimiler une partie de son savoir-faire réglementaire — cela réduit le goulot sans perturber la structure organisationnelle ; (2) planifier les validations de cet expert de manière à optimiser son temps disponible, en regroupant les revues et en lui soumettant des livrables complets plutôt que fragmentés ; (3) documenter formellement les critères de conformité réglementaire allemande de sorte qu'ils soient exploitables indépendamment de sa présence exclusive. Si le risque de surcharge ou d'indisponibilité est élevé, un contrat avec un cabinet juridique externe spécialisé peut servir de ressource de secours contractualisée (transfert partiel du risque). Ces actions doivent être inscrites dans le registre des risques avec une réponse planifiée documentée.
Un membre de l'équipe rencontre des difficultés avec le système de mapping de données, retardant un livrable critique à 10 semaines de la production. Comment le chef de projet doit-il gérer cette situation, et comment cela s'inscrit-il dans une approche globale de gestion des ressources humaines ?
Face à un membre de l'équipe en difficulté sur une compétence technique bloquante pour un livrable critique, la meilleure action immédiate est d'affecter une ressource expérimentée pour le soutenir. Cette approche remplit deux fonctions simultanément : réduire le risque de retard sur le livrable critique en apportant l'expertise manquante, et favoriser un transfert de compétences permettant au membre de développer sa maîtrise du système pour les livrables futurs. Le chef de projet doit d'abord avoir une discussion individuelle avec ce membre pour comprendre précisément la nature du blocage (manque de formation, documentation insuffisante, complexité sous-estimée) avant de déterminer le niveau de support nécessaire. Si le délai restant (10 semaines) ne permet pas une montée en compétence autonome sur ce livrable, l'affectation d'un expert en binôme est la solution la plus efficace. Cette approche illustre le principe PMBOK 7 de coaching et mentorat : plutôt que de remplacer le membre ou d'escalader immédiatement, le chef de projet favorise le développement des capacités de l'équipe tout en protégeant les objectifs du projet.
Lancement d'un produit FinTech — Gouvernance des changements et indicateurs financiers
Une société FinTech développe une application de gestion de portefeuille d'investissement destinée aux particuliers. Le projet, d'une durée de 12 mois, est géré avec une approche hybride : une architecture technique définie en phase prédictive, suivie de développements fonctionnels en sprints bimensuels. Le sponsor a imposé une date de lancement fixe liée à une fenêtre réglementaire d'agrément de l'Autorité des Marchés Financiers (AMF), avec un budget ferme approuvé par le conseil d'administration.nnEn cours d'exécution, le chef de projet fait face à plusieurs demandes simultanées : le responsable marketing demande l'ajout d'un module de gamification non prévu initialement, estimant qu'il augmentera l'acquisition client ; le département juridique impose en urgence l'intégration de nouvelles obligations KYC (Know Your Customer) issues d'une directive européenne révisée, sous peine de refus d'agrément AMF ; et un client institutionnel pilote demande des livrables intermédiaires plus fréquents pour valider l'ergonomie de l'interface, ce qui impacte le rythme des sprints. Par ailleurs, le sponsor envisage de réduire le budget de 15 % pour financer un autre projet stratégique.nnL'équipe est composée de 9 personnes dont 3 experts en conformité réglementaire. La performance à mi-projet montre un CPI de 1,05 et un SPI de 0,88, signalant une maîtrise des coûts mais un retard croissant sur le calendrier.
Le chef de projet fait face à trois demandes concurrentes : module de gamification, obligations KYC réglementaires, et livrables intermédiaires plus fréquents. Comment doit-il prioriser ces demandes et quel processus doit-il suivre pour chacune ?
La priorisation doit suivre une logique de contraintes non-négociables. Premièrement, les obligations KYC issues de la directive européenne constituent des exigences réglementaires obligatoires dont le non-respect entraîne le refus d'agrément AMF — une pénalité dévastatrice (6 mois de retard et interdiction de commercialisation). Ces exigences doivent être traitées en priorité absolue, intégrées immédiatement dans le backlog en tête de liste, et planifiées dans les prochains sprints sans compromis. Deuxièmement, la demande de livrables intermédiaires plus fréquents du client pilote est une demande de changement légitime qui doit être évaluée selon son impact sur le calendrier, les coûts et les ressources avant toute décision. Le chef de projet doit analyser cet impact, puis adapter le plan de communication et de livraison — potentiellement en ajustant la cadence des sprints ou en organisant des démos ciblées sans modifier le contenu des sprints. Cette demande doit faire l'objet d'une décision formelle du comité de pilotage. Troisièmement, le module de gamification est une amélioration commerciale non réglementaire : avec un SPI de 0,88 indiquant déjà un retard, ajouter du périmètre non essentiel aggraverait la situation. Ce module doit être placé dans le backlog pour une version ultérieure et la décision formalisée via le processus de gestion des changements.
Le sponsor envisage une réduction budgétaire de 15 %. Avec un CPI de 1,05 et un SPI de 0,88, quelle analyse le chef de projet doit-il présenter au sponsor pour éclairer cette décision ?
Le chef de projet doit d'abord refuser de subir une réduction budgétaire sans analyse des impacts : les trois contraintes (coût, délai, qualité/périmètre) sont interdépendantes. L'analyse à présenter au sponsor doit couvrir trois dimensions. Sur les coûts : le CPI de 1,05 démontre déjà une efficacité budgétaire supérieure à la normale — le projet génère 1,05 € de valeur pour chaque euro dépensé. Réduire le budget de 15 % alors que l'équipe performe efficacement risque de forcer des arbitrages sur des livrables critiques. Sur le calendrier : le SPI de 0,88 indique un retard de 12 % sur le calendrier. Une réduction budgétaire (potentiellement par réduction des ressources) aggraverait ce retard, mettant en péril la date de dépôt d'agrément AMF — une contrainte absolue. Sur le ROI et les bénéfices : si l'agrément AMF est retardé de 6 mois, la perte commerciale (revenus manqués, part de marché) dépasse largement les économies de 15 % visées. Le chef de projet doit présenter cette analyse coûts-bénéfices au comité de pilotage pour une décision éclairée, en proposant des alternatives : réduction de périmètre optionnel (ex. report du module de gamification) plutôt que réduction budgétaire directe.
L'approche hybride a été choisie pour ce projet. Quels éléments du contexte justifient ce choix, et quelles mesures spécifiques le chef de projet doit-il prendre pour assurer la cohérence entre la phase prédictive et les sprints agiles face aux nouvelles exigences KYC ?
L'approche hybride se justifie par deux caractéristiques concomitantes du projet : une date fixe non négociable (agrément AMF) et des exigences fonctionnelles évolutives (comportements utilisateurs, réglementation dynamique). La phase prédictive permet de fixer l'architecture technique, les contraintes réglementaires de base et le cadre contractuel — éléments stables nécessitant de la rigueur séquentielle. Les sprints agiles permettent d'intégrer les retours du client pilote, de s'adapter aux changements réglementaires (comme les nouvelles obligations KYC) et de prioriser dynamiquement les fonctionnalités selon la valeur métier. Face aux nouvelles exigences KYC, la cohérence entre les deux phases exige : (1) d'évaluer si les nouvelles obligations KYC impactent l'architecture technique définie en phase prédictive — si oui, une demande de changement formelle sur le plan de management du projet est nécessaire ; (2) d'intégrer les exigences KYC dans le product backlog avec la priorité maximale, en collaboration avec les 3 experts en conformité réglementaire de l'équipe ; (3) de s'assurer que la gestion de configuration est appliquée rigoureusement : toute modification de l'architecture technique sous-jacente doit être documentée, versionnée et validée pour éviter les incompatibilités avec les sprints en cours. La simulation Monte Carlo pourrait être utilisée pour réévaluer quantitativement l'impact de ces nouvelles exigences sur la date de livraison finale.