Aller au menu Aller au contenu

Par Charles Saulnier, directeur,  Analytique des données & Raphaël Baron, conseiller, Analytique des données

Épisode #1 – Comment j’ai appris à aimer le DevSecOps !

Dans les Coulisses de la donnée, le nouveau podcast de Larochelle

Dans cet épisode des Coulisses de la donnée animé par Raphaël, Charles, expert en visualisation de données chez Larochelle Groupe Conseil, explique comment le DevSecOps transforme le développement et le déploiement des solutions de visualisation.

Découvrez comment appliquer les principes du DevSecOps à Power BI pour standardiser les développements, automatiser les déploiements et intégrer la sécurité dès les premières étapes des projets.

Au programme : codéveloppement avec les projets Power BI (PBIP), gestion des versions avec Git, sécurité des données et des accès (RLS – Row Level Security), automatisation des processus de livraison et meilleures pratiques pour déployer des rapports Power BI en toute confiance.

Grâce au DevSecOps, les équipes de données peuvent réduire les erreurs manuelles, améliorer la collaboration entre développeurs et offrir des livraisons plus fiables et transparentes aux utilisateurs. Une approche qui apporte autant de sérénité aux développeurs qu’aux organisations qui misent sur des solutions analytiques robustes et sécurisées.

Dans cet épisode, vous découvrirez :

  • Ce qu’est le DevSecOps appliqué à la visualisation de données ;
  • Les avantages des projets Power BI (PBIP) pour le codéveloppement ;
  • Comment Git facilite le versionnement et la collaboration ;
  • Pourquoi intégrer la sécurité (RLS et gestion des accès) dès le début d’un projet ;
  • Comment automatiser les déploiements Power BI pour gagner en qualité et en efficacité ;
  • Les bonnes pratiques pour livrer des projets de données avec une plus grande paix d’esprit.

Transcription de l’épisode #1 :

Raphaël: Bienvenue dans les coulisses de la donnée, le podcast de Larochelle Groupe Conseil. Je m’appelle Raphaël et aujourd’hui, on va lever le voile sur les secrets les mieux gardés pour livrer des projets de données avec une paix d’esprit totale : Le DevSecOps appliqué à la visualisation.

Pour explorer ce sujet, j’ai avec moi mon collègue Charles Saulnier.

Charles: Bonjour Raphaël.

Raphaël: Bonjour Charles. Donc toi, t’es vraiment notre expert analyste de données à Larochelle et t’es aussi un maître de l’environnement Power BI et Fabric. On dit souvent de toi que tu es la personne qui arrive à transformer des processus techniques compliqués en quelque chose de fluide et sécurisé. Donc merci d’être avec nous.

Charles: Ça me fait plaisir.

Raphaël: Donc là, nous, on va parler de DevSecOps aujourd’hui. Le titre que tu nous as proposé est vraiment intéressant : Comment j’ai appris à aimer le DevSecOps. Est-ce que tu pourrais nous présenter un petit peu rapidement c’est quoi le concept ?

Charles: Oui, ben tout d’abord, je ne suis pas à la base quelqu’un de très technique. Donc souvent, c’est le profil parfait en visualisation, c’est-à-dire que les gens sont habitués de travailler avec un outil comme Power BI. Ils n’ont pas nécessairement tout le background technique d’ingénierie logicielle. Et en fait, le DevSecOps, si je fais une analogie, il faut le voir un petit peu comme un travail d’une cuisine dans un grand restaurant.

Donc c’est vraiment tout ce qu’on met en place pour être capable de livrer des plats gastronomiques à nos, nos clients. En fait, quand on l’applique à la visualisation, c’est vraiment tout ce qu’on met en place pour être capable de s’assurer que nos développements sont cohérents, respectent ce qui nous a été demandé et se font avec le moins de, d’irritants possible pour les utilisateurs.

