Présentation rapide de RootDB, une application auto-hébergeable open-source (AGPLv3), permettant de générer des rapports à base de requêtes SQL.

Sommaire

• Genèse du projet
• Open-source
• RootDB ?
• Fonctionnalités
  • Websocket
  • Bibliothèques graphiques au choix
  • Onglets & Menu
  • Cache
  • Paramètres en entrée
  • Liens entre rapports
• Hébergement
• Conclusion

Genèse du projet

Pour les besoins d'un client, il fallait que je génère rapidement des statistiques d'usage diverses et variées (à bases de tableaux et graphiques), à partir de plusieurs base de données relationnelles classiques et que j'intègre ces rapports dans un backoffice.

Le premier réflexe fut de me tourner vers une solution que j'ai utilisée pendant une dizaine d'années auparavant et qui se nomme MyDBR. Cela répondait parfaitement à son besoin tout en étant abordable. MyDBR, bien maitrisé, permet de faire énormément de choses, mais l'interface est vraiment datée et l'accès aux fonctionnalités des bibliothèques graphiques se fait par l’intermédiaire de wrappers en SQL.

J'ai cherché des alternatives, auto-hébergeables, simples à mettre en place, maintenues et avec la même logique pour la création de rapport mais je n'ai pas trouvé mon bonheur. Il y a, évidemment, pleins de solutions qui existent mais il y avait toujours quelque chose qui n'allait pas après essai, que ce soit dans la manière de générer des rapports ou bien les pré-requis, parfois compliqués, pour l'hébergement.

D'ou l'idée de créer, avec un collègue, notre propre solution de reporting - parce que pourquoi pas, finalement.

Open-source

Ce projet n'était pas open-source à la base et nous pensions simplement vendre des licences d'utilisation.

Sauf qu’aujourd’hui beaucoup de monde utilise le cloud, et ce dernier vient avec ses solutions intégrées de reporting, limitant de fait l'intérêt de ce genre de projet. Pour faire bref, je reste convaincu que tout le monde n'est pas sur le cloud et que ce genre de solution peut encore intéresser quelques personnes.
À cause des doutes sur la pertinence même du projet, je n'ai jamais sérieusement cherché du financement, ce qui ne m'a jamais permis d'être à temps plein dessus. Nous avons donc mis du temps avant de produire quelque chose d'exploitable dans un environnement de production : un an et demi environ.
À cela s'ajoute le fait que ce projet n'existerait pas sans toutes les briques open-source sur lesquelles il se base. Et comme c'est l'open-source qui me fait vivre depuis un certain nombre d'années, il me semblait finalement bien plus naturel de rendre ce projet open-source (licence AGPLv3) que d'essayer de le vendre en chiffrant le code source.

RootDB ?

Étant familier du SQL et du JavaScript, nous voulions avoir une solution qui ne mette pas de bâtons dans les roues du développeur, à savoir :

• utiliser principalement le SQL pour la récupération et le traitement des données ;
• avoir un accès intégral à la bibliothèque graphique choisie ;

Ce choix de préférer un environnement de développement de rapport orienté développeur est assumé, d'où le nom du projet.

Fonctionnalités

Je ne vais pas vous présenter toutes les fonctionnalités car le site web principal et l'instance de démonstration les présentent déjà correctement. Je vais donc plutôt mettre en avant les spécificités du projet.

Websocket

Les requêtes SQL peuvent prendre du temps à tourner, surtout si les tables ne sont pas correctement optimisées. Par conséquent l'interface repose lourdement sur les websockets afin d'éviter les problèmes de timeout. Quand un rapport est exécuté, l'exécution des différentes requêtes est dispatchée de manière asynchrone et les vues affichent des résultats uniquement quand les données arrivent sur le websocket du rapport.
D'une manière générale toute l'interface est rafraichie par websocket.

Bibliothèques graphiques au choix

Nous donnons accès à Chart.js ou D3.js, sans limitation, sans wrapper. Il est donc possible de se référer directement à la documentation officielle de ces deux bibliothèques.

Onglets & Menu

Nous aimons bien les menus. :)
C'est simple, élégant et permet d'accéder à beaucoup d'options de manière claire.
L'interface repose sur une barre de menu principale dynamique et une barre d'onglets dans lesquels s'affiche les différentes parties de l'application. Il est donc possible d'ouvrir plusieurs rapports (ou le même) dans le même onglet du navigateur web.

