Une réponse produite n’est pas nécessairement un travail terminé

Comparer deux modèles au prix du million de jetons renseigne sur une partie du coût technique. Pour décider d’un investissement, il faut encore savoir ce que ces jetons ont permis d’accomplir.

Une réponse de support acceptée, un document classé correctement, un dossier préparé puis validé : chaque usage a son résultat utile. Le compter oblige à définir ce que signifie « terminé ». Si une réponse doit être réécrite, si un document est mal orienté ou si le contrôle prend autant de temps que le travail initial, la production brute du modèle donne une image trompeuse de la performance.

La FinOps Foundation distingue précisément les métriques d’efficacité des ressources — coût par jeton, par capacité de calcul — des unités métier, comme le coût par transaction ou par dossier résolu. Les deux sont utiles, mais elles ne répondent pas à la même question.

Un premier arbitrage peut partir du coût complet par résultat accepté, sur une période définie. Il faut y faire entrer les tentatives infructueuses et les reprises humaines, pas seulement les cas que la démonstration réussit. Un faible coût moyen ne dispense pas non plus d’examiner les erreurs rares dont les conséquences seraient importantes.

Ce que le devis laisse à la charge de l’entreprise

Un fournisseur peut parfaitement chiffrer sa prestation sans chiffrer tout votre projet. La mobilisation d’un responsable métier, la reprise d’une documentation obsolète ou l’organisation du support interne ne figurent pas nécessairement dans son périmètre.

  • Préparation et intégration : qui remet les données en état, raccorde les outils et vérifie les droits d’accès ?
  • Fonctionnement : que coûtent les usages réels, les reprises, le stockage et les pointes de charge ?
  • Contrôle : qui vérifie les résultats, avec quelle compétence et pendant combien de temps ?
  • Adoption : quel temps faut-il pour former les utilisateurs et adapter leur manière de travailler ?
  • Maintenance et sortie : qui suit les changements, traite les incidents et reprend le service si la solution doit être remplacée ?

Cette liste doit devenir un budget, avec un responsable pour chaque hypothèse. Un temps interne n’est pas gratuit parce qu’il ne déclenche pas une facture supplémentaire : il mobilise une capacité qui ne sera pas disponible ailleurs. À l’inverse, cette mobilisation ne constitue pas toujours une dépense de trésorerie nouvelle. Mélanger les deux empêche de comprendre ce que l’entreprise finance réellement.

Il faut aussi éviter de compter deux fois la même charge, par exemple des heures internes déjà incluses dans un forfait de service. Et conserver un horizon de comparaison commun : un investissement initial et un abonnement mensuel ne se comparent pas sur la seule facture du premier mois.

L’arbitrage entre IA locale et cloud intervient à ce niveau. L’hébergement local déplace certains coûts vers le matériel et l’exploitation. Il ne les fait pas disparaître. Une API peut alléger l’investissement initial tout en exposant davantage la dépense aux volumes consommés.

Le temps gagné ne devient pas automatiquement une économie

Si un salarié termine une tâche plus rapidement, plusieurs choses peuvent se produire. Il peut absorber davantage de demandes, réduire un retard, consacrer plus de temps aux dossiers complexes ou simplement attendre l’étape suivante du processus. Ces situations n’ont pas la même valeur économique.

Dans leur working paper Generative AI at Work, publié en 2023, Erik Brynjolfsson, Danielle Li et Lindsey R. Raymond étudient l’introduction d’un assistant auprès de 5 179 agents de support client. Les effets observés sur la productivité sont très différents selon l’expérience des agents, avec un bénéfice particulièrement marqué chez les moins expérimentés. Ce résultat invite à regarder les tâches et les populations concernées, plutôt qu’à appliquer un coefficient de productivité uniforme à toute l’entreprise.

Une capacité libérée est donc une possibilité à organiser. Pour en faire une économie budgétaire, il faut identifier une dépense effectivement évitée. Pour en faire du chiffre d’affaires, il faut une demande supplémentaire, une capacité à la servir et une marge. Pour en faire une amélioration de qualité, il faut mesurer cette qualité.

Ces bénéfices peuvent être intéressants sans se traduire immédiatement en réduction de masse salariale. Les présenter pour ce qu’ils sont rend le dossier d’investissement plus solide, pas moins ambitieux.

Un pilote doit permettre de trancher

Le premier test ne devrait pas chercher seulement à montrer que l’outil sait répondre. Il doit lever les incertitudes qui empêchent de décider.

On commence par mesurer la situation actuelle sur un échantillon représentatif : durée de bout en bout, qualité attendue, erreurs, reprises et coût de traitement. Le test avec IA porte ensuite sur des cas comparables, y compris les cas difficiles. Il suit le même résultat final, pas seulement la vitesse d’une étape devenue automatique.

Il reste à convenir, avant les résultats, de ce qui justifierait une généralisation, une correction du dispositif ou son arrêt. Sans cela, une démonstration séduisante peut tenir lieu de décision alors que les hypothèses de départ n’ont pas été vérifiées.

Le cadre volontaire NIST AI RMF 1.0 fournit un appui utile : sa fonction MAP demande de préciser le contexte d’usage, les bénéfices attendus, les coûts potentiels des erreurs et les modalités de supervision humaine. Il n’apporte pas une garantie de rentabilité. Il rappelle que les propriétés du modèle ne suffisent pas à définir celles du service.

Le montant à financer doit finalement correspondre à un résultat, à un périmètre et à des conditions d’exploitation. Lorsque certaines hypothèses restent trop incertaines, un pilote limité peut fournir les observations manquantes avant un engagement plus large. Le budget devient alors un moyen de comparer des résultats et leurs conditions de réalisation, plutôt qu’une simple addition de licences.