Raphaël: Ok. Là, si on, on part de la base, tu sais, je pense que la réalité pour, pour, pour certains, c’est que on fait notre développement, on appuie sur le bouton publier, on croise les doigts que rien ne brise et on va prendre un café. En quoi est-ce que le DevSecOps, ça va apporter, ça va changer ce développement-là

Charles: Oui, ben en fait, c’est un peu le classique là, où comme je suis en train de travailler dans mon outil, j’ai la possibilité de publier directement. Puis là, je clique publier, puis peut-être que je me souviens que: « Oh, j’ai pas envoyé mes choses au bon endroit ou j’ai peut-être fait une erreur manuelle ».

En fait, le DevSecOps, ça tend à l’automatisation et c’est vraiment comment on met une structure pour que nos développements et nos déploiements soient le plus rigoureux, standardisés possible. Puis sur ce point-là, moi personnellement, je suis quelqu’un qui, qui aspire à beaucoup de rigueur. Je ne pratique pas toujours ce que je souhaite faire en théorie.

Donc c’est là où l’intérêt vient pour le DevSecOps, parce que tout, toute la liste de validation, si on veut, qu’on se fait ou qu’on garde à côté habituellement, on peut l’intégrer à notre processus. Donc à mesure que je développe puis j’avance, les cases se cochent automatiquement finalement, parce que ça fait partie de mon processus de livraison.

Et si je détaille un peu, dans le fond là, quand on parle du DevSecOps, on a trois portions qui sont le terme. Donc le Dev, c’est vraiment le travail que je fais personnellement ou que moi et d’autres membres de mon équipe faisons pour développer, faire les évolutions qui nous sont demandées par nos clients.

L’aspect Sec, c’est vraiment l’aspect de considérer la sécurité, les risques qu’il peut y avoir dans le développement en cours de notre processus. Et cet aspect-là, c’est autant les données elles-mêmes que finalement qui a accès à quoi dans le cadre du projet. Puis, pour les opérations, c’est vraiment la partie de livraison où on va se rendre jusqu’à publier de façon le plus automatisée possible le contenu.

Raphaël: Ok. Donc là, si on commence par le début avec le dev. Personnellement, et je sais que c’est la même chose pour certains d’autres d’entre nous dans le domaine, on a nos fichiers qui s’appellent version V1. On a notre PBIX version V1, version V2, version V3, VF, VF2, VF_vrai.

Juste pour commencer là-dessus, est-ce que le DevSecOps, ça peut améliorer, disons, cette pratique ?

Charles: Une des fondations qu’il y a pour, si je prends le cas de Power BI en particulier, une des fondations, c’est que l’exemple que tu donnes, c’est ce qui s’appliquait, puis ce qui s’applique encore quand on est dans un format de fichier, le PBIX, qui est le format classique quand je développe un rapport Power BI, qui peut être vu comme une boîte noire un peu.

D’où le fait que tu mentionnes, tu fais une V1, V2 pour être capable de choisir ce que tu veux mettre en place. À ce moment-là, la fondation dont je parlais tout à l’heure, c’est le fait que maintenant, on a accès à des projets Power BI. C’est finalement ce que Microsoft nous propose pour décomposer notre PBIX en fichiers qui vont distinguer chacun des éléments: les relations dans mon modèle, les tables, mes colonnes, mes mesures.

Donc tout est détaillé dans des fichiers regroupés dans un ensemble de projets. Puis, c’est ce qui va me permettre de comparer vraiment si tu as travaillé sur le développement de nouvelles mesures, je récupère ton travail, je suis capable de voir exactement ce qui a changé entre ton développement puis ce qu’il y avait précédemment, puis ensuite d’aller valider que tout correspond à ce qui était attendu.

Raphaël: C’est les fichiers PBIP que j’avais vu passer, je pense ? Oui, c’est ça. C’est la structure de projet Power BI. Si je comprends bien, ça veut dire qu’on pourrait être deux développeurs à travailler en même temps sur le même rapport.

Charles: Oui, chacun avec notre portion. Si toi, tu as des mesures à développer, moi, j’ai plus un travail d’ajout d’une table. On peut très bien le faire sans que ça génère de conflit dans nos développements.

