Les agents IA vont coûter cher. Ceux qui sauront les router vont gagner gros.

La semaine dernière, on parlait d’un glissement important : le Product Builder ne pense plus seulement en prompts, mais en boucles de travail.

Cette semaine, un deuxième glissement apparaît.

Quand une boucle IA commence à tourner souvent, le problème n’est plus seulement “est-ce que ça marche ?”. C’est “combien ça coûte, à quel moment ça casse, et qui décide quel modèle doit faire quoi ?”

C’est moins sexy qu’une démo agentique.

Mais c’est probablement là qu’une partie des prochains vrais business IA va se construire.

Au programme :

• 🧠 Pourquoi le moat remonte du modèle vers le routage, la marge et les garde-fous.

• 🛠️ Comment auditer un workflow IA en 30 minutes pour repérer les appels trop chers, les tâches mal routées et les risques invisibles.

• 🧩 Pourquoi le SaaS ne disparaît pas forcément : il devient parfois la surface où humains et agents travaillent ensemble.

• 🔮 Quelques découvertes à ne pas louper : TabFM, Acti, Gemma local-first, X MCP et la confiance dans les prompts.

Pendant la première vague d’outils IA, beaucoup de builders ont pensé en termes très simples :

“J’ai une tâche. J’appelle le meilleur modèle possible. Je rends le résultat.”

Pour une démo, ça suffit.

Pour un produit utilisé tous les jours, c’est une autre histoire.

Un agent qui résume un document une fois ne pose pas le même problème qu’un agent qui traite 2 000 tickets support, relance 800 leads, vérifie 400 factures, génère 150 brouillons de posts, ou analyse des dizaines de fichiers clients chaque semaine.

À petite échelle, tu regardes la qualité.

À grande échelle, tu regardes aussi :

• le coût par tâche terminée ;

• le coût par résultat accepté ;

• le nombre de retries ;

• la quantité de contexte envoyée au modèle ;

• les tâches qui auraient pu tourner sur un modèle moins cher ;

• les cas où un humain aurait dû valider avant l’action.

Autrement dit : la facture IA n’est plus un problème technique. Elle devient une question de design produit.

Every a publié cette semaine un cadre intéressant sur les “paris implicites” des startups IA. L’idée centrale : quand tu construis avec l’IA, tu fais toujours des paris sur le coût des tokens, la dépendance à un fournisseur, la capacité des modèles à absorber ton use case, ou encore l’évolution de la régulation. Si tu ne les rends pas explicites, ton produit peut devenir fragile sans que tu comprennes pourquoi. — Every

Le point qui m’intéresse ici est très concret.

Si tu construis un produit IA, tu ne dois plus seulement te demander :

“Quel est le meilleur modèle ?”

Tu dois te demander :

“Quelle partie de mon workflow mérite vraiment le meilleur modèle ?”

Ce n’est pas la même question.

Un modèle frontier peut être justifié pour une décision complexe, une synthèse sensible, une analyse juridique, une négociation commerciale, une revue de code critique, ou une étape où l’erreur coûte cher.

Mais est-ce qu’il est nécessaire pour reformater un texte, classer un email, extraire trois champs, nettoyer un CSV, générer un brouillon intermédiaire, ou détecter qu’un document est hors sujet ?

Souvent, non.

Et c’est là que le routage devient intéressant.

Le routage, dans ce contexte, c’est la couche qui décide quel moteur utiliser selon la tâche : modèle premium, modèle moins cher, modèle local, règle classique, cache, template, humain, ou parfois rien du tout.

Ce n’est pas seulement une optimisation.

C’est une manière de transformer une pile IA fragile en système économique.

Kilo a publié un guide très pragmatique sur la réduction des coûts IA en équipe engineering : model routing, contexte plus ciblé, garde-fous de dépenses, visibilité sur l’usage. Le vocabulaire est dev, mais le mécanisme vaut pour presque tous les workflows IA. — Kilo

Le signal est simple : plus les agents deviennent utiles, plus ils tournent souvent. Plus ils tournent souvent, plus les petits choix invisibles deviennent de gros sujets de marge.

Un Product Builder qui sait seulement “brancher Claude” va créer une démo.

Un Product Builder qui sait router, mesurer, limiter, vérifier et expliquer le coût d’un workflow peut vendre un système.

On pourrait croire que le routage est un sujet réservé aux équipes infra.

Je pense l’inverse.

Le routage est en train de devenir une compétence produit, parce qu’il force à comprendre la vraie valeur de chaque étape d’un workflow.

Prenons un exemple simple : un assistant commercial qui transforme des leads entrants en séquences de relance.

Version naïve :

1. tu envoies toute la fiche lead au meilleur modèle ;

2. il analyse ;

3. il écrit un email ;

4. il recommence pour chaque lead.

Ça marche en démo.

