Le projet de loi sur les jetons ne constitue pas une étude de cas commerciale pour l'IA

Chaque agent de recouvrement perdait du temps avant même que le travail proprement dit ne commence. Il ne s'agissait pas seulement de comprendre le compte, de décider des actions à entreprendre ou de faire avancer le dialogue avec le client. Avant toute chose, il fallait ouvrir plusieurs systèmes ERP, comparer les données des factures, valider le statut des paiements, identifier les écarts, les corriger et se constituer un dossier solide afin de connaître la situation réelle. De l'extérieur, ce travail ressemblait à du recouvrement classique. En interne, une grande partie consistait en un travail d'assemblage : rassembler les éléments, vérifier les chiffres et préparer le terrain avant que l'agent puisse se consacrer pleinement à sa mission.

Ce travail invisible coûtait environ deux heures par agent de recouvrement et par jour. Cela ne paraissait pas alarmant car les équipes s'y étaient habituées. L'organisation avait appris à composer avec les contraintes quotidiennes liées à la navigation entre les systèmes, à la comparaison des données et à la préparation des informations avant toute action. Mais lorsque ce type de tâche se répète quotidiennement au sein d'une équipe, il cesse d'être un simple désagrément et devient un fardeau structurel. L'automatisation de la comparaison des factures entre différents systèmes a permis de récupérer environ 9 000 heures de travail, non pas en remplaçant du personnel ni en prétendant que le recouvrement ne nécessitait aucun jugement, mais en supprimant la charge de travail administrative qui empêchait les employés qualifiés de se consacrer à des tâches à plus forte valeur ajoutée.

C'est un aspect souvent négligé dans les études de cas en IA. Elles se concentrent trop sur le coût visible de la technologie et pas assez sur le coût invisible du travail. En IA, cela se traduit souvent par une focalisation excessive sur le coût des jetons, sans prendre en compte les coûts opérationnels associés. La tarification des modèles est cruciale. Jetons d'entrée, jetons de sortie, mise en cache, fenêtres de contexte, latence, niveaux de service des fournisseurs, frais de plateforme et limites d'utilisation sont autant d'éléments importants. Aucune entreprise ne devrait les ignorer. Mais ils ne constituent pas l'étude de cas à eux seuls. Ils n'en représentent qu'une partie, et parfois même pas la plus importante.

La véritable question économique n'est pas de savoir quel modèle est le moins cher par jeton. Il s'agit plutôt de déterminer quel modèle opérationnel offre le coût fiable le plus bas par résultat résolu. Cette distinction est cruciale car un jeton est facile à comptabiliser, contrairement à un résultat résolu. Un jeton figure sur une facture. Un résultat résolu s'inscrit dans un flux de travail, avec toutes les étapes de révision, de correction, de retouche, d'escalade, de temps d'attente, de gouvernance, de gestion des exceptions et d'intervention humaine nécessaires à la finalisation du projet. Si l'on mesure l'économie de l'IA uniquement au niveau du modèle, l'analyse de rentabilité peut sembler simple, mais l'exploitation reste complexe.

Voilà comment les analyses de rentabilité de l'IA deviennent trop optimistes. Elles comptabilisent la première ébauche, mais pas la réécriture. Elles comptabilisent la réponse du chatbot, mais pas le contact ultérieur. Elles comptabilisent la première réponse, mais pas la réouverture du dossier. Elles comptabilisent l'interaction avec le modèle, mais pas l'effort humain nécessaire pour rendre le résultat exploitable. Elles comptabilisent l'automatisation visible et ignorent les personnes qui, discrètement, protègent le processus contre les erreurs de conception. Il ne s'agit pas d'un détail financier. Il s'agit de la différence entre l'activité de l'IA et sa valeur ajoutée.

Le système de jetons est attrayant car il offre aux responsables des éléments concrets. Un modèle est moins cher, un autre plus rapide. L'un gère un contexte plus étendu, un autre est plus performant en matière de raisonnement. L'un prend en charge la mise en cache, un autre a un coût par appel inférieur. La comparaison paraît rigoureuse car les chiffres sont clairs, mais une clarté excessive à un niveau inapproprié peut induire en erreur. Un modèle bon marché peut produire un résultat nécessitant davantage de vérifications, de corrections et d'escalades. Un modèle plus coûteux peut réduire suffisamment la charge de travail en aval pour s'avérer plus économique en pratique. Un modèle léger peut être idéal pour une classification simple, mais peu performant pour le traitement de cas complexes. Une stratégie de routage peut être préférable à l'utilisation d'un seul modèle pour tous les types de tâches.

