Les jours-homme, c’est (enfin) terminé ?

Vous avez déjà vu passer ces mots : TJM, coûts de journée, et le fameux « jour-homme » sorti d'un autre temps (où une femme était un homme comme un autre, au cas où il y en avait une dans l'équipe). Peut-on enfin remiser cette notion au placard grâce à l'IA ?

Et pour vous, qui achetez notre travail, qu'est-ce que ça veut dire ?

Imaginez : votre direction ou votre CA a voté une ligne budgétaire. 45 000 € pour refondre l'espace adhérent. En février, votre prestataire favori vous fait proposition qui annonce 60 « jour-homme ». Vous ne savez pas exactement ce que ça recouvre, mais ça tient dans l'enveloppe, et l'enveloppe est ce qui vous préoccupe. Vous signez.

Trois semaines plus tard, en point d'étape, le développeur vous annonce, plutôt content de lui, que la moitié du périmètre est déjà en ligne. Vous êtes ravie. Puis une question très simple vous traverse l'esprit, et vous n'osez pas tout à fait la poser à voix haute : je paie quoi, au fond ?

Posez-la. C'est la bonne question, et elle est beaucoup plus vieille que l'IA.

L'ouvrée, ou la journée devenue surface

Pour comprendre d'où viennent les mesures comme le jour-homme, sortons la tête du clavier et faisons un détour par la campagne. En Bourgogne par exemple, on mesure encore la vigne en ouvrées. Une ouvrée, c'est la surface qu'un homme travaille en une journée : un vingt-quatrième d'hectare, environ quatre ares. Ailleurs on comptait en journaux, ce qu'un laboureur retourne en un jour avec sa bête, et pour ne rien arranger un journal ne valait pas la même surface d'une région à l'autre, parce qu'on ne laboure pas une terre légère comme on attaque une argile lourde. L'unité n'était pas universelle : elle intégrait la difficulté du terrain.

Puis le tracteur est arrivé.

Soyons clairs : plus personne ne laboure une ouvrée en une journée. Le tracteur a démultiplié la productivité, mais l'ouvrée, elle, est restée. Elle a simplement cessé de parler de travail humain pour devenir ce qu'elle est aujourd'hui : une surface, fixe, cadastrale, dont le nom mentionne une journée d'homme par pure politesse historique.

Le jour-homme informatique descend de la même famille, avec un détour par l'industrie et l'organisation scientifique du travail. Taylor (oui, le papa du Taylorisme), chronomètre en main, décomposait le geste, le mesurait et l'additionnait. Il invente l'homme-heure. Un outillage bien adapté pour des tâches divisibles et reproductibles. Et une mesure adoptée dans des univers divers, comme l'informatique. Mais transposée au logiciel, cette mesure montre ses limites déjà bien avant l'IA : ajouter des développeurs à un projet en retard le retarde davantage, parce que le travail intellectuel ne se découpe pas comme une parcelle. Cinquante ans après cette critique formulée par Brooks, nous facturons toujours en jours-hommes.

Le jour-homme n'a jamais mesuré du travail accompli. Il a mesuré de la présence, et nous avons collectivement décidé que c'était une approximation acceptable.

Le pacte du TJM

Regardez une grille de TJM, le taux journalier moyen, le prix d'une journée de prestation. Un développeur junior à un certain tarif, un senior au double, un architecte au-dessus. Sur le papier, cela dessine une échelle de compétence bien précise. Dans la pratique, c'est une convention bien commode.

Le jour-homme impose un mode de calcul devenu universel : on multiplie le temps par le coût du professionnel, et on aura une quantité de travail attendue. Chacun projette sa vision du niveau de compétence et fait un calcul mental rapide : le senior coûte deux fois plus cher, mais il va deux fois plus vite, il se trompe moins, et il ne vous facturera pas dans six mois la reprise de ses propres approximations. Le surcoût journalier s'annule dans le total. Personne ne le vérifie vraiment, c'est une convention tacite, pas un théorème. Il est parfois trompeur (certains juniors sont des champions de vitesse, certains seniors font encore des erreurs de conception), demande parfois des bricolages, mais il a une vertu rare : il est comparable. Deux prestataires sur le même périmètre peuvent être mis côte à côte, ligne à ligne, par un acheteur qui ne connaît rien au code. Le jour-homme donne une mesure que tout le monde comprend.