Cache

Il existe deux niveaux de cache :

• un cache utilisateur, pratique pour cacher des résultats de manière temporaire afin de partager des résultats avec un autre utilisateur.
• un cache système (jobs) ou il est possible de générer du cache de manière périodique. Nécessaire pour des rapports qui utilisent de très grosses tables qu'il n'est parfois pas possible d'optimiser.

Paramètres en entrée

Il est très facile de générer ses propres paramètres afin de filtrer les rapports, que ce soit sur une plage de date, une liste d'options sortie d'une base de données, des cases à cocher etc.

Liens entre rapports

Que ce soit avec Chart.js ou bien un tableau, vous pouvez créer des liens entre vos rapports ou bien sur le même rapport pour faire des rapports de type drill-down.

Hébergement

Côté API, RootDB est une application Laravel qui fonctionne sur du PHP en version 8.2.x (voir 8.3.x, mais pas encore bien testé) et utilise Memcached pour la gestion du cache.
Le serveur de websocket est propulsé par Laravel Reverb.
Côté Frontend, il s'agit d'une application React classique, en TypeScript, qui utilise PrimeReact pour la suite de composants prêt-à-l'emploi.

Conclusion

Concernant les fonctionnalités que nous aimerions mettre en place petit à petit :

• une interface de configuration pour Chart.js - afin de, quand même, rendre plus simple la configuration des charts, tout en laissant la liberté au développeur de coder en javascript les fonctionnalités avancés ;
• un nouveau type de connecteur pour supporter Microsoft SQL Server ;
• une fonctionnalité d'auto-rafraichissement des rapports ;
• l'import asynchrone de gros fichiers CSV ou Excel.

Nous pouvons aider à l'utilisation, par l’intermédiaire :

• d'un salon discord mais ce n'est pas forcément idéal pour ce genre de projet. Je suis donc entrain de regarder du côté de Matrix, éventuellement ;
• un forum classique.

Voilà, c'était une brève présentation de RootDB.
C'est un projet qui n'a pas encore été testé par beaucoup de monde, d’où cette présentation pour le faire connaitre un peu plus.

J’ai le plaisir de vous présenter l’association OpenProduct qui se donne pour mission de faire connaître les producteurs locaux. Dans cette perspective, nous avons lancé un site web ainsi qu’une application mobile avec une carte et un wiki. Tout est Open-Source, du code source des softs, aux comptes de l’association en passant par la base de donnée.

Sommaire

• Présentation
• Historique
• Le lancement
• Existant
• Financement
• Open-Source
  • Concrètement
• L’architecture
• La communication
• Anecdotes
• Conclusion

Présentation

Le but du projet est de constituer un annuaire des producteurs locaux le plus exhaustif possible. On considère comme producteur une entreprise qui produit en France un produit destiné au grand public (pas de constructeur de robots industriels par exemple). Je ne me limite pas aux artisans ni aux PME, mais je vois mal une multi-nationale non plus. Je pense que les plus grosses entreprises sont celles du textile avec à peine une centaine d’employés maximum. J’ai aussi quelques biscuiteries peut-être. J’aimerais bien avoir de l’électronique par exemple, mais je n’ai pas trouvé de source dessus.
Attention, parfois la frontière est un peu fine, et il y a parfois des grossistes proches des producteurs qui peuvent un peu s’immiscer dans la base de données. L’idée n’est pas non plus de mettre tous les boulangers (scandale, ils fabriquent bien en France quoique parfois certains utilisent du surgelé industriel). Mais par contre les boulangers qui fabriquent avec de la farine locale avec un four solaire ou au bois ont une raison d’y être.
Pour faire simple (et simpliste) il faut rentrer dans l’ « esprit producteur local ».

Le site web est assez basique avec une carte et pour chaque producteur son site web, son numéro, son courriel, son adresse (obligatoire pour se trouver sur la carte) et un texte descriptif. Il est possible de filtrer par catégorie, mais cet élément gagnerait à être largement amélioré. Sur le site, on dispose d’un Wiki qui est pour le moment famélique. L’idée est qu’il serve de page web à certains producteurs qui n’en disposeraient pas. Pour ceux qui ont un site complet, leur site est sans doute plus intéressant. La question reste ouverte de savoir si le wiki gagnerait à être complété par d’autres informations. J’ai dernièrement ajouté des « Guides pratiques ».

