La refonte IA qui fait bouger l’ARR : un playbook, pas une démo

La plupart des « transformations IA » échouent d’une manière ennuyeuse : le modèle impressionne en démo, mais rien ne se met à composer dans l’activité.

Pas parce que les équipes sont paresseuses. Pas parce que les clients sont irrationnels. Parce que l’entreprise n’a pas changé ce qui fabrique réellement le chiffre : le système de travail qui transforme une réalité désordonnée en résultats reproductibles.

C’est pour cela que, dans l’article de SaaStr sur Owner.com, la phrase la plus utile ne parle ni de prompts ni d’agents. Elle parle d’horizon. Ils décrivent trois ans à reconstruire Owner.com autour de l’IA. Trois ans, c’est le temps nécessaire quand on arrête de traiter l’IA comme une feature et qu’on la considère comme le nouveau système de production.

Voici le playbook que j’aimerais voir utilisé bien plus souvent. Rien de romantique. On parle surtout de responsabilité, de handoffs et de qualité. C’est précisément pour cela qu’il fait bouger l’ARR.

Étape 1 : nommer le produit que vous refondez réellement

« Ajouter de l’IA », c’est vague. « Reconstruire autour de l’IA », c’est encore vague. Le premier geste concret consiste à nommer ce dont l’IA sera responsable, de bout en bout.

Raisonnez en chaîne de production, pas en features :

• Entrées : quels signaux entrent dans le système (messages clients, catalogue, tickets, usage, contrats, règles de pricing).
• Transformation : quelles décisions sont prises (classifier, recommander, rédiger, router, approuver, déclencher).
• Sorties : quel artefact est produit (un devis, un e-mail, une configuration, une prévision, une résolution support, un changement de code).
• Unité économique : quelle métrique vous cherchez à améliorer (conversion, churn, expansion, time to value, coût support par compte).

Si vous ne pouvez pas dessiner ce parcours sur une page, vous n’êtes pas en train de refondre quoi que ce soit. Vous saupoudrez de l’intelligence sur une machine inchangée.

C’est aussi à ce moment-là que vous devez cadrer honnêtement. Une refonte qui « touche à tout » devient une réécriture sans plan. Choisissez un parcours où le résultat est proche de l’argent, et où l’ancien workflow présente des frictions évidentes.

Étape 2 : faire passer la responsabilité des données de « disponible » à « assumée »

L’IA (intelligence artificielle) n’a pas d’abord besoin de plus de données. Elle a besoin de données que quelqu’un est prêt à défendre.

Dans la plupart des entreprises SaaS, la donnée a une propriété « molle » : « l’équipe data warehouse », « revops », « product analytics ». Ça fonctionne quand la donnée sert à alimenter des dashboards. Ça casse dès que la même donnée déclenche des actions visibles côté client.

Pour une refonte IA, vous avez besoin de trois niveaux de responsabilité explicites :

• Responsables des sources : ceux qui garantissent la vérité à l’origine. Exemple : les règles de pricing doivent vivre chez le responsable commercial, pas dans la tête d’un ingénieur, ni dans un tableur que personne n’ose modifier.
• Responsables du schéma : ceux qui garantissent le contrat de données (définitions, valeurs autorisées, versioning). Si un champ change de sens, quelqu’un doit communiquer et piloter la migration.
• Responsables des comportements : ceux qui portent la manière dont l’IA utilise la donnée pour agir (ce que le modèle est autorisé à faire, quand il doit demander, quand il doit s’arrêter).

Le point clé : ce ne sont pas des comités. Ce sont des noms, noir sur blanc.

Règle simple : si un champ peut modifier des résultats d’ARR, il doit avoir un owner humain et une piste d’audit. Sinon, vos « erreurs d’IA » seront surtout des erreurs de gouvernance déguisées en problème de modèle.

Étape 3 : repenser les workflows autour des handoffs, pas autour des outils

