De Tableau à Power BI : Migrer autrement avec le #VibeCoding

Phare Data

0:03[musique] [musique] Ouais, bonjour et bienvenue sur Fardata, la chaîne qui éclaire vos données. Dans l'océan des données, voir clair change tout. Sur Fardata. On décrypte les services de données d'Analytics et d'IA. Le tout avec un ton accessible, des choix techniques assumés et une touche dermarin. Que vous soyez architecte, analyse, dat engénieur, product honur ou simplement curieux, Fardata vous accompagne pour comprendre les enjeux réels, éclairer les compromis et prendre de meilleures décisions et parfois avec le cri des mouettes en bruit de fond. Si ce genre de continu vous parle, n'hésitez pas à vous abonner. Cap sur épisode du jour. Aujourd'hui, j'ai le plaisir d'être accompagné par Pierre et Marc pour évoquer le vibe coding en prenant comme exemple un besoin récurrent chez nos clients qui est celui de migrer des tableaux tableau vers fabrique. Marc, tu peux nous rappeler d'abord ton rôle et si tu as eu déjà des clients qui ont eu ce besoin ? Bien sûr. Bon, bonjour à tous. Donc moi, Marc, je suis Solution engineer du coup sur la partie data et euh effectivement aujourd'hui, on a beaucoup de clients euh qui sont intéressés par passer de de tableau ou bien même d'autres technologies. On parle au tableau au point de vue reporting, mais on on a on a beaucoup de de clients qui sont intéressés de manière générale de passer sur fabrique. Là en l'occurrence sur Power BI. Alors, ils sont euh les fonctionnalités, tout leur plaît, mais euh quid de la migration parce que euh aujourd'hui euh l'effort de migration pour passer d'un tableau à PowerBay, la philosophie est différente. Donc ce qui fait que on va devoir recoder l'ensemble et parfois euh projet en terme de de d'implémentation peut prendre du temps. Et donc, j'ai eu beaucoup de clients qui ont été, on va dire, stoppés par ce par ce par ce par ce par ce biais là. Et donc c'est pour ça que Pierre a mis en place un projet. Pierre, je te laisse te présenter. Oui. Donc je suis aussi engurer côté Microsoft he surtout de la stack data et j'ai eu le même souci que Marc. J'ai beaucoup de clients qui souhaitent migrer de tableau vers Power BI et actuellement faut être honnête il y a assez peu d'outils sur le marché qui le font avec des bonnes performances et ça veut dire qu'il nous faut des projets de 1 ou 2 ans. Et du coup de est venu l'idée de se dire bah est-ce qu'on peut accélérer cette migration ? Est-ce que le V coding peut nous permettre de créer des outils qui vont migrer dynamiquement du tableau vers PowerB ou même d'autres outils ? Une question bête Pierre, c'est quoi finalement le Vibe coding ?

Vibe Coding ?

