Ici archive

Nous remarquons qu’il n’existe aujourd’hui pas de solution clé en main pour piloter une mission d’adoption. Si l’on prend comme exemple les outils Microsoft 365, nous avons observé chez nos clients qu’il était compliqué de piloter une mission en analysant de près les usages, comme l’évolution de la communication chez les collaborateurs. Par exemple : l’envoi des emails diminue-t-il au profit de la collaboration sur Teams ?

Se pose alors la question : comment mieux mesurer l’engagement des collaborateurs pour l’utilisation des outils M365 et comment le faire vivre ?

Définir des indicateurs clés pour suivre les actions d’accompagnement sur le terrain

Nous sommes partis de deux constats. Tout d’abord, peu d’indicateurs clés sont aujourd’hui disponibles pour suivre les évolutions d’une mission. Microsoft propose un Dashboard figurant l’évolution et utilisation des outils Office 365, mais il contient beaucoup d’informations qui ne sont pas assez explicites pour nos clients ; granularité d’analyse pas assez fine, méthodes de calculs complexes et la donnée n’est rafraîchie qu’une fois par mois.

Au sein de nos missions, nous accompagnons les collaborateurs en suivant un plan d’adoption sur-mesure défini en accord avec les besoins et la culture de l’entreprise. Or pour en assurer la réussite, il est primordial de suivre les actions d’adoption de près (utilisateurs actifs, récurrents, département) et les actions menées (fréquence des accompagnements, sujets proposés, participants, taux de collaborateurs touchés par les accompagnements). Il était donc nécessaire de développer un outil pour faciliter cette tâche : le Dashboard d’adoption.

Dans le cadre d’une mission au dispositif complexe (24 sites différents en France et à l’étranger, plusieurs langues à traiter, plus de 16 000 collaborateurs), nous avons mis en place un Dashboard pour avoir une vision globale sur les accompagnements menés sur les outils M365 (coachings personnalisés pour prendre en main les options de réunion sur Teams, ateliers d’équipe pour mettre en place un flux automatisé pour des tâches à faible valeur ajoutée par exemple). Les équipes étant décentralisées, le Dashboard a pallié le manque de lien qu’il y avait entre le plan d’adoption établi et les actions sur le terrain. Plusieurs accompagnements avaient par exemple lieu en même temps sur des sites différents, menées par des personnes différentes. Il a donc fallu créer un cadre pour que la remontée d’informations par chaque intervenant soit faite de manière identique.

Nous avions maintenant des chiffres concrets à présenter (le nombre de participants aux accompagnements par site, pays et entité). Sur deux sites d’un même pays, nous avons constaté que l’un était très investi alors que l’autre moins : les chiffres étaient respectivement très élevés et très bas. En comprenant que d’un côté, une personne transmettait les communications aux collaborateurs du site, nous avons mis en place de l’autre les actions adaptées : contacter les relais, comprendre pourquoi les communications n’étaient pas relayées, trouver des solutions et adapter le programme à cette population. C’est le Dashboard qui nous a permis de mieux identifier les zones de risque, ainsi que les actions concrètes à mettre en place en face de résultats non concluants.

Écran d’accueil : vue globale de l’utilisation de Microsoft 365 sur le nombre d’utilisateurs actifs par application sur les 30 derniers jours

Faire vivre l’engagement fait pleinement partie du plan d’adoption. Le piloter de près permet de se rendre compte du niveau d’engagement à des moments clés. La mission précédemment citée a été menée en période de COVID : grâce à ce Dashboard de pilotage, nous avons pu identifier les zones de risque, être plus agiles et restructurer notre stratégie plus rapidement. Le dispositif initial devait avoir lieu en présentiel à 100% (chaque intervenant devait se rendre sur les sites pour accompagner les collaborateurs), mais le confinement nous a obligé à le revoir sur la base de nouveaux indicateurs. Une liste de personnes clé a été formée en priorité aux outils. Nous avons adapté le Dashboard pour suivre de près l’engagement de ces personnes. Avec du recul, nous avons aussi observé les limites des accompagnements à distance. Dès que les conditions sanitaires l’ont permis, nous avons accompagnés sur site les pays qui en avaient le plus besoin.

Forts de cette expérience sur le terrain, nos équipes EMEX et Data ont ensemble créé une solution clé en main visant à donner une vision globale sur l’engagement et utilisation des outils des collaborateurs ainsi que le pilotage des actions menées par les consultants sur le terrain. L’objectif : faciliter la prise de décision en cours de mission et mettre en lumière l’évolution des usages au sein de l’entreprise.

Vue générale de l’utilisation de Teams

L’outil : un Dashboard clé en main au service du client

L’objectif de ce nouvel outil est de répondre aux problématiques d’accompagnement mentionnées, mais aussi d’être une solution flexible. Le déploiement des outils de la suite Office 365 n’est pas toujours fait en une seule fois ; certains clients migrent progressivement leur architecture On-Premises vers le cloud. Cette phase de transition peut être monitorée avec des sources de données différentes (une source On-Premises et une source cloud) en adaptant l’outil à cet effet. Les outils à monitorer ne sont pas forcément tous sur Office (salles de réunions, installation des logiciels sur les postes de travail). Un produit agile est tout naturel dans un tel contexte.

Vue détaillée de l’utilisation des applications Microsoft 365

Cette solution clé en main comporte plusieurs avantages :

  • Le Dashboard clé en main s’adapte aux outils déjà existants dans l’entreprise, sur le principe des “composants sur étagère“. Le client peut choisir les outils qu’il souhaite monitorer ;
  • Un déploiement accéléré de la solution en entreprise grâce à des composants technologiques disponibles par exemple sur la plateforme Azure ;
  • Des choix technologiques variés selon le contexte de déploiement. Le client peut par exemple choisir d’utiliser une base de données déjà existante pour minimiser les coûts de fonctionnement liés à la création et maintenabilité du produit ;
  • La chaine de valeur de la donnée étant totalement maitrisée, il est tout à fait envisageable de se servir de ce produit comme un socle solide pour l’adoption, puis d’y ajouter des extensions pour des usages internes à l’entreprise ;
  • Le produit suit les évolutions des API Microsoft pour que ses indicateurs soient à jour ;
  • Le design visuel du rapport est adaptable aux besoins du client pour qu’il s’intègre au mieux à l’écosystème déjà en place.

Concernant la partie technique :

  • Stockage de données : PostgreSQL sur Azure. La solution est flexible et peu onéreuse ;
  • Extraction des données : nous utilisons l’API Graph de Microsoft ;
  • Langage : nous utilisons Python couplé à Azure Data Factory pour les traitements et Azure Blob Storage pour le stockage des fichiers ;
  • Accès aux données : nous utilisons un Service Principal qui nous donne la possibilité de ne pas attribuer de droits à un utilisateur en particulier ;
  • Visualisation : notre choix s’est naturellement tourné vers Power BI pour compléter cette suite Microsoft/Azure.

Dans ce contexte, l’avantage de Power Bi est qu’il est parfaitement intégré aux outils de la suite Office 365. Nous bénéficions ainsi à la fois de Metrics (visuels d’objectifs de Power BI) et des fonctionnalités d’intégration dans Teams. Les données vont à l’utilisateur – et non l’inverse. L’utilisateur peut par exemple intégrer des visuels dans PowerPoint pour présenter des chiffres clés (grâce à la dernière mise à jour Power BI).

Conclusion

Forts de notre expertise et nos expériences sur le terrain, nous sommes convaincus que ce Dashboard de pilotage clé en main permet à nos clients d’avancer avec une meilleure visibilité. C’est une vraie valeur ajoutée pour piloter plus précisément une mission, identifier des zones de risque plus rapidement et donc être plus agile pour se réorganiser et structurer. Ne l’oublions pas : il est plus simple pour les parties prenantes de se rendre compte de l’évolution des usages au sein de leur entreprise à l’appui d’éléments concrets et résultats clairs.

