Depuis quelque temps, la question de la conformité interne prend une place indéniable dans les entreprises. En effet, même si le RGPD est un règlement datant de 2018, l’attention a été portée aux données clients, aux besoins des équipes marketing, data ou digital et fournisseurs, délaissant de fait les données RH des organisations.

Une conformité RGPD permet cependant d’améliorer l’image employeur de son entreprise (pour les employés mais aussi pour les candidats) au travers du respect de la confidentialité et de la gestion des risques sur la vie privée, par une politique de protection des données.

De plus, c’est un moyen d’améliorer la gestion des employés et de mettre à la disposition du DRH, des informations à jour, complètes et centralisées qui permettront d’améliorer la prise de décision et de planification des ressources humaines.

Enfin, c’est aussi un moyen d’éviter à l’entreprise des sanctions financières et des poursuites en cas de violation des données des employés, sans compter les conséquences sur la réputation de l’entreprise.

Cet article a pour but de donner quelques conseils aux équipes RH et aux consultants. J’ai procédé à un exercice de collecte d’informations qui, je l’espère, vous sera utile pour vous guider dans votre mise en conformité.

Cependant, je n’aborderai pas tous les sujets nécessaires pour se mettre complètement en conformité, mais uniquement les points récurrents qui me sont souvent demandés.

Les 3 points à respecter pour que votre RH soit conforme à la RGPD

La base légale des traitements des données

Chaque traitement de données personnelles doit respecter une base légale.

Parce qu’il n’est pas nécessaire de réinventer la roue et que la CNIL a fait un excellent travail de présentation des bases légales envisageables pour les activités de traitements spécifiques à la gestion des ressources humaines, je vous propose ce tableau :

La durée de conservation des données RH

Les données personnelles ne pouvant pas être conservées à vie, il est nécessaire de mettre en place des purges automatisées ou non (selon la taille de vos espaces de stockage, il est parfois indispensable de passer par une purge automatisée).

Les durées de conservations sont généralement à définir par le métier, selon son besoin (la personne utilisant la donnée ou la collectant) ; dans votre cas : le DRH ou le responsable administratif en collaboration avec votre DPO ou le référent RGPD de votre organisation. Cependant, certains documents doivent respecter des durées légales de conservation déjà prévues par le droit.

Le tableau ci-dessous vous permet d’avoir une liste (non exhaustive) des documents les plus souvent demandés/collectés en interne :

La gestion des droits des personnes (candidats et employés)

La gestion des droits des personnes est une obligation sur toutes les données personnelles, il faut donc prendre en compte le processus de réponse à ces demandes. Les droits sont : le droit d’accès (avoir une copie des données personnelles), le droit de suppression (demander la suppression de tout ou partie de ses données personnelles), le droit de modification (demander la modification de ses données personnelles en cas d’erreur), le droit de portabilité (demander une copie sous format lisible par une machine (ex. : csv) de ses données personnelles), le droit de limitation (demander la non utilisation de ses données personnelles pour un traitement spécifique).

Des règles simples sont à respecter : 

• La réponse à une demande doit se faire au maximum 30 jours après la réception de celle-ci. Il peut y avoir une exception si la demande est complexe (si on vous demande une copie de la totalité des données personnelles que vous avez en votre possession), dans ce cas le délai monte à 3 mois, mais il faudra prévenir la personne que la durée est augmentée de 23 mois, un mois maximum à partir de la réception de la demande.
• La confirmation de l’identité du demandeur est nécessaire afin d’éviter d’envoyer/modifier/supprimer les données d’une une tierce personne. Si ça arrive, il s’agit alors d’une fuite de donnée qui doit être notifiée auprès de la CNIL. La confirmation est nécessaire seulement en cas de doute sur l’identité de la personne, elle n’est donc pas obligatoire. Enfin, une fois l’identité de la personne confirmée, la preuve doit être supprimée.
• La réponse doit être sous le format de la demande, c’est-à-dire qu’une demande par courrier doit avoir une réponse par voie postale, et une demande par mail, par mail.
• Il est possible de refuser une demande si celle-ci n’est pas fondée ou paraît excessive, ou encore si les données de la personne concernée ont été effacées. Ou enfin, s’il est demandé de supprimer des documents légaux ou devant être conservés obligatoirement (ex. : fiche de paie, contrat, …).

Mettre en place la conformité RGPD de vos Ressources Humaines

Pour bien commencer, il est important d’avoir une équipe dédiée à la conformité, en complément du DPO et du DRH qui sont indispensables. Cette équipe devra être formée et aura des rôles précis. Cette formation peut se faire directement par le MOOC de la CNIL, régulièrement mis à jour, qui est complet et qui donne de très bonnes bases (testé et approuvé par mon équipe). 

