L’App Frais et local : comment nous avons développé le Google Maps du ministère de l’Agriculture

Nous connaissons tous la formule, popularisée par Airbnb et Google Maps, avec une liste d’un côté, une carte de l’autre, un champ de recherche et un bouton de géolocalisation. Fin 2020, le ministère de l’agriculture a souhaité lancer un nouveau projet avec Opendatasoft : faire une App pour trouver les producteurs les plus proches.

L’objectif de l’App Frais et local : offrir un point d’entrée unique aux consommateurs recherchant des produits fermiers de proximité et une visibilité renforcée aux agriculteurs adhérents des plateformes partenaires.

À première vue, le développement de la partie visible – le frontend – est simple. En quelques heures de JS et à l’aide d’une librairie comme Mapbox-gl, il est possible de concevoir une carte qui affiche des points, se recentre sur la partie souhaitée et permet la géolocalisation.

Nous avons ensuite créé une page d’accueil, ajouté les mentions légales, donné un petit coup de « peinture » (CSS) et enfin, importé et permis la gestion des données avec la plateforme Opendatasoft.

Un premier défi apparaît rapidement : aujourd’hui les utilisateurs attendent beaucoup d’interactivité sur leurs interfaces. Par exemple, un champ de formulaire qui peut recevoir aussi bien une adresse qu’une géolocalisation, des filtres qui ajoutent ou retirent des points sur la carte, des clics dans une liste qui pilotent la carte, etc. Ils recherchent surtout, des transitions hyper-fluides qui ne nécessitent aucun rechargement de la page et avec des animations légères pour les guider. Tous ces petits détails ajoutent rapidement des lignes de code et quelques complications.

Pour arriver à ce résultat, les communautés de développeurs sont unanimes : il faut utiliser React. Vue éventuellement, ou encore Svelte comme nous l’avons fait. Mais certainement pas du simple JavaScript. Toutefois, utiliser ces fameux frameworks implique de les maîtriser : nouvelles syntaxes, nouvelle logique, un outillage conséquent, des étapes de compilation etc. Leurs complexités ont notamment révolté certains développeurs vétérans, au point d’en regretter l’époque de «l’ancien Javascript».

Pour développer Frais & local (mais aussi d’autres parties récentes de notre produit), notre choix ne s’est pas porté sur React, ni sur son principal concurrent Vue. Nous avons opté pour Svelte, le dernier né des Frameworks JavaScript de plus en plus populaire. Beaucoup plus léger et performant que ses deux concurrents, Svelte a aussi l’avantage d’avoir un modèle mental très simple et une syntaxe assez élégante. L’apprentissage a donc été rapide.

Avec de bonnes bases en HTML/CSS/JS, nous avons développé la première version de Frais & local en deux semaines seulement avec deux développeurs. S’ajoutent à cela deux à trois semaines pour prototyper une app générique, ce qui nous a permis de monter en compétence sur le sujet et d’avoir une démo prête rapidement pour les équipes du ministère. L’App est certes simple, mais n’a pas nécessité cinq ans d’expérience sur le framework, loin s’en faut.

J’ai trouvé l’expérience de développement très satisfaisante. Svelte a fait le pari de dévier du JS standard (ES6+) et d’introduire ses propres variations de syntaxe, qui seront ensuite compilées en ES6, ce qui permet d’avoir une syntaxe vraiment légère. D’autre part, Svelte a une philosophie de “faciliter l’intégration du Javascript au HTML/CSS”, là ou React est plus orientée vers “faciliter l’intégration de HTML dans une grosse base de javascript”- pour le dire simplement.

De plus, il est vraiment très naturel de passer de la maquette à une interface dynamique avec Svelte. On commence par une liste statique en HTML et CSS, on ajoute une carte puis on intègre progressivement de la réactivité et de la logique, avec relativement peu de code. Cela nous a permis de rester très proche de la maquette, et donc de l’utilisateur, dès le début du développement et tout au long du projet. Svelte est un outil très simple et fluide pour construire une interface graphique.

Néanmoins, une App est plus qu’une interface, il faut aussi gérer les données et permettre aux utilisateurs de naviguer et d’accéder aux informations.

Si l’on s’en tient strictement aux librairies de rendu comme Svelte ou React, il est très tentant de faire des apps en une seule page, avec uniquement des éléments interactifs, sans navigation (vers une nouvelle page). Ces Single Page Apps (SPA) posent de nombreux problèmes : obligation de repasser par la page d’accueil et de charger toute l’app à chaque visite, fermeture de l’app avec le bouton retour, intégration des données asynchrone etc.

Pour pallier à cela Svelte (qui est un framework de rendu), est accompagné d’un framework d’application, SvelteKit, inspiré de NextJS pour React, ou Nuxt pour Vue.

En premier lieu, SvelteKit nous a permis d’intégrer très facilement la notion de page et d’adresse en faisant correspondre simplement une arborescence de fichier à des URL. Notre bandeau de navigation, présent dans toutes les pages, se trouve dans un fichier à la racine de notre projet et la carte (à l’adresse /carte) dans le dossier carte . Ce modèle est vraiment agréable en tant que développeur : un fichier = une URL, un / dans l’URL = un sous-dossier.