Raphaël: Ok. Donc, on arrête d’écraser toujours le fichier que notre collègue a fait plus tôt. On a un petit filet de sécurité.

Charles: C’est ça, c’est l’idée. Puis en fait, de par l’intégration qui se fait dans Git, c’est vraiment là où on va versionner, pouvoir suivre et faire tout notre développement, ça nous permet de rétablir, si jamais par mégarde, on a fait une erreur, on peut revenir facilement à une version précédente.

Raphaël: Ok, donc j’imagine, oui, c’est ça, on parle de paix d’esprit. Juste au point de vue dev, ça doit être agréable de se dire…

Charles: oui, c’est ça.

Raphaël: Parfait. Et là, si on passe à la deuxième partie, le sec, le sécurité de notre DevSecOps, j’entends parler de DevOps depuis très longtemps en TI. Je pense que ça, c’est vraiment le truc qui est devenu la base pour livrer plus vite nos projets. En quoi le Sec est venu s’introduire entre ces deux concepts ?

Charles: C’est ça. C’est qu’en fait le DevOps, ça a déjà à la base permis d’accélérer la livraison de projets parce qu’on tend, un peu comme je le disais tout à l’heure, toujours à l’automatisation, à réduire les étapes qu’on doit gérer manuellement. Donc ça ne veut pas dire qu’il n’y a pas d’étapes manuelles, mais on tend à aller le plus possible prévoir le coup puis automatiser ce qu’on fait.

Et au niveau de la vitesse de livraison, ça va. L’aspect sécurité pouvait être soit négligé ou vu plus à la fin du projet. Puis comme la sécurité, ça peut impacter vraiment notre développement, il y a des projets où finalement, on se retrouvait à refaire, repartir peut-être pas de zéro, mais repartir de loin dans le processus pour pouvoir faire nos livraisons.

Donc en l’intégrant à tout ce flux d’activité-là, on le ramène plus vers le départ, donc plus près des développements initiaux pour être capable en fait de moins faire d’itérations inutiles, entre guillemets, quand je vais parler de l’aspect sécurité, on le considère dès le départ. Donc, on est en mesure de faire tout, tout en notre pouvoir pour que ça soit partie intégrante de nos développements.

Puis ce qui est à savoir aussi, c’est que le format de projet Power BI, le PBIP dont on parlait tout à l’heure, en fait, il ne va jamais stocker les données. Donc même si je travaille avec un rapport où je suis en mode import, donc j’ai importé les données dans mes différentes tables, quelqu’un qui récupère le projet pour faire un nouveau développement, s’il n’a pas accès aux sources de données, il ne sera pas capable d’explorer ou d’avancer sur le modèle ou le rapport où on travaille.

Raphaël: Ok. Donc ça, c’est un peu le shift left dont on entendait parler. Souvent, le décaler vers la gauche, de ramener la sécurité plus tôt dans le développement.

Charles: Exact.

Raphaël: Pour s’assurer de ne pas avoir à retourner en arrière, justement.

Charles: Certainement. Puis cet aspect, il y a les données, puis il y a aussi, comme on disait dans le code Power BI, souvent, la sécurité va passer par des rôles, donc du RLS, Row Level Security, ou des objets qu’on veut exposer ou ne pas exposer à certaines personnes.

Donc là aussi, ça fait partie de la définition de ce qu’on a dans le projet Power BI. Puis, on est en mesure de s’assurer que Raphaël, qui est notre VP Québec, donc est capable de voir les données qui le concernent. Puis Charles, qui est le VP Ontario ne verra pas les données de Raphaël, mais va voir ce qui le concerne au sein d’un même modèle et rapport. Donc sans demander aux développeurs de faire chacun leur version.

Raphaël: Oui, parce qu’on ne peut pas juste mettre un mot de passe sur le PBIP, c’est partager le mot de passe.

Charles: Non, idéalement.