Aujourd’hui, l’on considère que le site web, c’est seulement 30% du trafic. Une application mobile est dès lors absolument indispensable. Une application Android existe et est installable avec l’APK (Disponible sur le site web). Évidemment, qu’à l’avenir, elle devra être rendue disponible le play store de Google (Et sur FDroid). En théorie, cette application pourrait être compilée pour iPhone et placée sur l’AppStore. Mais je n’ai pas encore investi dans ces magasins car le ticket d’entrée n’est pas négligeable et que l’appli est encore perfectible (et c’est un euphémisme).

Historique

Au départ, mon idée était, dans un but personnel, d’avoir des objets purement open-source (réparable, bidouillable…). Ne trouvant pas souvent mon bonheur, je me suis dit : « et si je créais une entreprise qui produit un objet Open-Source ? » Peu importe lequel. Mais je me suis vite rendu compte que je n’arriverai jamais à le vendre à quelqu’un d’autre que moi… Les entreprises qui ont tenté ont toutes abandonné genre NumWorks ou alors ont marginalisé cette démarche au cours de leur croissance. A priori, la raison n’est pas que cela ne soit pas viable en soi mais plutôt que pour croître, ils ont dû faire appel à des investisseurs qui n’achetaient pas le concept d’Open-Source. Et s’ils n’ont pas pu grossir sans ces investisseurs, c’est qu’il est très difficile de vendre (pas vraiment de fabriquer). En fait, les gens ne voient pas l’intérêt de l’Open-Source si c’est « réparable ». Autrement dit, il « suffit » pour l’entreprise de dire qu’elle continue de vendre les pièces détachées. Mais si l’entreprise ne fournit ni pièces, ni plans, c’est trop galère à faire soi-même (ou trop cher par un réparateur). Il y a un autre problème qui se cumule, c’est la multiplication des versions. Il n’y a pas 1, 5 mais près d’une centaine de lave-vaisselles différents, aucune communauté ne pourra modéliser toutes les versions en service (pas seulement celle commercialisée, mais aussi toutes celles qui l’ont été depuis 15 ans). En fait si je fabrique moi-même un produit open-source, je vais avoir énormément de mal à en faire la promotion.

Mais je ne suis pas le seul dans ce cas, tous les petits producteurs locaux connaissent ce problème. Ils ont des articles de bien meilleurs qualité que le commerce standard (certes un peu plus cher) mais ils peinent à se faire connaitre. Ils utilisent généralement assez peu de brevets et c’est bien ça qui attire le client, il sait d’où ça vient, comment c’est fait (en gros). Sa force, c’est donc de ne pas cacher sa chaine de production, c’est donc en quelque sorte au minimum d’être open-source sur la chaine de production. Et on peut les aider à être plus transparents. D’où OpenProduct. Enfin, c’est l’idée à long terme.

Le lancement

Tout ça en serait resté au stade d’idée si je n’avais pas été au chômage. Au départ j’ai fait des travaux dans la maison puis faute de finance et de courage, j’ai dû réduire. Je me suis donc attelé à la tâche.

La tâche la plus simple pour moi c’était de faire le site web (je ne parle pas du design). Il n’y avait là aucune difficulté majeure, j’ai pas mal travaillé avec HTML/JavaScript/PHP dans mes précédentes activités professionnelles et un peu avec Leaflet. Je voulais penser performances et sécurité. Et pour moi, le plus évident c’était de faire du statique. Cela ne demande que les ressources minimales pour le serveur et c’est inattaquable. Aujourd’hui, on peut faire beaucoup en JavaScript. En plus, comme c’est statique, je n’ai pas de cookies… Donc pas cette satanée popup ce qui rend tout de suite le site plus plaisant.

Il y a bien du dynamique tout de même (dont les scripts), et là, j’avais envie d’explorer des technos que je trouve performantes :

