Pourquoi une démo IA réussie condamne ton projet

Plus ta démo a été impressionnante, plus ton projet a de chances de mourir. Je sais, ça paraît absurde et pourtant ta démo était propre, la direction a applaudi et le budget est tombé. Mais Garner a mesuré que 7 projets sur 10 ne rapporteraient jamais ce qu'ils ont coûté. Un POC qui marche ne prouve rien. Après plus de 20 systèmes de connaissances IA livrés en production et 50 [musique] analysés en coaching, je vais te montrer pourquoi.

Aujourd'hui, on va adresser une des plus grosses réalités euh du marché actuellement mais depuis l'année dernière, c'est quelles sont réellement les chances de succès de tous ces fameux projets IA qui ont été testés cette année, qu'on appelle aussi les POC pour preuve de concept. Et donc on va voir que si ton POC a marché, c'est probablement une mauvaise nouvelle car en réalité un POC réussi ne prédit absolument rien sur ce qu'il va se passer en production.

En fait, il faut s'imaginer qu'il est truqué par construction. Pas parce que c'est malhonnête, pas parce qu'on a envie de faire croire que quelque chose fonctionne alors que ça fonctionne pas. C'est juste qu'il fonctionne de manière en fait à montrer que ça peut marcher et pas que ça peut marcher en conditions réelles. Sauf que aujourd'hui, ça c'est une cause énorme en fait de projets qui ne démontreront jamais la valeur métier réel en conditions opérationnelles, mais également qui auront très souvent des problèmes de retour sur investissement. Et le but de cette vidéo, c'est vous montrer pourquoi et comment vous pouvez l'éviter dès le début.

Alors, première petite question. Est-ce que tu as déjà vu un POC rater sa démo ? Même quand une démo fait son effet waouh et qu'elle marche très bien, ça ne vous dira jamais que le projet sera une réussite ou que ça marchera en production car un POC est construit pour réussir. C'est sa définition même. On veut savoir est-ce que ça peut fonctionner ? Et il y a une grosse différence entre choisir et tester les 50 documents les plus appropriés et les plus propres pour son cas d'usage que de travailler en fait avec les 12000 documents de son serveur partagé. parce que c'est là où on va avoir les vrais problèmes et c'est là où nos systèmes de connaissance IA vont avoir besoin d'être les plus robustes. Donc ce que vous aurez fait sur 50 documents ne veut pas dire que ça peut marcher sur les 12000. Premier point très important.

Deuxième point c'est que c'est souvent à base de questions préparées à l'avance, celle qui marche bien pour la démo ou qui sont testées par l'équipe projet des gens qui savent exactement quoi demander puisque c'est en général eux qui ont construit le cahier des charges ou en tout cas qui ont demandé qu'est-ce que le système devrait être capable de faire. Le point commun, c'est que on est hors de tout workflow réel dans une belle interface de démo. Et là, on pourrait imaginer l'image que notre POC, c'est un peu comme un décor de cinéma, c'est-à-dire qu'on a une super jolie façade, mais derrière, il y a rien du tout.

De manière générale, et ça, j'en parle dans d'autres vidéos, nous on est contre l'époque. Pourquoi ? parce que on part du principe qu'un POC ne démontre rien particulièrement en et nous ce qu'on va préférer faire c'est ce qu'on appelle des preuves de valeur montrer dans une phase de test ou une phase pilote assez courte qu'on peut aller récupérer un ROI en mesurant les bons indicateurs et en regardant la valeur réelle en conditions opérationnell se confronter aux questions et à la data de manière non préparée. qu'on peut préparer des choses avec un échantillon, mais on va le tester sur un échantillon de données et sur des questions qui étaient hors de notre corpus de mise en place. Et ici, on va venir scorer notre système avec les bons indicateurs. Là, ce qu'on veut, c'est de la data, quelque chose qui nous montre que déjà notre système peut être fiable même sur des choses sur lesquelles il a pas été préparé. Et enfin, on va aussi faire des en simulation en conditions opérationnelles. Ça c'est super important. On veut savoir comment le système va réagir en condition réelles.