Raphaël: Donc, on a fait notre développement, notre codéveloppement. On a poussé tout ça pour avoir un fichier robuste. On a la partie sécurité, donc notre RLS où les gens qui ont les droits peuvent voir les colonnes et les lignes qui sont pertinentes pour eux. Maintenant la partie Ops, là j’imagine si on revient à notre analogie de cuisine, c’est le serveur qui amène le plat vers les clients.

Charles: Oui, puis on s’assure en fait qu’il n’y a pas d’obstacle sur son chemin. Donc le plat, oui, le serveur le prend, mais en fait tout est fait en amont pour que, s’il y avait besoin de goûter, de redresser l’assaisonnement, donc l’exercice est fait avant que ça se rende dans les mains du serveur.

Puis c’est vraiment la, l’aspect livraison. Donc les opérations, c’est comment je passe par exemple de mon développement local à un espace de développement partagé à la production. Donc c’est toutes les validations qu’on met en place pour se rendre à ces étapes-là, puis pouvoir faire notre déploiement en pleine confiance que tout va bien se passer, puis en gardant une trace aussi de ce qui est fait.

Raphaël: C’est ça. Donc je pense qu’il y a beaucoup de transparence à apprécier là-dedans. Parce que le, justement, je disais que quelquefois, ça m’arrivait de, de publier un rapport, quelquefois un vendredi après-midi tard et tu croises les doigts que ça ne brise pas. Là, j’imagine le, la personne, la cliente, la personne qui reçoit le rapport va ouvrir son rapport lundi matin sans remarquer aucun changement et peut-être juste comme quelques fonctionnalités en plus.

Charles: C’est ça. L’objectif, c’est vraiment que ça soit le plus transparent possible pour les utilisateurs. Et comme tu le mentionnais, là, ton stress du vendredi en fin de journée. Ben effectivement, dans la livraison, dans le parcours que notre travail fait, ben on a, on va avoir des documents soit très techniques ou très faciles à lire pour un utilisateur lambda qui nous permettent de savoir que notre déploiement a été fait.

Voici exactement ce qui a changé entre les deux versions. Puis, on s’assure que tout ça est traçable et comme je le disais, le plus transparent possible, à moins que ça soit un changement évidemment d’interface qu’on a à faire ou là ça va paraître pour l’utilisateur, mais c’est voulu aussi, c’est ce qu’on attend de cette livraison-là.

Raphaël: On arrive déjà à la fin de notre émission. Donc si je résume pour nos auditeurs, en fait, grâce à ce système, on arrive à faire du codéveloppement sécuritaire et on arrive à faire des livraisons appropriées rapidement.

Charles: Exactement. Donc le, le, le but, c’est que tout soit le plus rassurant pour nos clients et pour nous en tant que développeurs, parce qu’on le sait que quand notre travail avance d’une étape à l’autre, ben c’est parce qu’il respecte ce qu’on a mis comme standard en place.

Raphaël: Écoute, merci beaucoup d’avoir démystifié ça avec nous, Charles. Je pense que tu as réussi ton pari. Moi, j’ai, j’ai hâte d’appliquer le DevSecOps à la visualisation. J’imagine que nos auditeurs qui entendent ça, qui sont dans les mêmes galères que, auxquelles on fait face, le sont aussi. Donc merci beaucoup.

Charles: Ben merci Raphaël, c’est un plaisir.

Raphaël: Si cet épisode vous a aidé à mieux comprendre l’envers du décor, n’hésitez pas à le partager avec vos collègues et à vous abonner. C’était Charles et Raphaël dans les coulisses de la donnée, un podcast propulsé par Larochelle Groupe Conseil. Merci beaucoup et à la prochaine fois pour un nouveau sujet.

Références:

https://www.microsoft.com/en-ca/security/business/security-101/what-is-devsecops

https://git-scm.com/learn

https://learn.microsoft.com/en-us/power-bi/guidance/powerbi-implementation-planning-content-lifecycle-management-overview

Vous avez des questions?

Écrivez-nous