Aller au contenu

Toutes les fiches — Page 20

Économie & Marché

Outcome-based pricing for AI Agents

Billet de blog **Sierra** (10 décembre 2024, **Elliot Greenwald**) qui pose le **texte fondateur de l'*outcome-based pricing*** pour agents IA. **Thèse-pivot** : les agents IA qui exécutent des processus de façon autonome rendent possible un **modèle de tarification entièrement nouveau** — ***« you pay only when the software achieves specific, valuable outcomes: outcome-based pricing »***. L'article retrace une **généalogie de la tarification logicielle en quatre âges** : (1) **shrink-wrapped software** (années 1980-90, boîte de disquettes/CD-ROM chez Fry's Electronics — *« Whether you actually used it or not, you paid for it »*) → (2) **SaaS / seat-based** (pionnier **Salesforce**, suivi de Google/Microsoft/Adobe — Internet permet de vendre le logiciel *as a service*) → (3) **consumption-based** (**Amazon/AWS** et **Snowflake** — *« charged only for what you used »*) → (4) **outcome-based** (agents IA). **Définition canonique** : ***« outcome-based pricing is tied to tangible business impacts—such as a resolved support conversation, a saved cancellation, an upsell, a cross-sell, or any number of valuable outcomes. If the conversation is unresolved, in most cases, there's no charge »***. **Principe d'alignement des incitations** : ***« With outcome-based pricing, Sierra gets paid only when we complete a task for you. Our incentives are aligned »***. **Critique du seat-based & concept de *shelfware*** : *« Unused seats sit idly on a proverbial store shelf, hence the derisive moniker "shelfware" »* — on paie des milliers de dollars/an par licence, utilisée ou non. **Conflit structurel des fournisseurs CX legacy** : leur revenu dépend du seat-based, or *« the more effective their AI becomes, the fewer contact center seats their clients need—undermining the provider's own revenue model »* — un agent IA efficace **cannibalise** le modèle de revenu de l'éditeur dont la tarification repose sur les sièges. **Granularité de l'outcome** : distinction entre **résolutions simples** (répondre à une question) et **résolutions complexes** (gérer un cas nécessitant un appel L2 de 20 minutes) ; **les escalades n'entraînent en général aucune facturation** ; **tarification mixte (*blended*)** possible (ex. consumption-based pour les interactions de routage/accueil). **Engagement d'optimisation continue** côté fournisseur : *« we continue to deploy concerted, directed optimizations to refine the agent's performance over time »* — l'éditeur est aligné pour améliorer la performance puisqu'il n'est payé qu'au résultat. Importance : posé **fin 2024**, ce billet **précède et fonde** tout le débat 2026 sur l'économie agentique — il fournit le **vocabulaire de l'unité de facturation** (l'*outcome* complété plutôt que le siège, l'usage ou le token) que reprendront Gupta (*cost of a completed outcome*, *token-to-outcome attribution*), Bain (*outcome-based pricing déplace le revenue de fixed seats vers labor/operations economics*), Ng (*pricing power ancré sur le salaire de l'employé remplacé*). Sierra étant l'**exemple-référence** cité par Bain (*autonomous customer issue resolution*), ce texte donne la **vue côté fournisseur** de la mécanique que les autres analysent côté acheteur. Pertinence directe pour le positionnement **tarification de la delivery agentique / value-based** du cabinet et pour le slot **Optimisation des coûts** (le pendant *vendor* du *cost per outcome*).

#outcome-based pricing#tarification au résultat#AI agents

**Elliot Greenwald** — Sierra (entreprise fondée par Bret Taylor & Clay Bavor, plateforme d'agents IA conversationnels pour l'expérience client). Billet publié sur le blog Sierra le **10 décembre 2024**. Sierra est l'**exemple-référence** cité par Bain (*The $100-Billion SaaS Opportunity*) pour l'*autonomous customer issue resolution* · et fait l'objet de plusieurs fiches du dossier (recrutement AI-native, interview Plan/Build/Review).

Transformation & Adoption

Confronting Impossible Futures

Planification stratégique face aux futurs impossibles de l'IA et de l'AGI - One Useful Thing - Ethan Mollick

#AGI#Intelligence Artificielle Générale#planification stratégique

Ethan Mollick · Professeur à la Wharton School · University of Pennsylvania

