Erreurs critiques commises par les entreprises lors de l’intégration de l’IA/ML dans leurs processus

après avoir passé ma carrière à travailler dans un large éventail d’industries, des petites startups aux sociétés mondiales, des entreprises technologiques axées sur l’IA aux banques fortement réglementées. Au fil des années, j’ai vu de nombreuses initiatives d’IA et de ML réussir, mais j’en ai également vu un nombre surprenant échouer. Les raisons des échecs n’ont souvent pas grand-chose à voir avec les algorithmes. La cause première réside presque toujours dans la manière dont les organisations abordent l’IA.

Il ne s’agit pas d’une liste de contrôle, d’un manuel pratique ou d’une liste de règles strictes. Il s’agit d’un examen des erreurs les plus courantes que j’ai rencontrées, ainsi que de quelques spéculations sur les raisons pour lesquelles elles se produisent et sur la manière dont je pense qu’elles peuvent être évitées.

1. Absence d’une base de données solide

En l’absence de données médiocres, ou peu nombreuses, trop souvent dues à une faible maturité technique, les projets IA/ML sont voués à l’échec. Cela se produit trop souvent lorsque les organisations forment des équipes DS/ML avant d’avoir établi de solides habitudes d’ingénierie des données.

Un responsable m’a dit un jour : « Les feuilles de calcul ne rapportent pas d’argent. » Dans la plupart des entreprises, cependant, c’est exactement le contraire : les « feuilles de calcul » sont le seul outil qui peut augmenter les bénéfices. Ne pas le faire signifie devenir la proie de l’aphorisme classique du ML : « les déchets entrent, les déchets sortent ».

Je travaillais dans une entreprise régionale de livraison de nourriture. Les rêves de l’équipe DS étaient exorbitants : systèmes de recommandation de deep learning, Gen AI, etc. Mais les données étaient en ruine : une architecture trop ancienne, de sorte que les sessions et les réservations ne pouvaient pas être liées de manière fiable car il n’y avait pas d’identifiant de clé unique ; Les identifiants des plats des restaurants changeaient toutes les deux semaines, il était donc impossible de présumer en toute sécurité ce que les clients commandaient réellement. Ce problème et bien d’autres signifiaient que chaque projet était constitué à 70 % de solutions de contournement. Pas de temps ni de ressources pour des solutions élégantes. Mais pour une poignée d’entre eux, aucun des projets n’a donné de résultats en un an parce qu’ils ont été conçus sur la base de données peu fiables.

Emporter: Investissez dans l’ingénierie des données et la surveillance de la qualité des données avant le ML. Restez simple. Les premiers gains et les « fruits à portée de main » ne nécessitent pas nécessairement des données de haute qualité, mais l’IA le fera certainement.

2. Aucune analyse de rentabilisation claire

Le ML est généralement utilisé parce qu’il est à la mode plutôt que pour résoudre un problème réel, en particulier compte tenu du battage médiatique du LLM et de l’IA agentique. Les entreprises construisent des cas d’utilisation autour de la technologie plutôt que l’inverse, finissant par créer des solutions trop compliquées ou redondantes.

Pensez à un assistant IA dans une application de paiement de factures de services publics où les clients n’appuient que sur trois boutons, ou à un traducteur IA de tableaux de bord lorsque la solution doit rendre les tableaux de bord compréhensibles. Une recherche rapide sur Google d’exemples d’assistants IA défaillants révélera de nombreux cas de ce type.

Un de ces exemples dans ma vie professionnelle était un projet visant à créer un assistant sur une application de découverte et de réservation de restaurants (un agrégateur de restaurants, disons). Les LLM faisaient fureur, et il y avait FOMO du sommet. Ils ont décidé de développer un service sécurisé à faible priorité avec un assistant de chat confronté aux utilisateurs. L’assistant proposerait des restaurants en fonction de demandes telles que « montre-moi de bons endroits avec des réductions », « Je veux un dîner raffiné avec ma petite amie » ou « trouver des endroits acceptant les animaux de compagnie ».

