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.
Les entreprises de tout secteur industriel cherchent à maîtriser et améliorer les processus de gestion des données de leurs produits. Ce sujet comporte de nombreux défis car les produits n’arrêtent pas d’évoluer pour satisfaire les besoins des clients d’une part et pour être conformes aux exigences réglementaires et normatives d’autre part.
Si l’on veut exploiter les données de ses produits, il s’agit là d’une difficulté supplémentaire qui ne peut être surmontée à l’aide d’un simple référentiel de données générique (un outil de Master Data Management par exemple).
Mais avant d’en arriver là, tachons déjà de définir ce qu’est un référentiel Produit et de faire un tour d’horizon des solutions existantes sur le marché. Nous verrons ensuite ce qui fait la différence dans un référentiel produit.
Référentiel de données produit
Qu’est-ce qu’un référentiel produit ?
Le référentiel Produit constitue la base de données centrale dans laquelle est intégrée, stockée et liée toute l’information liée aux produits vendus par l’entreprise. Il est nourri à chaque étape du cycle de vie du produit par les différentes équipes qui travaillent dessus et permet de diffuser simplement une information qui a été qualifiée, unifiée et normée. Chaque intervenant peut ainsi travailler sur une base commune d’informations Produit fiable et complète.
Prenons l’exemple d’une enseigne de bricolage, elle propose à ses clients un catalogue de produits variés avec une grande différence entre eux (Boulon, Vis, Marteau, Clé à molette, Perceuse sans fil ou avec fil, Compresseur d’air, etc.). Dans son référentiel, chaque produit a sa propre nomenclature de composants qui peut être basique pour des produits comme les marteaux ou les clés à molette ou complexe comme dans le cas d’un compresseur d’air ou d’une perceuse et chaque composant de la nomenclature a ses propres caractéristiques. Grâce à son référentiel Produit, l’entreprise peut aussi gérer les multiples variantes associées à une perceuse par exemple (Perceuse rouge sans fil, Perceuse noire avec fil 2m, Perceuse jaune avec fil 4m, etc.). L’enseigne peut ainsi gérer les informations liées aux différentes étapes du cycle de vie de ses produits depuis leur conception jusqu’à leur retrait du marché.
L’importance d’un référentiel produit
Lorsqu’une entreprise possède un portefeuille produits étendu et/ou en constante évolution, la quantité de données liées aux produits ne cesse d’augmenter elle aussi. Il devient essentiel de les centraliser, les normer et finalement de les gérer plus simplement pour gagner en efficacité et en fiabilité.
Le référentiel Produit permet de réaliser cet objectif en concentrant dans un outil flexible et transversal toutes les données associées. Il permet de les unifier afin d’assurer leur cohérence et de les lier entre elles pour créer un maillage produit pertinent pour l’utilisateur et un produit fini de qualité et à temps pour le client final.
Exemple et types de référentiels produit
PIM : Abréviation anglaise de Product Information Management. Il permet de centraliser, d’organiser et de gérer les données produit. Le PIM est une sorte de catalogue des produits de l’entreprise et il est très orienté pour des utilisations marketing. En effet, il centralise les données destinées à être diffusées aux prospects / clients telles que les données marketing, les données commerciales, les données techniques.
PLM : Abréviation anglaise de Product Lifecycle Management. Il permet, comme son nom l’indique, de gérer le cycle de vie du produit depuis sa conception, jusqu’à sa fin de vie (fabrication, gestion des stocks, logistique et transport, vente, éventuellement recyclage). Il centralise ainsi toutes les données liées au produit, et permet ainsi de gérer d’une manière plus transversale les données du produit.
Qu’est-ce qui différencie un référentiel produit d’un référentiel générique de données ?
Avec la capacité croissante d’enregistrement des données industrielles, plein de nouveaux concepts caractérisant la gestion des données produit ont vu le jour chez les entreprises. Contrairement aux référentiels génériques, les référentiels Produit ont été conçus pour maîtriser ces concepts et répondre aux enjeux des entreprises en proposant des fonctionnalités et des outils, spécialement, dédiés à la gestion des données Produit.
1. La gestion des cycles de vie des produits :
Les cycles de vie diffèrent d’un produit à un autre. Chacun possède un cycle de vie qui caractérise son développement, sa production, sa commercialisation et sa fin de vie (Exemple ci-dessous)
Dans un référentiel de données Produit la notion de cycle de vie pour un produit fini est liée à la notion de la chaîne de valeur industrielle. Cette dernière permet de supporter les différentes phases de vie d’un produit depuis l’idéation jusqu’à son recyclage ou son retrait du marché.
Le référentiel Produit permet de gérer ces phases sous mode projet avec des jalons et des livrables précis associés à chaque phase.
Quant aux composants de la nomenclature du produit final, ils ont un cycle de vie qui leurs est associé et qui, à l’aide des boucles ou workflows de validation, permet le passage d’une version N à une version N-1 en cas de modifications appliquées à quelques éléments de la nomenclature comme le montre l’illustration basique ci-dessous. Il faut savoir que les cycles de vie des composants peuvent avoir plus de complexité en fonction du secteur d’activités de l’entreprise (Défense, Aérospatial, etc.) ou de l’utilisation finale du produit (Nucléaire, Sous-marin, etc.)
Exemple de cycle de vie d’un composant de nomenclature :
Exemple de cycle de vie d’un produit :
2. La favorisation du co-développement interne et externe :
Le co-développement interne est la collaboration entre les acteurs métiers impliqués dans le développement d’un nouveau produit.
Le co-développement externe est la collaboration d’une entreprise avec ses clients et fournisseurs pour développer de nouveaux produits et services. C’est un vecteur d’innovation et de performance dans un modèle gagnant pour les trois acteurs.
Un référentiel Produit permet de supporter le co-développement interne en mettant à disposition des outils de collaboration entre tous les métiers autour de la nomenclature du produit avec une vue dédiée pour chaque métier. Par exemple, le bureau d’étude veut voir le matériau, les dimensions et les contraintes mécaniques liés au produit alors que les bureaux des achats et des ventes veulent voir les coûts de production, de montage et de maintenance, etc. Le référentiel Produit permet d’avoir une appropriation du contenu et du discours de chaque produit et la création d’un vocabulaire commun. Les entreprises peuvent ainsi avoir des propositions de valeur concrètes répondant aux besoins évolutifs des clients.
Le référentiel Produit permet aussi de favoriser le co-développement externe entre une entreprise, ses clients et ses sous-traitants en donnant la possibilité de partager en toute sécurité les informations qu’elle souhaite avec ces acteurs via une plateforme dédiée. Cela permet d’avoir un gain considérable dans le temps de mise sur le marché des produits car la plateforme permet aux entreprises d’avoir des boucles d’itérations et d’échange avec ses clients et ses fournisseurs lors de la phase du développement du produit et non pas à sa fin comme le montre l’illustration ci-dessous.
Grâce au co-développement les entreprises peuvent minimiser le temps de mise sur le marché des produits et donc réduire leur coût de développement.
3. La gestion des options/variantes et des bom 150% (bill of materials)
La BOM 150 % ou la nomenclature à 150 % n’est qu’un autre nom pour une structure à variantes, ou plus précisément, une nomenclature configurable. Les nomenclatures configurables comportent un ou plusieurs composants optionnels et/ou sous-ensembles modulaires qui, lorsqu’ils sont correctement configurés, définissent une variation spécifique d’un produit. En fait, une nomenclature configurable est constituée de plusieurs nomenclatures possibles chargées dans une seule structure de produit. Lorsqu’elle n’est pas configurée, la nomenclature contient plus de pièces et de sous-ensembles que nécessaire, c’est-à-dire plus de 100 %. D’où l’expression « nomenclature à 150 % ». Cette approche est un moyen pour les ingénieurs de gérer la complexité de la structure et de la variation des produits.
La différence entre les options et les variantes dans un produit est que l’option est un système qui s’ajoute sans impact sur l’architecture du produit et les autres variantes et options choisies (Exemple : Climatisation dans une voiture) alors qu’une variante est un choix obligatoire et exclusif parmi des sous-ensembles et peut impacter l’architecture produit et même la structure de gamme d’assemblage (Exemple : Voiture 3 portes ou 5 portes)
Le référentiel Produit a la capacité de supporter toute la complexité liée à la gestion des BOMs 150 % en gérant non seulement les nomenclatures configurables associées à chaque produit mais aussi les règles de compatibilité entre toutes les options et les variantes possibles.
La gestion des nomenclatures configurables dans les référentiels Produit permet aux entreprises la possibilité de réutiliser les données de définition d’un produit et éviter d’avoir des doublons avec plusieurs numéros d’article pour un même composant.
L’illustration ci-dessous montre un exemple de déclinaison d’une BOM 150 % d’un stylo en deux nomenclatures du même produit mais avec des options et des variantes différentes.
4. Le support des différents types de processus de vente et de production
L’un des atouts majeurs d’un référentiel Produit est le fait qu’il puisse gérer la définition du produit pour les différents processus de vente et de production. Ces derniers varient entre les entreprises et peuvent même coexister pour différents produits au sein de la même entreprise, ce qui ajoute une couche de complexité à la gestion des données de ces produits.
Il existe divers processus de vente et de production dans le marché, on peut en citer :
Make To Stock : Lorsqu’un produit peut être vendu à partir d’un catalogue et qu’il est défini et spécifié par une fiche. La fabrication du produit peut être planifiée en se basant sur les prévisions.
Make To Order : Cette stratégie s’applique toujours aux produits standard dont les spécifications sont clairement définies. Pour ce type de produit, il n’est pas possible d’établir des prévisions et les produits sont fabriqués sur commande.
Configure To Order : C’est le processus le plus complexe du marché car le produit standard comporte un grand nombre de variantes. Il n’est donc pas possible de créer un numéro de produit pour chaque nomenclature à cause des nombreuses combinaisons possibles. Comme le montre l’illustration ci-dessous, la gestion des produits de ce type nécessite 3 briques essentielles que le référentiel Produit comporte :
Architecture produit : C’est le squelette générique du produit.
Familles de diversité : à chaque élément de l’architecture est attachée une famille de diversité donnant le champ des choix possibles pour chaque composant.
Règles de configuration : Les règles de configuration sont un mélange de règles de compatibilité entre les éléments des familles de diversité et de règles de productions qui permettent de configurer une produit fini réalisable par l’entreprise. Elles doivent être définies dans le référentiel et elles sont exécutées lors de la configuration du produit final.
Engineer To Order : C’est une approche de la production caractérisée par plusieurs activités d’ingénierie et soumis à un délai de livraison défini à la réception d’une commande du client accompagné d’un cahier de charge. (Exemple : Fabrication de câble pour un projet de construction d’un pont)
Avoir un outil capable de couvrir les différents processus, comme le référentiel Produit, permet aux entreprises d’optimiser et de centraliser la gestion des données de chaque produit. Par exemple, pour le processus CTO, le référentiel Produit aide les entreprises à éviter les retards de fabrication et les rejets des commandes en empêchant une mauvaise configuration du produit grâce aux règles de compatibilité entre les différents éléments. Chaque produit configuré dans un référentiel Produit est donc réalisable par l’entreprise.
5. La gestion de la conformité par rapport aux exigences
Les référentiels Produit permettent d’améliorer et d’optimiser la gestion de la conformité par rapport aux exigences. Il est possible de stocker, classifier et ordonner les métadonnées liées aux exigences (Client, Réglementaires, etc.) et cela permettra d’avoir une arborescence d’exigences (Requirements Breakdown Structure) qui est en lien direct avec la nomenclature du produit (BOM) comme le montre la figure ci-dessous. Chaque composant ou sous-ensemble est alors attaché aux exigences auxquelles il doit répondre et sa conformité est vérifiée en temps réel.
Cette méthode permet aux ingénieurs d’avoir une couverture totale des sous-ensembles et des exigences qui leurs sont associées. Le développement du produit devient ainsi plus efficace et sa commercialisation sera plus rapide.
6. La gestion des processus de modifications
Dans les référentiels Produit, les boucles de modification sont constituées d’une séquence d’événements comme le montre le logigramme ci-dessous. Les étapes principales de cette boucle sont :
Rapport d’incident ou Problem Report (PR) : c’est un signalement de problème ou une source potentielle de panne dans le produit. Le PR peut déboucher sur une demande d’évolution technique (modification) du produit ou d’un processus.
Demande de modification ou Engineering Change Request (ECR) : Un problème, si retenu, peut donner lieu à une ou plusieurs demandes de changement. Cette étape consiste à consolider les analyses sur les objets potentiellement concernés et impactés.
Ordre de modification ou Engineering Change Order (ECO) : Si l’ECR est accepté, on passe à un ordre de changement pour valider la liste complète des objets impactés devant être modifiés.
Grâce aux référentiels Produit, les processus de modification sont automatisés en suivant une logique d’étapes qui garantit une efficacité et une rapidité dans la réalisation des changements sur un produit donné. L’outil permet de gérer les passages de versions majeures et mineures sur chaque composant de la nomenclature et peut même produire une matrice d’impact sur le reste de la structure du produit et proposer d’appliquer des modifications sur d’autres composants.
Conclusion
Depuis son arrivée, le Digital a eu un impact de plus en plus important sur le monde de la Data avec un besoin croissant de garantir la consistance des données sur l’ensemble des canaux. Grâce à lui, le rythme ne cesse pas d’accélérer et il demande encore plus de rigueur dans la gestion des données Produit. Cette dernière, en plus de sa particularité, est devenue plus challengeante pour les entreprises avec des clients de plus en plus exigeants, des contraintes réglementaires en évolution continue et dans un marché de plus en plus compétitif.
Contrairement aux référentiels génériques de données, les référentiels de données Produit permettent aux entreprises de surmonter ces défis en leurs offrant un panel étendu de fonctionnalités et en introduisant plusieurs concepts pour les aider à améliorer les processus de gestion des données produit et à maîtriser les étapes du cycle de vie.
Si vous avez des questions sur les référentiels produits ou souhaitez être accompagnés sur le sujet ? Contactez transfodata@rhapsodiesconseil.fr
Découvrez-en davantage concernant l’expertise de Zied : Transformation Data.
Tout comme le Chief Marketing Officer a pour objectif d’augmenter la valeur « client », le Chief Data Officer doit poursuivre le même objectif avec les « données ».
En effet, chercher à augmenter la valeur des données actionne, in fine, tous les leviers auxquels le Chief Data Officier doit s’attaquer. Ce sont ces leviers que nous allons passer en revue ici pour cadencer la feuille de route du CDO.
Angle d’approche ? Les sources de données !
Pour augmenter la valeur des données, il va falloir être capable de la mesurer.
Quel périmètre doit-on mesurer ? Qu’est-ce qui détermine la valeur des données ?
Afin de disposer à la fois d’un périmètre fini à gérer, et des données présentant les mêmes caractéristiques, nous allons mesurer la valeur d’une « source de donnée » (exemple de sources de données : la donnée client dans le CRM, la donnée produit dans le référentiel produit, les opérations de compte dans le système dédié à la gestion des comptes, etc.).
Cela nous donne une première activité clé du CDO : Constituer et faire vivre le référentiel des sources de données majeures de son organisation. Elles vont constituer l’actif qu’il va devoir gérer et faire prospérer.
« Actif », vous avez dit « Actif » ?
C’est en particulier en considérant les données comme un actif, que l’on va disposer d’un guide pour établir et développer leur valeur.
Tout d’abord, la valeur propre de notre actif, qui caractérise son état actuel et son potentiel, va se traduire, pour une source de données, par :
Son niveau de connaissance : les données sont-elles décrites et leurs caractéristiques partagées au sein de l’organisation ? (exemple : définitions, données personnelles…)
Son niveau de qualité : les données sont-elles fiables ?
Son niveau d’accessibilité : les données sont-elles facilement accessibles ?
Son niveau de fraîcheur : les données sont-elles alignées avec la réalité qu’elles décrivent ?
Son niveau de gouvernance : le cycle de vie des données est-il géré ? Avec des rôles et responsabilités définis ?
Son niveau de conformité : les données répondent-elles à des cadres réglementaires ?
…
Ces différentes caractéristiques constituent un premier guide pour le CDO déterminant les domaines d’action à couvrir ou à dynamiser : C’est le plan d’action « Développer la valeur propre »
Mesurer et améliorer la qualité des données,
Disposer d’un cadre souple et agile de gouvernance des données,
Lancer des initiatives pour faciliter l’accès aux données (internes et externes),
Rapprocher les cadres réglementaires des données qu’ils couvrent … .
…
Une fois cette valeur propre établie, encore faut-il la concrétiser : Ce sont les usages qui vont en être fait qui vont permettre d’arriver à ce résultat.
Définissez vos cas d’usages !
Cette valeur d’usage va se caractériser de plusieurs façons, qu’il faut combiner pour démultiplier la valeur d’une source de données :
Combien de métiers différents utilisent ces données ? Uniquement le marketing ou aussi la conformité, les canaux digitaux, l’écosystème… ?
Quelle diversité y-a-t-il dans l’utilisation de ces données ? Uniquement pour du reporting ou aussi pour des usages en temps-réel, des usages opérationnels, des visions 360°, de la détection de fraude… ?
Quels revenus sont générés (ou économies réalisées) grâce à ces données ?
Quelle valeur est réalisée dans l’écosystème de l’organisation ? Les données sont-elles uniquement utilisées en interne ou bien participent-elles à un écosystème plus large (partenaires, Open Data, image…) ?
…
Ces axes de développement constituent un second guide pour le CDO, déterminant les domaines d’action qu’il doit couvrir ou dynamiser. : C’est son plan d’action : « Développer la valeur d’usage »
Développer une culture Data dans l’organisation afin de favoriser les nouveaux usages et de sensibiliser à la protection des données,
Multiplier les activités avec les métiers pour identifier de nouveaux usages,
Mesurer et maximiser les revenus et les économies permis par l’utilisation des données,
Étendre, jusqu’à l’écosystème de son organisation, ses activités et ses partenariats
…
Mettre en place les plans d’action que nous venons de lister va permettre de concrétiser à la fois la valeur propre et la valeur d’usage des données. Et nous disposons dès lors d’un critère de priorisation des activités centré sur la valeur. Et c’est bien là tout l’objet de cette approche consistant à faire de l’augmentation de la valeur des données l’objectif premier du CDO : Identifier les actions concrètes à mener, jour après jour, pour développer la valeur des données, avec des éléments de mesure objectifs.
Vous voilà parés pour augmenter la valeur de vos données.
A l’heure où la Data transforme le métier de l’assurance, ce leader de l’assurance et des services financiers, s’appuie sur la méthodologie de Rhapsodies Conseil, cabinet indépendant de conseil en management. Cette méthodologie est utilisée au sein des filiales de l’assureur dans une optique de valorisation des données visant le cadrage des investissements. Elle permet d’identifier les domaines de Data les plus opportuns pour générer des bénéfices mais aussi mettre en perspective les lacunes.
La stratégie de valorisation de la donnée
Parce que la transformation digitale est une lame de fond, ce leader européen de l’assurance y investit toutes les ressources nécessaires et accorde une place hautement stratégique aux sujets Data. Valoriser la donnée s’impose ainsi comme un enjeu clé pour analyser et prioriser ce qui va générer du bénéfice. C’est à ce titre qu’est utilisée « Augmentez la valeur de vos données ! », la méthodologie de Rhapsodies Conseil qui vise à orienter la stratégie Data et à définir les investissements nécessaires à la conduite des travaux de qualité de données. L’objectif : faire de la valeur de la Data le fil directeur stratégique pour répondre aux usages métier et apporter une forte valeur ajoutée à l’entreprise. Cette valeur ajoutée peut notamment permettre de d’accélérer la croissance commerciale, d’améliorer les profits, de faire des économies ou encore d’améliorer la productivité des équipes.
De cette méthodologie, notre groupe tire à ce jour de nombreux bénéfices notamment en matière d’efficacité, à commencer par l’amélioration des processus ou encore la gestion des sinistres. Tout particulièrement sur nos marchés émergents, nous constatons que la maîtrise de la donnée améliore considérablement la relation client et in fine la fidélisation des clients. Cela permet d’ailleurs de faire le lien entre la donnée et la valorisation financière. En somme, c’est sur l’ensemble de ses sujets ‘core business’ que ce travail sur la donnée prend tout son sens.
Chief Data Officer d’une des filiales de cet assureur
Voir notre méthode appliquée au sein d’un groupe tel que ce leader européen de l’assurance est une réelle fierté et la preuve tangible que notre vision de la valorisation Data trouve écho et résonne chez nos clients. C’est également révélateur d’une transformation digitale en ordre de marche où la Data est intrinsèquement devenue un acteur central de notre quotidien et de celui des entreprises et organisations.
Albert Bendayan
Application de la méthodologie data de rhapsodies conseil au sein du groupe européen d’assurance
Le groupe est organisé en différents marchés : la France, l’Europe, l’Asie et l’International New Market et chacun dispose de sa propre gouvernance. La méthodologie Data de Rhapsodies Conseil est adaptée aux besoins de chaque pays et au degré de maturité des différents marchés, qu’ils soient émergents ou matures, et qu’elles que soient les problématiques, les budgets, les contextes et les challenges. Rhapsodies Conseil intervient aux côtés du groupe sur plusieurs thématiques Data afin de définir des approches, des principes et des bonnes pratiques, agissant comme accélérateurs pour aider les différentes filiales du groupe. Les dirigeants locaux sont donc les premiers utilisateurs de la méthodologie qui est aujourd’hui particulièrement employée au Mexique, en Colombie et dans plusieurs pays du Golfe Persique.
Dans les entités émergentes les dirigeants locaux font face à des défis de taille : générer de la profitabilité dans des marchés complexes, où ils n’ont pas tout le temps, la latitude budgétaire et les capacités technologiques pour pouvoir être réactifs. Ils doivent donc effectuer des investissements mesurés sur le digital, la Data, l’IT,… et assurer un ROI rapide et important ?
Chief Data Officer
Ce leader européen de l’assurance a orienté son approche Data sur la partie stratégique qu’est la valorisation financière : c’est pour eux le levier principal et les bénéfices sont d’ores et déjà palpables. Fort de ce succès, le groupe a pour objectif en 2020 de continuer à appliquer cette méthode et de la promouvoir auprès de l’ensemble des parties-prenantes, pour qu’elle soit partagée avec les autres entités du groupe.
Les autres success stories qui peuvent vous intéresser
La Direction de la Stratégie d’un grand acteur mutualiste avait formalisé près d’une cinquantaine de cas d’usages Data couvrant tous les métiers de l’organisation. L’objectif de notre mission était d’accompagner la DSI à décliner opérationnellement ces cas d’usages sur leur Socle Data et de prioriser les sujets pour la construction de celui-ci.
Notre valeur
Notre accompagnement s’est fait par une analyse des cas d’usages en deux temps :
Phase 1 : Focus sur les métiers.
Nous avons raffiné les cas d’usages exprimés pour mettre en avant, pour chaque cas d’usage, le bénéfice métier ainsi que la faisabilité (disponibilité des données, etc.). Cela nous a aussi permis de déterminer s’il s’agissait plutôt de la connaissance, de la supervision, de l’automatisation ou de la prédiction liées aux données afin de catégoriser les usages pour la DSI. In fine nous avons pu constituer des groupes de cas d’usages selon leurs niveaux de priorité et leurs enjeux métiers et SI.
Phase 2 : Déclinaison opérationnelle sur le Socle Data.
Par la suite nous avons construit 5 types opérationnels qui permettent d’identifier comment un usage est mis en œuvre, de façon concrète, dans le Système d’Information: A-t-on besoin de gérer les données ? D’en étendre le périmètre avec des données externes ? De mener des analyses et de mettre en place des algorithmes ? D’exposer et de mettre à disposition des données ? De fournir des outils évolués de visualisation des données ?
Cela nous a permis d’identifier des fonctions du Socle Data à déployer pour chaque type opérationnel et de voir comment le cas d’usage est mis en œuvre de manière concrète dans le SI (un même cas d’usage peut avoir différents types).
Notre approche en deux temps a permis d’extraire 5 cas d’usage avec la priorité la plus élevée en termes de valeur et de faisabilité. Ils sont devenus des projets chez notre client par la suite. S’en est ainsi formalisée une aide pour la DSI pour lui permettre de construire le Socle Date de manière pragmatique et guidée par la valeur.
Bénéfices
Cette approche méthodique a pu apporter à notre client deux bénéfices majeurs :
En premier lieu le travail de classification des cas d’usages compréhensible de tous a permis d’établir un partenariat entre la DSI et les métiers autour des données. Les entités ont initié dans les projets un travail d’approche data commune, seul moyen de casser les silos et de vraiment valoriser les données de l’organisation.
Enfin, la priorisation des usages Data a permis que la construction du Socle Data soit guidée par la valeur, menée de façon progressive et ainsi concrétiser la valeur de celui-ci.
Les autres success stories qui peuvent vous intéresser
