Projets

Comment Total pousse l'IA en production

Sophânara de Lopez, datascientist chez Total, et Arnaud de Almeida, directeur du service de la valorisation des données chez Total, sont revenus sur la migration d'un projet IA en production. (Crédit Photo : D.R)

A l'occasion d'un évènement Octo Technology, Total a donné son retour d'expérience pour basculer un projet d'IA du mode PoC en production. Agilité, infrastructure innovante et une orientation métier sont des éléments à prendre en compte.

PublicitéTotal est connu pour son expertise dans le domaine pétrolier (prospection, exploitation, raffinage, distribution). Pour mener à bien ses missions, la firme française regarde avec attention les progrès de l'informatique et en particulier l'intelligence artificielle. A l'occasion d'un évènement organisé par Octo Technology, Total est venu parler de son expérience pour passer d'un test d'IA à la mise en production.

Arnaud de Almeida, directeur du service de la valorisation des données, chez Total résume le problème, « c'est un peu la rencontre du carré et du rond, car les premières réactions quand on parle d'IA sont : c'est génial cela va tout faire, mais cela va aussi me piquer mon boulot ». Pour réaliser une IA en production, il y a des prérequis : toutes les applications doivent répondre à de réels cas d'usage et avoir une valeur métier (ROI, valeur ajoutée,...). Il y a un ensemble de critères à respecter pour faciliter l'adoption, comme par exemple l'agilité, la rencontre avec les métiers le plus en amont possible, « car une personne sur une plateforme pétrolière, sur un site de production ou une salle de contrôle doit être impliquée le plus tôt possible », la démystification de l'IA, « ce n'est pas magique ! », les interfaces utilisateurs doivent faciliter les décisions opérationnelles et enfin l'expérience utilisateur doit être considérée comme essentielle.

Un PoC et des signaux faibles

Le cas d'usage présenté par Total portait sur un cas de maintenance prédictive sur des équipements critiques, en l'occurrence de pompes submersibles (ESP). Ces dernières sont installées en tête de puit pour remonter des fluides à la surface, « quand elles s'arrêtent ou tombent en panne, il n'y a plus de production. Donc prévenir les problèmes a une valeur ajoutée », rapporte Sophânara de Lopez, datascientist chez Total. Il y a deux types d'évènements sur ces pompes : ceux qui ne sont pas prévus, « c'est-à-dire hors planning de maintenance », et puis les casses.

Ces deux événements ont un impact opérationnel, car plus l'incident est long, plus la durée de vie de la pompe va se raccourcir. Il est donc important de détecter au plus tôt les problèmes pour anticiper la logistique de réparation ou de remplacement. Dans ce cadre, il faut que l'information remontée soit au plus prés des gens de terrain afin de prendre rapidement la bonne décision. Ils peuvent être aidés en parallèle par des experts au siège dans l'analyse des incidents.

Avant de basculer en production la solution de maintenance prédictive sur les pompes submersibles, un PoC a été réalisé en se focalisant sur un pays avec une dizaine de puits et autant de pompes comprenant près d'une centaine de capteurs et un environnement IT on premise. Après plusieurs itérations, il a été décidé de basculer en production plus grande échelle : 3 pays et 100 puits/ESP comprenant chacun une centaine de capteurs, la connectivité des datas est en temps réel « en mode PoC, il s'agissait de travailler sur un snapshot, des données froides », rappelle le datascientist. Par ailleurs, ce projet fonctionne dans un environnement cloud en se branchant sur un datalake. « Sur les capteurs, on va essayer de modéliser son comportement nominal en prenant comme inputs le comportement de l'ensemble des capteurs », souligne Sophânara de Lopez. L'idée est constater les divergences entre le comportement réel du capteur et le modèle de prédictibilité de comportement, ce que le datascientist appelle « des signaux faibles ». L'ensemble de ces signaux faibles est ensuite agrégé pour évaluer les risques par équipement.

PublicitéDes interrogations et des enseignements

D'autres interrogations existent pour la bascule en production : « Comment gérer le cycle de vie des modèles et comment garantir que le travail des datascientists est reproductible en production ». Le schéma de déploiement visé doit découpler la partie ingestion de données et la partie compute en s'adossant à une architecture de conteneurs pour garantir la mise à l'échelle et la réplicabilité. Une démarche qui s'apparente au DevOps et que le datascientist dénomme « DataOps ». Au sein des couches technologiques, il insiste sur deux aspects : Airflow, un organiseur des tâches complexes qui « affecte des ressources dynamiquement intéressant pour le deep learning (CPU) et qui est capable de faire des reprises sur erreurs, car des workflows data peuvent fonctionner pendant des heures, voire des jours, quand il y a des plantages on peut reprendre là où on s'est arrêté ». Le second aspect est la conteneurisation dans une volonté d'isoler les worflows et de personnaliser les infrastructures nécessaires. Aujourd'hui, les modèles sont entraînés toutes les semaines et la partie prédictive peut se faire de manière journalière avec une descente de 15 minutes.

Ce projet a permis à Total d'apprendre quelques enseignements. Pour Sophânara de Lopez, « l' approche Craftmanship (artisanat du logiciel, qui met l'accent sur les compétences de codage des développeurs) est assez nouvelle pour le datascientist peu au fait du développement. Cela implique une montée en compétences sur l'aspect DevOps, DataOps ». Au niveau des challenges, « le data engineering, c'est-à-dire exposer nos sources de données vers un datalake avec la prise en compte du legacy, de la gouvernance de la donnée. La partie cybersécurité est aussi un élément important à prendre en compte ».