Services-as-Software : une réécriture de la marge brute, pas un pivot produit

J’aime l’ambition derrière « Services-as-Software ». L’analyse de ZDNET va globalement dans la bonne direction : l’IA transforme une part croissante de la delivery de services en quelque chose que l’on peut packager, répéter et vendre avec une économie qui ressemble davantage à celle du software.

Mais la plupart des équipes commettent une erreur si basique qu’elle en devient gênante : elles le traitent comme un virage produit. Elles le budgètent comme un SaaS classique. Et six mois plus tard, elles se retrouvent avec des « fonctionnalités IA » qui se comportent comme une agence impossible à faire passer à l’échelle.

Mon point de vue d’opérateur est simple : Services-as-Software, c’est une réécriture de la marge brute. Si vous ne mesurez pas et ne contrôlez pas la variabilité, les cas limites dévorent votre P&L bien avant que le chiffre d’affaires n’ait l’air « AI-powered ».

J’ai vu la même dynamique dans deux univers. Dans les organisations de services industriels, la variabilité se cache sur le terrain : déplacements, temps de diagnostic, pièces détachées et escalades. Dans le SaaS, elle se cache dans le support et la delivery : workflows sur mesure, nettoyage de données, intégrations, et désormais tokens et minutes de human-in-the-loop. Surface différente. Même maladie.

Le vrai changement n’est pas « des features IA ». C’est la visibilité sur le cost-to-serve.

Les unit economics du SaaS classique partent du principe que le coût marginal est surtout de l’infrastructure et du support, et que les deux montent de façon raisonnable avec le revenu. Services-as-Software casse cette hypothèse, parce que l’exécution devient un hybride de :

• Travail variable côté compute (tokens par workflow, appels de retrieval, model eval, batch jobs).
• Travail variable côté humain (minutes de revue, gestion des exceptions, onboarding, correction de données, formation client).
• Travail variable côté support (tickets, incidents, escalades « pourquoi le modèle a fait ça ? »).

Si vous ne mesurez pas explicitement ces trois postes, vous ne pouvez pas piloter votre marge brute. Vous avancez à l’aveugle.

Quand je dirigeais une business unit internationale dans le smart-building et la domotique, j’ai appris une leçon difficile sur les produits connectés : la marge du hardware n’est pas la marge du système. Retours, support à distance, cas limites de firmware, erreurs d’installateurs et variabilité fournisseurs créent des coûts invisibles tant que vous n’instrumentez pas. La delivery par l’IA raconte la même histoire, sauf qu’ici la variabilité se trouve dans vos workflows et vos prompts.

Le piège : vous vendez de la certitude, mais vous livrez de la variabilité

La plupart des offres Services-as-Software se vendent comme si le fournisseur pouvait prédire la charge par client. Forfait. Tout inclus. « Unlimited ». Ça aide à signer. Ça subventionne aussi les comptes les plus bruyants et pénalise les comptes les plus calmes.

En tech industrielle, on n’a jamais fait semblant que le service était illimité. Il y a des conditions de garantie. Des niveaux de service. Des inclusions et des exclusions claires. Et on suit les modes de défaillance, parce qu’ils font le coût. Les équipes SaaS sautent souvent cette discipline parce que le software l’a historiquement tolérée. L’IA ne le fera pas.

L’article de ZDNET présente Services-as-Software comme le modèle suivant. Je suis d’accord sur l’orientation. Là où je diverge, c’est sur la facilité implicite. La partie difficile, ce n’est pas de livrer l’assistant. La partie difficile, c’est de transformer l’exécution en processus maîtrisé, avec des intrants mesurables et des extrants bornés.

Si ce sujet vous parle, il est directement lié à la responsabilité sur les workflows. J’en parle ici : AI Leadership Is Workflow Leadership: Own the Handoffs. Si vous ne tenez pas les handoffs, vous ne tiendrez pas le coût.

Instrumentez chaque interaction IA comme vous instrumentez le cloud spend

Voici la base opérationnelle que je mettrais en place ce trimestre. Pas l’an prochain. Ce trimestre.

1) Définissez l’« unité de travail » pour chaque workflow produit

Choisissez 3 à 5 workflows qui comptent commercialement. Exemples : « générer et approuver une réponse client », « rédiger une synthèse de conformité », « classifier une demande entrante et la router ». Pour chaque workflow, définissez une unité que vous pouvez compter.

2) Mesurez les trois drivers de coût par unité

• Tokens et tool calls : moyenne, p95 et max. Pas par curiosité. Pour contrôler la variance.
• Minutes de human-in-the-loop : revue, correction, escalade. Suivez qui intervient et pour quelles raisons.
• Charge support : tickets pour 100 unités, taux d’incident, temps de résolution.

