Nos publications

Toutes les compétences essentielles à la création de Produits Data de bout en bout sont-elles représentées au sein de vos équipes Data ?

Lorsque l’on parle d’équipe Data, les profils qui viennent assez souvent en tête sont les #datascientists et les #dataengineers. Mais ce n’est pas suffisant dans l’optique de créer des Produits Data qui apportent de la valeur business, et encore moins pour passer à l’échelle dans l’exploitation de la donnée de l’entreprise.

L’important n’est pas tant de savoir combien de personnes ou de métiers différents vous devez intégrer au sein de vos équipes Data, mais de construire une #datateam diversifiée, capable de créer des #dataproducts de bout en bout, sans laisser de côté les dimensions #business et #product.

Vos #datateams sont-elles encore obligées de convaincre vos directions business de l’intérêt de travailler avec elles ?

Un changement de perspective sur la place de la #data dans l’entreprise est nécessaire ! Le #chiefdataofficer et les équipes Data doivent passer d’un positionnement de “vendeurs de services” à celui de “partenaires privilégiés” du business pour les aider à prendre des décisions par la donnée.

L’objectif est de mettre la #data au cœur des enjeux stratégiques de l’entreprise et rompre le silotage entre les équipes Data et le reste de l’organisation.

Ces principes ne sont pas sans rappeler ceux du #datamesh, qui peut servir de source d’inspiration dans ce changement de paradigme.

‍

Sortie en Avril 2022 sur la région France, l’inférence “serverless” de AWS SageMaker apporte une promesse de forte réduction des coûts de déploiement de modèles de Machine Learning. Véritable point de convergence entre AWS Sagemaker (Machine Learning) et AWS Lambda (exécution de code sans serveur), cette nouvelle fonctionnalité permet l’obtention de prédictions en temps réel tout en se passant de la location et de la gestion de serveurs.

Avec une tarification à l’utilisation, ce mode Serverless permet ainsi une réduction significative des coûts pour bon nombre de cas d’usage, au prix de quelques compromis. Dans quel cas ce nouveau mode est-il le plus adapté ?

Rares sont les entreprises n’ayant aujourd’hui aucune exploitation de leurs données, mais rares aussi sont celles qui ont réussi à passer son exploitation à l’échelle de toute l’organisation et à mettre la Data au cœur de leur activité.

Démocratiser la Data est l'un des enjeux majeurs de nombreuses entreprises aujourd'hui. C'est notamment l'un des objectifs du Data Mesh, dont l'un des piliers repose sur la gestion de données par domaine métier afin de simplifier leur utilisation et leur maintenance.

Par conséquent, pour assurer la gouvernance de la donnée sans avoir à augmenter le nombre des profils Data, il est nécessaire de former ses équipes et d’être capable de parler le même langage entre les profils techniques et non techniques.

C’est là où nous avons besoin de la Data Literacy.

Utile, Utilisable, Utilisé ! Comment faire pour qu’un projet Data réponde à la règle des 3U ?

Nous vous proposons un support pour faciliter la phase de cadrage, qui constitue la première partie indispensable du cycle d’un projet Data.

C’est dès cette phase amont des projets qu’il faut créer un alignement entre toutes les parties prenantes. Embarquez donc les sponsors, les potentiels utilisateurs, les développeurs et toute personne qui pourra apporter des éléments pour faciliter et challenger vos réflexions concernant le problème à résoudre.

Lorsque l’on développe dans un Notebook en PySpark, on peut être amené à convertir nos DataFrames Spark en DataFrames Pandas afin de profiter de superbes bibliothèques comme PyPlot pour créer des graphiques, ce qui est très pratique. Mieux encore, les APIs étant très proches, on peut facilement migrer un code Pandas en Pyspark lorsque la volumétrie le demande. Cependant il faut faire attention et ne pas oublier que ça reste deux technologies différentes qui répondent à des besoin différents.

De nombreux chiffres ont été publiés et font du bruit sur le taux de projets data qui échouent à aller en production et ne dépassent pas le stade du PoC (Proof of Concept) :

• Un rapport de VentureBeat AI explique que 87% des projets Data Science ne vont pas en production
• Gartner estimait en 2019 que 80% des projets d’IA de 2020 allaient rester à l’état de PoC, menés par des “sorciers” dont les talents ne sont pas compatibles avec une exploitation de la data à l’échelle de l’entreprise
• Ce même rapport Gartner estime que seulement 20% des insights d’analytics vont réellement délivrer de la valeur en 2022