En interne, il est indispensable de pouvoir sensibiliser les collaborateurs sur leurs droits (droits des personnes, bases légales, limitations, …), mais aussi leurs devoirs vis-à-vis des données personnelles qu’ils traitent (sécurité des postes de travail, sécurité des documents, politique de mot de passe, …).

Enfin et afin de pouvoir être totalement conforme, il est nécessaire de créer un registre de traitement, de faire une revue des process de gestion des droits des personnes, d’analyser les applications internes, les contrats de sous-traitance et les mesures de sécurité de la DSI. Il est également nécessaire de s’assurer du bon fonctionnement des purges et archivages ou encore de mettre en place des analyses d’impacts sur la vie privée et des audits.

Les 3 étapes pour maîtriser la qualité de vos données

Qui ?

• Les équipes métiers
• Les équipes SI
• Data Management
• Data Office

État des lieux

Quoi ?

• Définir le scope des données clés et leurs dimensions* pour un périmètre précis
• Mesurer la qualité des données dans les systèmes sources
• Construire un tableau de bord des mesures et des KPIs établis

Outillage

• Glossaire métier des données et des règles de qualité
• Tableau de bord

Attentes des métiers

Quoi ?

• Identifier les usages métiers consommant les données définies dans le scope
• Etablir la matrice d’impact qualitatif de la non qualité
• Estimer le coût des actions de remédiation
• Définir et suivre le ROI en cas d’amélioration de qualité
• Définir et suivre les cibles / trajectoires des KPIs qualité

Outillage

• Tableau de bord
• Matrice d’impact

Plan d’actions d’amélioration

Quoi ?

• Identifier et qualifier les actions correctives et préventives de remédiation côté métiers / SI et Data Management
• Prioriser les actions permettant de générer des Quick Wins
• Suivre le plan d’action d’une façon itérative et agile

Outillage

• Backlog des actions à mettre en place

Les dimensions de la qualité des données

• Complétude : fait référence à la présence de toutes les données requises.
• Cohérence : assure que les données sont représentées de manière cohérente dans les systèmes.
• Unicité : indique qu’une instance de la donnée n’existe pas plus d’une fois dans le dataset.
• Intégrité : assure la cohérence entre les objets de données via une clé de référence contenue dans les deux objets.
• Validité : fait référence à la présence des valeurs des données dans un domaine défini de valeurs.
• Raisonnabilité : vérifie si un modèle suit une distribution raisonnable des données.
• Actualité : fait référence aux données acquises ou mises à jour dans les délais impartis.
• Exactitude : fait référence à la mesure dans laquelle les données représentent correctement les véritables valeurs réelles.

ArchiMate est un langage de modélisation développé par l’Open Group, basé sur les concepts TOGAF, qui permet de partager un langage commun pour décrire, analyser et visualiser l’architecture d’entreprise. Le but ?  Aider à la prise de décision des transformations de l’entreprise.

Résultat d’années de réflexions (travaux débutés en avril 2020), la nouvelle spécification ArchiMate 3.2 est publiée le 18 octobre 2022. 

L’objectif de cet article est de montrer l’exhaustivité des modifications apportées par la spécification 3.2 d’ArchiMate.

Voici une synthèse de ces modifications qui seront détaillées plus bas :

• La couche physique devient un composant de la couche technologie
• Modification de la notation
  • L’ensemble des éléments ont maintenant deux notations : sous forme de boite et d’icône
  • Tous les éléments de la couche Implémentation et Migration sont désormais de la même couleur
• Modification des méta-modèles 
• Reformulation des définitions de Outcome, Constraint, Business Function, Product et Technology Interface 
• Modification des relations dérivées
  • Ajout d’une règle de dérivation pour un élément Grouping
  • Modification majeure des restrictions

La couche physique devient un composant de la couche technologie

Jusqu’ici indépendantes, Archimate 3.2 intègre la couche Physique dans la couche Technologie.

Les modifications de la notation

Deux changements majeurs dans la notation ArchiMate sont apportés par la spécification 3.2 :

• L’ensemble des éléments ont maintenant deux notations : sous forme de boite et d’icône
• Tous les éléments de la couche Implémentation et Migration sont de la même couleur

Nous avons fait le travail de synthèse des modifications de la notation dans le tableau suivant :

Voici donc la nouvelle notation Archimate 3.2 :

La modification de définitions

ArchiMate 3.2 clarifie et simplifie les définitions des concepts Outcome, Constraint, Business Function, Product et Technology Interface.

Issu de la spécification ArchiMate, nous avons synthétisé l’ensemble des modifications de définitions dans ce tableau (rouge : supprimé ; vert : ajouté) :

La modification des méta-modèles

La spécification 3.2 modifie les méta-modèles des couches Business, Technologie, Physical, et des liens entre la couche Implémentation et Migration et l’aspect Motivation. 

