Calculez le nombre de jours restants pour terminer un projet à partir des heures restantes, des heures par jour et de la taille de l'équipe.
Calculer les jours restants d'un projet à partir des heures restantes et de la capacité quotidienne réelle est l'outil de pilotage le plus simple et le plus puissant. La clé : utiliser des heures PRODUCTIVES (typiquement 5-6 h sur 8 h contractuelles selon les études Calendar.com, Microsoft Work Trend Index 2024) et non les heures théoriques. Cette approche évite la sur-promesse classique « il reste 200 h, on est 4, donc 200 / (8 × 4) = 6,25 jours » qui ignore que personne ne produit 8 h pleines par jour.
Jours restants = heures restantes / (heures par jour × taille équipe)
Somme des heures de travail restantes pour finir le projet ou le sprint. Lisible sur le burn-down chart ou estimé par re-évaluation des tâches non commencées. Unité attendue : h. Valeur généralement attendue entre 0 et 1000000. Le pas de saisie conseillé est 0.5.
Heures réellement consacrées au projet par personne et par jour. Hors réunions, support et travail invisible : typiquement 5-6 h sur une journée contractuelle de 8 h selon les études sur la concentration (DeepWork, AnandRiess). Unité attendue : h. Valeur généralement attendue entre 0.5 et 24. Le pas de saisie conseillé est 0.5.
Nombre de personnes affectées effectivement au projet. Ne compte pas les contributeurs occasionnels (revues ponctuelles, expertise transverse). Unité attendue : pers. Valeur généralement attendue entre 1 et 1000. Le pas de saisie conseillé est 1.
Capacité quotidienne effective de l'équipe = heures productives par personne × taille équipe. Le moteur l'utilise directement comme dénominateur. Unité attendue : h. Valeur généralement attendue entre 0.5 et 100000. Le pas de saisie conseillé est 0.5.
Comparez le résultat aux jours calendaires restants jusqu'à la deadline. Marge >30 % : projet en avance, opportunité de pousser le scope ou d'absorber des imprévus. 0-30 % : zone confortable. 0 à -10 % : tension, mobiliser ou réduire le scope. <-10 % : retard structurel, négocier explicitement avec le sponsor (nouveau délai, scope réduit, renfort) plutôt que d'espérer rattraper. La transparence en amont est toujours moins coûteuse qu'une annonce tardive.
Projet site e-commerce : 240 h restantes en pré-prod. Équipe de 3 développeurs à 6 h productives/jour = 18 h/jour de capacité. Jours restants = 240 / 18 = 13,3 jours ouvrés. À 5 jours ouvrés par semaine, cela représente 2,7 semaines. Si la deadline est dans 4 semaines (20 jours ouvrés), marge = (20 - 13,3) / 13,3 × 100 = 50 % de buffer — confortable, scope ajustable à la hausse possible. Si la deadline est dans 2 semaines (10 jours ouvrés), il manque 3,3 jours soit 60 h — il faut soit ajouter une 4e personne (60 / 6 = 10 jours pour rattraper) soit réduire le scope de 60 h.
Trois ajustements pour fiabiliser l'estimation. (1) Utiliser un coefficient de focus réaliste : la moyenne en équipe produit est 5-6 h productives sur 8 h contractuelles (Microsoft Work Trend Index 2024). Plus optimiste = sur-promesse. (2) Réviser l'estimation à mi-parcours : les heures restantes en début de projet sont quasiment toujours sous-estimées de 20-40 % (loi de Hofstadter). Ajouter un buffer dès le début. (3) Distinguer heures équipe et heures d'une personne : si une tâche ne peut être parallélisée (un seul dev backend), inutile de multiplier par la taille équipe — utiliser la capacité de la personne sur la voie critique.
Les études récentes (Microsoft Work Trend Index 2024, Calendar.com, étude DeepWork de Cal Newport) montrent que la productivité réelle plafonne à 5-6 h par jour sur des tâches cognitives. Les 2-3 h restantes sont consommées par les réunions, le contexte switching, les échanges, le support et la fatigue. Compter 8 h productives mène systématiquement à des promesses non tenues.
Sur la voie critique (chemin de tâches dépendantes), ajouter des personnes n'accélère pas le projet et peut même le ralentir (« mythical man-month » de Fred Brooks). Si un module backend bloque tout le reste, utilisez la capacité d'une seule personne dans le calcul, indépendamment de la taille équipe. Pour les phases parallélisables (UI, tests, contenu), utilisez la capacité totale.
Deux méthodes. (1) Ajouter une marge fixe : 15-25 % de buffer sur le total estimé pour absorber les inconnus connus (bugs, ajustements, dépendances). (2) Méthode du « plus probable » : estimer optimiste + 4× plus probable + pessimiste, diviser par 6 (formule PERT). Cette pondération évite à la fois la sur-promesse et la sur-protection.