Vous souhaitez en savoir plus ou être accompagnés par nos équipes EMEX et Data ?

Rédigé par Pauline Zimon, Consultante Employee Experience, et Maxime Mauray, Consultant Data Driven

Le métavers est un réseau d’environnements graphiques virtuels en ligne, accessible grâce à des équipements de réalité virtuelle ou augmentée. Les utilisateurs sont plongés dans une expérience immersive au sein de laquelle ils ont la liberté d’être qui ils souhaitent et d’aller et de faire ce qu’ils veulent sans limite. Le film “Ready Player One” est un bon exemple pour illustrer le métavers – les personnages vivent dans l’Oasis, une société virtuelle accessible grâce aux mêmes technologies. La réalité a donc rattrapé la science-fiction : il est aujourd’hui possible de basculer dans ce monde parallèle…

L’intention de Mark Zuckerberg de transformer l’entreprise Facebook en un métavers est devenu un sujet incontournable pour les entrepreneurs, et plus particulièrement les acteurs du marketing. En effet, le monde virtuel offre des opportunités commerciales générant de la valeur : il est essentiel de s’y adapter rapidement ! L’exposition des marques et des produits dans le métavers est aujourd’hui la clé pour se positionner sur ce nouveau champ de bataille. Mais comment procéder ?

La publicité OOH virtuelle

L’espace de publicité est le modèle principal de sources de revenus du métavers (ex-Facebook, donc). Les designers et ingénieurs qui créent ces mondes virtuels travaillent ensemble pour permettre aux marketers et publicitaires de diffuser leurs annonces dans des espaces dédiés. À l’image des publicités out-of-home (OOH) que l’on retrouve sur les immeubles, les panneaux publicitaires ou dans les transports en commun, les annonces sont exposées sous des formats multiples non-contraints par les lois de la physique.

Les événements virtuels

En 2019, Marshmello réalisait pour la première fois un concert de musique électronique dans le jeu vidéo Fornite, rassemblant ainsi les joueurs autour d’une expérience musicale immersive. Ce concert a levé les contraintes logistiques et de capacité d’accueil pour laisser place à la créativité. Il a ouvert la porte à de nouvelles opportunités événementielles pour les marques comme l’organisation de défilés de mode, de premières de films ou d’évènements sportifs. Les possibilités sont infinies… sky is the limit !

Le placement de produit virtuel

Le métavers n’est pas qu’un lieu de jeu : il est possible d’y créer son avatar en lui donnant l’apparence et le style que l’on souhaite. Certaines marques de luxes comme Balenciaga et Gucci se sont déjà positionnées sur ce marché en intégrant leurs produits dans le monde virtuel : des boutiques offrent aux clients une nouvelle expérience, ayant pour objectif d’accroitre à terme les ventes dans la réalité.

L’avenir du placement de produit dans le métavers

Notre conviction est que les marques et organisations seront une partie intégrante du métavers dès lors que son usage sera mainstream. Ainsi, nous pouvons imaginer que les entreprises et marques loueront des espaces virtuels pour déployer leurs activités. Mercedes y lancera des véhicules virtuels, Starbucks offrira des espaces virtuels où se retrouver…

Saegus saisit l’opportunité de valoriser les données marketing du métavers pour augmenter les insights consommateur en fournissant un conseil en stratégie. Nos experts du data marketing vous accompagnent sur l’analyse des données du métavers (comportement utilisateur et médias digitaux), la mise en place de stratégie marketing dans le métavers et la réalisation de contenus créatifs digitaux. Le futur est déjà le présent : nous sommes prêts, et vous ?

Vous souhaitez en savoir plus ou être accompagnés par nos équipes Data ?

Rédigé par Tanasit Mahakittikun, Consultant Data

Maximiser l’efficience et l’efficacité opérationnelle dans un monde en constante évolution est un défi pour toutes les entreprises aujourd’hui, quel que soit leur secteur d’activité. Les challenges opérationnels sont de plus en plus nombreux et complexes : perturbation des chaînes d’approvisionnement, numérisation massive des modes de consommation, augmentation ininterrompue des exigences qualité et guerre concurrentielle pour offrir les meilleurs prix ne sont que quelques-uns d’entre eux. Dans ce contexte, les données de l’entreprise sont un asset qu’il n’est plus possible de ne pas exploiter et valoriser à sa juste valeur.

Martin Alteirac, Senior Manager en charge du secteur Industriel au sein de l’équipe Data Driven Business chez Saegus, répond à nos questions.

Comment les nouveaux usages de la data peuvent-ils contribuer à l’excellence opérationnelle ?

Avant d’être une démarche, l’excellence opérationnelle est un état d’esprit. Un des piliers de cet état d’esprit est à mon sens la faculté à objectiver les problèmes, à être pragmatique, à raisonner sur des faits et pas sur des idées préconçues ou des préjugés.

La data est donc un atout majeur dans la quête de cette excellence car elle permet de mettre en évidence de manière factuelle les points de faiblesses d’une organisation. Deux grands usages peuvent contribuer à l’excellence opérationnelle des entreprises :

  • L’analytics, par sa faculté à apporter à chaque collaborateur·rice une information personnalisée et actionnable et à faire rayonner dans l’entreprise une culture de la mesure de la performance ;
  • La data science, par sa capacité à optimiser et/ou automatiser certains processus métier complexes ou à aider à la conception de nouveaux produits ou services.

Le premier enjeu est d’identifier les fonctions d’une entreprise les plus à même de bénéficier de ces nouveaux usages de la data.

Quelles sont les fonctions de l’entreprises les plus propices au déploiement de ce type de démarche ?

Toutes les fonctions de l’entreprise peuvent bénéficier d’une démarche Data Driven Ops :

  • La production ou les opérations pour délivrer des produits ou services d’une qualité irréprochable tout en optimisant leur coût de production ;
  • La Supply Chain pour servir ses clients toujours plus vite en sollicitant le minimum de ressources ;
  • La maintenance pour garantir que les moyens de production soient les plus productifs possible ;
  • Le procurement où la transformation digitale permet d’acheter toujours mieux et au meilleur prix ;
  • Les ressources humaines pour booster l’efficacité des équipes ;
  • La recherche et le développement pour développer les produits et services de demain.

Bien évidemment l’intérêt de ces différentes fonctions dépend généralement du secteur d’activité concerné :

  • Le secteur du manufacturing sera intéressé par les cas d’usages autour de la valorisation des données issues des équipements ou des systèmes d’information liés à la production : optimisation des rendements, qualité ou maintenance prédictive, optimisation de la planification… ;
  • Le secteur de la distribution B2B ou B2C sera friand de cas d’usages autour de la supply chain, du procurement ou du pricing ;
  • Enfin le secteur énergétique sera concerné par la récupération et l’exploitation de données physiques mesurées par des capteurs posés au niveau des équipements de production et de consommation d’énergie pour prévoir la demande ou la production en temps réel.

D’autres cas d’usages existent (gestion des ressources humaines, des achats) ; chaque entreprise pourra également imaginer des cas d’usages spécifiques sur les problématiques qui lui sont propres. C’est souvent le cas lorsqu’on touche à des sujets de R&D ou d’innovation ayant pour objectif le développement de produits ou services visant à développer son activité.

Comment mettre en place une démarche Data Driven Ops ?

Les données de l’entreprise sont une mine d’or mais, comme pour l’or, les obstacles à franchir sont nombreux pour passer de leur découverte à leur valorisation.

Pour qu’une démarche Data Driven aboutisse il faut donc fédérer des acteurs à même d’apporter les expertises nécessaires :

  • Une expertise métier pour s’assurer que la démarche soit menée par la recherche de valeur ajoutée concrète, qu’elle soit technique, économique ou opérationnelle ;
  • Une expertise technique qui permette de sélectionner les bons outils et les bonnes technologies à mettre au service des métiers ;
  • Une expertise méthodologique sans laquelle les chances de voir la démarche aboutir s’amenuisent à cause des freins techniques, organisationnels ou culturels que ce type de démarche rencontrera à un moment ou à un autre.