L'IA n'a pas cassé ce pacte en accélérant les développeurs. Elle l'a cassé en rendant le travail illisible.

Car ce qui trahissait le junior, hier, c'était la forme : un nommage approximatif, des fonctions à rallonge, l'absence de tests, ce code smell (« code odorant ») qui prévient qu'une putréfaction est en cours. Aujourd'hui, un junior outillé produit du code propre, commenté, structuré, plausible. À la relecture, il ressemble à du code de senior. Ce qui manque ne se voit pas dans le fichier : c'est le jugement sur ce qu'il ne fallait pas écrire, et la connaissance des endroits où l'existant va se venger.

Ça ne se voit pas à la relecture. Ça se voit en production, quand le serveur tombe en panne 6 mois plus tard et qu'il faut faire de l'archéologie pour comprendre ce qui a causé l'incident.

La grille continue donc de tourner, mais elle a perdu son ancrage. Le jour d'un senior et le jour d'un junior ne produisent plus des livrables visiblement différents : ils produisent des risques différents. Et le risque ne se facture pas à la journée.

Le token, cette bête qui ne se laisse pas budgéter

Et voici l'IA, qui vient semer le trouble dans cette idylle entre le client et son prestataire. Car voici le token (jeton), l'unité de découpage du texte que les modèles facturent à l'entrée et à la sortie. C'est une dépense réelle, et elle a la particularité d'échapper à toute prévision. Trois mouvements se cumulent, et ils ne vont pas dans le même sens : le prix par token baisse, régulièrement, certes ; mais au même moment la consommation par tâche explose, parce que les agents ne répondent plus une fois mais explorent, se relisent, relancent les tests, recommencent ; et pour couronner le tout, le marché se renouvelle tous les trimestres, avec de nouveaux modèles et des modes de facturation imprévisibles.

Résultat : deux tickets d'apparence identique peuvent coûter 0,20 €, ou 30 €.

Ce n'est pas dramatique en soi, à petite échelle. Mais ces variations de coûts doivent être supervisées au quotidien par l'équipe de développement, car sans surveillance la facture peut exploser. C'est donc un coût variable, imprévisible, et non pilotable par le client, au moment précis où le client, lui, a besoin de l'inverse : un budget fixe et prévisible.

Ce que vous achetez vraiment : un montant qui ne bouge pas

Revenons à votre conseil d'administration.

Une association, un GIP, une collectivité ne cherchent pas le prix le plus bas. Ils cherchent un montant qui ne bouge pas. La ligne est votée en novembre pour l'année suivante, elle est fléchée par un financeur, elle sera justifiée dans un rapport. Un dépassement de 15 % n'est pas un inconvénient comptable : c'est un arbitrage à refaire, parfois un projet qui s'arrête. Nous le voyons souvent du côté associatif, où la complexité technique n'empêche pas l'enveloppe d'être fermée.

C'est là qu'on comprend à quoi sert vraiment le jour-homme. Ce n'est pas un instrument de mesure, c'est un instrument de partage du risque. En régie, je vous facture les jours passés : le risque de dérapage est chez vous. Au forfait, je m'engage sur un périmètre et un prix : il est chez moi, et je le provisionne. Entre les deux, tout est négociable, et tout le monde le sait.

D'où un paradoxe qu'il faut regarder en face. L'IA fait baisser le coût moyen de production du logiciel, et augmente sa variance. Certaines tâches sont dix fois plus rapides ; d'autres, le jugement, l'immersion dans du code hérité, la conduite du changement, n'ont pas bougé d'un pouce, voire même augmenté. Or c'est cette variabilité, pas la moyenne, qui détermine une prime d'assurance. À court terme, l'IA rend donc l'engagement au forfait plus difficile à tenir, au moment même où tout le monde attend qu'elle fasse tomber les prix.

Quelqu'un doit absorber cet écart. Et ce n'est pas le client.

Alors, quelle unité ?

Dans un monde idéal, il faudrait facturer le travail accompli. La difficulté est entière : le mesurer. Mais quelle unité choisir :

Les lignes de code ? Surtout pas ! On sait depuis cinquante ans que c'est l'unité la plus toxique qui soit : elle récompense le verbiage et pénalise l'élégance. Et l'IA, justement, produit des torrents de lignes. On ne va pas facturer à la frappe.