Voici les évolutions de ces méta-modèles :

En synthèse, les modifications des méta-modèles apportent les changements suivants :

• Ajout des relations
  • Agrégation et Composition du Product au Contrat
  • Agrégation et Composition entre Node, Device, System Software, Equipment et Facility
  • Assignation du Device à l’Artifact
  • Assignation du System Software à l’Artifact
  • Réalisation du Matériel à l’Equipement
  • Composition et Agrégation du Plateau à l’Outcome
  • Réalisation et Influence du Work Package au Requirement

• Suppression des relations
  • Réalisation entre des Nodes
  • Assignation des éléments technologiques de structure active à l’Artifact

• Modification des liens d’héritage
  • System Software, Device, Equipment et Facility n’héritent plus du Node et héritent des éléments technologiques de structure active 
  • Artifact, Material et Path sont des éléments technologiques de structure passive

Évolution des relations dérivées

Dans le but de réaliser des analyses d’impacts plus poussées, la spécification ArchiMate 3.1 avait introduit la notion de relation dérivée :

Si on a deux relations p(b,a):S et q(b,c):T avec a, b, c des éléments, p et q des relations respectivement de type S et T, alors on cherche à connaître la relation r de type U tel que r(a,c):U.

ArchiMate 3.1 définit :

• Des règles de dérivation strictes, qui s’applique quel que soit le modèle
• Des règles de dérivation potentielles, qui peuvent s’appliquer en fonction du modèle
• Des restrictions sur les règles de dérivation

En complément, Archimate 3.2 : 

• Réécrit totalement les restrictions sur les règles de dérivation, qui étaient jusqu’ici difficiles à lire
• Ajoute une règle de dérivation potentielle pour un élément Grouping : S’il existe deux relations p(b,a):S et q(b,c):T, avec S une relation de type Agrégation ou Composition, b un élément de type Grouping et T une relation de type Realization ou Assignment, alors une relation r(a,c):T pourrait être dérivée seulement si le métamodèle permet une relation T de a à c.

Conclusion

Les modifications du langage de modélisation Archimate apportées par la spécification 3.2, bien que mineures, permettent d’homogénéiser la notation, d’améliorer le méta-modèle et de supprimer des ambiguïtés par la clarification à la fois des définitions et des règles de restrictions des relations dérivées.

Pour approfondir le sujet, vous pouvez consulter la spécification d’Archimate 3.2.

Les entreprises, dans la mise en place de leur stratégie Data Driven, s’appliquent à rendre la donnée accessible à tous leurs acteurs métiers. Parmi les solutions d’exposition des données, on trouve majoritairement des outils de data visualisation ou « dataviz ». Ces outils sont choisis pour leur facilité d’interaction avec les différentes sources de données de l’entreprise, et également pour leurs fonctionnalités de présentation des données et d’indicateurs sous forme de graphique, carte, etc. Les cas d’usage de ces solutions sont multiples :

• Suivre le développement d’un produit,
• Étudier l’impact d’une campagne marketing,
• Piloter l’activité,
• Produire des rapports réglementaires (index égalité F/H, bilan social, etc.),
• Prévoir une situation future,
• Suivre la qualité des données.

Réglementation et sécurité de la Data Visualisation

De plus en plus de liberté et d’autonomie sont laissées au métier aujourd’hui pour construire et publier leurs data visualisations. Ce gain d’autonomie ne doit pas aller à l’encontre des principes de base sur la sécurité des données. La sécurité et la compliance doivent rester sous contrôle.
Pour cela, les usages de données sont à répertorier dans un “portefeuille d’usage”, ce qui va assurer leur documentation et faciliter leur partage au sein de l’entreprise.
Pour ceux utilisant des données à caractère personnel, les référencer permettra d’assurer le respect de la réglementation RGPD.

Lors de la documentation des usages, la liste des utilisateurs est définie. La politique de gestion des habilitations est ensuite utilisée pour rapprocher chaque utilisateur à un rôle lié au type de persona défini. Cette gestion des habilitations restreint les risques de diffusion des données sensibles et/ou stratégiques de l’entreprise auprès d’acteurs ne devant pas y avoir accès. Centraliser cette politique d’accès améliore le suivi et l’évolution des habilitations, à la suite de réorganisations par exemple.
Cette politique doit être menée de front par les équipes DSI en responsabilité des outils de data visualisation, les équipes d’audit interne ainsi que risque et conformité.

Disponibilité et qualité de l’information de la Data Visualisation

La multiplication des data visualisations a tendance également à augmenter le nombre d’indicateurs (parfois dupliquer), avec un manque de transparence sur la traçabilité et la qualité des données sous jacentes. L’utilisateur d’une data visualisation doit systématiquement pouvoir identifier le niveau de confiance qu’il peut avoir dans les chiffres qui lui sont fournis. Cet axe est donc majeur et on y distingue deux phases : la mise en production et le maintien en condition opérationnelle de la data visualisation.

