L’automatisation du développement de l’IA est utile lorsqu’elle élimine des tâches répétitives sans masquer les décisions qui nécessitent toujours l’intervention d’une personne expérimentée. AutoML peut exécuter des expérimentations sur les modèles et leurs paramètres. MLOps peut renforcer la cohérence de l’entraînement, des tests, de la mise en production et de la surveillance. Aucun des deux ne permet de déterminer si un modèle résout le bon problème, si les données sont adéquates ou si le résultat peut être utilisé en toute sécurité.
La question pratique n’est donc pas « Jusqu’où pouvons-nous automatiser ? », mais « L’automatisation permet-elle de mettre en production davantage de modèles utiles et acceptés pour le temps et l’argent investis ? » Pour y répondre, il faut une situation de référence, un essai contrôlé et une évaluation des coûts d’exploitation qui inclut l’examen humain.
Ce qu’AutoML et MLOps automatisent
AutoML couvre les parties répétitives, mais exigeantes sur le plan informatique, du développement de modèles. Une équipe définit le problème, fournit des données étiquetées, choisit une métrique d’évaluation et fixe des contraintes. La plateforme peut ensuite essayer différentes combinaisons d’algorithmes, de caractéristiques et de paramètres. La présentation d’Azure AutoML par Microsoft décrit ce processus comme un entraînement itératif reposant sur des paramètres et des critères d’arrêt définis par l’utilisateur. Des personnes doivent également identifier la tâche, configurer l’expérimentation et examiner ses résultats.
MLOps couvre le parcours plus large allant d’une expérimentation à un système exploité. Le guide d’architecture MLOps de Google Cloud aborde l’automatisation et la surveillance de l’intégration, des tests, de la mise en production, du déploiement et de l’infrastructure. Il établit une distinction importante : les tests d’un système de ML portent sur les données, les schémas et la qualité du modèle, et pas uniquement sur le code de l’application. La surveillance en production doit également détecter les changements dans les données et le comportement du modèle.
Ces outils peuvent réduire les transitions manuelles entre les étapes, rendre les expérimentations reproductibles et fournir des enregistrements plus clairs des éléments entraînés et mis en production. Ils ne suppriment pas la préparation des données, le jugement métier, l’examen de la sécurité, l’évaluation des modèles ni la responsabilité opérationnelle.
Dans quels domaines l’automatisation peut-elle être utile ?
Un flux de travail comprenant des expérimentations ou des mises en production répétées constitue un bon point de départ. AutoML peut aider à comparer des modèles candidats pour une tâche de classification, de régression ou de prévision. Un pipeline peut être utile lorsque les mêmes étapes de validation, de conditionnement et de déploiement sont répétées pour chaque modèle approuvé. La surveillance peut aider une équipe à repérer plus tôt des entrées manquantes, des changements de distribution, des problèmes de latence ou une dégradation de la qualité.
Les interfaces low-code peuvent permettre aux analystes et aux spécialistes métier de configurer une expérimentation ou d’en examiner les résultats, mais l’accès à une interface ne confère pas la compétence nécessaire pour approuver un modèle. Une personne doit toujours vérifier la variable cible, l’échantillonnage, les fuites de données, la conception de l’évaluation et les conséquences des erreurs. Plus la décision est lourde de conséquences, plus ces contrôles doivent être rigoureux.
Soins de santé
Dans les soins de santé, l’automatisation peut soutenir des expérimentations contrôlées portant sur des tâches telles que la classification d’images, l’estimation des risques ou les prévisions opérationnelles. Tout modèle utilisé dans un contexte clinique nécessite encore des données adéquates, une évaluation clinique, des contrôles en matière de respect de la vie privée et de sécurité, une évaluation réglementaire lorsqu’elle s’applique, ainsi qu’une surveillance au sein de la population auprès de laquelle il est utilisé. Un résultat hors ligne prometteur ne démontre ni un bénéfice pour les patients ni la sécurité du modèle.
Finance
Pour les processus financiers, les équipes peuvent automatiser des expérimentations portant sur les signaux de fraude, la classification de documents ou les prévisions. Une utilisation en production exige de prêter attention à l’accès aux données, à l’explicabilité, aux biais, aux pistes d’audit, à la gouvernance des risques liés aux modèles et aux procédures de repli. Le réentraînement automatisé ne doit pas entraîner automatiquement la mise en production d’un modèle, sauf si celui-ci réussit les tests convenus et si l’organisation a défini qui peut approuver le changement.
Industrie manufacturière et commerce de détail
Les entreprises manufacturières et les détaillants peuvent tester des modèles pour la prévision de la demande, l’inspection, la planification des stocks ou la maintenance. La valeur dépend de la qualité des données et de la manière dont la prédiction modifie une décision réelle. Une prévision légèrement plus précise peut malgré tout avoir peu de valeur si elle arrive trop tard, ne peut pas être intégrée aux systèmes de planification ou crée davantage de travail d’examen qu’elle n’en supprime. Notre article consacré à l’automatisation du travail et au ROI aborde également la nécessité de mesurer le travail dans son contexte, tandis que notre page sur l’IA pour l’e-commerce présente des applications connexes dans le commerce de détail.
Comment mesurer la rentabilité de l’automatisation ?
Commencez par mesurer le processus manuel actuel sur un ensemble représentatif de modifications de modèles. Consignez les heures de travail effectif consacrées à la préparation des données, à la configuration des expérimentations, à la supervision de l’entraînement, à l’évaluation, au conditionnement, au déploiement et à la gestion des incidents. Comptabilisez le nombre de modèles candidats examinés, le nombre de modèles rejetés et le nombre de versions acceptées pour utilisation. Notez séparément le temps écoulé : attendre la disponibilité de ressources informatiques n’équivaut pas à du temps de travail du personnel.
Appliquez ensuite l’approche automatisée à des tâches comparables et recueillez les mêmes mesures. Incluez tous les coûts, et pas uniquement l’abonnement à la plateforme :
- le travail manuel d’ingénierie et de science des données avant et après l’automatisation ;
- les coûts des ressources informatiques d’entraînement, du stockage et du suivi des expérimentations ;
- les coûts d’inférence et de mise à disposition pour des volumes de trafic réalistes ;
- les licences des plateformes, l’orchestration et l’observabilité ;
- le temps consacré à l’examen des données, de la qualité des modèles, de la sécurité et de l’acceptation métier ;
- la maintenance, les exécutions ayant échoué, les retours en arrière et la gestion des exceptions.
Le nombre de versions de modèles utiles et acceptées constitue un meilleur dénominateur que le nombre d’expérimentations réalisées. Une plateforme qui exécute des centaines d’essais peut augmenter les coûts sans améliorer le nombre ou la qualité des modèles que l’équipe peut utiliser de manière responsable. Comparez le coût total par version acceptée, le délai nécessaire pour parvenir à une version acceptée, le travail d’examen, la fiabilité en production et l’indicateur métier défini pour le cas d’usage.
Une règle de décision simple consiste à poursuivre lorsque la valeur mesurée de l’amélioration de la capacité, de la fiabilité ou des résultats dépasse le coût d’exploitation supplémentaire selon une marge jugée acceptable par l’organisation. Si l’avantage prend principalement la forme de capacités de travail libérées plutôt que d’économies budgétaires effectives, présentez-le comme tel. Réévaluez le calcul après le lancement, car les volumes d’inférence, les taux d’examen et le comportement des modèles peuvent changer.
Intégrer les contrôles au pipeline
L’automatisation doit s’arrêter lorsqu’un contrôle échoue, et non le contourner. Un pipeline pratique peut valider les schémas de données, tester le code, comparer les métriques du modèle à une référence approuvée, enregistrer la traçabilité et imposer un examen avant la mise en production. Le déploiement doit être réversible. La surveillance doit couvrir l’état de santé du service et le comportement du modèle, avec un responsable et une procédure d’intervention pour chaque alerte.
Le réentraînement automatique n’est approprié que lorsque les nouvelles données ainsi que les règles d’évaluation et de mise en production sont fiables. Dans de nombreux contextes, un entraînement automatisé suivi d’une approbation humaine constitue la conception la plus sûre. Les recommandations MLOps de Google considèrent également la validation des données et des modèles comme des composantes obligatoires d’un pipeline de production automatisé, plutôt que comme des tâches facultatives après le déploiement.
Une prochaine étape concrète
Choisissez un flux de travail lié à un modèle qui implique un travail manuel répété et pour lequel vous disposez d’un historique suffisant afin d’établir une situation de référence. Mesurez deux ou trois mises en production récentes, en incluant les ressources informatiques, les examens et les travaux rejetés. Automatisez une seule étape clairement délimitée, puis comparez les mises en production suivantes à l’aide des mêmes mesures. L’équipe disposera ainsi d’éléments probants pour étendre, adapter ou arrêter l’automatisation, sans s’appuyer sur une affirmation générique concernant les économies réalisables.