+190 XP

Cas d'usage GenAI en entreprise et création de valeur

En 2023, une banque de détail mondiale a lancé 47 proofs-of-concept d'IA générative en neuf mois. Dix-huit mois plus tard, exactement trois étaient passés en production. Les 44 autres sont morts dans ce que le CDO de la banque appelle aujourd'hui « le cimetière des démos », un disque partagé rempli d'applications Streamlit qui ont ébloui un comité de pilotage une fois et n'ont plus jamais été ouvertes. Le postmortem a révélé le schéma : **presque tous les projets morts avaient été retenus parce qu'ils étaient *techniquement intéressants* ou *visibles par le comex***, pas parce que quelqu'un avait modélisé où la valeur allait réellement atterrir ni qui en serait propriétaire après les applaudissements.

C'est le problème central du CDO avec la GenAI. La technologie démontre magnifiquement et ne produit presque rien sans une sélection disciplinée. Votre rôle n'est pas de mener des expérimentations, vos fondamentaux ont couvert cela. Votre rôle est de construire un portefeuille qui capitalise. Cela exige un autre jeu de jugements que n'importe quelle initiative data précédente, parce que la GenAI inverse plusieurs hypothèses sur lesquelles vous fonctionnez.

Pourquoi la GenAI casse vos instincts de priorisation actuels

Vous savez déjà prioriser des projets analytics : estimer la valeur, estimer le coût, pondérer par la faisabilité, séquencer par dépendance. La GenAI viole discrètement trois des hypothèses qui sous-tendent cette méthode.

Le coût marginal n'est pas nul, il est variable et souvent imprévisible. Un dashboard BI traditionnel coûte la même chose pour servir 10 ou 10 000 utilisateurs. Une fonctionnalité GenAI coûte au token, à l'appel, à la requête de retrieval. Un outil de résumé qui paraît bon marché dans un pilote à 50 utilisateurs peut devenir une ligne mensuelle à six chiffres à l'échelle de l'entreprise, surtout si vous l'avez construit sur un modèle frontier où vous payez une prime pour du raisonnement dont vous n'avez pas besoin. Les unit economics doivent faire partie de la sélection des cas d'usage *dès le premier jour*, et non être une réflexion tardive au moment du passage à l'échelle.

La précision est probabiliste, donc l'équation de valeur comporte un terme de coût d'erreur que vous ne pouvez pas ignorer. La bonne question n'est jamais « est-ce que ça marche ? ». Ça marche assez souvent pour faire une démo. La question est : *combien coûte une mauvaise réponse, et qui la détecte ?* Un outil GenAI qui rédige des textes marketing a un coût d'erreur trivial, un humain les relit, et le pire résultat est un brouillon jeté. La même capacité appliquée au résumé de l'historique médicamenteux d'un patient a un coût d'erreur catastrophique. Même technologie, profil de valeur radicalement différent, entièrement déterminé par la conséquence de l'erreur.

Le moat est rarement le modèle. N'importe qui peut appeler la même API que vous. L'avantage durable vient de ce que vous construisez autour du modèle : données propriétaires, évaluation spécifique au domaine, intégration dans le workflow, et le feedback accumulé qui vous permet d'ajuster et de router intelligemment. Quand vous évaluez un cas d'usage, demandez-vous quelle partie un concurrent *ne pourrait pas* répliquer d'ici le trimestre prochain. Si la réponse est « aucune », vous construisez une fonctionnalité, pas un actif.

Gardez ces trois bascules en tête, coût variable, pondération par le coût d'erreur, et localisation du moat, car chaque framework ci-dessous s'appuie dessus.

Un framework à deux axes pour séparer la valeur du théâtre

Placez chaque cas d'usage candidat sur deux axes. Le premier est la concentration de valeur : ce cas d'usage attaque-t-il un pool de coûts ou de revenus large et mesurable, ou saupoudre-t-il de petites commodités à travers l'organisation ? Le second est la tolérance à l'erreur : combien coûte un output erroné, et à quel point ce coût est-il contenu ?

