Dans l’IA générative, pourquoi voit-on autant de projets qui ne dépassent pas le stade du POC ?
C’est effectivement le grand paradoxe actuel. Jamais les outils n’ont été aussi puissants, et pourtant le taux d’échec reste massif. Si autant de projets stagnent au stade du POC, c’est avant tout faute de cadrage initial. Le réflexe dominant consiste à se précipiter vers une solution technique — LLM, agents — avant même d’avoir stabilisé l’usage réel. Deux raisons majeures expliquent cela : d’une part, on démarre trop souvent avec un besoin mal défini, sans avoir identifié le problème véritablement douloureux au quotidien, ce qui rend l’outil non essentiel pour l’utilisateur ; d’autre part, il manque une boussole, des KPI clairs permettant de déterminer si le projet est un succès. Chez Niji, nous avons la conviction qu’il faut cadrer rigoureusement chaque projet avant d’écrire la moindre ligne de code — sans quoi l’échec est prévisible.
Qu’est-ce qui pousse les équipes à vouloir aller très vite sur les POCs, parfois au détriment de l’usage ?
On se retrouve fréquemment face à une dynamique top-down déconnectée du terrain. Le besoin est identifié par le top management, qui perçoit — à juste titre — un enjeu stratégique majeur, mais qui veut avancer trop vite pour montrer que l’entreprise est dans la course à l’IA. On privilégie alors l’effet « wow ». Le piège est de vouloir un outil parfait, ultra-complet, dès le premier essai — ce qui n’est pas la bonne recette dans l’environnement technologique actuel. Il faut au contraire avancer par phases : poser d’abord un socle minimal mais solide, libérer des fonctionnalités de manière incrémentale, et élargir progressivement le cercle des utilisateurs en commençant par les plus engagés. L’idéal ne doit pas être un préalable au lancement.
Tu insistais beaucoup sur l’immersion terrain, le « vis-ma-vie ». Pourquoi est-ce devenu indispensable dans les projets d’IA générative ?
C’est indispensable précisément parce que l’IA générative est un outil qui s’insère directement dans le quotidien des utilisateurs. Contrairement au machine learning classique, qui automatise des processus en arrière-plan, elle assiste un humain dans ses tâches. Tout l’intérêt de l’immersion terrain est de voir ce que l’utilisateur ne verbalise pas. Se cantonner à des entretiens en salle de réunion, c’est passer à côté de la réalité : on ne voit pas le collaborateur jongler entre trois onglets sur un double écran pour accomplir une seule tâche, ni mesurer la charge réelle que représentent certaines opérations manuelles. Un outil qui ne comprend pas le terrain est un outil qui ne sera pas utilisé.
Qu’est-ce qui différencie un cas d’usage intéressant sur le papier d’un cas d’usage réellement adoptable ?
La différence tient à la valeur nette générée. Le premier filtre est naturellement le ROI : un projet peut être brillant techniquement, mais coûter plus en maintenance et en exploitation qu’il ne rapporte en gains de temps ou en chiffre d’affaires. Il ne faut pas négliger le coût du run — ressources humaines et ressources de calcul. Au-delà du ROI, deux critères sont déterminants : le gain de performance immédiat — l’outil libère-t-il les équipes d’une tâche pénible ? — et la rapidité de déploiement. Il faut privilégier les quick wins en premier lieu, pour maintenir la dynamique et préserver la confiance des équipes. Lors d’un audit de maturité récent, nous avons identifié une trentaine de cas d’usage pour n’en retenir que cinq.
Tu me disais que commencer par automatiser des actions périphériques au cœur de métier peut être une bonne stratégie. Pourquoi ?
Le réflexe naturel est de s’attaquer au cœur stratégique du métier. Mais c’est précisément là que l’expert est le plus exigeant et tolère le moins l’approximation. À l’inverse, les tâches annexes sont souvent vécues comme des corvées, et c’est là que l’IA est accueillie comme une véritable libération.
Dans un projet retail, par exemple, nous avons travaillé sur la gestion des fiches produits et de la communication — une tâche incombant au responsable de magasin, mais sans rapport avec son cœur de métier, qui est la vente et le conseil client. L’immersion terrain nous a permis d’identifier ces points de friction et de déployer une chaîne de cinq agents IA capables d’analyser une photo d’article, de vérifier sa conformité à la charte de l’enseigne, de générer le contenu marketing et de le publier sur les réseaux sociaux. Le responsable gagne du temps sur une tâche qu’il n’appréciait pas, tandis que l’enseigne sécurise son image et sa présence en ligne.
Tu parlais d’un Lean Canvas mis en place pour éviter l’effet POC et prioriser les cas d’usage. Peux-tu nous en dire plus ?
Le Lean Canvas est l’outil anti-gadget par excellence. Pour éviter de s’enfermer dans un POC sans issue, nous travaillons à deux échelles : macro, au niveau de l’organisation, et micro, au niveau du cas d’usage. Concrètement, on remplit le Canvas en examinant les prérequis — disponibilité des données, infrastructure, scalabilité, coût du run en maintenance — ainsi que les bénéfices concrets attendus. C’est un outil de priorisation, mais aussi de transparence vis-à-vis des équipes : il signale que leurs besoins ont été écoutés et que les décisions sont objectivées, non arbitraires. C’est ce qui permet d’embarquer les équipes dès le départ et de mener le projet jusqu’à son terme.
Quels conseils donnerais-tu pour sélectionner les utilisateurs pilotes et quel rôle jouent-ils dans la réussite du projet ?
Le choix des utilisateurs pilotes est, à mon sens, le levier stratégique numéro un : ce sont eux qui valident l’usage sur le terrain. Mais avant d’y parvenir, il faut un chef de projet pleinement convaincu, capable de valider la phase POC. Une fois cette étape franchie, on sélectionne un groupe restreint d’experts métiers — des profils disponibles, maîtrisant parfaitement leur domaine et capables de retours constructifs — pour construire le MVP avec eux et garantir une utilité immédiate. On élargit ensuite aux early adopters, profils curieux et technophiles, avant de procéder au déploiement global. La logique est simple : quand un collaborateur dit à un autre « cet outil m’a fait gagner une heure ce matin », la bataille de l’adoption est déjà à moitié gagnée.
Quel conseil très concret donnerais-tu à un Chief Data Officer pour maximiser l’adoption de ses projets IA ?
Le conseil essentiel : éviter à tout prix l’effet tunnel. Trop de directions data s’isolent pour livrer un produit parfait, alors que l’adoption repose sur deux piliers concrets.
Le premier est la transparence : ne pas attendre qu’un outil soit finalisé pour le mettre entre les mains des utilisateurs, communiquer en continu sur les avancées comme sur les apprentissages, et construire ainsi un climat de confiance.
Le second est la vigilance technologique : ne pas s’engager sur une solution sur la seule foi de promesses commerciales, mais la tester sur ses propres données. Le besoin doit piloter la technologie — jamais l’inverse.
