Des dépenses en jetons à l'économie des flux de travail : ce qu'exige le cadre de retour sur investissement de l'IA du BCG

Une facture de jetons vous indique le coût d'une inférence. Elle ne vous dit pas si le travail a été accepté, si un humain a dû le refaire ou si le résultat commercial est arrivé deux semaines plus tard. La gestion de l'économie de l'IA nécessite une nouvelle unité de contrôle : l'exécution du flux de travail, associée à son résultat final.

Le BCG propose une approche pertinente : cesser de considérer le jeton comme unité de gestion et commencer à mesurer le coût d'un résultat réussi. Son cadre de retour sur investissement de l'IA privilégie le rendement économique par rapport au coût combiné de l'intelligence humaine et des jetons. Il préconise également un modèle opérationnel au niveau du flux de travail capable de visualiser les dépenses, d'ajuster les coûts et de prouver la valeur — ou d'interrompre l'activité.

L'idée est solide. La difficulté réside dans sa mise en œuvre.

Les passerelles de modèles observent les requêtes. Les environnements d'exécution des agents observent les tours, les outils, les tentatives et les pauses. La finance voit les factures. Les systèmes métier observent si un dossier est clos, un paiement réglé, une demande de fusion expédiée ou une escalade rouverte. Aucun de ces enregistrements, pris isolément, ne constitue un retour sur investissement de l'IA.

1. Le jeton est une unité de facturation, pas une unité commerciale

Les jetons restent une télémétrie essentielle. Ils expliquent la taille des entrées, des sorties, le comportement du cache et une partie du coût d'un appel de modèle. Mais ils n'ont pas de signification commerciale stable selon les modèles ou les fournisseurs. Les tokeniseurs diffèrent. Les entrées, sorties, entrées en cache, création de cache, raisonnement, audio et autres modalités peuvent être soumis à des règles de facturation différentes. Un million d'unités dans un produit n'est pas automatiquement équivalent à un million d'unités dans un autre.

Même au sein d'une même catégorie tarifaire, où le coût facturé peut évoluer linéairement avec le volume de jetons, l'économie des flux de travail n'est pas nécessairement identique. Un contexte plus large peut modifier le comportement du modèle. Un modèle moins coûteux peut entraîner davantage de tentatives. Une réponse concise peut augmenter le besoin de révision humaine. Une mise en cache peut supprimer un appel d'inférence mais renvoyer une réponse obsolète par rapport à l'état actuel de l'utilisateur. Un agent peut entrer dans une boucle d'outils qui coûte peu par appel mais beaucoup par dossier résolu.

Le BCG identifie quatre forces de coût interdépendantes : l'étendue et la profondeur de l'adoption, l'intensité des tâches, le contexte et les boucles, et la combinaison de modèles. Ce cadre est important car chaque force existe au-delà de la requête individuelle. Une seule requête est souvent trop limitée pour montrer le travail ; une facture mensuelle de fournisseur est trop globale pour attribuer une responsabilité ou une valeur.

2. Définissez deux contrats avant de construire le tableau de bord

Un système crédible d'économie des flux de travail commence par deux contrats explicites : une enveloppe de coûts et un contrat de résultats. Le premier définit les ressources prises en compte. Le second définit ce que signifie le succès. Si l'un ou l'autre reste implicite, le coût par résultat devient un chiffre avec un dénominateur instable ou un numérateur négociable.

L'enveloppe de coûts

Pour chaque exécution de flux de travail, capturez les coûts qui modifient matériellement la décision. Cela inclut généralement l'inférence du modèle, l'utilisation des outils et de l'infrastructure, la supervision humaine, ainsi que les échecs ou les retouches. Les catégories doivent être mutuellement exclusives ou régies par une règle d'allocation afin que le même temps de correction ne soit pas compté deux fois. L'objectif n'est pas une fausse précision. Le temps humain, par exemple, peut être échantillonné par flux de travail et par rôle plutôt que mesuré à chaque clic. L'exigence est la cohérence : utilisez les mêmes règles d'inclusion lors de la comparaison des politiques.

