Le coût d'une fonctionnalité IA ne se calcule pas comme les autres

En cadrage produit, j’ai longtemps chiffré les fonctionnalités de la même façon : une charge de développement, une charge de recette, un coût d’exploitation forfaitaire. Ce modèle ne marche pas sur une fonctionnalité qui appelle un modèle de langage, et j’ai mis un projet à comprendre pourquoi.

La différence tient en une phrase : une fonctionnalité classique amortie devient gratuite, une fonctionnalité IA coûte à chaque usage. Tout le reste en découle.

Deux lignes, pas une

Je sépare désormais systématiquement.

Le coût de construction ressemble à celui de n’importe quel développement, avec une nuance : il faut y ajouter la constitution du jeu de cas d’évaluation et la mise en place de la mesure. Ce n’est pas du confort — sans eux, on ne saura pas si la fonctionnalité marche, ni si elle continue de marcher. Compter cette charge à part évite qu’elle soit rabotée en fin de projet, ce qui est sa destinée habituelle quand elle est fondue dans le développement.

Le coût d’usage n’a pas d’équivalent. Il se calcule en trois temps :

1. le coût d’une opération unitaire — un dossier traité, une conversation, un document lu ;
2. le volume attendu par mois ;
3. le facteur de croissance si la fonctionnalité prend.

Le troisième est celui qu’on oublie, et c’est celui qui fait mal.

Ce qui coûte n’est pas ce qu’on croit

Trois surprises fréquentes, dans l’ordre où elles arrivent.

Ce qu’on envoie coûte plus que ce qu’on reçoit. L’attention se porte naturellement sur la réponse produite. La facture vient surtout de ce qu’on fournit au modèle : le contexte, l’historique, les documents joints. Une conversation longue coûte de plus en plus cher à chaque tour, parce qu’on renvoie tout l’échange précédent.

Les tentatives comptent. Un appel qui échoue et qu’on rejoue est facturé deux fois. Une chaîne qui vérifie sa propre réponse par un second appel double son coût unitaire. Ces mécanismes sont souvent ajoutés pour la qualité, sans repasser par le budget.

Les cas d’échec coûtent parfois plus que les réussites. Un document illisible peut consommer plusieurs tentatives avant d’être abandonné. Si le taux d’échec est de 10 %, ces 10 % ne pèsent pas 10 % de la facture.

Le succès comme risque budgétaire

C’est le point que je mets désormais noir sur blanc dans toute proposition.

Sur une fonctionnalité classique, une adoption trois fois supérieure aux prévisions est une excellente nouvelle sans contrepartie. Ici, elle triple une ligne de coût récurrente. J’ai vu des équipes se retrouver à discuter en comité de la « trop forte utilisation » d’une fonctionnalité qu’elles avaient conçue — conversation absurde, et pourtant logique.

Ce que je fais maintenant, dès le cadrage :

• chiffrer trois scénarios — adoption faible, prévue, forte — et présenter les trois. La colonne « forte » est celle qui déclenche les bonnes questions ;
• poser un plafond, par utilisateur et par période, et surtout écrire ce qui se passe quand il est atteint. Dégradation vers une version moins coûteuse ? Mise en file ? Message explicite ? Cette décision prise à froid est toujours meilleure que celle prise un vendredi soir devant une facture ;
• rendre le coût attribuable par client ou par service. Sans cela, on ne peut ni facturer correctement, ni identifier l’usage anormal qui fait dériver le total.

Photo : domaine public (CC0).

Les leviers, par ordre de rendement

Quand il faut réduire, l’ordre est presque toujours le même — et il commence loin du modèle.

Ne pas appeler. Le levier le plus efficace. Une part des demandes se traite sans modèle : une recherche exacte, une règle métier, une réponse en cache. Une question fréquente posée à l’identique n’a pas besoin d’être régénérée à chaque fois.

Envoyer moins. Réduire le contexte à ce qui sert réellement. C’est souvent spectaculaire, parce que le contexte s’accumule par prudence : on ajoute des informations « au cas où », et personne ne les retire.

Structurer pour le cache. Les fournisseurs facturent moins cher la partie stable d’un prompt quand elle est réutilisable. Cela impose de mettre l’invariant en tête et le variable en fin — pas la façon naturelle de rédiger, mais un gain récurrent.

Choisir un modèle moins cher pour les tâches simples. Toutes les étapes n’exigent pas le meilleur modèle. Classer une demande, détecter une langue, décider d’un aiguillage : un modèle plus petit suffit, et coûte une fraction. C’est le dernier levier que je mobilise, parce qu’il demande de réévaluer la qualité sur chaque étape déplacée.

Photo : Negative Space — licence CC0.

Le coût que personne ne chiffre : la mesure

Un poste absent de la plupart des propositions que je relis, y compris les nôtres au début.

Mesurer coûte. Conserver les échanges pour diagnostiquer, faire tourner un jeu d’évaluation régulièrement, appeler un second modèle comme juge : ce sont des appels facturés, sur un volume qui n’est pas celui des utilisateurs mais celui des tests.

Sur les projets où nous le chiffrons, ce poste représente une part faible mais non nulle du coût d’usage. L’oublier a un effet pervers : quand la facture serre, c’est la première chose qu’on coupe — et on se retrouve avec une fonctionnalité qu’on ne sait plus évaluer, juste au moment où l’on aurait besoin de savoir si elle dérive.

Photo : Martin Vorel — licence CC0.

Le coût de sortie, qu’on découvre trop tard

Une fonctionnalité qui s’appuie sur un modèle propriétaire crée une dépendance dont le prix n’apparaît nulle part au lancement.

Le fournisseur peut changer ses tarifs, retirer un modèle, modifier son comportement à version constante ou durcir ses conditions d’usage. Aucun de ces événements n’est théorique : ils se sont tous produits ces deux dernières années.

Ce que nous faisons pour rester libres de changer : isoler l’appel au modèle derrière une interface interne, conserver les invites dans le dépôt plutôt que dans une console tierce, et garder un jeu de cas de référence avec les réponses attendues. Ce jeu est ce qui permet de tester un modèle concurrent en une journée au lieu de repartir de zéro.

Ce n’est pas de la défiance : c’est ce qui rend la question du prix négociable.

Deux ordres de grandeur utiles

Sans donner de chiffres qui vieilliraient mal, deux rapports valent la peine d’être connus.

Le coût par appel varie d’un facteur dix à cent entre les modèles disponibles pour une même tâche. Choisir le plus capable par défaut, sans avoir vérifié qu’un plus modeste suffit, est la dépense la plus courante et la plus évitable.

Le contexte pèse plus que la réponse. Sur la plupart des usages métier, l’essentiel du coût vient de ce qu’on envoie au modèle, pas de ce qu’il produit. Envoyer un document entier quand trois paragraphes suffisent multiplie la facture sans améliorer le résultat — et allonge la réponse.

La question à poser à toute proposition

Une seule suffit à savoir si le sujet a été traité :

Combien coûte cette fonctionnalité au mois 1, et combien au mois 12 si elle est adoptée trois fois plus que prévu ?

Une proposition qui ne sait pas y répondre n’a pas chiffré la fonctionnalité — elle a chiffré son développement. Ce sont deux choses différentes, et c’est la seconde qui revient tous les mois.