Ce qu'un taux journalier élevé achète réellement

« Pourquoi ce taux plutôt qu'un autre » est une question sur le prix d'une journée. Elle suppose que l'on achète du temps, et que deux journées de deux personnes différentes sont des biens comparables.

Sur ce type de mission, ce n'est pas le cas, et la raison n'a rien d'flatteur pour qui que ce soit. Ce qu'on achète, ce sont des décisions prises tôt, et l'essentiel de leur valeur tient dans ce qu'elles évitent.

Un projet d'IA mal cadré ne s'arrête pas au bout de trois semaines. Il consomme deux à trois trimestres avant que quiconque accepte de dire qu'il ne passera pas en production.

Pendant ce temps, il mobilise des équipes internes, il occupe un budget, et surtout il occupe la fenêtre d'attention de la direction, qui est la ressource vraiment rare. Le coût réel n'est pas le montant dépensé, c'est ce qui n'a pas été fait à la place.

Écarter un cas d'usage non viable en deuxième semaine plutôt qu'en huitième mois représente donc l'essentiel de la valeur apportée, et c'est la partie qui n'apparaît sur aucune facture.

Je propose toujours le même exercice, et il n'est pas à mon avantage dans tous les cas.

On prend le temps humain que le système doit supprimer, on le multiplie par le coût horaire chargé réel, on le projette sur douze mois. On soustrait le coût complet d'exploitation, inférence, relecture, évaluation, surveillance. Ce qui reste est le gain annuel.

Si ce gain ne couvre pas plusieurs fois le coût de la mission, il ne faut pas la faire. Je préfère le dire au cadrage : une mission qui ne se rentabilise pas produit un client mécontent et une référence que je ne pourrai pas citer.

Ce mode de travail suppose une présence longue et une responsabilité qui va jusqu'à l'exploitation. Il n'est pas compatible avec un carnet rempli.

Je prends donc peu de missions en parallèle, et cela fait partie de ce qui est acheté : la disponibilité pour aller au bout d'une seule chose, plutôt que l'avancement simultané de plusieurs.

Un cas d'usage écarté au cadrage économise plusieurs mois d'une équipe, et c'est la part du travail qui ne se voit sur aucun livrable. Elle est pourtant la plus rentable.

Sur cinq cas présentés, deux au plus méritent d'être poursuivis. Les trois autres échouent pour des raisons identifiables au cadrage : corpus indisponible, absence de propriétaire métier, résultat invérifiable.

Écarter ces trois cas ne produit aucun livrable et évite trois projets qui auraient consommé leur budget avant de s'arrêter. La méthode d'écartement figure dans combien de cas d'usage faut-il abandonner.

Un système qui tourne, un jeu de tests, une fiche d'une page, et une équipe qui a traité seule un incident réel. Ces quatre éléments constituent la sortie, et le dernier est le plus exigeant.

Le critère de sortie n'est pas « le système fonctionne » mais « l'équipe a traité seule le premier incident survenu après la transmission ». Si elle rappelle, la transmission n'a pas eu lieu.

Ce critère est vérifiable et il change la nature de la mission : il oblige à transmettre pendant, pas à la fin. Les gestes concernés sont décrits dans les trois gestes qui font tenir un système.

Comparer un taux journalier à un autre n'a aucun sens ; comparer le coût total d'un système qui aboutit à celui d'un système qui s'arrête au douzième mois en a un. C'est le seul calcul utile.

Un projet qui s'arrête après avoir consommé son budget coûte l'intégralité de ce budget, plus le temps des équipes mobilisées, plus le coût d'opportunité du cas d'usage non traité.

La question à poser n'est donc pas le tarif mais le taux d'aboutissement, et ce qui reste quand la mission s'arrête. Les traits communs aux systèmes qui aboutissent sont détaillés dans agents en entreprise : où s'arrêtent les projets.