Modélisation commerciale de l’IA d’entreprise : trois pilotes réussis ne font pas un portefeuille

Dans beaucoup de groupes, l’IA est arrivée par le bas : un assistant payé sur la carte d’un chef de produit, un pilote lancé par le service client, un script d’automatisation que personne n’a budgété. Deux ans plus tard, le comité de direction découvre une douzaine d’initiatives, trois fournisseurs de modèles et aucun chiffre comparable sur ce que coûte une tâche traitée. Ce qui manque, c’est un modèle qui transforme ces usages et ces pilotes en valeur durable.

C’est le rôle de la modélisation commerciale de l’IA d’entreprise. Estimer un ROI en fait partie, mais l’essentiel est ailleurs. Il s’agit de décider où l’IA crée de la valeur, comment elle s’ajoute aux autres projets, ce qu’elle coûte à faire tourner et quelles règles de contrôle elle impose.

Trois pilotes réussis ne font pas un portefeuille

L’IA ne se gère pas comme un logiciel classique. Un produit SaaS traditionnel repose sur des coûts marginaux stables et un modèle de déploiement connu. L’IA change l’équation.

Chaque requête a un coût de calcul (l’inférence). Il faut surveiller le système, réentraîner les modèles et vérifier leur qualité en continu. Un modèle peut se dégrader avec le temps (la dérive, ou drift). Il faut garder une trace de ses décisions et parfois faire relire ses réponses par un humain. Enfin, tout dépend de la qualité des données. Un modèle brillant sur le plan technique peut donc décevoir sur le plan économique.

L’erreur classique est de gérer l’IA comme une collection de projets. Un assistant interne ici, une automatisation des documents là, un moteur de recommandation dans une troisième équipe. Pris un par un, chaque projet se défend. Ensemble, ils produisent des briques qui ne vont pas ensemble, des coûts en double et des règles différentes partout.

Le calcul est souvent contre-intuitif. Trois pilotes réussis sur trois piles techniques différentes coûtent plus cher à maintenir qu’un seul pilote bâti sur une base partagée. Chacun garde ses jeux d’évaluation, ses règles de supervision et ses factures d’inférence.

Une entreprise ne devient pas « forte en IA » parce qu’elle a réussi trois pilotes. Elle le devient quand elle aligne ses investissements sur sa stratégie, réutilise ses composants, mesure le coût réel de ses flux de travail et forme ses équipes.

D’où la règle : raisonner sur l’ensemble des capacités, pas projet par projet. Chaque projet se juge aussi à ce qu’il laisse derrière lui : des données, des outils de test, un savoir-faire.

Trois natures d’initiatives, trois horizons

La logique de portefeuille classe les investissements selon la valeur attendue et l’horizon de retour.

• Efficacité et automatisation. Des gains rapides : moins de traitement manuel, moins de file d’attente, plus de capacité opérationnelle.
• Expérience et augmentation. L’IA enrichit une décision, accélère l’accès à l’information ou améliore l’usage d’un produit. Le retour est plus lent, mais plus profond.
• Paris stratégiques. Produit IA natif, plateforme sectorielle, modèle propriétaire. L’objectif est un actif difficile à copier.

Ce découpage évite deux pièges symétriques. Exiger de tout un ROI immédiat tue les investissements de long terme. Habiller tout en « pari stratégique » permet d’échapper à la discipline économique.

Concrètement, une carte lisible distingue au moins trois natures d’initiatives, chacune avec son horizon et sa mesure :

La règle de lecture : une initiative d’efficacité sans gain au bout de 6 mois doit être revue. Un pari stratégique s’évalue d’abord aux composants qu’il laisse réutilisables, avant même de générer le moindre revenu.

Pour le budget, un point de départ possible : un comité qui dispose de 3 millions d’euros par an pourrait viser environ 60 % en efficacité, 30 % en expérience et 10 % en paris stratégiques. Les proportions varient selon l’entreprise. Ce qui ne varie pas, c’est que chaque ligne a son propre horizon et son propre indicateur.

