MyAgri
Application de gestion pour les exploitations agricoles
- Produit
- Projet privé
MyAgri rassemble au même endroit ce qu’un agriculteur suit aujourd’hui sur papier ou dans un tableur : ses parcelles, ses traitements phytosanitaires et les chiffres de son exploitation. Les contours de parcelles proviennent des données ouvertes du Service public de Wallonie, si bien qu’il n’y a rien à ressaisir au démarrage.
Le besoin de départ
Un exploitant jongle entre un tableur pour ses coûts, des documents papier pour ses traitements et un portail administratif pour ses parcelles. Rien ne communique, tout se ressaisit, et la moindre déclaration devient une chasse aux informations.
- Période
- Depuis 2025
- Rôle
- Conception du produit, de l’API et des interfaces
- Technologies
- FlutterSvelteKitTypeScriptNode.jsExpressMariaDBJWT
Ce que ça fait
Principales fonctionnalités
- Cartographie des parcelles, préremplie depuis les données ouvertes wallonnes
- Catalogue des produits phytosanitaires et de leurs substances actives
- Enregistrement des traitements, rattachés à la parcelle concernée
- Suivi économique de l’exploitation
- Interface multilingue
- Application mobile pour la saisie sur le terrain
Ma contribution
Le projet est le mien de bout en bout : modèle de données, API REST, interface web et application mobile. J’ai également repris deux fois la façade — d’abord un site statique, puis une application SvelteKit, enfin une application mobile — sans jamais toucher au cœur.
Aperçu
En images
Ce qui a résisté
Difficultés techniques
Les problèmes qui ont demandé une décision, et ce que j’ai tranché.
Problème 01
Les parcelles du Service public de Wallonie sont diffusées en shapefiles — un format géographique, pas un format web.
Solution
Les géométries sont converties et rattachées aux exploitations côté base, de sorte que le client ne reçoit que ce qu’il doit afficher. Le travail de projection et de découpage est fait une fois, au chargement des données, plutôt qu’à chaque ouverture de l’application.
Problème 02
Le catalogue phytosanitaire devait exister en plusieurs langues sans dupliquer les produits eux-mêmes.
Solution
Deux tables séparées : le produit et ses substances actives d’un côté, ses traductions de l’autre. Ajouter une langue devient une insertion de lignes, jamais une modification du schéma.
Problème 03
Le projet a changé trois fois de façade — site statique, application web, application mobile.
Solution
L’API et le modèle de données sont restés le point fixe. Chaque client successif a consommé les mêmes endpoints REST, ce qui a rendu ces changements bien moins coûteux qu’une réécriture. C’est le projet qui m’a le plus convaincu qu’une API stable est ce qui permet de changer d’avis sur l’interface.