Le problème n'est pas celui du prix. Il s'agit de l'adéquation au résultat. Le travail en entreprise ne s'arrête pas lorsque l'IA génère une réponse. Il s'arrête lorsque le dossier est valide, accepté, maîtrisé et n'est pas renvoyé à l'organisation pour être retravaillé. Si un flux de travail se ferme rapidement mais se rouvre ultérieurement, la première fermeture ne reflétait pas le véritable résultat. Si une réponse est générée rapidement mais que sa validation humaine prend plus de temps, la rapidité du modèle n'est pas un atout pour l'entreprise. Si un agent achemine rapidement le travail mais envoie les exceptions au mauvais responsable, la rapidité d'acheminement n'est pas synonyme de productivité, mais de confusion accrue.

C’est pourquoi l’unité de coût est importante. Si l’organisation mesure le coût par appel de modèle, elle privilégiera les appels les moins chers. Si elle mesure le coût par résultat obtenu, elle privilégiera la qualité du travail. Ces deux approches peuvent mener à des décisions très différentes. La première relève d’une réflexion sur les outils. La seconde relève d’une réflexion opérationnelle. L’une vise à déterminer quelle ligne de modélisation est la plus économique. L’autre vise à déterminer si le flux de travail produit un résultat fiable sans reporter la charge ailleurs.

L'exemple des 9 000 heures est révélateur car il illustre le coût réel souvent constaté avant même l'introduction de l'IA. Ce coût ne se résumait pas à une simple facture technique, mais à la charge de travail quotidienne liée à la préparation : deux heures par collecteur et par jour, réparties sur plusieurs systèmes. Le travail ne semblait pas dysfonctionnel car il était toujours effectué par des personnes. Le problème résidait dans le fait que l'organisation avait normalisé ce gaspillage. C'est précisément ce qui se produit dans de nombreux programmes d'IA. La facture initiale est visible car elle est envoyée par le fournisseur. La facture des corrections est invisible car elle est absorbée par les employés. La facture des escalades est invisible car elle est supportée par les managers. La facture des retouches est invisible car les opérations la considèrent comme un volume normal. La facture de la confiance est invisible car les employés évitent discrètement d'utiliser l'outil pour des tâches réellement importantes.

La facture est visible, mais les coûts sont répartis. C'est pourquoi les analyses de rentabilité de l'IA doivent partir du travail lui-même, et non du prix du modèle. Quel est le coût actuel du flux de travail ? Combien de temps est consacré à la préparation, la recherche, la vérification, la correction, la remontée d'informations et la réouverture ? Que signifie un résultat résolu ? Quelles étapes sont routinières ? Lesquelles nécessitent un jugement ? Quelles exceptions se répètent ? Que se passe-t-il lorsque le résultat est erroné ? Quel contrôle humain reste nécessaire, et s'agit-il d'une supervision intentionnelle ou d'un simple nettoyage déguisé ? Sans ces questions, l'organisation risque d'approuver une analyse de rentabilité superficielle, sans une vision claire des coûts.

C'est important car l'IA améliore souvent la première étape visible avant d'optimiser l'ensemble du flux de travail. Elle rédige, résume, classe, extrait et génère plus rapidement. Cette rapidité est utile, mais n'est pas synonyme de valeur ajoutée. La valeur dépend de ce qui se passe après l'affichage du résultat. L'employé lui fait-il confiance ? Le client l'accepte-t-il ? Le dossier reste-t-il clos ? Le flux de travail évite-t-il les reprises ? Le résultat réduit-il les escalades ? Améliore-t-il le contrôle ? Libère-t-il des ressources pour des tâches plus intéressantes ? Ou se contente-t-il de déplacer les efforts vers la vérification, la correction et l'explication ?

Le héros opérationnel se réjouit des économies visibles. L'architecte, lui, suit les coûts de près jusqu'à la résolution complète du problème. Un modèle réduisant le temps de rédaction de cinq minutes semble idéal jusqu'à ce que le dossier soit rouvert. Un chatbot traitant davantage de demandes semble idéal jusqu'à ce que les contacts répétés augmentent. L'automatisation d'un flux de travail semble idéale jusqu'à ce que les exceptions soient renvoyées aux superviseurs. Un modèle moins coûteux semble idéal jusqu'à ce que la vérification humaine devienne le véritable centre de coûts. Il ne s'agit pas de scepticisme gratuit, mais de rigueur opérationnelle.