Mais en production, tu découvres vite les questions qui fâchent :

• pourquoi envoyer tout l’historique CRM si seuls trois champs comptent ?

• pourquoi utiliser un modèle premium pour détecter le secteur d’une entreprise ?

• pourquoi générer un email complet avant d’avoir vérifié que le lead est qualifié ?

• pourquoi refaire l’analyse si la même entreprise revient deux fois ?

• pourquoi laisser l’agent envoyer sans trace de décision ?

La bonne version ressemble plutôt à une chaîne de décisions :

• une règle ou un petit modèle classe le lead ;

• un enrichissement récupère seulement les infos utiles ;

• un modèle intermédiaire propose l’angle ;

• un modèle plus fort intervient seulement sur les comptes importants ;

• un humain valide les cas sensibles ;

• le système garde une trace : source, hypothèse, action, résultat.

Ce n’est pas moins “IA”.

C’est plus sérieux.

Le bon produit IA ne maximise pas l’intelligence appelée à chaque étape. Il maximise le rapport entre coût, fiabilité et valeur métier.

Et ça change la manière de vendre.

Tu ne dis plus :

“Je vais te construire un agent commercial.”

Tu peux dire :

“Je vais réduire le coût de qualification par lead, limiter les relances inutiles, garder une trace exploitable dans ton CRM, et réserver les modèles chers aux opportunités qui le méritent.”

C’est beaucoup plus proche d’un achat B2B.

Et beaucoup moins proche d’un gadget.

Ce que ça change pour toi :

• 🟢 Maintenant : sur un workflow IA que tu utilises déjà, liste toutes les étapes où tu appelles un modèle. Pour chacune, demande-toi : “est-ce que cette étape mérite vraiment le meilleur modèle ?”

• 🟡 À surveiller : les clients vont progressivement demander de la prévisibilité. Pas seulement “combien coûte l’outil”, mais “combien coûte une tâche terminée”.

• ⚪ Pas encore : ne transforme pas tout en usine à gaz. Si ton usage tourne dix fois par mois, le routage est peut-être prématuré. S’il tourne mille fois, il devient stratégique.

Si tu construis déjà avec l’IA, tu peux faire un mini-audit très simple cette semaine.

Pas besoin d’un dashboard magnifique.

Une feuille, un Notion, un Airtable, un Google Sheet, peu importe.

L’objectif est de sortir du flou.

Tu veux voir où ton workflow dépense de l’intelligence sans raison claire.

Voici la grille :

1. Entrée : qu’est-ce qui déclenche l’appel IA ?

2. Tâche : que demande-t-on vraiment au modèle ?

3. Modèle utilisé : lequel, et pourquoi celui-là ?

4. Contexte envoyé : de quelles données a-t-il réellement besoin ?

5. Risque d’erreur : que se passe-t-il si la réponse est mauvaise ?

6. Validation : qui vérifie avant action ?

7. Sortie utile : quel résultat métier est produit ?

8. Alternative moins chère : règle, template, petit modèle, modèle local, cache, humain ?

Tu vas probablement trouver trois types de fuites.

Première fuite : le contexte trop large.

On envoie un document complet alors que la tâche nécessite seulement un extrait. On envoie tout l’historique client alors que trois lignes suffisent. On colle un PDF entier alors qu’une étape de pré-processing ferait le tri.

Deuxième fuite : le modèle trop puissant.

On utilise un modèle premium pour une tâche répétitive, structurée, peu risquée. Classification, extraction, reformulation simple, nettoyage, tagging : souvent, ce n’est pas là que le meilleur modèle crée la valeur.

Troisième fuite : l’action trop rapide.

L’agent agit avant d’avoir vérifié. Il modifie, envoie, supprime, relance, publie, ou décide sans trace claire. Ce n’est plus seulement un sujet de coût. C’est un sujet de confiance.

Et c’est là que le Product Builder peut apporter quelque chose de très concret.

Tu peux vendre un diagnostic :

• où le workflow coûte trop cher ;

• où il manque une étape de validation ;

• où le modèle reçoit trop de contexte ;

• où un modèle local ou moins cher suffit ;

• où l’humain doit rester dans la boucle ;

• où la donnée métier peut devenir un avantage.

Ce genre d’audit peut devenir une offre simple pour une PME, une agence, une équipe sales, une équipe support, une équipe finance, ou un cabinet qui commence à utiliser des agents sans vraiment savoir ce qui se passe sous le capot.

Et franchement, c’est souvent plus vendable qu’un “agent IA sur mesure” présenté dans le vide.

Parce que tu pars d’une douleur :

“On utilise l’IA, mais on ne sait pas si c’est fiable, combien ça coûte vraiment, ni où ça peut casser.”

Ça, c’est une vraie phrase de client.

L’autre signal intéressant de la semaine, c’est que le débat “SaaS is dead” devient un peu trop simpliste.

