Si le terme DataOps vous donne des sueurs froides, que vous êtes terrifiés à l’idée de devoir discuter du sujet avec votre manager ou votre équipe, vous êtes donc au bon endroit pour vous y retrouver dans cette jungle impitoyable des buzzwords de la tech.

Mais comment en est-on arrivé là ?

Vous venez de passer ces derniers mois (voire années !) à suivre les tendances du monde de la data. En vous spécialisant sur les technologies Microsoft, vous pensiez être à l’abri et pouvoir prendre le temps de développer une expertise largement suffisante pour vous offrir un avenir radieux en tant que Data Analyst, Data Engineer ou Data Scientist. Power BI n’avait presque plus de secret pour vous. Et puis 2023 est arrivé : le nom de Microsoft Intelligent Data Platform a été prononcé, suivi quelques mois après de l’arrivée de Microsoft Fabric. Vous n’aviez même pas eu le temps de comprendre à quoi servait Azure Synapse Analytics.

Et aujourd’hui, votre patron vous demande de lui faire une synthèse du marché de la data. Il vous parle de Data Mesh, de DataOps, vous demande quelle est la meilleure architecture à adopter et vous ne savez même pas comment surfer cette déferlante data sans être submergé par des tas de concepts incompréhensibles.

Vous avez donc besoin de simplicité : je vais donc faire simple. Il vous suffit de :

• marquer cet article en favori. J’y ajouterai au fur et à mesure les liens utiles pour vous accompagner dans votre découverte du DataOps
• si le concept vous est inconnu, je vous invite à lire en détail le DataOps Manifesto. C’est le point de départ de votre apprentissage.
• si vous souhaitez aller plus loin, vous trouverez en fin d’article mes principales sources de connaissances sur le sujet.

DataOps Manifesto

Tout comme le manifeste DevOps (ainsi que tous les manifestes inspirés du manifeste Agile), DataOps est fondé sur 18 principes qui représentent l’alpha et l’oméga de ce que doit être une démarche DataOps. Plutôt que de lire une n-ième définition du concept de DataOps, parcourez un par un ces 18 principes pour comprendre la démarche avant de l’appliquer :

1. Satisfaire votre client de manière continue : des livraisons régulières apportant chacune son lot de fonctionnalités ou d’améliorations. En bref, mieux vaut une livraison partielle anticipée qu’une livraison complète plus tardive.
2. Valeur de fonctionnement de l’analyse : privilégier la robustesse de l’analyse en s’assurant de la qualité des données.
3. Etre ouvert au changement : parce que les besoins du client évoluent (je ne vous apprends rien !), l’accent doit être mis sur les échanges et la communication avec ce dernier.
4. Il s’agit d’un sport d’équipe : la diversité des profils dans l’équipe Data doit faire émerger l’innovation.
5. Interactions quotidiennes : plus de tunnel de développement mais des échanges quotidiens et continus avec l’équipe et le client. Une seule team pour un but commun.
6. Auto-organisation : de la discipline et de l’organisation (au sein de l’équipe) avant tout.
7. Réduire l’héroïsme : si toute l’équipe s’accorde sur un but commun, leurs efforts seront concentrés sur la maintenabilité et la scalabilité de leurs développements.
8. Faire son auto-critique : prendre du recul régulièrement et intégrer les feedbacks du client et de l’équipe.
9. L’analyse en tant que code : même si l’analyse de données nécessite des outils plutôt orientés low-code, elle produit toutefois des artefacts (environnements, paramétrage, code) qui nécessitent d’être documentés, sauvegardés, versionnés.
10. Orchestrer : un projet data est avant tout un projet, avec un début mais aussi … une fin !
11. Pouvoir reproduire : toujours envisager l’avenir, la réutilisation des méthodes appliquées au projet en cours.
12. Environnements disponibles : comme pour tout développement, la mise en place d’environnements techniques doit être la plus optimale possible (reproductible et peu coûteuse en temps).
13. Simplicité : LE principe à toujours garder en tête. Toujours penser simplicité avant tout.
14. L’analyse en tant que fabrication : les développements data sont avant tout des processus qu’il faut chercher à optimiser.
15. La qualité est primordiale : tout processus data devrait comporter ses propres contrôles en terme de sécurité et de détection d’anomalies.
16. Surveiller la qualité et la performance : détecter c’est bien, contrôler et superviser au fil du temps, c’est encore mieux.
17. Réutiliser : chaque projet n’est pas indépendant. On se doit de réutiliser les principes appliqués lors du développement du projet précédent.
18. Améliorer les temps de cycle : il faut réduire le temps séparant l’expression initiale du besoin de la livraison du projet final. Pour cela, chaque projet est une expérience dont il faut tirer des conséquences pour la suite.

Vous l’avez deviné, 18 autres articles suivront celui-ci, chacun détaillant un des principes du manifeste DataOps et présentant un cas concret de mise en application (un peu de patience : ça arrive !).

Pour aller plus loin

Au lieu de vous noyer sous les multiples références fleurissant sur le sujet (il y existe autant d’experts du DataOps que de professionnels de l’IA Générative, ces derniers temps), j’ai choisi de vous proposer les 3 ressources (la plupart traduites en français) apportant une vision à la fois complète et pragmatique du sujet :

• The DataOpsManifesto – LA référence. Le point de départ de toute démarche DataOps. Le site officiel a le mérite de proposer une version traduite dans 11 langues.
• Conception d’une architecture Azure DataOps – Microsoft s’est bien entendu emparé du sujet et propose un guide (également traduit en français) d’implémentation de la philosophie DataOps adaptée aux architectures data dans le cloud Azure.
• Bringing DataOps to Power BI – le blog de John Kerski (en anglais) est un guide complet d’implémentation du DataOps adapté à Power BI. Chaque article détaille un principe du manifeste et propose une mise en oeuvre pragmatique (avec des liens vers les ressources hébergées sur son GitHub).