L’apprentissage automatique en production ? Ce que cela signifie vraiment
que vous soyez manager, data scientist, ingénieur ou propriétaire de produit, vous avez presque certainement participé à au moins une réunion où la discussion tournait autour de « la mise en production d’un modèle ».
Mais sérieusement, que signifie produire ?
Comme vous le savez peut-être, je suis ingénieur en IA. J’ai débuté mon premier emploi en data science en 2015, dans une grande entreprise française du secteur de l’énergie. Nous étions à l’époque parmi les premiers acteurs à développer des applications d’IA pour la gestion et la production d’énergie (nucléaire, hydraulique et renouvelable). Et s’il est un domaine où la mise en production de l’IA est fortement réglementée, c’est bien celui de l’énergie, et notamment du nucléaire. Ceci est étroitement lié à la nature des données et au fait qu’il est difficile d’intégrer facilement des modèles d’apprentissage automatique dans un environnement existant.
Grâce à cette expérience, j’ai appris très tôt que créer un modèle dans un cahier n’est que la pointe de l’iceberg. J’ai aussi très vite commencé à parler de production, sans vraiment savoir ce que cela signifiait. Pour ces raisons, je souhaite partager avec vous la vision plus claire que j’ai développée au fil des années lorsqu’il s’agit de mettre en production des projets d’apprentissage automatique.
Mais arrêtons-nous un instant et réfléchissons à notre question principale.
Que signifie réellement produire ?
Parfois, ce qui se cache derrière ce mot à la mode, « production », peut être difficile à lire et à comprendre. Il existe d’innombrables vidéos et articles YouTube à ce sujet, mais très peu se traduisent par quelque chose que vous pouvez réellement appliquer dans des projets réels.
Si vous tentez d’y répondre, nos points de vue convergeront probablement d’ici la fin de cet article, même si les méthodes que nous utilisons pour parvenir à la production peuvent différer d’un contexte à l’autre.
La définition principale
Dans le contexte de l’apprentissage automatique, la production signifie que les sorties de votre modèle affectent directement un utilisateur ou un produit.
Cet impact peut prendre de nombreuses formes, comme éduquer quelqu’un, l’aider à prendre une décision ou permettre quelque chose qu’il ne pouvait pas faire auparavant ; cela peut également impliquer l’ajout d’une fonctionnalité au système de recommandation d’une application d’achat.
Tout programme contenant un algorithme d’apprentissage automatique utilisé par un utilisateur final ou un autre produit ou application peut être considéré comme un modèle en production.
Au-delà d’avoir un impact, la production s’accompagne également d’un niveau de responsabilité. Ce que je veux dire, c’est que si personne ou aucun système n’est chargé de corriger le modèle lorsqu’il est erroné, alors votre modèle peut être déployé, mais pas en production.
Il existe une idée répandue selon laquelle 87 % des projets de ML ne parviennent pas à atteindre la phase finale de production. Je ne sais pas si cela est strictement vrai, mais mon interprétation est simple : de nombreux modèles de ML n’atteignent jamais le point où ils ont réellement un impact sur un utilisateur ou un produit. Et même lorsqu’ils le font, il n’existe souvent aucun système en place pour les rendre fiables dans le temps, ils sont donc simplement déployés et accessibles.
Donc, si nous convenons que produire signifie avoir un projet de ML qui a un impact et qui est responsable, comment y arriver ?
Les multiples visages de la production
Pour répondre à cette question, nous devons accepter que la production a de nombreux visages. Le modèle n’est qu’un composant au sein d’un pipeline ETL plus vaste.
Ce point est crucial.
Nous imaginons souvent un modèle comme une boîte noire, les données entrent, la magie mathématique se produit et une prédiction en sort. En réalité, c’est une simplification excessive. En production, les modèles font généralement partie d’un flux de données plus large, souvent plus proche d’une transformation de données que d’un moteur de décision isolé.
De plus, toutes les « productions » ne se ressemblent pas selon la force du modèle dans le système final.
Parfois, le modèle prend en charge une décision, comme un score, une recommandation, une alerte ou un tableau de bord.
Parfois, il prend une décision, comme des actions automatiques, un blocage en temps réel ou le déclenchement de workflows.
La différence compte beaucoup. Lorsque votre système agit automatiquement, le coût d’une erreur n’est pas le même et les exigences techniques augmentent généralement très rapidement.
D’après mon expérience, la plupart des systèmes de production peuvent être décomposés en :
→ Le système de stockage de données en production, cela signifie que toutes les données sont stockées dans des systèmes de fichiers ou des bases de données hébergées en toute sécurité dans des environnements de production (cloud ou sur site).
→ La réalisation de la partie acquisition de données, cela signifie disposer d’un système ou d’un flux de travail qui se connecte aux bases de données de production et récupère les données qui seront utilisées comme entrée pour le modèle. Ces workflows peuvent contenir les étapes de préparation des données.
→ Mettre en production le composant machine learning, c’est la partie qui nous intéresse. Cela signifie que le modèle est déjà formé et que nous avons besoin d’un système qui lui permette de s’exécuter dans le même environnement que les autres composants.
Ces trois parties nous montrent clairement que le ML en production ne concerne pas le modèle d’apprentissage automatique lui-même, mais tout ce qui l’entoure.
Mais concentrons-nous uniquement sur le composant 3, « pousser le ML en production », car les autres étapes sont souvent gérées par différentes équipes au sein d’une entreprise.
La répartition en 4 étapes
Si j’avais un data scientist junior à qui je devais expliquer comment travailler sur ce composant, je le séparerais comme suit :
Étape 1 : la fonction
Vous commencez avec un modèle formé. La première chose dont vous avez besoin est une fonction, un code qui charge le modèle, reçoit les données d’entrée, effectue la prédiction et renvoie une sortie.
A ce stade, tout fonctionne localement. C’est excitant la première fois que vous voyez apparaître des prédictions, mais nous ne voulons pas nous arrêter là.
Un détail pratique qui compte dès le début, ne pensez pas seulement « est-ce que ça prédit ? », pensez aussi « est-ce que ça échoue proprement ? En production, votre fonction finira par recevoir des entrées étranges, des valeurs manquantes, des catégories inattendues, des fichiers corrompus ou des signaux hors de portée. Votre futur moi vous remerciera pour la validation de base et les messages d’erreur clairs.
Étape 2 : l’interface
Pour rendre cette fonction utilisable par d’autres (sans leur demander d’exécuter votre code), vous avez besoin d’une interface, le plus souvent une API.
Une fois déployée, cette API reçoit des requêtes standardisées contenant des données d’entrée, les transmet à votre fonction de prédiction et renvoie la sortie. C’est ce qui permet à d’autres systèmes, applications ou utilisateurs d’interagir avec votre modèle.
Et voici une réalité de production, l’interface n’est pas seulement une chose technique, c’est un contrat. Si un autre système attend /prédit et que vous exposez autre chose, la friction est garantie. Il en va de même si vous modifiez le schéma toutes les deux semaines. Lorsque les équipes disent « le modèle est en production », ce qu’elles veulent dire en réalité, c’est souvent « nous avons créé un contrat dont dépendent d’autres personnes ».
Étape 3 : L’environnement
Maintenant, nous avons besoin de portabilité. Cela signifie empaqueter l’environnement, le code, l’API et toutes les dépendances afin que le système puisse s’exécuter ailleurs sans modification.
Si vous avez suivi les étapes jusqu’à présent, vous avez créé un modèle, l’avez enveloppé dans une fonction et l’avez exposé via une API. Mais rien de tout cela n’a d’importance si tout reste verrouillé dans votre environnement local.
C’est là que les choses se professionnalisent : reproductibilité, versionnage et traçabilité. Pas forcément sophistiqué, juste assez pour que si vous déployez la v1.2 aujourd’hui, vous puissiez expliquer dans trois mois ce qui a changé et pourquoi.
Étape 4 : L’infrastructure
La dernière étape consiste à héberger tout quelque part où les utilisateurs ou les applications peuvent réellement y accéder.
Dans la pratique, cela signifie souvent le cloud, mais il peut également s’agir de serveurs internes à l’entreprise ou d’infrastructures de périphérie. Le point clé est que ce que vous avez construit doit être accessible, stable et utilisable là où cela est nécessaire.
Et c’est là que de nombreuses équipes apprennent une dure leçon. En production, le « meilleur modèle » n’est souvent pas celui qui présente la meilleure métrique dans un ordinateur portable. C’est celui qui correspond aux contraintes réelles, à la latence, au coût, à la sécurité, à la réglementation, à la surveillance, à la maintenabilité, et parfois simplement : « pouvons-nous faire fonctionner cela avec l’équipe dont nous disposons ?
Étape 5 : La surveillance
Vous pouvez disposer de l’API la plus propre et de l’infrastructure la plus performante, tout en échouant en production car vous ne constatez pas de problèmes à un stade précoce.
Un modèle en production qui n’est pas surveillé est déjà en panne, vous ne le savez tout simplement pas encore.
La surveillance ne doit pas nécessairement être compliquée. Au minimum, vous voulez savoir :
- le service est-il opérationnel et la latence est-elle tolérable ?
- les entrées semblent-elles toujours « normales » ?
- la sortie des données dérive-t-elle ?
- l’impact commercial est-il toujours logique ?
Avec de nombreux projets du monde réel, les performances ne s’effondrent pas en cas de gros crash. Il se décompose tranquillement.
La mise en place de tous ces composants transforme un modèle en quelque chose d’utile et d’impactant. Basé sur l’expérience, voici quelques directives pratiques.
Pour l’étape 1 (la fonction), tenez-vous-en aux outils que vous connaissez (scikit-learn, PyTorch, TensorFlow), mais pensez tôt à la portabilité. Des formats comme ONNX peuvent rendre l’automatisation future beaucoup plus facile. Si vous développez vos propres packages, vous devez être sûr, que vous soyez manager ou data scientist, que les compétences requises en ingénierie logicielle ou en ingénierie de données sont présentes, car construire des bibliothèques internes est une toute autre histoire que d’utiliser des outils du commerce.
Pour l’étape 2 (l’interface), les frameworks comme FastAPI fonctionnent très bien, mais pensez toujours au consommateur. Si un autre système attend /prédit et que vous exposez autre chose, la friction est garantie. Vous devez être en phase avec vos parties prenantes, tous les points techniques sur la destination des résultats de l’apprentissage automatique doivent être très clairs.
Pour l’étape 3 (L’environnement), c’est là qu’intervient Docker. Vous n’avez pas besoin de tout maîtriser immédiatement, mais vous devez comprendre les bases. Considérez Docker comme le fait de mettre tout ce que vous avez construit dans une boîte qui peut fonctionner presque n’importe où. Si vous possédez déjà de bonnes compétences en ingénierie de données, cela devrait aller. Sinon, vous devez soit les construire, soit compter sur quelqu’un de l’équipe qui les possède.
Pour l’étape 4 (l’infrastructure), les contraintes dictent les choix. Lambda, microservices, appareils de périphérie et bien sûr, GPU. Les charges de travail de ML nécessitent souvent une infrastructure spécialisée, parfois via des services gérés comme SageMaker.
À toutes les étapes, une règle qui sauve des vies : gardez toujours un moyen simple de revenir en arrière. La production ne consiste pas seulement à déployer, il s’agit également de récupérer lorsque la réalité se présente.
Ne considérez pas cette étape de votre projet de science des données comme une seule étape. C’est une séquence d’étapes et un changement de mentalité. Dans une entreprise, nous n’attendons pas que vous poussiez le modèle le plus compliqué, nous souhaitons que vous construisiez un modèle qui réponde à des questions métiers ou ajoute une fonctionnalité attendue par un produit spécifique. Nous avons besoin que ce modèle atteigne le produit ou l’utilisateur, et qu’il soit surveillé afin que les gens continuent de lui faire confiance et de l’utiliser.
Comprendre votre environnement est très important. Les outils que j’ai évoqués précédemment peuvent différer d’une équipe à l’autre, mais la méthodologie est la même. Je les partage uniquement pour vous donner une idée concrète.
Vous pouvez créer un excellent modèle, mais si personne ne l’utilise, cela n’a pas d’importance.
Et si les gens l’utilisent, alors il devient réel, il a besoin d’appropriation, de surveillance, de contraintes et d’un système autour de lui.
Ne laissez pas votre travail rester dans les 87 %.
Note: Certaines parties de cet article ont été initialement rédigées en français et traduites en anglais avec l’aide de Gemini.
🤝 Restez connecté
Si vous avez apprécié cet article, n’hésitez pas à me suivre sur LinkedIn pour des informations plus honnêtes sur l’IA, la science des données et les carrières.
👉 LinkedIn : Sabreiné Bendimérad
👉 Moyen: https://medium.com/@sabrine.bfinimérad1
👉 Instagram: https://tinyurl.com/datailearn
