Adam Mosseri, dirigeant d’Instagram au sein de Meta, estime que les entreprises devront bientôt piloter la consommation de tokens d’IA comme une dépense d’exploitation classique. Son scénario inclut des plafonds de consommation fixés à l’échelle de chaque ingénieur. L’enjeu porte sur la maîtrise des coûts, la traçabilité des usages et l’arbitrage entre productivité et budget.
À mesure que les assistants de code et les modèles génératifs s’installent dans les équipes techniques, la facture liée aux requêtes IA devient un poste visible. Dans les directions financières, la question n’est plus seulement quel outil?, mais quel volume, pour quel retour?
Adam Mosseri compare les tokens IA à une dépense d’exploitation
Dans l’écosystème des outils d’IA, l’unité de base de facturation est souvent le token, un fragment de texte utilisé en entrée et en sortie des modèles. Pour Adam Mosseri, cette mécanique pousse les entreprises vers une logique de gestion proche de celle appliquée à la masse salariale ou aux budgets cloud, avec des enveloppes, des contrôles et des règles d’allocation. La comparaison vise un point simple, la consommation d’IA n’est pas gratuite même quand elle est intégrée à un abonnement, car l’usage intensif fait rapidement varier les coûts réels.
Le raisonnement s’appuie sur l’évolution des pratiques. Les équipes d’ingénierie s’appuient sur des assistants pour générer du code, écrire des tests, résumer des tickets, produire de la documentation, analyser des logs. Chaque action multiplie les appels aux modèles, donc la dépense variable. Dans un contexte où les directions demandent de la prévisibilité, l’idée d’un budget de tokens par personne, par équipe ou par projet devient une réponse pragmatique.
Cette approche s’inscrit dans une tendance déjà connue dans le cloud. Les entreprises ont appris à limiter les coûts via des quotas, des alertes, des politiques de droits, des tableaux de bord. Mosseri projette une trajectoire similaire pour l’IA, avec des mécanismes de gouvernance plus explicites, car les usages se diffusent vite et peuvent être difficiles à attribuer sans instrumentation dédiée.
La question de la mesure est centrale. Sans suivi fin, il devient complexe de distinguer l’IA utilisée pour accélérer un cycle de développement d’une IA sollicitée pour des tâches à faible valeur. Les entreprises pourraient donc mettre en place des règles d’usage, des validations pour certaines requêtes coûteuses, ou des plafonds qui obligent à prioriser les demandes à fort impact.
Le point sensible reste l’équilibre entre contrôle et efficacité. Un plafond trop bas peut freiner l’expérimentation, donc la productivité. Un plafond trop élevé transforme la ligne IA en dépense difficile à défendre. Mosseri évoque un futur où cette tension sera arbitrée comme n’importe quel poste opérationnel, avec des objectifs, des budgets, et des choix assumés.
Des plafonds par ingénieur pour limiter la facture des outils génératifs
L’hypothèse d’un plafond par ingénieur revient à traiter la consommation de tokens comme un droit d’usage, comparable à une licence logicielle, mais indexé sur un volume. Dans un tel modèle, chaque profil disposerait d’une enveloppe mensuelle, par exemple liée au niveau de séniorité, au type de mission ou au produit. Les ingénieurs travaillant sur des refontes lourdes, de la migration ou de l’observabilité pourraient obtenir des budgets plus élevés que ceux mobilisés sur de petites évolutions.
Le mécanisme répond à une réalité économique, les modèles avancés coûtent plus cher à exécuter, et certaines requêtes, longues conversations, gros contextes de code, génération de suites de tests, font exploser la consommation. Les plafonds obligent à arbitrer entre un usage intensif et des alternatives, comme des modèles plus légers, des prompts plus courts, ou une préparation hors IA pour réduire les allers-retours.
Dans les entreprises, la mise en uvre peut passer par des outils internes de FinOps IA, avec des dashboards par équipe, des alertes de dépassement, et des règles de facturation interne. Les directions peuvent choisir un refacturation croisée, chaque équipe produit finance sa consommation, ou un budget central, mais soumis à des contrôles. Dans les deux cas, l’objectif est de rattacher la dépense à une responsabilité, donc à une décision.
Ce type de plafond a aussi un effet comportemental. Quand un volume est limité, les utilisateurs apprennent à optimiser, structurer leurs requêtes, éviter les discussions interminables, documenter les prompts efficaces, mutualiser des gabarits. À l’inverse, sans limites, les habitudes peuvent devenir coûteuses, par exemple demander à l’IA d’analyser de très longs dumps de logs ou d’ingérer des fichiers entiers sans tri préalable.
La limite n’est pas seulement financière. Elle touche au pilotage du risque, certains prompts peuvent exposer des données sensibles, certains usages peuvent créer une dépendance à un outil tiers. En encadrant l’accès, l’entreprise peut imposer des garde-fous, des environnements sécurisés, des modèles autorisés, et des règles de conformité. Le plafond de tokens devient alors un levier de gouvernance autant qu’un levier budgétaire.
Pourquoi la gouvernance des tokens rejoint les logiques FinOps et contrôle interne
Le parallèle avec FinOps, discipline de pilotage des coûts cloud, s’impose parce que la dépense IA partage plusieurs caractéristiques, une part variable, une complexité technique, et une difficulté d’attribution sans instrumentation. Les entreprises matures sur le cloud ont déjà des pratiques de tagging, de showback, de chargeback, et des revues mensuelles de consommation. Étendre ces pratiques aux tokens revient à créer une comptabilité d’usage pour l’IA.
Concrètement, cela suppose de connecter les outils IA aux systèmes internes, gestion des identités, traçabilité par projet, journalisation des requêtes, et catégorisation des cas d’usage. Une entreprise peut vouloir distinguer l’IA pour développement logiciel, l’IA pour support client, l’IA pour marketing, car les métriques de retour sur investissement ne sont pas les mêmes. Les contrôleurs de gestion cherchent des indicateurs simples, coût par ticket résolu, coût par story livrée, coût par incident analysé.
Le contrôle interne entre aussi en jeu. Si l’IA devient un outil de production, les décisions d’accès, de dépense et de conformité doivent être documentées. Les audits peuvent demander qui a eu accès à quel modèle, avec quel volume, sur quelles données. Dans certains secteurs, finance, santé, défense, la traçabilité est une contrainte structurelle. La gestion des tokens peut servir d’outil de preuve, en plus d’un outil de budget.
La gouvernance passe aussi par la standardisation. Les entreprises peuvent définir des profils d’usage, un pack de base pour les tâches courantes, un pack avancé pour la génération de code et la revue, un pack spécialisé pour l’analyse de données. Chaque pack correspond à un plafond, un modèle autorisé, et une politique de conservation des logs. Cette approche clarifie les responsabilités, tout en limitant la fragmentation des outils.
Reste la question de la performance. Certains modèles plus coûteux offrent une meilleure qualité, donc un gain de temps. Un pilotage trop strict peut pousser les équipes vers des modèles moins performants et augmenter le temps humain, ce qui revient à déplacer le coût. Les directions devront comparer le coût des tokens et le coût du temps ingénieur, en tenant compte des délais projet et de la qualité logicielle.
Les effets attendus sur la productivité, les prompts et les choix d’outils
Si des plafonds deviennent la norme, les pratiques quotidiennes vont évoluer. Les ingénieurs risquent de privilégier des requêtes plus structurées, avec un contexte réduit, des objectifs clairs, et des tests de validation. Les équipes peuvent formaliser des bibliothèques de prompts, des checklists de revue, et des modèles de conversation, pour éviter de brûler des tokens sur des itérations inutiles. Cette standardisation peut améliorer la qualité, mais elle peut aussi réduire la spontanéité de l’exploration.
Le choix des outils sera directement influencé. Dans un environnement plafonné, les solutions qui offrent une bonne efficacité par token, ou des modèles locaux, peuvent gagner du terrain. Les entreprises pourraient arbitrer entre des modèles propriétaires très performants et des alternatives open source déployées en interne, avec un coût d’infrastructure différent mais une meilleure maîtrise. Le calcul dépendra du volume, du besoin de confidentialité et des compétences internes.
Les plafonds peuvent aussi modifier la relation entre ingénierie et produit. Si l’IA est facturée par projet, les chefs de produit devront justifier certains usages, par exemple génération de prototypes, automatisation de tests, analyse de retours utilisateurs. L’IA devient une ressource à planifier, pas seulement un outil individuel. Cette logique peut favoriser les cas d’usage les plus mesurables, au détriment d’expérimentations plus difficiles à quantifier.
Dans les équipes, une autre conséquence est la montée en compétences sur le prompt engineering au sens large, savoir cadrer un problème, fournir un contexte pertinent, vérifier la sortie, et réduire les itérations. Les entreprises peuvent créer des formations internes et des guides, non pas pour faire du marketing, mais pour réduire le coût par résultat obtenu. Les managers peuvent suivre des indicateurs, nombre moyen d’appels par tâche, taux de réutilisation de prompts, part de requêtes longues.
Enfin, la perspective évoquée par Mosseri s’inscrit dans un mouvement plus large, la transformation de l’IA en poste budgétaire gouverné comme les autres. Quand les plafonds existeront, ils deviendront un signal de priorité. Les équipes jugées stratégiques recevront plus de capacité, les autres devront optimiser ou justifier, ce qui ancrera l’IA dans des arbitrages classiques de gestion, avec des effets directs sur la cadence de livraison et la manière de construire les produits.