Phase de mise en production de la donnée

Lors de la mise en production, l’inscription des sources de données dans le plan d’actualisation assure la fraicheur des données en correspondance avec le besoin métier. Avant la mise en place de plan d’actualisation, on observe parfois chez nos clients utilisant des bases de données dans le Cloud, des surcoûts non anticipés. Ils sont liés à des interactions trop nombreuses ou trop consommatrices den ressources.

Une non-gouvernance des plans d’actualisation peut également se traduire par un « plantage » du système s’il n’est pas prévu d’élargir les ressources disponibles. L’impact budgétaire dans le cas d’un environnement Cloud, est d’autant plus important que les data visualisations se multiplient et tendent à sur-solliciter les serveurs des data sources.
Lister les data sources permet de répondre par la suite à des besoins de mutualisation des data préparations, pour notamment réduire les interactions serveurs, ou des besoins liés à des études d’impact en cas de correctif en amont dans le cycle de vie des données.

Maintien en condition opérationnelle de la donnée

Au quotidien, les rapports sont utilisés à des fin de reporting et d’aide à la prise de décision.
Pour assurer la bonne qualité des données utilisées dans les data source, un suivi de la qualité peut être effectué dans un rapport annexe. Les indicateurs de qualité sont à construire selon différentes dimensions pour s’assurer de couvrir tout le spectre de la qualité des données.

Ce rapport n’a pas une visée à réaliser du data profiling, mais assure que les données sont en qualité pour répondre à l’usage. Des alertes sur des seuils par exemple, sont à paramétrer pour déclencher des actions de mise en qualité ainsi que pour alerter les utilisateurs dans un principe de transparence.

Une Data Visualisation qui satisfait les métiers

Donner de l’autonomie au métier dans la production de ces data visualisations ne va pas automatiquement leur permettre de répondre à leurs usages et ainsi provoquer leur satisfaction. Ce gain d’autonomie nécessite aussi un accompagnement plus important en termes de formation et de change management. De même, la multiplication des data visualisations peut voir la quantité l’emporter au dépend de la qualité et donc drastiquement réduire l’expérience utilisateur qui se retrouve perdue dans une multitude de visualisations de données. La satisfaction métier est donc évidemment un axe clé à maîtriser.

En effet si l’on résume les deux points précédents, on obtient, une data visualisation :

• Conforme aux diverses réglementations,
• Partagée et accessible à une liste d’utilisateurs pilotée,
• Présentant des données de qualité,
• Mutualisable pour d’autres usages (notamment la data préparation).

Ceci a pour bénéfice de maximiser la satisfaction des utilisateurs mais également des acteurs projets internes.

La satisfaction des métiers s’apprécie au regard de leur utilisation des data visualisations auxquelles ils peuvent accéder. La mise en place de rapport de suivi de l’utilisation des data visualisations est un outil qui est à utiliser pour effectuer des revues des rapports en production. Ces revues peuvent déclencher des actions pour réétudier le besoin métier.
Ceci fait partie d’un axe important de la gouvernance qui s’assure que le produit répond à un besoin et est maintenu dans le temps.

Vous l’aurez compris par ces trois enjeux, gouverner les data visualisations passe par des actions simples, qui permettent d’assurer leur gouvernance. Celle-ci est importante et permettra d’assurer que ces rapports soient fiables, de confiance, et utilisés à bon escient pour tous les utilisateurs.

Pour en savoir plus, n’hésitez pas à contacter nos experts Transformation Data.

Il n’est pas toujours évident de s’y retrouver dans la jungle que constituent les différents comités en entreprise, et les comités d’architecture ne font pas exception. Vous êtes perdus et ne savez pas comment définir la comitologie qui répondra aux besoins de votre organisation ? Suivez le guide !

Dans cet article, nous aborderons deux grandes étapes : 

• la définition de la comitologie d’architecture, dans un premier temps, 
• suivie par un focus sur l’animation de cette comitologie.

Une comitologie utile et intéressante doit être construite pour répondre à vos objectifs

Identifier clairement les objectifs de la comitologie

Les objectifs des organisations étant très divers, il est naturel qu’une myriade de comités d’architecture différents existent : 

• des comités transverses ou spécifiques à un programme de transformation, 
• des comités de partage entre architectes,
• ou des comités d’arbitrage.

L’un des écueils principaux consiste à faire surgir dans les agendas autant de comités que de champignons après les premières pluies d’automne. On voit souvent des participants occasionnels se mélanger les pinceaux avec les trois ou quatre réunions portant un nom approchant. Et s’ils ne savent pas les différencier, nul doute qu’ils ignorent leurs objectifs…