• j’ai utilisé Julia comme langage interprété pour les scripts et pour le Web (Avec le framework Genie)
• j’ai utilisé Svelte pour un formulaire « dynamique » en JavaScript.
• j’ai choisi React-Native pour le développement mobile car c’est du multi-plateforme et en JavaScript. Je pensais réutiliser le code javascript du web mais au final c’est tellement différent, qu’un autre langage n’aurait pas changé grand-chose. Du coup, je pense que Flutter aurait été plus performant (Il compile vraiment en langage machine : Java sous Android.)

Existant

Mais il existe déjà plein de solutions qui marchent très bien pensez-vous. Je vous ferrai une réponse de normand (bien que je sois breton) « Oui et non ».

Il existe des sites publics qui recensent certaines catégories :

• l’alimentaire avec jours-de-marche.fr et mon-producteur.com.
• Les métiers d’arts avec annuaire-metiersdart.com.
• Ou encore dans l’habillement comme cocorico.store et madefrance.fr mais ils n’identifient même pas toujours les producteurs.
• Des offices de tourisme mais chacun a une politique différente et l’on ne s’y retrouve pas facilement.
• Parfois des sites publics de départements/régions…
• Des groupes Facebook à la pelle.

Mais aucun ne propose une carte de localisation des producteurs et aucun n’est généraliste (Alimentaire, art et autres). Pire, ils ne recensent pas tous les producteurs (sans doute car ils demandent de l’argent) et en plus ils ne sont pas toujours à jour. Je soupçonne certains d’être un peu délaissés. Si bien que ce n’est pas si simple de connaitre les producteurs quand on se promène dans une région alors que pourtant la demande est là.

Aujourd’hui, les petits producteurs locaux peinent à se faire connaître. En fait, une part importante de leur travail est consacrée à cet effort ou ils ne sont pas toujours très bons. Ils mettent beaucoup d’énergie à faire un site web, à faire leur promotion sur les réseaux sociaux, à se vendre auprès de leurs amis et voisins pour le bouche-à-oreille. Mais c’est en grande partie en vain. En fait, ils comptent surtout sur quelques clients fidèles et sur un bouche-à-oreille de connaisseurs/passionnés. Or nous ne sommes pas tous connaisseurs/passionnés mais juste intéressés. Pire, même connaisseurs, quand nous traversons une région, nous ne pouvons pas y connaître les producteurs locaux. Je pense qu’OpenProduct peut aider à développer un tourisme de producteurs.

Financement

La question que l’on me pose souvent : mais quel est votre business-plan ? Mais ici, peut-être est-on entre personnes un peu plus sensibilisées à l’open-source et son financement.

Alors tout d’abord, je n’ai clairement pas un objectif de rentabilité avec ce projet. Ensuite, je ne vois pas comment je pourrais demander de l’argent aux producteurs alors que je n’ai pas de visiteurs (ou si peu aujourd’hui). De toute façon, concrètement, un hébergement web ne coute pas grand-chose (j’ai payé 50 euros pour un an). Par contre évidemment, que si je veux publier mon application sur Android et Apple, il faudra un peu plus de sous. Ensuite il y a un travail énorme à accomplir pour améliorer la base et l’IHM donc évidemment que j’aimerais des financements.

• Mon objectif premier serait de financer le projet avec des dons de producteurs et consommateurs qui seraient sensibilisés à la cause.
• Ensuite, j’aimerais, en tant qu’association d’utilité publique (J’estime en quelque sorte être un annuaire universel) réussir à toucher des fonds publics.
• Enfin, il me faudra sans doute rendre certaines options payantes. Tout dépendra du résultat au bout d’un an environ.

Vous le comprenez, la variable d’ajustement, ce sont les fonds disponibles étant donné qu’il y a très peu de charge fixe. Le projet n’en est pas dépendant pour survivre.

D’ailleurs je pense que pour un site web être payant n’est pas vraiment une option pour percer. J’entends par là, que l’essentiel est avant tout d’arriver à générer du trafic et à devenir important. Si de base vous bridez que ce soit côté producteurs ou côté consommateurs vous devenez in-intéressant pour les deux (à moins d’être réservé à une « élite »). C’est un peu ce qui se passe actuellement avec la plupart des existants (jours-de-marche.fr et mon-producteur.com). Pour prendre un autre domaine, c’est ce qui plombe un peu Twitter (il perd 30% des utilisateurs ce qui entraine une baisse de 60% de ses revenus et c’est un cercle vicieux). C’est aussi ce qui fait la force de Facebook ou Google. Ce n’est pas d’être gros qui importe mais d’être très gros pour ça, il n’y a pas 36 solutions. Je suis peut-être un peu ambitieux mais je sais que sans ça, il est évident que le projet ne grossira pas assez pour vivre bien.

