MARKETING & COMMUNICATION
METIER-CHEF-DE-PROJET-PLATEFORMES-DIGITAL · SÉANCE 1 · BLOC RNCP

Chef(fe) de projet plateformes / digital

Découvrir le métier — environnement, missions et compétences clés

Niveau
B2 — Technicien
Trimestre
T1 · Jan-Mars 2027
Bloc RNCP
RPMS · BC02
Made in
Groupe École de Commerce de Lyon
Bienvenue dans ce cours dédié au métier de chef de projet digital. Durant ces modules, vous allez découvrir en détail les responsabilités, les outils et les compétences requises pour exercer ce rôle au quotidien dans une organisation. Vous êtes sur le point de vous projeter dans un métier clé de la transformation numérique : cadrer des initiatives, animer des équipes, livrer des solutions, mesurer le succès. Ce que vous allez apprendre est directement transférable dans vos premiers contrats en alternance ou en CDI.
Couverture
Chef(fe) de projet plateformes / digital — Découvrir le métier — environnement, missions et compétences clés
Bienvenue dans ce cours dédié au métier de chef de projet digital. Durant ces modules, vous allez découvrir en détail les responsabilités, les outils et les compétences requises pour exercer ce rôle au quotidien dans une organisation. Vous êtes sur le point de vous projeter dans un métier clé de la transformation numérique : cadrer des initiatives, animer des équipes, livrer des solutions, mesurer le succès. Ce que vous allez apprendre est directement transférable dans vos premiers contrats en alternance ou en CDI.

Le plan du cours

Introduction

Trois parties pour maîtriser le métier de chef de projet digital.

1
Découvrir le métier
  • Qui est un chef de projet digital ?
  • L'environnement professionnel
  • Les compétences clés requises
2
Exercer le métier au quotidien
  • Cadrer un projet digital
  • Piloter en mode agile
  • Recetter et mettre en production
3
Performer et progresser
  • Mesurer et rapporter la performance
  • Gérer les crises de projet
  • Évoluer dans le digital
Ce cours s'organise en trois temps forts. D'abord, nous découvrirons ensemble qui est un chef de projet digital, son environnement professionnel et les compétences clés. Ensuite, nous détaillerons comment exercer ce métier au quotidien : cadrer un projet, piloter en mode agile, recetter et mettre en production. Enfin, nous explorerons comment performer dans le rôle et évoluer dans votre carrière digital.
Plan du cours
Le plan du cours
Ce cours s'organise en trois temps forts. D'abord, nous découvrirons ensemble qui est un chef de projet digital, son environnement professionnel et les compétences clés. Ensuite, nous détaillerons comment exercer ce métier au quotidien : cadrer un projet, piloter en mode agile, recetter et mettre en production. Enfin, nous explorerons comment performer dans le rôle et évoluer dans votre carrière digital.

Le passé éclaire l'avenir

Timeline

Vingt ans d'évolution du rôle de chef de projet digital.

2010
Émergence du rôle
Les premières méthodes agiles gagnent les entreprises
2015
Explosion du digital
Transformation numérique des PME et ETI
2018
Professionnalisation
Certifications Scrum Master et Product Owner généralisées
2022
Hybridation des méthodes
Approches Scrum + Kanban + mode traditionnel coexistent
2026
Ère de la maturité
Chef de projet digital : rôle structurant dans les organisations
Le métier de chef de projet digital n'existe que depuis deux décennies. En 2010, les premières méthodes agiles s'imposaient face aux approches en cascade. En 2015, la transformation numérique fait exploser la demande de chefs de projet. En 2018, les certifications Scrum Master et Product Owner deviennent des standards. Depuis 2022, nous voyons une hybridation des approches : agile, Kanban, et mode traditionnel coexistent. En 2026, le métier a maturé : c'est un rôle structurant et respecté dans les organisations de toutes tailles.
Repères
Le passé éclaire l'avenir
Le métier de chef de projet digital n'existe que depuis deux décennies. En 2010, les premières méthodes agiles s'imposaient face aux approches en cascade. En 2015, la transformation numérique fait exploser la demande de chefs de projet. En 2018, les certifications Scrum Master et Product Owner deviennent des standards. Depuis 2022, nous voyons une hybridation des approches : agile, Kanban, et mode traditionnel coexistent. En 2026, le métier a maturé : c'est un rôle structurant et respecté dans les organisations de toutes tailles.
Partie 1 sur 3
1
Découvrir le métier
METIER-CHEF-DE-PROJET-PLATEFORMES-DIGITAL · Séance 1 · Chef(fe) de projet plateformes / digital — Découvrir le méti...

Définition

Vocabulaire
Terme du cours
Chef de projet digital
Du français « chef » (responsable) et latin « proiectus » (jeté en avant) ; « digital » du latin « digitus » (doigt, puis numérique).
Professionnel responsable du cadrage, du pilotage et de la livraison d'une initiative digitale ou informatique. Il assure la faisabilité technique, le respect du périmètre, des délais et du budget, tout en fédérant une équipe pluridisciplinaire vers un objectif commun.
Un chef de projet digital est un pilote d'initiatives. Son rôle consiste à transformer une demande métier en solution concrète, livrée à temps et dans le budget. Il n'est pas technicien au sens strict, mais il doit comprendre les enjeux techniques, commerciaux et humains d'un projet. Contrairement à un manager hiérarchique classique, il n'a souvent aucune autorité directe ; il influence par la clarté du message, la qualité du pilotage et la légitimité de sa vision.
Définition
Définition : Chef de projet digital
Un chef de projet digital est un pilote d'initiatives. Son rôle consiste à transformer une demande métier en solution concrète, livrée à temps et dans le budget. Il n'est pas technicien au sens strict, mais il doit comprendre les enjeux techniques, commerciaux et humains d'un projet. Contrairement à un manager hiérarchique classique, il n'a souvent aucune autorité directe ; il influence par la clarté du message, la qualité du pilotage et la légitimité de sa vision.
Source : Scrum Guide · 2020

Les trois piliers du rôle

Notion clé
Le chef de projet digital repose sur trois piliers inséparables. Le cadrage d'abord : fixer les objectifs clairs, délimiter précisément le périmètre, identifier les ressources et les risques. Le pilotage ensuite : avancer pas à pas, rapporter régulièrement l'avancement, signaler les écarts et adapter le plan. La livraison enfin : assurer que le produit fini répond aux attentes, qu'il est accepté par le client et qu'il génère la valeur attendue. Ces trois piliers forment un cycle permanent.
Notion clé
Les trois piliers du rôle
Le chef de projet digital repose sur trois piliers inséparables. Le cadrage d'abord : fixer les objectifs clairs, délimiter précisément le périmètre, identifier les ressources et les risques. Le pilotage ensuite : avancer pas à pas, rapporter régulièrement l'avancement, signaler les écarts et adapter le plan. La livraison enfin : assurer que le produit fini répond aux attentes, qu'il est accepté par le client et qu'il génère la valeur attendue. Ces trois piliers forment un cycle permanent.

Les missions quotidiennes

Notion clé
Au quotidien, le chef de projet digital remplit des missions très concrètes. Il anime des réunions de synchronisation : daily standup de 15 minutes où chacun rapporte le jour précédent, réunion hebdomadaire de pilotage, revue de sprint tous les deux semaines. Il communique : tableaux de bord partagés, rapports d'avancement, listes de risques. Il valide : contrôle que chaque livrable respecte les critères de qualité définis. Il s'adapte : face à un imprévu technique, à un changement de périmètre ou à un départ d'équipier, il réajuste le plan sans perdre de vue l'objectif.
Notion clé
Les missions quotidiennes
Au quotidien, le chef de projet digital remplit des missions très concrètes. Il anime des réunions de synchronisation : daily standup de 15 minutes où chacun rapporte le jour précédent, réunion hebdomadaire de pilotage, revue de sprint tous les deux semaines. Il communique : tableaux de bord partagés, rapports d'avancement, listes de risques. Il valide : contrôle que chaque livrable respecte les critères de qualité définis. Il s'adapte : face à un imprévu technique, à un changement de périmètre ou à un départ d'équipier, il réajuste le plan sans perdre de vue l'objectif.

Cas — Migration d'une PME vers une SaaS RH

Cas concret
Prenons un cas concret : une PME chimique de 50 salariés utilisait depuis 20 ans un logiciel de paie sur serveur. Elle décide de migrer vers Workday, une plateforme cloud RH moderne. Le chef de projet identifie trois phases : phase de configuration et de test (3 mois), phase de migration des données historiques (2 mois), phase de formation et stabilisation (1 mois). Il coordonne l'équipe informatique interne, le consultant Workday externe et les responsables RH métier. Les risques identifiés : qualité des données migrées, charge de travail excessive sur RH pendant la transition, acceptation de l'outil par les managers. Son travail consiste à naviguer ces trois mondes et à livrer un outil fonctionnel que tout le monde accepte d'utiliser.
Cas concret
Cas — Migration d'une PME vers une SaaS RH
Prenons un cas concret : une PME chimique de 50 salariés utilisait depuis 20 ans un logiciel de paie sur serveur. Elle décide de migrer vers Workday, une plateforme cloud RH moderne. Le chef de projet identifie trois phases : phase de configuration et de test (3 mois), phase de migration des données historiques (2 mois), phase de formation et stabilisation (1 mois). Il coordonne l'équipe informatique interne, le consultant Workday externe et les responsables RH métier. Les risques identifiés : qualité des données migrées, charge de travail excessive sur RH pendant la transition, acceptation de l'outil par les managers. Son travail consiste à naviguer ces trois mondes et à livrer un outil fonctionnel que tout le monde accepte d'utiliser.

À retenir — Qui est un chef de projet digital ?

À retenir

À retenir

Le chef de projet digital est un pilote d'initiatives. Ce n'est pas un technicien qui code ou configure, mais un gestionnaire qui comprend les enjeux techniques, commerciaux et humains. Il s'appuie sur trois piliers : bien cadrer le projet avant de commencer, piloter régulièrement sans bloquer l'équipe, livrer un produit qui crée de la valeur. Il n'a rarement une autorité hiérarchique directe sur les équipes, donc il doit influencer par la clarté du message et la qualité de son pilotage.
À retenir
À retenir — Qui est un chef de projet digital ?
Le chef de projet digital est un pilote d'initiatives. Ce n'est pas un technicien qui code ou configure, mais un gestionnaire qui comprend les enjeux techniques, commerciaux et humains. Il s'appuie sur trois piliers : bien cadrer le projet avant de commencer, piloter régulièrement sans bloquer l'équipe, livrer un produit qui crée de la valeur. Il n'a rarement une autorité hiérarchique directe sur les équipes, donc il doit influencer par la clarté du message et la qualité de son pilotage.

Définition

Vocabulaire
Terme du cours
Marché du digital et de la transformation numérique
« Marché » du latin « mercatus » ; « digital » du latin « digitus ».
Écosystème économique constitué de clients (entreprises, organisations) cherchant à digitaliser, d'offreurs de solutions (agences, éditeurs SaaS, cabinets de conseil), et de professionnels (développeurs, data analysts, chefs de projet) qui les accompagnent.
Le marché du digital est l'ensemble des organisations qui investissent pour numériser leurs processus, services ou produits. En 2026, ce marché représente plusieurs centaines de milliards d'euros mondialement et plusieurs dizaines de milliards en France. Il comprend tous les secteurs : finance, santé, retail, industrie, public, énergie. La demande de chefs de projet est forte et stable : les entreprises réalisent que conduire le changement digital n'est pas une affaire d'IT seule, mais une transformation métier et humaine qui exige du pilotage.
Définition
Définition : Marché du digital et de la transformation numérique
Le marché du digital est l'ensemble des organisations qui investissent pour numériser leurs processus, services ou produits. En 2026, ce marché représente plusieurs centaines de milliards d'euros mondialement et plusieurs dizaines de milliards en France. Il comprend tous les secteurs : finance, santé, retail, industrie, public, énergie. La demande de chefs de projet est forte et stable : les entreprises réalisent que conduire le changement digital n'est pas une affaire d'IT seule, mais une transformation métier et humaine qui exige du pilotage.
Source : Syntec Numérique · Baromètre 2026

Les employeurs principaux

Notion clé
Qui embauche les chefs de projet digital ? D'abord, les agences digitales : petites structures de 10 à 500 personnes qui mixent création, stratégie et développement. Ensuite, les cabinets de conseil : Deloitte, Capgemini, Accenture, ou des plus petits. Puis, les éditeurs SaaS globaux qui ont besoin de chefs de projet pour accompagner l'implémentation de leurs solutions chez les clients. Enfin, les directions informatiques des grandes organisations qui conduisent leur transformation en interne. Chacun de ces univers offre une expérience différente : agence = diversité des clients et des domaines ; conseil = méthodologie rigoureuse ; éditeur = compréhension profonde d'un produit ; interne = stabilité et connaissance du métier.
Notion clé
Les employeurs principaux
Qui embauche les chefs de projet digital ? D'abord, les agences digitales : petites structures de 10 à 500 personnes qui mixent création, stratégie et développement. Ensuite, les cabinets de conseil : Deloitte, Capgemini, Accenture, ou des plus petits. Puis, les éditeurs SaaS globaux qui ont besoin de chefs de projet pour accompagner l'implémentation de leurs solutions chez les clients. Enfin, les directions informatiques des grandes organisations qui conduisent leur transformation en interne. Chacun de ces univers offre une expérience différente : agence = diversité des clients et des domaines ; conseil = méthodologie rigoureuse ; éditeur = compréhension profonde d'un produit ; interne = stabilité et connaissance du métier.

Cadre légal et réglementaire

Notion clé
Aucun projet digital n'échappe au cadre légal. Depuis 2018, le Règlement Général sur la Protection des Données (RGPD) impose de traiter les données personnelles de manière éthique et transparente. Tout projet qui collecte, stocke ou traite des données doit intégrer la conformité RGPD dès le départ, pas en fin de projet. La sécurité informatique s'impose aussi : certifications ISO 27001, directive NIS2 pour les opérateurs critiques. L'accessibilité web devient obligatoire : un site, une application, un portail doit être accessible aux personnes en situation de handicap. Le chef de projet digital doit connaître ces dimensions, car elles influencent l'architecture, le budget et les délais du projet.
Notion clé
Cadre légal et réglementaire
Aucun projet digital n'échappe au cadre légal. Depuis 2018, le Règlement Général sur la Protection des Données (RGPD) impose de traiter les données personnelles de manière éthique et transparente. Tout projet qui collecte, stocke ou traite des données doit intégrer la conformité RGPD dès le départ, pas en fin de projet. La sécurité informatique s'impose aussi : certifications ISO 27001, directive NIS2 pour les opérateurs critiques. L'accessibilité web devient obligatoire : un site, une application, un portail doit être accessible aux personnes en situation de handicap. Le chef de projet digital doit connaître ces dimensions, car elles influencent l'architecture, le budget et les délais du projet.
Sources : CNIL · Guide du RGPD · 2024 · Gouvernement français · Guide NIS2

Cas — Agence digitale accompagnant un secteur public