Sveltekit se charge alors de compiler cette arborescence, pour créer de vraies pages «intelligentes» : lorsqu’un visiteur arrive sur un point (url du type www.fraisetlocal/carte/id), la page d’accueil n’est pas rechargée. Si le visiteur navigue vers un nouveau point, SvelteKit n’exécute que le code qui est dans le dossier carte/[id], tout en conservant la carte et le bandeau de navigation, puisque la partie “www.fraisetlocal.fr/carte/…«  “ de l’URL n’a pas changée.

Cette opération assez complexe de découpage des fichiers et création des « pages », qu’il est très compliqué de faire à la main, est complètement transparente pour le développeur. Elle nous permet de créer très simplement une navigation facile à manipuler, qui respecte les codes du web (changement d’adresse, bouton retour etc.), avec plusieurs niveaux d’imbrication, un peu comme s’ il y avait des «sous-pages» ou les «îlots».

Dans un modèle à pages, l’appel des données est lui aussi simplifié. À chaque page correspond un nouvel appel aux données. Là où dans une SPA il faut écouter et suivre les clics de l’utilisateur. SvelteKit intègre justement une fonction spéciale pour récupérer ces données au bon moment. Cela permet d’intégrer les données à l’application déjà chargée dans le navigateur : une étape complexe car les données arrivent de façon asynchrone dans des composants qui ne sont peut-être ni chargés, ni montés.

De notre point de vue de développeur, le résultat est assez bluffant, surtout couplé à l’API Explore V2 de la plateforme Opendatasoft. Il suffit de mettre en haut de chaque fichier un appel à une URL type : https://www.fraislocal.fr/api/v2/

Et les bonnes données se chargent directement dans les composants Svelte à chaque navigation. On navigue ainsi très facilement de page en page avec une API RESTFul et un langage très proche du SQL.

Bien sûr tout n’est pas parfait. Cette notion de sous-page implique qu’il n’est pas toujours facile de savoir quel code sera ré-éxecuté ou non. De plus, nous n’avons pas pu utiliser la fonction de preload décrite plus haut, car sur un jeu de données de plus 20 mille enregistrements les performances baissent trop (ce qui explique l’apparition d’un spinner de chargement dans l’application).

Le résultat est tout de même impressionnant car l’on obtient une App qui a l’interface d’une application mobile, la navigation d’un site web, qui peut être utilisée offline et en plein écran avec très peu d’efforts, le tout sans écrire une seule ligne de code back-end et avec très peu d’appels au serveurs.

Frais & local est donc une App purement frontend, qui utilise la plateforme Opendatasoft comme un service «externe», à travers une API. La plateforme et l’App sont d’ailleurs hébergés séparément et ont été développés par des équipes différentes. Ce type d’App est dit «JAMstack» pour :

• JavaScript (ES6+), pour toute la logique,
• API (sous entendu web) pour les données,
• Markup pour décrire l’interface.

JAMstack est un vrai buzzword dans le monde du développement et la littérature sur le sujet abonde, souvent sous des formes un peu faciles du type : « Apprenez React et Tailwind et faites une app sans une ligne de backend » ou encore «3 8 raisons pour lesquelles ce framework est mieux que tous les précédents ».

Pourtant, sans APIs, il n’est pas possible de créer une App JAMstack. Le plus important dans le JAMstack, ce n’est pas le «J» ou le «M», mais bien le «A». En plus de l’API explore V2 d’Opendatasoft, nous utilisons d’ailleurs aussi deux APIs de notre partenaire Jawg, l’une pour les fonds de carte vectoriels, l’autre pour les suggestions de lieux. Cela aurait été plus long et fastidieux, mais nous aurions pu faire Frais & local sans framework front, alors que cela aurait été strictement impossible si nous avions dû écrire tout le code backend de ces APIs.

Cette façon d’utiliser la plateforme en tant que Backend/Backoffice-as-a-Service ouvre la porte à des combinaisons assez intéressantes. En plus d’Opendatasoft et Jawg, nous pourrions ajouter d’autres APIs :

• de l’authentification (e.g. Auth0),
• de la création de contenu rédactionnel avec un CMS headless (e.g. Strapi),
• un calendrier (e.g. google calendar), des paiements, des ventes, etc.…

Il y a une API pour tout aujourd’hui. Et ces Apps JAMstack sont une belle occasion de laisser chacun créer sa propre « recette » pour combiner toutes ces APIs.

C’est là toute la force de ce découplage front/back. Certes, au total, le coût de développement de l’API et du développement de l’App JAMstack, n’est pas forcément moins élevé que pour une App monolithique classique. Mais une fois que l’important travail de rationalisation des fonctions très complexes derrière une API est réalisé, de toutes petites équipes peuvent s’en saisir pour développer très rapidement des interfaces. Pour rappel, nous n’étions que deux pour développer une app en quinze jours.

Plus important encore, délestées de la très lourde tâche du backend, ces petites équipes peuvent voir le jour n’importe où et pas seulement chez Opendatasoft. Agence de développement, autre logiciel SaaS, collectif de citoyens, associations professionnelles, collectivités, entreprises, etc. Qui sait d’où viendra la prochaine App et quels usages de l’open data nous verrons émerger en poussant l’usage de nos APIs à travers ce type d’App ?