La plupart des équipes introduisent l’IA en ajoutant un outil dans un workflow existant. C’est rassurant. C’est aussi la raison pour laquelle l’adoption plafonne.

L’IA fait chuter le coût d’un premier jet. Le goulot d’étranglement se déplace. Le workflow doit se déplacer avec lui.

Il existe quelques patterns robustes, qui passent à l’échelle :

Pattern A : rédiger, puis approuver

À utiliser quand le coût d’une mauvaise sortie est élevé, mais que le coût de la revue reste raisonnable. Exemples : communications sortantes vers de grands comptes, exceptions de pricing, formulations quasi juridiques, réponses support sensibles.

• L’IA produit un draft.
• Un humain approuve à l’aide d’une checklist, pas au feeling.
• La décision d’approbation est tracée comme signal d’entraînement ou feedback de règles.

Pattern B : agir, puis auditer

À utiliser quand la vitesse compte et que le mode d’échec est récupérable. Exemples : routage, tagging, recherche de connaissance interne, personnalisation à faible enjeu.

• L’IA agit automatiquement dans des guardrails définis.
• Vous échantillonnez et auditez les résultats chaque jour ou chaque semaine.
• Quand des clusters d’échecs apparaissent, vous durcissez les règles ou ajoutez une étape de gate.

Pattern C : demander, puis assister

À utiliser quand l’utilisateur doit rester aux commandes, tout en gagnant en levier. Exemples : account planning, product discovery, exploration de design technique.

• L’utilisateur pose la question.
• L’IA propose des options, avec des sources citées à l’intérieur de votre système.
• L’utilisateur choisit et assume la décision.

Le piège consiste à mélanger les patterns sans le dire. On finit alors à débattre de « confiance », alors que le vrai sujet est : est-ce que le système a le droit d’agir, oui ou non ?

Si ce sujet vous parle, la même logique vaut en engineering. Un agent de code n’est pas un simple bouton. C’est un changement de release pipeline. J’ai développé cette idée dans Default-On Agentic Coding Is a Release Pipeline Change, Not a Feature Toggle.

Étape 4 : payer les équipes pour dire la vérité, pas pour livrer l’illusion

Une refonte IA percute rapidement les incitations.

Si les équipes produit sont récompensées pour « shipper » des features, elles livreront une fine couche d’IA et appelleront cela une transformation. Si les sales sont payés au closing, ils sur-vendront et déplaceront le risque vers le support. Si le support est mesuré au volume de tickets clôturés, il évitera de remonter les défaillances systémiques de l’IA, parce que cela crée du travail.

Il vous faut au moins quatre ajustements :

• L’adoption plutôt que l’annonce : récompenser la profondeur d’usage (workflows réellement complétés), pas les dates de lancement.
• La qualité plutôt que le volume : récompenser le faible rework, la faible escalade et la stabilité des résultats. Une sortie IA qui génère du travail supplémentaire, c’est de la productivité négative.
• La vérité plutôt que l’apparence : récompenser la remontée précoce des échecs. Faire de « j’ai trouvé un mode d’échec critique » un comportement valorisé.
• Une responsabilité partagée : relier les promesses commerciales aux réalités de delivery. Si un deal nécessite un comportement IA qui n’est pas en production, il faut le traiter comme un engagement produit, pas comme une ligne de vente.

C’est là que beaucoup de refontes meurent en silence. Pas sur la précision. Sur la politique interne. L’entreprise continue de payer l’ancien jeu, donc les équipes continuent d’y jouer.

Étape 5 : la QA devient un produit, avec des gates et une vraie capacité d’incident

La QA classique suppose du déterminisme. Le comportement de l’IA est probabiliste. Le système de QA doit donc évoluer de « est-ce que ça passe le test ? » à « est-ce que ça reste dans des bornes de comportement acceptables ? »

Concrètement, il vous faut quatre éléments :