Qu’est-ce qui fait de Saegus un partenaire de choix pour ce type de projet ?

Saegus est capable d’apporter à ses clients l’expertise et les ressources nécessaires pour initier, conduire et pérenniser une démarche Data Driven. D’une part, les directeurs et managers du cabinet ont conduit de vastes programmes de transformation au sein des plus grandes entreprises françaises ; d’autre part, ses consultant·e·s possèdent les expertises sectorielles, fonctionnelles et technologiques requises et sont continuellement formé·e·s aux nouvelles technologies et solutions du marché.

Mais plus que tout, nos équipes placent les utilisateurs et les usages au centre de la démarche Data Driven. Cela garantit la meilleure adéquation possible entre les choix technologiques et les besoins de l’entreprise et surtout l’adoption la plus large et durable possible des outils développés.

J’aurai l’occasion de vous parler de nos cas d’usages les plus emblématiques dans de futurs articles. Stay tuned !

Envie d’en savoir plus ou d’être accompagné·e·s par nos équipes Data ?

La business intelligence est aujourd’hui “drivée” par plusieurs éditeurs de logiciels – les principaux étant Microsoft avec Power BI, Tableau et Domo :

Ces outils fournissent des tableaux de bord opérationnels sur différents domaines à plusieurs niveaux hiérarchiques pouvant aller jusqu’au CODIR. Conscients des enjeux de cyber sécurité qu’implique ce type de projets, les architectes groupes réfléchissent aux solutions les plus adaptées.

Comment ces outils fonctionnent-ils ? Concrètement, dans une première démarche, un outil de BI stocke la donnée collectée dans ses propres bases de données dont le client ne peut souvent pas choisir le fournisseur et la localisation. Par exemple, un Power BI récupère de la donnée dans une base de données client chez Google Cloud et la stocke dans sa base de données Azure.

C’est ainsi que la plupart des outils de BI proposent à présent au moins deux modes de connexion : l’Import Query et le Direct Query.

Plusieurs défis se posent alors :

  • Est-ce un problème que ma donnée soit stockée dans deux bases de données différentes ? On pense par exemple à une donnée très sensible telle que la donnée financière ;
  • Les connecteurs Live Query sont-ils assez robustes pour interroger un très gros volume de données ?
  • Quels sont les coûts engendrés par le choix de l’architecture ?

Définition : Import Query et Direct Query

Tout d’abord, quelle est la différence entre ces deux notions, qui peuvent varier selon les outils de BI ?

Import Query : le fait de collecter la donnée stockée dans une database dédiée et qui appartient à l’outil de BI.

Direct Query : le fait de lire de la donnée en direct dans la database source sans la stocker ailleurs.

Import Query

La majorité des outils de BI propose ce mode de collecte de la donnée et ce, pour plusieurs raisons.

Mindset

Cela crée de la valeur pour l’outil en question. Évidemment, l’outil de BI garantit la sécurité de la donnée collectée (elle ne la diffusera ou ne la vendra pas), mais elle possède bien une donnée qui ne lui appartient pas et qui est importante aux yeux d’une entreprise. Cette dernière aura donc tendance à se fidéliser auprès de cet éditeur.

Bénéfices pour l’utilisateur

Une fois que la donnée est stockée, l’outil de BI propose aux éditeurs qui la traitent d’y apporter des transformations, comme des jointures avec d’autres bases de données. Il s’agit ici de transformer la donnée brute en une donnée qui répond parfaitement aux besoins de la visualisation dans un tableau de bord.

En matière de performance, la donnée étant stockée chez l’éditeur, les requêtes permettant d’afficher les visualisations lors d’un changement de page seront plus rapides.

Coût

Enfin, un dernier aspect non négligeable, le coût du tableau de bord. Généralement, lorsque vous souscrivez à un outil de BI, vous payez une licence qui vous donne le droit à un certain volume de stockage. Power BI est par exemple gratuit jusqu’à 1 go par jeu de données. Il faut passer sur une licence premium pour augmenter ce volume de stockage à 10 go ou plus. Vous payez donc un volume maximum.

Ainsi, vos frais relatifs à la donnée s’arrêtent là (exceptés donc les autres coûts liés par exemple aux accès utilisateurs). Peu importe le nombre de fois qu’un utilisateur requête une visualisation, votre coût sera fixe. À noter que l’entreprise paiera donc deux fois le stockage de sa donnée, une fois via l’outil de BI et une fois via le serveur où est stockée sa donnée source.

Direct Query

Une entreprise souhaitant stocker sa donnée à un seul endroit n’aura donc pas d’autre choix que d’utiliser ce mode de collecte. Le Direct Query est moins avantageux pour un éditeur d’outils de BI car il perd les points expliqués ci-dessus.

Mindset

La seule valeur ajoutée de l’outil de BI devient la visualisation.

Bénéfices pour l’utilisateur

  • Afficher la donnée la plus fraîche provenant de la base de données ;
  • Un seul point de stockage de la donnée (préférable si la donnée est sensible).

Inconvénients pour l’utilisateur

  • Avec le Direct Query, la majorité des outils de BI ne proposent plus la possibilité de faire des transformations. La donnée devra donc être traitée avant d’être collectée par l’outil de BI dans un BigQuery ou un Snowflake par exemple ;
  • La performance sera impactée en fonction du temps de réponse entre le serveur source et l’outil de BI, qui sera généralement plus long que la méthode Import. Sur un très gros volume de données, le temps d’affichage des visualisations sera trop long et deviendra un frein à l’adoption et la navigation.

Coût

En matière de coût, l’éditeur de l’outil de BI est le grand perdant. Le grand gagnant est en fait le fournisseur de base de données qui contient la donnée source. Par exemple, GCP facture à la requête, même dans un data studio qui appartient à Google, chaque nouvelle requête sur ce tableau de bord engendre des coûts d’utilisation au client. Plus la volumétrie est importante, plus les coûts le seront. Une architecture mal optimisée au sein de GCP sera vraiment coûteuse au quotidien, comme un Direct Query sur une vue classique faisant la jointure entre deux tables très volumineuses. Il sera important de porter une attention particulière à la performance et au nombre de requêtes effectuées. C’est le prix à payer pour avoir la main totale sur sa donnée et être maître de sa localisation.

Bonus : Hybrid Query

Chez certains éditeurs, notamment Power BI, il existe un troisième type nommé “Hybride”. Ce mode combine les modes import Query et Direct Query au sein d’une même table.

Concrètement, vous pouvez cibler une partie de votre table pour qu’elle vous renvoie la donnée en live query – comme les données du mois précédent, tandis que la donnée antérieure à ce mois sera récupérée via l’import Query.

Bénéfice pour l’utilisateur

Dans le cas où l’utilisateur requête une base de données avec une très grosse volumétrie, cela améliorera le temps d’affichage de son tableau de bord en lisant la plus grosse partie de la base (la donnée historique par exemple) via l’Import Query. Il pourra tout de même avoir de la donnée en temps réel (la donnée la plus fraîche par exemple) via le Direct Query sur une partie ciblée de la base de données.

Conclusion

La sensibilité de la donnée et le coût à terme sont deux points essentiels à considérer pour choisir une approche adaptée afin d’ingérer de la donnée dans des outils de BI pour réaliser un tableau de bord.

D’un point de vue relatif à la sécurité, une entreprise n’a pas intérêt à stocker sa donnée dans plusieurs base de données.