L’équipe a passé un an à le développer : des centaines de scénarios ont été conçus, des garde-corps ont été réglés et un backend rendu à l’épreuve des balles. Mais l’essentiel du problème était que cet assistant n’a résolu aucun problème réel pour les utilisateurs. Un très faible pourcentage d’utilisateurs a même essayé de l’utiliser et parmi eux, seul un nombre statistiquement insignifiant de sessions a abouti à des réservations. Le projet a été abandonné très tôt et n’a pas été étendu à d’autres services. Si l’équipe avait commencé par la confirmation du cas d’utilisation au lieu des fonctionnalités de l’assistant, un tel destin n’aurait pas pu être atteint.

Emporter: Commencez toujours par le problème. Comprenez en profondeur le problème, attribuez sa valeur en chiffres, puis commencez seulement le parcours de développement.

3. Chasser la complexité avant de maîtriser les bases

La plupart des communautés accèdent à la dernière version sans s’arrêter pour voir si les méthodes les plus simples suffiraient. Une taille unique ne convient pas à tout le monde. Une approche progressive, commençant simplement et incrémentée selon les besoins, se traduit presque toujours par un meilleur retour sur investissement. Pourquoi le rendre plus complexe qu’il ne devrait l’être alors que la régression linéaire, les modèles pré-entraînés ou les heuristiques simples suffiront ? Commencer simplement fournit des informations : vous découvrez le problème, découvrez pourquoi vous n’avez pas réussi et disposez d’une base solide pour itérer plus tard.

J’ai mis en œuvre un projet visant à concevoir un widget de raccourci sur la page d’accueil d’une application multiservice incluant le covoiturage. L’idée était simple : prédire si un utilisateur avait lancé l’application pour demander un trajet, et si c’est le cas, prédire où il irait le plus probablement afin que l’utilisateur puisse le réserver en une seule touche. La direction a décrété que la solution devait être un réseau de neurones et ne pouvait être rien d’autre. Après quatre mois d’évolution douloureuse, nous avons constaté que les prédictions fonctionnaient étonnamment bien pour peut-être 10 % des coureurs ayant un historique profond de covoiturage. Même pour eux, les prédictions étaient terribles. Et le problème a finalement été résolu en une nuit grâce à un ensemble de règles métier. Des mois d’efforts inutiles auraient pu être évités si l’entreprise avait démarré de manière prudente.

Emporter: Marchez avant de courir. Utilisez la complexité en dernier recours, pas comme point de départ.

4. Déconnexion entre les équipes ML et l’entreprise

Dans la plupart des organisations, la Data Science est une île. Les équipes créent des solutions techniquement étonnantes qui ne voient jamais le jour parce qu’elles ne résolvent pas les bons problèmes ou parce que les parties prenantes de l’entreprise ne leur font pas confiance. L’inverse n’est pas mieux : lorsque les dirigeants d’entreprise tentent de dicter le développement technique dans son intégralité, de fixer des attentes irréalisables et de promouvoir des solutions qui échouent, personne ne peut les défendre. L’équilibre est la réponse. Le ML prospère mieux lorsqu’il s’agit d’un exercice de collaboration entre experts du domaine, ingénieurs et décideurs.

J’ai vu cela le plus souvent dans les grandes entreprises non natives de l’informatique. Ils réalisent que l’IA/ML a un énorme potentiel et créent des « laboratoires d’IA » ou centres d’excellence. Le problème est que ces laboratoires travaillent souvent en totale isolement de l’entreprise et que leurs solutions sont rarement adoptées. J’ai travaillé pour une grande banque qui disposait d’un tel laboratoire. Il y avait là des experts très chevronnés, mais ils n’ont jamais rencontré les acteurs du monde des affaires. Pire encore, le laboratoire était constitué en filiale autonome et l’échange de données était impossible. L’entreprise n’était pas très intéressée par les travaux du laboratoire, qui aboutissaient à des documents de recherche destinés aux universitaires, mais pas aux processus réels de l’entreprise.