2:31Ah, c'est une très bonne question marque. Le vibe coding c'est assez simple, c'est juste un agent, vous connaissez tous la Gennyi on pose des questions sur vos données, des fichiers et cetera. Bah là, en fait, le but c'est qu'on a un stand qui va nous aider à développer. Donc ça être assez simple. On peut utiliser par exemple Gitup Copilote donc dans Visual Studio qui vous permet de faire ce type d'élément. Donc on va juste poser des questions et selon vos questions, ben l'outil va générer du code répondant à votre question. Donc c'est pas pour ça qu'en fait on a pu réaliser cet outil de tableau ver Power BI uniquement au V coding. On a créé aucune ligne de code même la documentation a été générée par le VAC coding et par l'agent et c'est fini. Mais ce qui est important c'est que vous allez voir c'est de plus en plus le VAC coding et va s'industrialiser. Au début on pouvait faire du VAC codingement pour créer un petit outil de migration ou juste un code tout simplement d'une cinquantaine centaines de lignes. Maintenant avec les nouveaux modèles, on peut quasiment créer les projets endions et des millions de lignes de codes à disposition. Vous allez voir sur sur notre projet tableau verb, on a 80 lignes 80000 lignes de code généré par l'outil. Donc on a quand même une bonne performance associée, la bonne sécurité et cetera. Mais il y a plusieurs méthodes de webcoding. Le premier par là où on commence la partie yolo. On connaît tous le yolo dans dans le jeu vidéo. C'est vraiment de se dire on y va à l'arrache, on pose des questions, on a un résultat très rapide. Le point c'est qu' va peut-être répondre à 20 % des besoins et cetera, mais au moins on a un prototype. Donc c'est très intéressant pour montrer un client que ça peut fonctionner avec le valoding. On fait un po rapide, on voit comment il est. OK. Au moins en 1 heure. En 1 heure on peut avoir un truc qui fonctionne, on peut le démontrer et après on va plus loin. Mais ça va beaucoup plus vite que juste déjà commencer à créer une infrastructure, autre chose. Là, on a un truc qui peut fonctionner dans certains cas. Voilà, on coupe peut-être 10 % du besoin mais au moins c'est utilisable. Ensuite, on aller sur la partie structurée qui est de se dire bah en fait, on va commencer déjà à passer en mode multiagent. Donc chaque agent va avoir une fonctionnalité spécifique. Un qui va définir le plan de migration, un qui va définir comment migrer, qui va faire un assessment, un qui va faire les tests, un qui va faire les déploiements et cetera. Là où c'est intéressant, c'est chacun a une tâche et chacun va avoir vraiment un ordre dans ce qu'on veut demander. Et ensuite, on va vraiment aller sur la partie SP driven dans le sens que on va pas commencer à coller. On va juste passer peut-être par exemple une journée, 1 heure ou 2h à définir le plan du projet en tant que tel. Donc c'est pour ça on va pouvoir faire un suivi dessus et chaque agent va avoir déjà une liste de tâches à faire dans le futur. C'est vraiment comme un planning projet tout simplement. Chacun on va avoir des phases et pour chaque phase, on vair des inputs, des outputs. Et par rapport à ça, en fait, on va pouvoir suivre toute la vie du projet. À chaque tâche, on a la mise à jour de ce qui s'est passé. On sait quels sont les futures étapes de migration ou de développement et on sait où on est toujours par rapport à notre achement. Encore une fois, le but c'est de se dire est-ce que on arrive à atteindre notre finalité ? Et à chaque fois, c'est pour ça qu'on parle toujours de gap analysis qui est de se dire bah oui, entre toutes mes étapes, où est-ce que j'en suis par rapport à ce qui était prévu, il a développé et ce qui reste à faire un projet end toend. Vas-y Marc. Une question qu'on se pose tous, c'est est-ce que c'est accessible à tout le monde ? Parce que finalement là, on a sur un sujet spécifique qui est de tableau vers Power BI. Alors, on sait que tableau en terme de philosophie par rapport à un Power BI, c'est forcément pas la même chose. Est-ce que ça te demande finalement de connaître l'outil source ou l'outil cible pour pouvoir le faire ? Ah oui, en fait c'est une très bonne question. La partie yolo, tout le monde peut le faire. Voilà, parce qu'on veut migrer, il va vous migrer quelque chose. Le point, c'est qu'il va pas migrer tous les objets parce qu'il y a pas détecté tous les types d'objets à migrer et cetera. Là où effectivement, tu as raison, il faut connaître les outils, il faut connaître ce qu'on a en entrée et ce qu'on a en en cible en fait. Donc, il faut connaître les fonctionnalités de tableau à disposition et comment pourrait être la cible côté pouvoir bi donc on peut l'aider. Lui, il va ce que tu vas faire dans le modèle spec où tu vas lui définir des spécificités de du produit initial. OK. Le but c'est c'est de comprendre en fait ce que lui il il a compris de cette migration. Peut- était très simple, il juste pas était sur la partie reporting uniquement mais tableau et pour ce n'est pas ça. Il y a une partie intégration, il y a une partie modèle, il y a même des dashboards, il y a même des abonnements et cetera en fait. Donc il peut juste se limiter la partie visuelle mais nous on va aller beaucoup plus loin. Donc le yolo, on aura juste le visuel, ça va fonctionner. Par contre on aura tout, on a'ura pas le backend, on aura on a'ura pas le déploiement et cetera. ça que l'pect est importante et surtout connaître les inputs et les outputs. Comme ça, on peut toujours contrôler ce que lui il a généré. Voilà. Alors, moi je suis assez curieux du langage que tu vas utiliser pour migrer puisque finalement si je fais euh du value coding sur Power BI, ben je vais utiliser le le DAX ou en tout cas les les langages qui sont directement dans Power BI. Là, comment tu te dis bah je vais utiliser tel ou tel langage qui va être mon outil de migration ? Alors, par défaut, il prend toujours le Python pour Gen du code de migration en tant que tel et par rapport à PowerB. Pourquoi ? parce qu'on a pas mal de bibliothèques ou librairies qui sont en Python qui permet d'accéder aux APIA ou MCP serveur côté fabrique. Donc dans ce cas-là, il a fait le choix de par exemple pour ce projet-là d'utiliser du Python. J'ai d'autres projets où il est passé en C++ parce que c'était par rapport à des backend et cetera mais par défaut c'est du Python. Et là dans notre cas en fait il a généré des PowerBill project en TMDL, en Gison et cetera. Ça qui est intéressant c'est comme ça on a l'information de tout ce qui était émigré. On a les objets unitaires, on a le rapport pour objet de projet qui est migré et aussi on peut aller plus loin notamment avec les livrairies de Python et cetera pour déployer directement ce proine. En fait, ça veut dire que là, tu vas utiliser, tu vas aussi te servir de certains MCP euh pour t'aider euh sur la target, c'est-à-dire qu'aujourd'hui, il va se connecter à un modèle PowerB pour faire toute la migration de tableau vers Power BI où c'est vraiment from Scratch qui va aller tout seul euh se dire bah voilà, je sais comment fonctionne le projet Power BI et j'ai pas besoin de d'installer des plugins avec des MCP supplémentaires. Alors, on peut lui demander en fait de base, moi comme c'était pour un client particulier, je lui demandé de jamais se connecter sur des MCP. Voilà, tu es juste connecté au MCP pour lui était ouvert en offline. Le but c'est après de pouvoir faire des migrations offline. Donc en fait, il y a il y a le choix. En fait, lui, il va poser la question est-ce que je fais tel ou tel MCP ou est-ce qu'on autorise tel ou tel MCP ? Moi, j'ai juste dit on garde le MCP fabrique parce que ça va nous aider pour la partie déploiement. Tout le reste, on interdit. Voilà. Donc dans ce cas-là, en fait, soit on peut tu sais par des modèles locals, soit dans ce cas-là, on lui demande souvent d'aller chercher toute la doc. En fait, moi il y a des moments, il a été recherché la doc euh chez nous, des exemples sur GitHub, pour voir comment on peut migrer et cetera. Alors, justement, tu as parlé de modèle, tu as parlé de modèle. Aujourd'hui, quel LLM tu utilises ? Parce que on sait que il y en a beaucoup. Est-ce que toi tu as des préférences là-dessus ? Alors, actuellement, soyons nés, depuis 2 mois, euh je v que pour Cloud Plus 4.6, il est assez nouveau et surtout comme il a un gros contexte, on peut vraiment créer des applications. Al comme je disais avant, il y a un an, on pouvait juste créer des je peut-être un fichier de code et c fonctionnait bien, mais on était vraiment limité sur une fonctionnalité. Maintenant, on peut créer un projet de N to avec ce type de modèle. Super intéressant, Pierre. Et du coup, bah comment on fait tout ça ? Parce que il y a on a parlé de LLM, on a parlé de Python et cetera. Comment quel utilité tu les utilises pour faire tout ça ?