Le contrat de résultats

« Réussi » doit être une définition versionnée et testable. Pour un flux de support, la clôture ne suffit pas si le ticket est rouvert dans les sept jours. Pour le codage, les lignes générées ne suffisent pas si le changement échoue à la révision ou n'est jamais déployé. Pour le traitement de documents, une extraction de champ n'est acceptée que lorsqu'elle passe la validation du domaine ou le rapprochement en aval.

Il s'agit d'une mesure opérationnelle, et non d'une formule de reporting financier. Lorsque la valeur d'un résultat ne peut être monétisée de manière responsable, utilisez le coût par résultat accepté et rapportez la qualité, la latence, le risque et la charge de révision en parallèle. Ne compressez pas chaque objectif en une seule estimation monétaire juste pour créer un ratio.

3. Construisez la jointure d'attribution

Les contrats de coût et de résultat ne deviennent utiles que lorsque leurs enregistrements peuvent être associés. Cette association doit être conçue avant le début de l'optimisation, car l'ajout a posteriori d'identifiants de propriété et de résultat après un pic de coûts laisse généralement des lacunes.

Un enregistrement pratique contient au moins :

• Identité du flux de travail : nom et version du flux de travail, ID d'exécution, environnement, propriétaire, équipe et centre de coûts.
• Identité de l'exécution : agent, session, tour, ID de requête ou de trace, politique de modèle, fournisseur, outils, et versions des prompts ou des compétences.
• Preuve de coût : coût d'inférence, de cache, d'outil, d'infrastructure, de révision humaine, de nouvelle tentative et de remédiation, avec la source de tarification et la version nécessaires pour reproduire le calcul.
• Identité du résultat : ID de résultat, système source, état provisoire ou définitif, méthode d'évaluation et horodatage du règlement.

Les métadonnées personnalisées constituent le tissu conjonctif. Une requête de passerelle doit porter l'ID d'exécution du flux de travail, le propriétaire, l'environnement, la limite du client ou du produit, et le centre de coûts le cas échéant. Le runtime doit préserver la même identité d'exécution à travers les tours et l'activité des outils. L'application doit inscrire cet ID d'exécution à côté du résultat final dans le système d'enregistrement.

Ne placez pas de contenu sensible dans des balises simplement parce que les métadonnées sont pratiques. Utilisez des identifiants opaques, appliquez une liste d'autorisation et résolvez les détails commerciaux au sein de l'environnement d'analyse autorisé. L'attribution doit améliorer la responsabilité sans transformer les champs d'observabilité en une nouvelle surface de fuite de données.

4. Les résultats arrivent plus tard que les coûts

Le coût d'inférence est généralement connu en quelques secondes. Les résultats commerciaux peuvent se concrétiser quelques minutes, jours ou mois plus tard. Un agent de codage peut terminer son tour aujourd'hui alors que le changement est déployé la semaine prochaine. Une conversation de service peut se fermer maintenant et rouvrir plus tard. Un assistant commercial peut rédiger un e-mail dont l'effet commercial ne sera connu que dans un trimestre.

Le registre a donc besoin d'états :

• Ouvert : le flux de travail est toujours en cours d'exécution ou en attente d'une intervention humaine.
• Provisoire : L'exécution est terminée, mais la fenêtre d'observation est ouverte.
• Accepté ou rejeté : la source de vérité a évalué le résultat défini.
• Inversé : un résultat précédemment accepté a été annulé, rouvert, rétabli ou contesté.

Cela permet d'éviter une erreur de reporting subtile : comparer le coût total d'aujourd'hui avec les résultats incomplets d'aujourd'hui. Les tableaux de bord doivent afficher les fenêtres de cohorte et la couverture de règlement. Si seulement 60 % des exécutions sont suffisamment matures pour être évaluées, le coût apparent par succès est provisoire.

