Tous les articles

FinOps

Pourquoi le FinOps de l’IA deviendra critique pour l’IA d’entreprise

Toute discipline de maîtrise des coûts qui a échoué en informatique a la même forme : ceux qui peuvent agir sur le chiffre ne le voient jamais. L’IA d’entreprise reproduit cette forme presque parfaitement, et c’est pourquoi le sujet devient urgent plus tôt qu’on ne l’imagine.

Le FinOps cloud s’est construit sur une hypothèse fiable : le coût suit la capacité. Vous provisionnez une machine virtuelle, vous payez cette machine virtuelle, et l’unité de compte est le temps. Tout ce qui en découle — étiquetage, showback, redimensionnement, réservations — repose sur cette seule idée.

L’IA d’entreprise rompt cette hypothèse d’une manière bien précise, et la plupart des dispositifs de gouvernance des coûts conçus pour le cloud ne s’en aperçoivent pas.

L’unité de compte se déplace

Dans le cloud classique, la dépense s’attache à une ressource. Étiquetez le groupe de ressources et vous savez quelle équipe porte la facture.

Un déploiement Azure OpenAI est lui aussi une ressource, et il portera lui aussi vos étiquettes. Mais l’étiquette vous apprend que ce déploiement a coûté quarante mille euros le trimestre dernier. Elle ne vous dit pas quel assistant les a dépensés, quelle direction a posé les questions, ni si l’argent est parti dans des réponses utiles ou dans la récupération de documents que personne n’a lus.

L’unité qui compte n’est plus la ressource : c’est la requête — et, à l’intérieur de la requête, les tokens. Ce chiffre est produit par le comportement de l’application, pas par une décision d’infrastructure, et rien dans votre modèle de coûts actuel ne regarde à cet endroit.

Le coût se décide désormais dans le code applicatif

C’est le point qui prend les directions financières au dépourvu.

Un développeur améliore la qualité des réponses en transmettant davantage de contexte au modèle : l’étape de recherche renvoie désormais huit passages au lieu de quatre. Les tokens d’entrée doublent approximativement pour chaque requête empruntant ce chemin. C’est une évolution technique sensée, faite pour une bonne raison, et il s’agit d’arithmétique plutôt que de prévision : deux fois plus de contexte, c’est deux fois plus d’entrée.

Observez maintenant ce qui ne s’est pas produit. Aucune machine plus grande. Aucune nouvelle ressource. Aucune discussion d’achat. Aucun point de validation, aucune revue d’architecture, rien sur quoi une alerte budgétaire pourrait se déclencher. Une modification d’une ligne sur un paramètre de recherche a changé le coût marginal de tout le service, et la personne qui l’a faite ignore peut-être qu’un modèle de coûts existe.

Les contrôles cloud traditionnels sont calibrés pour un monde où dépenser de l’argent supposait de déployer quelque chose. En IA, dépenser de l’argent suppose de fusionner une branche.

Le succès aggrave la situation

La deuxième surprise tient à la direction du phénomène.

Presque tout autre système d’entreprise devient moins cher par utilisateur à mesure qu’il grandit. Les coûts fixes s’amortissent, les licences passent des paliers, la plateforme tourne déjà. Élargissez le déploiement et les coûts unitaires s’améliorent. Cet automatisme est si profondément ancré que personne ne l’énonce.

L’inférence ne fonctionne pas ainsi. Le coût marginal par conversation reste globalement stable — les engagements et le cache l’infléchissent, ils ne le brisent pas. Doublez l’adoption et vous doublez approximativement la dépense. Le pilote qui coûtait quelques centaines d’euros par mois n’était pas économique parce qu’il était efficace : il l’était parce que vingt personnes l’utilisaient.

Le moment le plus dangereux pour le budget d’un programme d’IA est donc celui que tout le monde célèbre : celui où l’assistant devient réellement utile et où les usages décollent.

Les agents élargissent la distribution

Un service de recherche et de réponse présente un coût par requête prévisible. Un agent s’exécute jusqu’à estimer qu’il a terminé : une même demande utilisateur peut représenter deux appels de modèle ou quinze.

La conséquence pratique, côté budget, est que la moyenne cesse d’être la statistique utile. La capacité et les coûts se planifient sur la traîne — le p95 des appels par tâche, avec un plafond ferme d’itérations pour qu’une requête pathologique ne tourne pas tout l’après-midi. Les équipes qui prévoient sur des moyennes découvrent la variance en production, à l’échelle, le mois même où l’adoption progresse.

