Archives du mot-clé data

Contribution PxData
Politique de la donnée – procédé et formalisation

PxData

Définition d’une politique de la donnée

Aucune organisation ne peut ignorer le phénomène Data. La pression par les données devient de plus en plus forte (obligations réglementaires, nouveaux risques liés à l’inflation de la circulation et de l’exposition des données…).  les opportunités offertes par les données explosent (création de business models par l’intégration de services orientés données, enrichissement des données par le sourcing externe…). Les organisations multiplient les initiatives.

Dans ce contexte, comment piloter de manière concertée tout ce qui a trait aux données au sein d’une organisation ? Un élément de réponse est la définition d’une politique de la donnée.

En 2015, dans le cadre de la méthode publique Praxeme, une première version d’un procédé d’élaboration d’une politique de la donnée a été proposée. Ce procédé est le résultat de travaux de la société CONIX avec le support des auteurs de la méthode publique.

Le cœur de la politique est, par essence, le capital « données ». Sur la base de ce capital nous allons décrire les éléments clés support à la politique : définition, sensibilité à l’exposition, réglementaire, règles d’usage…

Praxeme couvre tous les aspects de l’entreprise, de la stratégie au déploiement. Sept aspects sont identifiés dans ce que l’on appelle le « Système Entreprise ». Les données sont présentes dans chacun de ces aspects et la politique de la donnée proposée est donc structurée pour répondre à chacun d’entre eux :

  • Aspect Intentionnel : les valeurs de l’entreprise et ses finalités (stratégie, culture, contraintes…)
    ➜ Déclinaison dans la politique de la donnée : exprimer les intentions liées aux données tout en respectant les valeurs de l’entreprise
  • Aspect Sémantique : la connaissance, les fondamentaux du métier (l’environnement, l’offre de l’entreprise, les objets métier…)
    ➜ Politique de la donnée : assurer la compréhension partagée des données (définition, dictionnaire, modèle sémantique…)
  • Aspect Pragmatique : les activités de l’entreprise et son organisation (rôles, processus, styles de management et de contrôle…)
    ➜ Politique de la donnée : ordonner les activités en vue de l’exploitation optimale des données, mettre en lumière dans les processus existants les impacts de la politique et faire les adaptations nécessaires
  • Aspect Géographique : la localisation des activités de l’entreprise (géographie de l’entreprise, virtualisation, télétravail, équipement nomade…)
    ➜ Politique de la donnée : préciser les dispositions techniques et organisationnelles à prendre quant à la distribution géographique des données
  • Aspect Logique : un aspect intermédiaire entre métier et technologie, introduit dans la chaîne de transformation pour faciliter la conception des systèmes techniques
    ➜ Politique de la donnée : Décrire l’architecture logique de données
  • Aspect Logistique : l’ensemble des ressources techniques au service de l’activité
    ➜ Politique de la donnée : Identifier les composants techniques support à l’architecture de données
  • Aspect Physique : le Système Entreprise complètement déployé (avec toutes ses ressources localisées)
    ➜ Politique de la donnée : Préparer le déploiement de la politique, dimensionner la cible, accompagner le changement

Enfin le dernier point nécessaire à une politique de la donnée est la gouvernance associée. C’est-à-dire l’organisation nécessaire à la maîtrise des données (profils, compétences…), l’inscription dans la « comitologie » existante, l’interaction avec les projets de transformation et trajectoire pour une cohérence transverse à la politique de la donnée et la promotion de la culture de la donnée au sens large pour la bonne mobilisation des collaborateurs.

Le formulaire et le mode d’emploi sont téléchargeables dans le respect de la licence Creative Commons qui régit le fond documentaire Praxeme (documents PxPRD-04f – Politique de la Donnée – et PxPRD-04m – mode d’emploi).

Ce premier travail, finalisé en 2015, a vocation à se poursuivre en 2016 et 2017 pour, en particulier, renforcer l’angle innovation et data science, accompagner la culture de l’expérimentation, développer le caractère auditable de l’application de la politique, explorer la dimension éthique et, enfin, réaliser un état de l’art sur les outils supports d’une politique de la donnée et de sa mise à jour.

Auteurs : Delphine BARRAU & Joël BIZINGRE

politique de la donnée - Observatoire CONIX de la donnée

Big Data : préparez le déluge !

Arche de Noé

Dans notre précédent billet, nous évoquions la « data agility » comme levier de réussite pour la conduite d’un projet Big Data.

