Discussion :

[jpf991]

Bonjour à tous,
Je suis novice dans le domaine de l’informatique décisionnel, et je fais actuellement un stage qui devrait me permettre d’apprendre dans ce domaine tout en aidant l’entreprise (à but non lucratif) à lancer ce projet. Cependant il n’est pas toujours évident de trouver des réponses à mes questions sur les différents forums et personne n’est capable de répondre à mes différentes questions dans le département informatique où je me trouve. Je me permets donc de poster sur ce forum en espérant que quelqu’un puisse m’aider.
Présentation du projet :
Mon stage s’effectue dans une clinique, qui se sert de différents logiciels qui sont principalement un ERP, un logiciel de dossier patient informatisé, et un logiciel de planification des rendez-vous. Il y a 3 ans, un projet a débuté avec une entreprise externe qui a réussi à vendre Qlikview mais sans mise en place d’un datawarehouse ce qui nous donne des dashboard uniquement branché sur l’ERP, pas toujours corrects, et surtout très compliqués à améliorer.
J’ai donc proposé de faire une preuve de concept avec la mise en place d’un datawarehouse (pour l’instant sur SQL Server Express), alimenté par un ETL (Talend), et je pense utiliser PowerBI comme Dataviz.
Le premier datamart que je dois mettre en place concerne l’activité de l’entreprise qui se mesure en nuit passé par le patient. Je souhaite donc faire une table de fait avec une ligne pour chaque nuit passée par un patient, car des informations peuvent changer au cours d’un séjour comme le médecin traitant etc… Mon fait est donc une date mais je souhaite également les filtrer et les afficher par date qui ressemble ainsi une dimension, qui de plus pourrait me servir à d’autres endroits (ex : date de naissance d’un patient).
Mes questions sont donc les suivantes :
Modélisation :
• J’ai vu plusieurs exemples ou les personnes utilisent pour la date une clé de type yyyyMMdd. Dois-je donc le faire pour toutes mes dates et donc avoir une dimension date qui peut être utilisé par ma table de fait mais aussi par une table de dimension patient contenant la date de naissance ?
• Est-il simple de faire des count pour la visualisation ? Ou dois-je ajouter dans chaque ligne une colonne avec une valeur de 1 pour faire des sommes ?
Architecture :
• J’ai entendu que Microsoft essaye de pousser les gens à utiliser du tabular au lieu de cubes OLAP. J’ai donc cherché malheureusement sans trouver quels sont les avantages et les limites de chacun de ces « systèmes » ?
• PowerBI est-il uniquement prévu pour du tabular ?
• Pour le logiciel de visualisation, la différence de qualité (vitesse et facilité d'utilisation) est-elle grande entre QlikView et PowerBI ? (Car l'a différence de prix l'est clairement...)
• Au niveau du datawarehouse, quel sera ma limite avec SQL server Express qu’est-ce que vous me conseillez ? Car j’ai entendu que MySQL n’est pas forcément fait pour du multidimensionnel ?

Merci d’avance pour votre aide et n’hésitez surtout pas à me dire si je suis un peu (voir complètement) à côté de la plaque…

Cordialement,

Julien

[nuke_y]

Bonjour,

faire le choix de remplacer Qlikview par un DWH + Power BI quand on ne connaît aucun des 3 me semble... audacieux

Pour information il est possible de faire un DWH intégralement en Qlikview. Cette solution n'étant pas fiable à mon goût, je ne vais pas troller en la conseillant mais elle existe. A noter aussi que si vous n'avez pas de DBA SQLServer, utiliser SQLServer Express pour un DWH ne sera pas plus fiable que le faire intégralement en Qlikview.

En soit sur l'architecture proposée:
- SQLServer Express : très bien, bien mieux que MySQL pour de la BI (SQL partiellement implémenté, il manque des opérateurs ensemblistes, index, etc.). Reste le potentiel problème de la volumétrie selon le volume de données à traiter.
- Talend : bon choix, en partant sur du SQLServer en BDD vous auriez pu prendre SSIS (pas en version Express) mais Talend ne sera pas le maillon faible
- PowerBI : très en dessous de Qlikview en termes de fonctionnalités d'analyse mais si Qlikview a été mal utilisé et que vous jouez sur les possibilités d'intégration de PowerBI, ça peut être un choix valable.

En vrac sur les autres points:

- Si vous êtes sur un POC ne vous prenez pas la tête à modéliser parfaitement dans les règles, surtout les dates. Une date peut rester en tant que champ dans un datamart sans que le dieu de la BI ne vous foudroie.

- Count(...) ou sum(1) ça dépend de votre outil. Normalement le sum(1) est à proscrire car il n'a aucune valeur fonctionnelle et ne doit être utilisé que pour des raisons techniques. Donc si techniquement votre outil demande un sum(1) pour des raisons de simplicité ou d'efficacité, il ne faut pas hésiter. A noter que sum(1) ne marche pas sur les dimensions dans un modèle relationnel alors que dans un modèle associatif (Qlikview) si.

- Tabular vous permet de gagner en temps de calcul "back-office" puisque contrairement aux cubes chaque cellule n'est pas pré-calculée. Par contre il réclame plus de ressources à l'utilisation et il faut une bonne technologie (Qlikview par exemple) pour l'exploiter sans problème de performances. Si vous faites des datamarts Tabular est probablement "suffisant".

- Normalement PowerBI peut consommer des cubes OLAP SSAS mais sur SQLServer Express je pense que vous n'avez pas SSAS dans la version Express (mais ça a pu changer récemment) donc la question ne se pose pas.

- La différence entre PowerBI et Qlikview est gigantesque, comme comparer une brouette avec un engin de chantier à 10 M€. Bon si c'est pour transporter 2 m3 de feuilles mortes, il vaut mieux utiliser une brouette bien entendu donc ça dépend du besoin, et selon le besoin il vaut mieux PowerBI. Mais il y a une vraie raison à la différence de prix.

- SQLServer Express, en dehors de petits projets étudiants et de l'auto-formation, je ne le conseille pas. Il y a de vraies limitations en termes de RAM et de volume qui sont vraiment casse-pied pour de la BI. Je ne connais pas vos volumes cependant, donc si vous devez gérer moins de 100 000 lignes ça doit passer sans souci. Mais j'ai déjà constaté que dans le médical il peut y avoir de gros volumes pour un métier "simple" (1 journée de séjour -> 100 lignes d'actes de soin, ça peut vite faire exploser les volumes).


Bonne chance

[jpf991]

Bonjour,

Tout d’abord merci beaucoup pour votre réponse et votre aide.

Concernant QlikView, l’entreprise de consulting l’a vendu à notre département finance (en 2013) avec en principe 6 tableaux de bords opérationnels pour un prix d’environ un jour de travail par tableau. Sauf qu’aujourd’hui, un seul tableau de bord fonctionne et encore pas complètement. Entre temps, ils ont complètement refait leur architecture avec un DWH et un ETL au lieu de n’utiliser que QV. Cependant le prix de leur nouvelle proposition est inabordable pour une entreprise à but non lucratif, et mes collègues auront du mal à leur refaire confiance… De plus l’objectif étant de préparer des données pour différents départements de l’entreprise, l’achat d’une licence QV par utilisateur me semble vraiment excessif pour des utilisateurs qui ne faire que regarder quelques dashboards de temps en temps.

Existe-il des concurrents de QlikView au niveau des modèles associatifs ? Pensez-vous qu’ils vont être amené à remplacer les cubes à terme ?

Pour SQLServer, le POC est prévu sur le Express pour ne pas faire d’achat immédiat, mais l’achat d’une licence est envisageable.

Concernant PowerBI, je n’arrive pas à comprendre pourquoi le Magic Quadrant de Gartner place Microsoft en premier alors que PowerBI n’est qu’une brouette… Cette brouette n’est-elle utile que lorsque tout le reste de la suite Microsoft est utilisé ?

Pour finir, je suis conscient que je n’ai ni les connaissances ni l’expérience nécessaire à la mise en place d’une telle infrastructure. Cependant, je n’arrive pas vraiment à trouver de formation dans ce domaine, mis à part des certifications des logiciels, qui (en plus de te marquer d’une étiquette de leur produit) sont généralement accessibles pour les personnes avec une certaine expérience dans l’informatique. C’est pourquoi j’essaye de prendre de l’expérience en essayant d’aider cette entreprise en même temps…


Cordialement,

Julien

[nuke_y]

Je dirais que l'entreprise de consulting a raté son coup, 1j par dashboard c'est insuffisant, même sur de l'intégration d'un produit existant. Enfin c'est suffisant pour que "ça marche" mais pas pour que les utilisateurs en aient la maîtrise, ce qui revient au même au final.

Il n'y a pas de concurrent Qlikview avec un modèle associatif, seulement des modèles pseudo-associatifs et souvent payants aussi. Qlikview et les autres technologies in memory ont déjà remplacé les cubes dans la majorité des cas d'usage. Il reste quelques cas où les cubes sont à privilégier, mais c'est un débat d'expert.

Le Magic Cadran du Gartner hein ? Bon je dirais rien de plus mais il ne faut surtout pas baser un choix d'architecture là-dessus. Le vrai gros problème de PowerBI c'est que tout le monde en parle mais personne n'en fait. Et que ceux qui en font vraiment rencontrent tellement de limitations qu'ils n'osent plus en parler. C'est quand la dernière fois que vous avez lu un article expliquant comment PowerBI avait révolutionné la BI d'une entreprise ? Des pro-microsoft j'en connais plein. Des pro-microsoft qui sont content de PowerBI je n'en connais pas, et pourtant j'en cherche pour avoir un vrai débat factuel parce que j'aimerais beaucoup pouvoir proposer du Microsoft dans les architectures BI que je conçois.


Pour revenir à votre sujet, j'ai déjà fait mes remarques sur les briques logiciel envisagées, je ne pense pas que ce soit stupide de partir sur SQLServer Express + Talend + PowerBI pour un POC, seulement un peu audacieux vu votre niveau. Au pire ça vous fera de l'expérience. Allez-y, surtout soyez pragmatique et pensez toujours à l'utilisateur avant d'essayer de respecter l'état de l'art et faites-nous un retour d'expérience sur PowerBI. Bonne chance

[jpf991]

Bonjour,

Je suis bien d'accord pour l'entreprise qui malheureusement a préféré avoir le contrat quitte à faire du travail bâclé...

Pour le reste je vous fais confiance, vous êtes l'expert et moi un simple débutant.

J'ai tout de même une question par rapport à ces histoires de dates qui me perturbent... En effet, j'ai créé une dimension date qui est donc rattaché à ma table de fait, qui contient chaque journée de présence et donc un champ date. Cependant, j'ai une dimension séjour qui contient les informations qui ne changent pas par rapport au séjour (provenance, date d'entrée etc...), mais malheureusement, je ne peux connecter ma table date à cette dimension puisqu'elle est déjà rattaché à ma table de fait.
Comment dois-je faire ?

- Mettre ma date d'entrée dans la table de fait quitte à ce qu'elle soit répété pour chaque jour ?
- Créer une deuxième table de dimension date qui sera uniquement rattaché à la dimension séjour ?
- Autre méthode ?

Merci encore pour votre aide,

Cordialement,

Julien

[nuke_y]

Sauf contrainte technique (comme on peut en trouver sous Qlikview) il n'y a aucune raison de vouloir mélanger les 2 notions fonctionnelles:
- la date d'entrée
- la date d'1 journée de séjour
Ce sont 2 informations différentes et donc elles devraient avoir leur propre colonne dans les tables et leur propre table de dimension.

Ensuite si on parle de bonne pratique, il faut effectivement redescendre la date d'entrée dans la table de faits et ne pas la laisser dans la table de dimension Sejour. Car si on a 1 table de faits reliée à 1 table de dimension Séjour qui elle même est reliée à une table de dimension Date d'entrée, ce n'est plus un modèle en étoile mais en flocon.

Donc question : voulez-vous absolument faire un modèle en étoile?

• Oui: il faut redescendre la date d'entrée dans la table de faits
• Non: laissez la date d'entrée dans la table Sejour (et vous aurez un flocon)

Ensuite, vu que la dimension date est générique (ou presque, il peut y avoir des cas particuliers mais là on va dire qu'un calendrier peut être générique), est-il bien nécessaire d'en faire 2? Donc vous pouvez n'avoir qu'1 seule table calendrier et l'utiliser à la fois pour la dimension Date de séjour et la dimension Date d'entrée, en faisant un alias SQL voir des vues pour avoir la même table physique mais 2 entités différentes sans alias.

Donc en résumé:
- 1 seule table calendrier convient
- A vous de voir si vous préférez faire simple en flocon ou "propre" en étoile. Personnellement je n'ai pas plus d’appétence que ça pour l'étoile mais bon...

A noter que tout ce que je viens de dire est à mettre à la poubelle si vous avez des contraintes techniques liées à l'outil de restitution qui vous oblige, par exemple, à avoir 2 tables physiques différentes pour les 2 dates.

[jpf991]

Bonjour,

Merci pour vos réponses pour la question des dates.

Voici de nouvelles questions concernant l'architecture désormais :

Avez-vous déjà entendu parlé du Late-Binding Data Warehouse et de son architecture/schéma apparemment (d'après l'entreprise qui la propose aux Etats-Unis: HealthCatalyst ) novatrice et efficace ? Mes connaissances sont vraiment trop limité pour me rendre compte des qualités de cette architecture et de sa faisabilité.

Avez-vous rencontrez des difficultés de modélisation en Schéma Classique (Etoile/Flocon) lors de vos expériences dans le médicale ? En effet, ma modélisation actuelle ne me semble pas assez propre pour être la base de ce projet.

Mon architecture actuelle :

Dimension Patient : toutes les infos relatives au patients qui ne changes jamais.
Dimension Date : classique.
Dimension Séjour : avec toutes les informations qui ne changent pas en cours de séjour
Table de fait présence : chaque journée de chaque séjour avec les FK vers les dimensions, et les infos qui sont à même de changer en cour de séjour (médecin, chambre etc...)

Merci d'avance pour votre aide,

Cordialement,

Julien

[jpf991]

Re-bonjour,

En plus de mes question d'architecture j'ai une question de méthodologie.

Est-il possible d'utiliser une méthode Agile pour mettre en place un Datawarehouse, ou cette méthodologie ne s'applique t'elle qu'une fois que l'architecture a été mise en place ?

En effet j'ai l'impression que faire l'architecture que pour une demande de rapport ne permettra pas de rendre le tout assez "Agile".

Merci encore d'avance,

Cordialement,

Julien

[nuke_y]

Bonjour,

les méthodes de DWH agiles existent, personnellement je n'utilise plus que celles-là (j'ai même écrit la mienne) et mon organisation aussi, mais elles ont de gros défauts:

- impossible d'établir un planning et de s'y tenir: il va forcément changer avec les besoins, c'est normal mais pour le DAF qui a commandé un "DWH" livré dans 6 mois, c'est pénible,

- difficile d'estimer un coût, on bascule alors en design to cost,

- le dispositif doit rester cohérent tout au long du projet au risque que le résultat soit un bazar pas possible: imaginez un emménagement d'une grande famille dans une grande maison mais toutes les heures, vous changez les personnes qui font l'emménagement, et imaginez le résultat,

- il est dangereux de poser des bonnes pratiques très (trop) détaillées de modélisation (ou même technique), car les problèmes se découvrent au fur et à mesure et les solutions à utiliser doivent être trouvées au fur et à mesure aussi. C'est moins vrai avec une équipe très expérimentée et habituée à travailler ensemble. Exemple: on décide d'un quadrigramme (ABCD) qui identifie de manière unique chaque table de faits, il DOIT correspondre aux 2 premières lettres du domaine et aux 2 première lettres du fait. On a un fait FInance CHarge et un fait FInance CHarter. Les 2 devraient s'appeler FICH mais ce n'est pas possible. Bref on se retrouve soit à violer la règle (FICH pour la 1ere et FICT pour la 2e) soit à renommer le 2e fait de "FInance CHarter" à "FInance IN charter" pour avoir un quadrigramme "FIIN". Donc pendant 10 ans on aura une table de faits nommée "bizarrement" juste à cause d'une norme trop précise et inadaptée.

- on doit faire un choix : soit une qualité moindre, soit accepter de régulièrement tout casser et tout refaire différemment parce qu'on a découvert un nouvel élément qui change tout.

- l'agile part souvent d'expression de besoin business, dans le cas d'un DWH le business est rarement en mesure d'exprimer un besoin sur le DWH en lui-même, au mieux des NFR (non-functional requirements) qui vont être prises comme des contraintes mais pas vraiment un besoin. C'est comme l'organisation d'un repas de mariage: les mariés expriment des besoins au traiteur, mais la manière dont il organise sa cuisine le regarde, sinon on tombe dans l'ingérence. Donc agile dans un DWH c'est assez compliqué. De plus l'agile est souvent "test-driven" et dans la BI, le test-driven c'est assez compliqué à mettre en place, il faut des intervenants vraiment expérimentés ou des experts côté client.


Pour votre projet ne vous posez pas la question du futur, surtout pas. Vous n'avez pas assez de compétence pour le faire "bien" du 1er coup de toutes façons, donc soyez pragmatique et pensez avant tout au bénéfice pour le business. Énormément de solutions BI de belle taille ont commencé avec un simple datamart, efficace, puis ont été refondues pour donner un "vrai" DWH. N'oubliez jamais que la BI, contrairement à d'autres solutions, a une durée de vie faible et peut disparaître du jour au lendemain si ce n'est pas jugé assez utile. J'ai déjà vu des solutions BI utilisées depuis des années s'arrêter d'un seul coup parce que ça "ne marchait plus" à cause d'une simple mise à jour logicielle Windows, et ne jamais redémarrer parce que l'effort qu'il aurait fallu pour les remettre en route était jugé trop important pour le bénéfice. A l'inverse des solutions BI totalement inutiles d'un point de vue performance sont maintenues coûte que coûte parce qu'un grand chef les "aime bien".



Le Late-binding c'est bien joli, c'est très utilisé pour les data-science et c'est le concept derrière un data-lake, mais franchement pour de l'informatique de gestion il vaut mieux se casser un peu la tête en amont à modéliser les données correctement. Ce que j'ai vu en late-binding c'est surtout des data-lake énormes sous hadoop, et personne qui n'utilise vraiment les données parce qu'elles sont "pourries".

Ceci étant dit, il est vrai que le médical est un secteur particulier avec une assez mauvaise qualité de données et de mauvaises architectures pour les raisons suivantes:
- peu de moyen IT en comparaison de banques ou autres
- des opérationnels dont la principale préoccupation est de sauver des vies, pas de saisir/contrôler des données
- énormément de petites structures
- un personnel administratif / back-office au service des médecins, et pas l'inverse, donc la parole du médecin vaudra souvent plus que la parole du contrôleur de gestion

Donc les données sont de mauvaises qualité, les règles de gestion sont mal appliquées, les logiciels sont truffés de bug, il y a plusieurs strates de logiciels car ils changent tous les 3 ans en espérant que le logiciel sera "magique" et compensera leurs erreurs, et donc faire de la BI c'est compliqué. Cependant pour votre sujet ça reste assez simple: il faut prendre les données en entrée et les retravailler jusqu'à obtenir un résultat exploitable par le business en sortie. C'est là-dessus que vous serez jugé, pas sur votre modélisation.

Votre modélisation me semble suffisante, si vous voulez absolument faire plus propre, vous pouvez faire:
- une table de traçabilité des changements sur les patients et les séjours, qui permet de retrouver TOUS les changements à la minute près
- des SCD (Slowly Changing Dimension) à la journée sur les patients et les séjours. Comme vous avez des faits à la journée, ça vous permettra de rapprocher les faits à des valeurs d'attributs des dimensions. Ca vous évitera d'avoir des tables Dimension Patient et Séjour trop vides car en fait énormément d'informations peuvent changer sur ces dimensions (surtout Séjour).

[jpf991]

Bonjour,

Merci encore pour vos super réponses, très explicites et qui me rendent bien service.

Concernant la table de traçabilité des changements sur les patients et les séjours :

- Est-ce une parti du DWH ou Est-ce directement dans la base de donnée de l'ERP que cette table doit être créée ?

- Si c'est une partie du DWH, comment cela fonctionne si le job d'ETL ne fonctionne qu'une fois par jour le soir ?

Concernant les SCD pour les patients et les séjours :

- Ma table de fait présence contient toutes ces informations qui évoluent chaque jour. Est-ce une mauvaise solution ?

- Quelle serait l'avantage de faire de séjour et patient des SCD ?

- Ne sera t'il pas plus compliqué pour les utilisateurs business de naviguer dans un tel schéma ?

- Du coup, si mes informations, types médecin traitant ou chambre, se retrouvent dans mes SCD, ma table de fait ne comprendra plus que la clé primaire numéro séjour - date de présence, et une clé étrangère par dimension ?

Autres questions :

Je souhaite calculer le taux de remplissage de chambre par jour :

- Dans ce cas, est-ce que la dotation par service est une mesure à ajouter à la table de fait ? (comme j'ai vu quelques exemples pour les budgets)

- Dois-je créer une dimension dotation ? Si oui, doit-elle être saisie par jour puisque mes fait sont à la journée ?

Merci d'avance pour votre aide,

Cordialement,

Julien

[nuke_y]

La table de traçabilité fait partie du DWH mais si vous n'avez qu'1 photo par jour ça ne servira à rien, votre table de fait fera office de traçabilité.

Les SCD c'est toujours bon à avoir, mais dans votre cas vous pouvez effectivement tout faire avec la table de faits, et puis créer des SCD plus tard. L'avantage des SCD:

- permettent de réutiliser un SCD créé à partir d'un fait pour un AUTRE fait. Par exemple un SCD "Patient" crée à partir des données du fait "Sejour" qui est utilisé pour le fait "Facturation" qui ne contient aucun des attributs qu'on peut trouver dans les données du fait "Sejour", mais comme une table de dimension "Patient" a été créée, et grâce au SCD, on peut analyse le fait "Facturation" au travers de la dimension "Patient"

- donnent une vision de l'historique de la dimension

- économisent de l'espace disque dans le fait puisque les données ne sont pas répétées x fois

- permettent de regrouper les n attributs de la dimension dans une table unique, au lieu de les mélanger à d'autres dans le fait

- permettent d'analyse des faits du passé avec les connaissances du présent. Par exemple soit un attribut "En retard de paiement" sur la dimension "Patient". Si on veut analyser TOUS les séjours des patients qui ACTUELLEMENT ont un retard de paiement, le SCD (avec des clés de substitution) rend cette analyse facile. Bon c'est un peu à la marge, mais il y a de vrais cas d'usage.

- souvent, les dimensions en SCD sont héritées de données référentielles et donc le SCD est "forcé" par les données source donc le SCD est "obligatoire" et ne constitue pas un choix de modélisation


Effectivement les utilisateurs vont s'ouvrir les veines s'ils doivent naviguer dans des SCD, c'est pour ça qu'on fait des SCD dans le DWH et pas dans les datamarts ou qu'on utilise des clés de substitution (suggorate keys) pour faciliter l'utilisation.


Quelle est la définition d'une dotation ? D'une manière générale j'essaie de calculer le moins de KPI possible dans le DWH, par contre aucun problème dans le Datamart. De même j'essaie de ne jamais calculer un KPI (ou même une mesure) qui met en jeu plusieurs lignes (par exemple "moyenne de la durée"), je ne le fais que quand je n'ai pas le choix, ça arrive.

[jpf991]

Une Dotation c'est le nombre de chambre réservé à un service. Elle est indiqué à l'année et par service. C'est donc une sorte de budget mais pas financier.

Mon problème est donc de savoir si je dois faire une table dotation, avec les dotations pour chaque jour de l'année, ou si je peux me servir d'une table où les dotations ne sont renseignées qu'à l'année.

Merci d'avance,

Julien

[nuke_y]

Visiblement une table où les dotations sont renseignées à l'année est largement suffisante.

[fredinkan]

- La différence entre PowerBI et Qlikview est gigantesque, comme comparer une brouette avec un engin de chantier à 10 M€. Bon si c'est pour transporter 2 m3 de feuilles mortes, il vaut mieux utiliser une brouette bien entendu donc ça dépend du besoin, et selon le besoin il vaut mieux PowerBI. Mais il y a une vraie raison à la différence de prix.

Hello,

Je ramène juste ma fraise sur ce point.
Effectivement il y a une grosse différence entre les deux produits et si que si powerBI est l'unique outil de restitution, il est insuffisant.
Cependant, s'il est associé à d'autres outils (typiquement garder quelques licences QV pour du report ou dashboard plus complexe et PowerBI pour des tableaux rapides), il peut être assez bien utilisé. J'ai pu remarquer que son utilisation était très souvent poussée par le business qui sort beaucoup d'Excel.

Les points qui ressortent souvent sont : impossibilité de faire un top n facilement, impossible de calculer 2 faits qui ne sont pas pré-calculés dans un cube (p.ex. vente vs location si les 2 infos sont dans un même fait), et j'en passe

[jpf991]

Bonjour Fredikan,

Je vous remercie de donner votre avis, qui m'intéresse bien évidemment.

Les demandes actuelles des médecins sont plutôt basiques et pense pouvoir utiliser PowerBI car le prix est clairement plus raisonnable que QV. Sinon auriez-vous une solution intermédiaire à me conseiller?

Par contre j'ai une question pour vous qui connaissez un peu PowerBI. Est-il possible de publier un rapport PowerBI sans que les données ne soient exporté vers le cloud par Microsoft ?

Merci d'avance,

Cordialement,

Julien