Emporter: Gardez les initiatives de ML étroitement alignées sur les besoins de l’entreprise. Collaborez tôt, communiquez souvent et itérez avec les parties prenantes, même si cela ralentit le développement.

5. Ignorer les MLOps

Les tâches Cron et les scripts maladroits fonctionneront à petite échelle. Cela dit, à mesure que l’entreprise grandit, c’est la recette du désastre. Sans MLOps, de petits ajustements nécessitent l’engagement des développeurs originaux à chaque étape du processus, et les systèmes sont entièrement réécrits encore et encore.

Un investissement précoce dans MLOps rapporte de manière exponentielle. Il ne s’agit pas uniquement de technologie, mais d’une culture ML stable, évolutive et durable.

Investir tôt dans MLOps est rentable de manière exponentielle. Il ne s’agit pas seulement de technologie ; il s’agit de créer une culture de ML fiable, évolutive et maintenable. Ne laissez pas le chaos vous envahir. Établissez de bons processus, plates-formes et formations avant que les projets ML ne se déchaînent.

J’ai travaillé dans une filiale de télécommunications qui faisait de l’AdTech. La plate-forme diffusait de la publicité sur Internet et constituait la principale source de revenus de l’entreprise. Parce qu’elle était nouvelle (âgée d’un an seulement), la solution ML était désespérément fragile. Les modèles étaient simplement enveloppés en C++ et intégrés dans le code produit par un seul ingénieur. Les intégrations n’étaient effectuées que si cet ingénieur était présent, les modèles n’étaient jamais suivis et une fois l’auteur original parti, personne n’avait la moindre idée de leur fonctionnement. Si l’ingénieur d’équipe était également parti, toute la plate-forme aurait été définitivement arrêtée. Une telle exposition aurait pu être évitée grâce à de bons MLOps.

6. Manque de tests A/B

Certaines entreprises évitent les tests A/B en raison de leur complexité et optent plutôt pour des backtests ou l’intuition. Cela permet aux mauvais modèles d’atteindre la production. Sans plateforme de test, il est impossible de savoir quels modèles fonctionnent réellement. Des cadres d’expérimentation appropriés sont nécessaires pour une amélioration itérative, en particulier à grande échelle.

Ce qui a tendance à freiner l’adoption, c’est le sentiment de complexité. Mais un processus de test A/B simple et rationalisé peut bien fonctionner au début et ne nécessite pas d’énormes investissements initiaux. L’alignement et la formation sont vraiment les clés les plus importantes.

Dans mon cas, sans aucun moyen solide de mesurer l’impact sur les utilisateurs, tout dépend de la capacité d’un manager à le vendre. Les bons arguments sont financés, défendus avec ferveur et durent parfois même lorsque les chiffres diminuent. Les métriques sont manipulées en comparant simplement les chiffres avant/après le lancement. S’ils augmentent, alors le projet est un succès, même s’il s’agit d’une tendance générale à la hausse. Dans les entreprises en croissance, des millions de projets médiocres se cachent derrière la croissance globale, car il n’existe pas de tests A/B pour séparer continuellement les succès des échecs.

Emporter: Créer une capacité d’expérimentation dès le début. Testez les déploiements à grande échelle requis et laissez les équipes interpréter correctement les résultats.

7. Gestion sous-formée

Une gestion du ML sous-formée peut mal interpréter les métriques, mal interpréter les résultats des expériences et commettre des erreurs stratégiques. Il est tout aussi crucial de former les décideurs que de former les équipes d’ingénieurs.