La même logique se retrouve dans les moindres détails. Dans une autre opération, réduire le temps de téléchargement d'une facture de 16 à 8 secondes peut sembler insignifiant pris isolément. Une demi-seconde par-ci, quelques secondes par-là, un clic en moins, un fichier récupéré plus rapidement. Les dirigeants négligent souvent ces micro-frictions car elles ne paraissent pas stratégiques. Mais répétées sur un volume important de tâches, ces petites frictions s'accumulent. Quelques secondes multipliées par des milliers de transactions représentent un impact sur la capacité. Une vérification manuelle quotidienne devient un coût. Un changement de système régulier devient une charge cachée. La taille de l'unité importe moins que sa fréquence et son rôle dans le flux de travail.

Les analyses de rentabilité de l'IA exigent la même rigueur. Un résultat de modèle peut sembler peu coûteux, mais si chaque résultat nécessite une petite correction, et que cette correction se répète sur des milliers de cas, le coût réel s'en trouve modifié. Si un flux de travail permet de gagner quelques minutes, mais augmente le taux de réouverture, la rentabilité est bouleversée. Si un outil réduit un type de tâche manuelle, mais en ajoute ailleurs, les économies ne sont pas totales ; elles sont simplement déplacées. L'analyse de rentabilité ne doit pas se limiter à ce que l'IA supprime, mais aussi à ce qu'elle laisse derrière elle.

C’est là que de nombreux programmes se fragilisent. Ils partent du principe que la vérification humaine est gratuite puisque des personnes sont déjà en place. Ils supposent que la correction est temporaire car le modèle s’améliorera. Ils supposent que les problèmes sont rares car l’échantillon pilote était concluant. Ils considèrent la gouvernance comme une charge inutile car elle ne semble pas générer de productivité. Ils supposent que l’adoption est synonyme de valeur ajoutée car l’utilisation est visible. Ces hypothèses rendent le projet plus facile à approuver, mais plus difficile à défendre.

La correction humaine est un piège majeur. On la présente souvent comme une supervision responsable, et c'est parfois le cas. Certains flux de travail nécessitent une relecture humaine, sont même essentiels et conçus intentionnellement. Cependant, il y a une différence entre supervision et correction. La supervision protège le travail effectué, tandis que la correction compense une conception défaillante. Si une personne relit le résultat d'une IA parce que le flux de travail exige un jugement, cela peut constituer une bonne gouvernance. En revanche, si cette personne réécrit le résultat, vérifie trois systèmes, complète le contexte manquant, identifie l'exception et empêche la poursuite d'une action erronée, il s'agit d'un travail de retouche invisible. Si ce travail invisible n'est pas mesuré, l'analyse de rentabilité de l'IA est incomplète.

Il en va de même pour l'escalade. Une certaine escalade est nécessaire, notamment pour les tâches à haut risque, mais toute escalade évitable engendre des coûts. Lorsqu'une IA ne détecte pas une exception, achemine mal un cas ou produit un résultat non fiable pour un employé de première ligne, le problème est transféré à un superviseur, un spécialiste, un responsable, l'équipe de gestion des risques ou un responsable en contact direct avec la clientèle. Ce temps supplémentaire est plus coûteux, plus perturbateur et rarement pris en compte dans la comparaison des modèles. Le coût de l'IA ne se limite pas à ce que le modèle consomme. Il englobe également les efforts que l'organisation a dû déployer pour rendre le résultat exploitable.

C’est pourquoi le coût par résultat résolu est un meilleur indicateur que le coût par jeton. Un résultat résolu englobe l’intégralité du processus : saisie, récupération, interaction avec le modèle, vérification humaine, correction, escalade, gouvernance, clôture et suivi qualité post-clôture. Si le dossier est rouvert, le résultat n’était pas aussi satisfaisant que le tableau de bord le laissait entendre. Un ticket d’assistance client n’est pas résolu parce que le bot a répondu une fois. Il est résolu lorsque le client n’a plus besoin de revenir pour le même problème. Un flux de travail financier n’est pas résolu parce que le système a enregistré une écriture. Il est résolu lorsque l’écriture est valide, rapprochée et n’entraîne aucune correction en aval. Un flux de travail d’approvisionnement n’est pas résolu parce qu’un document a été extrait. Il est résolu lorsque la commande peut progresser grâce à des données fiables, une validation correcte et des exceptions maîtrisées.

