Pourquoi la majorité des projets d'IA n'aboutissent à rien
Si vous lisez ceci, c’est probablement parce qu’il y a quelque part dans votre entreprise un modèle de machine learning, une preuve de concept avec l’IA ou un dashboard que personne n’utilise. Et vous avez sûrement vu ces rapports, posts et articles qui parlent de l’IA comme de l’invention la plus révolutionnaire depuis l’imprimerie, mais aussi ceux qui parlent du ROI quasi inexistant qu’elle génère habituellement. Comment ces deux réalités peuvent-elles coexister ?
Ces dernières années, on a échangé avec plus de cent entreprises sur des projets data et IA, et un schéma revient sans cesse : ce n’est pas que les projets échouent techniquement (c’est justement le principe d’une preuve de concept, démontrer qu’un truc a du potentiel), mais ils restent là, comme une promesse non tenue. L’expérience a fonctionné, le test a réussi ; mais quand vient le moment d’en tirer la valeur, les choses se compliquent : soit on n’arrive jamais en production, soit personne ne l’adopte.
Vous voulez éviter que ça arrive à votre entreprise ? On vous partage quatre erreurs très courantes au moment de lancer un projet de cette envergure, qu’on a vues bien plus souvent qu’on ne l’imagine.
Chercher une question à une réponse
Aussi connu sous le nom de « balance l’IA et on verra après », c’est l’erreur classique de ceux qui tombent amoureux de la solution et non du problème. De la technologie, et non de ce qu’elle permet de faire. Contre toute logique, on a croisé plus d’une fois des équipes qui construisent d’abord une solution, puis cherchent à quoi l’utiliser.
Le scénario typique démarre quand quelqu’un de l’équipe data identifie une opportunité, monte une démo, la présente en réunion et suscite l’enthousiasme. Les volontés s’alignent, les astres aussi, et le projet démarre. Mais quelques semaines ou mois plus tard, quelqu’un regarde l’écran et demande : quelle décision métier cela change-t-il ? En quoi ça me fait grandir ?
On sait que l’IA est formidable (c’est notre métier, après tout !), mais si on ne peut pas répondre aux questions ci-dessus, tout projet qui l’utilise finit dans le néant, ou pire, se transforme en cauchemar. Un projet data + IA mal cadré a le potentiel de perturber des flux opérationnels qui n’auraient pas dû être touchés de cette manière, et de laisser un goût très amer à ceux qui ont pris le risque d’intégrer un changement technologique dans leur organisation.
Laisser le développement sans soutien
La deuxième raison est bien moins évidente à première vue, et se manifeste dans les organisations qui n’ont pas une maîtrise technique solide de la solution qu’on leur a livrée. Plus d’une fois, on a rencontré des équipes qui ont une boîte noire entre les mains, sur laquelle repose tout le business. Et pourquoi boîte noire ? Deux raisons possibles : soit personne ne sait ce qu’il y a dedans ni pourquoi ça fait ce que ça fait, soit personne ne sait l’opérer. La technologie devient alors une sorte de « regarde mais ne touche pas », où tout changement possible (ou nécessaire) est impossible.
Bien que ce soit vrai pour le développement logiciel en général, c’est encore plus critique pour la data + IA car le développement « est vivant ». De la matière première (les données) à la technologie qui les exploite, on est dans un domaine qui change non pas mois par mois, mais semaine par semaine.
Que se passe-t-il quand on a besoin de réentraîner un modèle, quand les données changent de format ou quand quelque chose plante de manière inattendue et incompréhensible, et qu’on n’a personne en interne pour le résoudre ? Le problème, c’est que la solution n’en a jamais été une : c’est une chaîne qui attache votre entreprise à un prestataire externe.
La question à poser à n’importe quel cabinet de conseil avant de signer n’est pas « pouvez-vous le construire ? ». C’est « avec quelles compétences restons-nous quand vous aurez terminé ? ».
Ne pas définir quand le développement est un succès
Une raison un peu surprenante mais très fréquente : on a souvent vu des projets démarrer sans que personne n’ait défini ce que « le projet fonctionne » veut dire. Sans nécessairement philosopher : qu’est-ce que le succès ? C’est quand on s’améliore de 10 %, de 15 %, de 20 % ? Quelle est la métrique métier impactée en conséquence de la métrique technique ? Qui décide que le résultat est suffisamment bon pour sortir du laboratoire et entrer sur le terrain ?
Quand cette conversation n’a pas lieu au début, elle se produit au pire moment possible : à la fin, quand l’investissement est engagé, les attentes sont créées et qu’il n’y a plus de place pour dire « ce n’est pas encore prêt ». Ainsi, ces projets restent dans un limbe : bien que ça tourne techniquement, le poids des non-dits fait que personne ne l’utilise pour prendre de vraies décisions.
On a acheté de l’exécution quand le problème était le diagnostic
La quatrième raison est la plus difficile à voir de l’intérieur et c’est celle qui fait le plus mal : l’aide qu’on a achetée n’est pas celle dont on avait besoin. Ou pire : on vous a convaincu de construire une tour de 10 étages sur des sables mouvants.
Il y a des moments où une organisation a besoin de comprendre le problème avant de construire la solution, et ça porte un nom : l’honnêteté. Le rôle de quelqu’un d’externe à une organisation est de dire les choses telles qu’elles sont, avec un jugement professionnel. Dans notre domaine, ça implique de voir quelles données existent, dans quel état elles sont, quels cas d’usage sont viables dans le contexte de l’organisation et lesquels ne le sont tout simplement pas. Et le problème, c’est que plus d’une fois, des entreprises veulent faire des choses pour lesquelles elles ne sont tout simplement pas encore prêtes, et il faut beaucoup d’intégrité pour savoir dire non.
Ça se produit quand les entreprises ne mesurent pas pleinement l’importance d’un diagnostic, des deux côtés du comptoir. Le résultat est souvent le même : des projets qui semblent avancer, mais qui sont en réalité techniquement très solides et totalement inadaptés au problème à résoudre.
Il convient aussi de mentionner que l’inverse se produit également (même si, d’après notre expérience, c’est moins fréquent). Dans ce cas, des entreprises restent piégées dans des processus de conseil stratégique avec des diagnostics toujours plus élaborés sans jamais démarrer la construction, dans une quête éternelle de la solution la plus absolue et parfaite. Mais ça n’existe pas : à un moment, il faut commencer à construire pour finir de comprendre.
Le diagnostic et l’exécution sont des moments distincts, et les confondre a un coût.
Qu’ont en commun les projets qui fonctionnent
Les projets qui fonctionnent sont ceux qui posent les questions inconfortables avant de démarrer. Les « pourquoi » des choses.
Quelle décision métier va changer avec ce modèle ? Qui dans l’organisation va modifier son comportement en fonction des résultats et comment va-t-on accompagner cette personne dans ce changement ? Comment va-t-on mesurer le succès en termes métier ? Avec quelles compétences reste l’équipe interne quand le projet se termine ?
Si vous évaluez un projet data ou IA, ou si vous choisissez avec qui le faire, voilà les questions auxquelles vous devriez pouvoir répondre (et celui qui vous propose le projet aussi) avant de signer quoi que ce soit.
C’est pour tout cela qu’on a un mantra : on cherche à ce que ceux qui nous font confiance et choisissent de travailler avec nous le fassent par choix, pas par obligation.
Si vous voulez d’abord comprendre où vous en êtes avant de construire quoi que ce soit, c’est comme ça qu’on commence.