Il doit sans doute miser, plus que sur l’argent, sur la coopération d’une communauté façon Wikipédia/LinuxFR. C’est pourquoi je suis ouvert aux contributions. Cela peut-être du code mais même pour des informaticiens ce n’est pas simple (il faut rentrer dans le code installer… il faut compter des heures) mais aussi et surtout pour compléter la base de donnée. Vous me signalez les producteurs qui n’existe plus ou ceux oubliés. Pour l’instant cela ce fait par mail. Je souhaite aussi développer le Wiki avec des comptes « administrateurs ». J’ai un ersatz d’interface d’administration pour les producteurs…

Open-Source

Je suis un archi-convaincu du bien fondé de l’Open-Source et de l’Open-Data en général. C’est pourquoi j’essaye de pousser le concept d’Open-Source le plus loin possible. Tout mon code est sous licence GPL y compris la base de donnée et pour ce qui ne rentre pas dedans (images ou autres) c’est Créative Common Attribution. Cependant je ne me suis pas penché sur la question plus que cela.
Je pense notamment au logo/marque. Je n’ai pas envie de m’attribuer le concept OpenProduct, mais je n’ai pas envie qu’on en fasse n’importe quoi non plus. Faut-il un système à la Firefox ? En tout cas, en l’état mon logo n’intéresse personne.
Il y a aussi la question de la version de GPL. Je dirais la dernière v3 même si j’avoue ne pas avoir étudié les différences. Je sais qu’il y a des résistances sur la v2. S’il y en a qui sont partisans, merci de me le dire en commentaires.

Concrètement

Sur mon dépot Github (Ouais, ce serait mieux Gitlab), il y a six repository concernant ce projet:

• openproduct-web : Le projet principal (Il contient la partie web statique et dynamique)
• openproduct-web-svelte : C’est un sous-projet web destiné à svelte. On y trouve le formulaire svelte.
• openproduct-app-android : C’est le repository de ma toute première application Android. C’est un simple navigateur web sur la page web d’OpenProduct… Une sorte de marque-page. Elle est obsolète.
• openproduct-app : C’est une application React-Native destiné à Android (Qui doit pouvoir tourner sous Apple en théorie). Elle est loin d’être parfaite mais c’est vrai que c’est mieux que le web sur smartphone.
• openproduct-docs : Ce n’est pas du public dans les entreprises/associations normales, mais ce sont toutes les ressources autres. On y trouve:
  • les scripts de récupération de données pour la DB.
  • Les documents administratifs de l’association
  • Les comptes financiers.
  • Les démarches de communications externes.
• openproduct-db : Il contient la database (mysqldump).

Parmi les astuces, je ne sais pas si c’est une pratique courante, j’utilise le format plat pour les fichiers de LibreOffice. FODT au lieu d’OST, FODS au lieu d’ODS… Par défaut le format est un tar-gz de fichier XML, autrement dit c’est en quelque sorte du binaire. Or sur Git, il vaut mieux éviter le binaire. Git ne fait pas de diff sur du binaire, et de ce fait chaque modification renvoi tout au lieu de n’ajouter que les différences.

L’architecture

Pour celles et ceux que ça amuse, voici quelques détails au sujet de l’architecture technique.

En fait openproduct-web est un projet en langage Julia du Framework Genie. Pourquoi ? Tout simplement car j’avais envie de tester et que normalement, Julia est un langage très performant (Il est utilisé pour le calcul scientifique en « successeur » de Pascal).

J’ai dit que le site web est statique. C’est vrai pour l’essentiel: La page d’accueil, la carte… Il est stocké dans openproduct-web/public.

Mais j’ai un wiki qui est dynamique sur openproduct-web/wiki (Pas sur Git, c’est déjà un repo Git: médiawiki). Et j’ai aussi la page "unsubscribe.php" qui est dans openproduct-web/around/var.www.openproduct.wiki.unsubscribe.php.

