Catégorie : Développement

  • Comment éviter les oublis de reproduction en ferme laitière

    Comment éviter les oublis de reproduction en ferme laitière

    Pour faire de l’argent sur une ferme laitière il faut… faire du lait!

    C’est une évidence, rien là de très innovant. Mais pour pour faire beaucoup de lait il faut quoi exactement?

    • Du confort pour les vaches,
    • Une alimentation de qualité,
    • Une reproduction au point

    Le reste compte pour bien peu. Avec ces trois points c’est garanti que le lait va couler à flots.

    La reproduction est probablement LE point le plus critique des trois. Il suffit d’un oubli pour perdre 21 jours. 21 jours, ce n’est pas seulement du temps : c’est du lait en moins, un vêlage retardé, une lactation compromise.

    Sur papier, ça semble simple. En réalité, entre les traites, les champs, les imprévus, il est facile de se fier à sa mémoire… et de se tromper.

    C’est pour ça que j’ai développé Farmitrax. Suivre les chaleurs dans un troupeau laitier présente des difficultés : il faut être précis, un oubli est vite punis. Il faut être observateur pour me rien manquer.

    Je ne voulais pas d’un système compliqué. Je voulais quelque chose de simple, rapide, adapté à la réalité d’une ferme laitière.

    Alors je l’ai fait simple, orienté vers les tâches à accomplir. Si vous voulez voir à quoi ça ressemble, j’offre 30 jours d’essai gratuit.

  • Havyn : une application de santé que personne ne m’avait demandée

    Havyn : une application de santé que personne ne m’avait demandée

    Il existe des milliers d’applications de santé, souvent basées sur le cloud. Suivi de pression, suivi de médicaments, journaux de symptômes, graphiques, alertes, comptes utilisateurs, synchronisation distante et abonnements mensuels. Pourtant, malgré cette abondance d’outils, aucune application de santé sans cloud ne faisait exactement ce dont j’avais besoin.

    Havyn est née de ce constat simple : quand on vit avec un suivi de santé réel, quotidien, imparfait, on n’a pas envie de gérer une plateforme. On veut juste noter, voir clair, et continuer sa journée.

    Pas de données dans le cloud

    Beaucoup de ces applications gèrent nos données dans le cloud. Ce sont « nos » données mais la réalité est qu’elles sont hébergées loin de nous, parfois hors du pays.

    De nombreux scandales font état d’informations personnelles perdues ou volées par des pirates. Ce n’est pas ici le simple statut d’un personnage de jeu vidéo, nous parlons des données les plus sensibles nous concernant.

    Havyn ne se connecte à aucun serveur distant, toutes vos données sont conservées dans votre appareil. C’est un principe de base : mes données de santé, ma responsabilité. L’application Havyn se contente de les stocker et de produire le Rapport Havyn à votre demande.

    J’ai donc cherché la simplicité maximale. Pour ce faire j’ai choisi une voie peu commune encore. Une voie qui, dans ce cas précis, me permettait de faire une preuve de concept.

    Un projet full AI

    Full AI? Vraiment? Oui. J’assume.

    Au niveau de la sécurité, le risque est volontairement maintenu à un niveau très faible. Aucun serveur n’est impliqué dans le traitement ou le stockage des données. L’exposition aux risques est limitée par conception, l’application fonctionnant entièrement en local sur l’appareil de l’utilisateur. Havyn ne contient aucune donnée permettant d’identifier une personne. Les risques se limitent donc essentiellement à ceux liés à l’accès physique ou logique au téléphone lui-même, comme pour toute information stockée localement sur un appareil personnel.

    Comment j’ai fait pour la créer? J’ai d’abord passé beaucoup de temps à réfléchir à ce que je voulais avoir comme app. Local bien entendu, un formulaire d’entrée des pressions, une page présentant les données, une liste des médicaments (très pratique), une page pour des notes et questions au médecin et une exportation en PDF d’un joli document.

    J’ai ensuite écrit un fichier AGENTS.md, une sorte de guide destiné à l’agent IA qui aurait le boulot de construire l’application. Ce fichier doit être très détaillé, allant de l’architecture à l’interface utilisateur. Tout doit y être pensé avec soin pour que l’agent puisse travailler à construire l’application attendue.

    Maintenant, au travail!

    Une fois ce travail terminé j’ai informé mon agent de la présence du fichier à la racine du projet et lui ai demandé s’il lui manquait des précisions. Je lui ai donné les derniers détails, je lui ai dit « OK, commence à coder » et je suis allé souper.

    À mon retour il avait terminé. Je suis allé voir le résultat et comme attendu ça ne fonctionnait pas vraiment… Pas grave: après inspection du code je savais ce qui clochait. Nouveau prompt avec les instructions nécessaires à la correction du code, nouvel essai: ça marchait! J’avais l’application que je souhaitais.

    J’ai par la suite fait quelques ajustements. Rien de fou, juste le nécessaire pour rendre l’application fonctionnelle et agréable à utiliser. Je l’avoue, je ne pensais pas que l’IA réussirait aussi facilement.

    Reste maintenant à la publier et à la faire vivre.

    Publicité vs payant…

    Il vient un moment où il faut choisir un modèle économique viable pour n’importe quelle application. Personne n’aime travailler pour rien, ni vous ni moi. Donc il faut prendre une décision difficile…

    Ma frustration envers les autres applications était en partie due à la publicité invasive et à leur coût élevé. Pas question de faire ce que je reproche aux autres, mais je veux aussi être payé pour mon travail.

    La solution évidente est de faire mieux que les autres. J’ai donc choisi de permettre une publicité sobre, un simple bandeau en bas de page. Mais il est aussi possible de retirer la publicité et de gagner l’accès à la fonction la plus importante de Havyn: la production de rapports PDF.

    Créer l’outil que j’aurais voulu trouver

    Havyn n’est pas une application pensée pour plaire à tout le monde, ni pour courir après des tendances. Elle est née d’un besoin concret, vécu, presque banal : mieux comprendre sa santé sans en faire un projet informatique. Si personne ne me l’avait demandée, c’est probablement parce que beaucoup de gens se sont habitués à des outils qui compliquent plus qu’ils n’aident.

    Peut-être que Havyn restera une application de niche. Peut-être qu’elle rendra service à quelques centaines de personnes, ou à quelques milliers. Mais si elle permet à quelqu’un d’arriver chez son médecin avec des données claires, fiables, et maîtrisées, sans abonnement abusif, sans collecte opaque, sans friction inutile, alors elle aura exactement rempli son rôle.

    Parfois, les meilleurs outils sont ceux qu’on crée simplement parce qu’ils devraient exister.


  • La Bête, projet exploratoire

    La Bête est un projet d’application narrative interactive, amorcé comme une exploration créative autour du récit, du jeu et de l’expérience utilisateur.

    L’objectif initial était de concevoir une plateforme permettant de créer et de vivre des histoires interactives, où le lecteur devient acteur du récit. Le projet m’a permis d’expérimenter différentes idées liées à la structure narrative, à la progression, à la persistance des choix et à la conception d’outils de création.
    Le projet est actuellement inachevé et en pause. Il demeure toutefois un terrain d’expérimentation important, tant sur le plan technique que conceptuel, et a influencé ma façon d’aborder la conception d’applications plus concrètes et orientées métier.
    Certaines idées explorées dans La Bête trouvent aujourd’hui un écho plus pragmatique dans d’autres projets, notamment dans la manière de concevoir des interfaces simples, évolutives et centrées sur l’utilisateur.

    Pour essayer La Bête, rendez-vous sur le site (non sécurisé…), créez un compte et allez vers le bois. Le village n’est pas encore créé mais vous pourrez quand même tester le petit moteur de combat.

    http://la-bete.atwebpages.com/

    Aperçu du module de combat
  • Dexie

    Dexie

    Quand j’ai commencé à travailler sur le mode hors ligne de Farmitrax, une application web de gestion de ferme laitière, j’ai rapidement compris que le choix de la couche de stockage locale allait être critique.

    Connexion instable, utilisateurs peu techniques, données sensibles, besoin de fiabilité : ce n’était pas un “offline sympa”, mais une vraie contrainte métier.

    Dans cet article, je partage mon retour d’expérience avec Dexie : pourquoi je l’ai choisi, ce que ça m’a apporté, les pièges que j’ai rencontrés, et dans quels cas je le recommanderais (ou pas).

    Le contexte : pourquoi le offline était non négociable

    • Producteurs en zone rurale
    • Connexion cellulaire intermittente
    • Saisie de données sur le terrain (étable, pâturage, déplacements)
    • Impossible de dire à un utilisateur : « reviens quand tu auras du réseau »

    Le offline n’était pas un bonus, c’était une condition de survie de l’application.

    Pourquoi Dexie plutôt que l’IndexedDB “pure”

    • IndexedDB est puissante mais pénible
    • API verbeuse
    • Callbacks / promesses difficiles à lire
    • Risque d’erreurs silencieuses
    • Schéma déclaratif
    • Syntaxe fluide
    • Gestion des versions de base
    • Performance très correcte pour des volumes raisonnables

    Dexie apporte une couche d’abstraction très propre : schémas clairs, requêtes lisibles, transactions compréhensibles. Pour un développeur solo, ça compte énormément.

    Ce que Dexie fait très bien en pratique

    • Cache structuré des données métier
    • Lecture instantanée hors ligne
    • Réactivité de l’interface
    • Développement plus rapide qu’avec IndexedDB natif

    Pour le CRUD local pur, Dexie est un vrai plaisir.

    Là où Dexie commence à montrer ses limites

    Synchronisation

    • Dexie ne résout pas la sync serveur
    • File d’attente, conflits, retries → à faire soi-même

    🔹 Logique métier

    • Le offline force à repousser de la logique côté client
    • Risque de divergence si mal conçu

    🔹 Debugging

    • IndexedDB reste opaque
    • Debug plus lent que du SQL classique

    Dexie simplifie IndexedDB, mais ne supprime pas la complexité conceptuelle du offline.

    Ce que j’ai appris (et referais différemment)

    • Définir le périmètre offline exact dès le départ
    • Séparer clairement :
      • données locales
      • état de synchronisation
      • source de vérité
    • Ne pas sous-estimer le coût mental du offline

    Le offline, ce n’est pas une feature. C’est une architecture.

    À qui je recommande Dexie (et à qui non)

    ✅ Je recommande Dexie si :

    • Application métier
    • Développeur solo ou petite équipe
    • Besoin offline réel
    • Données structurées

    ❌ Je serais plus prudent si :

    • Synchronisation complexe multi-utilisateurs
    • Besoin temps réel strict
    • Équipe backend très lourde

    Conclusion

    Dexie.js a été un excellent choix pour mon cas d’usage, mais ce n’est pas une solution magique.

    Il faut accepter que le offline impose des compromis architecturaux, et Dexie rend ces compromis plus lisibles, pas inexistants.

    Si vous construisez une application web sérieuse avec de vraies contraintes terrain, Dexie mérite clairement sa place dans votre boîte à outils.