La fonctionnalité livrée ? Séduisante, mais une fonctionnalité n'en vaut pas une autre. Un écran de login et un moteur de scoring ne sont pas comparables. Et qui valide « livré » — le client, le dev, le PO ?

L'indicateur métier ? Minutes économisées par utilisateur, dossiers instruits sans intervention humaine, coût de traitement d'une notification. C'est le plus juste, et c'est ce que le client voulait acheter depuis le début. Mais l'attribution est un nid de guêpes, le chiffre a bougé, était-ce la fonctionnalité, la communication, ou la saison ? Et cela suppose un client qui mesure et maîtrise déjà finement ses indicateurs en amont, ce qui est rarement le cas.

Le vrai critère est ailleurs, et il explique la longévité du jour-homme. Une bonne unité de facturation n'est pas la plus juste, c'est la moins chère à vérifier ensemble. Le jour-homme est faux, tout le monde le sait, mais il se compte sur un calendrier, sans expert et sans dispute. Toute unité candidate se heurtera à ce mur.

Ce qu'on fait

Depuis des années que nous faisons ce métier, nous n'avons pas trouvé l'unité idéale. Nous avons arrêté de la chercher, et nous construisons nos engagements sur trois étages.

Un socle d'abonnement (TMA) pour ce qui doit tourner en continu : disponibilité, sécurité, mises à jour, incidents, veille sur les dépendances. Fixe, mensuel, ennuyeux, prévisible. Ce n'est pas aussi glamour que la production de fonctionnalités, mais c'est vital.

Les sprints agiles à périmètre macro et prix fixés. Ici le jour-homme reste l'unité, parce qu'il faut une monnaie de compte et que nos clients savent la lire. Mais il sert à dimensionner un engagement, pas à pointer des présences. Nous nous engageons sur ce qui sera en ligne, et sur le prix. Ce que ça nous a coûté à l'intérieur du jalon ne regarde que nous.

Une part variable, adossée à un indicateur métier, et plafonnée, quand le client accepte de mesurer avec nous, et seulement dans ce cas.

Et pour les tokens, jusqu'ici c'est resté notre problème. Nous choisissons les modèles, nous provisionnons, nous absorbons les variations, exactement comme pour les licences et les serveurs. Un client ne peut pas piloter une dépense dont il ne choisit ni le fournisseur, ni le modèle, ni le nombre de boucles.

La contrepartie est évidente, et c'est là que le forfait devient dangereux : payé à la livraison plutôt qu'au temps, on est tenté d'aller vite et de laisser la dette derrière soi. Notre garde-fou n'est pas la bonne volonté, c'est l'outillage, des tests automatiques qui contrôlent ce que l'IA produit, plutôt qu'une relecture ligne à ligne qui ne tient pas à l'échelle.

On tâtonne encore sur la mesure de la consommation d'IA. On a régulièrement sous-estimé un coût de tokens sur un projet long, parce qu'on n'avait pas anticipé la croissance du contexte et la gourmandise de certains modèles (Claude Opus, c'est de toi qu'on parle). La facture interne a mangé la marge. C'est à ce moment qu'on a commencé à mesurer sérieusement notre consommation d'IA.

On le garde, même s'il ne compte plus la même chose

Alors, la fin des jours-hommes ? Non. Mais la fin du jour-homme comme mesure du travail, oui. Il va devenir ce que l'ouvrée est devenue : une unité de compte commode, dont le nom parle d'une journée d'homme sans plus rien décrire ni de la journée, ni de l'homme. Ce n'est pas un scandale. C'est le sort de toute unité qui survit à la technique qui l'a fait naître.

Ce qui change vraiment, c'est l'endroit où se situe l'engagement. Facturer du temps, c'était vendre une présence et laisser le risque au client. Ce que nos clients demandent, et ce que l'IA rend enfin tenable, c'est l'inverse : un périmètre, une date, un montant qui ne bouge pas, et quelqu'un qui porte l'écart.

Enfin, sauf qu'on évitera le terme « jour-homme » pour lui préférer « jours de prestation ».

Si vous devez présenter à un conseil d'administration, en novembre, un budget qui ne bougera pas, parlons-en maintenant. Pas en février.