C’est là que les discussions avec les fournisseurs doivent être plus rigoureuses. Ils peuvent présenter les capacités du modèle, les fonctionnalités de la plateforme, des exemples d’automatisation et des comparaisons de coûts. C’est utile, certes, mais insuffisant. L’organisation doit apporter sa propre réalité opérationnelle à la discussion. Sinon, le fournisseur finit par axer son argumentaire sur les capacités de l’outil, et non sur les besoins réels de l’entreprise. Une entreprise qui ne comprend pas clairement son flux de travail devient une cliente facile, séduite par les promesses génériques de l’IA. On lui promet que l’IA réduira les délais de traitement, améliorera la productivité, soutiendra les employés, automatisera les tâches répétitives et libérera des ressources. Ces affirmations peuvent être vraies, mais seulement si le travail est correctement sélectionné et conçu.

La question n'est pas de savoir si l'IA peut créer de la valeur en général. Elle le peut. La question est de savoir si cette intervention de l'IA crée une valeur mesurable dans ce flux de travail, une fois tous les coûts pris en compte. Pour répondre à cette question, il faut des données opérationnelles. Il faut établir une situation de référence. Combien de temps prend le travail aujourd'hui ? Où est-il bloqué ? À quelle fréquence est-il corrigé ? À quelle fréquence est-il rouvert ? Quelles exceptions entraînent une escalade ? Quel effort est consacré à la recherche, la préparation, la comparaison et la validation avant même que le travail visible ne commence ? Qui supporte la charge invisible ?

Dans le cas des 9 000 heures, la charge cachée n'était pas d'ordre philosophique. Elle était quotidienne et mesurable. Deux heures par collecteur et par jour étaient absorbées par la comparaison multisystème avant même que les tâches à plus forte valeur ajoutée puissent être effectuées. Une fois cette charge supprimée, l'opération a gagné en capacité sans qu'il soit nécessaire de rejeter la faute sur les employés. Le problème ne venait pas des employés, mais de la conception du travail. Cette leçon s'applique directement à l'IA. Si l'analyse de rentabilité de l'IA repose sur le remplacement de l'effort humain sans comprendre la nature de cet effort, elle restera superficielle. Une partie de l'effort est du gaspillage. Une autre relève du jugement. Une autre encore du contrôle. Une autre enfin de la gestion des exceptions. Une autre enfin de la compensation des systèmes défaillants. Considérer tout cela comme un seul et même « gain de temps » conduit à de mauvaises décisions.

Une analyse de rentabilité rigoureuse permet de bien segmenter les tâches. Quelles sont les responsabilités ? Quelles sont les tâches à automatiser ? Quelles sont celles qui doivent rester manuelles ? Quelles sont celles qui doivent devenir des connaissances réutilisables ? Quelles sont celles qui doivent déclencher une alerte ? Quelles sont celles qui n’auraient jamais dû être une charge de travail manuelle ? Cette segmentation empêche l’IA de devenir une source supplémentaire de complexité et de coûts. Elle modifie également la façon dont la finance doit appréhender l’IA. Le directeur financier ne doit pas se contenter de s’interroger sur le coût du modèle. Il doit s’interroger sur la valeur ajoutée, sur la réduction des coûts (transfert ou simple déplacement), sur la libération effective de capacités, sur la diminution des taux de réouverture, sur la simplification de la gouvernance des flux de travail et sur la capacité de l’organisation à construire des connaissances réutilisables ou à réinvestir pour redécouvrir le même travail l’année suivante.

Ces questions ne sont pas contre l'IA. Elles sont au contraire favorables à sa création de valeur. Elles protègent l'organisation des faux-semblants. Ces faux-semblants se produisent lorsque l'organisation constate une activité, mais ne peut prouver d'amélioration opérationnelle. Un outil est opérationnel. Un tableau de bord est fonctionnel. Les utilisateurs s'en servent. Le fournisseur est satisfait. Le programme interne paraît moderne. Mais le travail de fond reste conséquent. Les employés continuent de corriger les problèmes. Les managers continuent de les signaler. Les exceptions persistent. Le service financier ne perçoit toujours pas clairement la valeur ajoutée. Il ne s'agit pas d'une transformation, mais d'une agitation superficielle.

