Le nombre de tokens est un mauvais thermomètre si la tâche doit être recommencée

Le détail qui me gêne

Deux agents dépensent des volumes très différents, mais le moins cher produit un fichier qui revient trois fois en correction. C’est le genre de situation qui paraît évidente après coup, mais qu’on oublie souvent au moment de concevoir l’usage : une consommation faible peut cacher un résultat inutilisable, et une consommation plus élevée peut éviter plusieurs heures de reprise. Le coût doit être relié au résultat.

Pourquoi ça compte plus qu’il n’y paraît

Les nouvelles fonctions IA abaissent rapidement le coût technique d’une action : chercher dans une boîte mail, modifier un tableur, créer un document ou enchaîner plusieurs applications. Le risque est de confondre capacité de l’outil et qualité du processus. Un workflow n’est pas une démonstration qui marche une fois. Il a des entrées, des règles, des états, des exceptions, un propriétaire et une manière claire de savoir si le résultat est acceptable. Pour ce sujet, je resserre volontairement la focale : Une consommation faible peut cacher un résultat inutilisable, et une consommation plus élevée peut éviter plusieurs heures de reprise. Le coût doit être relié au résultat. Sans ce détour, on finit vite par compter ce qui est visible plutôt que ce qui améliore vraiment le travail.

La tendance est suffisamment documentée pour qu’on la prenne au sérieux. Le Work Trend Index 2026, basé sur 20 000 répondants dans 10 pays, distingue capacité individuelle et préparation de l’organisation. Microsoft indique que 19 % des utilisateurs interrogés se trouvent dans la zone où ces deux dimensions se renforcent, alors que 31 % sont désalignés. Les outils de travail assisté par IA prennent en charge des missions plus longues, des fichiers, des applications et des livrables complets. Plus la durée et le nombre d’étapes augmentent, plus la question des points de contrôle et de reprise devient importante. La suite logique consiste donc à confronter ce signal à une tâche, une équipe et un résultat mesurable.

Dans une vraie journée de travail

Deux agents dépensent des volumes très différents, mais le moins cher produit un fichier qui revient trois fois en correction.

Le point faible d’un raisonnement rapide apparaît ici. La bonne question dépend donc du contexte, de la fréquence et surtout du coût d’une erreur. Deux agents dépensent des volumes très différents, mais le moins cher produit un fichier qui revient trois fois en correction. Il faut regarder qui est touché, ce qui peut mal se passer et qui pourra corriger.

Ce que je ferais à la place

Le premier contrôle que je mettrais sur la table serait simple : mesurer coût par résultat accepté, pas seulement volume de calcul. Compare le résultat accepté, pas seulement la première sortie. Les reprises racontent souvent l’histoire que la démo ne montre pas. Mesure le délai de bout en bout. C’est le seul moyen de voir si l’amélioration locale change vraiment le service rendu. Dessiner le processus actuel avant d’ajouter des connecteurs ou des agents. L’intérêt est surtout de créer un critère observable. Si personne ne peut dire si ce point est respecté, la règle restera décorative.

Définir l’état d’entrée, le résultat attendu et les cas d’exception. Le but n’est pas d’ajouter une couche de procédure. C’est de rendre visible la décision qui existait déjà, souvent de manière implicite.

Rendre visibles les changements effectués par l’IA afin qu’ils puissent être contrôlés. C’est le moment de comparer la promesse au flux réel, pas au scénario idéal préparé pour la démo.

Mesurer la tâche de bout en bout, y compris reprises et attente après l’étape automatisée. Le détail est moins spectaculaire que l’outil, mais il protège celui qui devra reprendre le résultat derrière.

La limite à garder en tête

L’outil peut prendre une action en charge. La responsabilité du processus, elle, doit toujours avoir un propriétaire clair. Plus le résultat est sensible, plus le niveau de preuve, de contrôle et de possibilité de reprise doit être explicite.

Je terminerais avec un contrôle plutôt qu’avec une promesse : mesurer coût par résultat accepté, pas seulement volume de calcul. C’est moins spectaculaire qu’une démo, mais beaucoup plus utile pour faire tenir l’usage dans le temps.