Dans mes années en électronique de puissance, la qualité tenait surtout à une discipline de mesure : définir les modes de défaillance, les capter de manière cohérente, et les intégrer dans les actions correctives. La delivery par l’IA demande le même muscle. Le metering, c’est votre « field return analysis ».

3) Créez un « cost-to-serve ledger » par compte

Pas un dashboard qui fait joli. Un ledger capable de répondre : ce compte a consommé X unités, généré Y exceptions, demandé Z minutes de travail humain, et déclenché N événements support.

Si vous ne pouvez pas produire ce ledger, vous ne pouvez ni tarifer rationnellement, ni tenir une discussion de renouvellement mature.

4) Intégrez les garde-fous dans le produit, pas dans des documents de politique

• Rate limits, quotas et mécanismes de backoff.
• Discipline sur la context window et plafonds de retrieval.
• Timeouts de workflow et dégradation maîtrisée (templates de fallback, modes « profondeur réduite »).
• Règles d’escalade auditables.

C’est là que beaucoup d’équipes confondent « AI architecture » et schémas. Ici, on parle d’une checklist de contrôles qui tournent tous les jours. Pour un parallèle, voir : AI Architecture Isn’t a Diagram. It’s an Operator’s Checklist.

Refondez la tarification : résultats + usage, avec des inclusions strictes

Dès que vous savez mesurer le cost-to-serve, la tarification devient un sujet d’ingénierie et de packaging, pas un débat en salle de réunion.

J’applique une règle simple : vendez le résultat, facturez la variabilité.

• Composante résultat : ce que le client achète (résolution plus rapide, débit plus élevé, moins d’erreurs). C’est l’ancrage de valeur.
• Composante usage : ce qui fait votre coût marginal (unités traitées, tokens, exécutions de workflows, tool calls). C’est ce qui protège la marge.
• Composante exception : ce qui casse l’exécution standard (intégrations sur mesure, préparation de données atypique, revue à haut risque). C’est soit un tier payant, soit du professional service.

Ne cachez pas les exceptions. Nommez-les. Inscrivez-les dans le contrat et dans le packaging produit. En service industriel, la garantie a des limites pour une raison. Dans les services IA, le « unlimited » sans garde-fous, c’est juste une perte de marge différée.

C’est aussi pour cela que je répète : Pricing Is Product Management in Disguise. La tarification vous force à définir la surface du produit. L’IA élargit cette surface. Si vous ne la contraignez pas, vos clients le feront à votre place, via le churn ou les escalades.

Un schéma vécu : le jour où vous arrêtez de deviner, le modèle devient scalable

Quand j’ai construit et opéré des produits SaaS (dont EatMore, puis mes propres ventures comme IBHQ), la phase dangereuse a toujours été la même : les premiers signaux de traction vous attirent vers une delivery sur mesure. Vous appelez ça « customer success ». En réalité, ce sont des opérations manuelles.

L’IA amplifie le phénomène parce qu’elle donne l’impression que le sur-mesure va vite. Vous colmatez un workflow avec un prompt. Vous ajoutez une étape de revue rapide. Vous accompagnez l’onboarding de près. Le revenu rentre. La marge brute s’érode en silence.

Le point de bascule arrive quand vous cessez d’argumenter sur le fait que quelque chose est « produit » ou « service », et que vous le traitez comme une ligne de production :

• Mesurer chaque étape.
• Réduire la variance là où cela compte.
• Faire passer les exceptions par un parcours payant.
• Réinjecter les modes de défaillance dans la conception des workflows.

Si vous n’êtes pas capable d’expliquer votre cost-to-serve par workflow sur une page, vous n’avez pas Services-as-Software. Vous avez une agence avec une UI.

Mon prisme de décision pour ce trimestre

Si vous envisagez une approche Services-as-Software, je prendrais trois décisions maintenant.

1. Choisissez les workflows que vous allez industrialiser. Pas tout. Commencez par ceux qui ont une structure répétable et une valeur claire.
2. Actez que le metering est une feature produit de premier rang. Tokens, minutes humaines, événements support. Pas de metering, pas de passage à l’échelle.
3. Repricer avant d’accélérer la distribution. Si vous poussez le go-to-market sur un modèle unitaire cassé, vous accélérez l’effondrement de la marge.

Mon avis est clair : Services-as-Software va gagner, mais uniquement pour les équipes qui l’opèrent comme une activité manufacturière. Instrumentez la ligne. Contrôlez la variabilité. Faites payer les exceptions. Le reste, c’est du théâtre.

Si vous voulez challenger vos unit economics et votre packaging pour un service assisté par l’IA, contactez-moi via la page de contact et dites-moi quel workflow vous essayez de faire passer à l’échelle.