Cas concret
Une collectivité locale commande à une agence digitale la refonte de son portail citoyen et de son intranet. C'est un projet public : les finances sont votées au budget municipal, le calendrier est contraignant (avant les élections), les règles RGAA sur l'accessibilité s'appliquent de facto. Le chef de projet coordonne avec l'agence (design, frontend, backend), le prestataire cloud (infrastructure), et les services métier locaux (RH, finances, culture). Il gère aussi les enjeux RGPD spécifiques au secteur public. Ce contexte rend le projet plus complexe qu'une simple refonte privée : il y a plus de parties prenantes et de contraintes légales, donc plus de négociation.
Cas concret
Cas — Agence digitale accompagnant un secteur public
Une collectivité locale commande à une agence digitale la refonte de son portail citoyen et de son intranet. C'est un projet public : les finances sont votées au budget municipal, le calendrier est contraignant (avant les élections), les règles RGAA sur l'accessibilité s'appliquent de facto. Le chef de projet coordonne avec l'agence (design, frontend, backend), le prestataire cloud (infrastructure), et les services métier locaux (RH, finances, culture). Il gère aussi les enjeux RGPD spécifiques au secteur public. Ce contexte rend le projet plus complexe qu'une simple refonte privée : il y a plus de parties prenantes et de contraintes légales, donc plus de négociation.

À retenir — L'environnement professionnel

À retenir

À retenir

Le chef de projet digital peut travailler dans quatre univers principaux : agence digitale pour la diversité, cabinet de conseil pour la méthodologie, éditeur SaaS pour l'expertise produit, ou direction IT d'une grande organisation pour la stabilité. Quel que soit l'univers, il ne peut ignorer le cadre légal : RGPD pour les données, sécurité informatique pour les risques, accessibilité web pour l'inclusion. Ce contexte légal influence budgets, délais et ressources. Le marché du digital reste stable et en croissance dans tous les secteurs : finance, santé, retail, industrie, public.
À retenir
À retenir — L'environnement professionnel
Le chef de projet digital peut travailler dans quatre univers principaux : agence digitale pour la diversité, cabinet de conseil pour la méthodologie, éditeur SaaS pour l'expertise produit, ou direction IT d'une grande organisation pour la stabilité. Quel que soit l'univers, il ne peut ignorer le cadre légal : RGPD pour les données, sécurité informatique pour les risques, accessibilité web pour l'inclusion. Ce contexte légal influence budgets, délais et ressources. Le marché du digital reste stable et en croissance dans tous les secteurs : finance, santé, retail, industrie, public.

Taille du marché du digital en France (2026)

Économétrie

Croissance annuelle du secteur IT & digital services en France.

Chiffre d'affaires en milliards EUR
120%90%60%30%0% 95.2% Conseil & intégration IT 32.5% Édition de logiciels 28.7% Services informatiques
Source : Syntec Numérique · Baromètre de l'activité 2026
+5,2 %
Croissance annuelle du secteur IT
180 K
Emplois IT en France (chefs de projet inclus)
Le marché du digital en France représente plus de 150 milliards d'euros de chiffre d'affaires annuel. Le conseil et l'intégration IT dominent avec près de 100 milliards, suivis par l'édition de logiciels (SaaS, outils métier) et les services informatiques purs. Le secteur croît de 5 % par an, au-dessus de la croissance économique générale. Cette croissance soutenue assure une demande stable de chefs de projet : environ 180 000 professionnels IT en France, dont une part croissante dans des rôles de pilotage et de gestion de projet.
Données
Taille du marché du digital en France (2026)
Le marché du digital en France représente plus de 150 milliards d'euros de chiffre d'affaires annuel. Le conseil et l'intégration IT dominent avec près de 100 milliards, suivis par l'édition de logiciels (SaaS, outils métier) et les services informatiques purs. Le secteur croît de 5 % par an, au-dessus de la croissance économique générale. Cette croissance soutenue assure une demande stable de chefs de projet : environ 180 000 professionnels IT en France, dont une part croissante dans des rôles de pilotage et de gestion de projet.

Définition

Vocabulaire
Terme du cours
Compétence
Du latin « competentia » (aptitude, convenance) ; ensemble de savoirs, savoir-faire et savoir-être mobilisables en situation.
Capacité d'une personne à mobiliser des connaissances, des techniques et des qualités humaines pour accomplir une tâche, résoudre un problème ou atteindre un objectif professionnel de manière efficace et autonome.
Une compétence n'est pas une connaissance passive ; c'est la capacité à agir. Un chef de projet digital doit maîtriser des outils (Jira, MS Project, Notion), des méthodes (Scrum, Kanban), et surtout des qualités humaines : écoute, clarté de communication, capacité à décider sous incertitude, résilience face aux imprévus. Ce que nous verrons dans cette sous-partie, ce sont les compétences-clés qui distinguent un bon chef de projet d'un débutant.
Définition
Définition : Compétence
Une compétence n'est pas une connaissance passive ; c'est la capacité à agir. Un chef de projet digital doit maîtriser des outils (Jira, MS Project, Notion), des méthodes (Scrum, Kanban), et surtout des qualités humaines : écoute, clarté de communication, capacité à décider sous incertitude, résilience face aux imprévus. Ce que nous verrons dans cette sous-partie, ce sont les compétences-clés qui distinguent un bon chef de projet d'un débutant.

Maîtriser la méthode et les outils

Notion clé
Un chef de projet digital doit comprendre et appliquer les méthodes agiles : Scrum pour les équipes de développement, Kanban pour les flux continus, ou une approche hybride selon le type de projet. Il maîtrise les outils de pilotage : Jira pour le suivi technique, Asana ou Notion pour la coordination générale, MS Project pour les plans plus formels. Il sait lire un budget, construire un plan de charge, identifier les goulots d'étranglement. Ces compétences techniques ne sont pas optionnelles : elles fondent la crédibilité et l'efficacité du pilotage.
Notion clé
Maîtriser la méthode et les outils
Un chef de projet digital doit comprendre et appliquer les méthodes agiles : Scrum pour les équipes de développement, Kanban pour les flux continus, ou une approche hybride selon le type de projet. Il maîtrise les outils de pilotage : Jira pour le suivi technique, Asana ou Notion pour la coordination générale, MS Project pour les plans plus formels. Il sait lire un budget, construire un plan de charge, identifier les goulots d'étranglement. Ces compétences techniques ne sont pas optionnelles : elles fondent la crédibilité et l'efficacité du pilotage.

Communiquer avec clarté et écoute

Notion clé
Le chef de projet digital passe 70 % de son temps en communication. Il écoute d'abord : les besoins métier du client, les contraintes techniques de l'équipe dev, les inquiétudes des managers opérationnels. Il adapte son discours à chaque audience : le client entend le business value et les délais, les développeurs veulent comprendre les contraintes techniques, la direction s'intéresse au ROI et aux risques. Il gère les conflits inévitables entre une demande métier ambitieuse, un budget serré, et des délais contraints. Cette compétence de communication se cultive par la pratique et l'humilité.
Notion clé
Communiquer avec clarté et écoute
Le chef de projet digital passe 70 % de son temps en communication. Il écoute d'abord : les besoins métier du client, les contraintes techniques de l'équipe dev, les inquiétudes des managers opérationnels. Il adapte son discours à chaque audience : le client entend le business value et les délais, les développeurs veulent comprendre les contraintes techniques, la direction s'intéresse au ROI et aux risques. Il gère les conflits inévitables entre une demande métier ambitieuse, un budget serré, et des délais contraints. Cette compétence de communication se cultive par la pratique et l'humilité.

Cas — Naviguer un désaccord entre métier et tech

Cas concret
Un cas classique : le métier commande une plateforme e-commerce avec N fonctionnalités en 4 mois et un budget Z. L'équipe tech évalue la charge réelle et conclut que 7 mois sont nécessaires pour la qualité. Le chef de projet n'impose pas la vision du métier ni celle de la tech, mais il propose une troisième voie : un MVP (minimum viable product) en 4 mois avec les fonctionnalités critiques, suivi d'évolutions trimestrielles qui ajoutent les « nice to have ». Cette approche satisfait le métier (on démarre à temps), la tech (on code qualité sans rushing) et l'business (on livrer de la valeur progressivement). Cela requiert de l'écoute, de la créativité et de la confiance mutuelle.
Cas concret
Cas — Naviguer un désaccord entre métier et tech
Un cas classique : le métier commande une plateforme e-commerce avec N fonctionnalités en 4 mois et un budget Z. L'équipe tech évalue la charge réelle et conclut que 7 mois sont nécessaires pour la qualité. Le chef de projet n'impose pas la vision du métier ni celle de la tech, mais il propose une troisième voie : un MVP (minimum viable product) en 4 mois avec les fonctionnalités critiques, suivi d'évolutions trimestrielles qui ajoutent les « nice to have ». Cette approche satisfait le métier (on démarre à temps), la tech (on code qualité sans rushing) et l'business (on livrer de la valeur progressivement). Cela requiert de l'écoute, de la créativité et de la confiance mutuelle.

À retenir — Les compétences clés requises

À retenir

À retenir

Un bon chef de projet digital maîtrise trois domaines. D'abord, la technique : les méthodes agiles, les outils de pilotage, la lecture des budgets et des délais. Ensuite, la communication : écoute active, clarté du message adapté à chaque audience, gestion constructive des conflits. Enfin, la résilience : capacité à décider sous incertitude, à adapter le plan face aux imprévus, à maintenir la motivation en période tendue. Ces trois compétences se renforcent mutuellement et s'acquièrent progressivement dans la pratique.
À retenir
À retenir — Les compétences clés requises
Un bon chef de projet digital maîtrise trois domaines. D'abord, la technique : les méthodes agiles, les outils de pilotage, la lecture des budgets et des délais. Ensuite, la communication : écoute active, clarté du message adapté à chaque audience, gestion constructive des conflits. Enfin, la résilience : capacité à décider sous incertitude, à adapter le plan face aux imprévus, à maintenir la motivation en période tendue. Ces trois compétences se renforcent mutuellement et s'acquièrent progressivement dans la pratique.
Partie 2 sur 3
2
Exercer le métier au quotidien
METIER-CHEF-DE-PROJET-PLATEFORMES-DIGITAL · Séance 1 · Chef(fe) de projet plateformes / digital — Découvrir le méti...

Définition

Vocabulaire
Terme du cours
Cadrage d'un projet
« Cadrer » (fixer les limites) ; du latin « quadrum » (carré, limite).
Phase initiale du projet qui formalise les objectifs, le périmètre, les ressources, les risques et les délais. Le cadrage est l'acte de passer d'une demande vague à un plan précis et accepté par tous.
Le cadrage est LA phase critique. Bien cadrer, c'est économiser trois mois de chaos en fin de projet. Un bon cadrage répond à cinq questions : Pourquoi ce projet (objectifs métier) ? Quoi livrer exactement (périmètre) ? Qui participe (ressources, équipes, rôles) ? Combien ça coûte et en combien de temps (budget, délais) ? Quels risques (et comment les mitiger) ? Un mauvais cadrage laisse ces questions ouvertes : périmètre flou, budget sous-estimé, délais irréalistes, équipes mal identifiées. Au premier imprévu, le projet déraille.
Définition
Définition : Cadrage d'un projet
Le cadrage est LA phase critique. Bien cadrer, c'est économiser trois mois de chaos en fin de projet. Un bon cadrage répond à cinq questions : Pourquoi ce projet (objectifs métier) ? Quoi livrer exactement (périmètre) ? Qui participe (ressources, équipes, rôles) ? Combien ça coûte et en combien de temps (budget, délais) ? Quels risques (et comment les mitiger) ? Un mauvais cadrage laisse ces questions ouvertes : périmètre flou, budget sous-estimé, délais irréalistes, équipes mal identifiées. Au premier imprévu, le projet déraille.

Les 5 éléments du cadrage

Notion clé
Un cadrage complet comporte cinq éléments. D'abord, les objectifs métier : gain de temps pour les salariés, réduction des coûts, amélioration client. On quantifie le business case : si on investit 500 k EUR, on économise 200 k EUR par an. Deuxièmement, le périmètre fonctionnel : quelles fonctionnalités sont incluses, lesquelles sont exclues intentionnellement. Troisièmement, les ressources : qui dirige (steering committee), qui exécute (équipe projet), qui valide (product owner), qui supporte (support métier). Quatrièmement, budget et délais : somme totale investie, phases et jalons clés. Cinquièmement, implicite mais crucial : les risques majeurs et leur mitigation.
Notion clé
Les 5 éléments du cadrage
Un cadrage complet comporte cinq éléments. D'abord, les objectifs métier : gain de temps pour les salariés, réduction des coûts, amélioration client. On quantifie le business case : si on investit 500 k EUR, on économise 200 k EUR par an. Deuxièmement, le périmètre fonctionnel : quelles fonctionnalités sont incluses, lesquelles sont exclues intentionnellement. Troisièmement, les ressources : qui dirige (steering committee), qui exécute (équipe projet), qui valide (product owner), qui supporte (support métier). Quatrièmement, budget et délais : somme totale investie, phases et jalons clés. Cinquièmement, implicite mais crucial : les risques majeurs et leur mitigation.

Documents de cadrage essentiels

Notion clé
Trois documents formalisent un bon cadrage. Le brief ou charter est concis : 1 à 2 pages qui résument les objectifs, le périmètre, le budget et les risques clés. Le cahier des charges fonctionnel (CdCF) détaille chaque besoin métier en spécifications. Enfin, les estimations de charge : l'équipe développement estime combien de jours sont nécessaires pour chaque fonctionnalité, avec des marges de sécurité. Ces trois documents ne sont pas paperasse : c'est une base de négociation et de pilotage. Tout écart pendant le projet se juge par rapport au cadrage initial.
Notion clé
Documents de cadrage essentiels
Trois documents formalisent un bon cadrage. Le brief ou charter est concis : 1 à 2 pages qui résument les objectifs, le périmètre, le budget et les risques clés. Le cahier des charges fonctionnel (CdCF) détaille chaque besoin métier en spécifications. Enfin, les estimations de charge : l'équipe développement estime combien de jours sont nécessaires pour chaque fonctionnalité, avec des marges de sécurité. Ces trois documents ne sont pas paperasse : c'est une base de négociation et de pilotage. Tout écart pendant le projet se juge par rapport au cadrage initial.

Cas — Cadrage d'une plateforme e-learning

Cas concret
Un organisme de formation lance un projet de plateforme e-learning pour 500 apprenants. Lors du cadrage, le chef de projet rencontre le directeur pédagogique, l'équipe IT et l'équipe support. Il documente les trois objectifs : augmenter l'accès aux formations (online), réduire les coûts d'organisation (pas de déplacement), suivre les acquis (reporting). Il définit le périmètre : catalogage des cours, accès learner, suivi, certificats. Budget estimé : 150 000 EUR (60 k dev, 40 k intégration, 30 k hosting et support an 1, 20 k imprévus). Délai : 3 mois live, puis 1 mois de stabilisation. Au démarrage du projet, tout le monde comprend les mêmes objectifs et les mêmes contraintes.
Cas concret
Cas — Cadrage d'une plateforme e-learning
Un organisme de formation lance un projet de plateforme e-learning pour 500 apprenants. Lors du cadrage, le chef de projet rencontre le directeur pédagogique, l'équipe IT et l'équipe support. Il documente les trois objectifs : augmenter l'accès aux formations (online), réduire les coûts d'organisation (pas de déplacement), suivre les acquis (reporting). Il définit le périmètre : catalogage des cours, accès learner, suivi, certificats. Budget estimé : 150 000 EUR (60 k dev, 40 k intégration, 30 k hosting et support an 1, 20 k imprévus). Délai : 3 mois live, puis 1 mois de stabilisation. Au démarrage du projet, tout le monde comprend les mêmes objectifs et les mêmes contraintes.

