Une facture d’IA devient inexplicable quand l’entreprise suit les jetons consommés sans relier cette dépense aux équipes, aux tâches et aux résultats obtenus. Pour la rendre défendable, il faut attribuer chaque coût à un usage précis, puis décider si cet usage mérite d’être maintenu.
À 8 h 17, dans un bureau encore calme à Lyon, Nadia agrandit une cellule de son tableur. Responsable finance d’une entreprise logicielle, elle tient une tasse de café froid et regarde le même total pour la troisième fois. La facture de plusieurs services d’IA a encore augmenté. À 9 heures, elle doit l’expliquer au comité de direction.
Cette scène est fictive, mais le problème qu’elle illustre est courant. Nadia connaît le montant global et les comptes fournisseurs. Elle ignore quelle équipe a consommé quoi, pour quelle tâche et avec quel résultat. Si elle recommande une coupe générale, elle risque d’interrompre des usages utiles. Si elle laisse passer la hausse, elle valide une dépense qu’elle ne sait pas défendre.
Le total révèle une dépense, pas sa valeur
Les tableaux de bord des fournisseurs répondent souvent à une question comptable simple: combien de jetons, de requêtes ou de crédits ont été consommés? Cette information permet de vérifier la facture. Elle ne permet pas de juger l’utilité de la dépense.
Une même somme peut financer des usages très différents. Une équipe produit peut résumer des entretiens clients avant une décision de conception. Le support peut préparer des réponses qui nécessitent ensuite une réécriture complète. Des développeurs peuvent utiliser plusieurs modèles pour comparer du code, tandis qu’un script oublié continue d’envoyer des requêtes sans produire quoi que ce soit d’exploitable.
Tout arrive pourtant sur la même ligne.
Le problème ressemble à celui décrit dans les unités incompatibles de Mars Climate Orbiter et ce qu’elles révèlent sur MCP: deux systèmes peuvent afficher des données exactes tout en rendant la décision fausse, faute d’un langage commun. Ici, la finance parle en euros, les fournisseurs en jetons et les équipes en tâches terminées. Aucun de ces relevés ne suffit seul.
Relier chaque coût à une décision observable
À 8 h 34, Nadia ouvre les journaux d’accès et appelle Malik, responsable de l’ingénierie. Ils découvrent que les clés d’API portent des noms de projets devenus incompréhensibles. L’une s’appelle «test-final», une autre «nouveau-test-2». Plusieurs personnes partagent le même accès.
Le comité approche. La seule explication disponible tient en une phrase: «L’usage a augmenté.» Nadia sait qu’elle ne passera pas l’examen suivant: «Pour produire quoi?»
Le tournant vient d’une feuille vierge, ouverte quelques minutes avant la réunion. Nadia et Malik cessent de chercher une justification parfaite pour la facture entière. Ils classent les dépenses selon quatre champs qu’ils peuvent vérifier:
- l’équipe responsable;
- la tâche effectuée;
- le modèle ou le service utilisé;
- le résultat observable, comme un ticket traité, une analyse relue ou une version livrée.
Cette structure ne prouve pas automatiquement qu’une dépense crée de la valeur. Elle rend toutefois les usages comparables et les zones opaques visibles. Une consommation sans propriétaire devient un problème à corriger. Un usage coûteux associé à un résultat important devient une décision à examiner, plutôt qu’une anomalie à supprimer.
Rippling a récemment lancé AI Spend Console après une hausse rapide de ses propres dépenses en jetons d’IA. Le principe annoncé consiste précisément à rapprocher les coûts et les usages des résultats par employé et par équipe. Ce contexte apporte un signal utile: la question du suivi se déplace du fournisseur vers le travail réellement accompli.
Installer des garde-fous avant la prochaine facture
Attendre le relevé mensuel transforme la maîtrise des coûts en enquête rétroactive. Les règles doivent exister au moment où un nouvel usage commence.
Chaque clé, abonnement ou agent devrait avoir un propriétaire nommé, une équipe, un objectif et une date de réexamen. Les environnements d’essai doivent être séparés de la production. Les alertes doivent porter sur les variations inhabituelles par projet, plutôt que sur un plafond global qui mélange tout.
Il faut aussi distinguer trois catégories:
- les usages établis, dont le résultat est observable;
- les expérimentations, avec un budget et une durée définis;
- les consommations orphelines, sans responsable ni résultat identifiable.
Cette distinction évite deux erreurs symétriques. La première consiste à couper un outil utile parce qu’il coûte davantage après son adoption. La seconde consiste à confondre activité technique et progrès réel. Une longue série de requêtes peut produire une décision solide, du texte inutilisable ou rien du tout.
Le suivi doit rester proportionné. Demander à chaque salarié de remplir un dossier pour chaque requête créerait une nouvelle dépense administrative. L’attribution peut commencer au niveau du projet, puis devenir plus précise là où les montants ou les risques le justifient.
La question à poser le lundi matin
À 9 h 02, Nadia n’arrive pas avec une explication complète. Elle présente trois groupes de dépenses, deux usages identifiés comme utiles et plusieurs accès impossibles à attribuer. Elle demande le gel des accès orphelins, pas celui de tous les outils.
La décision reste imparfaite, mais elle devient défendable. L’équipe peut préserver les usages reliés à un travail concret, limiter les expériences et enquêter sur le reste.
Le lundi suivant, Nadia ne commence plus par le total de la facture. Elle ouvre un tableau où chaque ligne répond à une question plus exigeante: quelle équipe a dépensé cet euro, pour quelle tâche, et quel résultat peut-elle montrer?
Commentaires
Pas encore de commentaires.