Si cela reste notre conviction, il n’est pas rare de lire dans la presse spécialisée SI (exemple du sondage CRIP autour du Big Data) que l’un des principaux freins à la réussite d’un projet demeure l’insuffisance de compétences au sein des DSI.

Ayant en mémoire un autre article, paru il y a quelques mois, qui abordait de manière humoristique cette problématique, force est de constater que la question des compétences nécessaires à la réussite d’un projet Big Data est un sujet récurrent.

Alors en temps qu’animateur de projet, si vous deviez, tel Noé, n’embarquer que quelques personnes pour une aventure sur le « grand lac de données » qui devriez-vous choisir ? S’il faut effectivement des compétences techniques (probablement un peu rares en regard de l’engouement récent pour le Big Data), il faut également des compétences métier. Nous vous conseillons donc d’embarquer avec vous les 6 rôles suivants.

Un narrateur sera un élément clé pour faciliter l’adhésion au projet. Par ses qualités de communicant et ses talents d’orateur, il saura porter la conviction au niveau des directions métier, communiquer sur le résultat des études, et convaincre le top Management. Il doit aussi avoir une forte appétence pour les données et très bien les comprendre pour en saisir la complexité et les limites. Le narrateur peut être interne ou externe, côté DSI ou métier, tant qu’il est à l’aise pour animer et communiquer.

La construction du modèle de données doit s’appuyer sur un expert en modélisation. Cet acteur connait et comprend l’entreprise dans sa vision dynamique (produit ou processus) et dans sa vision statique (modèle des objets métiers). Il est le gardien du temple pour les définitions et les règles métiers. Cette compétence est détenue généralement dans les pôles architectures, du côté des architectes de données ou des urbanistes. Interne ou externe, il faut surtout éviter de reproduire les modèles historiques et apporter de la généricité et de l’évolutivité.

Un ingénieur en technologie Big Data appuiera l’équipe dans le choix des outils existants, pour cibler et implémenter ceux qui répondent le mieux au besoin et à l’environnement. En fonction de son profil et de l’ampleur du projet, il devra être accompagné de développeurs pour construire le système. Ces compétences n’existent encore que peu en interne et si beaucoup de SSI se positionnent sur le marché, c’est souvent du côté des PME et startups que l’on trouve les meilleurs profils.

Il y a « the man in the shadow » (en référence au « data shadow » du précédent billet). Expert de la donnée, il les connait bien car il les manipule depuis des années avec ses outils bureautiques (fonctions d’extraction de données des applications, Access, Excel pour les interpréter, messagerie pour les échanger…). Il apportera une compétence fondamentale sur la valeur des données de l’entreprise. C’est une ressource interne par excellence, à chercher, par exemple, du côté des services financiers, marketing, ou statistiques si il existe.

Le datascientist est celui qui va créer l’inspiration et générer des idées en manipulant les données à la recherche de corrélations intéressantes (nous vous renvoyons à un de nos précédents billets pour notre vision du datascientist). Il s’appuiera sur les sachants métier, l’expert en modélisation et « the man in the shadow » pour valider son analyse des données et utiliser les bonnes sources internes à l’entreprise.

Beaucoup de projets se retrouvent bloqués par un manque de données, soit parce que le processus qui les génère n’est pas instrumenté, soit parce que l’entreprise ne les possède pas, tout simplement. Les deux derniers acteurs précités vont devoir investiguer pour résoudre cette difficulté. Ils rendront un service inestimable en remettant constamment en question le reste de l’équipe et les autres parties de la société qui pourraient fournir ces fameuses données (référence aux éternels silos métiers). Mais ils seront parfois légalement « borderline » car ne se soucieront pas toujours des conséquences (respect de la vie privée, informations commercialement sensibles…).

Un déontologue viendra donc compléter cette liste. Au plus près des équipes pour poser les questions de confidentialité sur les données et les cas d’usages, ses compétences permettront d’éviter des ennuis avec les autorités mais également avec les clients. Car l’écart est grand entre ce qui est techniquement légal et ce que les utilisateurs sont prêts à accepter. Il aidera l’équipe à trouver le juste équilibre. De récentes études prouvent que les entreprises ont tendance à prendre plus de mesures conservatrices quand elles n’ont pas accès à des conseils de qualité sur ce qu’elles peuvent faire ou non, par peur de transgresser accidentellement une loi. Des cabinets se spécialisent de plus en plus dans cette mission, ou s’associent pour offrir une couverture complète de la chaine de la donnée.