L’IA n’amplifie qu’un avantage qui existe déjà

Beaucoup d’entreprises partent d’une mauvaise question : « Où peut-on utiliser l’IA ? » Elle produit une liste très longue et très peu de priorités. La question utile est différente : où l’IA peut-elle amplifier notre avantage spécifique ?

L’avantage de départ décide du type de pari :

• Données propriétaires difficiles à reproduire : les transformer en meilleure décision, personnalisation ou exécution.
• Excellence opérationnelle : réduire la friction, les délais et les erreurs.
• Expertise métier profonde : l’encapsuler dans des copilotes, des systèmes d’assistance ou des modèles spécialisés.
• Qualité de l’expérience client : la rendre plus rapide, plus pertinente, plus fiable.

Prenons un distributeur de pièces industrielles qui dispose de dix ans d’historique de commandes et qui a deux propositions sur la table. La première est un chatbot générique pour son site. La seconde est un modèle de prévision de la demande par dépôt, entraîné sur ses propres données.

Le chatbot se lance en 6 semaines, mais n’importe quel concurrent peut acheter le même. La prévision demande 6 mois, et chaque point d’erreur qu’elle retire se traduit en stock immobilisé que personne d’autre ne peut économiser à sa place. La première proposition est faisable. La seconde multiplie un avantage.

Il ne reste alors que quelques projets qui renforcent vraiment ce qui distingue l’entreprise. Pour les départager, on compare plusieurs scénarios : ce que chacun rapporte, ce qu’il risque, quand il rapporte et ce qu’il laisse de réutilisable. Les scénarios ne donnent pas de vérité absolue. Mais ils obligent à écrire noir sur blanc des hypothèses qu’on peut comparer.

Le ROI se compte par tâche accomplie, pas par appel au modèle

La plus grande source d’illusion reste le ROI calculé sans le coût de service (cost-to-serve). Un projet paraît excellent en démonstration. Il devient moins convaincant quand on ajoute les coûts réels de fonctionnement.

Ces coûts dépassent le calcul de chaque requête. Comptent aussi la quantité de texte envoyée au modèle, la recherche dans les documents et le prix du calcul selon la région. Il faut encore ajouter la surveillance, l’entretien de l’index de recherche, le réentraînement, les jeux de test, la relecture humaine, la gestion des incidents, la sécurité et la conformité.

La bonne unité de compte est donc la tâche accomplie. Le prix d’un appel au modèle ne dit presque rien de la rentabilité d’un flux. Les outils de simulation économique servent précisément à rendre ces coûts visibles et à projeter les courbes de charge quand l’usage augmente.

La formule à garder sous la main :

• Coût par tâche accomplie = inférence par tâche + taux d’escalade × coût du traitement humain + maintenance mensuelle / volume.
• Gain mensuel = volume × coût manuel par tâche, moins volume × coût par tâche accomplie.
• Seuil de rentabilité = le taux d’escalade auquel le gain tombe à zéro.

Exemple chiffré (hypothétique). Une mutuelle reçoit 25 000 demandes par mois. Traiter une demande à la main coûte 6 € HT. L’assistant coûte 0,04 € d’inférence par demande, transmet 30 % des cas à un conseiller et demande 5 000 € HT par mois de maintenance de la base de connaissances.

Le calcul : inférence, 1 000 €. Traitement humain, 7 500 demandes à 6 €, soit 45 000 €. Maintenance, 5 000 €. Total, 51 000 € contre 150 000 € en traitement manuel. Gain : 99 000 € par mois.

Le retournement vient ensuite. Si le taux d’escalade monte à 60 % parce que les demandes se compliquent, le traitement humain passe à 90 000 € et le total à 96 000 €. Le gain tombe à 54 000 €, presque divisé par deux.