Cependant, un connecteur Direct Query n’est pas assez robuste sur des très gros volumes de données : nous l’avons vu, le temps de chargement sur une page sera un frein à la navigation sur le tableau de bord. En revanche, il est très efficace sur des petits volumes de données, si les tables alimentant les visualisations ont été factorisées en amont au sein de l’entrepôt de données. Il pourra également répondre au besoin d’afficher de la donnée en temps réel.

À ce jour, la solution la plus pertinente, notamment pour de gros volumes de données, est de choisir un même fournisseur pour stocker et lire la donnée. Par exemple, un Power BI ingérant de la donnée en Import Query depuis Azure la stocke également dans Azure – si le serveur est différent, il s’agit bien du même fournisseur.

Pour résumer :

Vous souhaitez en savoir plus ou être accompagné·e·s par nos équipes Data ?

Rédigé par Maxime Rousseau, Consultant Senior Data

Sources
(1) https://www.qlik.com/fr-fr/gartner-magic-quadrant-business-intelligence

Depuis ces dernières années, les solutions low-code se multiplient : accessible à un plus large nombre de personnes appelées “citizen developers”, le low-code atténue la barrière entre IT et métiers.

Qu’est-ce que le low-code ?

Le low-code est un environnement qui permet de développer des applications avec peu de code, contrairement au développement traditionnel. Les solutions low-code mettent ainsi en avant une interface graphique user-friendly souvent accompagnée de modèles prédéfinis pour accélérer et faciliter les développements. On estime que les lignes “low-code” représentent 20% du nombre moyen de celles créées dans les process classiques de développement.

Il est souvent fait mention de “no-code”. Il s’agit ni plus ni moins d’une sous branche du low-code qui pousse le concept jusqu’au point où coder n’est plus nécessaire pour développer.

Le contexte

Ces dernières années ont été marquées par l’accélération de la transformation numérique au sein des entreprises, renforcée et précipitée par la pandémie du Covid-19. Face à cette situation, les Directions des Systèmes d’information (DSI) ont vu une augmentation des demandes et des besoins qu’elle n’arrive souvent pas à prendre en charge face à la multiplication des projets et du fait de ressources financières et humaines limitées. La pénurie de développeurs sur le marché renforce d’autant plus ce constat.

La mise en place de solutions low-code a été l’une des réponses à cette situation.

Parce qu’ils requièrent moins de compétences techniques, ces outils permettent aux utilisateurs métiers de gagner en indépendance en créant rapidement leurs propres applications (interface de saisie, requêtes métiers, rapports de pilotage simple…). Un nouveau profil a alors émergé dans les entreprises, le “citizen developer” : généralement un profil métier avec une forte appétence pour le digital qui devient le pont entre la DSI, les solutions low-code et les équipes métiers.

Le citizen developer facilite ainsi la création d’applications au plus proche des besoins métiers. De ce fait, le time to market se voit réduit. Mendix, un des acteurs clés du marché low-code, considère que le temps de développement est divisé par deux ou plus par rapport à un développement traditionnel. À noter que la mise en place de ces solutions est accompagnée par les DSI dont le rôle évolue, devenant de véritables partenaires des métiers.

Le marché du low-code

D’après une étude réalisée par Forrester, cabinet d’étude et de conseil, le marché des solutions low-code est estimé à 21,2 milliards de dollars en 2022, contre 3,8 milliards de dollars en 2017.

Gartner, société américaine de conseil et recherche, prédit quant à elle que le low-code représentera 65 % des applications développées en 2024. La société a également publié en août 2021 un magic quadrant positionnant les différents acteurs du low-code actuels selon 4 axes : les challengers, les leaders, les solutions de niches et les visionnaires.

Parmi les leaders du low-code, on remarque Mendix, ServiceNow, Salesforce ou encore Microsoft, dont l’offre Power Platform propose 4 solutions low-code complètes :

  • Power Apps : transformez vos idées en solutions professionnelles, en permettant à chacun de créer des applications personnalisées destinées à relever les défis de l’entreprise ;
  • Power BI : prenez des décisions professionnelles fiables et avisées en fournissant à chacun des informations exploitables fondées sur des données ;
  • Power Automate : dopez la productivité et l’efficacité de votre entreprise en donnant à chacun les moyens d’automatiser les processus organisationnels ;
  • Power Agent : créez facilement des chatbots pour converser avec vos clients et vos employés, sans aucun codage requis.

Le low-code a donc un bel avenir devant lui avec des acteurs et des offres en plein essor !

Plus que de révolutionner le développement, c’est une invitation à réfléchir aux rôles et interactions des différents services dans les organisations et aux avantages concurrentiels qu’ils peuvent procurer.

L’enjeu est de déterminer la bonne solution et les cas d’usages avec une gouvernance associée, permettant ainsi de rassurer aussi bien les métiers que l’IT et offrir ainsi une alternative au shadow IT.

Vous souhaitez en savoir plus ou être accompagné·e·s par nos équipes Data ?

Rédigé par Claudio Anfuso, Consultant Senior Data

Le déploiement de la gouvernance des données est indispensable pour assurer une transformation vers des modèles davantage centrés sur la donnée.

Si les organisations ont pris conscience de cet enjeu, nous constatons qu’elles font face à de grands challenges lorsqu’il s’agit de déployer la gouvernance de la donnée : une forte disparité des niveaux de maturité dans l’entreprise, des difficultés à identifier les cas d’usages prioritaires, à démontrer de la valeur à court terme et à maintenir la démarche dans le temps, une faible disponibilité des parties prenantes…

Comment vous est venue l’idée d’introduire l’agilité à la gouvernance de la donnée ?

Chez Saegus, nous avons dans notre ADN de centrer nos projets sur une vision axée sur l’usage et la valeur. Ce besoin se fait davantage ressentir lorsque l’on parle de data gouvernance, où les résultats ne sont pas toujours identifiés par tous ni partagés en amont lors des phases de déploiement.

Un des enjeux majeurs des initiatives de gouvernance de la donnée réside donc dans la capacité à montrer rapidement un retour sur investissement et à illustrer les premiers résultats de manière concrète. Cette preuve de valeur permet de communiquer les premiers résultats à travers l’organisation rapidement, tout en les inscrivant dans une démarche globale.

C’est dans ce contexte que nous avons fait progressivement évoluer notre approche vers une méthodologie reposant sur les concepts de l’agilité. L’objectif ? Offrir à nos clients des résultats rapides et cohérents garantis par une forte implication des utilisateurs. De plus, la mise en place d’un framework agile permet de faire face et de s’adapter aux évolutions structurelles et organisationnelles inhérentes au déploiement d’une gouvernance de la donnée à l’échelle de l’organisation.

Comment mettez-vous en place ce genre d’approche chez vos clients ?

Mettre en place un projet de gouvernance en se positionnant sur l’ensemble des axes organisation, processus et outils nécessite un effort initial considérable de l’ensemble des parties prenantes. En conséquence, les résultats tardent souvent à apparaître. Il est donc nécessaire d’impliquer les utilisateurs métiers en leur offrant des résultats concrets. La création d’un catalogue de données est un bon levier pour générer cet engagement.

Maitriser son patrimoine de données, c’est d’abord le connaitre. Pour construire un catalogue centré sur l’usage et la valeur, il est indispensable d’identifier et prioriser les cas d’usages à fort impact, ayant un retour sur investissement démontrable. Cette démarche s’oppose aux approches par fonctions, entités ou zones géographiques. La volumétrie d’information rend leur mise en place longue, et les bénéfices qu’elles génèrent sont souvent difficilement mesurables. La démarche de gouvernance de la donnée ne doit pas être calquée sur l’organigramme mais sur la valeur. Pour atteindre ce résultat, Il est indispensable de collaborer avec les métiers. Ce sont eux qui disposent de la connaissance de leur périmètre et qui ont donc la capacité de structurer la donnée avec le plus de valeur ajoutée.