En guise de conclusion et avant de se voir opposer la carte de la disponibilité des ressources, nous parlons bien ici de compétences. Certains profils peuvent donc posséder plusieurs compétences et cumuler les rôles. Et, bien sûr, ce ne sont pas des rôles à temps plein. Ils n’interviennent parfois que ponctuellement mais toujours au juste moment. Nous avons, par nos expériences passées, acquis une certaine visibilité sur les charges associées en fonction des projets et nous les partagerons avec plaisir avec vous.

Auteure : Delphine BARRAU

data - Observatoire CONIX de la Donnée

Data Agilité : Comment le big data devient agile !

En 2001, les initiatives historiques autour de l’agilité se fédèrent avec le Manifeste Agile, qui couvre désormais toutes les activités d’une organisation. L’agilité est devenue un mot clé plus seulement limité au périmètre des projets. C’est la solution idéale vers laquelle toute organisation s’oriente pour répondre aux enjeux et contextes à venir.

Parallèlement, l’apparition ces dernières années des big data et surtout la prise de conscience de leur potentiel a poussé les géants de l’informatique à mettre en œuvre des architectures de stockage assez complexes, massivement distribuées, capables d’engloutir des données toujours plus nombreuses et variées. Les entreprises traditionnelles de leur côté, se retrouvent devant une jungle d’outils estampillés big data, avec des problématiques qui leurs sont propres, mais sans aucune promesse de connaître un jour le succès des GAFAS et autres NATU (Netflix, Airbnb, Tesla, et Uber).

Dans un tel contexte, il devient crucial de savoir concilier deux besoins : d’une part, celui de disposer d’une architecture de données (moyens – technologies – logiciels – infrastructure, contenus, politique) robuste et, d’autre part, celui de répondre rapidement (le « juste à temps ») et de façon agile à des besoins métier (use case). Cet article propose une définition de la Data Agilité.

La Data Agilité, c’est répondre aux enjeux du Big Data, proposer une architecture robuste, c’est-à-dire vérifiant un ensemble de qualités telles que performance, sécurité, lisibilité, traçabilité et résilience. Pourtant, dans la réalité, la construction d’une telle infrastructure échappe souvent à la vigilance des entreprises. Certaines s’engouffrent dans une phase architecturale longue, quasi bureaucratique, au délai non adapté et aux lacunes variées. D’autres, au travers de projets dits novateurs, se retrouvent avec des architectures non pérennes se transformant en goulot d’étranglement, et au final le ROI n’est plus assuré.

Pire, une fois l’architecture aboutie, celle-ci devient non conciliante, car à la recherche de la norme absolue de représentation des données, niant ainsi la richesse des différents points de vue et des différentes maturités à considérer sur les données. Son contenu accuse alors un retard continu dans la prise en compte des évolutions, intrinsèques au contexte de toute entreprise. Finalement, la construction d’une telle architecture accumule les reproches que l’on retrouve dans des projets plus classiques de type datawarehouse d’entreprise.

Le projet est fragilisé : il s’appuie sur des données non maîtrisées, qui dégradent les fonctions visées. A terme, l’architecture finit par reconstituer des silos de données et aboutit à un stockage « dépotoir » avec le retour des problématiques de cohérence / écarts du fait de l’utilisation de données « non fiables  » ou non contrôlées.

Un récent sondage réalisé par le CRIP autour du Big Data annonce que 50% des CTO français estiment que l’un des principaux freins aux projets Big Data est l’insuffisance de compétences au sein des DSI. Pourtant, les compétences ne sont pas les seules à entrer en jeu : l’un des freins majeurs, selon nous, est le manque d’alignement entre la démarche agile et l’architecture de données sous-jacente aux projets Big data.

Premier point, la Data Agilité pose les briques essentielles d’un projet à succès car elle répond à une logique de capacités et non à un besoin précis : alimentation de données, représentations des données, fonctions d’exploitation de ces données, contrôle et gouvernance des données… Plus précisément, on cherche à mettre à disposition une architecture ayant la capacité à répondre à N besoins que l’on ne connait pas à l’avance. L’architecture est un cadre structuré facteur d’accélération, de préservation et de capitalisation des travaux antérieurs sur les données.

Deuxième point, cette capacité couverte par l’architecture de données relève d’une construction incrémentale alignée avec les projets. Cette démarche itérative sur le plan de l’architecture doit rejoindre celle que l’on retrouve dans un projet data science :

