Un modèle de formulaire dynamique en Python / Django

Le concept : Un n-ième outil de création de formulaire

Le sujet n’est pas réellement innovant : il doit exister autant de site de formulaire dynamique que de développeur  … Pourtant, à chaque nouveau développement, il est rare de trouver l’outil, le module, qui va permettre de ne pas développer son modèle de formulaire. Il manque souvent, la fonctionnalité, ou le paramétrage qui va permettre d’avoir le paramétrage ou la personnalisation nécessaire.  Le principe de ce développement ne sera donc pas de faire le module de formulaire le plus complet possible … mais au contraire, de proposer un outil simple, robuste qui pourra être utilisé tel quel … ou étendu pour des besoins spécifiques.

L’innovation : Penser directement pour l’exploitation des résultats

En effet, un formulaire, quel qu’il soit n’est utile que si l’exploitation des résultats est possible.  L’objectif de ce développement sera donc de fournir l’ensemble des outils permettant la conception et l’utilisation d’un formulaire mais également, ceux qui permettent une exploitation ou un export des résultats.

Le mode de distribution

Sur ce point,  je vais essayer d’être le plus complet possible afin que tous puisse y trouver leur compte.  L’objectif sera donc de proposer :

  • Un service en ligne complet et autonome.
  • Une Api, permettant à des solutions de personnaliser complètement une partie de l’interface tout profitant d’un backend et de solution d’export existante.
  • Sous forme de brique logicielle autonome pouvant être déployant directement au sein d’une infrastructure
  • et pour ceux qui veulent aller plus loin dans la personnalisation, directement les sources de la solution (open ou closed source) en fonction de la cible du logiciel.

la stack technique

Pour le moment, rien n’est définitif … Mais le premier jet sera basé sur Python Django + un serveur MariaDB.  L’objectif de cette stack est de permettre d’obtenir un premier résultat rapide. De plus, ce choix permet de jolies évolutions. 

La cerise sur le gâteau est que Python est Le langage a suivre pour le moment. Ce choix est donc à la fois pour l’évolution du produit .. que pour mon évolution. 

Power Bi, Open Data et listing des pharmacies

Voici un petit article présentant comment il est possible d’obtenir un listing dans Power BI présentant une grande majorité des pharmacies.

La première étape est de récupérer un fichier contenant l’ensemble des établissements de santé.
Le choix se fait sur le fichier Fichier Finess:

Le choix est déterminé par la certification du fichier et sa fréquence de sa mise à jour.

Ce dossier du site Open Data contient en fait plusieurs documents distincts dont le détail est visible dans l’aperçu précédent.

Pour ce premier article, nous n’aurons besoin que du fichier contenant les extractions Finess des établissements ainsi que la géolocalisation de ces établissements. En supplément, il est possible de consulter le 1er fichier permettant d’obtenir un descriptif des différentes informations contenus dans le dossier.

Le traitement dans Power Bi sera minimaliste. La première étape consiste à importer les différents fichiers CSV. Après import des fichiers, il faut faire attention au typage automatique des colonnes. En effet, pour se faire, Power BI fait un échantillonnage sur les premières colonnes du fichier. Dans le cas des départements, cela pose problème car le type numérique du début de fichier n’est pas conservé sur son intégralité (2A / 2B pour la corse par exemple). Il est donc recommandé de conserver le type alphanumérique pour toutes valeurs qui n’est pas un nombre exploitable. Ceci se fait très facilement en appliquant changeant le type.

Pour le fichier structure, les étapes sont les suivantes :

  1. Source : import initial
  2. Promoted Headers : permet de sélectionner la première ligne comme entête de la table
  3. Changed Type : permet de passer du type numérique à alphanumérique
  4. Merged Queries : permet de faire une jointure entre le référentiel des types de voie et la table structure.

Un autre point à mentionner est que, dans le fichier fournit, le type de voie est donné sous la forme d’un référentiel qui n’est pas fourni. Pour le construire relativement rapidement, il suffit d’utiliser un tableur et de sélectionner l’ensemble des valeurs distincte de la colonne typvoie. Une fois la sélection obtenue, il est possible de créer son propre référentiel après avoir complété l’ensemble des libellés associés.

 

Nous obtenons donc 3 fichiers qu’il est possible le lier par la suite dans l’écran de modélisation.

Un dernier point de détail concerne le widget utilisé pour la localisation des établissements. Celui fonctionne à l’aide des adresses postales. L’inconvénient est quand le fichier fourni, l’adresse est éclaté dans plusieurs champs. Un moyen simple pour contourner ce problème est d’ajouter une colonne calculée à notre table, regroupant l’ensemble des champs devant être joint. On peut voir dans cette formule l’utilisation du référentiel sur le type de voie et l’ajout, en dur, du pays. Le fichier étant localisé par nature, il ne contient pas la notion de pays.

En conclusion, nous obtenons l’ensemble des établissements de santé, géolocalisées, dans des listes filtrables.