À retenir — Cadrer un projet digital

À retenir

À retenir

Le cadrage est l'investissement qui économise le temps plus tard. Passer 2 à 4 semaines à bien cadrer évite 3 mois de chaos en fin de projet. Un bon cadrage répond à cinq questions : pourquoi, quoi, qui, combien, quels risques. Ces réponses sont formalisées dans trois documents clés : un brief concis, un cahier des charges détaillé, et des estimations de charge. Chaque projet, quelle que soit sa taille ou sa méthode (agile ou traditionnelle), passe par cette phase de cadrage. Ne pas la négliger.
À retenir
À retenir — Cadrer un projet digital
Le cadrage est l'investissement qui économise le temps plus tard. Passer 2 à 4 semaines à bien cadrer évite 3 mois de chaos en fin de projet. Un bon cadrage répond à cinq questions : pourquoi, quoi, qui, combien, quels risques. Ces réponses sont formalisées dans trois documents clés : un brief concis, un cahier des charges détaillé, et des estimations de charge. Chaque projet, quelle que soit sa taille ou sa méthode (agile ou traditionnelle), passe par cette phase de cadrage. Ne pas la négliger.

Définition

Vocabulaire
Terme du cours
Méthode agile et Scrum
« Agile » du latin « agilis » (flexible, mobile) ; « Scrum » du rugby anglais (mêlée de repartage de ballon).
Approche itérative et incrémentale de gestion de projet basée sur la livraison fréquente de petits incrément de valeur, l'adaptation rapide aux changements, et l'implication de l'équipe et du client dans la décision.
L'agilité n'est pas une mode : c'est une réponse pratique à l'incertitude. Quand on lance un grand projet, on ne sait pas tout d'avance : les besoins évoluent, la tech surprend, le marché change. Plutôt que de tout prévoir sur 12 mois (et se tromper), l'agilité propose : planifier 2-3 semaines (1 sprint), livrer quelque chose de testable, récolter le feedback, ajuster. Scrum est la méthode la plus utilisée. Elle implique trois rôles (product owner qui priorise, scrum master qui anime, équipe dev qui code), trois artefacts (product backlog, sprint backlog, increment), et quatre cérémonies (sprint planning, daily standup, sprint review, retro).
Définition
Définition : Méthode agile et Scrum
L'agilité n'est pas une mode : c'est une réponse pratique à l'incertitude. Quand on lance un grand projet, on ne sait pas tout d'avance : les besoins évoluent, la tech surprend, le marché change. Plutôt que de tout prévoir sur 12 mois (et se tromper), l'agilité propose : planifier 2-3 semaines (1 sprint), livrer quelque chose de testable, récolter le feedback, ajuster. Scrum est la méthode la plus utilisée. Elle implique trois rôles (product owner qui priorise, scrum master qui anime, équipe dev qui code), trois artefacts (product backlog, sprint backlog, increment), et quatre cérémonies (sprint planning, daily standup, sprint review, retro).
Source : Scrum Guide · 2020 (Schwaber & Sutherland)

Les outils agiles : Jira, Asana, Notion

Notion clé
Le chef de projet agile s'appuie sur des outils pour orchestrer le travail. Jira est le standard de facto pour les équipes de développement Scrum : on y crée des user stories, on les estime en points de complexité, on les place dans un sprint. Jira génère automatiquement un graphique burndown qui montre si on va livrer à temps. Asana offre une vue plus généraliste : timeline gantt, kanban, dépendances. Elle convient aux projets multi-équipes. Notion est plus flexible : combinaison wiki + base de données + calendar, idéale pour les PME et startups qui ne veulent pas trop de structure. Quel que soit l'outil, le chef de projet doit maîtriser son utilisation pour que tout le monde travaille au même endroit.
Notion clé
Les outils agiles : Jira, Asana, Notion
Le chef de projet agile s'appuie sur des outils pour orchestrer le travail. Jira est le standard de facto pour les équipes de développement Scrum : on y crée des user stories, on les estime en points de complexité, on les place dans un sprint. Jira génère automatiquement un graphique burndown qui montre si on va livrer à temps. Asana offre une vue plus généraliste : timeline gantt, kanban, dépendances. Elle convient aux projets multi-équipes. Notion est plus flexible : combinaison wiki + base de données + calendar, idéale pour les PME et startups qui ne veulent pas trop de structure. Quel que soit l'outil, le chef de projet doit maîtriser son utilisation pour que tout le monde travaille au même endroit.

Les cérémonies Scrum : rythme et décisions

Notion clé
Scrum fonctionne sur un rythme régulier de cérémonies qui structurent le travail. Chaque matin, 15 minutes de daily standup : chacun dit en deux phrases ce qu'il a fait hier et ce qu'il va faire aujourd'hui. Le lundi matin (sprint planning) : 2 à 3 heures pour décider quelles fonctionnalités le sprint va livrer. Tous les deux jeudis (sprint review) : 1 à 2 heures pour montrer au client/product owner ce qui fonctionne et recueillir du feedback. Enfin, deux heures de retrospective : l'équipe se demande comment elle va mieux travailler le sprint suivant. Ces cérémonies assurent que tout le monde reste synchronized et que les problèmes remontent vite.
Notion clé
Les cérémonies Scrum : rythme et décisions
Scrum fonctionne sur un rythme régulier de cérémonies qui structurent le travail. Chaque matin, 15 minutes de daily standup : chacun dit en deux phrases ce qu'il a fait hier et ce qu'il va faire aujourd'hui. Le lundi matin (sprint planning) : 2 à 3 heures pour décider quelles fonctionnalités le sprint va livrer. Tous les deux jeudis (sprint review) : 1 à 2 heures pour montrer au client/product owner ce qui fonctionne et recueillir du feedback. Enfin, deux heures de retrospective : l'équipe se demande comment elle va mieux travailler le sprint suivant. Ces cérémonies assurent que tout le monde reste synchronized et que les problèmes remontent vite.

Cas — Piloter une équipe de 6 devs en Scrum

Cas concret
Un projet e-commerce démarre en Scrum. L'équipe comprend 3 développeurs frontend, 2 backend, 1 testeur QA. Le product owner (client side) a écrit 50 user stories, du type « En tant que client, je veux pouvoir filtrer les produits par catégorie ». Chaque story est estimée : facile (1-2 points), normal (3-5 points), difficile (8-13 points). Le scrum master (souvent le chef de projet) anime les cérémonies. Sprint 1 : l'équipe prend 30 points de travail (7 stories). Elle livre ce qui était promis en fin de sprint. Le client valide, propose des ajustements, et priorise les 30 points suivants. Après 6-7 sprints, la plateforme est live. Cette approche expose les vrais problèmes tôt : si on ne livre que 20 points après 3 sprints alors qu'on en promettait 30, on ajuste le scope ou les délais.
Cas concret
Cas — Piloter une équipe de 6 devs en Scrum
Un projet e-commerce démarre en Scrum. L'équipe comprend 3 développeurs frontend, 2 backend, 1 testeur QA. Le product owner (client side) a écrit 50 user stories, du type « En tant que client, je veux pouvoir filtrer les produits par catégorie ». Chaque story est estimée : facile (1-2 points), normal (3-5 points), difficile (8-13 points). Le scrum master (souvent le chef de projet) anime les cérémonies. Sprint 1 : l'équipe prend 30 points de travail (7 stories). Elle livre ce qui était promis en fin de sprint. Le client valide, propose des ajustements, et priorise les 30 points suivants. Après 6-7 sprints, la plateforme est live. Cette approche expose les vrais problèmes tôt : si on ne livre que 20 points après 3 sprints alors qu'on en promettait 30, on ajuste le scope ou les délais.

À retenir — Piloter en mode agile

À retenir

À retenir

Piloter en mode agile signifie accepter que le plan changerait en fonction du feedback client et des surprises tech. Plutôt que de tout prévoir sur 12 mois, on planifie par sprints de 1-2 semaines, on livre des incrément testables et on ajuste. Scrum en est la mise en œuvre la plus courante : trois rôles clairs (PO, SM, équipe), trois artefacts (backlogs et increment) et quatre cérémonies qui structurent le rythme. Les outils comme Jira, Asana ou Notion capturent cette réalité : backlogs, points estimés, burndown, feedback du client. La vélocité (points/sprint) aide à prédire quand le projet sera fini.
À retenir
À retenir — Piloter en mode agile
Piloter en mode agile signifie accepter que le plan changerait en fonction du feedback client et des surprises tech. Plutôt que de tout prévoir sur 12 mois, on planifie par sprints de 1-2 semaines, on livre des incrément testables et on ajuste. Scrum en est la mise en œuvre la plus courante : trois rôles clairs (PO, SM, équipe), trois artefacts (backlogs et increment) et quatre cérémonies qui structurent le rythme. Les outils comme Jira, Asana ou Notion capturent cette réalité : backlogs, points estimés, burndown, feedback du client. La vélocité (points/sprint) aide à prédire quand le projet sera fini.

Définition

Vocabulaire
Terme du cours
Recette et mise en production
« Recette » du latin « recepta » (procédé acquis) ; « production » du latin « producere » (conduire dehors).
Phase finale du projet : validation du produit fini par le client (recette), préparation de l'environnement de production, et déploiement en live. Cette phase détermine le succès ou l'échec du projet aux yeux de l'utilisateur final.
La recette est le moment de vérité : vérifier que le produit livré répond vraiment aux besoins spécifiés en début de projet. Ce n'est pas juste du test technique (ça, c'est le job du testeur), c'est une validation fonctionnelle par le client. La mise en production est le passage du produit de l'environnement de développement à l'environnement réel, avec tous les utilisateurs. Cette phase comporte des risques : un bug critique passe inaperçu en test et plante en prod, une donnée n'a pas migré correctement, une dépendance externe n'est pas disponible. Un bon chef de projet prépare cette phase avec un plan de test rigoureux et un plan de recette claire.
Définition
Définition : Recette et mise en production
La recette est le moment de vérité : vérifier que le produit livré répond vraiment aux besoins spécifiés en début de projet. Ce n'est pas juste du test technique (ça, c'est le job du testeur), c'est une validation fonctionnelle par le client. La mise en production est le passage du produit de l'environnement de développement à l'environnement réel, avec tous les utilisateurs. Cette phase comporte des risques : un bug critique passe inaperçu en test et plante en prod, une donnée n'a pas migré correctement, une dépendance externe n'est pas disponible. Un bon chef de projet prépare cette phase avec un plan de test rigoureux et un plan de recette claire.

Plan de test et critères d'acceptation

Notion clé
Avant la recette, on prépare un plan de test structuré en couches. Les tests unitaires valident chaque fonction isolée : un formulaire accepte bien un email valide, refuse un email invalide. Les tests d'intégration s'assurent que les modules communiquent : la base de données reçoit bien les données du formulaire. Les tests utilisateur (UAT) simulent des scénarios réels avec un vrai client : un client commande 3 produits, paie, reçoit une confirmation. Les critères d'acceptation doivent être définis AVANT la recette pour éviter le dialogue de sourds : « Qu'est-ce que tu attends exactement ? » Et les critères doivent être objectifs : pas « c'est rapide », mais « le chargement d'une page dure < 2 secondes ».
Notion clé
Plan de test et critères d'acceptation
Avant la recette, on prépare un plan de test structuré en couches. Les tests unitaires valident chaque fonction isolée : un formulaire accepte bien un email valide, refuse un email invalide. Les tests d'intégration s'assurent que les modules communiquent : la base de données reçoit bien les données du formulaire. Les tests utilisateur (UAT) simulent des scénarios réels avec un vrai client : un client commande 3 produits, paie, reçoit une confirmation. Les critères d'acceptation doivent être définis AVANT la recette pour éviter le dialogue de sourds : « Qu'est-ce que tu attends exactement ? » Et les critères doivent être objectifs : pas « c'est rapide », mais « le chargement d'une page dure < 2 secondes ».

Déploiement et rollback : préparer le jour J

Notion clé
Le jour du déploiement, tout doit être prévu. L'environnement de production est différent de celui de dev : hardware dimensionné, sauvegardes en place, firewall configuré, certificats SSL prêts. Une checklist de déploiement énumère chaque étape : migrations de base de données, déploiement du code, configuration des variables d'env, vérification des logs. Mais choses malheureuses arrivent : un bug critique qu'on n'avait pas vu en test, une API externe qui ne répond pas. D'où l'importance d'un plan de rollback : comment revenir au version précédente en moins de 30 minutes. Et enfin, le support jour 1 : l'équipe dev et les ops sont en astreinte pour intervenir sur tout problème immédiat.
Notion clé
Déploiement et rollback : préparer le jour J
Le jour du déploiement, tout doit être prévu. L'environnement de production est différent de celui de dev : hardware dimensionné, sauvegardes en place, firewall configuré, certificats SSL prêts. Une checklist de déploiement énumère chaque étape : migrations de base de données, déploiement du code, configuration des variables d'env, vérification des logs. Mais choses malheureuses arrivent : un bug critique qu'on n'avait pas vu en test, une API externe qui ne répond pas. D'où l'importance d'un plan de rollback : comment revenir au version précédente en moins de 30 minutes. Et enfin, le support jour 1 : l'équipe dev et les ops sont en astreinte pour intervenir sur tout problème immédiat.

Cas — Recette d'une app mobile pour une banque

Cas concret
Une application mobile de paiement pour une banque rentre en recette. Le client sélectionne 50 utilisateurs power-users qui testent les scénarios clés : connexion, consultation du compte, effectuer un virement, un paiement par QR code. Au jour 3, le QA remonte un bug : sur iPhone 12, après 5 minutes d'inactivité, la session se ferme de façon inattendue. On mobilise un dev qui isole le bug (mauvaise gestion du token), le fix, et on re-teste. Jour 5, ça passe. Go-live : plutôt que de basculer d'un coup 500 000 utilisateurs, on déploie en deux vagues : d'abord 10 % (50 000) pour 24 heures, puis 100 %. Pendant ces 24 heures, l'équipe observe les logs, prête à rollback. Zéro problème en vague 1, donc vague 2. Succès.
Cas concret
Cas — Recette d'une app mobile pour une banque
Une application mobile de paiement pour une banque rentre en recette. Le client sélectionne 50 utilisateurs power-users qui testent les scénarios clés : connexion, consultation du compte, effectuer un virement, un paiement par QR code. Au jour 3, le QA remonte un bug : sur iPhone 12, après 5 minutes d'inactivité, la session se ferme de façon inattendue. On mobilise un dev qui isole le bug (mauvaise gestion du token), le fix, et on re-teste. Jour 5, ça passe. Go-live : plutôt que de basculer d'un coup 500 000 utilisateurs, on déploie en deux vagues : d'abord 10 % (50 000) pour 24 heures, puis 100 %. Pendant ces 24 heures, l'équipe observe les logs, prête à rollback. Zéro problème en vague 1, donc vague 2. Succès.

À retenir — Recetter et mettre en production

À retenir

À retenir

