La majorité des projets d’apprentissage automatique ne parviennent pas à atteindre le stade de la production
La plupart des projets d’apprentissage automatique n’aboutissent pas. Vous pouvez obtenir un modèle fonctionnel, impressionner quelques personnes en interne par ses performances sur des données de test, voire même construire un beau prototype. Mais lorsqu’il s’agit de transformer ce travail en un produit qui apporte une valeur ajoutée à grande échelle, c’est là que les choses se gâtent. C’est là que les choses se gâtent. Selon une étude de 2023 Rexer Analytics, seul un tiers de ces efforts aboutissent à la production. Auparavant, les taux d’échec atteignaient 85 %. À eux seuls, ces chiffres devraient faire réfléchir n’importe quel dirigeant.
Il ne s’agit pas seulement d’un mauvais code. Il s’agit de problèmes systémiques, d’objectifs peu clairs, d’un mauvais alignement entre les départements, d’une infrastructure manquante et souvent d’un manque de collaboration précoce. Un modèle d’apprentissage automatique solide nécessite encore des pipelines de données, une surveillance, une mise à l’échelle de l’informatique, des contrôles de risque et une intégration orientée vers l’utilisateur. Cela fait beaucoup à coordonner. Et s’il n’y a pas d’adhésion ou de clarté dès le départ, le projet s’enlise.
Les dirigeants doivent comprendre que cette situation n’est pas rare. L’échec n’est pas toujours mauvais. Les bonnes équipes apprennent vite, éliminent rapidement les mauvaises idées et avancent plus fort. Mais le vrai problème, c’est lorsque les projets traînent pendant des mois ou des années, en consommant des ressources, sans jamais être testés sur le terrain. Ce n’est pas de l’expérimentation. C’est du gaspillage.
Si vous voulez que vos initiatives d’apprentissage automatique portent leurs fruits, concentrez-vous sur l’alignement précoce, l’appropriation interfonctionnelle et une supervision rigoureuse. Fixez des jalons précis. Veillez à ce que le succès soit mesurable. Et ne récompensez pas les démonstrations internes, récompensez les résultats.
Les efforts d’apprentissage automatique échouent souvent en raison de définitions de problèmes peu claires ou mal alignées.
Avant de vous préoccuper des GPU, des modèles ou des algorithmes, posez-vous la question suivante : ai-je le bon problème ? Beaucoup d’équipes se lancent dans la construction d’outils parce qu’ils semblent prometteurs. Mais l’apprentissage automatique n’est pas de la magie. Si votre objectif n’est pas clairement défini ou si le problème n’a pas été bien posé au départ, vous perdrez des mois à poursuivre des cibles mouvantes. Il s’agit de l’écueil le plus élémentaire, mais il fait constamment dérailler les projets.
Les scientifiques des données ne lisent pas dans les pensées. Ils ont besoin de questions commerciales clairement définies qui peuvent être mises en correspondance avec des objectifs mathématiques. Dans le cas contraire, ils créent de grands modèles qui résolvent des problèmes non pertinents. Dans l’enquête 2023 de Rexer Analytics, seuls 29 % des praticiens ont déclaré que les objectifs du projet étaient définis « la plupart du temps ». Plus d’un quart d’entre eux ont déclaré que c’était rarement le cas. Ces lacunes sont importantes. Les changements de direction tardifs détruisent l’élan et bloquent la livraison.
Les équipes de direction ont toutes présenté leurs projets comme essentiels, mais ils manquaient de clarté. L’effort de ML le plus réussi n’était pas le plus tape-à-l’œil, c’était celui qui s’alignait clairement sur un centre de profit majeur, s’intégrait à un pipeline de produits existants et avait un chemin clair vers une amélioration mesurable. Une approche basique, mais efficace.
Les dirigeants doivent être prêts à poser des questions difficiles et à y répondre rapidement. Ce problème vaut-il la peine d’être résolu ? L’apprentissage automatique peut-il réellement aider ? Avons-nous défini des critères d’évaluation ? Et surtout : que se passera-t-il si tout se passe bien ? Si la réponse est vague ou politique, abandonnez-la avant de gaspiller des cycles. L’IA doit être ciblée, et non un théâtre expérimental.
Les pièges liés aux données minent systématiquement les projets d’apprentissage automatique à chaque étape
Si vous voulez tirer quelque chose d’utile de l’apprentissage automatique, vos données d’entrée doivent être propres, pertinentes et correctement structurées. La plupart des projets qui échouent ne le font pas à cause de mauvais modèles, mais parce que les données sont erronées dès le départ. Ce n’est pas pour rien que l’on parle de « garbage in, garbage out ». Aucun algorithme ne peut corriger le bruit sous-jacent, les biais ou les incohérences dans les données.
Même les équipes expérimentées ne sont pas à l’abri. Une étude réalisée en 2022 par l’université de Princeton a révélé des fuites de données dans 22 articles de recherche évalués par des pairs, qui ont ensuite affecté plus de 290 études de suivi dans 17 domaines. Il ne s’agissait pas d’équipes subalternes, mais de chercheurs de premier plan. Cela devrait vous indiquer à quel point ces problèmes sont profonds et cachés.
La préparation des données de base, le filtrage des valeurs aberrantes, le remplissage des valeurs manquantes, l’équilibrage des distributions par classe, sont nécessaires, mais loin d’être suffisants. Vous travaillez souvent avec des systèmes existants, des formats contradictoires, des étiquettes mal étiquetées ou des silos internes où les équipes ne savent même pas quelles sont les fonctionnalités disponibles. Si vos équipes ne prennent pas le temps d’explorer et de comprendre les données de première main, vous les mettez sur la voie de l’échec.
L’étiquetage est un problème à part entière. Les ensembles de données de référence pour l’évaluation n’apparaissent pas sans effort. Vous avez besoin de directives d’annotation claires, d’un jugement cohérent de la part des évaluateurs et de vérifications constantes du bruit et des désaccords. Dans les cas d’utilisation plus récents comme la GenAI, les équipes sont encore en train de comprendre à quoi ressemble une évaluation significative. La dépendance à l’égard du jugement humain pour les résultats, sans répétitivité soutenue, conduit à des déploiements fragiles.
Si vous êtes un dirigeant qui mise sur la ML, comprenez ceci : la plupart de vos risques se situent dans la couche de données, et non dans la couche de modèle. Faites de la place pour l’exploration initiale des données, investissez dans des outils d’étiquetage et de suivi, et ne précipitez pas l’évaluation. Les projets qui sautent ces étapes se heurtent généralement à des problèmes majeurs lorsqu’il est déjà trop tard pour rectifier le tir.
Le passage du développement d’un modèle de ML à un produit déployable pose des défis techniques importants.
Disposer d’un modèle fonctionnel est loin d’être la ligne d’arrivée. La véritable complexité commence lorsque vous essayez de faire fonctionner ce modèle de manière efficace et fiable dans le monde réel. C’est à cette étape, qui consiste à passer du concept au produit, que de nombreuses équipes se heurtent à un mur. Une grande partie de l’effort se situe en dehors du modèle lui-même. Vous avez besoin d’un écosystème complet : pipelines de données, infrastructure de service, surveillance des mesures, journalisation, mise en cache, programmation, gestion du basculement, contrôle de la confidentialité, et bien plus encore.
Google l’a clairement indiqué dans l’un de ses diagrammes du système de ML, la majeure partie du code de production d’un produit de ML n’est pas du tout liée au modèle. C’est tout ce qui l’entoure qui le maintient stable, performant et évolutif. Et ces systèmes ont leur propre cycle de vie, leur propre complexité et leurs propres coûts de maintenance.
Supposons que votre équipe souhaite utiliser génération augmentée par récupération (RAG) pour intégrer des données d’entreprise en temps réel dans un grand modèle linguistique pour l’automatisation de l’assistance. Sur le papier, c’est basique : appelez une API, ajoutez une base de données vectorielle, exécutez une orchestration. Mais dès que vous dépassez le stade de la démonstration, c’est une autre histoire. Vous devez évaluer la qualité des réponses, vous prémunir contre les hallucinations, surveiller la latence, garantir l’équité et la confidentialité, et obtenir l’adhésion de plusieurs services. Et si vous négligez un seul de ces facteurs, vous ne disposez pas d’un système de production, mais d’un risque qui ne demande qu’à faire surface.
Servir la ML à grande échelle signifie que le travail est interfonctionnel par défaut. Les équipes gagnantes ne jettent pas les modèles par-dessus le mur à l’ingénierie en s’attendant à ce que les choses fonctionnent. Elles s’alignent très tôt sur les critères de qualité, les mesures commerciales, les attentes des utilisateurs et les exigences en matière d’infrastructure. Si ces conversations n’ont pas lieu dès le départ, vous serez confronté plus tard à des goulets d’étranglement dont la résolution sera bien plus coûteuse et consommatrice de ressources.
C’est pourquoi les organisations intelligentes investissent dans de solides pipelines MLOps, non seulement pour des projets ponctuels, mais aussi pour assurer la répétabilité et la fiabilité des efforts déployés. Vous ne voulez pas des flux de travail de héros. Vous voulez des systèmes qui fonctionnent encore et encore, avec un minimum de friction.
Les performances des modèles hors ligne ne se traduisent pas toujours par un succès en ligne
Les environnements hors ligne et contrôlés ont tendance à donner aux équipes d’apprentissage automatique un faux sentiment de confiance. L’entraînement sur des données historiques à l’aide de métriques propres est très bien perçu lors de l’évaluation interne. Les équipes se félicitent de mesures telles que l’exactitude, la précision ou les scores F1. Mais dans le monde réel, ces chiffres ne sont pas toujours synonymes de succès.
Les déploiements en ligne introduisent des variables uniques : des données en direct et bruyantes, des exigences de latence en temps réel, des règles commerciales et les attentes des utilisateurs. Un modèle qui donne de bons résultats lors des tests hors ligne peut facilement se comporter de manière imprévisible en production. Les incohérences peuvent provenir de la façon dont les données ont été échantillonnées, de la façon dont les caractéristiques évoluent dans le temps ou de la façon dont le modèle interagit avec d’autres composants dans un système de recommandation ou de notation.
Les dirigeants doivent insister sur la validation en ligne dès le début. Ne vous contentez pas de mesures hors ligne élevées, insistez sur des tests A/B au niveau de l’entreprise dans un environnement d’utilisateurs réels. Si vos indicateurs clés de performance sont liés à la fidélisation, à l’engagement, à la conversion ou au chiffre d’affaires, assurez-vous que vos modèles sont évalués en production à l’aide de ces mesures. Sinon, vous risquez de prendre des décisions techniquement impressionnantes qui nuisent à la croissance réelle du produit.
Poussez au déploiement dès le début du cycle de vie, puis répétez. C’est là que se produit le véritable retour d’information et que la ML passe de la performance théorique à une valeur commerciale exploitable.
Les obstacles non techniques sont les principaux facteurs d’échec des projets de ML
La technologie n’est pas le principal obstacle à l’IA. Les véritables obstacles sont d’ordre organisationnel. Dans l’enquête 2023 de Rexer Analytics, les deux raisons les plus fréquemment citées pour expliquer les échecs étaient le manque de soutien des parties prenantes et une planification insuffisante, toutes deux non techniques. Pensez-y : après avoir embauché d’excellents ingénieurs et data scientists, construit des modèles puissants et mis en place l’infrastructure, ce sont les problèmes de processus et d’alignement qui tuent l’élan.
Une mise en œuvre réussie de l’apprentissage automatique nécessite une coopération active entre les équipes, le produit, le service juridique, l’ingénierie et l’entreprise. Les projets achoppent lorsque les décideurs hésitent, comprennent mal les risques ou n’attribuent pas les responsabilités. Certains hésitent parce qu’ils attendent des réponses parfaites de la part de systèmes imprécis. D’autres se sentent mal à l’aise lorsqu’il s’agit d’approuver des changements dans les activités de l’entreprise en fonction des résultats du modèle. Cela ralentit l’exécution et érode la motivation de l’équipe.
Une partie de la solution réside dans la formation. Les cadres qui ne sont pas issus du monde de l’IA ont besoin d’aide pour prendre des décisions éclairées. Ils doivent comprendre clairement trois choses : comment l’intelligence artificielle apprend (à partir de modèles probabilistes dans les données), quelles sont ses limites (cas limites, biais, boucles de rétroaction) et ce qui est nécessaire pour la déployer de manière fiable (accord interfonctionnel, examen juridique, validation par l’utilisateur).
La planification est également une question de structure. Votre organisation a besoin d’un plan clair avant le déploiement. Définissez le MVP. Choisissez un seul objectif d’optimisation. Construisez une version de bout en bout dès le début, n’attendez pas de « perfectionner » quelque chose en interne. Ensuite, testez et reconstruisez en vous basant sur ce que font les utilisateurs réels, et non sur ce que disent les indicateurs théoriques.
Certaines entreprises ont intérêt à séparer le travail d’exploration de l’exécution liée au produit. Un incubateur dédié à la ML peut prendre des risques plus importants et innover librement, tandis que les équipes produits renforcent les solutions fiables et évolutives. Il s’agit d’une approche à deux vitesses qui maintient la livraison sans bloquer la créativité.
Si vous occupez un poste de direction, reconnaissez que le succès de l’apprentissage automatique dépend davantage de la clarté, de la communication et de l’engagement que du code.
Les initiatives de ML réussies nécessitent une collaboration interfonctionnelle et des pratiques de gestion agiles
L’apprentissage automatique ne réussit pas en silos. Si votre équipe chargée des données travaille seule, que vos ingénieurs devinent comment les choses devraient fonctionner et que vos responsables commerciaux ne sont pas au clair sur les objectifs, votre projet est déjà compromis. Les initiatives de ML les plus efficaces sont interfonctionnelles dès le premier jour. Tout le monde est aligné dès le départ : produit, données, infrastructure, conformité et opérations commerciales.
Trop souvent, les entreprises traitent la ML comme un processus de transfert : elles construisent le modèle, puis le transmettent à l’ingénierie. Cela ralentit les choses et conduit à des systèmes incompatibles ou à des conceptions qui ne correspondent pas au contexte de l’entreprise. Les équipes les plus performantes agissent de manière synchronisée. Elles définissent leurs objectifs ensemble, testent les hypothèses dès le début et construisent d’abord une version simple du système complet. Cela permet d’accélérer le retour d’information et de clarifier les points à améliorer, que ce soit sur le plan technique ou organisationnel.
Commencer par un MVP clair permet de se concentrer. Vous n’avez pas besoin d’une infrastructure massive ou des modèles les plus avancés dans la première version. Vous avez besoin de quelque chose de fiable qui fonctionne de bout en bout et qui capture des données utiles. Plus vous testez tôt en conditions réelles, plus votre équipe apprend rapidement ce qui compte réellement pour vos clients et ce qui ne compte pas.
Ensuite, répétez. Développez l’ensemble de données, affinez vos mesures, mettez à jour vos modèles, mais toujours sur la base d’un retour d’information en direct. C’est ainsi que la ML devient une capacité évolutive et non une simple série d’expériences déconnectées les unes des autres.
Du point de vue de la gestion, cela signifie que les efforts de ML ne doivent plus être isolés. Ils devraient être ancrés dans des feuilles de route de produits plus larges, bénéficier de ressources comme des plates-formes partagées et être évalués en fonction de la valeur à long terme, et pas seulement de la nouveauté expérimentale. Cela signifie également qu’il faut prévoir du temps et des ressources pour les tests, les plans de retour en arrière et les améliorations progressives.
Les organisations qui y parviennent ne sont pas nécessairement celles qui effectuent les recherches les plus tape-à-l’œil. Ce sont celles qui déploient en permanence des solutions liées aux performances réelles de l’entreprise. Et elles le font par conception, et non par accident.
Réflexions finales
Pour mettre en production l’apprentissage automatique, il ne s’agit pas d’embaucher davantage de scientifiques des données ou de rechercher la dernière architecture. Il s’agit de mettre en place le bon système, interfonctionnel, fondé sur la valeur métier et capable de gérer la complexité sans s’enliser.
En tant que dirigeant, votre rôle n’est pas de micro-gérer la technologie. Il consiste à créer l’environnement adéquat. Cela signifie qu’il faut définir des objectifs clairs dès le départ, donner à vos équipes des priorités alignées, encourager une exécution précoce de bout en bout et veiller à ce que les bonnes personnes se parlent dès le début, et non pas après un échec.
N’attendez pas la perfection. Ces projets sont par nature incertains. Ce qui compte, c’est la rapidité avec laquelle votre organisation navigue dans cette incertitude, apprend et va de l’avant avec discipline. Si vous y parvenez de manière cohérente, l’apprentissage automatique ne se contente pas de fonctionner, il s’enrichit.
Investissez dans l’exécution. Protégez la flexibilité. Récompensez les résultats réels, et non les victoires théoriques. C’est ainsi que vous transformerez l’apprentissage automatique du potentiel en performance.
