Pourquoi les cas d'usage de l'IA ne sont-ils pas exploités ? MLOps apporte une réponse.

Pourquoi les cas d'usage de l'IA ne sont-ils pas exploités ? MLOps apporte une réponse.

écrit avec Regis Amichia, Data Science Lead, Foxintelligence

Au cours des dernières années, de nombreuses organisations ont investi massivement dans les données et l'analytique. L'objectif est de devenir plus axé sur les données, de devenir une organisation de type technologique. Les entreprises désireuses d'aller plus loin que le simple profilage symbolique de l'organisation, investissent dans l'IA pour passer de l'analyse descriptive à l'analyse prédictive et prescriptive. Cela nécessite un solide programme de gouvernance des données et de l'IA, une infrastructure informatique qui rend toutes les données facilement disponibles dans un "lac de données", et un pilotage de l'organisation par le biais d'un portefeuille d'indicateurs de performance clés soigneusement sélectionnés. Il a cependant été largement documenté que l'obstacle le plus important est le changement vers une culture qui embrasse l'agilité et l'expérimentation. En fait, ce sont les humains qui ont besoin d'une nouvelle formation. En conséquence, des programmes de formation ont été lancés et les grandes organisations peuvent désormais se vanter de disposer de centaines de cas d'utilisation créés par des équipes interdisciplinaires qui sont partagés dans un référentiel interne pour la poursuite du développement et de l'innovation. La question difficile vient ensuite : quel est le rendement de ces énormes investissements ? Pourquoi y a-t-il si peu de cas d'utilisation de l'IA en production et où se trouve la génération d'une valeur tangible ? Il semble y avoir un vide à combler et les MLOps apportent une partie de la réponse.

Avant d'aborder les MLOps, prenons un peu de recul. La communauté des développeurs de logiciels s'est toujours creusé la tête pour trouver la meilleure méthodologie de gestion de projet. Tout a commencé avec l'approche en cascade, introduite dans les années 70 par Winston Royce. Cette approche linéaire définit plusieurs étapes dans le cycle de vie du développement logiciel : exigences, analyse, conception, codage, tests et livraison. Chaque étape doit être terminée avant de commencer la suivante et les clients ne voient les résultats qu'à la fin du projet.  Cette méthodologie crée un "tunnel de développement" entre la collecte des besoins du client et la livraison du projet. Pendant de nombreuses années, cette approche linéaire a été à l'origine d'énormes pertes de ressources. Une erreur dans la phase de conception ou le changement d'avis du client nécessitait de relancer le processus de développement. En outre, les équipes d'ingénieurs étaient regroupées à différents stades (les développeurs pour le codage, les équipes d'assurance qualité pour les tests et les administrateurs système pour la livraison), ce qui créait des frictions et un terrain fertile pour les erreurs de communication. C'est l'une des raisons qui ont conduit à une nouvelle méthodologie qui a vu le jour vers 2001 : l'approche agile.

Les principes agiles ont imprégné la culture du génie logiciel depuis plus de 20 ans. Ils ont doté les entreprises de la capacité de s'adapter aux nouvelles informations plutôt que de suivre un plan immuable. Dans un environnement commercial en pleine mutation, il s'agit davantage d'une question de survie que d'un simple changement de méthodologie. Désormais, les entreprises placent l'implication du client et l'itération au cœur du processus de développement logiciel. Elles réunissent des ingénieurs aux compétences complémentaires au sein d'équipes coordonnées par des chefs de produit pour diffuser régulièrement des morceaux de logiciel, recueillir des commentaires et adapter la feuille de route en conséquence. Il s'agissait d'une véritable révolution, mais elle n'était pas parfaite : il y avait encore un fossé entre le développement de logiciels et ce qui se passe après la sortie du logiciel, également connu sous le nom d'opérations. En 2008, Patrick Debois et Andrew Clay comblent ce fossé avec la méthodologie DevOps (contraction de développement et opérations). En réunissant toutes les équipes (développeurs de logiciels, QA et Sysadmin) dans les processus de développement et d'exploitation, les temps d'attente sont réduits et chacun peut travailler plus étroitement, afin de développer plus rapidement de meilleures solutions.

Pour en revenir à aujourd'hui, que peut apporter DevOps à l'ère de l'intelligence artificielle ? Les besoins sont les mêmes : les entreprises cherchent une méthodologie pour développer et mettre à l'échelle les algorithmes d'IA afin de générer de la valeur et de récolter les fruits de leurs investissements. Les dirigeants de données ont récemment commencé à étudier les avantages de la méthodologie Devops. Cependant, les algorithmes d'apprentissage automatique et d'IA ont une particularité qui les différencie radicalement des logiciels traditionnels : les données.

MLOps est un ensemble de pratiques, réunissant Devops, l'apprentissage automatique et l'ingénierie des données pour déployer et maintenir les systèmes ML en production. C'est la pièce manquante qui permet aux organisations de libérer la valeur contenue dans les données grâce à l'intelligence artificielle. Grâce à la formalisation et à la standardisation des processus, MLOps favorise l'expérimentation mais garantit également une livraison rapide, afin de faire évoluer les solutions d'apprentissage automatique au-delà de leur statut de cas d'utilisation. Une fois que les solutions sont en production et consomment de nouvelles données, le suivi des performances prédictives est essentiel. Les solutions universelles d'apprentissage automatique plus performantes pour des solutions spécifiques n'existent tout simplement pas, c'est pourquoi les organisations doivent surveiller les performances prédictives en temps réel. MLOps permet de surveiller ces performances et d'agir en cas de détérioration due à la dérive des concepts. L'automatisation de la collecte des informations sur le cycle de vie des algorithmes, c'est-à-dire le suivi de ce qui a été recalibré par qui et pourquoi, permet d'améliorer le processus d'apprentissage et de rendre compte aux auditeurs si nécessaire. Ainsi, les questions de responsabilité et de conformité peuvent être abordées.

Alors que la plupart des programmes de formation aux données se concentrent sur les éléments de l'apprentissage automatique, les statistiques et le codage, et travaillent sur des cas d'utilisation dans un environnement de bac à sable, les principes MLOps ne sont pas encore largement couverts. En outre, les chefs d'entreprise investissent dans l'IA sans comprendre pleinement comment créer un environnement de développement et d'exploitation efficace pour leurs équipes de données. Combler le fossé entre les données et les opérations n'est pas simple. La complexité des algorithmes ML, souvent considérés comme une boîte noire gérée par des data scientists qui sont censés être les seuls dans l'entreprise à comprendre ce qu'ils font, sépare les autres du processus de développement et crée un autre fossé entre l'IA et les entreprises.

MLOps ne concerne pas seulement les ingénieurs, chaque partie prenante des solutions basées sur les données devrait être impliquée. La révolution de l'intelligence artificielle est sans aucun doute en train de se produire maintenant, et tous ceux qui ont l'intention d'en faire partie auront un rôle à jouer dans la création et la gestion des processus MLOps dans leur organisation. Les futurs leaders en matière de données devraient acquérir des compétences MLOps de base dans leurs programmes de formation afin de supprimer la frontière néfaste et inutile entre les chefs d'entreprise et les équipes d'ingénieurs autour des sujets liés aux données.

ESSEC Knowledge sur X

Suivez nous sur les réseaux