Réussir une POC en data science
⏱ 5 minL’innovation en data science passe souvent par des Proofs of Concept (POC ou preuves de concept en français). De quoi tester l’efficience d’une solution via une réalisation expérimentale, tant du point de vue technique que fonctionnel. Mais de l’innovation à son implémentation concrète, les attentes et le niveau de maturité visés varient. Pourtant, que l’on parle d’une POC logicielle, d’une POC méthodologique, d’une expérimentation ou encore d’une démonstration, les garanties de mise en production des solutions découlent dans l’ensemble des mêmes bonnes pratiques. Et les échecs, des mêmes erreurs…
Apporter de la valeur ajoutée à l’entreprise. C’est le but affiché par un industriel quand il lance une POC. Vaste sujet ! Selon les interlocuteurs, en data science, cela peut signifier valider (ou non) des concepts fonctionnels, expérimenter un algorithme, livrer un prototype. Il peut s’agir aussi de vérifier la faisabilité de la technologie d’un client, ou encore de démontrer à ses clients la faisabilité de ses propres solutions… Si l’on se réfère à l’échelle de niveaux de maturité technologique TRL (Technology Readiness Level) qui en compte 9, les POC se limiteraient à TRL 3, quand les démonstrateurs vont jusqu’à 6, et l’industrialisation d’une solution à 9. Il n’en reste pas moins que tout le monde s’accorde pour dire qu’une POC réussie doit être mise, à terme, en production. Et dans tous les cas, rapidement, dans les 2 à 6 mois en général. Sinon, il s’agit d’un projet de recherche. Néanmoins une POC peut tout aussi bien aboutir à la conclusion que les objectifs sont hors d’atteinte.
Ingénierie logicielle ou solution algorithmique
Pour une société de conseil en ingénierie logicielle comme Xebia, la POC est une étape avant la mise en place de ce qu’ils appellent « l’usine logicielle data science » de l’entreprise : « Nous accompagnons les entreprises pour enchaîner les étapes qui mènent du POC au produit, en passant par un prototype, puis un MVP [Minimum Viable Product ou produit à fonctionnalité réduite, NDLR] », précise Yoann Benoît, data scientist et Chief Data Officer chez Xebia (voir le livre blanc de Xebia « TechTrends, produits data science » dans notre repository).
Pour des laboratoires publics de recherche, la POC a plutôt vocation à aboutir à une méthode mathématique ou algorithmique qui réponde à un problème posé, en général sans aller jusqu’à un prototype logiciel. « Les industriels se tournent vers nous lorsqu’ils cherchent une expertise scientifique, ou pour développer de nouvelles méthodes, explique Mathilde Mougeot, enseignante-chercheuse à l’ENSIEE (Ecole nationale supérieure d’informatique pour l’industrie et l’entreprise). Nous fournissons une solution de recherche appliquée, mathématique ou algorithmique, qui peut aller jusqu’au développement d’un démonstrateur logiciel. En tant que chercheurs, nous n’avons en général ni les moyens ni les compétences pour aller jusqu’à la phase de mise en production, même si certains labos de recherche le font. Pour aller plus loin, nous pouvons faire développer la méthode par des ingénieurs de recherche en informatique. »
« Les enjeux de production sont peu pris en compte par les académiques, remarque Frédéric Oblé, responsable d’un département R&D d’Atos/Worldline. Il en va de même de nos propres data scientists, qui n’ont pas forcément en tête toutes les contraintes inhérentes au déploiement en production de leurs algorithmes. » Il cite le cas de la détection de fraude qu’Atos Worldline cherche sans cesse à améliorer, notamment grâce à de l’intelligence artificielle, en conservant la même rapidité d’exécution. Par exemple, un algorithme issu de la recherche et conçu pour le traitement de séquences de transactions pour une carte donnée ne saura pas traiter correctement le cas de la transaction issue d’une carte nouvellement apparue dans le système.
Un problème bien posé
De même, si les chercheurs ne testent leurs algorithmes que sur des jeux de données de petite taille, il est probable qu’ils ne passent pas à l’échelle. « Nous sensibilisons nos data scientists aux impératifs de la production et nos ingénieurs IT à l’intérêt de collaborer avec des chercheurs que ce soit en interne ou sous contrat avec des laboratoires », poursuit Frédéric Oblé. « Nous vivons dans des univers différents, confirme Mathilde Mougeot (ENSIEE), il faut beaucoup d’humilité de part et d’autre pour mener un travail en commun et pour anticiper le passage à l’échelle de la solution. Pour éviter les dérives, il faut des échanges et des points réguliers. » Quoi qu’il en soit, il faut bien définir la problématique, l’objectif et les performances visées – ce qui est loin d’être simple –, ainsi que la disponibilité et la qualité des données. « On passe beaucoup de temps à partager nos objectifs, on a l’impression de se comprendre, mais le diable se cache dans la trivialité », reconnaît Frédéric Oblé.
Même son de cloche du côté des laboratoires de recherche : « La première étape, quand un industriel nous sollicite, est de retranscrire sa problématique métier en une problématique mathématique voire algorithmique, précise Mathilde Mougeot de l’ENSIEE. Dans le domaine de la data science, nous demandons aussi très tôt à l’industriel un jeu de données qui illustre sa problématique. À partir de l’étude approfondie et de l’exploitation de ce jeu de données, nous proposons une première solution. Dans certains cas, elle répond parfaitement aux exigences de l’industriel, mais il arrive également que l’étude conclut qu’il est difficile de répondre en l’état. Dans ce cas là, nous proposons une solution alternative, parfois dégradée, ou nous redéfinissons la problématique métier en collaboration avec l’industriel, ou encore nous préconisons d’enrichir les données. Et si la POC soulève des points mathématiques originaux à approfondir, nous lançons un projet de recherche sur une plus longue période : c’est une conséquence très intéressante des POC pour un chercheur. »
Elle cite par exemple les POC à base de transfer learning, sujet de recherche actif notamment dans le cadre de la chaire IDAML (Industrial Data Analytics and Machine Learning)Cette chaire, créée fin 2016, réunit le CMLA (ENS Paris-Saclay), Atos, le CEA, Bertin Technologies et l’ENSIEE. Elle a pour vocation l’analyse de données industrielles par machine learning. dont elle est titulaire. « Le transfer learning consiste à répondre à une question en exploitant au mieux les connaissances acquises (modèles ou données) dans le cas d’un problème voisin dont les données ne sont pas directement exploitables, explique-t-elle. Par exemple, détecter automatiquement les fraudes bancaires dans un pays en tirant parti de ce qui se serait fait avec les données d’un autre pays. » Ce genre de techniques promet d’accélérer les industrialisations.
Des modèles de plus en plus poussés à partir des mêmes données
Comment procèdent les sociétés d’ingénierie logicielle ? « Avant tout développement, nous réunissons experts techniques, experts-métiers, data scientists, développeurs, spécialistes de l’interface graphique si besoin, utilisateurs finaux… pour définir ensemble la problématique et la vision produit associée,explique Yoann Benoît de Xebia. Une POC répond à un besoin, elle ne doit pas être focalisée sur une technique – les algorithmes de machine learning ne sont pas une fin en soi ! – et un data lake n’en garantit pas le succès – il manquera une date de référence ici, une mise à jour là, une donnée ailleurs. »
« Pour lever les hypothèses les plus critiques pour la validation ou non de la faisabilité technique du cas d’usage, nous réalisons rapidement un prototype, en environ 2 semaines, poursuit-il. Nous mettons ensuite en production un MVP, un premier modèle naïf construit sur des règles métiers ou un modèle très basique, mais sur toute la chaîne de traitement des données, jusqu’au résultat final, en orchestrant les programmes de lecture de données, d’entraînement du modèle, de sauvegarde, de prédiction… On peut ensuite se concentrer sur la partie purement algorithmique et l’améliorer jusqu’au seuil de performance fixé. Mais il faut savoir s’arrêter et enclencher la mise en production. Au risque de devoir tout réimplémenter. »
Yoann Benoît souligne par ailleurs que les POC à base de machine learning introduisent une complexité croissante quant à l’historique de données de production à réunir et à la mise à disposition des modèles et résultats : « Il faut penser à préciser par qui le modèle sera appelé, si c’est en temps réel, en batch ou dans une API à la demande. Certaines techniques seront incompatibles avec ces contraintes, même si elles sont plus performantes. Il peut aussi être utile d’automatiser le ré-entraînement du modèle pour s’adapter à un environnement de données fluctuant. » Chaque POC est unique !
Isabelle Bellin