Oui, certains logiciels vont se faire absorber par les modèles.

Oui, certaines interfaces trop génériques vont perdre de la valeur.

Oui, si ton produit est juste un formulaire avec une API LLM derrière, tu risques de te faire copier vite.

Mais ça ne veut pas dire que tous les SaaS disparaissent.

Les meilleurs SaaS peuvent devenir les endroits où les agents travaillent avec les humains.

Every a pris l’exemple de Linear, qui ne s’est pas contenté d’ajouter une couche IA décorative. L’outil se repositionne comme un environnement agent-native : les agents peuvent devenir des utilisateurs du système, agir dans le workflow logiciel, et cohabiter avec les équipes humaines. — Every

C’est une nuance énorme.

Le SaaS faible dit :

“Regarde, j’ai ajouté un chatbot.”

Le SaaS fort dit :

“Mes objets, mes permissions, mon historique, mes statuts, mes commentaires, mes intégrations et mes règles métier sont lisibles par des agents.”

Dans le deuxième cas, l’interface garde de la valeur.

Pas parce qu’elle est jolie.

Parce qu’elle devient une surface d’orchestration.

On voit le même mouvement ailleurs.

X vient d’annoncer un MCP hébergé pour connecter des outils compatibles MCP à l’API X avec les permissions du compte utilisateur. Le signal n’est pas seulement “X a une API”. Le signal, c’est que les grandes plateformes commencent à rendre leurs données et actions plus directement utilisables par agents. — X Developers

Acti, de son côté, parie sur un autre point d’entrée : le clavier mobile. Leur idée est simple : si l’intention de l’utilisateur passe déjà par le texte qu’il tape dans toutes ses apps, alors le clavier peut devenir une surface d’action agentique. — TechCrunch

Même logique, autre surface.

La valeur n’est pas seulement dans le modèle.

Elle est dans l’endroit où l’intention apparaît, où le contexte existe déjà, et où l’action peut être déclenchée avec le moins de friction.

Pour un Product Builder, c’est une question très utile :

“Dans ce métier, quelle est la surface où l’intention apparaît déjà ?”

Ça peut être :

• le CRM ;

• la boîte mail ;

• le calendrier ;

• le tableur ;

• le ticket support ;

• le back-office ;

• le clavier ;

• le document ;

• le fil de discussion ;

• le dashboard métier.

Si tu trouves cette surface, tu n’as pas forcément besoin de construire “le prochain ChatGPT vertical”.

Tu peux construire la couche qui rend un workflow existant plus actionnable, plus fiable, plus mesurable.

C’est moins spectaculaire.

Mais c’est souvent beaucoup plus proche du budget.

→ TabFM par Google Research : Google présente un modèle de fondation spécialisé pour les données tabulaires, capable de faire classification et régression sur des tables nouvelles sans entraînement manuel classique. Le signal : les workflows finance, supply, BI, pricing ou ops pourraient devenir beaucoup plus attaquables par de petites équipes si les modèles commencent à mieux comprendre les tableaux métier. — Google Research

→ Gemma 4 12B en local : Google pousse Gemma 4 12B comme modèle multimodal capable de tourner sur des laptops grand public avec 16 Go de RAM, avec des usages locaux via Google AI Edge. Le signal : le local-first n’est plus seulement une posture souveraineté, c’est aussi une piste de coût, de latence et de confidentialité pour certains workflows. — Google AI Developers Blog

→ Acti et le clavier agentique : Acti met des agents IA directement dans le clavier mobile. Ce qui m’intéresse ici, ce n’est pas seulement le produit, c’est le choix de surface : le clavier est là au moment exact où l’intention se formule. Pour un builder, c’est un bon rappel : le meilleur point d’entrée n’est pas toujours une app séparée. — TechCrunch

→ X MCP : X lance un MCP hébergé pour connecter des outils compatibles à l’API X. Le signal : les plateformes qui veulent rester utiles aux agents vont devoir rendre leurs actions, permissions et données plus structurées. La distribution de demain ne sera peut-être pas seulement humaine, elle sera aussi lisible par machines. — X Developers

Si un sujet t’a parlé, si tu veux challenger une idée ou juste dire que tu étais là — réponds directement à cet email. Je lis tout et je réponds à tout.

Et si tu as un projet à développer — une app, un outil interne, une V1 à finaliser — c’est exactement pour ça que je suis là. Un message en réponse à cet email suffit pour qu’on en parle.

Si tu veux sponsoriser les prochaines éditions c’est possible. Je te laisse consulter le deck.

Si cette édition t’a apporté quelque chose, le meilleur coup de pouce que tu puisses me donner, c’est de la partager à quelqu’un qui en ferait quelque chose 👇

Share

Tu peux aussi me retrouver sur LinkedIn pour suivre ce que je construis en dehors des éditions.

Bonne semaine,

— Milan