Préparation des champs, culture, traitement, récolte, acheminement, tri, emballage, préparation, … la liste est encore très longue avant que vous ne puissiez déguster votre produit.
Ceci est bien souvent imperceptible du grand consommateur mais les challenges à relever sont innombrables entre le champ et l’assiette.
Challenges d’autant plus compliqués à résoudre avec les enjeux qui courent :
Nourrir 7,7 Milliards d’humain sur Terre avec une tendance à la hausse de 1,2% par an,
Mieux répartir les denrées alimentaires pour éviter les gâchis aberrant et les famines navrantes,
Jongler avec un climat capricieux qui joue avec les extrêmes entre sécheresse et inondation,
Mieux manger avec une exigence réglementaire de traçabilité mais également impulsé par les consommateurs soucieux d’inverser la tendance,
Pour être efficace il faut agir sur chacun des maillons de la chaîne Production – Supply Chain – Vente tout en ayant une approche holistique.
Plusieurs révolutions ont bouleversé ces champs d’activité ces dernières décennies, une autre est en marche il s’agit de l’Internet Of Things.
L’IoT dans le champ : Agriculture 4.0
La production de denrées alimentaires est un secteur critique répondant à notre besoin primaire de se nourrir. Vous, moi, nous sommes désormais tous quasi dépendants de cette production qu’elle soit agricole, piscicole, …
Il faut optimiser les productions tout en respectant dame nature et ses ressources mais également les consommateurs finaux en garantissant une nourriture saine et de qualité.
La culture intensive est toujours très utilisée de par le monde mais aux vues des dégâts engendrés, des méthodes plus respectueuses ont émergé : agriculture raisonnée, durable, biologique, mais elles ne sont pas forcément viables dans tous les contextes (la perte de production pouvant se traduire par une perte de rentabilité sur un secteur déjà difficile et malmené).
C’est là que les nouvelles technologies et l’IoT entrent en jeu.
A bien des égards il peut être aberrant et contre nature de barder de capteurs cette dernière.
Et pourtant, quelques capteurs/actionneurs connectés …
… bien localisés avec une empreinte faible sur l’écosystème constituent un important levier d’optimisation pour :
Prédire la météo (à l’échelle de l’exploitation) et agir en conséquence,
Optimiser l’utilisation des ressources (eau, électricité, traitement, nourriture, …) en répondant au juste besoin (en quantité et en temporalité),
Déceler les comportements anormaux et les prémisses de maladies pour intervenir en anticipation,
Contribuer au bien être animal,
Identifier précisément les niveaux de maturation pour récolter au bon moment et limiter les pertes,
Préserver la qualité de la marchandise stockée,
Connaître en temps réel le stock disponible,
Diminuer la pénibilité du travail en automatisant certaines activités,
Limiter la pollution, l’usage de la biochimie (pesticide), et l’impact sur la faune et la flore.
La GreenTech rayonne de plus en plus avec des solutions innovantes et diversifiées, que ce soit sur les objets connectés eux mêmes mais également sur les plateformes IoT spécialisées (Sencrop, Libelium, Observant, Agrilab.io, pycno, arable, …).
En France, la valorisation des données Agricoles est lancée, la société API AGRO a créé une place de marché (AgDataHub) permettant aux éditeurs de services digitaux, notamment les start-up, de co-développer de nouvelles applications web et mobiles pour l’agriculture numérique.
Bien que ce paroxysme de la maîtrise de l’environnement et de la réutilisation des ressources en circuit fermé est parfaitement atteint dans les cultures hydroponiques, ces moyens technologiques peuvent trouver leur place dans tous types de production de par leur polyvalence d’emploi et leur facilité de mise en œuvre.
L’IoT dans la Supply Chain : Industrie 4.0
2 tonnes de poissons frais arrivent au port, 1 tonne de fraises sortent de l’exploitation, la course contre la montre démarre pour mettre ces denrées sensibles et périssables à disposition des consommateurs finaux.
La Supply Chain entre dans la danse avec son infrastructure (Entrepôts, chaînes mécanisées, poids lourds, camionnettes réfrigérées, …), ses processus très normés et son lot d’enjeux :
Comment garantir la chaîne du froid : pas uniquement au niveau du contenant (palette) mais également au niveau du contenu (poisson) lui-même ?
Comment géolocaliser mes flux d’entrées/sorties de marchandise ?
Comment optimiser le temps de transport et éviter les retards ?
Comment automatiser le rapprochement de données entre marchandises commandées et marchandises livrées ?
Comment garantir la qualité de mon aliment fragile à son arrivée à destination ?
…
L’accessibilité, l’autonomie et la performance des capteurs IoT couplés à un réseau 0G (LPWAN) peuvent faire des miracles …
Equiper vos moyens de transports et vos containers d’un tracker GPS pour :
les suivre en temps réel et adapter les parcours et moyens à mettre en oeuvre en fonction des aléas rencontrés sur le trajet,
gérer vos flux intermodaux d’entrée/sortie,
garantir la disponibilité de vos moyens de transport pour la prise en charge d’une nouvelle marchandise,
Placer des capteurs de températures / hygrométrie dans vos moyens de transport mais également au coeur de la marchandise pour agir au besoin sur les équipements de régulation afin de préserver la qualité des produits et garantir le respect de la chaîne du froid,
Installer des capteurs de mouvement et vibration pour déceler le malmenage de vos marchandises et :
agir en conséquence auprès de vos équipes, équipements et partenaires,
router la marchandise abîmée sur une voie parallèle plutôt que de la livrer à la poubelle
Étiqueter vos Unités de Conditionnement avec des tags RFID pour automatiser l’identification et le calcul de la quantité de marchandises reçues.
… en intégrant cet écosystème IoT au Système d’Information Supply (Warehouse Management System, Warehouse Control System, Manufacturing Execution System), l’ensemble devient connecté, plus efficient et proactif face aux défis et aléas à relever.
L’IoT en point de vente
Malgré la forte progression de l’e-commerce, 90% des ventes sont toujours réalisées dans les points de vente (PDV) physiques.
Ces derniers, en passant leurs commandes de marchandises, se positionnent en clients des deux précédents maillons (Production et Supply Chain).
Ils ont donc une responsabilité certaine sur :
la répartition des produits alimentaires,
le gâchis alimentaire
Mais également des exigences fortes sur la performance et l’agilité des deux précédents maillons pour obtenir de la marchandise de qualité en temps et en heure convenus.
Les points de vente ont finalement trois enjeux fondamentaux :
Piloter finement leur stocks pour à la fois :
éviter les ruptures qui engendrent un manque à gagner sur les ventes manquées et une insatisfaction client,
éviter le sur-stockage qui coûte cher et peut générer un important gâchis alimentaire
Vendre une marchandise de qualité pour…
… Satisfaire et fidéliser les clients.
Là encore les acteurs de l’IoT ont su cerner ces cas d’usage et proposer des solutions aux Retailers pour optimiser les processus clés de leur métier :
Utiliser des racks, étagères, présentoirs connectés afin de connaitre l’état réel des stocks en rayon pour optimiser le processus d’achalandage et de réapprovisionnement,
Utiliser des armoires réfrigérées connectées permettant de monitorer finement leur bon fonctionnement afin d’ intervenir rapidement en cas de panne et ainsi éviter les pertes de marchandises sensibles,
Remplacer les étiquettes papiers par des étiquettes électroniques connectées afin d’optimiser les processus d’affichage des prix de vente mais également pour afficher des informations recherchées par les consommateurs (traçabilité, ….)
Utiliser des caméras connectées (sous réserve d’autorisation) pour analyser la fréquentation, le comportement des consommateurs en fonction de la période et adapter en conséquence les commandes de marchandises,
Donner de l’autonomie aux clients pour que leur parcours de courses et d’achat soit agréable et efficace avec des solutions de self scanning, de panier connecté ou de casier connecté pour le retrait de marchandises en Click & Collect.
L’IoT sur chacun des maillons de la chaîne (Production, Supply, Retail) a su s’adapter et décliner des solutions efficaces pour répondre à leurs enjeux propres. Le challenge à relever pour atteindre l’efficience de l’ensemble, réside dans la capacité de chacun des maillons à s’intégrer (partage de données IoT/métier) avec les autres pour créer un écosystème connecté et intelligent au service du “mieux manger” et d’un environnement durable.
« La data actif essentiel et incontestable de nombreuses organisations ».
Il suffit de poursuivre cette phrase en citant 2 ou 3 chiffres clefs de grands cabinets de conseil en stratégie, et voilà l’argument d’autorité posé… Oui mais quand on a dit ça, hé bien, qu’est-ce qu’on en fait ?
« La data » est en effet transverse aux entités d’une organisation, source d’opportunités commerciales, d’innovation ou de relation client de qualité, mais elle est bien souvent jugée comme un sujet technique ou abstrait. Le rôle de CDO est encore récent dans de nombreuses organisations : il lui faut trouver sa place et la meilleure articulation avec les Métiers, la DSI, mais aussi la Direction Générale. Il y a donc un enjeu à ce que ce dernier asseye son rôle stratégique dans toute organisation qui veut gérer ses données comme des actifs stratégiques. Le Chief Data Officer a un rôle clef, transverse et à de multiples facettes pour exploiter pleinement le potentiel que représentent les données : compétences humaines, techniques et de leadership. Il doit incarner la transformation vers un mode d’organisation orienté données.
Constructeur de fondations stables
Partons du plus évident (mais pas forcément du plus simple !). Pour toute construction il faut des fondations stables, hé bien avec la data c’est pareil. Des « datas », objets parfois suspects et mal identifiés, sont stockées un peu partout dans les bases de données des entreprises, des Sharepoint collaboratifs ou des fichiers Excel sur le disque dur des collaborateurs… La clef sera dans un premier temps de maîtriser et de sécuriser ces données. Le CDO doit impulser cette dynamique, s’assurer que les données soient connues (recensement dans un data catalog par exemple), accessibles (stockage efficient ), de qualité (règle de gouvernance des données avec des data owners), conformes aux réglementations et à l’éthique (RGPD ou autre) et répondent à des cas d’usages simples et concrets (avant de vouloir faire de l’IA ne faut-il pas que les reporting opérationnels les plus basiques et indispensables soient bien accessibles par les bonnes personnes au bon moment et avec le bon niveau de qualité ?).
Le CDO : architecte et chef d’orchestre
Le Chief Data Officer doit être l’architecte (rôle opérationnel) et le chef d’orchestre (rôle stratégique) de ces projets de fondations en concertation avec les métiers et l’IT. Avec son équipe, il doit accompagner les métiers pour répondre aux usages à valeur et avancer de façon pragmatique. Rien ne sert de lancer 12 projets stratégiques sur la data en même temps : apporter des preuves concrètes en traitant de façon pertinente 2 ou 3 cas d’usages clefs pour améliorer les enjeux opérationnels et vous pouvez être certain que la dynamique métier autour de votre transformation data sera bien mieux lancée ! Il en est de même pour l’IT : il doit aussi soigner sa relation avec la DSI avec laquelle il doit travailler sur des solutions concrètes nécessaires à la mise en œuvre de sa vision data et des usages métiers.
Le Chief Data Officer doit être fédérateur
Le CDO n’a pas nécessairement pour vocation à prendre en charge lui-même l’ensemble des sujets qui traitent de la donnée. Les métiers doivent être des acteurs de première ligne sur le sujet. Le CDO s’intègre régulièrement à un existant désordonné, où les sujets sont déjà plus ou moins traités, mais de façon dispersée. Il doit apporter la vision transverse tout en laissant de l’autonomie aux métiers. Dans la mesure où les équipes data se sont constituées et professionnalisées dans les grands groupes, l’enjeu se déplace aujourd’hui vers la capacité à faire travailler ensemble tous les départements de l’organisation. L’acculturation de l’entreprise et la formation des équipes sont au cœur des enjeux du CDO en 2021.
En résumé : le Chief Data Officer doit faire preuve de savoir-faire mais aussi de savoir-être. Il doit incarner la vision, adosser son action au sponsorship inconditionnel de la Direction Générale, tout en restant au contact des équipes métier et en travaillant avec bonne intelligence avec les équipes IT.
Chiefs Data Officers, si vous n’aviez qu’une idée à retenir de cet article : pour en tirer sa valeur, la data doit pouvoir être expliquée et comprise par ma grand-mère (et je précise que ma grand-mère n’est pas data scientist !) ; visez le pragmatisme et les sujets à valeur immédiate pour votre organisation. Cela fondera le socle indispensable de votre transformation data dans la durée : expériences, résultats concrets et crédibilité !
Les idées exposées ici sont peut-être évidentes pour certains, utiles pour d’autres ! En tout cas, chez Rhapsodies Conseil, au sein de notre équipe Transformation Data, nous essayons d’appliquer cela systématiquement, et nous pensons que c’est le minimum vital.
A l’heure de l’omniprésence algorithmique dans une multitude de domaines de notre société, une commission européenne dédiée publiait, il y a un an déjà, un livre blanc mettant en lumière le concept d’IA de confiance. Si ce concept englobe une multitude de notions et d’axes de réflexion (prise en compte des biais, robustesse des algorithmes, respect de la privacy, …), nous nous intéresserons ici particulièrement à la transparence et l’explicabilité des systèmes d’IA. Dans cette optique et après un rappel des enjeux et challenges de l’explication des modèles, nous construirons un simple tableau de bord rassemblant les principales métriques d’explicabilité d’un modèle, à l’aide d’une librairie Python spécialisée : Explainer-Dashboard.
Vous avez dit “explicabilité” ?
L’IA Explicable est l’intelligence artificielle dans laquelle les résultats de la solution peuvent être compris par les humains. Cela contraste avec le concept de «boîte noire» où parfois même les concepteurs du modèle ne peuvent pas expliquer pourquoi il est arrivé à une prédiction spécifique.
Le besoin d’explicabilité de ces algorithmes peut être motivé par différents facteurs :
la confiance des utilisateurs et personnes concernées en leur justesse et en l’absence de biais ;
l’obligation réglementaire de pouvoir justifier et expliquer toute décision prise sur recommandation de l’algorithme : si le RGPD prévoit vaguement que toute décision prise par une IA doive être expliquée à la personne concernée sur demande, la loi française est bien plus précise. En prévoyant la mise à disposition d’informations concernant le degré et le mode de contribution du traitement algorithmique à la prise de décision, les données traitées et leurs sources, les paramètres de traitement et, le cas échéant, leur pondération, appliqués à la situation de l’intéressé et les différentes opérations effectuées par le traitement. Les secteurs bancaires et assurantiels sont particulièrement surveillés sur le sujet, notamment via l’action de l’ACPR.
Quand on adresse cette problématique, il convient de définir les différents termes (étroitement liés) que l’on peut retrouver :
La transparence donne à comprendre les décisions algorithmiques : elle traduit une possibilité d’accéder au code source des algorithmes, aux modèles qu’ils produisent. Dans le cas extrême d’une opacité totale, on qualifie l’algorithme de « boîte noire » ;
L’auditabilité caractérise la faisabilité pratique d’une évaluation analytique et empirique de l’algorithme, et vise plus largement à obtenir non seulement des explications sur ses prédictions, mais aussi à l’évaluer selon les autres critères indiqués précédemment (performance, stabilité, traitement des données) ;
L’explicabilité et l’interprétabilité, que l’on peut distinguer comme suit :
Si l’on considère des travaux de chimie au lycée, une interprétabilité de cette expérience serait “on constate un précipité rouge”. De son côté, l’explicabilité de l’expériencenécessitera de plonger dans les formules des différents composants chimiques.
Note : dans un souci de simplification, nous utiliserons largement le terme “explicabilité” dans la suite de cet article.
Via l’explication d’un modèle, nous allons chercher à répondre à des questions telles que :
Quelles sont les causes d’une décision ou prédiction donnée ?
Quelle est l’incertitude inhérente au modèle ?
Quelles informations supplémentaires sont disponibles pour la prise de décision finale ?
Les objectifs de ces explications sont multiples, car dépendants des parties prenantes :
faciliterles échanges itératifs avec les métiers, en imageant rapidement comment le modèle utilise les variables d’entrée pour répondre au problème posé ;
rassurerles experts métiers et les équipes en charge de la conformité sur l’absence de biais algorithmique ;
faciliter la validation du modèle par les équipes de conception et de validation ;
garantir la confiance des individus impactés par les décisions ou prédictions de l’algorithme.
Et concrètement ?
Le caractère “explicable” d’une IA donnée va principalement dépendre de la méthode d’apprentissage associée. Les méthodes d’apprentissage sont structurées en deux groupes conduisant, selon leur type, à un modèle explicite ou à une boîte noire :
Dans le cas d’un modèle explicite (linéaire, gaussien, binomial, arbres de décision,…), la décision qui en découle est nativement explicable. Sa complexité (principalement son nombre de paramètres) peut toutefois endommager son explicabilité ;
La plupart des autres méthodes et algorithmes d’apprentissage (réseaux neuronaux, agrégation de modèles, KNN, SVM,…) sont considérés comme des boîtes noires avec néanmoins la possibilité de construire des indicateurs d’importance des variables.
Lors du choix d’un modèle de Machine Learning, on parle alors du compromis Performance / Explicabilité.
Récupérer les données et entraîner un modèle simple
Pour cette démonstration, notre cas d’usage analytique sera de prédire, pour un individu donné, le risque d’occurrence d’une défaillance cardiaque en fonction de données de santé, genre, âge, vie professionnelle, …
Si cette problématique ne revêt pas spécifiquement d’aspect éthique relatif à la transparence de l’algorithme utilisé, nous pouvons toutefois bien percevoir l’utilité de l’explicabilité d’un diagnostic de risque assisté par IA : collaboration facilitée avec l’expert métier (en l’occurrence, le médecin) et information plus concrète du patient, entre autres bénéfices.
Le jeu de données éducatif utilisé est fourni par l’OMS et peut être téléchargé sur la plateforme de data science Kaggle :
Il contient les données de 5110 personnes, réparties comme suit :
Données :
Age du sujet ;
Genre du sujet ;
A déjà souffert d’hypertension (oui / non)
A déjà souffert de maladies cardiaques (oui / non)
Statut marital
Type d’emploi
Type de résidence (citadin, rural)
Niveau moyen sanguin de glucose
IMC
Fumeur (oui / non)
Note : nous avons procédé à une simple préparation des données qu’il est possible de retrouver dans le notebook complet en bas de page.
Pour la partie modélisation, nous utiliserons un modèle « baseline » de Random Forest. Pour éviter que notre modèle ne reflète seulement que la distribution des classes (très déséquilibrée dans notre cas, 95-5), nous avons ajouté des données “synthétiques” à la classe la moins représentée (i.e. les patients victimes de crises cardiaques) en utilisant l’algorithme SMOTE, pour atteindre une répartition équilibrée (50-50) :
Notre modèle est prêt, nous pouvons à présent l’utiliser en input du dashboard !
Création du dashboard
Nous avons donc à disposition un modèle entraîné sur notre dataset et allons à présent construire notre tableau de bord d’interprétation de ce modèle.
Pour ce faire, nous utilisons la librairie explainer-dashboard, qui s’installe directement via le package installer pip :
pip install --upgrade explainerdashboard
Une fois la librairie installée, nous pouvons l’importer et créer simplement une instance “Explainer” à l’aide des lignes suivantes :
Plusieurs modes d’exécution sont possibles (directement dans le notebook, dans un onglet séparé hébergé sur une IP locale, …) (plus d’informations sur les différents paramètres de la librairie dans sa documentation).
Note : le dashboard nécessitera d’avoir installé la librairie de visualisation “Dash” pour fonctionner.
Interprétation des différents indicateurs
Le tableau de bord se présente sous la forme de différents onglets, qu’il est possible d’afficher / masquer via son paramétrage :
Features importance : impact des différents features du jeu de données sur les prédictions ;
Classification Stats : aperçu complet de la performance du modèle de classification utilisé (ici, Random Forest) ;
Individual Predictions & What if analysis : zoom sur les prédictions individuelles et influence des features sur ces dernières ;
Features dependance : visualisation de l’impact de couples de features sur les prédictions et corrélations entre features ;
Decision Trees : permet, pour les modèles à base d’arbres de décision, de visualiser les paramètres et cheminement de décisions de chacun de ces arbres.
Plongeons à présent dans les détails de chacun de ces onglets !
Features Importance
A l’instar de l’attribut feature_importances_ de notre modèle de Random Forest, cet onglet nous permet de visualiser, pour chaque colonne de notre dataset, le pouvoir de prédiction de chaque variable.
L’importance des features a ici été calculée selon la méthode des valeurs de SHAP (acronyme de SHapley Additive exPlanations). Nous n’approfondirons pas ce concept dans cet article (voir rubrique “aller plus loin”).
Ces scores d’importance peuvent permettre de :
Mieux comprendre les données à disposition et ainsi, avec l’aide d’un expert métier, détecter lesquelles seront les plus pertinentes pour notre modèle ;
Mieux comprendre notre modèle et son fonctionnement, puisque les scores d’importance peuvent varier en fonction du modèle choisi ;
En phase d’optimisation de celui-ci, diminuer son nombre de variables pour en réduire sa durée d’entraînement, en augmenter son explicabilité, faciliter son déploiement ou encore atténuer le phénomène d’over-fitting.
Dans l’exemple ci-dessous, on peut constater que :
l’âge, l’IMC et le niveau moyen de glucose dans le sang sont des prédicteurs forts du risque de crise cardiaque, ce qui correspond bien à une intuition commune ;
Toutefois, d’autres prédicteurs forts sortent du lot, comme le fait de ne jamais avoir été marié ou encore le fait d’habiter en zone rurale, qui ne sont pas évidents à première vue …
Classification Stats
Cet onglet nous permet de visualiser les différentes métriques de performance de notre modèle de classification : matrice de confusion, listing des différents scores, courbes AUC, … Il sera utile en phase de paramétrage / optimisation du modèle pour avoir un aperçu rapide et complet de sa performance :
Individual Predictions
Cet onglet va nous permettre, pour un individu donné, de visualiser les 2 indicateurs principaux relatifs à la décision prise par le modèle :
Le graphe des contributions :
La contribution d’un feature à une prédiction représente l’impact probabilistique sur la décision finale de la valeur de la donnée considérée.
Suite à notre traitement du déséquilibre des classes, nous avons autant de sujets “sains” que de sujets “à risque” dans notre jeu de données d’apprentissage. Un estimateur aléatoire aura donc 50% de chances de trouver la bonne prédiction. Cette probabilité est donc la valeur “baseline” d’entrée dans notre graphe des contributions.
Ensuite, viennent s’ajouter en vert sur le visuel les contributions des features pour lesquelles la valeur a fait pencher la décision vers un sujet “à risque”. Ces features et leur contribution amènent la décision à une probabilité de ~60% de risque.
Puis, les features dont la contribution fait pencher la décision vers un sujet “sain” viennent s’ajouter (en rouge sur le graphe). On retrouve ici nos prédicteurs forts tels que l’âge ou encore l’IMC.
> Le sujet est proposé comme sain par l’algorithme
Le graphe des dépendances partielles :
Ce visuel nous permet de visualiser la probabilité de risque en fonction de la variation d’une des features, en conservant la valeur des autres constantes. Dans l’exemple ci-dessus, on peut voir que pour l’individu considéré, augmenter son âge aura pour effet d’augmenter sa probabilité d’être détecté comme “à risque”, ce qui correspond bien au sens commun.
What if Analysis
Dans l’optique de l’onglet précédent, l’analyse “what if” nous permet de renseigner nous mêmes les valeurs des différents features et de calculer l’output du modèle pour le profil de patient renseigné :
Il reprend par ailleurs les différents indicateurs présentés dans l’onglet précédent : graphe des contributions, dépendances partielles, …
Features Dependance
Cet onglet présente un graphe intéressant : la dépendance des features.
Il nous renseigne sur la relation entre les valeurs de features et les valeurs de SHAP. Il permet ainsi d’étudier la relation générale entre la valeur des features et l’impact sur la prédiction.
Dans notre exemple ci-dessus, le nuage de points nous apprend deux choses :
L’âge (abscisses) est un fort prédicteur pour notre cas d’usage car, pour chaque observation, les valeurs de SHAP (ordonnées) sont élevées (mais nous le savions déjà). On remarque une inversion de la tendance autour de l’âge de 50 ans, ce qui conforte notre intuition (i.e. les sujets plus jeunes sont moins enclins à être considérés comme “à risque”) : une valeur de SHAP “hautement négative” nous indique que la feature est un prédicteur fort d’un résultat associé à la classe nulle (ici, un individu désigné comme “sain”) – à l’inverse, une valeur de SHAP “hautement positive” indique que la feature est un prédicteur fort d’un résultat associé à la classe positive (ici, un individu désigné comme “à risque”).
L’âge est fortement corrélé au statut marital des individus observés (points rouges = individus célibataires). Cela est cohérent avec le sens commun mais nous renseigne également sur le pouvoir prédictif du statut marital qui ne serait finalement dû qu’à sa forte corrélation à l’âge, vrai prédicteur important de notre problématique. Dans une optique d’optimisation du modèle, cette feature pourrait potentiellement être retirée.
Decision Trees
Enfin, dans le cas où l’input du dashboard est un modèle à base d’arbres de décisions (gradient boosted trees, random forest, …), cet onglet sera utile pour visualiser le cheminement des décisions de la totalité des arbres du modèle.
Dans l’exemple ci-dessous, nous considérons le 2712ème individu du jeu de données pour lequel 50 arbres ont été calculés via l’algorithme de Random Forest. Nous visualisons la matrice de décision de l’arbre n°13 :
Ce tableau nous montre le cheminement de la décision, depuis une probabilité de ~50% (qui serait la prédiction d’un estimateur ne se basant que sur la moyenne observée sur le jeu de données). On peut constater que, pour cet individu et pour l’arbre de décision considéré :
La ruralité, l’occupation professionnelle et le statut marital (bien que démontré précédemment comme prédicteur faible) ont poussé la décision de cet arbre vers “individu à risque” ;
Les autres données de l’individu telles que son genre ou encore son âge ont fait basculer la décision finale de l’arbre à “individu sain” (probabilité de risque finale : 7.14%).
L’onglet nous propose également une fonctionnalité de visualisation des arbres via la librairie graphviz.
L’étude des différents indicateurs présentés dans les onglets du dashboard nous a permis :
De confirmer des premières intuitions sur les variables importantes de ce problème de modélisation : l’âge du patient, son IMC ou encore son taux moyen de glucose ;
A l’inverse, de conclure de la pertinence relativement moindre de variables telles que le statut marital (merci à la dépendance des features !), le statut professionnel, le lieu de résidence mais également les antécédents cardiaques (moins évident à priori…). On pourra alors se poser la question de conserver ou non ces variables dans une optique de simplification du modèle ;
De mesurer la performance globale du modèle et, derrière une accuracy honorable de ~0.80, de découvrir de pauvres recall et precision (respectivement 0.44 et 0.14) : notre modèle est donc plus performant pour détecter les Vrais Négatifs (les sujets “sains”) que les sujets réellement à risque. Il faudra travailler à l’optimiser autrement.
De procéder à des analyses de risque et de comportement du modèle sur un patient donné via l’interface de l’onglet “What if…”.
L’étude de ces indicateurs doit être partie intégrante de tout projet d’IA actuel et futur
L’explicabilité des modèles de Machine Learning, aujourd’hui considéré comme l’un des piliers d’une IA éthique, responsable et de confiance, représente un challenge important pour accroître la confiance de la société envers les algorithmes et la transparence de leurs décisions, mais également la conformité réglementaire des traitements en résultant.
Dans notre cas d’étude, si la librairie explainer-dashboard est à l’initiative d’un particulier, on remarque une propension à l’éclosion de plusieurs frameworks et outils servant le mouvement “Fair AI”, dont plusieurs développés par des mastodontes du domaine. On peut citer le projet AIF360 lancé par IBM, une boîte à outils d’identification et de traitement des biais dans les jeux de données et algorithmes.
Cette librairie est utile en phase de développement et d’échanges avec le métier mais peut toutefois ne pas suffire en industrialisation. Alors un dashboard “maison” sera nécessaire. Elle a toutefois un potentiel élevé de personnalisation qui lui permettra de répondre à de nombreux usages.
La data science est devenue un levier clé aujourd’hui, pour mettre les données au service de bénéfices et de problématiques métiers : Automatisation de tâches & de choix, Fourniture de nouveaux services « intelligents », Amélioration de l’expérience client, Recommandations, etc.
C’est aussi une discipline qui passionne par son caractère particulièrement « innovant », encore aujourd’hui, mais qui génère des croyances sur ce qu’elle peut réellement apporter à une organisation. Certains dirigeants ont souvent donné trop de valeur intrinsèque à la discipline, s’attendant à des retours importants sur leurs investissements (data lake & armées de data scientist / engineers).
En réalité, la Data Science n’est qu’une technique qui a besoin de méthodologie et de discipline. A ce titre, elle nécessite au préalable de très bien définir les problèmes métiers à résoudre. Et quand bien même le problème est bien défini, et le modèle statistique pour y répondre performant, cela ne suffit pas encore. Le modèle doit être utilisable « en pratique » dans les processus métiers opérationnels, s’intégrer parfaitement dans l’expérience utilisateur, etc.
Quels principes clés peut-on se proposer d’appliquer pour maximiser la valeur de cette capacité ? Essayons ici de donner quelques pistes.
Comprendre le métier : analyser les risques, les besoins d’optimisation, les nouvelles opportunités
L’identification d’usages métier, qui nécessitent des méthodes d’analyse de données avancées, est une étape clé. Ces usages ne tombent souvent pas du ciel. Une démarche proactive avec les métiers est nécessaire pour les identifier. C’est d’autant plus vrai lorsque le métier est encore peu familiarisé avec les techniques de data science, et ce qu’il est possible d’en tirer concrètement.
C’est un travail de “business analysis”, dont la Data Science n’a absolument pas le luxe de se passer contrairement à ce qui est pratiqué parfois : Comment travaille le métier aujourd’hui ? Quels sont ses enjeux, ses drivers, ses axes d’innovation, ses axes d’optimisations des processus opérationnels en place, et quelles données sont manipulées aujourd’hui, comment et pour quoi faire ? Quel est le niveau de qualité de la donnée, manque-t-il des informations clés pour répondre aux problèmes quotidiens, ou pour innover ? etc.
Quand on est au clair sur toutes ces questions, on est prêt à identifier des usages concrets avec le métier, qui pourraient bénéficier de techniques d’analyse avancée.
Comprendre l’usage et le système concerné : adopter le point de vue systémique !
Imaginons que nous cherchons à prédire le flux de patients sur un jour donné dans un hôpital, afin d’adapter les ressources, les processus, les dispositifs pour limiter le temps d’attente. Il convient, avant de foncer tête baissée dans l’analyse des données, de comprendre l’ensemble de la problématique. Par exemple, les approches de « system thinking » peuvent être tout à fait adaptées pour que le data scientist s’assure de ne pas oublier de paramètres clés dans la dynamique du problème qu’il veut résoudre. Ainsi, il n’oubliera pas non plus des données clés pour son modèle (existantes ou dont il faudrait organiser la collecte à l’avenir pour améliorer le modèle).
Ce type de représentation (ici : Causal loop diagram), peut permettre au métier de s’exprimer sur le processus, sur l’identification des variables clés, et de formuler ses intuitions sur les paramètres et les dynamiques en jeu qui peuvent influer sur la variable à prédire ! (ici les influences positives ou négatives entre les variables structurantes décrivant la dynamique du système).
Le diagramme ci-dessus n’est qu’un exemple de représentation systémique, on peut adopter d’autres types de représentation du système au besoin. L’important étant d’étendre la compréhension du système, qui peut nous amener à identifier des variables cachées (non intuitives a priori).
Concrétiser un usage : prototyper au plus tôt avec le métier, dans son environnement de travail, au risque de rester éternellement au statut de POC !
Une fois que le système est bien défini, et que les hypothèses et intuitions sont posées, il faut comprendre : comment le modèle analytique sera concrétisé en pratique, qui sera l’utilisateur final, quel est son environnement de travail actuel et comment on pourra intégrer les résultats d’un modèle statistique dans son travail quotidien.
Une technique simple et confortable pour le métier : faire un prototype rapide, même avec des fausses données pour commencer, des faux résultats de modèles statistiques. Bref, l’idée est rapidement de se projeter dans l’usage final de la manière la plus concrète possible, pour aider le métier à s’inscrire dans sa future expérience. Évidemment, nous ne resterons pas éternellement avec des fausses données.
L’objectif est d’être tout à fait au clair, dès le départ, sur le produit fini que l’on veut atteindre, et de s’assurer que le métier le soit tout à fait (ce qui est loin d’être toujours le cas). Ensuite, nous pourrons pousser le prototype plus loin (des vrais données, des vraies conditions pour évaluer la performance, etc.).
Cette méthode permet au data scientist de se mettre à la place de l’utilisateur final, et de mieux comprendre comment son modèle devra aider (est-ce qu’il doit apporter juste une classification, un niveau de probabilité, des informations contextuelles sur la décision prise par le modèle, est-ce qu’il doit favoriser le temps de réponse, l’explicabilité, la performance du modèle, etc.). Toutes ces questions trouvent rapidement une réponse quand on se projette dans le contexte d’usage final.
Interagir par itération avec le business, éviter l’effet Kaggle
Nous pouvons rencontrer parfois un comportement (compréhensible), qui est de vouloir faire le modèle le plus performant possible, à tout prix. On passe des heures et des jours en feature engineering, tuning du modèle, on tente toutes combinaisons possibles, on ajoute / teste des données exotiques (au cas où) qui ne sont pourtant pas identifiées en phase de “business analysis”. Je l’appellerai l’effet « Data Challenge » ou l’effet « KAGGLE*».
Et après avoir passé des jours enfermés dans sa grotte, on arrive tout fier devant le métier en annonçant une augmentation de 1% du score de performance du modèle, sans même avoir songé que 1% de moins pourrait tout à fait répondre aux exigences du métier… Comme on dit… « Le mieux est l’ennemi du bien ». Pour éviter cet effet tunnel qui peut être tentant pour l’analyste (qui veut annoncer le meilleur score à tout prix ou qui joue trop sur Kaggle*), des itérations les plus fréquentes possibles avec le métier sont clés.
Arrêtons-nous au bon moment ! Et cela vaut pour toutes les phases du projet. Commençons par chiffrer le système décrit en phase de business analyse, avec des données réelles, et itérons avec le métier sur cette base. Cela permet d’améliorer déjà la compréhension du problème du data scientist, et du métier concerné. Et cela a déjà une vraie valeur pour le métier ! Alors qu’aucun modèle statistique n’a été conçu pour le moment.
Si un modèle nécessite des données inexistantes, organisons la collecte de ces données avec le Chief data officer, dans le temps. Mais ne nous battons pas à vouloir faire un modèle avec des miettes, si nous savons que cela ne permettra pas d’être à la hauteur des attentes opérationnelles.
Le Data Scientist peut avoir aussi ce réflexe un peu étrange de dire « On va essayer, on va faire avec ce qu’on a et on verra ! » comme s’il croyait lui-même que son métier relève de l’incantation.
Evidemment, je ne fais là aucune généralité. Le rôle d’expert nous oblige à prendre nos responsabilités, et à dire « Non, après examen et quelques tests, je ne suis pas confiant du tout pour répondre à votre besoin avec les données qu’on a aujourd’hui ». Humilité, responsabilité et transparence, à chaque itération avec le métier, sont de mise.
On trouve souvent ce risque de dérive dans la relation Expert vs Métier. Ne tombons pas dans le piège de jouer sur l’ignorance de l’autre pour se créer un travail inutile !
Ces quelques principes sont peut-être évidents pour certains, utiles pour d’autres ! En tous les cas, chez Rhapsodies Conseil, au sein de notre équipe Transformation Data, nous essayons d’appliquer cela systématiquement, et nous pensons que c’est le minimum vital.
Pour éviter de faire perdre du temps à nos clients (et de l’argent), nous commençons nos missions BI & Analytics, systématiquement avec une « micro mission » préliminaire qui nous permet de valider la réelle valeur & la faisabilité de l’innovation recherchée (avec toutes les parties prenantes, en faisant des analyses flash des données…) avant d’aller plus loin !
Nous considérons que dans tout projet de Data Science, le prototype métier, tel que décrit dans l’article, est obligatoire. Nous proposons systématiquement un prototypage métier, toujours dans le soucis de bien projeter la valeur attendue pour le métier !
Nous allons plus loin sur la solution que l’analyse avancée des données. Notre expertise globale sur la transformation data, nous permet y compris sur des missions BI & Analytics, de ne pas hésiter à relever si pertinents des axes clés d’amélioration sur la gouvernance de certaines données, l’organisation, la data quality, la stratégie data long terme de l’organisation ou la culture data de l’entreprise, qui pourraient être profitables ou indispensables à l’usage traité.
Pour nous, traiter un usage BI & Analytics, c’est le traiter dans son ensemble, de manière systémique ! Notre solution finale n’est pas un modèle statistique. Notre solution finale est potentiellement un modèle statistique, mais aussi une gouvernance adaptée pour avoir la qualité de données nécessaire, un modèle qui s’adapte à l’expérience utilisateur souhaitée (et pas l’inverse), et un suivi du ROI de l’usage analytique et de sa pertinence par rapport à la stratégie de l’entreprise.
J’ai eu le plaisir d’introduire la table ronde « Le futur du paiement de proximité », organisée par le groupe de travail Perspectives & Innovations du France Payment Forum. J’ai présenté une synthèse des différents éléments qui pourraient favoriser la construction de nouveaux parcours utilisateurs en proximité, à commencer par l’émergence et le développement des schemes de Real Time Payment
En effet, depuis le Zengin japonais lancé en 1973, les schemes de paiement en temps réel n’ont cessé de se développer et se généraliser avec une certaine accélération sur les dernières années. Les derniers en date étant le SCT Inst en Europe en 2017, la Malaisie et la Roumanie en 2019 et le Vietnam en 2020.
Un environnement favorable
Parmi ces initiatives, les transferts de compte à compte en proximité constituent une partie significative des cas d’usage. Une analyse comparative fait apparaître des similitudes en termes d’écosystème. En effet, au-delà de l’existence d’un scheme de real time payment, nous remarquons la présence de catalyseurs tels que :
le Request to Pay sous toutes ses formes, du simple lien de paiement pré-renseigné au modèle 4 coins tel que celui développé par l’EPC
les alias afin de fluidifier la gestion des identités numériques ; pour simplifier l’expérience d’achat, les alias permettent de ne pas avoir à renseigner son IBAN ou bien celui du commerçant
les QR codes, qu’ils soient dynamiques ou non
Des API ouvertes qui favorisent les interactions entre les acteurs de l’écosystème et la construction d’expériences d’achat de plus en plus pertinentes pour des niches jusque-là non/mal servies
Les Soft POS qui démocratisent l’accès à l’expérience de paiement digital en proximité en permettant à de petits commerçants de transformer leurs smartphones ou tablettes en terminaux de paiement simplement en téléchargeant une application
Pour quels bénéfices ?
Toutefois, bien que ces catalyseurs favorisent indéniablement l’émergence de nouveaux usages, le véritable challenge reste celui de l’adhésion à la fois des consommateurs et des marchands. Pour cela, la nouvelle proposition de valeur devra résoudre un véritable pain point ou bien améliorer substantiellement un usage existant. Parmi les bénéfices attendus de la part des consommateurs, nous pouvons citer :
Régler de gros achats sans être limité par les plafonds de paiement de la carte
Améliorer la confidentialité et la sécurité des opérations en n’ayant plus à communiquer ni son PAN ni son IBAN
Disposer d’un mode de paiement alternatif pour répondre à des usages de niches
Bénéficier d’une expérience de paiement plus fluide…
Du côté des commerçants il sera important de :
Co-construire un modèle économique complémentaire qui prenne en compte les spécificités du nouveau cas d’usage et son panier moyen
Minimiser la fraude et les impayés liés aux autres moyens de paiement (chèques, carte…) et apporter une garantie d’irrévocabilité
Faciliter l’accès aux paiements digitaux à travers de nouveaux modèles d’acceptation qui minimisent les frais de mise en place
Faciliter l’automatisation de la réconciliation des paiements et le cas échéant fluidifier les opérations de remboursement…
Comment s’y prendre ?
Face à cet objectif de fluidification de l’expérience utilisateur, plusieurs approches sont envisageables. A titre d’exemple, le tableau récapitulatif présenté ci-dessous fait le parallèle entre le modèle du consortium Bizum, fruit de la coopération de 31 banques espagnoles, et celui de la FinTech (AISP/PISP) Vibe Pay.
Bien que sensiblement différents en termes de scheme sous-jacent, de stratégie de couverture et de moyen, il est à noter que les deux modèles adressent les mêmes cas d’usage, à savoir le P2P, l’e-commerce et le paiement en proximité. De ce fait, le dernier challenge à relever, et non des moindres, sera de construire une expérience d’achat unifiée sans coutures.
Pour atteindre cet objectif, il est essentiel d’intégrer le paiement bien en amont lors de la conception de l’expérience utilisateur afin qu’il se fonde dans le parcours d’achat et non pas être un nième moyen de paiement qui arriverait en bout de chaîne.
Outre l’offre bancaire classique, la France compte plus de 600 FinTechs, dont pas moins de 150 PayTechs. Bonne nouvelle au niveau de l’offre, mais comment s’y retrouver au moment du choix de solution de paiement, que l’on soit commerçant, marketplace, fournisseur de service en ligne, association…
Les critères à prendre en compte sont multiples dans le choix de son PSP. Concentrons-nous ici sur le critère économique, autour de 7 questions visant à :
Evaluer les coûts des solutions de paiement
Et s’assurer que la comparaison s’applique à des prestations comparables…
1. Quel est le positionnement du PSP ?
Derrière le check-out ou plus généralement l’ordre client, nombreux sont les intervenants dans la chaîne de paiement. Les stratégies fournisseurs varient largement :
De l’orientation one-stop-shop, intégrant des partenaires pour apporter une solution plus complète au client,
A un positionnement de spécialiste, sur un maillon de la chaîne…
Le couplage Acceptation / Acquisition illustre cette problématique de périmètre, avec ses conséquences directes sur l’analyse des coûts :
Acceptation ET Acquisition (one-stop-shop) Certains PSP proposent une prestation intégrant acceptation et acquisition. Ils s’appuient sur leurs partenaires pour l’acquisition, sélectionnés pour raisons d’appartenance au même groupe financier ou dans le cadre de négociations tarifaires massifiées.
Acceptation seule D’autres permettent au client de choisir son acquéreur. La solution de paiement intervient dans ce cas en tant que passerelle technique, routant les flux vers l’acquéreur retenu par le client. Cette configuration permet au client de conserver / renforcer sa relation avec son acquéreur, auquel il peut avoir confié d’autres prestations et négocié des conditions particulières, notamment sur les transactions On-Us…
2. Quelle est votre maîtrise de vos volumes d’opérations de paiement ?
« La prévision est difficile surtout lorsqu’elle concerne l’avenir… ». Au moment du choix d’une solution de paiement, il peut être difficile d’évaluer les volumes d’opérations, leur répartition par moyen de paiement…
S’ils sont bien maîtrisés, les propositions plus détaillées (jusqu’à 25 paramètres recensés dans notre grille d’analyse) pourront permettre d’optimiser les coûts, au prix d’un engagement dans la durée, de minima de volumes, de conditions de modification et de sortie….
Dans l’autre cas, les propositions plus flexibles et plus intégrées seront plus adaptées à un modèle économique à prouver.
3. Quelle palette de moyens de paiement ?
Les nouveaux PSP se sont d’abord développés sur le modèle de la carte, en tant que moyen de paiement privilégié des clients, en ligne et en magasin.
Les autres moyens de paiement (Virement, Prélèvement…) ont depuis commencé à percer, notamment pour des raisons de coût à la transaction.
Le Virement Instantané va contribuer à élargir cette palette, en concurrence directe avec la carte, à la fois au niveau des coûts, mais aussi pour des paiements supérieurs aux plafonds cartes.
Au niveau de la comparaison des coûts, les PSP proposant ces différents moyens de paiement bénéficieront de coûts moyens inférieurs aux pure-players de la carte.
4. Faut-il prévoir des coûts complémentaires pour les retries, rejets, chargebacks, reporting… ?
Au-delà du traitement nominal des opérations, il est important d’intégrer aussi les cas d’exception (trop nombreux d’ailleurs, pour être qualifiés d’exceptions…).
Là encore, les PSP se distinguent entre :
Ceux qui considèrent ces services comme indissociables du paiement ; dans une logique de cas d’usage (vision client) familière aux FinTechs, il est naturel d’intégrer ces services dans l’offre globale, sans surcoût / option spécifique ;
Ceux qui les considèrent comme des services supplémentaires, dans une vision orientée fournisseur, considérant la rentabilité de chaque service qu’il propose et les coûts externes (interbancaire, schemes…) générés par chacun.
5. Quel impact sur la fraude et les charges internes ?
La fraude intervient dans la comparaison économique des PSP à 2 niveaux :
D’abord dans l’efficacité de la gestion du risque que le PSP peut proposer, avec une performance à évaluer en matière de faux positifs / négatifs et dans la gestion de l’authentification forte (mode frictionless…). L’enjeu se mesure directement dans la perte de Chiffre d’Affaires et le montant des impayés.
Ensuite, dans les moyens mis en œuvre pour la gestion des litiges et la relance pour impayé. Le service peut être proposé par le PSP ou assuré en interne par le Client, à prendre en compte dans la comparaison des coûts.
Outre la fraude, d’autres postes de charge interne sont touchés par le choix du PSP :
Réconciliation & Reporting : les ressources dédiées au rapprochement des commandes et des règlements dépendent fortement de la qualité du reporting fourni par le PSP ;
Traçabilité : la capacité offerte par un PSP d’accéder directement au statut d’un paiement dans la chaîne de traitement permet d’éviter les multiples échanges téléphoniques… ;
Gestion des retries : la délégation au PSP de la représentation des paiements en échec peut libérer des ressources au sein de l’entreprise. Au-delà de l’existant, les opportunités d’optimisation ne manquent pas, dans la digitalisation des processus internes, comme la gestion des factures fournisseurs, la gestion des salaires… les fournisseurs spécialisés se développent en complément des éditeurs de solutions de comptabilité, paie… Le choix du PSP peut impacter ce potentiel d’optimisation, selon sa capacité à s’interfacer avec ces solutions, via ses API et les partenariats noués avec ces fournisseurs spécialisés.
6. Encaissement direct ou reversement ?
Au-delà des coûts de transaction, les offres des PSP peuvent aussi impacter la trésorerie. Deux modèles coexistent :
Encaissement direct : Le client reçoit directement les fonds sur son compte ;
Reversement : Les fonds sont collectés par le PSP, qui les reverse au Client selon des conditions de fréquence, montant minimum…, avec des délais jusqu’à 30 jours…
7. Quels coûts de mise en œuvre de la solution de paiement ?
Au-delà des coûts de fonctionnement traités plus haut, les coûts de mise en œuvre peuvent aussi varier :
Les principales solutions du marché (CMS e-commerce) proposent des extensions ou plug-ins, à télécharger par le client, avec un support léger pour le paramétrage. Les coûts de projet sont négligeables dans ce cas.
Dans d’autres cas, le déploiement donne lieu à un véritable projet, avec les ressources mobilisées côté client, auxquelles peuvent éventuellement s’ajouter des frais d’installation (set-up) facturés par le PSP.
En conclusion, la multiplication des PSP a apporté une plus grande richesse des services de paiement. Elle a aussi rendu plus complexe la comparaison des offres, au moment du choix du Prestataire de Services de Paiement.
Rien que sur le critère des coûts, la comparaison nécessite de prendre en compte le modèle économique du PSP, sa position dans la chaîne de bout en bout, la palette de moyens de paiement supportés, la fraude, les optimisations possibles sur les charges internes et les opportunités des solutions de digitalisation dans l’entreprise…
En rappelant toutefois que l’équation économique repose avant tout sur le taux de transformation client et que la fluidité du parcours de paiement proposé par le PSP précède la question du coût !
Alors, rendez-vous sur nos prochains articles sur le choix des solutions de paiement pour éclairer l’ensemble de ces critères.