Je travaillais autrefois avec une équipe qui disposait de toute la technologie dont elle avait besoin, ainsi que de solides tests MLOps et A/B. Mais les managers ne savaient pas comment les utiliser. Ils ont utilisé les mauvais tests statistiques, ont interrompu les expériences après un jour où la « signification statistique » avait été atteinte (généralement avec beaucoup trop peu d’observations) et ont lancé des fonctionnalités sans impact mesurable. Résultat : de nombreux lancements ont eu un impact négatif. Les managers eux-mêmes n’étaient pas de mauvaises personnes, ils ne comprenaient tout simplement pas comment utiliser leurs outils.

8. Métriques mal alignées

Même si les organisations ML/DS doivent être alignées sur leurs activités commerciales, cela n’implique pas qu’elles doivent avoir un instinct commercial. Les praticiens du ML s’aligneront également sur les mesures qui leur sont fournies s’ils estiment qu’elles sont correctes. Si les objectifs du ML ne correspondent pas aux objectifs fermes, le résultat sera alors pervers. Par exemple, si la rentabilité est ce que souhaite l’entreprise mais que maximiser la conversion de nouveaux utilisateurs est un objectif de l’organisation ML, elle maximisera la croissance non rentable en ajoutant de mauvais utilisateurs économiques qui ne reviendront jamais.

C’est un problème pour de nombreuses entreprises. Une entreprise de livraison de nourriture souhaitait se développer. La direction a observé que le faible taux de conversion des nouveaux utilisateurs était le problème qui empêchait l’entreprise d’augmenter ses revenus. L’équipe DS a été invitée à résoudre ce problème en améliorant la personnalisation et l’expérience client. Le vrai problème était la rétention, les utilisateurs convertis ne revenaient pas. Au lieu de la rétention, l’équipe s’est concentrée sur la conversion, en remplissant efficacement d’eau un seau qui fuyait. Même si le taux de conversion s’est accéléré, cela ne s’est pas traduit par une croissance durable. Ces erreurs ne sont pas spécifiques à la taille d’une entreprise ou d’un secteur : ce sont des erreurs universelles.

Ils peuvent néanmoins être évités. L’IA et le ML fonctionnent lorsqu’ils sont élaborés selon des principes solides, conçus pour résoudre des problèmes réels et soigneusement mis en œuvre dans l’entreprise. Lorsque toutes les conditions sont réunies, l’IA et le ML se transforment en technologies disruptives susceptibles de bouleverser des entreprises entières.

Emporter: Alignez les métriques ML sur les véritables objectifs commerciaux. Combattez les causes, pas les symptômes. Valorisez les performances à long terme, et non les mesures à court terme.

Conclusion

Le chemin vers le succès de l’IA/ML repose moins sur des algorithmes de pointe que sur la maturité organisationnelle. Les schémas sont évidents : les échecs résultent d’une précipitation dans la complexité, d’un mauvais alignement des incitations et de l’ignorance des infrastructures fondamentales. Le succès exige de la patience, de la discipline et une ouverture à commencer modestement.

La bonne nouvelle est que toutes ces erreurs sont totalement évitables. Les entreprises qui mettent en place une infrastructure de données en premier, maintiennent une coordination étroite entre les équipes techniques et commerciales et ne se laissent pas distraire par les modes découvriront que l’IA/ML fait exactement ce qu’elle promet. La technologie fonctionne, mais elle doit reposer sur des bases solides.

S’il y a un principe qui relie tout cela, c’est bien celui-ci : l’IA/ML est un outil, pas une destination. Commencez par le problème, confirmez le besoin, développez de manière itérative et mesurez toujours. Les entreprises qui l’abordent avec cet état d’esprit n’échouent pas seulement. Au lieu de cela, ils créent des différenciateurs concurrentiels à long terme qui s’aggravent avec le temps.

L’avenir n’appartient pas aux entreprises dotées des modèles les plus récents, mais à celles qui ont la discipline de les appliquer de manière judicieuse.