Nous avons constaté que la capitalisation de cette connaissance est difficile et souvent chronophage, nécessitant de longues sessions d’ateliers. En conséquence, nous apportons un support significatif dans la consolidation du catalogue de données pour minimiser l’effort des métiers, tout en maximisant la valeur apportée au travail de cartographie.

Quels sont les bénéfices d’une telle démarche ?

Pour optimiser l’exercice de cartographie des données, nous avons mis en place une approche de travail agile fonctionnant par courtes itérations. Celles-ci permettent aux métiers de décrire de petits périmètres de données préalablement identifiés, puis modélisés dans l’outil de data cataloging.

Les longues sessions de travail en réunion ont ainsi laissé place à des points de partage fréquents, mais courts, qui garantissent l’alignement des acteurs sur la méthodologie. Elles génèrent également des échanges sur les points de divergence, permettent la validation en continu des informations du glossaire de termes métiers et assurent l’application des standards établis à l’échelle du groupe.

L’objectif de cette approche est d’implémenter l’information en quasi-temps réel dans le catalogue de données pour permettre à chacun de la visualiser et d’y accéder dès les premiers résultats.

Une telle approche présente un second bénéfice majeur : elle fait monter en maturité et en compétence les équipes métiers sur les sujets data. Une étape indispensable pour commencer à déployer une culture data dans l’organisation et pour préparer les acteurs de demain à leur futur rôle dans l’organisation (data owner, data steward, data custodian…).

Comment cette approche permet-elle d’adresser l’ensemble des composantes de la gouvernance de la donnée ?

Les travaux de cartographie permettent l’identification des référents métiers et IT et leur montée en compétence avant la formalisation de leur rôle dans l’organisation data de l’entreprise.

Cette phase amont permet l’identification des référents métiers avant la formalisation de leur rôle et également d’auditer l’architecture data sur différents axes (fiabilité, sécurité, accès). Un plan de progrès peut alors être établi avec une liste de projets associés.

Enfin, le déploiement d’initiatives localisées de cartographie de données étend le tissu de la gouvernance dans l’organisation, par et pour les métiers pour couvrir l’ensemble des périmètres prioritaires en accord avec l’ambition stratégique data de l’entreprise.

Grâce à notre savoir-faire et nos partenaires privilégiés, notre équipe Data Driven Business est en mesure de proposer des démarches de gouvernance de l’information tant organisationnelles qu’opérationnelles.

Retrouvez le replay notre table ronde exceptionnelle sur l’introduction de l’Agilité dans les processus de Data Gouvernance : https://bit.ly/3HzEvz9

Vous souhaitez être accompagnés par nos équipes Data ? Contactez-nous !

Rédigé par Marc Gabet, Consultant Data

Ces dernières années, de nombreuses entreprises ont décidé de mieux utiliser leurs données pour en faire un véritable atout concurrentiel. Cette culture Data Driven doit favoriser la maîtrise des cycles de décisions, de production, et d’approvisionnement, permettant la conception de produits plus en phase avec les attentes du marché…

Ce constat fait, plusieurs défis restent à relever :

  • L’identification et l’organisation des données ;
  • La captation de nouvelles sources ;
  • La priorisation des cas d’usage ;
  • Les choix de solutions, ou modernisation des socles existants ;
  • La création d’assets ou accélérateurs technologiques ;
  • La conformité règlementaire ;
  • La diffusion d’une culture « Data Driven » et la bonne utilisation des solutions mises à disposition.

Cette liste est non exhaustive, mais donne une indication d’un nombre conséquent de chantiers sensibles à mettre en œuvre.

À cela s’ajoute les particularités liées au niveau de maturité (des entreprises ou services) et au modèle d’organisation. Sans rentrer dans l’ensemble des cas, nous pouvons distinguer 2 typologies bien distinctes :

  • Les organisations centralisées, dont les fonctions IT ont la plupart du temps pour mission de gérer la donnée, de recueillir les besoins des directions métiers et d’offrir des « services » d’accès à l’information ; 
  • Les organisations décentralisées, dont les filiales ont plus d’autonomie et pour lesquelles les fonctions corporate ont un pouvoir de recommandation et de négociation face aux tierces parties, ainsi qu’un pouvoir de diffusion de bonnes pratiques.

Ce dernier cas est particulièrement intéressant en termes d’adoption car les filiales ont « le choix » : de fait, les techniques et bonnes pratiques utilisées dans ce contexte sont applicables à tout type d’organisation.

Diffuser une culture Data Driven

Notre conviction profonde est que plus la personne est proche du métier, plus elle sera efficace pour formaliser des indicateurs pertinents, manipuler l’information et itérer rapidement sur des analyses fonctionnelles. 

Encore faut-il lui donner les solutions, les bonnes pratiques, un accès à l’information simple et, si possible, des accélérateurs ou templates. 

Le message « Faites reposer vos décisions sur la data » reste souvent obscur pour les utilisateurs : comment puis-je accéder à la donnée ? Comment puis-je la retravailler ? Qu’est-ce qui de mon périmètre de responsabilité ou de celui de mon service IT ? 

Diffuser une culture Data Driven avec succès nécessite d’accomplir quelques devoirs :

  • La communication : diffuser des messages clairs expliquant la volonté et la stratégie de l’entreprise en termes d’accès à l’information ;
  • L’acculturation : sous forme de Data Literacy, de sessions de formation, de démonstrateurs, de showroom… permettant de faire découvrir l’étendu du possible et de diffuser un langage commun dans l’entreprise. Par exemple : qu’est-ce qu’un cycle de vie de la donnée, comment définir la data quality, proposer des ateliers de modélisation… ;
  • La présentation du « patrimoine » : elle peut se faire sous forme de cartographie des données accessibles par domaine métier, processus ou cas d’usage. Le but est de faire prendre conscience de la matière disponible et accessible, sinon d’identifier les manques et sources potentielles ;
  • Le coaching, ou la diffusion de bonne pratiques ou d’assets prêts à l’emploi : capitaliser sur les réussites, partager des retours d’expériences, des blocs techniques ;
  • Un processus de collaboration et d’échange : sous forme de communauté d’expertise/business ou de relais locaux pour les entreprises étendues ;
  • Un processus de gouvernance efficace : cela permettra de contrôler les assets partagés, de s’assurer de la bonne application des guidelines et d’identifier par la suite les réussites.

L’ordre d’application de ces « devoirs » peut être revu en fonction de la maturité des entreprises.

Quelle cible atteindre demain ?

L’objectif pour les directions business est de « libérer le potentiel des utilisateurs ».  Cette nouvelle catégorie d’utilisateurs, « éclairés » sur l’usage de la donnée, sont des « Business Scientist » ou « Business Analyst ». Il est alors nécessaire que chaque direction dispose d’un nombre suffisant de ces Data Leaders/Data Champions.

L’objectif pour les directions IT/Data est en effet de créer et d’offrir des services adaptés au cadre définit précédemment.

Ce bouquet de services peut être à géométrie variable en fonction des entreprises, mais l’on retrouve généralement :

  • Des services de stockages (cloud, solution de bases de données) ;
  • Des services d’extraction des données brutes et/ou de mise en qualité ;
  • Des services de transformation/préparation des data set (plus ou moins aboutis en fonction de l’autonomisation des utilisateurs) ;
  • Des services de monitoring et d’industrialisation des pipelines ;
  • Des services de gestion de référentiel ;
  • Des assets techniques (librairies d’algorithmes, d’api…).

Comment s’appuyer sur les instances de type « Data Factory/Data Lab » ?

Depuis plusieurs années, on assiste à une recrudescence de services : Data Factory, Data Lab, Data Foundry… Mais des questions reviennent souvent : faut-il scinder ces activités ? Si oui, comment les coordonner de manière efficace et agile ? Lesquelles dépendent de l’IT et du métier ? Lesquelles sont des entités autonomes ? 

Là encore, il n’existe pas de réponse absolue – il faut adapter la définition en fonction de la maturité des organisations. 