Mais dans ce cas, comment créer une comitologie d’architecture claire, lisible et utile ? 

Afin de choisir la plus adaptée, il est tout d’abord capital de bien comprendre le contexte de votre entreprise et d’identifier vos objectifs. Cela peut passer par des interviews mais aussi être exploré dans le cadre d’un audit de maturité de l’architecture, qui comporte un volet sur la comitologie. 

Définir ensemble la comitologie qui répond aux objectifs identifiés

Une fois les objectifs clarifiés, la construction collaborative de la comitologie peut ensuite débuter !

Rhapsodies Conseil vous aide à dessiner la comitologie qui vous conviendra le mieux en s’appuyant sur : 

• les éléments de contexte,
• un catalogue d’exemples de comités d’architecture,
• un arbre de décision.

Votre connaissance fine de l’organisation dans laquelle vous évoluez sera également précieuse et devra être prise en compte. 

Vous obtiendrez à terme une description des différents comités d’architecture à mettre en place précisant : 

• leurs objectifs, 
• la fréquence à laquelle ils seront tenus, 
• leurs périmètres respectifs,
• les différents participants. 

Ces éléments seront bien sûr diffusés au sein de l’organisation pour bien expliquer le rôle du ou des comités d’architecture. Bien communiquer en amont de la mise en place des comités permettra de s’assurer que tous les participants, récurrents ou occasionnels, n’aient pas de doutes sur leurs objectifs.

Il ne reste plus qu’à les mettre en œuvre et les animer !

Pas si simple me direz-vous ? Comment s’assurer que cette comitologie soit animée de manière efficace et réponde ainsi aux objectifs de l’organisation ? 

Tout en évitant à tout un chacun d’écouter distraitement d’une oreille en travaillant sur un autre sujet en parallèle ou en traînant sur son téléphone… 

Eh bien, en s’appuyant sur le PMO de l’architecture ! 

Le PMO de l’architecture : cet acteur clé qui rend vos comités efficaces et productifs

Qui est le PMO de l’architecture ?

Ce terme de “PMO” a été dévoyé et il peut paraître n’être qu’un scribe qui n’apporte pas de vraie valeur ajoutée. Notre conviction chez Rhapsodies Conseil est la suivante : cet acteur doit avoir une culture de l’architecture d’entreprise. Il peut alors faire tellement plus pour l’équipe architecture que compléter un fichier excel une fois par mois !

Il  dispose ainsi de nombreuses compétences : 

• bonne connaissance du SI
• maîtrise de la gouvernance de l’architecture,
• bon relationnel,
• compréhension de l’organisation et du rôle de l’équipe d’architecture,
• compréhension des enjeux projets,
• connaissance des dossiers d’architecture et des modèles, 
• techniques d’animation de réunions.

C’est pourquoi il est le plus à même d’animer la comitologie d’architecture et de la rendre intéressante pour l’ensemble des participants, décideurs y compris.

La première activité du PMO de l’architecture : sélectionner et vérifier les dossiers d’architecture

C’est lui qui propose un ordre du jour en fonction de la maturité et du niveau d’urgence des dossiers d’architecture. Il vérifie que ceux-ci sont bien complets avant leur passage en comité. Il comprend les enjeux et peut donc appuyer les différents architectes dans la préparation de leurs dossiers. Il dispose aussi de templates de dossiers d’architecture afin de guider les architectes nouvellement arrivés dans la rédaction de leurs premiers dossiers. 

Une bonne préparation avec des attendus précis, dont le PMO de l’architecture est le garant, permet d’éviter bien des désillusions en comité… Et de devoir à de nombreuses reprises rapporter les mêmes éléments complémentaires devant des participants qui ont oublié une bonne partie du sujet…

Le PMO de l’architecture est aussi en charge de l’animation des comités le jour J

L’animation des comités en tant que tels fait également partie de son rôle : il partage l’ordre du jour, suit le bon déroulement du comité, recueille les avis en séance et prend les notes explicatives. Il établit le relevé de décision et partage le compte-rendu aux différents participants. 

Il peut aider à remettre le comité sur le droit chemin quand les échanges s’enlisent. 

Un suivi est mis en place par le PMO pour que les décisions ne restent pas lettre morte

Suite aux comités, il réalise le suivi des dossiers en fonction des décisions : 

• passage en mode projet, 
• programmation d’un deuxième passage du dossier, 
• études à refaire ou à compléter. 

Il établit donc les ordres du jour des prochains comités. 

Ce suivi fin des ordres du jour permet d’éviter ce que l’on voit parfois : 

• un ordre du jour déformé car il a été mal compris par la personne chargée du suivi,
• la présentation d’un sujet devant des décideurs qui ont oublié l’avoir demandé. 

