Le jour-homme dans un chiffrage de développement

Un jour-homme, souvent noté « j/h » ou « JH », est une journée de travail d'une personne. Chiffrer un développement en jours-hommes consiste à estimer combien de journées de travail chaque tâche demande, puis à multiplier le total par un taux journalier, le TJM (tarif journalier moyen). Un projet chiffré à 30 jours-hommes représente 30 journées de travail, qu'elles soient faites par une personne pendant six semaines ou par deux personnes pendant trois semaines environ. Le prix reste en principe le même, le délai change.

Presque tous les devis de développement sont construits ainsi, même ceux qui affichent un prix global au forfait. Savoir lire cette unité permet de vérifier un chiffrage, de le comparer à un autre et de poser des questions précises au prestataire.

Le vocabulaire d'un chiffrage

• Jour-homme (j/h). Une journée de travail d'une personne. On rencontre aussi « jour-personne ». Le mois-homme sert au même usage pour les gros projets.
• Charge. Le nombre total de jours-hommes, c'est-à-dire la quantité de travail à fournir.
• Délai. Le temps calendaire entre le lancement et la livraison. Il dépend de la charge, du nombre de personnes affectées et des temps d'attente, dont vos propres validations.
• TJM. Le prix d'une journée de travail facturée, en général hors taxes. Il peut varier selon le profil : chef de projet, développeur, designer.
• Provision pour risques. Des jours ajoutés pour couvrir les imprévus. Elle figure parfois sur une ligne à part, parfois elle est répartie dans toutes les tâches.

Des jours au prix

Le calcul de base tient en une ligne : prix = nombre de jours-hommes × TJM. Prenons un outil de suivi des commandes estimé à 40 jours-hommes, exemple inventé pour l'illustration. Au tarif journalier moyen affiché par les développeurs indépendants confirmés sur Malt, 576 €, le développement représente 40 × 576 = 23 040 € hors taxes.

Source du taux : Malt, baromètre des tarifs tech, relevé le 14 septembre 2026. Le nombre de jours est inventé pour l'exemple.

Le même nombre de jours à un autre taux donne un autre total. C'est pourquoi deux devis aux charges proches peuvent afficher des prix éloignés, et pourquoi deux devis au même prix peuvent cacher des charges très différentes : un prestataire cher qui a prévu peu de jours, un autre moins cher qui en a prévu beaucoup.

Les plateformes de freelances affichent souvent des taux horaires. Sur Codeur.com, la moyenne des tarifs horaires proposés par les développeurs logiciel était de 37 €. Un taux horaire et un taux journalier ne se comparent qu'en sachant combien d'heures compte la journée facturée : posez la question au prestataire avant de comparer.

Source : Codeur.com, combien coûte un développement logiciel, consulté le 22 octobre 2026.

Charge et délai, deux choses différentes

Doubler le nombre de personnes ne divise pas le délai par deux. Frederick Brooks l'a décrit dans Le Mythe du mois-homme, publié en 1975 : le mois-homme laisse croire que personnes et mois s'échangent, alors que chaque nouvel arrivant doit être formé par ceux qui sont déjà là et multiplie les échanges entre développeurs. On en a tiré la loi de Brooks, selon laquelle ajouter des personnes à un projet déjà en retard accentue ce retard.

Source : Wikipédia, Le Mythe du mois-homme, consulté le 22 octobre 2026.

Pour vous, deux conséquences. Un prestataire qui promet un délai très court en mettant beaucoup de monde sur un petit projet ne gagnera pas autant de temps qu'il l'annonce, et la coordination entre ces personnes se retrouvera dans la facture. À l'inverse, un délai long n'indique pas forcément une charge élevée : il peut refléter le temps de vos validations ou une seule personne affectée au projet. Le guide sur les délais de développement d'une application détaille ce qui fait varier le calendrier.

Comment un prestataire estime les jours

Une estimation sérieuse part d'une description du besoin découpée en tâches assez petites pour être estimées une à une : un écran, une règle de calcul, un export, un échange avec un autre logiciel. Chaque tâche reçoit un nombre de jours, souvent sous forme de fourchette. S'ajoutent ensuite les postes transverses, qui ne correspondent à aucune fonction précise mais prennent du temps : gestion de projet, tests, mise en production, documentation.

La qualité de l'estimation dépend surtout de la qualité de la description. Plus votre besoin est précis (écrans, règles de gestion, exemples de documents, volumes de données), moins le prestataire a besoin d'ajouter de jours pour se couvrir. Le guide sur l'expression des besoins aide à préparer cette description, même sans connaissances techniques.

L'IA change une partie du calcul. Elle accélère l'écriture de certaines parties du code, et un prestataire qui l'utilise peut annoncer moins de jours pour le même résultat. C'est ainsi que je travaille, avec un réseau de développeurs freelances roumains quand un projet demande plus de bras. Le temps de compréhension du besoin, de relecture et de tests, lui, ne disparaît pas : un chiffrage qui le réduit à rien doit vous alerter.

Un exemple de chiffrage détaillé

Voici à quoi peut ressembler le détail des 40 jours-hommes de l'outil de suivi des commandes évoqué plus haut. Le découpage et les nombres sont inventés pour l'illustration ; ils montrent la forme qu'un chiffrage lisible doit avoir.

Avec un tableau de ce type, la discussion devient concrète. Vous pouvez demander pourquoi l'export comptable compte quatre jours (le format de votre logiciel comptable est-il connu ?), si le tableau de bord peut attendre une deuxième étape, ou si l'import suppose un fichier déjà propre. Chaque réponse peut retirer ou ajouter des jours, et vous savez exactement lesquels.

Vérifier un chiffrage en jours-hommes

Devant un devis détaillé en jours, voici les points à contrôler :

• Les jours sont-ils donnés tâche par tâche, ou en un seul bloc ? Un bloc ne se vérifie pas.
• Les grosses tâches sont-elles découpées ? Une ligne « développement du back-office : 25 jours » cache tout ce qui compte.
• Les postes transverses (gestion de projet, tests, mise en production) sont-ils comptés à part, et combien de jours représentent-ils ?
• Une provision pour risques existe-t-elle, et sur quelles hypothèses repose-t-elle ?
• Le TJM est-il le même pour tous les profils, ou différent selon qu'il s'agit d'un chef de projet, d'un développeur ou d'un designer ?
• Les jours de vos propres collaborateurs (ateliers, tests, validations) sont-ils estimés ? Ils ne figurent pas sur la facture, mais ils coûtent à votre entreprise.
• Les fourchettes sont-elles larges ? Un écart important entre le bas et le haut d'une fourchette signale une zone mal comprise, à éclaircir avant de signer.

Le guide pour lire un devis de développement reprend ces points dans l'ordre du document, avec les autres postes à vérifier.

Jours-hommes au forfait ou en régie

Le chiffrage en jours sert dans les deux grands modes de prix, mais il n'engage pas de la même façon. Au forfait, les jours servent à calculer un prix fixe : si le prestataire s'est trompé dans son estimation, le dépassement est en principe pour lui, tant que le périmètre ne change pas. En régie, les jours sont une estimation : vous payez le temps réellement passé, dépassement compris. Le guide forfait ou régie compare les deux et dit quand choisir l'un ou l'autre.

Ma façon de chiffrer suit la première logique : un prix fixe, découpé en étapes, chaque étape réglée une fois livrée et validée. Quand vous m'envoyez un devis d'agence, je compare ses jours poste par poste avec mon propre chiffrage et je réponds sous 48 heures ouvrées. Les repères de prix du marché sont sur la page prix d'un logiciel métier sur mesure.