La recette est la dernière opportunité de corriger les problèmes avant le go-live. C'est une validation fonctionnelle par le client : le produit répond-il vraiment aux besoins définis ? On teste par couches : unitaire, intégration, puis avec de vrais utilisateurs (UAT). Le jour du déploiement en production, on doit avoir une checklist précise, un plan de rollback au cas où, et une équipe support en astreinte. La mise en production est souvent une opération nervante car il y a peu de seconde chance, mais bien préparée, c'est un succès qui termine le projet sur une note positive.
À retenir
À retenir — Recetter et mettre en production
La recette est la dernière opportunité de corriger les problèmes avant le go-live. C'est une validation fonctionnelle par le client : le produit répond-il vraiment aux besoins définis ? On teste par couches : unitaire, intégration, puis avec de vrais utilisateurs (UAT). Le jour du déploiement en production, on doit avoir une checklist précise, un plan de rollback au cas où, et une équipe support en astreinte. La mise en production est souvent une opération nervante car il y a peu de seconde chance, mais bien préparée, c'est un succès qui termine le projet sur une note positive.
Partie 3 sur 3
3
Performer et progresser
METIER-CHEF-DE-PROJET-PLATEFORMES-DIGITAL · Séance 1 · Chef(fe) de projet plateformes / digital — Découvrir le méti...

Définition

Vocabulaire
Terme du cours
Performance de projet et KPI
« Performance » du français ancien « parfournir » (accomplir complètement) ; « KPI » = Key Performance Indicator.
Ensemble d'indicateurs quantifiables qui mesurent si un projet atteint ses objectifs. Les KPI doivent être SMART (Spécifiques, Mesurables, Atteignables, Réalistes, Temporellement définis).
Un bon chef de projet sait mesurer et communiquer la performance de son projet. Ce ne sont pas des vagues impressions (« c'est bien avancé »), mais des chiffres concrets : % d'avancement, budget dépensé vs. prévu, délai avec ou sans dérive. Les indicateurs clés d'un projet sont : planning (% de charges réalisées vs. prévues), budget (dépenses réelles vs. budget alloué), qualité (nombre de bugs, taux d'acceptation en recette), et risques (nombre et sévérité). Ces KPIs doivent être visibles, actualisés chaque semaine, et partagés avec la gouvernance du projet.
Définition
Définition : Performance de projet et KPI
Un bon chef de projet sait mesurer et communiquer la performance de son projet. Ce ne sont pas des vagues impressions (« c'est bien avancé »), mais des chiffres concrets : % d'avancement, budget dépensé vs. prévu, délai avec ou sans dérive. Les indicateurs clés d'un projet sont : planning (% de charges réalisées vs. prévues), budget (dépenses réelles vs. budget alloué), qualité (nombre de bugs, taux d'acceptation en recette), et risques (nombre et sévérité). Ces KPIs doivent être visibles, actualisés chaque semaine, et partagés avec la gouvernance du projet.

Les trois domaines de KPI

Notion clé
Les KPI d'un projet se structurent en trois domaines. Planning d'abord : combien de jours-homme avons-nous brûlé vs. prévu ? De combien de jours sommes-nous en retard ou en avance ? Budget ensuite : avons-nous dépensé trop ou pas assez jusqu'à maintenant ? À ce rythme, dépasserons-nous le budget final ? On calcule un « run-rate » : si on a dépensé X EUR en 2 mois et qu'on en a 6 de total, on est à X*3 EUR. Qualité enfin : combien de bugs avons-nous détectés ? Combien ont été fixés ? Quel taux d'acceptation client lors de la recette ? Ces trois domaines ensemble donnent une vue d'ensemble de la santé du projet.
Notion clé
Les trois domaines de KPI
Les KPI d'un projet se structurent en trois domaines. Planning d'abord : combien de jours-homme avons-nous brûlé vs. prévu ? De combien de jours sommes-nous en retard ou en avance ? Budget ensuite : avons-nous dépensé trop ou pas assez jusqu'à maintenant ? À ce rythme, dépasserons-nous le budget final ? On calcule un « run-rate » : si on a dépensé X EUR en 2 mois et qu'on en a 6 de total, on est à X*3 EUR. Qualité enfin : combien de bugs avons-nous détectés ? Combien ont été fixés ? Quel taux d'acceptation client lors de la recette ? Ces trois domaines ensemble donnent une vue d'ensemble de la santé du projet.

Tableaux de bord et reporting

Notion clé
Un chef de projet doit opérationnaliser ses KPI pour que tout le monde voie la même réalité. D'abord, un dashboard temps réel : graphique burndown depuis Jira qui montre si on va finir à temps, budget actuel depuis le CRM, liste des risques actifs. Ce dashboard est mis à jour en continu par les outils métier eux-mêmes. Deuxièmement, un rapport hebdo : 1 page maximum, 3 à 5 KPI clés avec une tendance (rouge/orange/vert), un paragraphe sur les highlights et les problèmes. Troisièmement, une réunion steering : chaque semaine ou chaque deux semaines, faire le point avec le sponsor et le client. Qui ? Chef de projet, product owner, sponsor. Quoi ? Avancement, budget, risques. Quand ? Escalade si alerte rouge. Budget ? Engagé vs. restant. Qui ? Qui fait quoi à partir de maintenant.
Notion clé
Tableaux de bord et reporting
Un chef de projet doit opérationnaliser ses KPI pour que tout le monde voie la même réalité. D'abord, un dashboard temps réel : graphique burndown depuis Jira qui montre si on va finir à temps, budget actuel depuis le CRM, liste des risques actifs. Ce dashboard est mis à jour en continu par les outils métier eux-mêmes. Deuxièmement, un rapport hebdo : 1 page maximum, 3 à 5 KPI clés avec une tendance (rouge/orange/vert), un paragraphe sur les highlights et les problèmes. Troisièmement, une réunion steering : chaque semaine ou chaque deux semaines, faire le point avec le sponsor et le client. Qui ? Chef de projet, product owner, sponsor. Quoi ? Avancement, budget, risques. Quand ? Escalade si alerte rouge. Budget ? Engagé vs. restant. Qui ? Qui fait quoi à partir de maintenant.

ROI de projets digitaux : distribution des coûts et bénéfices

Économétrie

Analyse du retour sur investissement pour les projets de transformation numérique.

Millions EUR (coûts sur 3 ans, bénéfices annualisés)
5%3%2%1%0% 1.2% Coûts infrastructure 2.8% Coûts ressources 4.5% Bénéfices réalisés an 1-3
Source : Gartner Magic Quadrant — Étude ROI projets IT 2025
45 %
Projets qui dépassent le budget initialement alloué
2,1 ans
Délai moyen pour atteindre l'équilibre (ROI positif)
Mesurer le retour sur investissement (ROI) d'un projet digital est essentiel pour justifier auprès de la direction. En général, les coûts directs (infrastructure, ressources) sont engagés durant les 12-18 premiers mois. Les bénéfices (réduction de coûts opérationnels, augmentation de revenus) s'étalent sur 2-3 ans. Sur l'exemple d'un projet de 3,9 millions EUR investi, les bénéfices estimés à 4,5 millions sur 3 ans donnent un ROI légèrement positif. Mais attention : 45 % des projets dépassent le budget initial, ce qui prolonge la date d'équilibre. Un bon chef de projet suit ce ROI de près pour ajuster le périmètre ou les priorités si les bénéfices tardent trop.
Données
ROI de projets digitaux : distribution des coûts et bénéfices
Mesurer le retour sur investissement (ROI) d'un projet digital est essentiel pour justifier auprès de la direction. En général, les coûts directs (infrastructure, ressources) sont engagés durant les 12-18 premiers mois. Les bénéfices (réduction de coûts opérationnels, augmentation de revenus) s'étalent sur 2-3 ans. Sur l'exemple d'un projet de 3,9 millions EUR investi, les bénéfices estimés à 4,5 millions sur 3 ans donnent un ROI légèrement positif. Mais attention : 45 % des projets dépassent le budget initial, ce qui prolonge la date d'équilibre. Un bon chef de projet suit ce ROI de près pour ajuster le périmètre ou les priorités si les bénéfices tardent trop.

Cas — Reporting d'un projet en dérive

Cas concret
Un projet démarre avec un plan de 10 semaines et 100 k EUR. Après 4 semaines, le chef de projet consolide les KPI. Planning : on aurait dû être à 40 % d'avancement (4 semaines sur 10), on en est à 25 % seulement. Alerte rouge. Budget : on a dépensé 30 k EUR (30 % du total) pour 25 % du travail fini. Run-rate : au rythme actuel, on va dépenser 120 k EUR au lieu de 100 k EUR. Escalade immédiate au sponsor. Trois options : 1) garder budget et délai, réduire scope (certaines fonctionnalités partent); 2) garder scope et budget, rallonger le délai; 3) laisser le budget exploser. Le sponsor choisit option 1 : on coupe 15 % du scope pour être back on track. Le chef de projet réactualize le plan, communique les ajustements, et relance la machine.
Cas concret
Cas — Reporting d'un projet en dérive
Un projet démarre avec un plan de 10 semaines et 100 k EUR. Après 4 semaines, le chef de projet consolide les KPI. Planning : on aurait dû être à 40 % d'avancement (4 semaines sur 10), on en est à 25 % seulement. Alerte rouge. Budget : on a dépensé 30 k EUR (30 % du total) pour 25 % du travail fini. Run-rate : au rythme actuel, on va dépenser 120 k EUR au lieu de 100 k EUR. Escalade immédiate au sponsor. Trois options : 1) garder budget et délai, réduire scope (certaines fonctionnalités partent); 2) garder scope et budget, rallonger le délai; 3) laisser le budget exploser. Le sponsor choisit option 1 : on coupe 15 % du scope pour être back on track. Le chef de projet réactualize le plan, communique les ajustements, et relance la machine.

À retenir — Mesurer et rapporter la performance

À retenir

À retenir

Bien mesurer et communiquer la performance, c'est la crédibilité du chef de projet. Les KPI doivent être concrets et SMART : % avancement, budget dépensé vs. prévu, taux d'acceptation. Elles sont visibles dans un dashboard en continu (Jira, Asana), synthétisées dans un rapport hebdo d'une page, et discutées à la réunion de gouvernance. Quand l'alerte rouge s'allume, on ne cache rien : on remonte vite, on propose des solutions. À la fin du projet, on mesure le ROI réalisé : avons-nous généré la valeur promise ? Si non, pourquoi ? Cette transparence et cette rigueur fondent la confiance.
À retenir
À retenir — Mesurer et rapporter la performance
Bien mesurer et communiquer la performance, c'est la crédibilité du chef de projet. Les KPI doivent être concrets et SMART : % avancement, budget dépensé vs. prévu, taux d'acceptation. Elles sont visibles dans un dashboard en continu (Jira, Asana), synthétisées dans un rapport hebdo d'une page, et discutées à la réunion de gouvernance. Quand l'alerte rouge s'allume, on ne cache rien : on remonte vite, on propose des solutions. À la fin du projet, on mesure le ROI réalisé : avons-nous généré la valeur promise ? Si non, pourquoi ? Cette transparence et cette rigueur fondent la confiance.

Définition

Vocabulaire
Terme du cours
Crise de projet
« Crise » du grec « krisis » (décision, moment critique).
Situation d'urgence et de forte incertitude qui menace gravement les objectifs du projet (délais, budget, qualité, satisfaction client). Exige une décision rapide et une action coordonnée.
Chaque chef de projet, tôt ou tard, affrontera une crise : développeur clé qui démissionne soudainement, bug critique découvert une semaine avant le go-live, client qui change ses priorités radicalement, API externe qui ne répond plus. Une crise n'est pas une simple petite retard de deux jours, c'est un moment où les bases du projet tremblent. Le chef de projet doit transformer le chaos en ordre rapidement : communiquer, analyser la situation, proposer des solutions, décider et agir. Le leader qui garde la tête froide en crise gagne énormément de crédibilité.
Définition
Définition : Crise de projet
Chaque chef de projet, tôt ou tard, affrontera une crise : développeur clé qui démissionne soudainement, bug critique découvert une semaine avant le go-live, client qui change ses priorités radicalement, API externe qui ne répond plus. Une crise n'est pas une simple petite retard de deux jours, c'est un moment où les bases du projet tremblent. Le chef de projet doit transformer le chaos en ordre rapidement : communiquer, analyser la situation, proposer des solutions, décider et agir. Le leader qui garde la tête froide en crise gagne énormément de crédibilité.

Protocole de gestion de crise : les 4 étapes

Notion clé
Face à une crise, il faut un protocole clair pour ne pas paniquer. Étape 1 : sécuriser l'immédiat. Un bug qui casse la base de données ? Rollback d'urgence. Un hacker qui s'est infiltré ? Isoler le système. Objectif : rendre le système stable suffisamment pour analyser. Étape 2 : analyser vraiment. Quel est l'impact réel ? Combien d'utilisateurs sont affectés ? Avons-nous perdu de la data ? Quels sont les dominos qui vont tomber ? Étape 3 : réunir la « crisis room » et décider. On explore trois options : plan A (solution rapide, quality compromise), plan B (compromis), plan C (gros effort mais on sauve tout). Étape 4 : communiquer avec transparence. Au client, à la direction, aux équipes. Voici la situation vraie, voici ce qu'on fait, voici le délai estimé.
Notion clé
Protocole de gestion de crise : les 4 étapes
Face à une crise, il faut un protocole clair pour ne pas paniquer. Étape 1 : sécuriser l'immédiat. Un bug qui casse la base de données ? Rollback d'urgence. Un hacker qui s'est infiltré ? Isoler le système. Objectif : rendre le système stable suffisamment pour analyser. Étape 2 : analyser vraiment. Quel est l'impact réel ? Combien d'utilisateurs sont affectés ? Avons-nous perdu de la data ? Quels sont les dominos qui vont tomber ? Étape 3 : réunir la « crisis room » et décider. On explore trois options : plan A (solution rapide, quality compromise), plan B (compromis), plan C (gros effort mais on sauve tout). Étape 4 : communiquer avec transparence. Au client, à la direction, aux équipes. Voici la situation vraie, voici ce qu'on fait, voici le délai estimé.

Prévention et résilience