La meilleure approche est plus pragmatique. Commencez par évaluer le coût actuel du travail. Intégrez les étapes invisibles : recherche, assemblage, vérification, correction, réouverture, remontée d’informations et gouvernance. Déterminez ensuite comment l’IA peut réduire les frictions de manière responsable. Après le déploiement, mesurez l’amélioration du résultat global, et non la rapidité d’obtention du premier résultat. Ceci est particulièrement important lors du passage d’une approche collaborative à une approche automatisée. Une approche collaborative peut aider une personne à rédiger une ébauche, à résumer un document ou à préparer une réponse, mais l’humain reste impliqué dans la production. Un agent peut influencer le flux de travail plus directement : acheminement, mise à jour, déclenchement, priorisation ou exécution. Cela modifie le coût des erreurs.

Si un agent génère davantage de corrections, les coûts peuvent rapidement s'accumuler. S'il gère mal les exceptions, les escalades se multiplient. S'il agit sans traçabilité suffisante, les coûts de gouvernance augmentent. Si les employés n'ont pas confiance, l'adoption reste superficielle. Si le flux de travail n'était pas prêt, l'organisation en paiera le prix fort en raison des travaux de correction. La facture initiale ne le reflétera pas. Seul le travail accompli, lui, le révélera.

C’est pourquoi l’analyse de rentabilité doit être élaborée au niveau du flux de travail, et non au niveau du modèle. Différents flux de travail requièrent différentes logiques économiques. Une tâche de classification à faible risque et à volume élevé peut justifier un modèle moins coûteux avec un échantillonnage humain léger. Une exception financière complexe peut justifier un modèle plus robuste, des contrôles plus stricts et une vérification humaine plus approfondie. Un flux de travail orienté client peut nécessiter des fenêtres de qualité et une mesure de réouverture. Un flux de travail soumis à des exigences de conformité peut nécessiter une traçabilité et une escalade contrôlée. Une stratégie de modélisation unique pour chaque type de travail est rarement la solution optimale. La solution optimale consiste à adapter le niveau de capacité d’IA, de supervision humaine, de gouvernance et de tolérance aux coûts à la nature du travail.

Les organisations internationales doivent redoubler de vigilance. Un même flux de travail peut présenter des résultats économiques différents selon les régions, en raison des variations du coût de la main-d'œuvre, de la complexité linguistique, de la maturité des processus, de la réglementation, des attentes des clients et de la qualité des données. Un modèle qui semble efficace sur un marché peut engendrer des difficultés de correction sur un autre. Un flux de travail automatisable dans une région peut nécessiter davantage d'intervention humaine ailleurs. Une analyse de rentabilité globale qui ignore les réalités opérationnelles locales paraîtra simple au siège, mais sera chaotique dans son exécution. La solution n'est pas de traiter chaque marché comme un cas particulier, mais d'appliquer une logique économique commune, étayée par des données locales. Le coût par résultat obtenu constitue cette logique commune. Les données locales expliquent les conditions nécessaires à l'obtention du résultat dans son contexte.

Le même principe s'applique aux employés. Si on leur demande d'utiliser l'IA mais qu'ils sont toujours évalués uniquement sur leur productivité manuelle, ils privilégieront l'ancien système de notation. Si on leur demande de valider les résultats mais que cette validation est perçue comme un délai, ils seront contraints d'aller plus vite que ce que le flux de travail peut supporter en toute sécurité. Si on leur demande d'acquérir des connaissances mais que seule la clôture des dossiers est récompensée, l'acquisition de connaissances restera secondaire. Si on leur demande de superviser les agents mais que cette supervision est invisible dans la planification de la charge de travail, l'analyse de rentabilité sous-estimera le travail humain nécessaire pour garantir la fiabilité de l'IA. La facturation ne le reflétera pas non plus. Seul le système de performance, lui, le révélera.

