Aller au contenu
Julien Fleuridas
EN — Switch to English
← Tous les projets

Produit · Développement

DayBrief

Une appli météo qui ne parle que quand c'est utile : un seul message le soir, et une correction si la prévision change vraiment.

Prototypeaoût 2026 — en coursProjet personnel

En résumé

Problème
Les applis météo affichent tout ce qu'elles savent, et c'est à chacun de trouver ce qui compte pour lui. On les ouvre souvent, et on en retient peu.
Solution
Un seul message le soir sur le lendemain, puis une seule correction si la prévision change vraiment. Des règles fixes décident de ce qui mérite d'être dit, sans jamais exagérer la certitude.
Ce que ça apporte
Plus besoin de regarder la météo : s'il y a quelque chose à savoir, on le reçoit. Sinon, l'appli se tait.
Où il en est
Prototype. L'appli tourne en mode démo et ses 420 tests passent, mais elle n'est pas publiée et les notifications n'ont pas été testées en conditions réelles.
Mon rôle
J'ai défini la promesse, les cinq règles, les seuils et ce que les tests devaient prouver. Le code a été écrit avec des assistants, sous ma direction.

Le problème

Une appli météo affiche tout ce qu'elle sait : la température heure par heure, le vent, l'humidité, la pression. C'est à chacun de faire le tri et de comprendre ce qui compte pour lui demain. On l'ouvre souvent, et on en retient peu.

L'idée

Pas besoin de regarder la météo. S'il y a quelque chose à savoir, on vous le dit.

Chaque soir, à l'heure choisie, un seul message sur le lendemain. Ensuite, l'appli surveille la prévision : si quelque chose d'important change, elle envoie une seule correction, qui dit ce qui a changé. Sinon, elle se tait. Et si demain est un jour ordinaire, elle le dit simplement.

Les cinq règles

  1. L'essentiel, pas tout. Une donnée n'est pas affichée juste parce qu'elle existe. Un vent normal n'est jamais mentionné.
  2. Pas de fausse précision. Avoir des données heure par heure ne veut pas dire connaître la météo à l'heure près. Le message parle de « fin de journée ».
  3. Aucune IA n'invente la météo. Le message est construit par des règles fixes et des phrases écrites à l'avance. Rien ne peut être inventé.
  4. Discrète par défaut. Un message le soir, une correction au maximum, jamais de notification pour faire revenir l'utilisateur.
  5. Jamais plus sûr que les données. Selon la confiance, le message dit « prévu », « probable », « possible » ou « incertain ».

La troisième est celle qui compte le plus. Une IA générative aurait rendu le message plus fluide, mais elle aurait pu, un soir, annoncer une pluie qui n'existe pas. Pour une appli dont tout repose sur la confiance, le risque n'en vaut pas la peine.

Où elle en est

Les 420 tests passent, dont des tests de référence qui échouent dès qu'une règle change. En revanche, l'appli n'est pas publiée, et l'envoi des notifications n'a pas été testé en conditions réelles. C'est un prototype.

Chiffres

420

tests automatisés qui passent

le moteur météo et les écrans, sur 22 séries de tests

Source · npx jest, exécuté le 30 septembre 2026

Ce que j'ai fait

  • Design produit

    J'ai fixé la promesse et les cinq règles qui tranchent chaque choix : dire l'essentiel, ne pas faire semblant d'être précis, se taire par défaut.

  • Création des règles

    J'ai défini les seuils : un vent normal n'est jamais mentionné, un degré d'écart ne vaut jamais un message.

  • Définition du besoin

    J'ai écrit tout le fonctionnement, du message du soir à la décision d'envoyer, ou non, une correction.

  • Tests

    J'ai fait écrire des tests de référence qui échouent dès qu'une règle change.

  • Développement assisté

    L'application et son moteur ont été construits avec des assistants de code.

Preuves

  • 420 tests qui passent

    vérifié

    Le moteur météo et les écrans sont couverts par des tests, dont certains vérifient ce que le message dit, et ce qu'il ne doit pas dire.

    Source
    suite de tests du dépôt
    Vérifiable par
    Exécution complète le 30 septembre 2026 : 22 suites, 420 tests passants.

  • Aucune IA n'invente la météo

    vérifié

    Le message est construit par des règles fixes et des phrases écrites à l'avance. Rien ne peut être inventé, chaque message coûte presque rien, et le résultat est toujours le même pour les mêmes données.

    Source
    documentation d'architecture du dépôt
    Vérifiable par
    Lecture de l'architecture et de la chaîne de traitement.

  • Des règles écrites et faciles à régler

    vérifié

    Chaque seuil (vent, température, pluie) est défini à un seul endroit. Le modifier fait échouer un test : aucun changement ne passe inaperçu.

    Source
    documentation des règles produit
    Vérifiable par
    Lecture des règles produit et du fichier de seuils.

Limites

  • Pas encore publiée sur l'App Store ni sur Google Play, et pas d'utilisateurs pour l'instant.
  • Les notifications envoyées depuis le serveur n'ont pas été testées en conditions réelles.
  • Les seuils sont des choix de produit à tester, pas des vérités météo.
  • Le code a été écrit avec des assistants : ce que ce projet montre, c'est la conception du produit et de ses règles, pas une maîtrise de React Native.
  • Le code est privé, il n'est donc pas consultable depuis ce site.

Ce que j'en retiens

  • Choisir de ne pas utiliser d'IA générative est aussi une décision produit. Quand toute la valeur repose sur la confiance, une seule phrase inventée coûte plus qu'elle ne rapporte.
  • Décider de ce qu'on ne dit pas demande plus de règles que décider de ce qu'on dit.

Ce que ça peut apporter à une entreprise

  • Toute notification client (livraison, facture, alerte) gagne à suivre la même règle : un message quand il y a quelque chose à dire, une seule correction, sinon rien.
  • Séparer les règles qui décident de la façon de le dire vaut pour tout produit où une erreur fait perdre la confiance.

Technologies

  • React Native
  • Expo
  • TypeScript
  • Supabase
  • PostgreSQL
  • Open-Meteo
  • Zod
  • Jest