Mais au final, est-ce une si mauvaise chose que certains projets n’aillent pas plus loin ? La question mérite d’être posée.

Les entreprises constatent aujourd’hui les investissements exorbitants nécessaires pour maintenir et faire évoluer leur plateforme Data. La frustration augmente car les retours sur investissement sont complexes à mesurer dans la plupart des cas.

De plus, nous observons à nouveau des silos avec des équipes data qui sont isolées des autres équipes métiers ou IT.

Il est temps de repenser notre façon de travailler autour de la data.

Jeune développeur, allons voir si ton wheel,
De son packaging si difficile,
Et de sa robe de pourpre sur ton poste,
A point perdu quand tu exportes
De sa compatibilité si complexe
Et de son gain si perplexe.‍

Ah le packaging en Python! Une étape nécessaire mais malheureusement assez douloureuse lors de la gestion des projets Python.

Le monde de la Data a souvent été vu comme un univers parallèle peuplé de Data Scientists aux airs de licornes ou autres moutons à 5 pattes qui allaient magiquement faire faire des avancées incroyables aux entreprise grâce à leurs petits doigts.

La désillusion fut grande lorsque le temps du bilan a sonné : POCs qui duraient éternellement et échouaient à partir en production (ou bien à simplement apporter de la réelle valeur pour le business), manque d’appropriation de la donnée en dehors des équipes data, manque de confiance dans la provenance, la traçabilité et la qualité de la donnée, et projets tirés par la tech et pas suffisamment par la valeur business.

Pour améliorer les performances de votre job Spark, vous avez probablement déjà pensé à ajouter un cache sur une ou plusieurs de vos DataFrames. C’est même peut-être devenu une habitude.

Le terme MLOps (Machine Learning Operations) est de plus en plus souvent employé dans la communauté data et est rapidement devenu un concept central dans la mise en production et le passage à l’échelle de projets à base de Machine Learning.

Tâchons de comprendre ce qu’il y a derrière, d’où cela vient, et surtout pourquoi c’est maintenant devenu une nécessité.

Cette année, nous nous sommes lancés dans un projet de benchmark d’Apache Spark avec pour objectif d'être capable de déterminer les différences de temps d’exécution entre Spark avec Yarn et Spark sur Kubernetes. Nous partagerons nos différentes découvertes au fur et à mesure dans cette série d’articles.

‍

Un produit Data Science étant avant tout un produit logiciel, les bonnes pratiques de Software Craftsmanship et de développement itératif et agile y ont toute leur place. Sauf que lorsqu’il est question du modèle de Machine Learning en lui-même, il est très courant de beaucoup moins respecter ces principes. Et se pose alors souvent la question fatidique : “stop ou encore ?”.

“Responsible AI”, “Explainable AI”, “AI Fairness”, “Ethical AI”, etc. Tous ces termes prennent de plus en plus d’ampleur dans les discussions mais aussi dans les investissements des entreprises qui créent des produits incorporant de l’Intelligence Artificielle.

Que ce soit d’un point de vue business pour mieux comprendre le raisonnement derrière certains modèles “Black Box” et prendre de meilleures décisions, ou d’un point de vue sociétal ou environnemental, une réelle prise de conscience est en train de se dessiner autour de ce sujet.

Notre conviction est qu’un modèle de Machine Learning (ML) n’a que très peu de valeur en soi, c’est son utilisation en production et en réponse à une problématique métier précise qui est importante. Et pour cela, rien de mieux que de rapidement passer à la création d’un MVP de bout en bout.

Dans cet article, nous vous proposons 6 propositions d’approches afin d’avoir des premières versions de modèles simples à mettre en place et permettant donc d’implémenter rapidement un MVP plutôt que de rester trop de temps sur le modèle en lui-même.

‍

“Responsible AI”, “Explainable AI”, “AI Fairness”, “Ethical AI”, etc. Tous ces termes prennent de plus en plus d’ampleur dans les discussions mais aussi dans les investissements des entreprises qui créent des produits incorporant de l’Intelligence Artificielle.

Si le potentiel incroyable de l’Intelligence Artificielle est maintenant compris et exploité depuis plusieurs années, son impact - voire sa dangerosité - sur nos vies, nos sociétés et notre environnement est de plus en plus scruté et débattu.

L’IA Responsable n’est aujourd’hui plus seulement un sujet de débat, c’est devenu une réalité qu’il est nécessaire de prendre en compte dès les premières phases des projets à base de Machine Learning (ML). Mais qu’y a-t-il vraiment derrière ?