Data Agilité : Démarche de Data Science

  • Mise en place du socle – construction de l’architecture de données : cette première étape vise à initier la structure data agile en esquissant une vision macroscopique de la partie modélisation des données (à l’aide d’un modèle d’objet métier par exemple) et en chargeant les premiers jeux de données bruts sur une infrastructure de base. On privilégiera lors de cette étape des outils de stockage « ouvert » ou des solutions de data virtualisation, les scénarios variant bien sûr selon l’existant IT.
  • Itération X – «  réponses » agiles au use case data : la seconde phase vise quant à elle à développer l’architecture initiale selon les uses case data que l’on souhaitera aborder. La modélisation du macro-modèle pourra être détaillée, de nouvelles briques d’architecture ajoutées ou étendues…

Troisième point, l’architecture doit également accorder une autonomie vitale aux nouveaux acteurs et organisations data (CDO, data scientist, datalab, data manager…) en apportant d’une part le « juste à temps » grâce à sa rapidité de mise en œuvre et d’exploitation immédiate et, d’autre part une structuration / représentation des données à l’usage et non a priori. Le data shadow IT (excel, mail d’échanges de données…) coté métier est de son côté réintégré dans l’architecture et encadré par l’autonomie apportée. Enfin, l’intégration de nouveaux composants dès le premier incrément, renforce cet esprit d’agilité, de « juste à temps » et d’autonomie. On distinguera notamment une chaîne de composants support aux démarches agiles :

  • Les « ETL visuels » : venant compléter les ETL classiques (Extract-Transform-Load) dont la fonction initiale est l’extraction (avec des connecteurs par sources de données), la transformation de données (filtre, enrichissement, fusion, jointure de données) et la création / alimentation d’une nouvelle source (un dataset). La nouveauté de ces outils est la « programmation » visuelle et dynamique qu’ils apportent à ces différentes étapes ainsi que leur facilité à combiner différentes sources (de la simple jointure à la mise en œuvre d’algorithme avancé de matching), en plus d’intégrer des fonctions avancées de calcul ou de pré-traitement/préparation des données.
  • Les bacs à sable : qui constituent une solution de stockage « libre », dans un espace dédié, sans perturbation des stockages dits industriels. Plus généralement, un bac à sable est conçu comme un environnement non opérationnel où les analystes et les scientifiques de la donnée peuvent tester des idées, manipuler les données et le modèle sans imposer une charge de calcul excessive sur les processus opérationnels de base. Il a une espérance de vie limitée et les découvertes associées sont soit incorporées dans l’entrepôt de l’entreprise soit abandonnées.
  • Les stockages de type NoSQL, Hadoop… libérant des contraintes de structuration a priori, par leur implémentation de modèles à la volée. Leur vocation est de répondre à la problématique de stockage des données en étant non-relationnelle, distribuée (réplication élévée), open-source et horizontalement évolutives.
  • Le « self BI », les fonctions de data discovery : c’est-à-dire la capacité de construire une couche d’abstraction sur des données sources de façon dynamique, à l’aide notamment de fonctions de navigation dans les données. Cette approche libre-service permet aux utilisateurs finaux de créer des rapports personnalisés et des requêtes analytiques dans un cadre structuré permettant de concilier industrialisation et expérimentation.

Quatrième et dernier point, n’oublions par enfin que la Data agilité c’est également la reprise de méthodes de travail agiles, dont la pertinence n’est plus à démontrer. On retiendra notamment la possibilité qu’elles offrent en terme de maturation métier au fur et à mesure de la progression du projet, mais aussi la prise en compte des évolutions, naturelles au contexte des projets data.

Alliée au phénomène data, la Data Agilité propose un cadre de travail robuste qui convaincra tous les acteurs de la donnée.

Auteurs : Joël BIZINGRE et Elkhader FATNI

Observatoire CONIX de la Donnée

Co-gouvernance des données : les limites d’un exercice « vertueux »

Co-gouvernance
Il était une fois, dans un pays appelé Entreprise, deux peuples qui vivaient en presque parfaite harmonie : le peuple Métier et le peuple SI (comme Système d’Information), le premier s’occupant des fonctions opérationnelles du cœur de l’activité de l’entreprise, le deuxième assurant, historiquement, le support technologique.

Le temps passe et, comme souvent dans toute organisation humaine, les activités évoluent, se mélangent, se complexifient, et les limites de responsabilité des uns et des autres, bien définies au départ, se brouillent.

C’est alors que surgit, dans notre pays appelé Entreprise, la « découverte d’une ressource inestimable » (ou devrais-je dire « la prise de conscience de la valeur jusque-là négligée d’une ressource »), je veux parler de la DONNEE ou DATA. Et cela ne se fait pas sans soulever un certain nombre de questions.

