Quand l’IA devient bon marché, l’exécution devient la seule marge

J’ai déjà vu ce film, sous d’autres costumes. Le hardware se banalise. Les primitives cloud deviennent moins chères. Les outils se diffusent. Ce qui reste rare, ce n’est pas le composant : c’est la capacité à le faire fonctionner dans une opération réelle.

L’IA (intelligence artificielle) suit la même trajectoire. Si vous pariez sur une marge « brute » au niveau du modèle, les maths finiront par se retourner contre vous. Quelqu’un proposera une capacité comparable à un coût inférieur. Un autre l’intégrera dans un bundle. Un troisième l’exécutera sur des modèles plus petits, au plus près du travail. Vous pouvez discuter des délais, pas de la direction.

Je considère donc la « marge IA » comme une illusion, sauf si elle est ancrée dans l’exécution. La marge défendable, c’est votre capacité à intégrer l’IA dans des workflows, à la maintenir fiable et à produire des résultats mesurables trimestre après trimestre. Ce n’est pas une formule de product marketing. C’est de l’exécution opérationnelle.

Le basculement : de l’économie des tokens à l’économie opérationnelle

En salle de board, la question n’est pas : « Quel modèle utiliser ? » La question est : « Quelle unité de travail devient moins chère, plus rapide et plus sûre ? » Voilà l’économie opérationnelle.

Quand je dirigeais une business unit internationale dans le smart building et la home automation, la marge ne venait pas uniquement de la nomenclature (bill of materials). Elle venait de la baisse des retours, d’une exécution de livraison plus fiable et d’un service scalable d’un marché à l’autre. Le même principe vaut pour l’IA. Le « modèle » n’est pas le produit. Le produit, c’est l’amélioration opérationnelle qu’il rend possible.

Quand les coûts des modèles baissent, deux choses se produisent :

• L’inférence devient un input variable. Comme l’électricité dans une usine ou les frais SMS dans une app grand public : cela compte, mais cela justifie rarement une prime durable.
• L’intégration devient la contrainte. Le goulot d’étranglement se déplace vers la conception des processus, les contrats de données, la QA et la conduite du changement.

Si vous voulez une marge qui tient, vous devez maîtriser la contrainte.

Budgétez l’IA comme un programme d’amélioration des ops, pas comme un projet de recherche

Les opérationnels se trompent de budget IA de façon prévisible. Ils sur-financent le modèle et sous-financent tout ce qui le rend utile en production. Puis ils concluent que l’initiative a échoué.

Je budgète l’IA comme je budgétais les programmes qualité et fiabilité dans l’industriel. On met l’argent là où se trouvent le risque et la reprise.

Voici l’ordre que j’applique :

1. Cartographier le workflow et attribuer la responsabilité. Nommez un responsable de process. Définissez le « avant » et le « après ». Si vous ne savez pas décrire les handoffs, vous ne savez pas les automatiser. C’est le même raisonnement que j’expose dans AI value and the stop button. Si personne ne détient le stop button, personne ne détient le résultat.
2. Intégration d’abord. Votre modèle reste un cerveau dans un bocal tant qu’il ne sait pas lire et écrire dans les systèmes où le travail se fait. ERP, CRM, ticketing, PLM, MES, e-mails, tableurs. L’intégration n’est pas spectaculaire, mais c’est là que vous gagnez du cycle time.
3. QA et monitoring comme un produit, pas comme une tâche. Dans l’électronique grand public, lorsque j’avais la QA et le test sur hardware et software, le plus gros coût n’était pas l’équipement de test. C’étaient les défauts qui s’échappaient, puis revenaient en retours et en charge support. Pour l’IA, c’est pareil. Il vous faut des cas de test systématiques, des suites de régression et du monitoring en continu.
4. Formation et incitations. Si vous mesurez les équipes sur la production mais que l’IA change les étapes, vous devez mettre à jour les mesures. Sinon, vous créez des processus parallèles et un rejet silencieux.
5. Dépense modèle en COGS variable. Traitez-la comme une ligne qui doit baisser. Négociez-la. Multisourcez-la. Concevez pour pouvoir changer de fournisseur.

Cette posture budgétaire fait deux choses : elle vous protège contre la compression des prix des modèles ; et elle vous force à construire les capacités qui créent un vrai levier opérationnel.

Quoi mesurer : exploiter l’IA comme un système critique

La plupart des équipes IA remontent des métriques au niveau du modèle qui ne se traduisent pas en pilotage opérationnel. Precision, recall, scores de benchmark. Utile, mais incomplet.

Comme ancien COO dans l’électrification et le stockage d’énergie, je regardais des métriques reliées à l’exécution et au risque : disponibilité, lead time, rebuts, reprises, pannes terrain. Si un système d’IA touche des engagements clients ou le débit interne, il mérite la même exigence.

Mon scorecard de base ressemble à ceci :

• Disponibilité : la capacité est-elle accessible quand l’opération en a besoin ?
• Latence : répond-elle dans la fenêtre de décision du workflow ?
• Précision pour la tâche : pas une précision générique, mais la précision sur vos cas réels, y compris les cas limites.
• Coût par tâche résolue : coût total, y compris revue humaine, escalades et reprises.
• Taux d’escalade : à quelle fréquence passe-t-on à un humain, et pourquoi ?
• Taux de reprise : à quelle fréquence le travail en aval doit-il corriger une sortie IA ?
• Taux d’échec des changements : quand vous mettez à jour des prompts, des outils ou des modèles, à quelle fréquence cassez-vous le workflow ?