Demo

9:10Et ben le plus simple c'est de vous le montrer en direct hein de toute façon donc comme je je l'avais présenté on va utiliser principalement Gitup Copilot donc là ici c'est tout mon projet de migration qui est à disposition que vous voyez et ici c'est ici mon agent voilà ici je poser mes question là je suis sur Visual [raclement de gorge] Code je poser mes questions et il va se mettre à jour donc selon mes question bah je vais savoir qu'est-ce que j'ai en cours de développement qu'est-ce qui a été développé mes limites et cetera ça que vous allez voir j'ai beaucoup de fichiers on va pas être trop dans les détail mais le but c'est vraiment de se dire bah oui j'ai même un plan de déploiement de développement qui est à disposition. Et dans tous les cas, moi je vais savoir à un instant donné où j'en suis dans mon plan de développement, quels sont les features qui ont été implémentés ou non et cetera. Et ensuite, il y a plus qu'à tester. Voilà, à la fin, il va juste générer du code Python euh qu'on va pouvoir exécuter tel qu'elle sur la machine. Donc euh là, ce qui est important, c'est qu'on a plusieurs exemples à disposition. Donc là le GitHub il est il est il est à disposition mais on va pouvoir migrer soit des rapports unitaires, soit euh en boucle plusieurs rapports. So on peut même se connecter sur un tableau serveur, récupérer métadonnées et migrer. Donc là on va faire un cas simple, c'est qu'on a deux rapports tableau. Donc ces rapports sont publics, il est aussi été les récupérés directement sur GitHub en tant que tel. Donc un sur la partie NBA quand on le voit, il est assez sexy celui-là. Donc on verra après quel pourra être le rendu que va générer l'outil de migration. Et un second qui est sur la partie superstore. Voilà donc on a deux rapports à disposition. Les deux sont disponibles dans un dossier en tant que tel. Donc les deux, ils sont sur un de mes dossiers qui sont ici. Donc ces deux rapports, ils sont là. Et ce qui est important sur migration, vous allez voir, c'est qu'il y a pas mal d'options. On va faire l'option assez simple qui est de se dire "Bah, je vais le migrer en tant que tel." Donc là, c'est juste un migrate. Pille, j'ai des options. Est-ce que je fais en batch et cetera et quel est mon dossier de sortie ? Donc, je vais l'exécuter. Donc là, vous allez voir prendre là, il faut il faut qu'on aille sur ton git faire un clone de tout ton projet. Ouis, on fait un clone et vous pouvez l'utiliser. Voilà. On peut directement le exécuter le point. Il y a pas de librairie installé, c'est important. Encore une fois, faut juste avoir une version de Python 3.12 et ensuite vous pouvez l'exécuter. Là, j'ai exécuté, il a pris 2 secondes pour migrer de rapport. Donc là, je vais avoir à disposition mon outil de migration. Donc j'ai aussi à on met à disposition un rapport de migration pour entre guillemets savoir bah quel est le contenu de tous les workbooks qui ont été immigrés côté tableau. Donc les contenus, ça peut être le nombre de tables, les colonnes, les mesures, les visuels et cetera. la part qui si on a un peu plus de complexité et ce qui est important ça vous permet aussi de vous de contrôler donc par exemple ici je suis sur à la la vue qui est un peu la partie DAX donc je sais les formules sources et je sais comment il a converti en DAX même si à la fin j'ai rapport utilisable mais au moins vous avez le suivi et s'il a besoin de contrôler vous l'avez l'information et c'est pour ça qui est important donc là on a la même chose sur tous les visuels comment il a converti les visuels qu'est-ce qu'il a comme dimension et comme mesure sur chacun des visuels vous avez les informations et ensuite pour chaque rapport il va vous générer le Power BI project, donc la partie rapport, la partie modèle sémantique, la partie power query là c'est juste pour information si on veut l'extraire ou mettre dans un gène 1 ou gène 2, on peut aussi directement le faire. Et le dernier c'est la partie data. Voilà, on crée aussi un dossier data. Pourquoi ? Parce que dans tableau, vous pouvez stocker dans un document tableau directement soit des fichiers Excel, soit des fichiers hyper. Donc en gros, c'est un peu des fichiers compressés, un peu comme des modèles sémantiques. Dans ce cas-là, en fait, il va générer euh un fichier CSV correspondant à l'hyper file et comme ça on pourra le réintégrer directement dans Pouvoir Bill. Donc là, je suis en train d'ouvrir. Ce que je comprends, c'est que tu as deux modes. Soit tu as des connexions directes qui étaient dans le tableau euh vers des des euh backend type bah big query ou n'importe quelle base de données. Donc là, il va aller migrer les connexions tout seul. Et par contre quand le fichier est dans l'hyperfile qui est le format propriétaire de tableau, il va faire des extractions vers un format compréhensible par PowerBI. C'est ça. C'est ça. Et du coup le charger en mode import, ton power query va passer en mode import dans ce cas-là. Voilà. Dans ce cas non, en fait ça dépend des sources. Les sources si eux ils étaient déjà en en normal, il va rester tel quel et sinon il va le changer. Effectivement là c'est vraiment au choix des utilisateurs de ce qu'il va mettre en place. Donc là, il y a pas de c'est vraiment vous qui choisit. Donc une fois qu'on a ouvert le Power BI qui a migré, on a juste à ouvrir le power BI, on met à jour les données. Il a même migré les données. Donc on a plus qu'à faire un refresh du rapport power BI. Là, comme vous voyez, voici ce qu'il a produit. On est assez proche euh de l'équivalent côté tableau. Donc, il a récupéré les images, les noms, les noms des objets et cetera. il a même créé des calculation group parce que comme vous voyez ici, ici on est lié à des calculation group les a recréé et cetera. Là où il y a une petite différence que vous voyez c'est que bon déjà il a repris la mise en forme, on est pas mal. Le point c'est que il a créé il y a un visual custom côté tableau qui n'existe pas côté power bi qui de se dire bah oui c'est comme si j'avais une image de mes joueurs et des éléments. Donc là actuellement elle est juste mis en multicard. Encore une fois les tout est donné ont été immigrés, le rapport a été immigré, la mise en forme a été immigrée. Certains visuels ont toujours un peu de drift par rapport 90 % du job quoi. Il a fait 90 % du job. Maintenant bah vous ajustez. Voilà, ça qui est important juster. Là où c'est plus intéressant, c'est vraiment pour les rapports où il y a assez peu de customisation côté euh tableau qu'on voyez ici celui-ci. Donc vous voyez même les noms euh des visuels 11 étaient un peu customisés en terme de de police. Ils ont été mis en grâce. sur ligne et cetera. Et voici le pendant côté power BI donc qui reprend encore une fois la même chose, la mise en gras a été mis au milieu. On est quasiment identique en terme de visuel. Donc ici en plus il a ajouté les informations custom mais on pourrait les supprimer par rapport au tableau. La seule petite différence étant le slicer ici c'est qu'ici il me l'a mis en mode dropdown alors que côté tableau, il est pas en drop en dropdown mais on a plus qu'à modifier. Et comme vous voyez au final, il a fait allez dans ce ce cas-là peut-être 98 % du boulot. Mise en forme les mêmes typologies de visuel. J'ai juste à changer deux choses côté power. 1 pas ici je suis en pas de temps jour au lieu du pas de temps mois dans tableau. Donc ça j'ai plus qu'à changer le pas de temps. Et ici le format, je change de dropdown à un élément global comme ça je sélectionne et c'est fini. Voyez ? Il a migrer les données, le rapport donc le TMDL, le modèle, les liaisons, les mesures d'axe, les visuel. Maintenant, j'ai plus qu'à publier sur Ouais. Le modèle, il est déjà finalisé. Il y a les bonnes relations, il y a tout, le DAX, il y a les formules s'il y a besoin, tout est fait. voir le modèle de données de que cel il est assez simple voyez cel il est assez simple par que c'est les deux tables qui sont autoliées mais sinon il a il a tout généré le seul point important sur ce type d'outil c'est qu'on a essayé de poser au maximum le fait que les coines calculés dans tableau on peut faire beaucoup de coines calculés là on peut faire la même chose côté power bien mais on sait que c'est moins performant donc en gros on a modifié les colonnes calculées pour les pousser dans le power query pour en fait faire qu'au maximum tout soit près calculé dans le power query le modal est fait vous avez les liaisons et ensuite bah vraiment la partie mesure tiens uniquement pour les calculs voilà plus du tout de col calculé c'est un peu ça la petite différence qu'on a fait en terme d'optimisation donc l'outil fait aussi des optimisations entre tableau et powerbite pour maximiser le fait que tout ce qui est calcul se fait dans la partie power collect là tu nous parl vas-y vas-y vas-y non je t'en prie je t'en prie vas-y tu non parce que après moi je suis curieux de là tu nous parles d'un d'un pyon que tu as créé toi hein et que tu offres gratuitement dans un guitupos aitory. Mais ce que je pense intéresse tout le monde, c'est comment tu as fait ça et combien de temps ça t'a pris. Alors celui-ci ça m'a pris 2 semaines à peu près. Alors c'est pas de semaines à temps plein c'est encore une fois en vibe coding vous posez une question il va peut-être travailler pendant 15 minutes avant d'er un retour. Donc ça qui est intéressant. Moi je peux le faire à longueur de journée, je joue avec et cetera. Donc ça m pris à peu près 2 semaines. En 3 jours, j'avais quelque chose qui était viable donc principalement sur quasiment toutes les fonctionnalités. Et ensuite, j'ajouté pas mal de fonctionnalités additionnelles. En fait, encore une fois, c'est que au début, on a la baseline, on a un tableau vers Power BI. Là où j'étais plus loin, c'est pour la partie visuelle. Voilà, on a ajouté les visuels au fil de l'eau. 1 partie modèle sémantique. En fait, on a aussi une option pour fusionner des modèles sémantiques. Donc, en gros, si on a mis plusieurs rapports tableau, il va aller vérifier le contenu des modèles. Et s'il voit qu'il y a plusieurs tables qui sont identiques à plusieurs modèles, ben il va vous proposer de créer un seul modèle sémantique. Là, il y a aussi de l'optimisation en terme de modèle. Et le dernier qu'on a aussi ajouté, c'est sur le fait que bah on peut déployer sous forme fabrique. Dans ce cas-là, on aura des notebooks, des data pipeline, des data flow, un houseous et un rapport power bi en direct leck. Ah oui, début, on a fait la baseline. Voilà, on a fait la baseline qui était juste tableau vers PowerBi. On a essayé d'ajouter le maximum de visuel, le maximum de requête d'axe au fil de l'eau. Ça qui est important, c'est de le faire évoluer encore une fois. Après, on a ajouté la partie fusion des modèles sémantiques et ensuite on a ajouté la partie bah le fait qu'on peut migrer sur format fabrique pur. Voilà. Et donc ce qui est important c'est que même vous vous pouvez prendre ce ce Python et le faire évoluer chez vous. Comme j'ai soin des clients, c'est ce que j'ai présenté en live à un client. B on l'a exécuté sur un de ses rapports tableaux, il avait une erreur. J'ai fait un screenshot, j'ai mis le screenshot directement ici dans le compte, il a corrigé. 2 minutes après, il a on l'a réexécuté. Le rapport de tableau verbi était fonctionnel. C'est ça aussi la magie du truc, c'est de se dire oui, c'est un outil. Oui, il va peut-être faire 80 % du boulot, mais il peut encore avoir des erreurs. Mais le but, c'est qu'on utilise, on continue à utiliser le V coding pour corriger l'outil par rapport à un contexte client. Moi, je l'ai fait sur une dizaine vingtaine de rapports différents, mais il y a des chances que peut-être vous avez des cas particuliers et le but voilà, c'est qu'on dise on continue à utiliser GP Cop pour corriger et faire évoluer cet outil. C'est dire que le client en question doit du coup télécharger ton RIPO, se mettre sur VS Code et là utiliser Gitup Copilot finalement pour améliorer ou ajouter des feures à l'outil. Ouais. Et pour moi c'est vraent ça la différence du VA coding par rapport à un outil qu'on acheté clé en main ou avant on acheta un outil clé en main. Ça marchait tant mieux ça marchait pas bah