Transformation & Adoption

Accelerating the development of life-saving treatments — Moderna case study

Étude de cas officielle OpenAI sur le déploiement de ChatGPT Enterprise chez Moderna : 750 GPTs en 2 mois, 100% d'adoption juridique, GPT Dose ID pour les essais cliniques, citation de Stéphane Bancel "100 000 employés", framework de transformation organisationnelle (mChat, Generative AI Champions, forum interne 2 000 participants).

#Moderna#OpenAI#ChatGPT Enterprise

OpenAI (étude de cas officielle, citations Stéphane Bancel, Brad Miller, Brice Challamel, Shannon Klinger, Kate Cronin, Meklit Workneh)

Transformation & Adoption

L'IA générative est plus une affaire de produit technologique qu'un projet d'IA

Tribune d'**Olivier Rafal** (Consulting Director Strategy chez **WeNvision**) publiée le **23 février 2024** sur **CIO-Online** (rubrique *Tribune*), qui pose une thèse encore contre-intuitive à l'époque : **l'IA générative relève davantage du produit technologique que du projet d'IA / data science**. **Argument 1 — la data science n'est pas le cœur du sujet** : créer un *foundation model* de toute pièce demande *« plusieurs mois, des millions d'euros et l'accès à d'énormes quantités de données »* — réservé à des acteurs aux datasets spécifiques et monétisables (ex. **Bloomberg** et son **BloombergGPT** pour la finance). Pour la quasi-totalité des entreprises, le bon réflexe n'est donc pas de recruter des data scientists. **Argument 2 — décalage de compétences** : il faut surtout des **ingénieurs de développement et d'intégration** (back/front), de **fortes compétences cloud** et du **DevOps**. Citation client : *« On n'a pas forcément besoin d'être data scientist, mais il faut comprendre les concepts de base, avoir des compétences de développement back office et de fortes compétences cloud. »* **Argument 3 — architecture de plateforme (orchestrateurs + API)** : construire une **plateforme d'IA générative** d'entreprise via orchestrateurs et API permet *« de travailler avec les meilleurs LLM du marché et d'en changer au fur et à mesure de leurs évolutions respectives, sans retoucher aux applications »* (anti vendor lock-in). **Argument 4 — du projet au produit** : *« La plate-forme […] il faut la considérer elle-même comme un produit »* ; au lieu d'un investissement ponctuel, prévoir un **flux de financement mensuel** (itérations continues, innovation permanente). **Argument 5 — gouvernance & shadow AI** : la démocratisation inédite de la GenAI engendre *« tant du shadow AI que de fortes attentes vis-à-vis de la DSI »* → gouvernance pour capter les besoins métiers, **prioriser les produits par la valeur**, superviser le bon fonctionnement. **Changement de paradigme** annoncé : *« on passe d'une programmation algorithmique classique à des agents Langchain qui gèrent une partie des décisions »*. **Intérêt pour la veille** : texte **fondateur (J-2 ans)** de la doctrine WeNvision (produit > projet, plateforme/API, financement en flux, gouvernance, shadow AI) que prolongeront les fiches [[wenvision-ai-agents-enterprise-deployment-2025-10-01]], [[habert-ia-agentique-production-2025-10-29]] et rafal-wenvision-tokenomics-foundation-finops-ia-2026-06-04 (FinOps/token, financement en flux → gouvernance financière). Préfigure aussi le *harness/plateforme autour du modèle* (Dropbox/Okumura : *systems around the model*) et l'**indépendance modèle** par couche d'orchestration.

#IA générative#produit technologique#produit vs projet

**Olivier Rafal** · *Consulting Director Strategy* chez **WeNvision** (cabinet de conseil FR). Tribune publiée dans la rubrique *Tribune* de **CIO-Online**. Auteur déjà présent dans la veille (cf. fiches WeNvision/Atlas/Tokenomics). Publié le **23 février 2024**.

Qualité & Sécurité

