# Rapport d'étonnement du potager numérique des [Jardins Nourriciers](https://www.lesjardinsnourriciers.com/) - Temps passé : 0,5 jour - Source des schémas - [Comment j'ai compris les choses](https://excalidraw.com/#json=5147829873934336,nXSq2ceNMaJjOjwwQI0uZw) - [Comment j'imagine les choses](https://excalidraw.com/#json=5766772737179648,dA018OmfjzhjdWJMz6GsdA) - [Exemple de vente](https://excalidraw.com/#json=5650910332059648,T_jrVyu4G1p0EEblvyCVCA) ## Ma compréhension J'ai apprécié la simplicité et la richesse des éléments de gestion des différentes feuilles Excel qui ont été partagées avec moi : - Comptabilité 2019.xlsx - Gestion paniers 2019.xlsx - Saisie production 2019.xlsx - Suivi individuel adhérent 2019.xlsx J'en ai dressé un schéma où je représente les "domaines" de fonctionnement des Jardins, et les liens implicites entre les fichiers. [![Comment j'ai compris les choses](https://i.imgur.com/MadN115.png)](https://i.imgur.com/MadN115.png) ### Qu'est-ce qui fonctionne bien ? - ça fait le travail - l'interface d'Excel combine visualisation, modification et calculs de données - retour en arrière possible en cas de problème (tant qu'on n'a pas fermé le fichier) - le coté tout-en-1 ### Qu'est-ce qui gêne ? - recopie des données obligatoire - certains champs gagneraient à être préremplis (listes fermées pilotées par d'autres feuilles) - mélange de plusieurs domaine pendant une action humaine (ajouter un produit à panier ou d'abord un·e adhérent·e ? Penser au code comptable ?) - récupérer d'une erreur est coûteux en temps humain, et demande une aisance à naviguer dans les données - les fonctionnalités de tableaux de bord sont coûteux en temps de calcul - partager un fichier nécessite un travail de recopie manuelle ### Qu'est-ce qui est complexe de manière inhérente - la gestion des points de vente - le calcul des prix - données à jour et synchronisées - visualisation utile des données ## Un futur possible : des logiciels métiers Plutôt que de réinventer la roue, allons regarder du côté de logiciels qui gèrent des point de vente, du paiement en ligne, et des adhésions : - [Cagette](https://www.cagette.net/) - [AmapJ](https://amapj.fr/) - [Amapress](https://amapress.fr/) - [OpenDistrib](https://www.opendistrib.net/) - [PanierLocal](https://www.panierlocal.com/) D'autres font partiellement le boulot, pour la partie "associative", sans la gestion des paniers/distribution : - [Garradin](https://garradin.eu/) - [Galette](https://galette.eu/dc/index.php/pages/%C3%80-propos) - [OpenConcerto](https://www.openconcerto.org/fr/) - [Dolibarr](https://www.dolibarr.fr/) Le gain réside dans leur conception : si ça marche pour d'autre, ça peut marcher pour les Jardins Nourriciers. Le hic sera dans les "cas à la marge" : il faudra s'y faire ou bricoler des solutions autour. À tester, pour exercer un choix en conscience, et accepter ce qu'on perd ou ce qu'on n'aura pas — ou combien ça coûterait de l'avoir. ## Un futur possible : développer un logiciel maison Partir de zéro semble une bonne idée. Mais ça repose aussi sur un [biais d'optimisme](https://fr.wikipedia.org/wiki/Biais_d%27optimisme), qui est nourri par l'idée que c'est plus facile si on s'en occupe soi-même, car on croit savoir — alors qu'on baigne en réalité dans un déni de complexité. Si l'association n'a pas pour intention de partager son logiciel avec d'autres structures, je déconseille de partir de zéro. ## Un futur possible : une base de données visuelle C'est une approche hybride entre "développer soi-même" et "utiliser des logiciels existants", mais où on se contente de développer seulement des _interfaces visuelles_. Ces interfaces sont de 2 natures : _lire_ des données, ou _écrire_ des données. Une vue "à la Excel" pour des personnes des Jardins aide à _inspecter_ les données, et à les _rectifier_ si nécessaire. Les interfaces sont développées avec des technologies ouvertes et universelles : HTML et CSS. Les données sont lues et écrites depuis une base de données avec laquelle on peut dialoguer via Internet. Des exemples de logiciels qui gèrent une couche de données interrogeable à distance : - [AirTable](https://airtable.com/) — payant, mais suffisant pour prototyper rapidement sans développement logiciel - [Kinto](https://docs.kinto-storage.org/) - [RxDB](https://rxdb.info/) - [Strapi](https://strapi.io/) - [Firebase](https://firebase.google.com/) L'opportunité est de créer les interfaces visuelles qui manquent aujourd'hui. Chaque interface visuelle est indépendante, sauf de la base de données qu'elle va interroger pour y lire, ou déposer les données. La philosophie est de pouvoir jeter un œil aux données, comme on le fait aujourd'hui avec Excel, en préservant l'intégrité des données, leur structure. Les interfaces s'ajoutent à ça, et donnent du sens, contrôlent les saisies. La seule chose qui peut mal vieillir c'est la manière dont on stocke et organise les données — les feuilles Excel existantes nous renseignent aujourd'hui très bien sur la manière de les organiser, on ne part ainsi pas de zéro. Il faut imaginer chaque formulaire ou tableau de bord comme une planche permacole : elles se construisent chacune en regard des autres, mais leur contenu est "indépendant". --- Voici une évolution du premier schéma, sur la répartition des données si elles migraient de Excel vers un tel modèle : [![Comment j'imagine les choses](https://i.imgur.com/nxvKyyy.jpg)](https://i.imgur.com/nxvKyyy.jpg) Voici comment se déroulerait une vente : [![Exemple de vente](https://i.imgur.com/ZiEs62x.jpg)](https://i.imgur.com/ZiEs62x.jpg) Deux bonus : - d'autres applications peuvent se greffer, et peuvent être écrites dans n'importe quel langage de programmation, pour automatiser des traitements de données - la gestion hors-ligne et la synchronisation des données sont couvertes par des librairies open source (ex : [Kinto.js](https://kintojs.readthedocs.io/en/latest/)) — un formulaire de saisie de données peut ainsi gagner la capacité "hors-ligne" a posteriori