Les anciens leviers ne conviennent pas

Le redimensionnement n’a pas d’équivalent ici : on ne redimensionne pas une conversation. Les leviers qui font réellement bouger la dépense IA sont d’une autre nature :

  • La discipline du contexte. Récupérer moins de passages, mais meilleurs. La plupart des chaînes de recherche envoient plus de contexte que la réponse n’en exige, parce que « plus » paraissait plus sûr pendant le développement.
  • Le routage des modèles. La classification, l’extraction et l’aiguillage n’exigent que rarement votre modèle le plus performant. Envoyer chaque étape au plus gros modèle est le gaspillage le plus répandu en IA de production.
  • Le cache. Cache de prompt pour le contexte système stable, et mise en cache des réponses aux questions qu’une organisation pose de façon répétée — c’est-à-dire, en entreprise, la plupart d’entre elles.
  • Les limites de sortie. Les réponses verbeuses coûtent plus cher et sont rarement meilleures. Plafonnez-les délibérément plutôt qu’accidentellement.
  • Les modèles d’engagement. Le débit provisionné échange de la souplesse contre un tarif effectif plus bas. C’est l’équivalent d’une réservation, mais le profil de risque diffère, car la demande sur laquelle vous vous engagez relève des comportements et non de l’architecture.

Chacun de ces leviers est une évolution technique. Aucun n’est une décision d’achat. C’est précisément le problème.

Coût et qualité se mesurent ensemble

Ce qui précède comporte un mode de défaillance évident : tous ces leviers réduisent le coût en réduisant ce que le modèle reçoit ou ce qu’il a le droit de faire. Appliqués sans mesure, ce n’est pas de l’optimisation, mais une dégradation de la qualité que vous ne voyez pas.

C’est pourquoi le FinOps de l’IA et l’évaluation de l’IA sont le même programme sous deux étiquettes. Un jeu d’évaluation figé — des questions aux réponses connues — est ce qui permet d’affirmer que la configuration la moins chère est aussi une configuration acceptable. Sans lui, chaque économie est un pari que trancheront plus tard les réclamations des utilisateurs, et l’équipe apprend à cesser d’optimiser.

Le chiffre que la direction finira par demander

Tôt ou tard, quelqu’un demandera ce que l’assistant coûte par conversation, et si c’est moins que ce qu’il a remplacé.

La question est la bonne, et la plupart des organisations ne savent pas y répondre. Non parce que la donnée serait indisponible, mais parce que personne n’a instrumenté la requête : quel cas d’usage, quel modèle, combien de tokens en entrée et en sortie, combien d’appels. Capturez ces quatre éléments par requête dès le premier déploiement et la réponse tient dans une requête analytique. Ajoutez-les après un an de production et cela devient un projet.

La comparaison importe davantage que la valeur absolue. Un coût par demande résolue est un chiffre que le métier peut mettre en regard du processus remplacé. Un total mensuel Azure OpenAI est un chiffre sur lequel personne ne peut agir.

Pourquoi cela devient critique, et non simplement utile

Regardez la forme du problème.

La dépense se loge là où aucun contrôle existant ne surveille. Elle est décidée par des personnes qui ne voient jamais la facture. Elle croît proportionnellement au succès du programme. Et le seul moyen de la réduire — agir sur le contexte, les modèles, le cache et les limites — suppose que les ingénieurs sachent ce que leurs choix coûtent.

Toute discipline de maîtrise des coûts qui a échoué en informatique a cette forme. La discipline ne porte pas vraiment sur le coût : elle consiste à refermer la boucle, en plaçant le coût par cas d’usage devant l’équipe qui peut le changer, en quelques jours plutôt qu’en fin de trimestre, à côté d’une mesure de qualité qui lui dira si elle a cassé quelque chose pour y parvenir.

Faites-le tant que les chiffres sont petits : c’est un tableau de bord et une habitude. Attendez qu’ils soient élevés et cela deviendra un gel budgétaire, imposé par quelqu’un qui n’avait aucun autre moyen d’évaluer le système — c’est ainsi que des programmes d’IA prometteurs s’arrêtent sans bruit.

Prêt à bâtir un cloud Microsoft sécurisé et prêt pour l’IA ?

Commencez par une évaluation ciblée de votre environnement cloud, sécurité, IA ou FinOps.