Notion clé
La meilleure crise est celle qu'on évite. D'où l'importance d'une bonne gestion des risques dès le début : identifier les risques majeurs (perte d'un dev clé, API externe instable, exigences changeantes) et préparer des mitigation. Ensuite, la redondance : ne jamais avoir un seul point de défaillance. Si un dev est la seule personne qui comprend un module critique, c'est un risque. Former quelqu'un d'autre. Si la données n'existe que sur un serveur, c'est un risque. Avoir une sauvegarde. Enfin, la résilience : cultiver une culture d'équipe qui accepte que l'imprévu arrive et qui change de plan sans se plaindre. Cette culture prend du temps mais elle rend les crises moins catastrophiques.
Notion clé
Prévention et résilience
La meilleure crise est celle qu'on évite. D'où l'importance d'une bonne gestion des risques dès le début : identifier les risques majeurs (perte d'un dev clé, API externe instable, exigences changeantes) et préparer des mitigation. Ensuite, la redondance : ne jamais avoir un seul point de défaillance. Si un dev est la seule personne qui comprend un module critique, c'est un risque. Former quelqu'un d'autre. Si la données n'existe que sur un serveur, c'est un risque. Avoir une sauvegarde. Enfin, la résilience : cultiver une culture d'équipe qui accepte que l'imprévu arrive et qui change de plan sans se plaindre. Cette culture prend du temps mais elle rend les crises moins catastrophiques.

Cas — Fuite de données critiques 1 semaine avant go-live

Cas concret
Un projet de plateforme client est presque prêt à go-live. 1 semaine avant, le testeur découvre une fuite de données critique : un fichier CSV contenant 50 000 clients avec numéro de sécurité sociale, adresse, etc. a été exposé pendant 48 heures sur un serveur accessible via Google. Crise maximale : responsabilité légale RGPD (15M EUR d'amende potentielle), panique client, perte de confiance. Réaction du chef de projet : jour 1, sécuriser (bloquer accès), analyser (quelles données, combien de temps, qui d'autre avait accès ?), notifier la CNIL. Jour 2, lancer un audit de sécurité complet sur la plateforme. Jour 3, décider : on ne peut pas live dans cette situation. On repousse de 2 semaines le go-live, on fixe la faille, on re-teste tout. Impact : 100 k EUR de coûts supplémentaires, 2 semaines de délai. Mais on évite une amende RGPD et on live avec une plateforme sécurisée.
Cas concret
Cas — Fuite de données critiques 1 semaine avant go-live
Un projet de plateforme client est presque prêt à go-live. 1 semaine avant, le testeur découvre une fuite de données critique : un fichier CSV contenant 50 000 clients avec numéro de sécurité sociale, adresse, etc. a été exposé pendant 48 heures sur un serveur accessible via Google. Crise maximale : responsabilité légale RGPD (15M EUR d'amende potentielle), panique client, perte de confiance. Réaction du chef de projet : jour 1, sécuriser (bloquer accès), analyser (quelles données, combien de temps, qui d'autre avait accès ?), notifier la CNIL. Jour 2, lancer un audit de sécurité complet sur la plateforme. Jour 3, décider : on ne peut pas live dans cette situation. On repousse de 2 semaines le go-live, on fixe la faille, on re-teste tout. Impact : 100 k EUR de coûts supplémentaires, 2 semaines de délai. Mais on évite une amende RGPD et on live avec une plateforme sécurisée.

À retenir — Gérer les crises de projet

À retenir

À retenir

Chaque projet affrontera une crise : démission clé, bug critique, changement client, fuite de données. Le chef de projet doit avoir un protocole pour transformer le chaos en ordre : sécuriser l'immédiat, analyser vraiment, réunir crisis room et décider, communiquer avec transparence. La meilleure approche reste la prévention : identifier les risques majeurs tôt, mettre en place des mesures de redondance (pas de point unique de défaillance), cultiver une équipe résiliente. Le chef de projet qui gère les crises avec sang-froid gagne énormément de crédibilité et de respect.
À retenir
À retenir — Gérer les crises de projet
Chaque projet affrontera une crise : démission clé, bug critique, changement client, fuite de données. Le chef de projet doit avoir un protocole pour transformer le chaos en ordre : sécuriser l'immédiat, analyser vraiment, réunir crisis room et décider, communiquer avec transparence. La meilleure approche reste la prévention : identifier les risques majeurs tôt, mettre en place des mesures de redondance (pas de point unique de défaillance), cultiver une équipe résiliente. Le chef de projet qui gère les crises avec sang-froid gagne énormément de crédibilité et de respect.

Définition

Vocabulaire
Terme du cours
Carrière dans le digital
« Carrière » du latin « carrata » (voie, route) ; représente le parcours professionnel.
Progression de responsabilités et d'expertise d'un professionnel du digital au fil des années : junior, confirmé, senior, expert ou manager.
Votre carrière de chef de projet digital peut suivre deux chemins : une voie d'expertise (rester expert technique du pilotage, maîtriser les méthodes avancées, accompagner les juniors) ou une voie de management (progresser vers programme manager, directeur de projet, directeur de transformation). Les deux valent, le choix dépend de vos appétences. Quel que soit le chemin, les chefs de projet les plus respectés sont ceux qui livrent de la valeur de façon prévisible, qui apprennent des crises, et qui développent les autres.
Définition
Définition : Carrière dans le digital
Votre carrière de chef de projet digital peut suivre deux chemins : une voie d'expertise (rester expert technique du pilotage, maîtriser les méthodes avancées, accompagner les juniors) ou une voie de management (progresser vers programme manager, directeur de projet, directeur de transformation). Les deux valent, le choix dépend de vos appétences. Quel que soit le chemin, les chefs de projet les plus respectés sont ceux qui livrent de la valeur de façon prévisible, qui apprennent des crises, et qui développent les autres.

Les étapes : junior, confirmé, senior, expert

Notion clé
Une carrière en chef de projet s'échelonne typiquement sur 10-20 ans. Les deux premières années, c'est la phase d'apprentissage : on assiste un senior, on apprend les outils, on comprend comment l'organisation fonctionne. Ans 3 à 5, on devient autonome : on gère des projets de taille petite à moyenne en solo. Ans 6 à 10, on est senior : on prend des initiatives stratégiques plus complexes, on enseigne aux juniors. Au-delà de 10 ans, on devient expert : on conseille la direction sur la stratégie de transformation, on architecte le portefeuille de projets. À chaque étape, la compétence technique s'affine, mais aussi les soft skills : communication, influence, vision stratégique.
Notion clé
Les étapes : junior, confirmé, senior, expert
Une carrière en chef de projet s'échelonne typiquement sur 10-20 ans. Les deux premières années, c'est la phase d'apprentissage : on assiste un senior, on apprend les outils, on comprend comment l'organisation fonctionne. Ans 3 à 5, on devient autonome : on gère des projets de taille petite à moyenne en solo. Ans 6 à 10, on est senior : on prend des initiatives stratégiques plus complexes, on enseigne aux juniors. Au-delà de 10 ans, on devient expert : on conseille la direction sur la stratégie de transformation, on architecte le portefeuille de projets. À chaque étape, la compétence technique s'affine, mais aussi les soft skills : communication, influence, vision stratégique.

Cas — Parcours d'un junior vers senior en 8 ans

Cas concret
Portrait d'une trajectoire réelle. Alex débute en 2018 comme chef de projet junior chez une agence digitale, à 23 ans. Il assiste un senior sur des projets web et e-commerce de 50 à 200 k EUR. Il apprend Scrum, Jira, la gestion de budget. An 2, il pilote seul son premier projet. An 3, on lui confie un ERP de 3M EUR pour une PME industrielle : 6 mois, 8 personnes, 5 % d'imprévu. Il passe testées, livre à temps. L'expérience et la réussite le crédibilisent. An 5, il rejoint une grande organisation publique en tant que senior : il dirige un programme de 5 projets, budget 10M EUR sur 2 ans. Il enseigne les juniors, propose des améliorations des méthodes. An 8, il est reconnu comme expert en transformation digitale ; il est sollicité pour du conseil ou pour diriger l'ensemble de la direction IT d'une organisation. Son salaire a progressé de 30 à 65 k EUR, mais surtout sa responsabilité et son impact.
Cas concret
Cas — Parcours d'un junior vers senior en 8 ans
Portrait d'une trajectoire réelle. Alex débute en 2018 comme chef de projet junior chez une agence digitale, à 23 ans. Il assiste un senior sur des projets web et e-commerce de 50 à 200 k EUR. Il apprend Scrum, Jira, la gestion de budget. An 2, il pilote seul son premier projet. An 3, on lui confie un ERP de 3M EUR pour une PME industrielle : 6 mois, 8 personnes, 5 % d'imprévu. Il passe testées, livre à temps. L'expérience et la réussite le crédibilisent. An 5, il rejoint une grande organisation publique en tant que senior : il dirige un programme de 5 projets, budget 10M EUR sur 2 ans. Il enseigne les juniors, propose des améliorations des méthodes. An 8, il est reconnu comme expert en transformation digitale ; il est sollicité pour du conseil ou pour diriger l'ensemble de la direction IT d'une organisation. Son salaire a progressé de 30 à 65 k EUR, mais surtout sa responsabilité et son impact.

À retenir — Évoluer dans le digital

À retenir

À retenir

Votre carrière de chef de projet digital peut suivre deux directions : une voie de chef de projet expert (maîtriser les méthodes, accompagner les juniors, conseiller la direction) ou une voie de management (manager des équipes, diriger des programmes, évolution vers directeur de transformation). Les meilleurs professionnels du digital sont ceux qui livrent de la valeur de manière prévisible, qui apprennent de chaque crise, et qui développent les talents autour d'eux. La progression prend du temps (10-20 ans pour senior), mais elle est gratifiante : responsabilité croissante, impact stratégique, respect et stabilité.
À retenir
À retenir — Évoluer dans le digital
Votre carrière de chef de projet digital peut suivre deux directions : une voie de chef de projet expert (maîtriser les méthodes, accompagner les juniors, conseiller la direction) ou une voie de management (manager des équipes, diriger des programmes, évolution vers directeur de transformation). Les meilleurs professionnels du digital sont ceux qui livrent de la valeur de manière prévisible, qui apprennent de chaque crise, et qui développent les talents autour d'eux. La progression prend du temps (10-20 ans pour senior), mais elle est gratifiante : responsabilité croissante, impact stratégique, respect et stabilité.

Exercice — Cadrer un projet digital de A à Z

Exercice — à rendre

Consignes

Format attendu : Tableur Excel ou Google Sheets avec 4 onglets (cadrage, backlog agile, recette, risques)
Dépôt : Moodle, avant la séance suivante M2
Pondération : 15 % de la note du module
Cet exercice vous force à appliquer tout ce que vous avez appris : cadrer un projet en donnant des chiffres et des jalons, préparer l'approche agile avec des user stories estimées, anticiper la recette et les risques. Vous pouvez choisir un vrai projet ou utiliser le cas proposé : une PME qui veut refondre son site web et développer une app mobile pour ses clients. Livrables : un tableur avec cadrage complet, backlog agile, plan de recette, registre des risques. La qualité de votre cadrage détermine si le projet démarre sur de bonnes bases.
Exercice
Exercice — Cadrer un projet digital de A à Z
Cet exercice vous force à appliquer tout ce que vous avez appris : cadrer un projet en donnant des chiffres et des jalons, préparer l'approche agile avec des user stories estimées, anticiper la recette et les risques. Vous pouvez choisir un vrai projet ou utiliser le cas proposé : une PME qui veut refondre son site web et développer une app mobile pour ses clients. Livrables : un tableur avec cadrage complet, backlog agile, plan de recette, registre des risques. La qualité de votre cadrage détermine si le projet démarre sur de bonnes bases.

Sources & références

Bibliographie

Bibliographie et ressources officielles pour approfondir le métier.

Académique & universitaire
  • Schwaber K., Sutherland J. (2020) — Scrum Guide , Scrum.org
  • Project Management Institute (2021) — Project Management Body of Knowledge (PMBOK) , PMI
Livresque (Dunod prio)
  • Royce W. (2019) — Managing the Development of Large Software Systems , Addison-Wesley
  • Highsmith J. (2013) — Adaptive Software Development , Addison-Wesley Professional
Presse / synthèse
  • Forbes (2025) — The Future of Digital Project Management
  • Harvard Business Review (2024) — Agile Leadership in Digital Transformation
Webographie officielle
  • Syntec Numérique — Baromètre de l'activité et des salaires du secteur IT 2026
  • Scrum Alliance — Certifications Scrum Master et Product Owner
  • PMI — Programme de certification Project Management Professional (PMP)
  • CNIL — Guide du RGPD pour les projets numériques
Pour approfondir le métier de chef de projet digital, nous vous recommandons d'explorer ces sources de référence. Le Scrum Guide reste la bible de l'agilité, gratuit et en libre accès. Le PMBOK du PMI définit les standards mondiaux de gestion de projet. Les livres de Royce et Highsmith offrent des perspectives complémentaires sur l'agilité et la gestion adaptative. Les salaires et l'employabilité : consultez le baromètre Syntec Numérique chaque année. Enfin, les certifications Scrum Master (CSM) et Product Owner (CSPO) sont hautement respectées sur le marché.
Sources
Sources & références
Pour approfondir le métier de chef de projet digital, nous vous recommandons d'explorer ces sources de référence. Le Scrum Guide reste la bible de l'agilité, gratuit et en libre accès. Le PMBOK du PMI définit les standards mondiaux de gestion de projet. Les livres de Royce et Highsmith offrent des perspectives complémentaires sur l'agilité et la gestion adaptative. Les salaires et l'employabilité : consultez le baromètre Syntec Numérique chaque année. Enfin, les certifications Scrum Master (CSM) et Product Owner (CSPO) sont hautement respectées sur le marché.

Acronymes du cours

Annexe
POProduct Owner — responsable de la priorisation des fonctionnalités
SMScrum Master — facilite les cérémonies et élimine les blocages
UATUser Acceptance Testing — test utilisateur final par le client
MVPMinimum Viable Product — version minimale livrée rapidement
KPIKey Performance Indicator — indicateur clé de performance
ROIReturn on Investment — retour sur investissement
RGPDRèglement Général sur la Protection des Données
CdCFCahier des Charges Fonctionnel — spécifications détaillées
ERPEnterprise Resource Planning — progiciel intégré de gestion
SaaSSoftware as a Service — logiciel en mode cloud
Ces acronymes sont essentiels au métier de chef de projet digital. PO et SM sont les deux rôles clés en Scrum. UAT et MVP sont des concepts d'agilité. KPI et ROI mesurent la performance. RGPD guide la conformité légale. CdCF documentes les besoins. ERP et SaaS sont les types de projets que vous piloterez.
Acronymes
Acronymes du cours
Ces acronymes sont essentiels au métier de chef de projet digital. PO et SM sont les deux rôles clés en Scrum. UAT et MVP sont des concepts d'agilité. KPI et ROI mesurent la performance. RGPD guide la conformité légale. CdCF documentes les besoins. ERP et SaaS sont les types de projets que vous piloterez.

Lexique technique

Annexe
BacklogListe de toutes les tâches/features à faire, ordonnée par priorité
SprintPériode de travail agile de 1-2 semaines, bornée et prévisible
BurndownGraphique montrant les points de tâche restants au fil du sprint
VélocitéMoyenne de points réalisés par sprint, aide à prédire la fin
RollbackRevert à une version antérieure du code suite à problème
DériveÉcart entre planning réel et planning prévu (en jours ou %)
PérimètreEnsemble des livrables et fonctionnalités inclus dans le projet
EscaladeRemonter un problème non résolu à un niveau de décision supérieur
MitigationAction mise en place pour réduire l'impact d'un risque
Go-liveJour du déploiement en production, passage en service réel
Ce lexique capture les termes techniques que vous rencontrerez tous les jours. Backlog et sprint structurent l'agilité. Burndown et vélocité mesurent l'avancement. Rollback et go-live concernent la mise en production. Dérive, escalade et mitigation aident à gérer les problèmes. Maîtriser ce vocabulaire vous rend immédiatement crédible dans les réunions.
Lexique
Lexique technique
Ce lexique capture les termes techniques que vous rencontrerez tous les jours. Backlog et sprint structurent l'agilité. Burndown et vélocité mesurent l'avancement. Rollback et go-live concernent la mise en production. Dérive, escalade et mitigation aident à gérer les problèmes. Maîtriser ce vocabulaire vous rend immédiatement crédible dans les réunions.

Auto-test de fin de séance

Validation 80 %

Dix questions auto-corrigées. Seuil de validation : 80 %.

1. Quel est le rôle principal du chef de projet digital ?
  • a. Coder les fonctionnalités critiques
  • b. Cadrer, piloter et livrer un projet à temps et dans le budget
  • c. Évaluer les performances individuelles de l'équipe
2. Quel est le budget estimé pour une petite plateforme e-learning (500 users) ?
  • a. Environ 50 k EUR
  • b. Environ 150 k EUR
  • c. Environ 500 k EUR
3. Qu'est-ce qu'un sprint en Scrum ?
  • a. Une réunion de 15 minutes le matin
  • b. Une période de travail bornée, généralement 1-2 semaines
  • c. La fin du projet quand on démarre les tests
4. Combien de cérémonies Scrum majeures y a-t-il ?
  • a. 2 : daily et sprint review
  • b. 3 : planning, daily, review
  • c. 4 : planning, daily, review, retrospective
5. Quel outil est le plus courant pour tracer les user stories en Scrum ?
  • a. Excel
  • b. Jira (Atlassian)
  • c. Word
6. Qu'est-ce que l'UAT (User Acceptance Testing) ?
  • a. Test technique par les développeurs
  • b. Validation fonctionnelle par le client avec des scénarios réels
  • c. Test de performance en production
7. Quel pourcentage de projets IT dépassent le budget initialement estimé ?
  • a. Environ 15 %
  • b. Environ 30 %
  • c. Environ 45 %
8. Comment s'appelle la situation d'urgence qui menace les objectifs du projet ?
  • a. Retard banal
  • b. Crise de projet
  • c. Notification client
9. En combien de temps typiquement un projet digital atteint son équilibre financier (ROI positif) ?
  • a. 6 mois
  • b. 1 an
  • c. 2,1 ans
10. Quelle est la progression typique d'un chef de projet : junior → senior ?
  • a. 1-2 ans
  • b. 3-5 ans
  • c. 6-10 ans
Cet auto-test valide votre compréhension des concepts clés : rôle du chef de projet, chiffres budgétaires, méthodes agiles, outils, recette, performance et carrière. Révisez les sections où vous n'êtes pas sûr avant de valider le module.
Auto-test
Auto-test de fin de séance
Cet auto-test valide votre compréhension des concepts clés : rôle du chef de projet, chiffres budgétaires, méthodes agiles, outils, recette, performance et carrière. Révisez les sections où vous n'êtes pas sûr avant de valider le module.
Pour briller en société
«
Un projet n'échoue jamais à cause des outils ; il échoue parce qu'on n'a pas bien cadré ce qu'on voulait faire, et qu'on n'a pas communiqué honnêtement quand les choses déraillaient.
Adapté librement
0:00
0:00
1 / 58
Fiche métier — Boîte à outils opérationnelle

Boîte à outils — Chef(fe) de projet plateformes digitales

École de Commerce de Lyon — Groupe ECL  ·  Alternants digital  ·  Version 2026

1 Semaine type en sprint — daily cadencé, planning, exécution, rétro

Mode d'emploi : sprint = 2 semaines (lun-ven + lun-ven). Cette semaine type s'applique à un sprint standard (équipe 6-8 dev/design, ~100-150 points de charge). Ton rôle : cadencer cérémonies, arbitrer priorités, débloquer blocages, suivre budgets et délais.

Règle d'or : Réunions courtes, décisions rapides, risques détectés tôt. Un retard découvert lundi matin = escalade directeur mardi max. Pas de pseudo-transparence : si c'est rouge, tu dis rouge au sponsor même si c'est pas beau.

Lundi 9 h 00 – 17 h 00 — Sprint planning + kick-off équipe

HeureZoneCe que tu fais, concrètement
9 h 00 – 9 h 30 Cadrage Préparation : tu as revisualisé backlog du sprint (Jira ou Notion). Tickets triés par priorité (P0 bloquant, P1 critique, P2 important). Budget du sprint validé (jours/homme × tarif marché). Capacité équipe (6 dev × 8 j = 48 jours dispo, −20 % meetings/admin = ~38-40 jours réels de travail). Risques identifiés (préfab pas livrée ? Prestataire retard ? Client pas joignable ?)
9 h 30 – 11 h 30 Planning Sprint planning réunion (120 min) : toi + 6-8 dev/design + sponsor. Tu présentes roadmap 2-3 slides : où on était, où on va ce sprint, dépendances externes. Chaque ticket : taille estimée (1-5-8-13 points story), assigné à qui, risques. Équipe dit oui/non (« Vous pouvez livrer ça en 2 semaines ? »). Finale : 60-90 points charge validés pour le sprint.
11 h 30 – 12 h 00 Planning Break. Puis confirmation : email recap sponsor : « Sprint S24 : 8 stories, ~80 points, livrables attendus [liste]. Budget = X € HT. Livraison vendredi J+9 sauf découverte risque. Accord ? »
13 h 00 – 13 h 30 Planning Déjeuner rapide. Puis briefing équipe : qui fait quoi. Lead dev : prend 3 stories backend. Lead design : prend 2 stories UI/UX. Alternant junior : prend 1 story test/QA. Check : zéro story non-assignée.
13 h 30 – 14 h 30 Exécution Tech deep-dive : for each story, senior dev explique techno : quels services API, quels tests requis, dépendances internes. Tu notes blocages potentiels (« Y a besoin d'accès base de données, on a ? » « T'as schema prestataire X, tu as ? »). Resolutionning immédia : « Je te give access à midi ».
14 h 30 – 16 h 30 Exécution Équipe commence dev. Toi : tu update Jira backlog (meta pour chaque ticket : assigné, priorité, sprint S24). Tu crées tableau Notion « Sprint S24 — tracking ». Colonnes : ticket, assigné, status (not-start / in-progress / review / done), blocages, ETA. Visible pour sponsor et équipe. À jour chaque jour.
16 h 30 – 17 h 00 Risque Réunion « Risques sprint » : y a des trucs qui vous inquiètent ? Lead dev : « Prestataire Figma pas confirmé design system ». Toi : escalade immédiate, email sponsor urgent : « Design system validation needed before wed, sinon retard. »

Mardi – Vendredi (semaine 1 du sprint) — Daily standup 15 min, déblocage continu

HeureZoneCe que tu fais, concrètement
10 h 00 – 10 h 15 Exécution Daily standup (15 min rituel) : équipe stand, tour de table rapide. Chacun : hier j'ai fait quoi (1 ligne), aujourd'hui je fais quoi (1 ligne), blocages ? Pas de « bonjour, ça va ? », juste facts. Si blocage : tu la note (« Auth service pas ready »), tu dis « on résout après le standup ».
10 h 15 – 10 h 30 Risque Déblocage (après standup) : les 3-4 blocages notés, toi tu les traites : call prestataire, get accès base data, escalade sponsor. Notes résolution dans Notion. Update Jira status pour chaque ticket affecté.
Matin, après Exécution Équipe bosse. Toi : tu chécks Jira/Notion tous les midis (13h30) : progress ok ? Velocity tracking ok ? Tickets movés dans « in-progress » ? Si ticket reste « not-start », tu demandes pourquoi.
14 h 00 – 15 h 00 Planning Rétro rapide du jour : 15 min async : what worked / what didn't / TODO tomorrow (tu le fais dans Notion doc). Plus rapide, zéro meeting fatigue.
Fin d'après Risque Si retard découvert (ex: story est Q sûr à finir jeudi, pas vendredi), tu escalades : email sponsor, call si critique. Plan B : descope? Repush S25? Budget revise?

Mardi – Jeudi (fin jour, ~17h) — Code review, tests, intégration continus

HeureZoneCe que tu fais, concrètement
17 h 00 – 17 h 30 Exécution Review + intégration : lead dev pull story en staging (env test). Toi : tu dois vérifier qualité. Checklist rapide (5 min par story) : code review done ? Tests passent 100 % ? Logs propres ? Deploy strategy documenté? Si vert, tu approves « Ready for prod friday ».
Jeudi soir Exécution Staging QA final : alternant junior fais 30 min smoke test (« Est-ce que les features base marchent ? Pas de crash ? Pas d'erreur 500 ? »). Screenshot « tout fonctionne ». Fichier Excel risques : P1 bugs si trouvés = fix avant prod, P2 = accepté ou post-prod.

Vendredi 9 h 00 – 17 h 00 — Déploie prod + clôture de sprint

HeureZoneCe que tu fais, concrètement
9 h 00 – 10 h 00 Exécution Deploy prep : tu vérifies checklist: rollback plan doc ? Feature flags testé (so we can disable). DB migrations appliquées staging ok ? CDN purged. Monitoring alerts wired. Comms client ready (« Features live at 11am CET »). Lead dev : « Go/No-Go ? » Go or No-Go.
10 h 00 – 10 h 30 Exécution Production deployment : lead dev triggers deploy. Toi : tu watches logs real-time. Si erro, tu calls rollback immédiat. Si ok, tu posts message client channel : « Features live. Testing now. »
10 h 30 – 12 h 00 Exécution Post-deploy smoke test : équipe accès prod. Tu + lead dev + alternant : tester 15 min les flows critiques. Rien cassé ? Metrics up (page load time, error rate) ? Si tout vert, tu notify sponsor : « Features stable, production validated. »
14 h 00 – 15 h 30 Planning Rétro sprint (90 min, core team) : qu'est-ce qui a bien marché ? Retards ? Pourquoi ? Quality ok ? Velocity (points delivered vs planned). Tu prépares slides factos : « S24 : 85 points planifiés, 78 points livrés. 1 story descoped (API prestataire retard). 0 P1 bugs en prod. » Puis : action items pour S25.
15 h 30 – 17 h 00 Planning Email sponsor : recap sprint. Livré, qualité, budget consommé. Points pour améliorations S25. Et : « Kick-off S25 lundi 9h, prep doc prêt dimanche soir. »
Truc de pro : garder Excel tempo projet : par sprint, combien de points planifiés vs livrés (velocity tracking). Après 3 sprints, tu as un pattern : si équipe fait toujours 70 points et toi tu promises 90, c'est pas l'équipe qui est lente, c'est toi qui estimes mal. Escalade délais avant ça va exploser en prod.
↑ Retour au sommaire

2 13 scripts mot à mot — cadrage flou, refus, retard, daily, recadrage, rétro, comité…

Mode d'emploi : ces scripts gèrent les moments politiques du rôle. Lis-les à voix haute pour mémoriser ton ton. Les variables entre [crochets] varient (noms, durées, montants). Chaque script a un but : clarifier périmètre, arbitrer conflits, remonter mauvaises nouvelles sans perdre crédibilité.

Cadrage client

Script 1 — Cadrage avec client flou (kick-off réunion)
Client : directeur digital, demande plateforme « transformée digitale ». Trop vague. Toi + sponsor : tirer la ficelle, clarifier.
TOI : Merci [Monsieur Lebrun] de nous recevoir. Vous dites « transformation digitale plateforme ». Je vais demander des questions bêtes pour qu'on finisse avec un accord sur le même truc. 1. Utilisateurs cible : qui va utiliser la plateforme ? 100 ? 1000 ? Internes ou publics ? [CLIENT RÉPOND] « Ok [500 vendeurs en boutique]. » 2. Périmètre fonctionnel : on fait quoi dans la plateforme ? Gestion stocks ? Commandes clients ? Reporting ? [CLIENT RÉPOND, tu notes] 3. Calendrier : quand vous voulez c'est ready ? 6 mois ? 1 an ? Et go-live quand ? [CLIENT RÉPOND] « [Septembre 2026], ok. » 4. Budget : vous avez chiffre en tête ? ~500k ? ~1M ? (Toi tu penses : senior dev/UX/PM = ~80k€/mois, donc 6 mois = ~480k.) [CLIENT RÉPOND] « Pas de chiffre fixe, you have flexibility. » « Ok. Donc : 500 vendeurs internes, features X-Y-Z, deadline sept, budget flexible mais raisonnable. Ça veut dire équipe 8 personnes, 6 mois, ~500k. Sponsor [Marc], ça te va ? [SPONSOR VALIDE] On envoie brief détaillé demain, vous validez jeudi, on démarre lundi. Accord ? »
Script 2 — Refuser une demande hors périmètre (en sprint)
Sponsor : « Y a besoin d'intégrer le système legacy Z dans le projet. » Hors périmètre, retardera tout. Toi : tu dois refuser poliment mais fermement.
SPONSOR : « On vient d'apprendre : faut que la plateforme talk au système legacy RH. C'est critique. » TOI : Je comprends. Legacy RH, c'est important. Mais regardons l'impact : on a sprint qui ferme vendredi, 78 points charge. Intégration legacy = ~20 points, 1 semaine de travail. Ça veut dire soit : Option A : on descope une story cette semaine (laquelle tu veux laisser tomber ? Reporting dashboard ? Login 2FA ? ) et on le prends legacy. Option B : on repush legacy en S25 ou S26. Option C : on allonge le sprint (coût +20 %, deadline repush), on fais tout. Qu'est-ce que tu préfères ? Mais y a pas d'option D (« fais les trois sans impact »). »
Script 3 — Annoncer un retard au sponsor (escalade urgente)
Lead dev te dit jeudi 16h : API prestataire pas livrée (attendu mardi dernier). Ça bloque 3 stories. Livraison vendredi = impossible. Toi : tu dois annoncer au sponsor avant qu'il l'apprenne ailleurs.
« [Sponsor], appel urgent. Situation : API prestataire qu'on attendait mardi = toujours pas livrée. 3 stories bloquées. Livraison prevue vendredi = on peut pas la faire. Plan B : on descope les 3 stories bloquées (28 points), on livre 50 points demain (autres trucs prêts). Ça nous donne 2 options : 1. Descope jeudi, livrer demain les 50 points, push 28 points en S25. On perd 1 semaine, mais pas chaos. 2. Attendre API jusqu'à lundi (prestataire promet), risquer plus de retard. Plan worst case : 3 semaines dérive. Je recommande option 1 (descope jeudi). Ça te va ? »

Exécution et déblocage

Script 4 — Daily standup type (ce qu'on dit/ce qu'on ne dit pas)
Standup quotidien 15 min. Pas une séance « bisous coucou », juste facts.
DEV 1 : Hier j'ai fini intégration auth. Aujourd'hui je passe test. Blocages : non. DEV 2 : Hier j'ai commencé API payment. Aujourd'hui suite. Blocages : oui, faut accès base prod — [Tom] tu peux donner accès avant midi ? TOM : Oui, 10h. DEV 2 : Merci. DESIGN : Hier refinement comps. Aujourd'hui handoff à dev. Blocages : non. TOI (résumé 30 sec) : Merci. Donc : auth done, payment in progress, design on track. Bloc accès DB = résolu. On suis velocity ok ? (Check Jira) Oui, 18 points hier, on était à 15-17 target, bon. Mercredi nous rencontrons sponsor 10h pour comms feature preview. Quelqu'un a questions ? Non. OK demain même heure. »
Script 5 — Recadrer un prestataire en retard (mail ferme mais pro)
Prestataire design devait livrer wireframes lundi. Jeudi, toujours rien. Ça bloque le dev. Toi : tu dois escalader sans perdre la relation.
« [Raphael], on a un pb. Wireframes étaient dues lundi. Jeudi 16h, on les a pas. Ça bloque l'équipe dev (3 personnes en attente). Impact budget : +3 jours de coût (~3k€). Je comprends t'as had challenges. Mais faut qu'on soit réalistes : 1. Si tu peux livrer demain (vendredi 17h max), on continue. Risque on accepte (un peu tight). 2. Si tu sais pas, faut qu'on te replaçons (autre prestataire, même prix/qualité). Qu'est-ce que c'est? »

Gestion de réunions critiques

Script 6 — Présenter status à un comité de pilotage (5 min, chiffres réels)
Comité mensuel sponsors. Toi : présente status projet en 5 min flat. Slides : budget, timing, qualité, risques.
« Bonjour. Projet plateforme digitale, juin status. Périmètre : 500 vendeurs, 12 modules, go-live Sept 2026. Avancement : S22-S24 = 3 sprints done, 240 points livrés (plan 220, donc +9 % velocity). 8 sprints left avant septembre. Budget : Budget plan 500k, dépense 125k après 6 semaines (25 % consommé, on track). Qualité : 0 P1 bugs en prod, 6 P2 bugs post-deployment (normal, accepté). Risques : 1 amber : prestataire intégration legacy = 1-2 semaine de retard possible. Plan B : pousser legacy en wave 2 (post go-live). Actions pour vous : Approval descope legacy wave 1 ? Ou attendre ? » [SPONSOR RÉPOND, VALIDE] « Merci. Next check-in dans 2 semaines. D'autres questions ? »
Script 7 — Animer une rétrospective sans que ce soit déprimant (feedback constructif)
Rétro sprint : équipe a travaillé dur mais y a eu frictions. Toi : tu dois extraire learnings sans que personne se sente jugé.
« Rétrospective S24. Merci tout le monde pour ce sprint. On a livré 78 points, qualité ok, 0 P1 bugs. Félicitations. Maintenant, réflexe : qu'est-ce qui pourrait être mieux ? Colonnes Miro : What went well / What didn't / Action items. Vous vous écrivez anon pendant 5 min (pas jugement, juste vérité). » [5 min de silence, équipe écrit] « Ok, lisons. What went well : « Daily stand super court, gagnons 20 min/jour. » « Code review rapide, pas blocages. » Merci, on garde. What didn't : « Sprint planning trop long, 2h30 trop. » « Prestataire communication lent. » « Je sais pas quand story fini, floue. » Ok. Actions pour S25 : 1. Sprint planning 90 min max (pas 2h30). 2. Prestataire : j'escalade (ça c'est mon pb). 3. Criteria of done : clarifier (Jira template — tu sera prêt lundi). Ça vous go ? (Thumbs up du monde). Good. »
Script 8 — Négocier un chiffrage avec un prestataire (ferme mais fair)
Prestataire design demande 900 €/jour pour design system. Tu sais que marché c'est 600-800 €. Toi : tu dois négocier sans perdre qualité.
« [Sarah], merci pour ta devis. Design system 40 jours = 36k€ (@900 €/j). Je comprends c'est du travail de qualité. Mais regardons le marché : senior design France 2026 = 600-800 €/jour en agence, 800-1000 € freelance très senior. Toi tu demandes 900, donc upper range. Fair, mais j'ai pas budget là-dedans. Deux options : 1. Toi = 700 €/jour, ça fait 28k€, c'est dans budget. Ou tu dis « c'est low, je peux pas faire ». 2. Scope réduit : design system (pas intégration dev), donc 20 jours non 40. Ça fait 18k€ @900€/j. Intégration dev = on fait nous-même après. Laquelle vous préférez ? »
Script 9 — Clarifier une dépendance externe floue (prestataire/vendor)
Dev dit : « On attend API payment tiers (Stripe intégration). » Tu sais pas si c'est confirmé quand. Toi : tu dois clarifier le commitment.
« [Lead dev], API payment est bloquant story S24-15 (checkout) ? Quand on a besoin ? Et vendor a confirmé quelle date ? [DEV] : « On a besoin dans 2 semaines. Vendor a pas dit de date, juste « on travaille dessus ». » Pas bon. On a pas commitment date. Moi je vais call vendor today : « You need to confirm : API ready when ? And in writing (email sig). We can't build blind. » Si y répondent pas clear, on plan B : on simule payment fake (pas real Stripe pour cette phase), on l'intègre pour real later. Je te donne update cette après. »
Script 10 — Annoncer une mauvaise estimation (timeline réaliste)
Équipe dig lundi 9h : « La story auth est plus complexe qu'on pensait. Au lieu 5 jours, c'est 10 jours réels. » Ça impacte timeline. Toi : tu dois annoncer vite au sponsor.
« [Sponsor], situation S24. Story auth qu'on estimait 5 jours = c'est 10 jours réels (découverte lundi). C'est une dériv +100 %, pas accepté. Pourquoi ? (Lead dev explique) : « Legacy auth system v3 n'a pas docs. On a dû reverse-engineer. Plus de edge cases que prévu. » Ok. Options : 1. Descope auth (user login next sprint), livrer features sans auth S24 (testing only). Gain 5 jours, mais auth critique, pas ok. 2. Push timeline S24 vendredi → mercredi semaine d'après (+3 jours). Impact : go-live repush 3 jours. Budget +15k€. 3. Add dev (embauche contract dev 10 jours), parallelize. Budget +7k€ mais timeline = non-impacté. Je recommande option 3 (contract dev). Ça va ? » [SPONSOR RÉPOND]
Script 11 — Escalade risque mineur (amber, pas alerte rouge)
Prestataire infra dit : « Migration base de données pourrait avoir downtime 30 min (pas 5 min comme prévut). » C'est pas catastrophe mais impacte go-live window. Toi : tu dois tracker mais pas panicker.
« Prestataire infra dit : BD migration = 30 min downtime au lieu 5 min plan A. Ça change notre go-live window. Plan A était : dimanche 2am (weekend, trafic low). 5 min downtime = acceptable. Si 30 min : users ne peuvent pas accéder 30 min. Sponsor veut pas ça. Plan B : on fais canary deploy (10 % users d'abord, watch errors, puis 100 %). Zéro downtime. Mais testing plus long (mercredi-vendredi + staging test dimanche). Ça marche pour nous. On va plan B. Prestataire infra : tu es ok ? [Infra lead oui]. Sponsor : approval plan B ? »
Script 12 — Défendre approche agile vs waterfall (vis-à-vis client/sponsor)
Sponsor old-school dit : « Pourquoi vous pas me livrer un cahier des charges COMPLET avant de coder ? Agile c'est du chaos. » Toi : tu dois l'éduquer sans l'insulter.
« Question légitime. Voilà pourquoi agile fonctionne mieux ici : Waterfall : on écrit 200 pages specs, client signe. Puis on code 6 mois. Livraison : client dit « c'est pas ce que je voulais ». Trop tard, c'est déjà code. Agile : on écrit 1-2 pages brouillon specs. On code 2 semaines. Chaque vendredi, vous voyez feature live (en staging). Vous dites « oui, c'est bon » ou « change ça ». On pivot. Résultat : fin de projet, c'est EXACTEMENT ce que vous vouliez. Exemple concret : spec dit « search produit ». Waterfall : code 6 semaines, client : « Ah mais je voulais facets par category ! » Boom, 2 semaines re-engineering. Agile sprint 1 : « Voilà search basique. » Client : « Oh, faut facets. » Sprint 2 : « Facets added. » Ça bon pour vous ? »
Script 13 — Communication changement de scope en mid-project (pas un shock)
Client dit semaine 4 : « On voudrait ajouter feature reporting qu'on pensait pas avant. » C'est hors périmètre original. Toi : tu dois dire « possible mais coûte X ».
« Feature reporting, bonne idée. Mais regardons impact : reporting = 15-20 points charge, donc 3 sprints, donc ~25k€ + délai. Trois options : 1. Ajouter maintenant : go-live repush +3 semaines, budget +25k€. 2. Wave 2 (post go-live) : on livre features core en sept comme prévu. Reporting on fait en octobre (bonus). Zéro delay, budget +25k€ mais pas urgence. 3. Version light reporting (dashboards simple, pas custom export) : ~8 points, ~10k€, on peut fit dans sprint 6 (août). Plus light que full, mais couvre 80 % use-cases. Qu'est-ce que préférez vous ? »
↑ Retour au sommaire

3 4 procédures pas-à-pas chiffrées — cahier des charges, backlog Jira, planning Notion, recette

Mode d'emploi : chaque procédure est détaillée avec exemples réels, durées, coûts. Imprimer la section 3 et garder sur le bureau.

Procédure 3.A — Rédiger un cahier des charges projet (8 sections, 3 jours)

Cas exemple : Plateforme digitale 500 vendeurs, 500k budget, go-live sept 2026.

  1. Jour 1 — Structure (4h) : Ouvre Google Doc template. Sections : 1) Contexte client (business case, objectifs), 2) Utilisateurs (500 vendeurs, 10 managers), 3) Périmètre fonctionnel (12 modules), 4) Contraintes (compliance, perf), 5) Architecture tech (stack proposée), 6) Timeline (semaine par semaine, 26 semaines), 7) Budgets (€ par phase), 8) Risques (avec mitigations).
  2. Jour 1 soir — Contenu (4h) : Tu remplis de brouillon. Chaque section : bullets concis (pas prose), exemples concrets chiffrés (« Module gestion stocks = 40 points, 1 semaine dev »). Référentiel tech validé par lead dev (« On utilise React + Node »).
  3. Jour 2 — Revue interne (4h) : Lead dev, lead design, lead QA lisent. Feedback: tech réaliste ? Timeline serré mais faisable ? Budgets match effort ? Révisions.
  4. Jour 2 après-midi — Validation sponsor (2h) : Sponsor lit, valide contenu. Email : « Cahier des charges validé, on peut le montrer client. »
  5. Jour 3 — Présentation client (4h) : Call 90 min : toi + lead dev + sponsor. Toi : présente 30 min (slides ou doc partagé), contexte → périmètre → timeline → budget. Client : questions, amendements. Notes tout. Email : « Prochaine étape : vous validez, on affine les détails, on démarre quand ? »
  6. Jour 3 soir — Finalization (2h) : Intègre feedback client dans cahier des charges version 2. Signature électronique client (DocuSign ou juste email « J'approuve »). Archiver PDF final dans repo projet.

Procédure 3.B — Monter un backlog dans Jira (étapes, 2 heures)

Prérequis : compte Jira (gratuit pour équipe < 10 personnes, sinon ~700 €/an).

  1. Étape 1 — Créer projet : Jira + Create project → Agile Scrum. Nom : « Plateforme Digitale ». Key : « PLAT ». Team : 8 personnes assignées. Sprint duration : 2 semaines.
  2. Étape 2 — Configurer champs : Project settings → Issue types. Ajouter champs custom : Story Points (1/2/3/5/8/13), Priority (P0/P1/P2), Epic link. Et champ « Assigné à quoi » (backend / frontend / design / QA).
  3. Étape 3 — Créer Epics : Create → Epic. Exemple : Auth (login, 2FA). Gestion stocks. Reporting. Intégration legacy. Chaque epic = 1 major feature.
  4. Étape 4 — Créer user stories sous chaque epic : Ex. Epic « Auth » : Create → Story. Title : « As a vendor, I can login with email/password ». Description : acceptance criteria listet (« User can enter email, password, system validates DB, creates session »). Points : 5. Assigné : lead dev auth.
  5. Étape 5 — Trier backlog : Drag-drop stories dans ordre priorité (P0 top). Jira : Backlog → sort by priority. Save.
  6. Étape 6 — Créer sprint 1 : Create sprint. Drag top 60-80 points stories dans S1. Start date : lundi, end date : vendredi +1 semaine.

Procédure 3.C — Construire un planning avec jalons dans Notion (gantt, 3 heures)

Outil : Notion gratuit (1 workspace, 10 pages) ou Notion Pro (10 €/mois, database illimité).

  1. Étape 1 — Template Gantt : Notion : + New database → Timeline. Name : « Project Timeline S1-S8 ». Champs : Task name, Start date, End date, Assigné, Status (not started / in-progress / done), Priority.
  2. Étape 2 — Créer jalons : Ajoute rows : « S1 sprint (Sept 1-14) », « S1 review (Sept 14 15h) », « Integration tests (Sept 15-20) », « Staging QA (Sept 21-30) », « Go-live (Sept 30) ». Pour chaque : dates start/end, assigné (toi, lead dev, lead QA selon phase).
  3. Étape 3 — Ajouter dépendances : Notion timeline : if task A ends, task B starts. Exemple : « Code done Sept 20 » → « QA starts Sept 21 ». Notion render gantt visual automatiquement.
  4. Étape 4 — Partager (clients peuvent voir) : Notion Share → Get shareable link → Read-only. Email client : « Voilà le planning live, vous pouvez follow avancement semaine par semaine. »

Procédure 3.D — Dérouler une recette (plan de tests, 1-2 jours)

Contexte : Feature prête en staging. Avant prod, faut tester 100 % des cas (normal + edge cases).

  1. Matin — Préparation (2h) : Toi + QA lead + lead dev. Créer « Test plan » Excel : pour each user story / feature, rows = test cases. Ex. Feature « Login » : test case 1 = « Valid email + password → login success ». Test case 2 = « Invalid password 5x → account locked ». Test case 3 = « 2FA SMS reçu, code enter → access ». Pour chaque : expected result, bug priority si fail (P1 blocker / P2 accepté).
  2. Matin 10-13h — Exécution tests : QA alternant lance chaque test case dans staging. Pass ou fail ? Screenshot si fail. Reporte dans Excel : « Pass » ou « FAIL — [bug description] — [P1/P2] ».
  3. Après-midi — Triage bugs : Toi + lead dev review bugs trouvés. P1 (bloquant prod) = faut fix avant deploy. P2 (accepté) = ok, track dans post-go-live bugs. Exemple : « Login SMS code expire après 5 min » = P1. « Dashboard tooltip text typo » = P2.
  4. P1 fixes : Lead dev fix, QA re-test (1-2h turnaround). Sinon, don't deploy.
  5. Fin jour — Déc de go/no-go : QA lead : « All P1s passed, 3 P2s logged, staging stable ». Toi : « Go for prod deploy tomorrow ». Email sponsor : « Recette complète, qualité ok, on est green. »
↑ Retour au sommaire

4 Tableau de bord projet — avancement, vélocité, budget, bugs

Mode d'emploi : ce tableau tu le updates chaque jour (15 min). C'est ton cockpit : tout ce qui compte (budget, timing, qualité) visible d'un coup. Sponsor le consulte quotidien.

Tableau de bord — 7 KPIs clés (Excel ou Notion)

KPIFormule / CalculTargetRéel (S24)Commentaire / Action
Avancement % (Points livré / Total points sprint) × 100 100 % 86 % (78/90 pts) On track. 1 story descoped (prestataire retard). 12 pts push S25.
Vélocité Points livrés S24 vs S23 vs S22 (moving avg) 75-85 pts/sprint S22: 80 pts, S23: 76 pts, S24: 78 pts Stable, trend ok. Projet peut pas promet 90 pts/sprint vu cette velocity.
Budget consommé (Jours facturés / Budget total) × 100 ~25 % après 6 sem 24 % (125k / 500k) Green. On a buffer 5k€ (contingency ok).
Bugs ouverts P1 ouverts + P2 ouverts P1: 0, P2: <5 P1: 0, P2: 3 Ok. 3 P2s : « Dashboard load slow », « Email typo », « Mobile UX edge case ». Post-go-live fix ok.
Test coverage Tests écrites / Acceptance criteria >=80 % 75 % Amber. Lead QA : need +5 tests pour edge cases. Action S25.
Satisfaction sponsor Sponsor « ok » ou « alerte » weekly check « OK » « OK » Last week sponsor confirmed : « Timing ok, no scope creep detected, happy. »
Dependencies blocker External APIs / Prestataires = on-time ? 0 bloquants 1 amber Prestataire design : 1 week late (mitigated). Legacy API : on track. Monitoring.
Règle d'or : Si une métrique passe rouge (budget dérive >10 %, velocity <70 pts, P1 bug), tu escalades sponsor même soir. Pas d'attendre lundi.
↑ Retour au sommaire

5 Grille d'évaluation prestataire — 20 points critiques

Mode d'emploi : tu utilises cette grille avant de commander un prestataire (dev, design, QA, infra). Chaque critère = point ou demi-point. Score final = 16+ = ok, 12-15 = risque, <12 = passer.

Grille 20 points (notation /20)

Critère évaluationNotation
1Expérience tech requise : a-t-il fait des projets similaires (stack React, Node, Docker) ? Preuves (portfolio, refs clients).☐ /2
2Méthodologie agile : Scrum certification ou >2 ans expérience prod. Parle-t-il sprints, rétrospectives ?☐ /2
3Processus QA : a-t-il processus test automatisé ? TDD mentionné ? Ou juste « on teste manuellement » ?☐ /2
4Communication : clear, répond mails <24h, peut faire calls réguliers (pas ghosting) ? Check avec refs clients.☐ /2
5Pricing transparent : a-t-il devis clair, pas de « ça dépend » flou ? Coût par jour ou T&M bien défini ?☐ /2
6Délais respectés : ask refs : « il a jamais dépassé deadline de >20 % ? ». Ou track record mauvais = red flag.☐ /2
7Escalade risques : dit-il proactivement « attention, ce truc va être serré » ? Ou il attend que ça explose ?☐ /1.5
8Coût vs marché : TJM dev senior marché 2026 = ~600-800 €. Il demande 800 € ? Ok. 1200 € ? Chère. 300 € ? Risqué (rookie ou scam).☐ /1.5
9Disponibilité immédiate : peut il commencer lundi ? Ou « je suis busy jus qu'à octobre » ?☐ /1
10Apprentissage tech maison : il bosse avec vos outils (Jira, Notion, Slack) sans traing ? Ou faut 1 semaine onboard ?☐ /1
TOTAL☐ /20

Interprétation : 16-20 pts = hire (excellent fit). 12-15 pts = interview plus avant, checklist risques. <12 pts = pass, chercher ailleurs. Exemple : prestataire 14 pts mais « risqué timing » = tu lui donnes trial 1-2 weeks (petit module test) avant engagement long terme.

↑ Retour au sommaire

6 8 prompts IA — user stories, comptes rendus, plans de tests

Mode d'emploi : copie-colle ces prompts dans Claude/ChatGPT. Adapte les variables [entre crochets]. IA génère brouillon, tu édites pour cohérence projet.

Prompt 1 — Écrire une user story bien structurée (format agile)
Tu es chef de projet agile. Écris une user story pour plateforme e-commerce.

Contexte : vendeurs en boutique besoin chercher produit dans inventaire centralisé.

Écris user story format :
— As a [role], I can [action], so that [business value].
— Acceptance criteria : 5-7 bullets (testable, non ambigu).
— Estimation : quand tu penses ça prend combien de jours dev ? (1-5 days = story points 3-5).
— Dependencies : APIs a l'appel ? DB schemas Ok ?

Réponse :
Prompt 2 — Générer un compte rendu réunion (PV structuré)
Réunion juste eue : kick-off sprint S24 (90 min, 10 pers). Moi je pense points clés mais je voudrais bien structuré.

Points discutés :
— Périmètre : 8 stories, ~85 points charge.
— Risques : prestataire design late 1 week (impact story 3-4).
— Budget : ~11k€ pour sprint.
— Timeline : livraison vendredi, pas de delay.

Génère un PV formalisé (sections : attendants, périmètre, décisions, actions, risques, next steps). Format : document pro, pdf-ready (Markdown ou simple HTML). Tone : factuel, pas fluff. Max 1 page.
Prompt 3 — Lister des cas de test (test plan exhaustif)
Feature : « Vendor can search product in inventory ». Inputs : product name, SKU, category. Output : matching products list (name, stock qty, location, price).

Génère test cases exhaustif. Format :

# Test Case 1
— Description : Happy path search
— Precondition : vendor logged in, inventory DB has 100 products
— Steps : 1. Enter product name « shoes ». 2. Click search. 3. Observe results.
— Expected : « 12 shoes products shown, each with qty, location, price ».
— Type : functional
— Priority : P1 (critical)

# Test Case 2 ... (7-10 total cases, covering happy path + edge cases + error scenarios).

Générer :
Prompt 4 — Rédiger une escalade risque (alert sponsor)
Problème identifié : API payment tiers (Stripe) pas certifiée pour notre stack Node.js v18. Ça peut bloquer paiement feature (story S24-15). Découvert aujourd'hui (mercredi), livraison prevue vendredi.

Écris email escalade sponsor (court, factos, plan B clair). Format :
— What's the pb ? (1-2 lines)
— Impact ? (timeline/budget)
— Plan A (ideal) vs Plan B (fallback)
— Decision needed by ? (time)
— Recommendation

Tone : pro, pas panique, solutions-oriented. Max 200 mots.
Prompt 5 — Générer un budget détaillé par sprint (forecast)
Projet : 8 sprints, équipe 8 pers (6 dev, 1 design, 1 QA). Budget total : 500k€.

Chaque sprint est ~2 semaines. Dev senior = 700€/j, dev junior = 400€/j, design = 600€/j, QA = 500€/j.

Sprint 1-3 : focus backend, heavy dev hours.
Sprint 4-6 : frontend + integration.
Sprint 7-8 : QA, stabilization, launch prep.

Génère budget par sprint (table) : who, how many days, cost per person, total sprint cost. Et cumulative (total spent after S1, S2, ... S8).

Format : Excel-friendly table (copy-paste ready).
Prompt 6 — Écrire un checkliste de déploiement production
Feature « Payment integration » est ready en staging. Avant go-live prod, je dois checklist déploiement.

Génère checklist (items à cocher) :
— Technical readiness (code review, tests, monitoring)
— Ops readiness (rollback, runbooks, on-call schedule)
— Communications (customer notice, status page)
— Post-deploy (validation, metrics, support)

15-20 items, chaque bien spécifique (pas juste « tested », mais « payment flow tested with 5 cards, all succeed »).

Format : Markdown with ☐ checkboxes. Ready to print/screenshot.
Prompt 7 — Synthétiser un rapport qualité sprint (metrics)
Sprint S24 vient de finir. Data que j'ai :
— 78 points delivered (planned 90).
— 0 P1 bugs in prod, 3 P2 bugs.
— 2 bugs found in QA staging (fixed before prod).
— Velocity : 78 pts this sprint, 76 last sprint, 80 two sprints ago.
— Morale check : team happy, no attrition.
— Customer feedback : positive (3/5 stars in pilot).

Écris rapport qualité 1-pager synthétisant data. Sections : KPIs (tableau), Analysis (what went well, risks), Recommendations (S25 focus).

Tone : executive summary, factos, actionable.
Prompt 8 — Générer une matrice RACI (responsabilités projet)
Projet plateforme 500 vendeurs, équipe :
— Sponsor : client directeur digital
— PM (moi)
— Tech lead (dev senior)
— Design lead
— QA lead
— Prestataire infra

Activités clés : sprint planning, code review, QA gate, budget approval, client comms, ops/deployment.

Génère matrice RACI (Responsible, Accountable, Consulted, Informed) :
— Rows : chaque activité
— Columns : chaque role
— Cells : R/A/C/I (ou vide si not involved).

Format : table, copy-paste Excel.
↑ Retour au sommaire

7 Check-list mise en production et tableau « Combien ça coûte »

Mode d'emploi : section 1, remplis check-list jour du déploiement. Tous les ☐ doivent être ☑. Section 2, prix réels 2026 pour budgétiser outils projet.

Check-list finale avant déploiement production (jour J-1)

  • Code review : tous les commits approuvés, pas de TODOs laissés, refactoring terminé.
  • Tests automatisés : 100 % tests passent, coverage >=80 % des fonctionnalités critiques.
  • Staging QA : feature testée complètement en staging (happy path + edge cases), 0 P1 bugs.
  • Performance : load testing effectué, page load time < 2 sec, pas de N+1 queries, CDN ready.
  • Monitoring : alertes configurées (error rate, latency, DB connection pool), on-call schedule activé.
  • Rollback plan : documentation écrite, mock rollback testé lundi, runbook disponible.
  • Database : migrations tested en staging réplica, backup pris avant déploiement.
  • Feature flags : flags wired (so we can disable without redeploy si pb).
  • Security : aucune credentials en code, secrets dans env vars, HTTPS enforced.
  • Documentation : README deploy updated, runbook ops disponible, tech stack documenté.
  • Client comms : sponsor notifié heure déploiement, support team briefé, known issues doc.
  • Vendor sign-off : prestataire QA/infra : « go/no-go », email timestamp.

Tableau « Combien ça coûte » : budgets réels outils gestion projet 2026

Outil / LicencePrix annuelModèleQuand l'utiliser
Jira Cloud 0 € (< 10 pers), 800 €/an (10 pers) SaaS abonnement Backlog, sprints, tickets, release management. Standard industrie. Le must-have.
Notion 0 € (gratuit), 10 €/mois (Pro) SaaS Wiki projet, timeline Gantt, planning, tracking. Collab docs. Plus flexible que Jira (moins agile-strict).
Trello 0 € (gratuit), 80 €/an (Business) SaaS Kanban simple (todo / in-progress / done). Sympa pour petites équipes, moins puissant que Jira pour sprints.
Slack 0 € (gratuit), 7 €/pers/mois (Pro) SaaS Comms équipe, intégration Jira/Notion notifications, daily standup async. Essentiel pour remote/hybrid.
Figma 0 € (gratuit), 12 €/mois (Pro) SaaS Design system, wireframes, design handoff à dev. Gratuit pour 1 team ok, Pro pour collab.
GitHub / GitLab 0 € (gratuit/OSS), 21 €/pers/mois (GitHub Teams) SaaS Code hosting, CI/CD pipelines (Actions, Runners), PR review, deploy automation. Gratuit pour public repos.
Google Workspace 0 € (gratuit), 6-18 €/pers/mois SaaS Email, Docs (cahier charges, PVs), Sheets (budget tracking). Nice to have si pas Notion.
Monitoring (DataDog / New Relic) ~500-1500 €/mois SaaS Application performance monitoring (APM), logs, alerts prod. Essential après go-live.
TOTAL minimum annuel (équipe 8 pers) : ~3000-5000 €/an (Jira + Notion + Slack + Figma + monitoring) pour gestion projet + ops.
Budget projet 500k€ (8 sprints, équipe 8) : Jours/homme = ~480 jours (40 jours/sprint × 12 pers × utilization factor 90 %). Salaires : ~400-500k€. Outils ~4k€. Infrastructure/hosting ~10-20k€. Contingency 10 % = ~50k€. Total ~550k€ (5 % overage acceptable).
↑ Retour au sommaire

8 Outils et logiciels — Jira, Notion, Slack, Figma, GitHub, pricing 2026

Mode d'emploi : la boîte à outils opérationnelle du chef de projet. Chaque outil : qu'est-ce que c'est, pros/cons, coût, quand l'utiliser.

Jira Cloud — Gestion tickets et sprints agile

Qu'est-ce que c'est : plateforme Atlassian pour gérer backlog, sprints, tickets. Crée stories, estime points, track avancement, génère burndown chart automatique. Intégration GitHub/GitLab/Bitbucket (code reviews linkées tickets).

Pros : Interface puissante, standard industrie, burndown automatique, custom fields flexible, reporting (velocity chart, cycle time). Tout ce qu'il faut agile.

Cons : Courbe apprentissage (non-intuitive day 1), coût ~800 €/an équipe 10 pers, peut être lourd pour mini-projets.

Quand : Équipe 6+ personnes, projet 6+ mois. Si équipe 3 pers, 3 weeks ? Trello suffise.

Notion — Wiki, docs, tracking collaboratif

Qu'est-ce que c'est : plateforme all-in-one : wiki (docs projet), databases (timeline Gantt), docs (PVs, cahier charges). Notion remplacer : Confluence + Google Docs + Excel timelines.

Pros : Très flexible (tu crées ta structure), prix bas ~10 €/mois, sharable publiquement (clients peuvent follow planning), intégration pas mal (Slack notifications).

Cons : Pas natif agile (pas burndown auto), database queries peuvent être lentes gros volumes, pas code-first (plus « human friendly »). Meilleur pour docs/planning que sprint management.

Quand : Docs partagées, timeline client-facing, wiki interne projet. Complémente Jira (Jira = sprints, Notion = docs + planning visuel).

Slack — Communication équipe temps réel

Qu'est-ce que c'est : plateforme messaging par channels. Channels : #general, #dev, #design, #random. Threads, mentions, file sharing. Intégration Jira : notifs tickets auto → channel.

Pros : Équipe connect instantané, intégration écosystème (Jira, GitHub, Notion bots), history searchable, remplace 100 emails/jour.

Cons : Coût 7 €/pers/mois (équipe 8 = ~560 €/mois). Attention : 1000 messages par jour = hard to follow (discipline canaux nécessaire).

Quand : Équipe remote/hybrid, need async comms rapide. Ou dailies standup dans Slack (threaded, ≠ meeting).

Figma — Design system et wireframes

Qu'est-ce que c'est : outil design cloud. Crée wireframes, mockups, prototypes. Handoff dev : code specs auto-generated (spacing, colors, fonts). Real-time collab (plusieurs designers → same file).

Pros : Web-based (no install), collab real-time, dev integration (Figma → code plugin), prototype interactive.

Cons : Coût 12 €/mois/pers (equipe 2 designers = 288 €/an). Performance peut lag avec huge files.

Quand : Projet 3+ mois ou design system. Si « quick MVP », Wireframe.cc 0 € suffice.

GitHub / GitLab — Version control + CI/CD

Qu'est-ce que c'est : repo git + CI/CD pipelines. GitHub Actions automate : run tests on PR, deploy to staging on merge. GitLab similar mais plus robust self-hosted option.

Pros : Code history, PR review workflow (comments, approvals), CI auto-runs tests, deploy automation (no manual FTP). Standard industrie dev.

Cons : Courbe apprentissage Git (3-5 jours pour juniors). GitHub 21 €/pers/mois team plan. GitLab self-hosted free mais ops burden.

Quand : Obligatoire dès 2+ devs. Single dev ? Still use (backup, audit trail).

Google Workspace — Email, docs, sheets

Qu'est-ce que c'est : suite bureautique cloud. Gmail custom domain, Google Docs (cahier charges collab), Sheets (budget tracking).

Pros : Email pro, docs collab real-time (meilleur que Word), pricing 6-18 €/pers/mois.

Cons : Excel macros non-compat (Sheets < Excel power). Si tu veux SQL + pivot tables avancées, Excel meilleur.

Quand : Besoin domaine email propre + docs partagés. Nice-to-have, pas critical si Notion + Slack suffise.

Monitoring (DataDog / New Relic) — Alertes production

Qu'est-ce que c'est : platform surveiller app en prod. Logs, metrics (latency, error rate), traces transactions. Alerts : si error rate >1 %, email + Slack.

Pros : Détecte bugs prod ASAP, dashboards beautés (execs loves), data-driven debugging.

Cons : Coût ~500-1500 €/mois (cher). Setup complexe (need instrumentation code).

Quand : Obligatoire après go-live prod. Day 1 dev ? Peut attendre (CloudWatch AWS suffice pour MVP).

Workflow type chef de projet : Jira (sprint backlog) → Notion (docs + timeline client) → Slack (daily comms) → GitHub (code push triggers CI) → Figma (design handoff) → Monitoring (prod alerts). Tous linked, minimal context-switching. Budget tools = ~4k€/an (< 1 % budget projet 500k).
↑ Retour au sommaire