1. Golden tasks : un ensemble vivant de cas représentatifs, exécuté à chaque changement de prompts, de modèles, d’outils ou de mapping de données.
2. Spécifications comportementales : des énoncés simples de ce que le système doit faire et ne doit jamais faire. Pas académiques, mais applicables. C’est la différence entre un système pilotable et un système « hanté ».
3. Release gates : si l’IA touche à la facturation, aux communications clients ou à des actions irréversibles, il faut une gate. Sans gate, pas de refonte.
4. Boucle d’incident : quand quelque chose déraille, traitez-le comme un incident : triage, root cause, prévention et un artefact qui modifie le système. Sinon, vous accumulez des histoires, pas des corrections.

Un exemple vécu. En construisant un système de trading, j’ai appris que « globalement correct » n’est pas une métrique rassurante. Un modèle faux 2 % du temps peut tout de même vous mettre en faillite si ces 2 % se concentrent précisément au moment où vous augmentez l’exposition. La leçon se transpose très bien au SaaS : le coût de l’erreur dépend du moment où elle survient, de qui elle touche, et de l’existence – ou non – d’un frein dans le workflow.

La QA n’est pas une taxe. Dans un produit IA-native, c’est ce qui vous permet d’aller plus vite sans transformer vos clients en bêta-testeurs.

Le vrai coût : personnes, temps et risque

Le récit de la démo ne coûte pas cher. La refonte, si.

D’après ce qui casse réellement dans les organisations, budgétez explicitement :

• Personnes : il vous faudra plus qu’« un AI engineer ». Il vous faut un owner data par domaine, quelqu’un capable de construire et maintenir des dispositifs d’évaluation, et un leadership produit capable d’arbitrer – parfois durement – où l’automatisation est acceptable.
• Temps : les premiers prototypes arrivent vite. La valeur qui compose arrive quand les changements de workflow passent en production, quand les gates de QA se durcissent et quand les incitations s’alignent. C’est pour cela que Owner.com parle d’une refonte sur plusieurs années, pas sur un trimestre.
• Risque : vous allez livrer des régressions. Vous allez créer de la confusion chez les clients. Vous allez découvrir que vos champs CRM ne signifient pas ce que tout le monde pense. La seule vraie question : avez-vous mis en place les systèmes de feedback et de confinement avant que les échecs ne passent à l’échelle ?

Règle pratique : si votre initiative IA ne comporte pas une ligne budgétaire pour l’évaluation et le monitoring, ce n’est pas une refonte. C’est une histoire de marketing.

Un plan « taille trimestre » que vous pouvez lancer maintenant

Si vous cherchez un impact ARR sans vous perdre pendant trois ans, abordez cela comme une migration ciblée :

• Choisissez un workflow proche du revenu et définissez entrées, transformation, sorties et unit economics.
• Désignez les data owners des champs qui pilotent les décisions dans ce workflow.
• Choisissez un seul pattern opérationnel (rédiger puis approuver, agir puis auditer, demander puis assister) et tenez-vous-y.
• Construisez une suite de golden tasks avant le déploiement large, pas après.
• Changez une incitation qui, aujourd’hui, récompense le fait de cacher la vérité.

C’est aussi pour cela que beaucoup de « programmes IA » dans les grandes organisations s’enlisent : les achats vous enferment dans des outils avant que vous n’ayez des voies de sortie, et le workflow n’est jamais repensé. J’analyse cette dynamique dans Denmark’s AI Problem Isn’t Models. It’s Procurement Without Exit Ramps.

Mon point de vue : l’IA n’est pas une feature. C’est le travail.

Les entreprises qui prendront de l’avance ne seront pas celles avec la plus jolie chat UI. Ce seront celles qui auront fait de l’IA leur système de production au quotidien : responsabilité claire, handoffs repensés, incitations alignées et QA traitée comme une discipline prête à gérer des incidents.

Si vous traitez l’IA comme une feature, vous continuerez à payer des démos. Si vous la traitez comme le système qui produit des résultats, vous construirez un avantage cumulatif – et votre ARR le reflètera.