Dans openproduct-web/around est un peu un fourre tout des fichiers qui doivent être mis à un endroit précis mais hors du projet. On trouve ma config NGinX, ma config Wiki (Enfin la version de mon PC de dev, pas celle de prod à cause des mots de passe). Le fichier unsubscribe.php (Il est dynamique et seul mon répertoire wiki est dynamique sur mon PC).

La partie dynamique pour l’essentiel est en Julia. Elle ne peut pas tourner sur le serveur qui est un hébergement mutualisé ou Julia n’est pas disponible. Elle tourne donc seulement sur mon PC (le PC de dev : https://openproduct.freeboxos.fr/ quand je la lance). Elle est destinée à ceux qui voudraient m’aider à compléter corriger la base de donnée. Elle permet de renseigner des producteurs dans la table openproduct.producer sans avoir à connaitre MySQL (Ni même à utiliser DBeaver).

La communication

Ce n’est pas vraiment mon fort mais c’est assez essentiel en ce moment. Maintenant que c’est en ligne il faut absolument que je crée une dynamique pour qu’il prenne.

Ma première étape a consisté à prévenir les producteurs par mail, du moins ceux dont j’ai le mail. Évidemment, j’en profite pour leur demander de me faire un peu de promotion. J’ai donc écrit un script qui se connecte à ma boite Gmail (ouuuuuh pas bien) et qui envoie les mails à la chaine. Le problème, c’est que mon compte de l’association est en fait un compte standard limité en nombre de mail envoyé. J’ai donc saturé les envois, je suis passé avec ma boite perso. Par paquets de 200 à 300, il m’a fallu cinq jours pour envoyer les 3 584 mails dont je dispose sur les 5 050 producteurs. Et j’ai reçu 720 mails d’erreurs… j’ai donc écrit un script pour lire ces mails et les noter dans ma base. J’ai aussi reçu des retours pour me corriger des erreurs (adresse, téléphone, cession d’activité…) et quelques encouragements. J’ai reçu un seul retour négatif car il estimait que son art ne devait pas être mêlé a de vulgaires produits.

Parmi les retours, j’ai eu la remarque intéressante qu’il me manquait un flyer. Je me suis donc dépêché de faire un flyer. Je ne suis vraiment pas expert dans l’exercice.

Ensuite mon moyen de promotion est Facebook. J’ai créé une page et je me suis inscrit à tous les groupes de producteurs. Et j’y publie partout une annonce. J’ai quelques retours, mais la plupart de mes annonces sont encore en attente de modération.

Il faudrait la diffuser sur d’autres réseaux sociaux. Mais je n’ai pas envie d’installer les applications privatrices et je constate qu’à part Facebook, il n’existe pas beaucoup de réseaux ou l’on peut s’inscrire sans installer une application sur smartphone…

Maintenant, il faudrait aussi passer à l’étape supérieure : la presse. On va dire que LinuxFr constitue mon premier pas. Pour le reste on verra, ça peut encore attendre.

J’ai une autre étape à faire : solliciter les services publics pour des subventions. J’ai légèrement commencé mais tant que je n’avais rien en ligne j’étais peu crédible. Depuis j’ai simplement envoyé au département des Côtes d’Armor qui est mon département (peut-être pas le plus riche ;) ).

Anecdotes

Question piège : que représente mon logo ? 

Réponse: une hutte de Hobbit avec la porte en bois et la Hutte en terre. La lumière verte qui en sort, est la couleur exacte du logo OpenSource, et si vous regardez, elle forme un O ouvert comme dans le Logo OpenSource (Pour cette raison même).
Cette cabane symbolise, selon moi, le lieu de fabrication d’objets mystérieux. Et on entre-ouvre la porte pour laisser y échapper les secrets ou pour que le client y entre.

Vous ne l’aviez pas deviné ? C’est normal, c’est du made in moi. Mon frère est susceptible de le refaire en 3D.

Conclusion

Je pense me concentrer plus sur le non-alimentaire car le domaine alimentaire est déjà pas mal investi par d’autres. Pour le reste, il y a un grand besoin. J’aimerais avoir plus de producteurs « petit-industriels » ou du moins d’objets. Et mettre à part les producteurs d’arts (d’objets d’arts : ferronnerie, verrier, potier, vannerie…).

Il reste beaucoup de travail à faire. On verra si la graine prend. ;)