Par exemple, une organisation centralisée aura tendance à positionner la Factory sur les activités de Data Engineering et d’industrialisation, en gouvernant un ou plusieurs Data Lake/Data Store. Le Data Lab est dans ce cas souvent centralisé : les Domain Owners, en charge de la préparation des données et de leur valorisation, sont ici spécialisés par fonction Business. C’est dans cette structure que l’on retrouve les Data Scientists. 

Au contraire, une organisation décentralisée aura tendance à simplement fournir les outils et les assets, mais à reporter les processus d’engineering et d’analyses dans ses filiales ou divisions. Suivant leur taille, ces structures peuvent scinder leurs activités de Factory et de Lab, ou à l’inverse les regrouper dans une même instance. 

Proposer un modèle de capitalisation et de partage efficace

Pour que le système soit durable, il est indispensable de définir un processus de gouvernance partagé. Ce processus, lien entre les différentes parties prenantes, est l’un des moyens les plus sûrs d’atteindre un ROI rapide. Plus un asset ou un service sera partagé et réutilisé, plus son coût de création sera amorti et donc, la valeur dégagée élevée.

Repenser l’accès

L’accès à ces assets/informations doit lui aussi être repensé. Le contenu doit être adapté au profil de l’utilisateur (information, news, habilitation sur le contenu), puis mis à jour régulièrement avec des nouveautés afin de susciter un engagement croissant des utilisateurs.

Passer à l’action !

Comme souvent sur les projets de transformation, nous conseillons d’avancer par itération. Il est inutile d’avoir finalisé l’ensemble des éléments pour se lancer. 

Il est par contre indispensable d’avoir cadré la démarche, établi une vision claire de la trajectoire et de préparé une communication adaptée. La richesse de contenu sera ainsi auto-alimentée par la communauté adhérant au processus. 

Enfin, il faut surtout rester agile. L’équipe supervisant ce process « Data Driven » doit adopter une posture d’équipe produit : écouter les feedbacks et savoir pivoter si nécessaire selon son marché interne, en fonction du succès de l’adoption, de l’élévation de la maturité et de la prise d’autonomie.

Pour en savoir plus…

Notre équipe Data se tient à votre disposition pour partager ses retours d’expérience et vous aider à cadrer et développer votre modèle Data Driven.

Rédigé par Frédéric Brajon, Associé Co-fondateur de Saegus et Directeur du département Data

La difficile valorisation des projets de MLOps

Dans un monde numérique bouleversé par une digitalisation généralisée, les entreprises font de plus en plus appel aux nouvelles technologies afin d’augmenter leur efficacité. Les Nouvelles Technologies d’Information et de Communication (NTIC) s’intègrent progressivement depuis les années 70 avec, par exemple, l’apparition des micro-ordinateurs, puis plus fortement à la fin du XXe siècle avec l’utilisation d’internet et des courriers électroniques. Plus récemment, les entreprises profitent d’outils ERP (Enterprise Ressource Planning) pour faciliter leur gestion, ou encore s’appuient sur des objets connectés pour suivre, harmoniser et automatiser leurs activités.

Ces nouveautés génèrent de très nombreuses données devenant ainsi le nouvel or noir du numérique. Les entreprises ont à leur disposition de nombreuses solutions permettant de les valoriser : « modern Datawarehouse », Business Intelligence, Data Viz, etc. Les domaines d’applications sont nombreux et touchent tous les secteurs. En particulier, sur la base de ces données, il devient ainsi possible de mettre en place des analyses descriptives, diagnostiques, prédictives, voire prescriptives. Ce type d’approche mobilise très souvent des solutions basées sur le Machine Learning qui a suscité un fort engouement ces dernières années.

En effet, selon une étude de NewVantage Partners, on observe que 55% des 65 entreprises de FORTUNE 1000 ont investi en 2019 au moins 50 millions de dollars dans des projets Big Data et IA. Cependant, aux vues des investissements des entreprises dans ce domaine, il est inacceptable de constater que – selon Gartner – jusqu’en 2020 seulement 13% des projets de Machine Learning ont été industrialisés.

Pour expliquer ce paradoxe, Saegus a étudié les nombreux freins à l’épanouissement de la Science des Données dans les organisations : la délicate gestion des Data Scientists, un usage sous-optimal des ressources (outils, données et humaines), des enjeux culturels ralentissant l’adoption de la culture Data par toutes les parties prenantes, etc. Tous ces facteurs contribuent à la dégradation de la rentabilité des initiatives en Sciences des Données (voir notre article correspondant). Parmi ces freins, l’opérationnalisation des modèles constitue une difficulté majeure. Autrement dit, le grand enjeu que rencontre cette discipline est la mise en production des solutions de ML et tout ce que cela implique. Par analogie, cet enjeu est comparable à ceux de la culture DevOps qui est présentée plus en détail dans la suite de l’article.

Zoom sur le DevOps

Les problèmes de l’ancien modèle

Comme décrit dans la précédente section, depuis l’émergence de l’informatique, les entreprises s’appuient massivement sur les outils et les services liés au numérique, secteur en perpétuelle évolution. Le déploiement de ces derniers est complexe, voire problématique et nécessite une méthodologie élaborée. Par exemple, en génie logiciel, 66% des projets dépassent le budget et un tiers des projets ne tiennent pas les délais selon une étude de McKinsey & Oxford. Avant l’apparition du DevOps, comme nous pouvons le voir sur le schéma ci-dessous, deux équipes indépendantes intervenaient lors de la création de nouveaux produits digitaux. Une équipe de développement se chargeait de collecter les besoins métiers et de développer le produit, puis de tester le bon fonctionnement de celui-ci. S’il était conforme aux attentes, une autre équipe « opérationnelle » prenait le relais et assurait son exploitation dans un environnement de production.

Cette approche pose de nombreux problèmes. Tout d’abord, la présence de deux équipes a divisé les responsabilités et a créé des objectifs antagonistes. L’équipe de développement a pour objectif de modifier et faire évoluer l’application le plus rapidement pour suivre les exigences et les besoins des utilisateurs. Elle corrige les bugs, et ajoute de nouvelles fonctionnalités – parfois dans un délai court, tentant de minimiser les coûts et en n’attachant pas toujours une priorité maximale à la qualité. L’équipe des opérationnels assure le maintien de l’application et garantie sa stabilité et sa qualité. Pour cela, elle utilisera plus de temps et augmentera le coût nécessaire pour le déploiement d’une nouvelle version. Cette dissonance de priorité et d’objectifs peut entraîner des blocages et des allers-retours entre les deux équipes, ayant des conséquences néfastes sur le projet.

De plus, il arrive qu’il y ait peu de communications continues entre les deux équipes sur les problèmes rencontrés et les besoins changeants. Pour être performante, l’entreprise doit déployer sa solution le plus rapidement possible. Celle-ci présentera par la suite de nombreuses mises à jour permettant de corriger les bugs et d’améliorer le contenu. Le manque de communication pénalise le rythme de développement et d’exploitation de tels projets, rendant la surveillance et le déploiement des applications ardus, alimentant ainsi le risque de blocages.

Pour résoudre les dysfonctionnements de cette approche, la méthodologie du « DevOps » est apparue en 2007, imaginée par Patrick Debois.

Qu’est-ce que le DevOps ?