Deux règles d’opérateur :

• Si vous ne pouvez pas revenir en arrière en sécurité, vous n’êtes pas prêt à passer à l’échelle. C’est un problème de discipline de release, pas un problème d’IA.
• Si vous ne pouvez pas expliquer un échec, vous ne pouvez pas l’améliorer. Traitez les incidents comme un écart de production.

C’est aussi pour cela que j’apprécie les déploiements plus petits et plus contrôlables, quand c’est pertinent. J’ai détaillé cet état d’esprit dans shipping AI with small models. Quand le coût de l’échec est réel, le contrôle vaut mieux que la sophistication.

Tarification : vendez des résultats, pas des tokens

Si vous tarifez l’IA comme « tokens + marge », vous choisissez une course vers le bas. Et vous désalignez les intérêts. L’acheteur veut moins de tokens, moins d’étapes, moins d’erreurs. Vous voulez plus de consommation. Cela finit mal.

La tarification à la performance est plus difficile, mais elle correspond à la logique des opérationnels. Reliez vos frais à l’unité d’amélioration que votre client valorise réellement :

• Débit : dossiers clôturés par jour, devis produits par semaine, sinistres traités par heure.
• Baisse du taux d’erreur : moins de factures erronées, moins d’escalades injustifiées, moins d’écarts de conformité.
• Performance sous SLA : temps de réponse et disponibilité pour un workflow défini.

Dans mes expériences SaaS et fintech, j’ai appris à expliciter la frontière entre automatisation et responsabilité. Si vous tarifez au résultat, vous devez aussi définir :

• Les inputs requis (qualité des données, accès aux systèmes, règles de revue humaine).
• Le périmètre (quels workflows, quelles langues, quels types d’exception).
• Ce que signifie « bon » (critères d’acceptation et auditabilité).

Une tarification au résultat sans définitions opérationnelles se transforme en litige contractuel. Avec des définitions opérationnelles, elle devient un partenariat.

Un prisme simple : où se trouve réellement votre marge défendable

J’utilise un prisme simple pour évaluer un produit ou une initiative d’IA : identifiez où se situe la marge défendable, puis investissez à cet endroit.

• Marge modèle : fragile. Attendez-vous à une compression.
• Marge d’accès aux données : parfois durable, souvent politique. Il faut de toute façon exécuter pour en tirer parti.
• Marge d’intégration au workflow : durable. Douloureuse à répliquer.
• Marge de fiabilité : très durable. La plupart des équipes n’ont pas la discipline nécessaire.
• Marge de conduite du changement : durable. Sous-estimée par les équipes techniques.

Quand je construis des ventures comme Shopeno et IBHQ, je pars du principe que la capacité IA sous-jacente deviendra moins chère et plus accessible. La différenciation doit venir de la manière dont le produit s’insère dans le workflow, de la sécurité d’exploitation, et de la vitesse d’amélioration sans casser la confiance. C’est la seule façon de bâtir quelque chose qui survive à un reset des prix.

La même logique vaut dans l’industrie. La fiabilité est un contrat : on le paye, et on le fait respecter. Je l’ai formulé explicitement dans ruggedization as a reliability contract. Pour l’IA, c’est pareil. Le travail de fiabilité, c’est là que la marge se cache.

Ma checklist pour le prochain trimestre

Si vous êtes membre de board, propriétaire ou opérateur et que vous voulez rendre cela actionnable rapidement, voici ce que je pousserais sur les 90 prochains jours :

1. Choisir un workflow avec volume et douleur clairement identifiables. Pas une démo. Une file d’attente réelle.
2. Définir l’unité de valeur. Temps de résolution, coût par dossier, taux de reprise, conformité aux SLA.
3. Instrumenter le point de départ. Si vous ne mesurez pas le « avant », vous ne pouvez pas revendiquer le « après ».
4. Financer l’intégration et la QA avant la dépense modèle. Rendez le modèle remplaçable.
5. Livrer avec un stop button et une capacité de rollback. Si le système ne peut pas échouer proprement, il échouera bruyamment.
6. Mettre le monitoring en routine. Un dashboard unique, réellement utilisé par le responsable de process.
7. Tarifer (ou refacturer en interne) au résultat. Alignez les incitations sur moins de gaspillage, pas plus de tokens.

Mon avis : les gagnants ressembleront à des opérateurs, pas à des revendeurs de modèles

L’IA va continuer à coûter moins cher à exécuter. C’est une bonne nouvelle pour tout le monde, mais cela détruit les entreprises qui confondent coûts d’inputs et création de valeur.

Celles qui préserveront leur marge seront capables de prendre une réalité imparfaite, de la traduire en workflow, d’intégrer en profondeur, et d’exploiter le système avec une discipline de fiabilité. Elles parleront moins de modèles, et davantage de débit, de défauts et de SLA. Elles traiteront l’IA comme une capacité opérationnelle, pas comme une feature.

Si vous voulez une marge défendable, arrêtez de chercher comment monétiser l’inférence. Commencez à chercher comment monétiser l’exécution.