Charge de travail et délai de livraison : pourquoi 40 jours-homme ne font pas 8 semaines ?

Quelle est la différence entre la charge et le délai d'un projet ?

La charge de travail est la quantité d'effort nécessaire pour réaliser un périmètre donné. Elle s'exprime en jours-homme : « ce lot représente 40 jours-homme » signifie qu'un développeur travaillant seul, à temps plein et sans interruption, aurait besoin de 40 journées de travail effectif pour le réaliser.

Le délai de livraison est la durée calendaire entre le démarrage et la mise à disposition : « livré dans 10 semaines ». Il intègre tout ce que la charge ignore : week-ends, congés, réunions, temps d'attente, dépendances techniques, revues de code et allers-retours de validation.

La charge est une mesure d'effort, le délai une mesure de temps qui passe. Les deux sont liés, mais par une conversion — jamais par une égalité. Un devis sérieux affiche toujours les deux chiffres séparément.

L'analogie la plus parlante : la charge, c'est le nombre de litres d'essence nécessaires pour le trajet ; le délai, c'est l'heure d'arrivée. Personne ne confond les deux en voiture — en développement logiciel, c'est pourtant l'erreur la plus fréquente dans les comités de pilotage.

Comment convertit-on une charge en délai réaliste ?

La formule de base est simple, ce sont ses paramètres qui sont systématiquement sous-estimés : Délai ≈ Charge ÷ (effectif × taux de focus × taux de parallélisation) + temps incompressibles.

Voici l'impact de chaque paramètre sur un exemple concret de 40 jours-homme :

Résultat : 40 jours-homme = environ 10 à 12 semaines pour un développeur seul, 7 à 9 semaines pour un binôme. Jamais « 8 semaines à deux » comme le calcul naïf le laisse croire, et encore moins « 2 semaines à quatre ».

Le taux de focus de 70-80 % n'est pas un aveu d'inefficacité : c'est la réalité de tout travail intellectuel en équipe — cérémonies agiles, revues de code, clarifications fonctionnelles, incidents de production. Un planning qui suppose 100 % de focus est un planning déjà en retard le jour de sa signature.

Pourquoi ajouter des développeurs ne divise pas le délai ?

C'est la loi de Brooks, formulée dès 1975 dans The Mythical Man-Month : « ajouter des personnes à un projet logiciel en retard le retarde davantage ». Trois mécanismes l'expliquent :

• Le coût de coordination croît de façon quadratique. À 2 personnes, 1 canal de communication ; à 5 personnes, 10 canaux ; à 10 personnes, 45. Chaque canal consomme du temps de synchronisation qui ne produit aucune ligne de code.
• Les tâches ont des dépendances. L'API doit exister avant que le front la consomme, le modèle de données avant l'API. Une partie du chemin est séquentielle par nature — c'est le « chemin critique », et aucun renfort ne le raccourcit.
• L'onboarding a un coût négatif à court terme. Chez Athenix, un développeur qui rejoint un projet en cours consomme le temps des développeurs en place pendant en moyenne 2 semaines avant de devenir un contributeur net.

L'image classique de Brooks résume tout : neuf femmes ne font pas un bébé en un mois. Certaines charges sont parallélisables, d'autres non — et une estimation sérieuse distingue les deux dès le chiffrage. C'est aussi pourquoi une équipe dédiée stable livre plus vite qu'une équipe redimensionnée en cours de route : le coût de coordination est amorti et le taux de focus est connu.

Quelles sont les erreurs les plus fréquentes côté client ?

• Diviser la charge par l'effectif pour obtenir le délai. « 60 jours-homme, vous êtes 3, donc 20 jours ouvrés, donc 4 semaines. » C'est le calcul qui produit les plannings intenables — et les conflits en fin de projet.
• Confondre estimation et engagement. Une estimation de charge est une prévision avec une incertitude (typiquement ±20-30 % en début de projet) ; un délai contractuel est un engagement. Le modèle contractuel joue ici un rôle central — voir notre comparatif régie ou forfait : quel modèle d'engagement choisir.
• Négocier la charge pour comprimer le délai. Marchander « 35 jours-homme au lieu de 40 » ne raccourcit pas le calendrier : la charge est une propriété du périmètre, pas une variable commerciale. Pour réduire le délai, on réduit le périmètre ou on parallélise raisonnablement.
• Ignorer son propre temps de réponse. Validations, fourniture des contenus et des accès font partie du délai. Chez Athenix, nous intégrons systématiquement une marge de 2 semaines dédiée aux temps d'attente et de validation côté client dans nos plannings.
• Comparer des devis sur la seule charge affichée. Un prestataire qui annonce 30 jours-homme là où les autres en annoncent 45 n'est pas plus rapide : il a soit exclu des activités du périmètre, soit sous-estimé — dans les deux cas, c'est le client qui paie l'écart.

Comment cadrer un projet avec ces deux notions ?

La bonne pratique consiste à exiger les deux chiffres, séparément, dès le devis :

1. La charge par lot, avec son niveau d'incertitude — une fourchette, jamais une valeur unique.
2. Le délai calendaire, avec ses hypothèses explicites : effectif, taux de focus, dépendances client, jalons de validation.
3. La règle de conversion utilisée : un prestataire sérieux sait expliquer pourquoi 40 jours-homme deviennent 10 semaines. S'il ne peut pas, méfiance.
4. Le chemin critique : quelles tâches sont séquentielles, lesquelles sont parallélisables — c'est lui qui borne le délai minimum, quel que soit le budget.
5. Les responsabilités client planifiées : validations, contenus, accès, avec des dates précises.

En pilotage, suivez ensuite les deux courbes distinctement : le reste à faire (charge) et la date de fin projetée (délai). Un projet peut consommer sa charge conformément au plan et déraper en délai — ou l'inverse. Ne suivre qu'un seul indicateur, c'est piloter avec un œil fermé.