Le DevOps est avant tout une philosophie qui permet aux entreprises d’évoluer vers une approche dynamique orientée client pour le développement et la livraison de leurs applications, complétée par un contrôle de la qualité de la production irréprochable. Ainsi, les nouvelles évolutions sont intégrées et déployées continument et itérativement sur tout le cycle de vie du projet. La conception et la gestion du cadre d’opération des solutions sont traitées tout au long du projet, des prémices lors de la phase de cadrage jusqu’à la surveillance post-production. Cette méthodologie permet à l’entreprise de gagner en agilité et d’accélérer le « Time to Market » des produits. Pour cela, elle combine les compétences entre les équipes de « développement » et « opérationnelles » autrefois séparées, qui suivront des principes communs :

  • Culture : améliorer les attitudes de l’entreprise au service du développement
  • Automatisation : automatiser le plus possible les différentes procédures
  • Lean : optimiser l’utilisation des ressources afin de diminuer les coûts
  • Mesure : localiser rapidement les erreurs, analyser le comportement des utilisateurs en mettant en place des remontées d’informations efficaces
  • Testing : mise en place de nombreux tests (unitaires, fonctionnels, d’intégration) garantissant le bon déroulement des développements itératifs
  • Partage : mieux communiquer entre les équipes sur les problèmes et les améliorations possibles de l’application

Les composantes du DevOps sont présentées dans le schéma ci-dessous. Les deux équipes « Dev » et « Ops » sont imbriquées et partagent un même cycle sur lequel les différents segments du DevOps se suivent chronologiquement. Sa représentation, sous la forme du symbole de l’infini, témoigne d’une logique d’itération dans le temps : à la fin d’un cycle, un autre redémarre.

Grâce à l’automatisation des tâches, le DevOps fluidifie et accélère les interactions entre les parties prenantes du projet, ce qui supprime les temps morts. Le déploiement continu associé à l’automatisation des tests accélèrent le développement. Ces gains de temps provoquent mécaniquement une réduction des coûts et accélèrent la mise à disposition de l’application.

Un métier pluridisciplinaire a émergé de cette philosophie : l’ingénieur DevOps. Tout d’abord, il doit posséder des compétences techniques de développement et d’exploitation de logiciel. Il présente également une expertise sur de nombreux outils spécifiques au DevOps.  Il doit également faire preuve de compétences « humaines » : il sait prendre du recul pour comprendre le point de vue des autres, et en faire la synthèse afin de mener à bien le projet.

Généralisation de la culture “Ops”

De nouveaux besoins

Ainsi, cette culture Ops s’est développée en réponse aux besoins rencontrés lors du développement logiciel et d’applications. De nos jours, ces solutions sont souvent constituées de nouveaux types de composants leur permettant d’être plus modulables, sécurisées, innovantes et intelligentes (cloud, ML, grande quantité de données, …). Or, l’intégration de ces nouvelles technologies dans les applications a augmenté les risques pour le bon déroulement des projets. Bien souvent, ce type de produits nécessite l’intervention de nouveaux métiers – Data Scientist / Data Engineer / Data Analyst… Cela ravive les difficultés rencontrées par le passé dans la gestion du cycle de vie des projets. C’est particulièrement le cas lors de l’accompagnement d’un produit d’une phase de développement à une phase de production, a fortiori étant donnée cette nouvelle diversité fonctionnelle de parties prenantes.

Les insuffisances du DevOps au service de la Data et du Machine Learning

L’intégration de modèles d’intelligence artificielle et plus particulièrement de Machine Learning dans des applications a soulevé de nouveaux enjeux. La philosophie DevOps a essayé de s’adapter pour pouvoir répondre à ces nouveaux défis, mais les principes DevOps initialement définis ne suffisent plus pour mener à bien un projet ML. En effet, ces projets présentent de nombreuses spécificités qui ne sont pas couvertes ou sont mal traitées par le DevOps (voir le tableau ci-dessous).

Ainsi le DevOps ne permet pas de répondre à tous les besoins de ces nouvelles technologies, induisant l’émergence de nouvelles disciplines.

Pour prévenir au mieux les risques et accélérer l’intégration de nouvelles fonctionnalités, de nouvelles perspectives et tendances émergent chaque jour autour des idées du DevOps, déclinées pour chaque usage et générant une véritable ère des Ops : « MLOps », « DataOps », « SecOps », « ITOps », etc. Ces différentes notions sont décrites brièvement dans le tableau ci-dessous.

Pour mieux comprendre les dynamiques associées à ces nouvelles disciplines, nous avons mené une étude sur l’évolution de leur popularité sur Twitter, acteur majeur dans l’émergence, l’exposition et la popularité des nouvelles technologies. Après avoir récupéré l’ensemble des tweets mentionnant chacun des termes associés (DevOps, MLOps, DataOps, etc.), nous avons quantifié et dénombré leur nombre comme mesure de leur popularité sur les dernières années. Les courbes de popularité de ces différents termes sont présentées dans le graphique ci-dessous, avec le terme DevOps qui est présenté à part du fait de ses particularités (voir cadrant en haut à gauche).

Dans le monde de la Tech, le mouvement DevOps se positionne comme précurseur et semble être à l’origine des autres disciplines. En effet, nous observons sur le graphique que la première apparition du terme sur Twitter est en 2007, soit deux ans avant l’apparition d’autres mouvements Ops. De plus, nous observons qu’il y a une augmentation pseudo-exponentielle de sa popularité jusqu’à 2015, suivi d’une augmentation plus faible jusqu’à 2017, portant à 725 000 tweets sur le DevOps en une année (soit 2 000 tweets par jour !). L’inversion de la tendance de popularité à partir de 2017 peut s’expliquer en partie par la création de nouveaux mouvements Ops, entraînant un effet de vases communiquant. Ces mouvements complètent la philosophie du DevOps dans certains domaines nécessitant des pratiques plus spécifiques.

Pour autant, les nouveaux termes associés sont nettement moins représentés sur la Twittosphère avec un rapport de x40 par rapport au nombre de tweets sur le DevOps. Cela peut s’expliquer par le fait qu’avant le DevOps, la communauté des ingénieurs logiciels était déjà massive. Les autres disciplines (Big Data, Machine Learning, …), nettement plus jeunes, n’ont pas encore de communauté mature et manquent d’ailleurs de nombreuses ressources.

À l’origine de tout projet Data, une problématique forte qui s’impose aux organisations est la collecte, le stockage et le raffinage d’une grande variété de données volumineuses. C’est probablement l’une des raisons pour lesquelles nous pouvons voir que la popularité du DataOps augmente fortement dès 2015. Cela a également posé des questions relatives à la sécurité de ces données, d’où l’augmentation de la popularité en parallèle du concept de SecOps.

Il est très intéressant de remarquer que le développement de la popularité du MLOps est postérieur à celle du DataOps. Une première explication de cet ordonnancement fait écho à ce que nous avons décrit précédemment : la première difficulté d’un projet Data est la récupération automatisée de données qualifiées, d’où la primauté du DataOps. Une autre explication complémentaire relève du fait que le DataOps englobait initialement toutes les problématiques liées à l’opérationnalisation des données : du Data Engineering à la Data Science. La stagnation puis la diminution de la popularité du DataOps sur Twitter pourraient s’expliquer par la différenciation des problématiques opérationnelles associées à chaque segment fonctionnel (Data Engineering et Data Science), cédant donc un peu d’espace au MLOps.

En effet, le MLOps s’attache à travailler sur les spécificités d’un projet d’IA et de Machine Learning qui ne sont pas couvertes par le DataOps tels que le versionning, ou encore le monitoring des modèles de ML. La forte augmentation depuis 2018 du nombre de tweets sur le MLOps est un indicateur confortant notre vision sur l’intérêt porté à ce nouveau métier, et en même temps souligne sa prime jeunesse. Par ailleurs, contrairement au DevOps ou au DataOps, ce terme ne semble pas avoir atteint son plateau de popularité sur Twitter, montrant ainsi que le sujet reste pleinement d’actualité. Enfin, les courbes du DataOps et du MLOps se croisent en 2020, laissant penser que les enjeux du MLOps présentent actuellement une importance quelque peu supérieure au DataOps aux yeux de la communauté.