Il peut identifier les décisions qui donnent lieu à de la dette et en faire le suivi. 

De plus, connaissant les différents dossiers en cours, il maîtrise les dépendances entre les sujets. Il est donc à même de prévenir les architectes dont les sujets peuvent être impactés par les décisions du comité. Le PMO de l’architecture ayant une vision globale de l’avancement des sujets, il peut créer du lien entre les architectes. Cela permet aussi d’assurer que l’ensemble des décisions prises lors des comités restent cohérentes.

Le PMO de l’architecture participe également à l’amélioration continue de la gouvernance de l’architecture 

Enfin, son rôle transverse lui permet de construire le reporting de la comitologie : il suit le nombre de dossiers qui passent en comité, les décisions et les avis émis… Il peut alors proposer des améliorations de la comitologie afin d’optimiser la gouvernance de l’architecture. Il pourra donc vous aider à ajuster la comitologie si nécessaire en fonction de ce qu’il observe en comité et des issues des présentations. 

J’ai tenu ce rôle pendant 1 an et eu la chance de travailler avec des collègues qui avaient aussi tenu ce rôle. J’espère que cette synthèse vous sera utile et que vous connaissez désormais mieux le PMO de l’architecture, cet acteur qui garantit le succès de vos comités. N’hésitez pas à nous contacter pour échanger sur vos retours d’expérience. 

Après avoir été successivement décrit comme le job le plus sexy du 21^ème siècle puis comme aisément remplaçable par la suite, le data scientist a de quoi souffrir aujourd’hui de sacrés questionnements. Son remplaçant le plus pertinent ? Les solutions d’Auto-Machine Learning, véritables scientifiques artificiels des données, capables de développer seuls des pipelines d’apprentissage automatique pour répondre à des problématiques métier données.

Mais une IA peut-elle prendre en charge la totalité du métier de data scientist ? Peut-elle saisir les nuances et spécificités fonctionnelles d’un métier, distinguer variables statistiquement intéressantes et fonctionnellement pertinentes ? Mais aussi, les considérations d’éthique des algorithmes peuvent-elles être laissées à la main … des mêmes algorithmes ?

Le Data Scientist, vraiment éphémère ?

Le data scientist est une figure centrale de la transformation numérique et data des entreprises. Il est l’un des maîtres d’œuvre de la data au sein de l’organisation. Ses tâches principales impliquent de comprendre, analyser, interpréter, modéliser et restituer les données, avec pour objectifs d’améliorer les performances et processus de l’entreprise ou encore d’aller expérimenter de nouveaux usages. 

Toutes les études sur les métiers du numérique depuis 5 ans sont unanimes : le data scientist est l’un des métiers les plus en vogue du moment. Pourtant, il est plus récemment la cible de critiques. 

Des observateurs notent une baisse de la « hype » autour de la fonction et une décroissance du ratio offre – demande, qui viendrait même pour certains à s’inverser. Trop de data scientists, pas assez de postes ni de missions. 

Deux principales raisons à cela : 

• La multiplication de formations et bootcamps certifiants pour le poste, résultant en une inondation de profils juniors sur le marché ; 
• Une rationalisation des organisations autour de l’IA et une (parfois) limitation des cas d’usage – l’époque de l’armée de data scientists délivrant en série des POCs morts dans l’œuf est belle est bien révolue. 

Mais également, et c’est cela qui va nous intéresser pour la suite, pour certains experts, le « data scientist » ne serait qu’un buzzword : l’apport de valeur de ce rôle et de ses missions serait surévalué, jusqu’à considérer le poste comme un effet de mode passager voué à disparaître des organisations. 

En effet, les mêmes experts affirment qu’il sera facilement remplacé par des algorithmes dans les années à venir. D’ici là, les modèles en question deviendraient de plus en plus performants et seraient capable de réaliser la plupart des tâches incombées mieux que leurs homologues humains. 

Mais ces systèmes si menaçants, qui sont-ils ?

L’Auto-ML, qu’est-ce que c’est ?

L’apprentissage automatique automatisé (Auto-ML) est le processus d’automatisation des différentes activités menées dans le cadre du développement d’un système d’intelligence artificielle, et notamment d’un modèle de Machine Learning.

Cette technologie permet d’automatiser la plupart des étapes du procédé de développement d’un modèle de Machine Learning :