En effet, dans sa forme brute et comme beaucoup de ressources brutes, la donnée est de qualité médiocre, difficile à exploiter, à appréhender. Le peuple SI, qui stocke cette ressource dans ses espaces de rétentions (appelés communément « bases de données »), a beau déployer tous les outils possibles de raffinage, de purification, la qualité n’est pas au rendez-vous, ou alors à des coûts prohibitifs, car c’est à la source qu’il faudrait travailler ! Il devient alors impossible d’en retirer toute la valeur pressentie.

Débute une longue négociation entre les deux peuples. Qui a découvert cette ressource ? A qui appartient-elle ? Qui en a la responsabilité ?

Le peuple SI cherche à convaincre le peuple Métier de son implication dans le processus de création de cette ressource. Ce peuple doit prendre conscience que c’est SA donnée, qu’il en est le garant et qu’il assumer ce rôle pour le bien de l’Entreprise !

Peu enclin à gérer cette nouvelle activité, le peuple Métier finit par entendre raison et à se sentir investi d’une véritable mission : la GOUVERNANCE de la Donnée.

Mais le peuple SI, qui est tout de même à l’origine de cette découverte, ne voulant pas être en reste, propose d’instaurer une co-gouvernance des données : le peuple Métier sera le garant de la donnée et de sa valeur, la définira et cadrera la stratégie d’entreprise vis-à-vis de cette ressource au travers d’une Politique de la Donnée. Le peuple SI mettra en œuvre les technologies qui permettront de garantir cette politique de la donnée et de répondre aux objectifs stratégiques de l’entreprise, tout en apportant son expertise sur les technologies émergentes de traitement de l’information.

(J’aurais aussi pu vous raconter une autre histoire où le peuple Métier est, dès le départ, conscient que la donnée lui appartient et qu’il en est responsable, mais s’oppose à la résistance du peuple SI, et doit le convaincre de lui ouvrir les portes de ses espaces de rétentions pour analyser la situation et mettre en place les mesures nécessaires… Mais c’est une toute autre histoire… avec, étonnamment, les mêmes conclusions !)

Tout pourrait aller pour le mieux dans le meilleur des mondes. Mais les choses se corsent quand il est question de nommer un chef ! Qui sera le « chef de la donnée » ? Qui pilotera la manipulation et la transformation de cette donnée ? Le peuple métier qui connaît les données et leurs usages ? Ou bien le peuple SI qui connaît les outils et les technologies ?

Et c’est l’éternel recommencement (les crises ne sont pas que religieuses…). Les peuples ne se comprennent pas, s’opposent, se jugent et se déchirent (bon d’accord, là j’exagère un peu pour le sujet qui nous concerne).

Si je devais être la médiatrice du pays Entreprise, je rappellerais que, dans l’idéal, les responsabilités doivent être clairement séparées : le SI s’occupe des outils, le métier se charge des usages. La gouvernance des données concerne donc le SI essentiellement dans sa capacité à en assurer le support technologique. Mais comme aujourd’hui aucun « métier » n’a nativement l’approche transverse nécessaire, une bonne gouvernance des données passe par un parfait équilibre entre des acteurs métiers et des acteurs SI.

Néanmoins, comme dans toute structure (française, au moins), pour réussir et s’imposer il faut un seul et unique pilote. Un pilote proche du pouvoir, qui sait écouter et comprendre, ouvert et innovant et qui travaille pour le bien collectif de l’entreprise. Que ce pilote soit d’une origine ou d’une autre, je dirais « peu importe », à condition que ceux qui l’accompagnent dans la définition de la politique de la donnée, dans la connaissance du patrimoine DATA de l’entreprise, dans la sécurisation, le partage et le maintien en vie de ce patrimoine, soient mixtes et intégrés. Et je conseillerais fortement à ce pays de positionner ce pilote, quelque soit son origine, coté Métier dans une nouvelle structure transverse, voire dédiée.

J’espère que vous aurez apprécié le ton volontairement un peu naïf de cet article qui a pour finalité première de rappeler que l’on oublie trop souvent les fondamentaux, même (ou surtout) dans la gouvernance des données, quand il est question de Pouvoir.

Auteur : Delphine BARRAU

Le CDO mis à prix : tout le monde en veut !

CDO Wanted

Oui, mais lequel ? Le Chief Data Officer ou le Chief Digital Officier ?