Cela produit quatre quadrants, et chacun exige un jeu différent.

Valeur élevée, tolérance à l'erreur élevée, commencez ici

C'est le terrain fertile, et c'est là que la plupart des entreprises *ne commencent pas* parce que c'est moins glamour que les sujets risqués. Pensez à l'assistance aux agents de centre de contact qui rédige des réponses qu'un humain envoie, à la complétion de code pour les développeurs, à l'extraction de clauses contractuelles avec un juriste dans la boucle, ou à la génération de premiers jets pour du travail de connaissance à fort volume. Le pool de valeur est réel et large ; l'humain dans la boucle absorbe le coût d'erreur.

La référence classique est l'assistant de service client de Klarna, dont l'entreprise a dit qu'il traitait l'équivalent du volume de centaines d'agents. Ce qui l'a fait fonctionner n'était pas la sophistication du modèle, c'est que le cas d'usage se situait pleinement dans ce quadrant : un volume de tickets énorme et mesurable (valeur concentrée) avec des chemins d'escalade humaine et un domaine borné (coût d'erreur contenu). C'est la forme d'un premier pari.

Valeur élevée, faible tolérance à l'erreur, construisez, mais avec l'architecture adaptée

Réconciliation financière autonome, aide à la décision clinique, souscription automatisée. Le gain est important mais une mauvaise réponse est coûteuse ou dangereuse. Ces cas ne sont *pas* interdits, c'est là que les plus grands avantages finissent par se trouver, mais ils exigent d'investir dans des garde-fous, des harnais d'évaluation, des points de revue humaine, et souvent une conception de « routage par confiance » où le système n'agit de façon autonome qu'au-dessus d'un seuil de certitude calibré et escalade tout le reste. **Séquencez-les *après* avoir développé le muscle organisationnel dans le quadrant plus sûr**.

Faible valeur, tolérance à l'erreur élevée, le cimetière des démos

Le bot interne « discutez avec notre wiki ». Le générateur de comptes rendus de réunion auquel personne ne fait assez confiance pour sauter la réunion. Ces projets sont peu coûteux à construire, sans risque à exploiter, et faciles à démontrer, ce qui est précisément pourquoi ils métastasent. Ils génèrent de l'activité et consomment de la roadmap sans faire bouger un chiffre que quelqu'un rapporte au board. Tuez-les vite ou intégrez-les dans une logique de plateforme, mais ne les laissez jamais structurer votre portefeuille.

Faible valeur, faible tolérance à l'erreur, évitez

Risque élevé, faible récompense. Si un cas d'usage atterrit ici, la seule action correcte est de ne pas le faire, ou de repenser le workflow pour que le coût d'erreur baisse avant d'y toucher.

La discipline que ce framework impose : *vous ne justifiez jamais un cas d'usage sur la seule faisabilité.* « On sait le construire » n'appartient à aucun quadrant. La valeur et le coût d'erreur sont les seuls critères d'admission.

Noter le portefeuille : des quadrants à une liste classée

Les quadrants trient ; ils ne classent pas. Pour séquencer un portefeuille, traduisez chaque candidat survivant en quatre chiffres que votre CFO et votre board reconnaîtront.

1. Pool de valeur ($) : le coût ou le revenu adressable que le cas d'usage touche, multiplié par un taux de capture réaliste. Soyez brutal sur la capture, un outil qui fait gagner 30 minutes par jour à chaque analyste ne crée de la valeur que si ce temps se convertit en production ou en effectifs, pas s'il s'évapore en pauses café plus longues. Modélisez la valeur *réalisée*, pas la valeur théorique.

2. Unit economics à l'échelle ($ par transaction) : estimez le coût par output utile au volume projeté, en utilisant le modèle que vous déploieriez réellement, pas le modèle phare utilisé pour le prototype. La plupart des cas d'usage en production tournent très bien sur des modèles plus petits ou open-weight une fois le retrieval et le prompting ajustés.

3. Exposition au coût d'erreur : le coût attendu d'un output erroné, probabilité d'erreur fois conséquence fois volume, moins ce que votre couche de revue intercepte. C'est ici que vous forcez la conversation sur la confiance avant de construire.

4. Contribution au moat : ce cas d'usage capitalise-t-il ? Génère-t-il des données de feedback propriétaires, approfondit-il l'ancrage dans un workflow, ou construit-il une capacité de plateforme réutilisable ? Un cas d'usage à valeur modeste qui construit une plateforme réutilisable de retrieval et d'évaluation peut passer devant un cas à valeur plus élevée mais isolé.

Un simple score pondéré rend les arbitrages explicites et défendables en instance de gouvernance :

priority_score = (
    value_pool * capture_rate          # valeur annuelle réalisée ($)
    - annual_run_cost                  # tokens + infra à l'échelle ($)
    - expected_error_cost              # P(erreur) * conséquence * volume ($)
) * moat_multiplier                    # 1.0 de base, jusqu'à ~1.5 pour la construction de plateforme

Le résultat n'est pas un montant précis, traitez-le comme un instrument de classement. Sa vraie puissance est procédurale : il oblige la personne qui défend son projet fétiche à énoncer son taux de capture et son coût d'erreur à voix haute, devant ses pairs. La moitié du cimetière des démos n'aurait jamais été creusée si les sponsors avaient été contraints de nommer un taux de capture.

How to Build a Generative AI Strategy for the Enterprise

Watch on YouTube

Une dernière règle de séquencement : orientez vos deux ou trois premiers paris en production vers des cas d'usage qui partagent l'infrastructure. Si votre outil de centre de contact classé premier et votre outil d'analyse de contrats classé troisième ont tous deux besoin d'un pipeline de retrieval documentaire et d'un harnais d'évaluation, les construire ensemble rend le second bien moins cher et votre moat de plateforme commence à capitaliser. La logique de portefeuille bat la logique de projet précisément ici.

Vérification des acquis

1. Selon la leçon, pourquoi la GenAI casse-t-elle la méthode traditionnelle de priorisation analytics consistant à estimer valeur, coût et faisabilité ?

2. La leçon oppose l'usage de la GenAI pour rédiger des textes marketing à celui du résumé de l'historique médicamenteux d'un patient. Quel concept central cette comparaison illustre-t-elle ?

3. Quel est le rôle central du CDO face à la GenAI, tel que la leçon le formule ?

CHOIX MULTIPLES

4. Sélectionnez TOUTES les hypothèses de la priorisation analytics traditionnelle que la leçon dit être violées par la GenAI.

Sélectionnez toutes les réponses correctes.

CHOIX MULTIPLES

5. Sélectionnez TOUTES les affirmations qui reflètent le raisonnement de la leçon sur les raisons pour lesquelles tant de proofs-of-concept GenAI ont fini au « cimetière des démos ».

Sélectionnez toutes les réponses correctes.

Gouverner le portefeuille pour que la valeur atterrisse vraiment

Bien sélectionner vous donne une bonne roadmap. Réaliser la valeur exige trois mécanismes de gouvernance que la plupart des organisations ajoutent trop tard.

Stage-gate avec des critères d'arrêt définis en amont. Chaque cas d'usage progresse par pilote → production limitée → passage à l'échelle, et *chaque gate a un seuil numérique fixé avant le début des travaux.* Non pas « la démo est-elle convaincante » mais « atteint-il X de précision sur le jeu d'évaluation mis de côté ET reste-t-il sous Y de coût par transaction ET montre-t-il une adoption mesurable par les utilisateurs cibles ». La banque de notre introduction n'avait aucun critère d'arrêt, donc rien ne mourait jamais à temps, les projets traînaient comme des zombies, consommant du budget sans rien produire. Des critères d'arrêt engagés à l'avance sont l'antidote à la paralysie par coûts irrécupérables. La volonté de tuer est elle-même une capacité concurrentielle : elle libère du capital pour le concentrer sur les gagnants.

L'évaluation comme actif de premier rang, pas comme réflexion tardive. Pour chaque cas d'usage en production, il vous faut un jeu d'évaluation spécifique au domaine, une collection curée d'inputs avec des outputs de référence, notés en continu. C'est là que votre moat propriétaire vit physiquement. Deux concurrents utilisant le même modèle de fondation se différencient entièrement par la qualité de leur harnais d'évaluation, parce que c'est ce qui vous permet de changer de modèle, d'ajuster les prompts et de détecter les régressions sans crainte. Traitez vos jeux d'évaluation comme vous traitez vos données de référence : avec un propriétaire, un versioning et une gouvernance. Quand un nouveau modèle sort, l'organisation dotée d'un harnais d'évaluation solide sait en une journée s'il faut basculer ; celle qui n'en a pas devine.

L'attribution de valeur câblée avant le lancement. Décidez *comment vous allez prouver* qu'un cas d'usage a créé de la valeur avant de le livrer. Cela signifie instrumenter la baseline dès maintenant, temps de traitement actuels, cycle actuel du brouillon à la publication, taux d'erreur actuels, parce qu'une fois l'outil en production vous ne pouvez plus mesurer le monde sans lui. Quand c'est possible, mettez en place un vrai holdout : un groupe de contrôle qui n'a pas l'outil. Les affirmations de GitHub sur la productivité de son assistant de code ont pesé précisément parce qu'elles étaient appuyées par une mesure contrôlée, pas par des impressions. Les vagues « gains d'efficacité » sont décotés par tous les CFO qui ont déjà entendu la formule ; un avant-après défendable avec un groupe de contrôle est ce qui débloque le tour de financement suivant.

Ces trois mécanismes transforment un portefeuille d'une slide en une machine. Les stage-gates garantissent que le capital va vers les gagnants. Les harnais d'évaluation construisent le moat technique. L'attribution de valeur construit le moat de *crédibilité* qui maintient le financement du programme par le board pendant le creux inévitable après la retombée de l'enthousiasme initial.

Les CDO qui paraîtront visionnaires dans trois ans ne seront pas ceux qui auront mené le plus d'expérimentations. Ce seront ceux qui auront été impitoyables sur les quatre quadrants, qui auront forcé les taux de capture à sortir au grand jour, qui auront construit une infrastructure partagée entre leurs meilleurs paris, et qui auront pu prouver, avec un groupe de contrôle et sans rougir, exactement quelle valeur chaque système en production a créée.

Points clés

  • L'admission exige valeur et coût d'erreur, jamais faisabilité. « On sait le construire » ne justifie rien. Placez chaque candidat sur les axes concentration de valeur et tolérance à l'erreur, et commencez par le quadrant valeur élevée / tolérance élevée où un humain absorbe le risque.
  • Modélisez les unit economics à l'échelle de production dès le premier jour, avec le modèle que vous déploieriez réellement, pas le modèle frontier utilisé pour le prototype. Un outil bon marché sur un pilote à 50 utilisateurs peut coûter six chiffres par mois à l'échelle.
  • Obligez chaque sponsor à énoncer un taux de capture et une exposition au coût d'erreur à voix haute. La vraie valeur de l'exercice de notation est procédurale : il tue les projets fétiches avant qu'ils ne consomment la roadmap.
  • Séquencez pour l'infrastructure partagée. Orientez vos premiers paris vers des cas d'usage qui réutilisent le même pipeline de retrieval et le même harnais d'évaluation, pour que votre moat de plateforme capitalise au lieu de se fragmenter.
  • Fixez des critères d'arrêt numériques et instrumentez la baseline avant de livrer. Des gates engagés à l'avance battent la paralysie par coûts irrécupérables, et un avant-après contrôlé est la seule affirmation de valeur que votre CFO ne décotera pas.

À faire, tiré de cette leçon

Ces actions sont compilées dans le plan d'action du rôle.

  • Modéliser les unit economics de l'IA à l'échelle de la production dès le premier jour
Voir le plan d'action complet →