Le test inverse confirme où se trouve le levier. Divisez le prix de l’inférence par deux : le gain progresse de 500 €. Faites passer l’escalade de 30 % à 25 % : il progresse de 7 500 €, quinze fois plus. Le levier, c’est le taux d’escalade ; le prix du modèle pèse à peine.

Un détail français change aussi le calcul. Les opérations d’assurance sont exonérées de TVA, donc la mutuelle ne récupère pas les 20 % payés sur ses achats de logiciel et d’inférence. Ses 6 000 € HT de dépenses externes lui coûtent en réalité 7 200 €. Sur ce dossier l’écart est faible, mais sur un projet à marge étroite il décide du vote.

Le même calcul explique pourquoi la marge d’un produit d’IA ressemble rarement à celle d’un logiciel classique. Dans un SaaS, servir un client de plus ne coûte presque rien. Ici, chaque demande entraîne une part d’inférence et, surtout, une part de travail humain qui grandit avec le volume. Les prix de l’inférence baissent d’année en année, mais la supervision humaine et l’adaptation à chaque client ne suivent pas la même pente, et ce sont elles qui pèsent dans la colonne des coûts.

Les 30 % d’escalade restent une hypothèse de départ, tout comme la satisfaction des adhérents face aux réponses automatiques. Les deux se mesurent en production, sur des échantillons relus par des conseillers.

Un cas limite mérite d’être isolé : les demandes qui touchent à l’argent. Une question sur un délai de remboursement tolère une réponse automatique imparfaite. Une contestation de prise en charge, non. Si ces dossiers pèsent 10 % du volume et exigent toujours un conseiller, le taux d’escalade plancher du système est déjà de 10 %, et le gain réaliste se situe sous la moyenne affichée.

Le retour se répartit ensuite en quatre catégories, à séparer pour pouvoir les piloter :

1. Économies directes. Attention : une baisse du temps de traitement libère de la capacité, mais ne réduit pas forcément les dépenses. Il faut préciser quels coûts seront évités ou quelle activité utilisera ce temps.
2. Productivité. Plus de volume traité, moins d’erreurs, des flux plus rapides.
3. Bénéfice stratégique. Moins de risque de conformité, plus de rétention, plus de ventes croisées.
4. Nouveaux revenus. Produits IA natifs, fonctions premium, panier moyen plus élevé.

Une cinquième catégorie se glisse souvent dans les dossiers sans dire son nom : la visibilité. Le chatbot générique du distributeur de pièces se montre bien en comité, mais il n’a ni indicateur ni coût par tâche, et personne ne saura dire en fin d’année s’il a rapporté quelque chose. C’est exactement ce que la carte de portefeuille doit filtrer.

Peu d’entreprises contestent ces dimensions. Beaucoup n’en mesurent qu’une, la plus simple. Elles montrent du temps gagné, sans prouver l’effet sur la fidélisation. Elles parlent de revenus futurs sans dire quel comportement commercial doit changer.

La règle : une initiative n’a pas « amélioré l’efficacité » tant qu’on ne peut pas dire quel flux a accéléré, de combien, avec quelle qualité et à quel coût total.

Un test A/B ne suffit pas à prouver l’effet de l’IA

Encore faut-il prouver que l’effet vient bien de l’IA. Dans l’entreprise, le test A/B n’est qu’un outil parmi d’autres. Il faut aussi des tests sur des données passées, des pilotes avec groupe témoin, des analyses par tâche, des suivis sur plusieurs mois et parfois des méthodes statistiques plus poussées pour isoler la cause.

C’est nécessaire parce que l’IA modifie rarement une seule variable. Elle touche la vitesse, la qualité, la façon de travailler, la charge de supervision et parfois la structure même du flux. Un indicateur superficiel conclut trop vite au succès.

Un protocole sérieux fixe donc à l’avance l’effet attendu, le seuil à partir duquel un résultat compte et la façon de comparer des équipes pilotes et témoins vraiment semblables. La mesure s’alourdit un peu. C’est le prix pour éviter les faux positifs qui coûtent très cher au passage à l’échelle.