En effet, duquel parle-ton ? Parmi les articles nombreux sur le Web, certains sèment la confusion. Nous avons l’exemple significatif du Journal du Net qui démarre l’article « Chief Data Officer, une destinée de bon augure ? », en décrivant les missions du Chief Data Officer, et le termine en évoquant la direction de rattachement probable et le salaire du … Chief Digital Officer ! Soit il s’agit d’une coquille (un peu grosse), soit l’auteur considère avoir affaire au même poste. Autre cas non moins symptomatique, celui d’Henri Verdier, nommé Administrateur Général des Données de l’État, poste que le journal Le Monde traduit par Chief Data Officer et met au même niveau que les Chief Data Officers de villes nord-américaines comme New York ou San Francisco, alors que celles-ci ont fièrement annoncé avoir embauché leur … Chief Digital Officer ! Une telle confusion n’est peut-être que le reflet de celle qui paraît régner dans les entreprises puisque, d’après Les Echos, 85% de ces dernières déclarent avoir un Chief Digital Officer. Ce phénomène est par ailleurs compréhensible car depuis deux ans, se succèdent les annonces de nominations de Chief Digital Officers par les grandes entreprises françaises (ERDF, L’Oréal, Pernod Ricard, Renault…). Alors, effet de mode ? Finalement, qui est qui ?

De fait, pour commencer à positionner les rôles respectifs du Chief Data Officer et du Chief Digital Officer, il faut revenir aux contextes encadrant ces métiers : le Big Data et la transformation numérique. Le premier contexte est celui de la multiplicité des sources de données internes / externes et structurées / non structurées. Le second regroupe les problématiques d’organisation et de modes de travail à partir du numérique pour repenser les activités, les partenariats, la relation client et jusqu’au business model de l’entreprise. Le Chief Data Officer serait alors plus proche du Big Data en termes opérationnels et le Chief Digital Officer de la transformation numérique en termes stratégiques. Qu’est-ce que cela signifie pratiquement ? Que font ces deux profils ? Que sont-ils censés savoir faire ? Où les trouve-t-on ? Où faut-il les placer au sein de l’entreprise ?

Chief Data Officer et Chief Digital Officer, pour quoi faire ?

Dans les magazines spécialisés du net, un consensus semble émerger à propos de la mission d’un Chief Data Officer. Son objectif serait d’apporter aux directions métiers – les directions marketing, commerciale, innovation et R&D sont généralement citées ; j’ajouterais celles de la production, des ressources humaines et de la finance – des « insights » pertinents et générateurs de valeur à partir du Big Data. L’« insight », en tant que vérité sur le consommateur porteuse d’un potentiel d’activité pour l’entreprise, oriente rapidement sur le point de vue du marché et du revenu bien sûr essentiel pour l’entreprise, mais la valeur peut se situer plus en amont, c’est-à-dire qu’on peut donner du sens à des données pour des directions qui ne génèrent pas du revenu (finances ou ressources humaines par exemple), et toute l’entreprise pourra en bénéficier.

En retouchant la définition de la mission du Chief Data Officer, on obtient : son objectif est d’apporter aux directions métiers, quelles qu’elles soient, à partir du Big Data, du sens générateur de valeur pour elles. Dans le détail, ce sens est construit en trois phases successives : la collecte, le traitement et la restitution / diffusion de données. En première phase, il s’agit d’identifier les sources de données, de les faire acheter par l’entreprise si nécessaire (en négociant les fonds en interne et avec les fournisseurs), de vérifier la qualité des données collectées, de les organiser et enfin de les classifier. Dans la phase de traitement, il faut filtrer les données, effectuer des calculs sur elles et les consolider en respectant les règles de gestion de l’entreprise. En ce qui concerne dernière phase, l’objectif est de rendre accessible les données obtenues sous le bon format, à la bonne personne et au bon moment. Dans ce cadre, il est facile d’imaginer l’utilité des outils de décisionnel (business intelligence en anglais) et d’analyse prédictive, mais la compétence associée à la maîtrise de ces outils doit s’accompagner d’une bonne connaissance du métier !

Le recruteur Robert Half a une formule heureuse pour décrire le poste de Chief Data Officer : « responsabilité de la gouvernance du capital que représentent les données ». Cette description met en évidence d’une part la notion de gisement de valeur des données, et d’autre part la fonction de garant de la politique de données, rarement citée et pourtant fondamentale dans l’activité du Chief Data Officer : un capital se protège et s’utilise selon des règles précises !

Cependant, dans ce qui précède n’est évoquée nulle vocation à faire transformer les processus et les organisations, même si la mise en place d’outils de traitement et d’analyse de données peut être à l’origine de telles transformations. C’est à ce moment qu’entre en jeu le Chief Digital Officer.