Ce qu'il faut retenir, c'est que le POC ne teste pas ton système. Il teste le scénario de démo. La façade est magnifique et derrière il y a rien et c'est tout à fait normal, c'est ce qu'on lui demande. Donc le réflexe aujourd'hui, c'est de vous demander une seule chose ou de demander la personne qui vous fait votre système de connaissance ou votre poia ou je ne sais quoi de refaire la même démoci de documents que vous aurez choisi qu'il n'avait pas qui sont dans le même cas d'usage et avec des questions que les équipes n'ont pas écrites. Et là, vous verrez très rapidement la réaction de la personne ou pas, à quel point le système peut passer à l'échelle ou pas et le savent ou pas.

Le jour où on branche la vraie data, c'est là où ça devient en général le vrai bordel. La prode n'est pas le POC en plus gros, c'est un changement nature complet. Et c'est là où l'effet de levier peut être à double tranchant car LIA, elle va pas arranger le bordel, elle va l'amplifier et le mettre à l'échelle. Donc pour ça, je vais prendre un exemple. On va se dire que on a un commercial, lui il est dans son CRM, il a sa fiche client. Donc pour lui, c'est un client puisqu'il a établi une relation commercial. Par contre, il sait que une fois qu'il enverra la commande pour d'autres services comme par exemple la finance, eux ne considèrent pas que c'est un client car pour eux un client est quelqu'un qui a un contrat actif. Alors, c'était un ancien client. Donc déjà, on a deux définitions différentes de clients. Ici, c'est quelqu'un avec qui on a une relation commerciale qui a déjà acheté chez nous. Ici, c'est quelqu'un qui a un contrat actif. Le commercial, lui, humain, il le sait. Donc quand il va envoyer l'information aux autres services, il va peut-être parler d'un prospect ou il va peut-être mentionner le fait que c'est un ancien client ou je ne sais quoi, peu importe. Dans tous les cas, il n'a pas besoin de chercher, il n'a pas besoin de réfléchir. Il sait directement à la connaissance client que on n' pas la même définition et donc quand il enverra l'information, il ne fera pas l'erreur. Ça c'est ce qu'on appelle un rework et ça c'est invisible dans ce cas-là et c'est quasiment instantané et très rapide.

Quand on va demander à Lia de faire ça mais fois 1000 actions, peut-être qu'on va passer euh là on sera pas à 10 mais on sera à 700 rework parce que Lia elle elle va pas faire la différence entre quelle est la bonne définition du client entre ce qu'il y a dans le CRM ou ce qu'il y a côté finance. Elle va prendre l'information, elle va voir qu'il y a marqué client. Pour elle, elle va définir que c'est client et elle va envoyer ça directement aux autres services avec cette information là. Donc là en l'occurrence il y aura pas de rework invisible, ça sera visible. Et donc euh là, les erreurs seront amplifiées. Ce qu'il faut garder en tête, c'est que la bonne data devient meilleure avec Lia, la mauvaise devient plus problématique. Et il y a pas que les bonnes choses qui s'automatisent, un workflow cassé s'automatise aussi et amplifie les problèmes. Il faut pas dire que c'est ta boîte ou votre boîte qui est mal gérée. C'est un peu le cas de toutes les boîtes et c'est normal tant qu'on fait pas ce travail sur la data. Et le gros paradoxe dans lequel bien évidemment on veut pas tomber, c'est de payer quelqu'un pour accélérer et automatiser les tâches qui font perdre du temps et finir avec un amplificateur de bordel.

Là, le travail à faire, il est assez simple. Il faut s'assurer soit qu'on a unifié notre logique métier et nos définitions euh directement dans notre donnée. Si c'est trop compliqué ou que ce n'est pas possible, il faut donner la logique à notre système IA pour qu'il puisse la reproduire.

Alors, qu'est-ce que font les 28 % des projets qui obtiennent un ROI parmi ceux qui arrivent en production ? Donc ça fait quand même beaucoup d'échecs. Si on a déjà qu'à peu près 15 % d'époque qui sont validé et après parmi les choses qui sont validées, qu'on a qu'une partie qui démontre un héroï, ça commence à faire beaucoup de pertes. Donc moi ce que je vous propose c'est pas de faire un meilleur po mais c'est de commencer à faire des pauves, des preuves de valeur.