Un pilote profite presque toujours de conditions qui disparaissent au passage à l’échelle : une équipe volontaire, des cas triés, quelques semaines d’attention de la direction. Si un comité reçoit 10 pilotes et que les 10 « marchent », il mesure probablement l’adoption et l’enthousiasme des équipes pilotes. La valeur reste à démontrer.

Indicateur et garde-fou. Pour l’assistant de la mutuelle, l’indicateur principal est le coût par demande résolue. Le garde-fou est le taux de réouverture : si les dossiers clos par l’IA sont rouverts plus souvent que ceux clos par un conseiller, le gain est fictif. Règle de départ raisonnable : suspendre l’extension si l’écart dépasse 2 points pendant 4 semaines consécutives.

Découvrir, systématiser, puis seulement passer à l’échelle

Quand une initiative IA échoue, l’idée de départ est rarement seule en cause. Le problème vient d’une mauvaise transition entre expérimentation et industrialisation. La feuille de route se pense donc par étapes.

Découverte. On identifie les flux compatibles avec l’IA, on construit des preuves de valeur, on cartographie la qualité des données. On cherche à apprendre. Un horizon raisonnable par hypothèse est de 8 à 12 semaines, avec un critère d’arrêt écrit avant le lancement : « si l’escalade dépasse 40 % en semaine 10, le pilote s’arrête ». Un pilote sans critère d’arrêt n’échoue jamais, et donc n’apprend rien.

Systématisation. L’organisation construit une base commune : un registre central des modèles, des briques réutilisables, des alertes quand un modèle se dégrade, des tests de qualité communs, des règles de contrôle et la sécurité. Sans cette couche, chaque nouveau projet coûte autant qu’un premier projet. Avec elle, chaque nouveau cas d’usage s’appuie sur un socle commun que l’on sait exploiter.

Passage à l’échelle. L’IA entre dans plusieurs divisions, dans des flux plus critiques, parfois dans des produits IA natifs. Beaucoup d’organisations tentent de sauter du pilote au déploiement massif. Elles découvrent alors que le budget était là et que l’organisation manquait.

Un signal simple que la systématisation fonctionne : le troisième cas d’usage coûte nettement moins cher que le premier. S’il coûte autant, rien de réutilisable n’a été construit.

Trois symptômes signalent une feuille de route cassée :

• Chaque équipe choisit son fournisseur de modèles. En un an, on compte cinq contrats et aucun coût comparable.
• Aucun pilote n’est arrêté. Si rien n’a été fermé en 12 mois, le comité se contente d’empiler.
• L’extension est demandée par le fournisseur. Elle arrive avec une offre commerciale et sans taux d’escalade mesuré.

Ce que chaque métier doit savoir faire

Le facteur limitant tient plus souvent à la capacité de l’organisation qu’à la qualité du modèle. L’écart se voit dès le premier incident en production. Une entreprise peut acheter de la technologie et travailler avec d’excellents partenaires. Sans capacités internes, tout reste suspendu à quelques experts ou prestataires.

Produit. Les product managers doivent comprendre les limites des modèles, la qualité des données, l’économie de l’inférence, l’évaluation et la gouvernance. Sans être data scientists, ils doivent savoir transformer un problème métier en problème opérable. Une grille remplie par chaque PM puis relue par un pair de l’équipe data suffit souvent à objectiver les écarts, par exemple sur la lecture d’un rapport d’évaluation.

Le calcul de la mutuelle donne le prix de cette compétence. Chaque point d’escalade représente 250 demandes par mois traitées à la main, soit 1 500 € de plus. Un PM qui sait lire un rapport d’évaluation et repérer les questions que la recherche documentaire traite mal fait baisser ce taux ; celui qui ne le sait pas le découvre dans la facture.