• Analyse exploratoire : préparation et nettoyage des données, détection de la typologie de problème à adresser ;
• Ingénierie et sélection des variables : analyse purement statistique (et non fonctionnelle, c’est l’un des points faibles) des différentes variables, sélection des variables pertinentes, création de nouvelles variables (ces modèles peuvent-ils le faire… ?)  ;
• Sélection du ou des modèles à tester, entraînement, mise en place de méthodes ensemblistes de modèles, fine tuning des hyper-paramètres, analyse et reporting de la performance ;
• Agencement de l’analyse : mise en place du pipeline sous contrainte (coût / durée d’entrainement, complexité du ou des modèles, …) ;
• Industrialisation et cycle de vie : restitution à l’utilisateur des résultats sous la forme de graphes ou d’interface, branchement simplifié à un tableau de bord prêt à l’emploi, sauvegarde et versionning des différents modèles.

L’Auto-ML démocratise ainsi l’accès aux modèles d’IA et techniques d’apprentissage automatique. L’automatisation du processus de bout en bout offre l’opportunité de produire des solutions (ou à minima POC ou MVP) plus simplement et plus rapidement. Il est également possible d’obtenir en résultat des modèles pouvant surpasser les modèles conçus « à la main » en matière de performances pures.

En pratique, l’utilisateur fournit au système :

• Un jeu de données pour lesquelles il souhaite mettre en place son usage d’intelligence artificielle – par exemple une base de données client et d’indicateurs calculés (chiffre d’affaires total, sur la dernière année, nombre de transactions, panier moyen, propension à abandonner son panier, …)
• Une variable cible d’entraînement, qu’il souhaite prédire dans le cadre de l’usage en question – par exemple la probabilité de CHURN du client en question ;
• Des contraintes vis-à-vis de la sélection du modèle : quelle typologie de modèle à utiliser / exclure, quelle(s) métrique(s) de performance considérer, quels seuils de performance accepter, quelle durée d’entraînement maximale tolérer, …

Le système va alors entraîner plusieurs modèles – ensemble de modèles et modéliser les résultats de cette tache sous la forme d’un « leaderboard », soit un podium des modèles les plus pertinents dans le cadre de l’usage donné et des contraintes listées par l’utilisateur.

Quelles sont les limites de l’Auto-ML ?

Pour autant, l’Auto-ML n’est pas de la magie et ne vient pas sans son lot de faiblesses. 

Tout d’abord, les technologies d’Auto-ML rencontrent encore des difficultés à traiter des données brutes complexes et à optimiser le processus de construction de nouvelles variables. N’ayant qu’une perception statistique d’un jeu de données et (aujourd’hui) étant dénué d’intuition fonctionnelle, il est difficile de faire comprendre à ces modèles les finesses et particularités de tel ou tel métier. La sélection des variables significatives restant l’une des pierres angulaires du processus d’apprentissage du modèle, apparaît ainsi une limite à l’utilisation d’Auto-ML : l’intuition business humaine n’est ainsi pas (encore) remplaçable.

Également, du fait de leur complexité, les modèles développés par les technologies d’Auto-ML sont souvent opaques vis-à-vis de leur architecture et processus de décision (phénomène de boîte noire). Il peut être ainsi complexe de comprendre comment ils sont arrivés à un modèle particulier, malgré les efforts apportés à l’explicabilité par certaines solutions. Cela peut ainsi amoindrir la confiance dans les résultats affichés, limiter la reproductibilité et éloigner l’humain dans le processus de contrôle. Dans une dynamique actuelle de prise de conscience et de premiers travaux autour de l’IA éthique, durable et de confiance, l’utilisation de cette technologie pourrait être remise en question.

Enfin, cette technologie peut aussi être coûteuse à exécuter. Elle nécessite souvent beaucoup de ressources de calcul (entrainement d’une grande volumétrie de modèles en « one-shot », fine tuning multiple des hyperparamètres, choix fréquent de modèles complexes – deep learning, …) ce qui peut rendre son utilisation contraignante pour beaucoup d’organisations. Pour cette même raison, dans une optique de mise en place de bonnes pratiques de numérique durable et responsable, ces technologies seraient naturellement écartées au profit de méthodologies de modélisation et d’entrainement plus sobres (mais potentiellement moins performantes).

Quelles solutions d’Auto-ML sur le marché ?

On peut noter 3 typologies de solutions sur le marché : 

• Les solutions des éditeurs de cloud (GCP, AWS, …), pré-packagées dans les offres, permettant de profiter d’infrastructures d’entraînement performantes et de modèles pré-entraînés ; 
• Les éditeurs spécialisés dans les plateformes de data science, comme la licorne française Dataïku ou le pure-player ML DataRobot ; 
• Les librairies Python (et leur pendant R, parfois) open-source, certaines se branchant sur des frameworks bien connus de la profession (Auto Sklearn, AutoKeras, …) 

H2o Auto-ML en pratique

Jetons un coup d’œil à H2o.ai, librairie Python open source d’Auto-ML développée par l’entreprise éponyme. Nous prendrons comme cas d’usage un problème de classification binaire classique sur des données tabulaires, issu du challenge mensuel Kaggle d’Août dernier. 