Autant, dans la littérature du Web, la description de la mission du Chief Data Officer est relativement précise, autant celle du Chief Digital Officer est vague ! Par exemple, le Chief Digital Officer doit « transformer, fédérer et piloter », formule manifestement appréciée, pouvant embrasser de bien vastes chantiers, mais lesquels précisément ? Les entreprises pressentent bien qu’il y a quelque chose à faire à partir du numérique, au moins générer plus de revenus et/ou rationaliser le portefeuille de projets numériques, d’où la nomination en série de Chief Digital Officers, parfois clonés au sein de la même structure et affectés d’objectifs pouvant parfois se contredire. Ainsi, pour l’Usine Digitale, un Chief Digital Officer est « chargé de guider l’entreprise dans sa transition numérique. (…) Il diffuse la culture et les projets digitaux auprès des collaborateurs. » Le mot est lâché, c’est un guide dont l’entreprise aurait besoin. Ce n’est pas elle qui sait, c’est lui qui a la VISION. Le mysticisme n’est pas loin, surtout dans les milieux technologiques qui raffolent des gourous. Même sans être croyant, une chose est sûre : l’enjeu est clairement organisationnel. S’il fallait retenir une description des missions d’un tel guide, on pourrait conserver celle d’Accenture qui propose 4 rôles :

  • le « digital strategist » qui pense la stratégie numérique de l’entreprise,
  • le « digital marketing leader » en charge de la génération de (nouveaux) revenus en ligne,
  • le « digitalisation leader » qui a pour objectif d’« injecter » le numérique dans la chaîne de production de l’entreprise,
  • et le « digital transformation leader » qui accompagne la transformation numérique, aux niveaux de l’organisation et des processus de l’entreprise.

On retrouve bien ici l’axe « externe » de la génération de revenus à partir de canaux numériques et celui « interne » de transformation des processus et des organisations, à partir d’une stratégie (autre mot pour vision).

Nous pouvons maintenant poser que le Chief Digital Officer travaille sur la valeur de l’entreprise (optimisation des modes de travail et des revenus) à partir de la valeur de la donnée, tandis que le Chief Data Officer s’applique concrètement à faire surgir cette valeur de la donnée. Le premier s’appuie dès lors naturellement sur le second.

Avec quelles compétences ?

On attend beaucoup d’un Chief Data Officer, peut-être un peu trop. Car qui ne rêverait d’embaucher un profil à la fois créatif, rigoureux, investigateur, ouvert, pédagogue et bon communicant auprès du management, connaissant les systèmes d’information, les langages de programmation, l’architecture de réseaux, l’analyse décisionnelle tout en ayant une forte orientation business ? Tout ceci pour un salaire entre 42 et 59k€ ! Difficile de faire mieux en termes de rapport qualité – prix.

Selon moi, il faudrait plutôt se concentrer sur l’essentiel, c’est-à-dire la valeur de la donnée pour les métiers. Deux axes de compétences sont ainsi concernés : une bonne connaissance des SI et en particulier une expérience consolidée sur des projets BI, associée à une expertise métier. Avec, en appui de ces compétences, une capacité à dialoguer / écouter et à transmettre. Reste qu’avec ce type de préconisation, il faut tout de même réussir à trouver l’homme ou la femme idoine, à rémunérer selon une fourchette de salaires forcément plus élevée que celle annoncée précédemment.

En revanche, le profil du Chief Digital Officer est plus difficile à cerner. L’opinion commune des cabinets et des ressources humaines cerne un expert de la transversalité, doté d’une culture hybride mêlant technicité digitale et connaissance du marché, adepte des méthodes agiles et possédant une bonne vision des enjeux stratégiques de l’entreprise. Peut-on être plus précis ? Pour ma part, je définirais le Chief Digital Officier comme la personne capable de dire rapidement à un comité directeur ce que signifie concrètement pour l’entreprise transformation numérique en termes d’optimisation de l’organisation et des revenus, soit un stratège ou un entrepreneur (ou les deux à la fois) avec une culture, même récente, de la data. Ce sera un dirigeant, et aura des émoluments en conséquences : la fourchette couramment citée est 150-200 k€.

Ainsi, le Chief Digital Officer pense la stratégie de la transformation numérique, son plan d’action et le promeut. Je verrais alors le Chief Data Officer comme la cheville ouvrière de la conduite du changement correspondante.

Où recruter ?

