Page **About** du site **tokeneconomics.com**, présentant la **Tokenomics Foundation** — un projet de la **Linux Foundation** annoncé le **3 juin 2026**, opéré en **partenariat étroit avec la FinOps Foundation**. **Mission déclarée** : *« establish open industry standards, benchmarks, and best practices for the economics of AI infrastructure »* — relier **production, consommation et monétisation** des tokens à la **valeur métier**. **Définition-cadre du tokenomics** : *« Tokenomics is not just about the cost of tokens, it's about the entire layer of AI that they drive from production, to consumption to monetization »* — c'est-à-dire **toute la couche économique de l'IA**, du coût d'infrastructure à la sélection de modèle jusqu'à l'optimisation de la valeur. **Thèse de phase** : l'adoption précoce de l'IA a priorisé la **capacité** ; la phase actuelle bascule vers **efficience et valeur**, ce qui exige une gestion systématique des coûts et de la **visibilité**. **5 principes fondateurs** : (1) ***« Efficiency is a design choice. AI cost is shaped by architecture, not just usage »*** ; (2) ***« Bigger is not always better. The best AI system is not always the one using the most expensive model »*** (right-tool / routage) ; (3) ***« Visibility comes before optimisation. Teams cannot manage what they cannot see »*** ; (4) ***« Value matters more than volume. More tokens, more calls, and more automation do not automatically mean better outcomes »*** ; (5) ***« Open knowledge benefits everyone »*** (standards partagés, apprentissage communautaire, transparence). **Gouvernance** : un **Governing Board** (direction industrielle + déploiement des fonds) et un **Technical Committee** (spécifications ouvertes + benchmarks). **Livrables** : extension de la **spécification FOCUS** (FinOps), specs ouvertes, benchmarks, frameworks et métriques partagées. **Public cible** : CAIO, CTO, CIO, CFO, ingénieurs, équipes produit, praticiens FinOps, chercheurs, startups, entreprises, secteur public. **But affiché** : faire passer les organisations *« from experimental AI adoption to sustainable AI operations »* en étendant la discipline du **variable technology spend** à l'ère du token. **Importance pour la veille** : institutionnalisation/standardisation du **FinOps agentique** au niveau d'une fondation industrielle — converge frontalement avec les fiches [[finops-foundation-finops-for-ai-overview-2026-02-17]], [[finout-finops-ai-agents-four-step-allocation-framework-2026-04-27]], [[orq-ai-finops-ai-agents-cost-per-outcome-hosseini-2026-04-15]], [[gupta-token-budget-wars-marginal-token-utility-2026-05-28]] (allocation layer, token-to-outcome) et avec la bascule **token → outcome** (Salesforce/Tallapragada, Sierra/Greenwald). Les 5 principes recoupent exactement les leviers déjà capitalisés : architecture > usage, **routage Haiku/Sonnet/Opus**, observabilité avant optimisation, valeur ≠ volume.
#Tokenomics Foundation#tokenomics#token economics
**Tokenomics Foundation** (entité collective, projet de **The Linux Foundation**, en partenariat avec la **FinOps Foundation**). Page institutionnelle *About* — **aucun auteur individuel nommé**. Annonce datée du **3 juin 2026**.
Billet du **Dropbox Tech blog** (rubrique *culture*), publié le **28 mai 2026** par **Kazuaki Okumura** (Dropbox, rôle non précisé dans l'article), reprenant une intervention à la conférence **DX Annual 2026** (productivité développeur). **Thèse-pivot** : la productivité d'ingénierie doit dépasser la *génération de code*. *« Accelerating code generation simply shifted some bottlenecks downstream »* — l'IA a massivement augmenté le débit de code, mais *« the faster code moves, the more pressure it puts on review queues, CI systems, validation workflows, release coordination, and production operations »*. Le vrai enjeu n'est plus d'écrire du code plus vite, mais de permettre à tout le SDLC d'**absorber, valider et livrer en sécurité** un volume bien plus grand. **De copilote à agent** : la première vague (explication de code, snippets, Q&A) opérait *« as copilots alongside the engineer »* ; l'agent, lui, *« can take a scoped task, inspect the codebase, edit files, run tests, iterate on failures, and return an artifact for human review »* — l'ingénieur restant *« accountable for intent, architecture, quality, and release decisions »* (plus de travail parallèle, plus d'options, délestage de l'exécution répétitive). **Nova** = plateforme d'agents de codage **interne** de Dropbox : décrire une tâche en langage naturel, exécution en environnement contrôlé avec le contexte du codebase. Datapoint canonique : ***« Nova's value comes less from the model itself than the systems surrounding it »*** (codebase context, internal practices, safe execution, workflow integration, human review) ; Nova représente **~1 PR sur 12 chez Dropbox** aujourd'hui (adoption en croissance), et s'étend au-delà des features : **migrations, remédiation de tests flaky, investigation de bugs, mises à jour de dépendances** (travail à forte pénibilité). **Mesurer la vélocité produit, pas l'output de code** : le *PR throughput*, signal utile quand la vélocité de codage était la contrainte, *« was no longer sufficient »*. Modèle de mesure en **4 étages** : ***Fuel*** (les outils IA sont-ils sollicités ?) → ***Adoption*** (comment les workflows changent à travers les équipes) → ***Output*** (l'IA contribue-t-elle au travail de production ?) → ***Impact*** (*« improving product velocity and reducing the time it takes to move from idea to customer value »*). Signaux qualité suivis : **code review turnaround time, first-run test pass rate, defect ratio, rework rate**. *« Quality and trust matter as much as speed »* — le cœur de la bascule : *« moving from local activity metrics toward broader system outcomes »*. **Les workflows doivent évoluer** : ce n'est *« not just a tooling shift »* mais un changement d'**operating model** — le rôle de l'ingénieur glisse vers *« defining intent, mapping problems, reviewing generated changes, and making higher-context architectural and quality decisions »*. L'**enablement** est aussi crucial que l'outil (hands-on learning, hackathons, workflow spotlights, bootcamps, peer-led examples) ; adoption à vitesses variables selon les équipes ; *« The goal is not to force every workflow through an agent »* — le rendre *« useful, safe, measurable, and repeatable where it creates meaningful leverage »*. **Ce qu'on a appris** : ***« AI doesn't eliminate bottlenecks in software development, but it does move them »*** (downstream : review, validation, testing, release, prod ops) → optimiser l'ancien goulot ne crée plus le même levier. *« The advantage will not come from access to the same foundation models everyone else can use. It will come from the systems built around those models : context, internal tooling, quality controls, and the workflows that connect them together. »* Pression aussi **en amont** (product & design) : specs structurées, design clarity, problem framing plus aiguisé. Clôture : ***« The future of engineering productivity will not be defined solely by who has the best models. It will be defined by who builds the best systems around them »*** ; *« The real challenge is no longer just generating more code, but building engineering systems that can reliably turn AI-assisted output into valuable experiences for our customers »*. Convergence directe avec **Salesforce/Tallapragada** (Effective Output : mesurer la valeur, pas le volume ; pas de tradeoff vitesse/qualité), **Gupta** (token-to-outcome attribution, cost of a completed outcome), **DORA** (au-delà du débit) et le déplacement du KPI vers le **system outcome** (idea→customer value).
#productivité d'ingénierie#engineering productivity#beyond code generation
**Kazuaki Okumura** — Dropbox (rôle non précisé dans l'article ; le billet reprend une intervention présentée à la conférence **DX Annual 2026** sur la productivité développeur, ce qui suggère un profil engineering leadership / platform, sans confirmation). Publié sur le **Dropbox Tech blog** (dropbox.tech) · rubrique *culture* · le **28 mai 2026**.
Thread X viral (**230,5K vues**, 28 mai 2026, 1h51) de **Jaya Gupta** (@JayaGup10, investisseuse — vraisemblablement Foundation Capital, auteure du cadre *Context Graphs*) intitulé ***« Token Budget Wars »***. **Thèse-pivot** : ***« Enterprise AI has moved from adoption to allocation »*** — la phase 1 de l'IA d'entreprise a prouvé que les modèles savent travailler ; la phase 2 décidera **combien de ce travail vaut la peine**. La nouvelle monnaie au sommet de l'entreprise est la **capacité à quantifier le ROI de l'IA** : *« show me the value »*. Concept canonique : ***marginal token utility*** = *« the business value created by each additional dollar of inference »* — le nombre qui compte à l'échelle, et que **la plupart des entreprises ne peuvent pas voir**. Chronologie : **Claude shippé novembre 2025**, après le lock des budgets annuels 2026 → dès le **Q1**, entreprises *« running multiples ahead of plan »* → l'inférence cesse d'être une ligne d'expérimentation pour devenir un **coût opérationnel récurrent**. Bascule **expérimentation (quelques 100K$) → infrastructure (7 chiffres, 1M$+)** : à l'échelle infra, **la variance technique produit des swings de P&L matériels — deux exécutions du même workflow sur le même input peuvent différer de 5-10× en coût de tokens** sans rien de visiblement cassé, *« a number the CFO has to explain to the CEO »*. **L'IA concurrence le travail** : 3 types de demandes budgétaires (remplacer du travail externalisé / interne / générer du revenu) → glissement vers le ***cost of a completed outcome*** (cost per resolved ticket, processed claim, reviewed contract, completed invoice, avoided hire, retained customer, dollar of revenue moved). **BPO = baseline le plus facile à benchmarker** (déjà tarifé en unités complétées) ; travail interne bien plus dur (employés polyvalents, gains diffus, résistance RH à réduire les effectifs). **Pourquoi c'est différent du SaaS** : le SaaS a appris à traiter l'usage comme proxy de valeur ; l'IA casse ce proxy — *« the signal and the noise share the same unit »* (le token), *« SaaS usage told you the software had been adopted. AI usage tells you the meter is running. It doesn't tell you whether your company is cooking »*. **Trois causes de l'invisibilité de la marginal token utility** : (1) ***retry tails*** — tokens par workflow résolu ≈ **T/p** ; passer de 90% à 70% de complétion augmente le coût effectif de ~**28%**, pas 20%, car les échecs composent ; (2) ***context inflation*** — coût d'inférence ≈ **O(n²)** en longueur de contexte (attention), doubler le contexte **quadruple** le coût de raisonnement (sur-récupération : 50 docs quand 5 suffisent) ; (3) ***routing*** — par défaut on prend le modèle le plus puissant (classification basique sur modèle de raisonnement complexe) ; sur des millions d'appels, la différence entre router les tâches faciles vers un petit modèle et tout envoyer au frontier = *« the difference between a manageable bill and a board-level problem »*. **Bifurcation sectorielle** : entreprises **software** = problème de **mesure de productivité** (déjà instrumenté : PRs, commits, deploys, incidents, cycle time, MTTR — tracke les *« AI layoffs »*) ; entreprises **non-software** = problème de **transformation** (travail opérationnel : claims, underwriting, support, compliance reviews, supply chain exceptions, payment disputes — *right under audit, not just right on average*). **La couche manquante = token-to-outcome attribution** : une couche de conversion reliant dépense d'inférence → travail effectué → outcome business, qui répond à 3 questions (coût réel incluant retries/corrections ; quelles parties du trace ont compté vs thrashing ; le travail a-t-il changé l'operating model). ***Measurement becomes memory*** : pour relier un token à un outcome il faut capturer les **decision traces** (ce que l'agent a vu, récupéré, appelé, ignoré, où il a retried, quand un humain a overridé) — *« decision rationale is one of the most perishable assets in a company »* (vit dans Slack, emails, escalation calls, têtes des gens). Les agents **créent** ces traces ; capturées d'abord pour justifier la dépense, elles deviennent *« more valuable than the cost report »* → un **context graph** (*« although I am so tired of that word these days »*). **The allocation layer is the prize** : qui possède le token-to-outcome attribution fait les **allocation calls** (quels workflows méritent plus de compute, lesquels cappés, lesquels en modèles cheaper, lesquels restent humains, lesquels remplacent le BPO). Les entreprises ne le feront pas seules — elles l'**achèteront comme une transformation** (playbook Fortune 500 : McKinsey + alumni Palantir + top-down CEO, à la manière ERP/BI/digital transformation, un *« program »* avec sponsor exécutif et une infra qui devient la **nouvelle source de vérité**). Cadre par **Charlie Munger** : *« show me the incentive and I will show you the outcome »*. Sous-thèse organisationnelle : instinct exécutif trentenaire *big teams = big jobs/scope/power* → quand l'intelligence devient la **ressource rare**, le nouveau marqueur est *« how much of it you're orchestrating »*. Pertinence directe pour le **positionnement Optimisation des coûts / FinOps agentique** : confirme empiriquement les leviers (routage modèles, prompt caching, hygiène contexte, sub-agents) et déplace le KPI vers le **coût par outcome complété**. Convergence forte avec Bain *cross-system labor* (execution data moat, Cursor), Ng *No AI jobpocalypse* (pricing ancré sur le salaire de l'employé remplacé), DORA ROI (coût par feature), Mensch/Mistral (electron→token), Ensarguet (économie de la computation), Foundation Capital *Context Graphs* (decision traces, même autrice), Wescale *Token Burning*, BFM/Girard (token = fuel de valeur).
#Token Budget Wars#marginal token utility#token-to-outcome attribution
**Jaya Gupta** (@JayaGup10) — investisseuse / VC. Très probablement **Foundation Capital** (le thread s'auto-réfère au cadre ***Context Graphs*** — *« ahem, context graph, although I am so tired of that word these days »* — concept porté par Foundation Capital, cf. fiche `bain-100b-saas-opportunity` qui cite *Foundation Capital — Context Graphs trillion-dollar opportunity, 2025-12-22*). Thread publié sur X le **28 mai 2026 à 1h51** · **230 · 5K vues** · format essai long en un seul post. Une réponse notable de **@tuning_engines** (*« DevSecFinOps for the Agentic Era »*) : *« Tokens will basically have to be managed like headcount […] model hierarchies too »*.
Billet de blog officiel **Salesforce News** (rubrique *Agentic Enterprise*, série *« Pioneering the Agentic Shift Within Salesforce Engineering »*), publié le **27 mai 2026** (6 min de lecture) par **Srinivas « Srini » Tallapragada**, *President and Chief Engineering and Customer Success Officer* de Salesforce. Suite directe d'un premier billet (*« How we got our engineers to use AI — without breaking everything »*) qui racontait le passage de **>90% d'adoption**. **Thèse-pivot** : Salesforce Engineering est passé d'un monde où l'IA était un *copilote* utile à un monde où des **outils agentiques pilotent le cycle de vie logiciel (SDLC) lui-même** — écriture de code, revue de PRs, génération de tests, mise à jour de doc, gestion des déploiements, coordination du travail jadis confié à des handoffs humains. **Décision-signal canonique** : standardisation org-wide sur **Claude Code** + ***« we removed all token limits »*** — *« remove every last piece of friction between our engineers and the tools that make them faster and more effective »*. **Résultat empirique majeur** (avril 2026 vs avril 2025) : work items complétés par développeur **+50,8%**, PRs mergées par développeur **+79%**, et surtout **Effective Output score** (mesure ML de la **valeur réelle du code livré**, pas le volume) **+151,3% en glissement annuel**. **Cas d'usage emblématique** : migration de **33 endpoints API** vers une architecture cloud-native, estimée **~231 person-days** (7 par API) en traditionnel, réalisée en **13 jours = 18× plus vite** — via un **framework rule-based en Claude** (fichiers markdown + reference implementations), feedback des PRs réinjecté en continu dans le rule set, **boucles LLM autonomes (build, fix, validate)** sans intervention manuelle, parallélisées sur environnements isolés → **5 PRs**, la plus grosse livrant **21 endpoints avec 100% de couverture de tests**. **Pas de tradeoff vitesse↔qualité** : via la plateforme **Engineering 360** (centralise les données d'ingénierie de centaines de systèmes), **les incidents totaux baissent de 5%** malgré la hausse des PRs (*« quality doesn't suffer from speed. It benefits from it »*), grâce à des **guardrails de sécurité et standards qualité encastrés structurellement** dans le workflow agentique (Trust = valeur n°1). **Refonte du SDLC** : une fois l'IA adoptée, les ingénieurs **détruisent et reconstruisent** les workflows (quels process supprimer ? quels handoffs inutiles ? où l'humain fait-il encore un travail qu'un agent peut posséder ?). **Nouveau craft d'ingénierie** : les **Claude Code skills** (capacités packagées/réutilisables encodant contexte d'équipe, conventions de nommage, patterns) deviennent un **artefact d'ingénierie** partagé et composable ; **AI Expert Suite** + **Salesforce Foundation Plugins** = bibliothèque curatée institutionnalisée de skills (benchmark interne : **précision et fiabilité en hausse, coût inutile réduit**) ; **subagents & agent teams** parallélisent les workstreams (*« They describe the outcome, and a set of coordinated agents figures out the steps »*). **Ce qui reste dur** : (1) **gestion du contexte** en sessions longues — la **qualité des fichiers CLAUDE.md** varie beaucoup et pèse fort sur la qualité de sortie ; (2) **sécurité agentique** = modèle fondamentalement différent (agents qui *agissent*, pas seulement *suggèrent* → blast radius accru) ; (3) **évolution des rôles** (comment les juniors deviennent seniors si l'IA absorbe le travail entry-level ? rôle du designer/PM ? l'unité d'exécution = scrum team → expérimentations d'unités à 1 ou 3 personnes). Conclusion : *« It changed what was economically possible »* ; ambition affichée = **« the most automated, agentic SDLC in the industry »**. Recoupe directement Gupta (*cost of a completed outcome*, marginal token utility), Greenwald/Sierra (outcome-based pricing), DORA (ROI / coût par feature) et le débat BFM/Girard (token = fuel de valeur, pas coût à couper).
#SDLC agentique#agentic SDLC#Claude Code
**Srinivas « Srini » Tallapragada** — *President and Chief Engineering and Customer Success Officer* de **Salesforce**. Plus d'une décennie chez Salesforce · dirige l'ingénierie mondiale de la plateforme unifiée. Auteur de la série *Agentic Enterprise* sur le blog Salesforce News ; ce billet (27 mai 2026) est la **suite** d'un premier opus consacré à l'adoption de l'IA par les milliers d'ingénieurs Salesforce (*« How we got our engineers to use AI — without breaking everything »*). Position d'autorité = **dirigeant exécutif** parlant en son nom et au nom d'une organisation d'ingénierie à grande échelle (donnée terrain à l'échelle d'un hyperscaler SaaS) · avec accès aux métriques internes (Engineering 360, Effective Output).
FinOps pour agents IA : framework d'allocation en 4 étapes pour les coûts des coding assistants (Claude Code, Cursor, Copilot) et pourquoi le tagging cloud traditionnel échoue - Finout
#FinOps agentique#allocation des coûts#coding assistants
Finout (équipe, sans auteur nommé)
FinOps pour agents IA centré sur le « cost per outcome » : pourquoi le FinOps traditionnel échoue face au comportement runtime, guardrails, observabilité comportementale et cycle de vie en 4 phases - Orq.ai
#FinOps agentique#cost per outcome#comportement runtime
Sohrab Hosseini (co-fondateur, Orq.ai)