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

Avec un TJM élevé sur une mission d’IA, on n’achète pas du temps mais des décisions prises tôt, dont l’essentiel de la valeur tient dans ce qu’elles évitent : trimestres perdus, projets refaits, systèmes abandonnés. Le taux journalier moyen, ou TJM, est le prix facturé pour une journée d’intervention d’un consultant ou d’un indépendant.

« 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 de flatteur pour qui que ce soit. Un taux journalier ne s’achète pas au jour. Il s’achète au risque évité, aux trimestres non perdus et à ce qu’on n’a pas à refaire.

Le coût invisible d’un projet d’IA mal cadré est le temps qu’il consomme avant que quiconque accepte de dire qu’il ne passera pas en production, et surtout l’attention de direction qu’il immobilise pendant ce temps. L’arrêt tardif ajoute un coût d’opportunité.

Quand un projet s’enlise sans décision explicite, sa durée augmente sans garantie de résultat. Pendant ce temps, le projet 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 tôt un cas d’usage non viable évite de prolonger un investissement sans justification, et c’est la partie qui n’apparaît sur aucune facture.

La valeur d’une mission d’IA se vérifie dans les décisions documentées, le système effectivement exploité et la capacité de l’équipe interne à poursuivre sans dépendance permanente.

• Un avis tranché, y compris négatif. Si le cas d’usage ne tient pas, je le dis en cadrage, et je le documente.
• Un système en service, pas un prototype : branché aux données réelles, journalisé, mesuré.
• Une architecture réversible : le modèle peut être remplacé sans réécrire le système.
• La conformité intégrée plutôt que rapportée, ce qui évite un chantier de plusieurs semaines plus tard.
• Une équipe qui tient l’outil et le démontre avant mon départ. C’est ce qui supprime la mission suivante.

Écarter un cas d’usage au cadrage est la partie la plus rentable d’une mission d’IA parce qu’elle évite un projet entier en produisant une décision négative documentée. Un cas écarté tôt économise plusieurs mois d’une équipe.

Dans les portefeuilles que j’examine, seule une minorité des cas présentés mérite d’être poursuivie. Les autres échouent pour des raisons identifiables dès le cadrage : corpus indisponible, absence de propriétaire métier, résultat invérifiable.

La décision d’écarter ces cas est elle-même un livrable et évite des 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. Le critère du corpus, souvent décisif, est développé dans où part réellement un budget d’IA.

Pour calculer honnêtement ce qu’une mission d’IA rapporte, on part du temps humain que le système doit supprimer, on le valorise au coût chargé réel sur douze mois, puis on soustrait le coût complet d’exploitation. Je propose toujours cet exercice, et il n’est pas à mon avantage dans tous les cas.

1. Identifier la tâche supprimée ou réduite. Une tâche précise, décrite geste par geste, avec le temps qu’elle prend aujourd’hui.
2. Valoriser ce temps. Le multiplier par le coût horaire chargé réel des personnes concernées.
3. Projeter sur douze mois. En tenant compte d’une montée en charge progressive, pas d’un usage plein dès le premier jour.
4. Soustraire le coût complet d’exploitation. Inférence, relecture, évaluation, surveillance.
5. Comparer au coût de la mission. Ce qui reste est le gain annuel ; s’il 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 calcul est d’ailleurs le point de départ d’un audit IA.

Un diplôme, une ancienneté ou la maîtrise d’un outil ne suffisent pas à justifier un tarif élevé sans résultats vérifiables, responsabilités claires et transmission effective à l’équipe.

Le diplôme, l’ancienneté ou la maîtrise d’un outil ne démontrent pas le résultat attendu. Ce qui justifie un tarif, c’est la probabilité que le système existe encore et soit utilisé dix-huit mois plus tard, et cette probabilité se démontre par ce qui tourne, pas par un curriculum.

Comparer les seuls taux journaliers laisse de côté la durée, les reprises et l’exploitation, alors que le coût complet permet d’évaluer ce que l’organisation achète réellement. 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 porte donc sur le tarif, le périmètre et les preuves 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. Un incident mal géré après le départ du prestataire a, lui aussi, un coût qu’il faut compter, comme le montre ce que coûte un incident sur un système d’IA.

Une mission d’IA bien conduite doit laisser 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, et la fiche dans écrire la fiche d’un système d’IA.

La disponibilité du consultant compte lorsque la mission exige une présence suivie, des arbitrages rapides et une responsabilité d’exploitation, mais elle ne se déduit pas du seul tarif. La disponibilité fait partie de ce qui est acheté.

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. C’est le principe du métier décrit dans Forward Deployed Engineer : le métier, pas le titre, et présenté sur la page métiers.

Les erreurs fréquentes en choisissant un intervenant en IA sont de choisir au tarif, de juger sur le curriculum, d’acheter un prototype et de ne pas définir de critère de sortie. Elles déplacent toutes le coût vers la suite du projet.

• Choisir le tarif le plus bas. Le coût se reporte sur la durée du projet et sur sa probabilité d’aboutir.
• Juger sur le titre. Le diplôme est une condition d’entrée ; il ne dit rien de ce qui tournera dans dix-huit mois.
• Acheter une démonstration. Un prototype qui n’est pas branché aux données réelles ne prouve presque rien.
• Oublier le critère de sortie. Sans équipe capable de traiter seule un incident, la mission suivante est déjà programmée.
• Ne pas demander d’avis négatif. Un intervenant qui ne refuse jamais un cas d’usage ne protège pas le budget.