Penser que la Data est exempte des bonnes pratiques Craft

Le monde de la Data a souvent été vu comme un univers parallèle, tellement spécifique qu’il doit avoir ses propres règles de gestion et de développement. Encore aujourd’hui, la Data a un caractère “mystique” pour beaucoup de personnes non initiées, ce qui justifie la prise de certains raccourcis.

L’un d’entre eux concerne l’application des bonnes pratiques de développement logiciel (ou Software Craftsmanship) à la création de Produits Data. Nous savons depuis de nombreuses années qu’afin d’obtenir un haut niveau de qualité dans un logiciel, un certain nombre de bonnes pratiques sont nécessaires : stratégie de tests, revues de code entre pairs, itérations courtes, mise en place de boucles de feedback pour participer à l’amélioration continue, etc. Dans le monde de la Data, nous avons souvent eu tendance à prendre des raccourcis en ce qui concerne ces bonnes pratiques, et c’est encore plus marqué en Data Science.

La question à vous poser :Gérez-vous vos Produits Data comme on gère un logiciel ?

Les entreprises ont déployé beaucoup de temps et d’efforts afin de mettre en place des bonnes pratiques autour de l’agilité, du DevOps, du Software Craftsmanship et du Product Management, mais lorsqu’il s’agit de la Data, toutes ces bases peuvent s’envoler en fumée. S’il est indéniable qu’il existe des particularités qui sont spécifiques à la Data (citons par exemple le côté exploratoire inhérent à la Data Science), il n’est pas nécessaire de réinventer la roue lorsque l’on sait déjà créer des logiciels et produits depuis des années et qu’il suffit alors de créer quelques adaptations plutôt que de retomber dans des tunnels de plusieurs mois.

Encore aujourd’hui, il n’est pas rare de constater un mode de fonctionnement où des Data Scientists travaillent de manière isolée, pour ensuite donner leurs travaux à des Data Engineers afin d’industrialiser le tout. Au-delà du fait que ce mode de fonctionnement ne fasse qu’agrandir des silos, c’est aussi un risque fort d’un point de vue technique.

En effet, que faire si le package utilisé change de version ? Que faire s' il n’est pas compatible avec les environnements de production ? Quid d’une dégradation des performances si l’on doit changer de langage ? Que faire si le temps de calcul est beaucoup trop long pour que le modèle soit utilisé en conditions réelles ?

Il est bien dommage de se rendre compte de ces problématiques seulement après que de longs mois d’exploration aient été dépensés.

Notre recommandation : Gérer la Data comme on gère du logiciel : appliquer les bonnes pratiques du Software Engineering en prenant en compte les spécificités de la Data.

Quelle que soit l’étape dans laquelle vous êtes dans votre projet Data, nous vous recommandons de mettre en place des bonnes pratiques issues du monde du développement logiciel. Citons notamment deux bonnes pratiques pour illustrer ce propos :

Mettre en place une stratégie de tests pour chacun des composants de votre chaîne de traitement

De la collecte de la donnée au réentraînement automatique d’un modèle, chaque brique doit avoir sa stratégie de tests adaptée.

Mettre en place des revues de code entre pairs, ainsi que des revues de code croisées

Faire en sorte que même le code “exploratoire” dans le notebook d’un Data Scientist puisse être relu par un Data Engineer est une bonne pratique permettant de faire en sorte que certains réflexes puissent être mis en place en termes de qualité de code ainsi que de facilité à l’industrialisation. Il en est de même dans le sens inverse, car permettre à un Data Scientist de relire le code des Data Engineers lui permet d’appréhender la complexité de la création de code selon les standards du développement logiciel, et de resserrer l’écart entre les deux mondes.

Considérer un Produit Data comme du logiciel, c’est se donner les garanties de la création d’un produit dans lequel on peut avoir confiance, qu'il soit résilient et adaptable. Les spécificités du monde de la Data ne doivent pas faire oublier les acquis de nombreuses années en termes de bonnes pratiques de développement logiciel.

Le DataOps est défini par Gartner comme “une pratique collaborative de gestion des données visant à améliorer la communication, l’intégration et l’automatisation des flux de données entre les gestionnaires et les consommateurs de données au sein d’une organisation”.

Les connaisseurs des méthodologies DevOps y verront beaucoup de parallèles, et c’est bien normal, car le DataOps s’inspire des mêmes principes pour les appliquer aux équipes qui travaillent avec la donnée.

En voici ses principaux enjeux :

• Déploiements continus afin de réduire le délai de mise en production ;
• Tests automatisés pour s’assurer d’obtenir des données de meilleure qualité ;
• Contrôle des métadonnées afin de garantir une meilleure gestion des changements et éviter les erreurs ;
• Monitoring pour le suivi du comportement des données et de l’utilisation du pipeline afin d’identifier plus rapidement les défauts qui doivent être corrigés ;
• Collaboration constante entre les parties prenantes sur les données afin d’assurer une livraison plus rapide des données.

De son côté, le Data Reliability Engineer est tout simplement un SRE (Site Reliability Engineer) qui a un focus tout particulier sur les problématiques spécifiques de la Data citées plus tôt.

Vous l’aurez compris, les approches techniques et méthodologies de développement ont un rôle essentiel dans la quête d’une donnée de confiance. Mais cette quête ne se résout pas que par un volet technique. En outre, une bonne gouvernance des données est l’un des piliers d’une stratégie Data performante. Et ce point relève plus de problématiques organisationnelles que techniques.

L’un des pré-requis est d’avoir des personnes au sein de l’organisation qui ont pour responsabilité de gérer et maintenir cette gouvernance. Elles ont souvent une casquette de Data Manager, et doivent prioriser les sujets de qualité de la donnée ainsi que poser les définitions et rôles en interne autour du Data Management.

Un autre pré-requis communément admis est de se doter d’un Data Catalog, qui permet d’accélérer et de garantir la bonne gestion de ses données et de leurs propriétés.

Enfin, il va sans dire qu’il n’y a pas de bonne gestion et gouvernance de la donnée sans un respect des réglementations en vigueur, notamment la RGPD en Europe. D’autres réglementations, comme la Digital Services Act ou la Digital Markets Act, sont sur le point d’arriver et pourraient fortement affecter certains acteurs. Les changements techniques et organisationnels à opérer pour les respecter peuvent s’avérer complexes mais essentiels à mettre en place. Chaque acteur manipulant de la Data a une responsabilité forte dans sa gestion et son exploitation, et se doit d’être pleinement conscient de son impact sur ses utilisateurs et la société au sens large.

Au final, la mise en place effective d’une gouvernance des données n’est pas un simple projet technique, mais plutôt un programme de transformation à l’échelle de l’entreprise, et entre directement dans les prérogatives du Chief Data Officer.

Si vous souhaitez avoir l’ensemble des écueils à portée de main, rien de plus simple ! Vous pouvez télécharger notre eBook dédié directement en pdf, ou bien vous le procurer en version imprimée ou Kindle sur Amazon !