19:06tant pis fallait faire la main. Voilà c'est un peu ça le sujet là. Maintenant, ça marche pas en fait, il va se corriger de lui-même en fait pour que ça marche à la fin. C'est ça qui est intéressant et c'est là où le gain de temps est important. C'est un on gagne du temps parce qu'on crée un outil qui existe pas sur le marché en tant que tel assez rapidement. En de tr jours, on a un truc qui fonctionne si on allit plus loin sur partie industrielle, déploiement et cetera parce que là l'outil peut aller directement récupérer dans tableau tout migrer et directement pousser dans online sans geste manuel. Ça il peut le faire. Voilà, c'est c'est une possibilité. Mais après ce qui est important c'est de se dire s'il y a une erreur ben en fait il va se corriger et c'est là où on gagne du temps. Quel est le premier prompt que tu as utilisé pour créer cette solution ? Imagine demain j'ai j'ai une autre solution que je dois migrer vers Power BI. Par quoi je commence ? Moi je demande toujours de défier un plan un plan de migration et de se dire bah quels sont les éléments dont il a besoin pour mirer par exemple de tableau vers pour BI ou de microstratégie vers pour BI. il va vous générer un plan, il faut lire le plan pour bien l'appréhender et c'est là où vous pouvez être critique en fait et c'est là où vos connaissances sont importantes. C'est de se dire "Bah non, peut-être il manque ça, peut-être qu'il manque ça, et cetera." Et une fois qu'on a le plan d'éventement, on lui demande de créer plusieurs agents pour que chacun a des tâches particulières et ensuite on vérifie bah le plan de développement. Donc là, c'est vraiment de se dire bah combien j'ai de tâches qui arrivent, combien j'ai de phases de développement, est-ce que les phases sont liées à notre besoin. Comme ça, on peut se dire "Bah tiens, fais rapidement un prototype qui est fonctionnel peut-être sur 10 % 20 % euh de l'outil et ensuite on améliore." Ça qui est intéressant. Et ensuite on itère. Voilà, il fait la première phase, on peut tester, on vérifie avec lui si c'est OK ou pas. Si c'est pas OK, bah il va continuer itérer sur la phase actuelle et après si c'est OK, bah on passe à la phase suivante et cetera. Et on fait ça que dans une seule interface qui est celle que tu nous montres dans VS qui est celle-ci. Voilà. Et puis en fait, il peut même tout faire. Moi à un moment donné quand j'étais en phase de test, il faisait la migration pour moi. Il faisait des évolutions sur l'outil, il faisait la migration et ensuite il m'ouvrait le rapport pour avop. Donc j'ai même pas besoin d'ouvrir le rapport pour desktop. Il le faisait pour moi et si j'avais un message d'erreur, j'avais juste à faire un copier d'écran, je collais, c'était fini. Il me fermait à nouveau le power bi desktop, il refisait ses corrections et il m'a réouvrit le rapport power bi. Voilà, c'est comme ça que j'ai fonctionné. et ça a été assez vite. Un point important justement, tu dis il t'ouvre il t'ouvre PowerB desktop et cetera. Est-ce que ça c'est quelque chose qu'il faut que tu lui spécifie parce que de enfin c'est ce qui fait peur aussi dans les agences se dire bah il va prendre la main sur ton poste et puis il va commencer à tester des choses et cetera. Est-ce que c'est toi qui lui définit le degré de liberté qu'il va avoir sur sur ton ordinateur finalement pour faire toutes ces ces phases de test ? Oui parce que par défaut en fait il a pas le droit de par exemple d'exécuter du du Power Shaell, d'exécuter des streets et cetera. En fait, c'est vous qui autorisez. Donc vous allez pouvoir dire bah tiens peut-être juste pour cette session en cours. Donc quand j'ouvre mon visual studio, est-ce qu'il a le droit d'accéder à des dossiers ? Est-ce qu' a le droit deer des outils ? Est-ce qu'il peut exécuter strip shell ? Donc ça on a le droit de l'autoriser ou l'interdire. Voilà. Et ensuite c'est juste que moi j'ai créé un module qui s'appelle l'autoplay. Et l'autoplay qu'est-ce que c'est ? Bah en fait il exécute pour moi l'ouverture d'un rapport pour desktop. Mais effectivement faut que je l'ai autorisé au fait qu'il peut se connecter au dossier où il y a power pour B desktop et qui peut exécuter PowerB desktop. Donc vous avez la main sur oui ou non, est-ce qu'il exécute telle ou telle l'activité ? Ben justement, est-ce que tu peux nous montrer un cas d'exemple où tu as eu une erreur et justement qu'est-ce que tu as fait pour améliorer ton ton script ? Oui. Et ben c'est simple. Regardez, j'ai fait exprès d'avoir une erreur dans mon power, je vais l'ouvrir. Ici, j'ai une erreur assez classique des problèmes de TMDL et cetera. Dans ce casl je m'embête pas à copiercoller le code. Je pourrais copiercoller le message un screenshot. Je copie, je copie. Je vais dans mon visio code. Je dis juste error parce qu'on peut pas juste envoyer une image et c'est parti. Et là, vous allez voir, il va commencer à travailler. C'està dire, il va aller lire le message d'erreur, il va essayer de comprendre et ensuite il va essayer de trouver où cette erreur a pu être générée dans le code. Ça qui est important, c'est toujours cette compréhension de se dire bah je vais comprendre le code, je vais comprendre ce que j'ai fait comme élément. Voyez là, il commence à travailler. Voilà, là il voit qu'il y a une erreur dans la partie calendar. Donc il a retrouvé le bon élément et cetera et là il va commencer à analyser tout ce qui se passe. Donc là c'est une partie de description et il a raison ce que je suis en train de faire monter de version pour prendre en charge les description des champs parce que je fais je mets à jour le PowerBi report pour bi le TMDL il a je tes descriptions mais elles sont pas encore disponibles sur cette version de TMDL. Donc là il va commencer à mettre à jour cet élément là donc se dire bah est-ce que je fais une montée de version TMDL de Probl Project en tant que tel ou est-ce que je supprime une description des description. Vous voyez là, il a compris TMDL, il supporte pas les descriptions. Donc là maintenant, ben soit je lui dis bah en fait supprime-moi les descriptions, soit je vais lui demander de créer ou mettre à jour le l'avant monter de version de PowerB project mais de base ce qu'il va faire c'est qu'il va le supprimer je pense. Voilà donc vous voyez là il va corriger le code en tant que tel pour pouvoir réexécuter mon power desktop. Je n'ai rien à faire. Message d'erreur. Il voit où est l'erreur, il vous explique l'erreur en tant que telle et laissez le faire. Voilà. Là, il fait un river parce que je je lui demandé juste avant de d'aller plus loin. Il fait un revers de ce qu'il a fait et maintenant il va me faire les corrections. Ensuite, il peut selon si on demande refaire la migration pour moi. Il va me réouvrir le power bi desktop où je l'ouvre manuellement et je vais pouvoir vérifier que ça a été corrigé. Puis il te génère une nouvelle version de ton euh ton gén et que tu pourras après réexécuter. Donc tu peuxécuter. OK. Et ensuite comme à chaque fois je demandé dans mes instructions de faire des tests comme vous voyez à chaque fois j'ai des tests. Voilà. Il modifie tel ou tel street, j'ai un certain nombre de tests relatifs à chacun des scripts. Pourquoi ? C'est des tests sûr que ça peut être exécutable, qu' a pas de régression et cetera. Ça c'est important, c'est que j'en ai pas parlé avant, c'est toujours lui demander d'effectuer des tests en fait. Et dans tous les cas, dès qu'il fait une modification de code, il fait les tests pour pour être sûr que ce soit exécutable et des tests de non régression. Donc là, il va faire ses corrections comme je dit, ça peut prendre du temps. C'est ça qui est important avec le VA coding. C'est comme c'est lui qui travaille, on lui met le message d'erreur. Pendant ce tempsl, moi je peux travailler de mon côté, je ne fais rien. Ça prend du temps mais c'est pas le tien. [rires] C'est pas le mien. Voilà, ça le point c'est que honnêtement de vous à moi, je peux me le faire en réunion ou autre chose, c'est que bah oui, corrige, il se corrige, je reviens, je reviens, non mais je reviens 5 minutes après, je vois qu'il a corrigé, je peux jouer avec. Voilà, c'est ça qui est intéressant, c'est que bah on n'est pas bloqué par cette tâche là. Alors qu'avant on était bloqué. C'était nous qui faisons le test, on on buit la solution, on ouvrait, on testait, on était obligé de modifier code. Là non, je mets le screenshot, il travaille tout seul, je reviens 5 10 minutes après et c'est fini. Une une question que que j'ai parce que justement tu parlais de temps, [grognement] euh je mets la place du client qui a une centaine de rapports à migrer pour dans le cadre d'un passage de tableau à à à PowerBA. Est-ce que tu peux batcher ou tu conseilles vraiment de faire de l'unitaire ? Comment tu vois le les choses ? Non, on peut mettre en batch honnêtement. Moi, j'ai testé au début, on fait du unitaire euh c'est intéressant, maisant on peut faire en batch de façon l'outil par exemple sur c il prend en batch et c'est quand même beaucoup plus rapide. Et ce qui est intéressant le batch aussi c'est en fait plus lui là d'exemple plus il sera performant. Voilà parce qu'il saura comment faire. Par exemple dans des cas sur la partie NBA, il y avait des calculation group, il en a assez peu dans des rapports. C'est pour ça que là il y a eu un cas avec calculation group. Donc du coup, il a créé des fonctions pour migrer en calculation group et ça va servir pour tout le monde. Ça que plus on a d'exemples, c'est comme à l'époque de de l'IA, les documents et cetera. Bah là, plus on a d'exemples de rapport, plus on aura de fonctionnalités possibles migrabl. Voilà, parce que calculation group de base, il savait pas, il savait pas le faire. Jeis pas demandé mais moi j'is pas demandé donc il connaissait pas. Et là et avec ce rapport là spécifique, il a ajouté la partie calcul groupe. Donc non, si vous pouvez faire du batch, c'est mieux. Donc peut-être que oui, ça prendra un peu plus de temps à se corriger, mais au moins vous serez vraiment plus performant et plus de fonctionnalités seront couvertes par l'outil. Et tu as ton rapport qui il génère tout seul son rapport de migration. C'est ça que tu as montré tout à l'heure l'HT. Ça qui est important. Voilà, dans tous les cas, il y a rapport de migration et comme je dis, il sert de deux manières, hein. C'est euh bah se dire bah qu'est-ce qu'il a fait en tant que tel ? Il est ici. Qu'est-ce qu'il a fait en terme de migration et ça permet aussi de contrôler. Voilà, ça vous permet de savoir bah qu'est-ce connecteurs, qu'est-ce les types d'objets associés. Donc des calculation group, des visuels et cetera. Et pour moi, ce comme je disais, ce qui est important, c'est aussi la partie d'act. Voilà, la partie d'Ax oui, il fait la conversion de la partie tableau en DAX, mais après vous pouvez quand même contrôler et comme je dis, voilà, tout ce qui est quand même calculé. Ouais. Voilà. Et ça qui c'est que même vous pouvez contrôler, c'est de se dire bah je peux ouvrir juste mon rapport PowerB et même encore une fois je pourrais migrer moi-même. Et ce qui est intéressant, c'est qu'il m'a déjà fait la conversion d'axe. Donc si je veux, je peux migrer moi-même le rapport tableau vers le refaire de zéro. Mais au moins il m'a déjà fait une grosse partie qui est le DAX. que le DAX çait peut rester compliqué selon certaines formules. Là au moins j'ai les éléments qui sont à disposition. Donc il fait l'assess en gros c'est un rapport de migration et