5. Distinguer corrélation et causalité

Un résultat associé à une exécution d'IA est attribuable au sens de la base de données ; il n'est pas automatiquement causé par l'IA. La saisonnalité, les effectifs, les changements de politique, les évolutions de produits et les effets de sélection peuvent influencer la même métrique.

Pour les décisions importantes, établissez une base de référence et utilisez une conception expérimentale ou quasi expérimentale lorsque cela est possible : groupes témoins randomisés, déploiements progressifs, cohortes appariées ou analyse de séries temporelles interrompues. Au minimum, enregistrez la version de la politique de production et comparez des segments de flux de travail comparables.

Cette distinction est particulièrement importante lorsque l'effort humain se déplace plutôt qu'il ne disparaît. Si un assistant rédige plus rapidement mais génère davantage de travail de révision en aval, une métrique de productivité locale peut augmenter alors que le coût global reste inchangé. Le dénominateur doit suivre le flux de travail au-delà des frontières organisationnelles.

6. Optimisez un levier à la fois — et maintenez la qualité comme contrainte

Le BCG propose de supprimer l'utilisation inutile des modèles, d'acheminer les tâches selon leur complexité, de réutiliser le contexte et les composants, et de former à la discipline des jetons. Ce sont des leviers sensés. Mais chacun peut affecter la qualité, la latence et le risque ; l'optimisation nécessite donc une boucle de contrôle plutôt qu'une réduction des coûts ponctuelle.

Supprimez le modèle là où la tâche est déterministe

L'arithmétique, les recherches exactes, les seuils de politique, la validation de schéma et le routage déterministe relèvent souvent du logiciel conventionnel. Cela peut réduire les coûts et améliorer la fiabilité. L'enjeu de conception important n'est pas d'éliminer le raisonnement sans discernement, mais de le préserver pour les situations ambiguës nécessitant du jugement.

Acheminez selon la complexité de la tâche

Un modèle plus petit ou à poids ouverts peut être l'outil idéal pour les tâches routinières, tandis qu'un modèle plus performant est réservé aux cas complexes. Mais le routage est une expérience, pas une promesse. Mesurez le taux d'escalade, les tentatives, la qualité acceptée, la latence et le temps de révision par itinéraire. Un prix de requête plus bas qui augmente les boucles d'échec peut rendre le résultat plus coûteux.

Réutilisez le contexte de manière délibérée

Les préfixes stables, la mise en cache des invites du fournisseur, la mise en cache des réponses de la passerelle, l'exécution par lots, la discipline de récupération et le chargement différé peuvent réduire le travail répétitif. Ce sont des mécanismes différents avec des sémantiques distinctes. La mise en cache des invites du fournisseur réutilise le traitement de l'invite tout en générant une nouvelle réponse. La mise en cache exacte ou sémantique des réponses peut éviter l'appel au modèle, mais nécessite des contrôles d'isolation, d'expiration et de correction. Les invites et compétences versionnées améliorent la réutilisation et la gouvernance ; elles ne garantissent pas, par elles-mêmes, la possibilité de mise en cache.

Boucles limitées et sortie

Définissez le nombre maximal de tours, les tentatives d'outils, l'effort de raisonnement, les budgets de contexte et les limites de sortie adaptés au flux de travail. Enregistrez la raison pour laquelle une exécution s'est arrêtée. Une règle d'arrêt doit distinguer le succès, le transfert à un humain, le blocage par une politique, le dépassement de délai, l'épuisement du budget et l'erreur irrécupérable. Sinon, une réduction des coûts peut simplement apparaître comme une augmentation du travail abandonné.

7. Une comparaison illustrative : requêtes moins coûteuses, résultats plus onéreux

Prenons l'exemple d'un flux de travail de révision de documents qui doit choisir entre un modèle léger et un modèle plus performant. Les chiffres ci-dessous sont des unités de coût normalisées à titre d'illustration et ne constituent pas des données de référence.

‍