Chacun de ces mouvements est pour la plupart très récent, et de fait, il n’existe pas au sein de la communauté de consensus sur la définition de leurs périmètres, de leurs modus operandi, et des bonnes pratiques associées. En particulier, le MLOps apparaît comme le concept le plus juvénile, et pas des moins complexes. L’impérieuse nécessité d’une vision Ops se résume parfaitement par cette citation de Klaus Schwab, ingénieur, économiste et président du Forum Économique Mondial :

Dans le nouveau monde, ce n’est pas le gros poisson qui manque le petit ; c’est le plus rapide qui mange le plus lent.

Définition, objectifs, périmètre, outils… Retrouvez-nous bientôt pour la suite de cette tétralogie dédiée au MLOps ! En attendant, contactez nos expert·e·s Data pour en savoir plus.

Rédigé par Clément Moutard, Manager Data, et Martin Cudicio, Consultant Data

Dans un monde numérique en plein bouleversement, les entreprises font de plus en plus appel aux nouvelles technologies afin de tirer de la valeur de leurs données.  Cependant, selon Gartner, seulement 13% des projets de Machine Learning (ML) seraient industrialisés aujourd’hui.

L’un des principaux problèmes empêchant les modèles d’être exploités est lié à la difficulté de les opérationnaliser. Autrement dit, le grand enjeu que rencontre la Data Science est la mise en production des solutions de ML.

Le cycle de vie d’un projet ML est constitué de nombreuses phases et convoquent de nombreux métiers : aux côtés du Data Scientist et du Data Engineer qui modèlent la solution, le rôle du ML Engineer est essentiel dans la gestion à terme du projet.

Ses objectifs sont les suivants :

  • Accélérer l’avancement des projets de ML en gérant le cycle de vie des modèles, de leur phase de développement à la post-production ;
  • En amont, co-articuler le projet avec les pipelines de données qualifiées (pertinentes, fiables, de qualité) développées par le Data Engineer. Ces données sont remises au·à la Data Scientist afin qu’il puisse travailler au développement des modèles de ML ;
  • Organiser la phase d’entraînement des modèles pour faciliter la phase d’intégration et de déploiement (selon des règles comme A/B testing, Canary Rollout) dans des environnements de production. Cela permet au·à la Data Scientist de versionner les modèles pour assurer leur gestion systématique ;
  • Suivre la performance des modèles et des données et, s’il y a lieu, faire remonter les écarts, erreurs et métriques au Data Scientist pour assurer l’absence de semantic/concept drift. Le cas échéant, il est envisageable d’y remédier par un réentraînement des modèles, si possible automatiquement ;
  • Suivre la bonne exposition des services ML, par exemple via l’encapsulation des modèles dans une application en collaboration avec une équipe de développement (DevOps et/ou Cloud Architect).

Le ML Engineer maîtrise les librairies de Data Science (Tensorflow, Scikit-Learn) et les outils de développement (Python, R. Jupyter), de DevOps (Airflow, Git, Ansible), de versionning et de ML Management (MLflow, AutoML, Kubeflow). Il est également à l’aise avec la méthodologie Agile afin d’assurer la gestion de projets (Scrum).

C’est un métier facilitateur et pluridisciplinaire qui s’appuie sur des frameworks de gestion de workflows, de versionning, et de ML management. Son rôle est clé, car il crée de la valeur rapidement.

En conclusion

La discipline du MLOps est récente et les pratiques ne sont pas encore harmonisées au sein de la communauté. Toujours en développement, elle garantit des activités très concrètes et innovantes. Si ces perspectives à la fois ouvertes et challengeantes vous intéressent, n’hésitez pas à contacter nos experts Data ou à candidater pour nous rejoindre ici. Au plaisir d’échanger !

Rédigé par Clément Moutard, Manager Data, et Martin Cudicio, Consultant Data

Avec le lancement d’Azure Purview, Microsoft devient le premier cloud provider majeur à faire son entrée dans un domaine aujourd’hui incontournable pour les entreprises : la gouvernance des données.

L’exploitation des données et des analytics est devenue de plus en plus critique et stratégique, que ce soit pour optimiser les ressources, revoir les processus et les produits ou réviser les business models, afin d’en tirer un avantage concurrentiel ou comme prendre les bonnes décisions pour traverser les crises.

La gouvernance, maillon essentiel dans la stratégie des entreprises pour accomplir leur objectif de transformation « data-driven », nécessite la mise en place d’une organisation dédiée, la définition et la distribution de rôles à l’ensemble des acteurs qui manipulent, créent ou utilisent de l’information. Elle a pour objet d’établir la connaissance du patrimoine de données et d’assurer la fiabilité des informations mises à disposition.

« La réalisation de cet objectif est un défi constant dans l’histoire des données et de l’analyse, car son écosystème continue à être complexe et hétérogène » comme l’a souligné Julia White lors du lancement de Purview en décembre dernier.

Ce concept n’est en effet pas nouveau et a toujours été un immense challenge, porté par la mise en œuvre de grands projets décisionnels puis par l’émergence des plateformes Big Data.

Microsoft avait déjà fait ses premiers pas dans ce domaine, avec la mise en œuvre des systèmes BI avec sa solution MDS sur SQL server 2008 R2, puis avec l’émergence des solutions cloud et l’ouverture du service Azure Data Catalog en 2016.

Microsoft effectue aujourd’hui une avancée majeure dans le domaine de la gouvernance (Azure Data Catalog se limitant à la découverte et la compréhension des données), en proposant avec Azure Purview une plateforme unifiée de gouvernance des données qui automatise les fonctions de discovery, de catalogue, de cartographie, et de suivi du cycle de vie des données.

La promesse d’Azure Purview est de centraliser la gestion de grands volumes de données et surtout de les répertorier de manière automatisée.

En effet, la solution dispose de fonctionnalités pour classer et cataloguer les données, qu’elles proviennent d’applications internes, hébergées en mode SaaS (via l’API d’Apache Atlas), stockées dans le cloud ou On-Premise ou encore provenant d’applications de reporting comme Power BI.

Grâce à des fonctionnalités d’IA, Purview permet également de reconnaitre automatiquement les données qu’elles soient structurées ou non ce qui permet d’identifier leurs liens et de les classifier ce qui facilite ainsi leur utilisation.

Le service fournit en complément un moteur sémantique pour la recherche des données par mot-clé, par type (numérique, texte, date…) ou par format (csv, json, document…), issu de glossaires gérés directement par les entreprises ou bien grâce à des templates qui sont proposés par la solution.

Enfin Purview permet aussi de reconnaitre différentes typologies de données (comme des données personnelles ou sensibles) afin d’assurer le respect des règles de sécurité et compliance et fournit également des fonctionnalités de gestion des rôles et des accès grâce à l’intégration dans Azure AD.

Microsoft fait ainsi une entrée remarquée dans un domaine concurrentiel ou se côtoient des poids lourds tels qu’Informatica, Talend, Collibra ou bien des startups récentes comme Zeenea ou Data Galaxy.

La valeur ajoutée du nouveau service Microsoft réside dans son probable impact auprès des entreprises dont Azure est le principal service cloud. Son adoption pourrait donc rapidement lui permettre de gagner des parts de marché, et d’asseoir définitivement Microsoft comme le leader des systèmes de gestion de l’information.

Rohan Kumar, Vice-Président en charge des activités Azure Data précise que « l’investissement dans Purview va durer plusieurs semestres et la prochaine étape sera davantage axée sur les politiques de gouvernance », démontrant la volonté de Microsoft de se placer comme un acteur incontournable du domaine de la gouvernance des données.

Avec le lancement de Purview, le géant du cloud a également annoncé la disponibilité générale de Synapse Analytics, qui lui permet de se doter d’une plateforme unique et complète, rassemblant l’intégration, le stockage, l’analyse et donc la gouvernance des données d’entreprise.

Si vous voulez en savoir plus, n’hésitez pas à nous contacter.

Rédigé par Julien Ayral, Manager Data Driven Business.