C’est pourquoi la valeur de l’IA est indissociable de sa conception opérationnelle. Le modèle ne représente qu’une partie du coût. La question fondamentale est de savoir si l’organisation a conçu le travail, les rôles, la gouvernance et les indicateurs de performance en fonction du résultat escompté. L’exemple des 9 000 heures ne nous apprend pas que l’automatisation est toujours la solution. Il nous apprend plutôt que le travail invisible doit être mis en lumière avant toute affirmation sérieuse de valeur ajoutée. Une fois la charge de comparaison cachée révélée, l’entreprise a pu repenser le travail. L’IA exige la même rigueur. Avant de parler d’économies, les dirigeants doivent identifier le travail supprimé, celui qui subsiste et celui qui est créé.

Autrement, l'analyse de rentabilité devient trop simpliste. Elle affirme que l'IA permet de gagner du temps, mais sans tenir compte des corrections. Elle prétend qu'elle réduit les coûts, mais sans suivre les escalades. Elle affirme qu'elle améliore la productivité, mais sans mesurer les tâches rouvertes. Elle affirme qu'elle soutient les employés, sans se demander si l'outil a allégé leur charge de travail ou ajouté un niveau de contrôle supplémentaire. La facture symbolique ne constitue pas l'analyse de rentabilité de l'IA, car elle n'en représente que la partie la plus visible. La véritable rentabilité réside dans le travail accompli. Elle se manifeste par le temps gagné par les employés, les erreurs évitées, la réduction des reprises, la réutilisation des exceptions, l'amélioration des décisions, le renforcement des contrôles et la réaffectation des ressources à des tâches réellement importantes.

Les dirigeants ne doivent pas ignorer le coût des modèles. Ils doivent le comprendre clairement. Mais ils doivent cesser de le confondre avec l'économie de l'IA. La question pertinente n'est pas « Quel modèle est le moins cher ? » mais plutôt « Quel flux de travail permet d'obtenir un résultat fiable et concluant au juste prix, avec le niveau de contrôle adéquat et sans détourner les coûts ? » Cette question est plus complexe. C'est aussi la seule qui révèle la vérité.

Questions et réponses

Q : Pourquoi le projet de loi sur les jetons ne constitue-t-il pas un argumentaire commercial en matière d'IA ?

A : La facture indicative ne prend en compte que le coût d'utilisation du modèle visible. Elle n'inclut pas l'intégralité des coûts opérationnels nécessaires à l'obtention d'un résultat fiable, tels que la récupération, la vérification, la correction, l'escalade, la gouvernance, les retouches, les dossiers rouverts et le temps de travail des employés.

Q : Quel est le coût par résultat obtenu ?

A : Le coût par résultat résolu correspond au coût total nécessaire pour mener à bien la tâche et garantir sa résolution. Il inclut l'interaction avec le modèle, la vérification humaine, la correction, l'escalade, la gouvernance et toute reprise effectuée avant la clôture définitive du résultat.

Q : Un modèle moins cher peut-il devenir plus cher en pratique ?

R : Oui. Un modèle moins coûteux peut devenir plus onéreux s'il génère davantage de corrections, de reprises, d'escalades ou de réouvertures de dossiers. À l'inverse, un modèle plus coûteux peut parfois s'avérer plus économique au final s'il offre des résultats plus fiables et réduit le travail caché.

Q : Quels coûts cachés les dirigeants doivent-ils inclure dans les analyses de rentabilité de l'IA ?

A : Les dirigeants doivent inclure la correction humaine, les contacts répétés, la réouverture des dossiers, l'escalade, le contrôle qualité, la gouvernance, les efforts de mise en œuvre, l'intégration du système, l'infrastructure de récupération et le temps que les employés consacrent à la vérification ou à la reconstruction des résultats de l'IA.

Q : Comment le secteur financier devrait-il évaluer la valeur de l'IA ?

A : Le service financier devrait s'intéresser non seulement au coût du modèle, mais aussi à l'amélioration du flux de travail. Il est essentiel de déterminer si les délais de traitement, les taux de correction, de reprise, d'escalade et de réouverture diminuent, et si la capacité est réellement libérée ou simplement réaffectée à des tâches de révision invisibles.

Q : Quelle est la première étape pratique avant d'approuver un projet d'intelligence économique basé sur l'IA ?

A : Commencez par recenser le coût actuel du travail, en incluant les étapes préparatoires, de recherche, de vérification, de correction et les ajustements nécessaires. Une fois le coût total connu, l'IA peut être évaluée en fonction du résultat qu'elle est censée améliorer, et non uniquement en fonction du prix du modèle.