TDD is dead. Long live testing. (Une contre-argumentation point à point à l'article phare de David Heinemeier Hansson, détracteur du Test-driven development)

**Mathieu Eveillard** publie sur son blog personnel le **7 décembre 2022** (dernière mise à jour 17 mars 2025) une **contre-argumentation point à point** au célèbre essai de **David Heinemeier Hansson (DHH)** *"TDD is dead. Long live testing."* (RailsConf 2014). Article catégorisé **craft / best-of**, position d'**artisan logiciel** qui défend le **Test-Driven Development** sans dogmatisme. **Distinction-pivot** que DHH manque selon Eveillard : ***"Test-first"*** (écrire tous les tests avant le moindre code) vs ***"Test-Driven Development"*** (les tests me **guident** dans l'écriture du code, donc j'écris à chaque fois un peu de code *"en réaction"* à un nouveau test). DHH critique le *Test-first* en l'appelant TDD — confusion qui **cache une tout autre façon de programmer**. **Réponses point à point** : (1) *"TDD as hammer to beat down the nonbelievers"* — Eveillard concède le point déontologique mais redéfinit *"bon code"* : pas seulement absence de bugs mais **tests unitaires fins** documentant le comportement au plus bas niveau, co-localisés avec le code, **filet de sécurité** ; (2) *"Rebalance from unit to system"* — TDD **ne dit rien** des tests système et **ne dit pas** qu'il n'y a rien en dehors du TDD ; tests système ne **remplacent pas** unitaires (impôt sur le revenu en e2e n'a aucun sens) ; **pyramide de tests** — chaque type apporte sa pierre, unitaires pour feedback **millisecondes** + détection bug précoce ; (3) *"Horrendous monstrosities of architecture (service objects, command patterns)"* — Eveillard répond qu'il **ne connaît pas ces effets en programmation fonctionnelle**, donc l'effet est probablement dû à la **POO**, pas au TDD ; mais concède que trop d'injection de dépendances peut coupler test et implémentation. **Conclusion équilibrée** : *"Le TDD n'est pas une religion, c'est un outil"*. Le TDD se prête particulièrement bien au **code du domaine** (noyau fonctionnel d'un *bounded context*, *cœur de l'hexagone*) — moteur de calcul, règles de gestion fines, cas limites — ***"30% au plus de la codebase"***. Mention de la **Loi de l'Instrument** (si l'outil n'aide pas, c'est qu'on tombe dedans). **Pertinence dossier** : article **craft hors-corpus IA** mais à archiver pour positionner les débats actuels sur les coding agents (Beck *Augmented Coding Beyond Vibes* 2025-06-25, Vibe Coding vs TDD, Frizzo *writing muscle atrophy*) dans la lignée historique des débats craft autour du TDD. À mobiliser comme **fond de bibliothèque** pour formations.

#Mathieu Eveillard#TDD#Test-driven development

**Mathieu Eveillard** — développeur / coach craft / formateur (blog personnel mathieueveillard.com, services *Accompagnement* et *Office hours*). Identité publique : *artisan logiciel* avec une pratique pédagogique autour du TDD · du DDD et du craft. Newsletter hebdomadaire (*"Chaque mercredi, une idée pour démarrer la journée"*).

Architecture & Construction

The Magic of Platforms

Keynote **Gregor Hohpe** (Enterprise Strategist AWS, auteur *The Software Architect Elevator* et du livre en cours *Platform Strategy: Accelerating Innovation Through Harmonization and Reuse*) à **PlatformCon 2022** sur **la magie des plateformes** — pourquoi les plateformes réussissent, ce qui les distingue d'une simple *IT Service Management*, et **les décisions d'architecture non-triviales** à prendre quand on en construit une. **Thèse-pivot** : *« les standards ne réduisent pas la créativité, ils peuvent la décupler »* — analogue Baltimore 1904 (incendie, pompes incompatibles), vis métrique ISO, HTTP, papier A4. **Citation canonique reprise de Peter / Thoughtworks** : ***« platforms centralize expertise but not innovation »*** — on ne réinvente pas la roue, mais on laisse l'innovation aux équipes proches du client. **Analogie pivot** : industrie automobile (Volkswagen Group construit Audi A4 et Bentley Bentayga sur la même plateforme), *« undifferentiated heavy lifting »* (vocabulaire AWS) sous le capot, différenciation visible côté client. **Trois propriétés d'une vraie plateforme** : (1) **low friction** — on ne peut pas forcer l'adoption, les équipes contourneront ; (2) **transparence** (pas une *black box*) — les utilisateurs doivent pouvoir diagnostiquer s'ils sont en cause ou si c'est la plateforme ; (3) **shared responsibility** (référence directe au *AWS Shared Responsibility Model*) — la plateforme ne corrige pas une appli mal conçue. **Anti-pattern explicite** : *« a common layer can be many things — it is not necessarily a platform »* ; l'IT Service Management traditionnelle a la même image (couche commune sous tout le monde) mais l'**interface est l'opposée** (high-friction, formulaires, bottleneck). **Deux voies de construction** : (a) anticiper tous les besoins (Hohpe : *« I don't feel I'm smart enough »*) ; (b) **évolution** à partir de pièces utiles, en observant l'usage. **Décisions à expliciter** : objectifs (cognitive load ↓, safer / fewer mistakes, faster via samples/blueprints/self-service, compliance), forme de la courbe d'apprentissage (cliff, hockey stick, gear shift). **Concept canonique #1 — Floating platforms vs Sinking platforms** : quand la *base platform* (typiquement le cloud) gagne de nouvelles capacités, **deux stratégies opposées** : **sinking platform** (statique, dupliquant ce que la base offre maintenant, coulant à mesure que le niveau monte) vs ***floating platform*** (jette les morceaux devenus redondants, **re-monte au-dessus du nouveau niveau**, innove plus haut). Métaphore *« submarine and a boat »*. Implication contractuelle forte : **prévenir explicitement les stakeholders** que des composants seront supprimés quand la base les absorbe. **Concept canonique #2 — Fruit salad vs Fruit basket** : une plateforme n'est pas une collection de capacités juxtaposées (panier) mais un assemblage **proportionné et bite-sized** où les pièces interagissent — *« the per-kilo price for fruit salad is higher than for a fruit basket »*. Le titre dérive de l'expression *the magic of platforms* — l'effet contre-intuitif où **standardiser libère l'innovation au lieu de l'étouffer**, à condition de soigner l'interface, l'évolution et l'intégration entre les composants. À mobiliser pour : architectes plateforme, **Platform Engineering / IDP teams 2026** (référence fondatrice, prédate l'explosion *Internal Developer Platforms* mais structure le vocabulaire), DSI évaluant build-vs-stagnate face aux capacités natives cloud, COMEX produit. Convergence avec **AI/works™ Thoughtworks** (2026-05-12), **L'Usine Logicielle Augmentée Wescale** (2026-05-03), **PROJ-AI Habert/WEnvision** (2026-05-05), **DORA AI ROI** (2026-04-21 — Platform comme pilier systémique).

#Plateformes logicielles#platform engineering#Internal Developer Platforms IDP

**Gregor Hohpe** — Enterprise Strategist chez Amazon Web Services · architecte logiciel · auteur prolifique (*Enterprise Integration Patterns* — référence depuis ~2003 — et *The Software Architect Elevator*, O'Reilly 2020). Au moment du talk · écrit *Platform Strategy: Accelerating Innovation Through Harmonization and Reuse* (publié sur Leanpub, accessible via *leanpub.com/platformstrategy*). Profil : architecte *bridging the gap between business and tech* · expérience CTO Allianz · conseil C-suite · conférencier régulier (QCon, GOTO, PlatformCon). Référence majeure dans l'architecture d'entreprise et l'intégration. Talk donné en **keynote PlatformCon 2022** (juin 2022, conférence en ligne organisée par platformengineering.org).

Philosophie & Société

How To Speak

Techniques de communication orale, présentation académique, heuristiques de parole efficace

#communication orale#art oratoire#présentation

Patrick Winston

Philosophie & Société

Goodhart's law

Article encyclopédique (Wikipedia, anglais) sur la **loi de Goodhart** : énoncée par l'économiste britannique Charles Goodhart en 1975 à propos de la politique monétaire — « toute régularité statistique observée tend à s'effondrer dès qu'on exerce une pression sur elle à des fins de contrôle » — puis généralisée par l'anthropologue Marilyn Strathern (1997) en l'aphorisme canonique « quand une mesure devient une cible, elle cesse d'être une bonne mesure ». Le sujet relie économie, théorie des incitations, évaluation des politiques publiques et, par extension, l'optimisation des métriques dans les systèmes d'IA.

#loi de Goodhart#mesure devenue cible#régularité statistique

Wikipedia contributors (concept : Charles Goodhart ; généralisation : Marilyn Strathern)