En ce qui concerne les formations par lesquelles pourraient passer les futurs Chief Data Officers, il ne semble pas encore y avoir de maturité au sein de l’enseignement supérieur français. Pêle-mêle, il y a en particulier le Master européen Datamining & Knowledge Management proposé par UPMC, Université de Lyon Lumière Lyon 2 et Polytech Nantes, le Master Degree in Multimedia and Data Management de Polytech Nantes, le Mastère Spécialisé Big Data : Gestion et Analyse des Données Massives de Télécom Paris Tech, le Mastère Spécialisé Big Data : analyse, management et valorisation responsable de l’ENSIMAG et de l’EMSI à Grenoble… Pour le type de fonctions occupées auparavant, il y a celles autour de la « data » – Datascientist, Master Data Manager, Data Protection Officer… Encore faut-il, dans ces cas, identifier la compétence métier et/ou business… A l’inverse, il est aussi possible de chercher parmi les postes au sein de directions métiers en lien avec le marché – des responsables commerciaux, marketing, innovation – et identifier la compétence data. Pour les ressources humaines, il s’agit d’un véritable challenge car le recrutement d’un tel « hybride » va au-delà des grilles classiques de recherche. Elles auront nécessairement besoin d’accompagnement…

Quant aux Chief Digital Officers, les « filières » naturelles sont celles où la transition numérique s’est déjà opérée, par exemple celles de l’informatique et des télécoms sans oublier le passage par une start-up. On trouve en particulier dans ces filières les éditeurs, les SSII, les intégrateurs et les opérateurs. Comme pour le Chief Data Officer, on peut aussi partir du métier et rechercher un profil qui a occupé des fonctions de direction dans la production, le commercial, le marketing ou l’innovation et qui est doté d’une très forte « appétence » pour le numérique. N’oublions pas que la cible est un visionnaire pragmatique du numérique.

Pour quel positionnement ?

Pour bien appréhender le positionnement possible de ces deux profils au sein de l’entreprise, c’est en fait une équipe complète qu’il faut considérer, intégrant des ressources propres et utilisant des ressources d’autres directions. Le patron de cette équipe est le Chief Digital Officer qui est un cadre dirigeant, rappelons-le, rattaché au Comité de Direction et nommé par la Direction Générale. Il y a donc du management hiérarchique dans sa fonction, mais aussi, et c’est essentiel, du management non hiérarchique, car il sera le relais de la transformation numérique auprès des métiers.

Il devra notamment travailler sur trois axes : l’axe technique, l’axe métier et l’axe diffusion. Le premier axe est en lien étroit avec la Direction du Système d’Information (DSI). De façon « naturelle », l’articulation entre la DSI et les directions métiers sera opérée par le Chief Data Officer qui, lui-même, en fonction de la taille de l’entreprise, s’appuiera sur une équipe de datascientists, de chefs de projet en décisionnel, de statisticiens et d’experts métiers amateurs de data. Pour l’axe métier, comme la transformation numérique commencera par la transformation des modes de travail et se poursuivra par la transformation organisationnelle, elle se fera en liaison avec les ressources humaines de l’entreprise et sera accompagnée par des spécialistes de la conduite du changement. L’axe diffusion vise la communication auprès des relais métiers et auprès de tous les salariés. Dans le premier cas, la communication est inter-personnelle : elle est du ressort direct du Chief Digital Officer. Dans le second cas, elle s’appuie sur la communication interne de l’entreprise et ses outils de marketing opérationnel. On voit bien que, pour monter une telle équipe, il vaut mieux éviter d’être seulement dans la réaction : il est nécessaire d’anticiper et de se préparer…

L’analyse qui vient d’être esquissée montre que s’interroger sur une mode actuelle, celle du CDO, Chief Data Officer ou Chief Digital Officer, revient à s’interroger sur la manière de gérer l’arrivée de la lame de fond de la transformation numérique, ici à travers la compréhension de ce que peuvent être ces deux profils et de ce à quoi ils peuvent servir dans ce contexte. En fait, c’est toute une stratégie que l’entreprise va devoir mettre en place qui va la modifier en profondeur, dans ses relations avec ses clients et dans son organisation. Une culture va remplacer une autre. Soit on « surfe » sur la mode et on fait comme les autres, on embauche son Chief Digital Officer dont on espère qu’il détiendra la vérité, soit on se prépare à la transformation numérique en y réfléchissant d’abord avec ceux qui la perçoivent déjà dans les directions métiers, au sein de la DSI, et avec l’aide éventuelle de conseils externes, et on imagine ensuite l’équipe, dont j’ai tenté la définition, et les moyens correspondants. Enfin, on recrute et on trouve les « pépites », avec un peu de chance…

Auteur : Michel GIRONDE