Ingénierie et MLOps. Il faut que le modèle réponde vite même avec beaucoup de demandes, le surveiller, repérer quand il se dégrade, le réentraîner automatiquement et faire travailler plusieurs modèles ensemble. Sans cela, même un bon modèle devient fragile.

Évaluation. La qualité d’un système IA ne se maintient pas par intuition. Elle dépend de jeux d’évaluation solides, de taxonomies d’erreurs, de seuils de performance et de tests de biais ou d’hallucination.

Les organisations avancées institutionnalisent l’apprentissage : académies internes, laboratoires, guildes, bases de connaissances, simulation de scénarios. La dépendance à quelques personnes recule, et l’IA devient une capacité d’entreprise.

Gouvernance et capacité partagée : par où commencer ?

En IA, la gouvernance pèse directement sur la viabilité du modèle économique. Négliger la traçabilité, la documentation, la supervision humaine ou le suivi des versions fait gagner du temps au début. Ce gain est presque toujours temporaire. Plus les usages se multiplient, plus les risques de dérive, d’erreur et de perte de confiance augmentent.

Une gouvernance utile couvre plusieurs points : les données, la documentation des modèles, la possibilité d’auditer, l’évaluation du risque, le suivi des versions et la relecture humaine. Elle prévoit aussi les risques concrets. Hallucinations, biais, dérive, confidentialité, résidence des données, pics de charge et explosion des coûts sont des variables qui changent le pricing, le design du produit et le mode de déploiement.

Pour la mutuelle, la contrainte est plus lourde qu’ailleurs : les demandes d’adhérents touchent souvent à la santé, une catégorie de données sensibles au sens du RGPD, sous le contrôle de la CNIL. Ce coût de conformité entre dans la formule du coût par tâche : relégué en note de bas de page, il fausse le calcul.

La supervision humaine a son propre piège : le biais d’automatisation, cette tendance à valider ce que propose la machine. Il grandit avec le volume et avec la fiabilité apparente du système, car plus l’assistant a raison, moins on relit ses réponses. Un conseiller qui approuve 200 réponses par jour sans les lire ne supervise rien. Mieux vaut le vérifier avec des échantillons contenant des erreurs connues.

Réunies, ces briques forment un système : positionnement stratégique, architecture de capacités, modèle financier avec coût de service et réentraînement, gouvernance, compétences et protocole d’expérimentation. Séparées, elles ne livrent que des fragments de vérité.

Reste la décision par laquelle ouvrir la feuille de route : choisir la capacité partagée qui manque le plus. Pour la trouver, reprenez la carte des initiatives et notez ce que chacune a dû construire seule : un jeu d’évaluation, un pipeline de détection de la dérive, une base vectorielle, une règle de supervision. L’élément qui revient le plus souvent est le candidat naturel à mutualiser.

Ce choix a deux effets mesurables. Le coût de service des initiatives qui l’adoptent baisse, puisque chacune cesse de maintenir sa propre version. Et la prochaine initiative démarre plus vite, avec un cadre d’évaluation déjà validé. Le pilote suivant se choisit ensuite dans la ligne du portefeuille où l’avantage est le plus net, avec un indicateur fixé avant le lancement et un coût de service estimé pour au moins deux volumes.

Tout cela suppose une certaine taille. Avec deux ou trois initiatives, la mutualisation rapporte peu, et une plateforme commune devient vite une bureaucratie qui retarde le premier gain. En dessous de 3 initiatives actives, investissez d’abord dans la mesure (indicateur et coût par tâche). Dans un groupe où chaque division a déjà ses fournisseurs, la capacité commune la plus utile est souvent la couche d’évaluation, plus facile à imposer qu’une pile technique unique.

Un indicateur montre d’un cycle budgétaire à l’autre si la séquence tient : le délai entre la validation d’un pilote et son premier usage en production raccourcit, parce que l’évaluation, la gouvernance et une partie des données n’ont plus à être reconstruites.