Alors là c'est quoi la différence ? Un POC demande est-ce que la techno marche ? Ça c'est assez clair depuis pas mal de temps maintenant. au moins depuis l'année dernière, la techno marche il a générative, fonctionne, elle apporte de la valeur. Là où le POV va demander est-ce que ça produit de la valeur mesurable chez moi dans mon entreprise pour mes cas d'usage ? Et ça c'est la seule question qui compte. C'est la seule question que le POC ne peut structurellement pas poser.

Et donc là on va retrouver un petit résumé. Ben le POC ça montre est-ce que la techno marche ? Ça aujourd'hui on s'en fout. Ce qu'on veut savoir, c'est est-ce que ça produit de la valeur mesurable chez moi ? On veut éviter de ne travailler que sur de la donnée statique bien travailler, bien nettoyé sur 50 documents choisis. On veut pouvoir voir comment ça peut se comporter sur de la vraie data. On veut quelque chose qui puisse le démontrer. On sera forcément sur un échantillon réduit, sinon ça reviendrait à mettre un produit en production. Et par contre, il y a différents façons de terster échantillon réduit pour éviter en fait de venir polluer un petit peu toutes les données de test.

Ensuite, ce qu'on veut éviter aussi, c'est que seuls les équipes projet, soit les testeurs pendant cette phase de test, on veut des vrais utilisateurs, ceux qui seront vraiment dans le pool représentatif de ceux qui vont l'utiliser et quelles seront exactement les questions qui poseront au quotidien quand on sera en plein travail, quand il y aura pas mal de choses à faire en situation réelle pour savoir exactement comment ils vont poser ces questions et avoir quelque chose plus proche de la réalité. Ici, on veut pas simplement un ressenti euh d'un effet waouh, le le c'est "C'est trop bien, il nous faudrait la même chose", et cetera. Ici, on veut un verdict, on veut un scoring en face d'un référentiel pour savoir OK, mon système, il est fiable à combien de pourcent et on prend des décisions sur de la data et pas sur un simple ressenti.

Ici, malheureusement, ben là, on va finir au cimetière d'époque très souvent, enfin en tout cas dans plus de 80 % des cas. Et là, on a déjà des fondations pour aller vers la production. Et même si on obtient un logo, c'est déjà une bonne décision parce que vaudra mieux avoir perdu 3 semaines de test sur quelque chose en conditions réell que c'est pas viable et tuer le projet très vite avant qu'il ait coûté trop cher et qu'il a mobilisé trop de monde. On aura déjà gagné de l'argent plutôt que d'avoir l'illusion que notre projet était bon et repartir pour 3 mois de plus et commencer à ouvrir un gouffre financier.

À retenir, c'est que un POC réussit, on le jette, un pauvre réussit, on le déploie. Et donc ce que vous pouvez vous dire en en cadrage, c'est que la démo finale, elle tourne sur un échantillon de data. non curé, donc la solution n'a pas vu par exemple, ça peut être un bon test, que les testeurs seront des utilisateurs finaux, pas l'équipe projet et que le succès se mesure contre un cahier de recette qui permet objectivement de mesurer le système et pas simplement en ressenti. Ceux qui refusent de se conformer à ces trois règles-là, je pense que vous avez déjà votre réponse et pour moi ça sent pas très bon.

En résumé, comme j'ai déjà dit deux trois fois dans la vidéo, le POC ne prouve pas que ton projet marche, il prouve que la démo marche. Et c'est cette nuance-là qui va fixer le prix de ton budget IA et qui va éviter de perdre de l'argent ou diluer ton HOI. [grognement]

Ce qu'il faut savoir, c'est que 28 % des projets validés en POC démontrent bien un ROI, que 72 % donc ne jamais de ROI et la démarche I donc ne fonctionne pas et que aujourd'hui 74 % de la valeur de l'IA est captée par ces 28 %. Donc autant commencer à faire comme eux.

Maintenant que tu vois bien la différence entre un système IA qui peut aller en production et un système IA qu'on sait qu'il ne pourra pas aller en production dès le début, tu veux peut-être savoir comment on le construit. Et si tu veux savoir comment créer les bonnes fondations pour un système IA d'entreprise qui marche réellement, j'ai fait une vidéo complète là-dessus. On se retrouve là-bas. Yeah.