Après un chargement des données et une initialisation de l’instance locale, on va pouvoir lancer le moteur d’AutoML : 

Doivent être spécifiés : 

• La volumétrie maximale de modèles à entraîner (permet d’ajuster les performances et de ne pas aller dans le « toujours plus ») ; 
• Une durée maximale de temps d’exécution, pratique en phase de prototypage du pipeline ; 
• Le H2o dataframe d’entraînement en indiquant les variables indépendantes (x) et la variable à prédire (y). A noter qu’il s’agit d’un format de dataframe spécifique mais que la conversion depuis et vers un dataframe pandas « traditionnel » se fait très simplement.

Il est également possible d’ajouter des paramètres tels que :

• Les éventuelles typologies de modèles à exclure – ici on retire les modèles de deep learning mais peuvent également être exclus l’empilement (« stacking ») de modèles, les xgboost ou encore les algorithmes de « gradient boosting » ;
• Une métrique d’arrêt (ex : logloss, AUC, …) qui permettra, une fois la valeur cible atteinte ou un nombre de rounds d’entrainement sans amélioration dépassé d’arrêter le processus de training ; 
• Tout un ensemble de paramètres pour gérer la validation croisée (nombre de folds, conservation des modèles non retenus et leurs prédictions, …) ;
• Des fonctionnalités de ré-équilibrage des classes, afin d’adresser les problématiques de datasets déséquilibrés (par exemple, dans un problème de classification binaire, une répartition 90-10 sur la variable à prédire dans le jeu d’entraînement) ; 
• … et bien d’autres – plus d’informations dans la documentation du moteur. 

Il est important de noter que H2o AutoML ne propose aujourd’hui qu’une fonctionnalité limitée de préparation des données, se limitant à de l’encodage de variables catégorielles. Mais la société travaille aujourd’hui à enrichir ces fonctionnalités.

Une fois l’entraînement terminé, des informations sur le modèle vainqueur sont affichées : 

• Informations de base sur le modèle : nom, typologie, paramètres, … Dans notre cas, il s’agit d’un ensemble de plusieurs modèles et l’ensemble des paramètres n’est pas affiché (disponible via une commande supplémentaire)
• Un listing des performances du modèle : matrice de confusion, métriques de classification (voir ci-dessous)

Il est également possible d’avoir accès au « leaderboard » des modèles entrainés et testés : identifiant, performances, temps d’entrainement et de prédiction, typologies des modèles (ensembles, gradient boosting, …) .

Informations modèle leader

Leaderboard

Voir en
plein écran

Enfin, le module d’explicabilité (restreinte…) nous permet d’obtenir des informations sur l’importance globale des variables dans les décisions du modèle, ainsi que l’importance globale des variables par modèle entraîné / testé, des graphes de dépendance partielle, une représentation des valeurs de SHAP des variables, … Il est également possible d’obtenir des explications locales sur des prédictions données.

En définitive, H2o AutoML permet d’expérimenter rapidement sur un cas d’usage donné, permettant par exemple de valider l’intérêt d’une approche par Machine Learning. Pour autant, dans notre cas précis, le modèle vainqueur constitue un assemblage complexe de plusieurs modèles non clairement spécifiés (il faut chercher…longtemps !) et cette complexité et ce manque de transparence peuvent en premier lieu rebuter les utilisateurs.

En définitive, l’Auto-ML signe-t-il vraiment la fin du Data Scientist ?

Le succès futur de cette technologie repose aujourd’hui sur les progrès à venir en matière d’apprentissage par renforcement, discipline qui peine aujourd’hui à percer et convaincre dans le monde professionnel. L’explicabilité et la transparence sont également des challenges à relever par cette technologie pour accélérer son adoption.

Mais de toute évidence, l’Auto-ML s’inscrira durablement dans le paysage IA des années à venir. 

Quant au data scientist, il est certain que la profession telle que nous la connaissons va être amenée à évoluer. Nouvelle au début des années 2010, comme tous les métiers depuis et selon les organisations, leurs profils et activités vont évoluer.

D’un côté, des profils data scientists plus « business » et moins « tech » vont certainement se dégager se concentrant sur des échanges avec les métiers et la compréhension fine du fonctionnement et des enjeux des organisations. On peut d’ores et déjà voir que ces profils émergent des équipes business elles-mêmes : les fameux citizen data scientists. Ces derniers seront très certainement des fervents utilisateurs des outils d’AutoML. 

Également, des profils hybrides data scientist – engineer se multiplient aujourd’hui, ajoutant aux activités classiques de data science la mise en place de pipelines d’alimentation en données et l’exposition des résultats et prédictions sous un format packagé (API, web app, …). L’ère du Machine Learning Engineer a déjà démarré !