27:35d'assess et vous avez toutes ces informations là. Voilà. Donc même si ça a planté au moins il peut faire les corrections. Voyez bah voilà là il me l'a il l'a fini. Il m'a dit qu'il a fini corrigé avec peu près 7000 tests en fait sur partie. Là il m'a directement commité sur mon ripo maintenant c'est disponible. Je veux je peux le réexécuter. Je relance et c'est bon. Magnifique. C'est super impressionnant. Merci Pierre. Et justement donc là euh on a fait un focus sur tableau, mais est-ce qu'on sait le faire sur d'autres outils ?

Conclusion

28:02Ah oui, totalement. En fait, ce qu'on ce qui est possible, c'est que maintenant qu'on il sait comment migrer, en fait, on peut répliquer sur tous les outils possibles. Donc là, même moi je l'ai fait sur du clic, sur du microstrat, euh tout ce qui est on va dire euh datavis, on peut le faire. Donc ça va être simple. Il connaît déjà comment il a migré de quelque chose en dash, comment il a généré du TNDL et cetera. Donc on peut reprendre cette intelligence là et dire bah non, en fait c'est pas que tableau, ça peut être du clic, du microstrat et cetera. On peut même le faire sur partie hôtel. Nous, on l'a mis en place sur du data IQ, de l'informatica ou même du SSIS. On peut aussi migrer ça directement dans fabric. Voilà. Donc oui, on peut le faire sur quasiment tous les outils. Donc à la fois pour faire de la migration, voilà, on choisit l'outil source et on essaie de toujours dans la même cible qui est fabrique/p et ensuite on peut aussier pour des accélérateurs. Moi j'utilise beaucoup pour faire des démos à des clients. Comme ça, je pourrais une démo end toend sur un business précis pour un client. il va tout vous créer, les flux datafow, les pipeline, le houseous, même les dates agents, il va tout vous faire tant que la pierre est à disposition dans l'outil par exemple sur fabrique et ben il pourra le créer pour vous. Et ce qui est intéressant c'est qu'on peut pareil pour une démo, on se dire bah oui, j'ai flux total, je veux changer ma démo, ça c'est facile, on va juste lui demander de faire sur un autre élément business, par exemple, de passer d'un élément du livre à des voitures, il va créer les jeux de données, recréer des modèles et même créer les rapports pour ABI. Ce qui est intéressant, c'est que même il va vous créer des rapports pour Bia qui sont intéressants en fait, qui sont lisibles avec des images, des tableaux et cetera sur vos données. Vous avez rien à faire. Il y a même pas besoin de générer des données, il va le faire pour vous. On a plus qu'à laisser travailler quoi pour nous à notre place. Il y a plus qu'à laisser travailler. Voilà. Voilà. Il faut juste avoir l'idée et quand même contrôler. Peut partir en vacances mais il faut toujours le contrôler. Encore une fois, bah il faut le superviser et il faut surtout savoir ce que vous voulez. Comme je dis même sur un accélérateur, bah il faut dire oui peut-être il me faut un date agent, peut-être il faut autre chose. Voilà. et lui, il va peut-être se limiter à à la partie basique. Par contre, vous pouvez bien entendu poser plus de questions pour aller plus loin et ajouter plus de fonctionnalités. Ça c'est important ce que tu as dit. Tu tu as dit contrôler, c'est-à-dire que il faut quand même avoir une bonne connaissance et que finalement euh les gens qui nous regardent, qui nous disent qui se disent bah voilà, on va être remplacé demain et cetera. Mais tu es quand même là pour superviser et il y a ta connaissance qui fait que que finalement tu as réussi à à réaliser ces outils là. C'est ça. C'est vraent les connaissances. Si je connais pas de tableau par défaut, j'aurais pas pu. Voilà, là c'est parce que je connaissais bien un tableau euh de mon ancienne vie. Donc oui, on peut migrer mais encore une fois, on peut commencer sans connaître. C'est juste qu'on aura un outil qui fera peut-être 20 % du boulot de migration. Plus on connaît, plus on sa on connaît les fonctionnalités en sources, les fonctionnalités en cible et plus même nous, on peut l'aider sur le mapping. Voilà, important c'est toujours l'aider et superviser. Lui, il va faire des propositions peut-être elles sont bonnes, elles sont pas bonnes. Peut-être des fois on pourra améliorer en terme de performance, autre chose. Bah, c'est là où on va le guider. Mais ce qui est important, c'est qu'il peut tout faire de A à Z. C'est vraiment ça qui est important. Donc oui, c'est pas juste un prompte qui fera tout. Non, un prompte il va vous faire le plan de développement et cetera et ensuite vous allez avec lui. Mais encore une fois, comme je vous ai montré, même pour un message d'erreur, je lui pousse le message d'erreur, ça soit en copiercollé ou un screenshot, je dis qu'il y a une erreur, il va se corriger lui-même sans avoir lui dit où est l'erreur dans le code. Non non, il va aller trouver l'erreur dans le code, il va se corriger, il va refaire ses tests et après vous pouvez retester directement. Super démo, c'est impressionnant. Vous avez vu, on a fait attention, on a mis les fonds d'écran en fonction. On est vraiment dans le monde du vibe coding aujourd'hui. Euh moi je suis impressionné. Euh je pensais pas que c'était aussi simple de créer des solutions Python qui permettent de migrer tableau vers PowerBI. Euh Marc, tu l'as déjà testeté chez des clients cette solution ? C'est ça. Et j'ai même fait un peu le le beta testeur pour Pierre. Donc moi, j'ai installé, j'ai récupéré le le RIPO, j'ai testé la solution sur des des rapports de certains clients et on peut le faire en live he avec le client en disant bah voilà effectivement bah donnez-nous un rapport, on va le tester. Alors on va avoir comme disait Pierre certaines erreurs parce que bah effectivement il y a des toujours des cas que que l'outil n'a pas de migration n'a pas encore prévu. Mais c'est ça le c'est vraiment ça l'attrait du de de l'outil, c'est de se dire bah Kitup Copilot lui va aller rajouter des feures au fur et à mesure et donc à la fin le client il aura un rapport qui marche. Pierre tu nous partageras le lien du du Rippo et on demande à tout le monde de changer la solution de tester de l'améliorer. Tester pouvez l'améliorer et ce voilà c'est prenezla chez vous pouvez continuer guitable copilot pour la faire évoluer par rapport à votre contexte. Voilà, ça qui est intéressant, vous allez voir, il va se corriger tout seul et il va s'améliorer et ça évite les actions manuelles. Et comme on a vu bien entendu, il y aura toujours les actions manuelles pour remettre en forme certains visuel et cetera, mais c'est déjà 90 % du boulot est fait, on gagne pas mal de temps. Ouais. Bah, en tout cas, si vous avez des questions, des retours d'expérience, n'hésitez pas à nous les mettre en commentaire. On vous dit à très vite sur la chaîne Fardata pour un nouvel épisode. D'ici là, abonnez-vous à la chaîne. On vous dit à bientôt. Merci. Sí.