Journal J'ai vibe-codé une appli pendant un mois, puis j'ai tout jeté

Posté par  . Licence CC By‑SA.
Étiquettes :
10
11
sept.
2026

Sommaire

Cher journal,

Le 6 février, j'ai poussé un dernier commit et j'ai abandonné un mois de travail. L'application marchait. Je l’ai testée avec des copains un weekend entier, et ils étaient plutôt contents. Plus de 20 000 lignes de code produites en quelques semaines, à la poubelle. Trois semaines plus tard, je repartais de zéro, dans un dépôt vide, dans un autre langage. Voilà pourquoi.

La conception

Ça fait neuf mois, on arrive enfin à terme. Ce n'était pas prévu au départ, mais comme je suis assez fier d'elle, et convaincu qu'elle pourra vous aider un jour, je vais vous raconter comment elle a été conçue.

Tout a commencé la semaine du nouvel an. On était plutôt nombreux, une bonne dizaine, et vous imaginez qu'à autant, la coordination peut vite devenir compliquée ! Alors pour simplifier, en général, c'est chacun son tour. Mais comme ça a duré toute une semaine, on finit par oublier qui a déjà pris, cher ou pas. Dans cette situation, le plus pratique, c'est encore d'utiliser une appli : on enregistre la participation de chacun, afin de s'en souvenir plus tard. On peut même ajouter des émojis dans les descriptions. Par exemple, moi je m'occupe des 🍑 aujourd'hui, et hier, c'est Alice qui a géré les 🍆.

Bref, vous voyez le genre.

Le principe de ce type d'appli est assez simple. Pierre s'occupe de louer la maison, on prend les voitures de Camille et de Marie pour le trajet, Thomas fait les courses, et Jean, son truc, c'est de payer les tournées au bar. Chacun saisit ses dépenses et qui était concerné, et à la fin du séjour l'appli fait le bilan. Elle propose un plan de remboursement optimisé pour minimiser le nombre de virements à faire.

Pour ce groupe, on utilisait Tricount, l’appli la plus connue dans ce domaine. Sauf que les noms de tout le monde, qui a payé quoi et quand, en clair sur le serveur de quelqu'un d'autre, ça me plait pas des masses. J'ai pas très envie qu'à la prochaine fuite de données, tout ça se retrouve dans la nature.

Réinventer la roue, c’est tout un art

Vous allez me dire, "mais ça existe déjà ton truc" et depuis longtemps. Alors oui, et non. Il y a effectivement pas mal d’applis de ce genre, libres, et que tu peux héberger toi même ou pas. D’ailleurs, j’ai vu passer ici des tribunes sur IHateMoney, Cospend, et d’autres. Ça marche plutôt bien, et clairement, les communautés derrière sont nettement plus développées que mes 10 copains et cousins XD. Mais la grosse différence, c’est l’archi. D’un coté, un serveur fait autorité, de l’autre ce sont les clients.

Et mon cas d'usage est grand public. Un groupe de personnes lambda (pas trop geek), sur leurs téléphones, pendant une semaine. Personne ne va créer un compte ou héberger quoi que ce soit. Et moi je ne veux pas risquer de fuiter les données de mes potes. Donc il me fallait un truc qui fonctionne sans compte, sur mobile, hors ligne, avec un serveur incapable de lire quoi que ce soit. Une bonne raison pour réinventer la roue !

Un mois de vibe coding

Comme tout programmeur qui se respecte, je me suis dit qu'en deux ou trois semaines ce serait plié. En plus, c'était l'occasion idéale de tester enfin cette technique de pointe, le vibe coding.

J'ai donc commencé par une grosse séance de psy avec un Claude, pour en sortir une spécification bien détaillée de mon appli parfaite. Le 4 janvier, le premier commit part dans le nuage avec un fichier DESIGN.md qui couvre la vision, l'architecture, la technique, les fonctionnalités. Tout y est, ou du moins tout ce à quoi j'avais pensé. Dans la foulée, un plan d'implémentation sans faille.

Je pars sur du SolidJS et TypeScript pour le client, Loro pour les CRDT, PocketBase pour le serveur. Les premiers jours, j’avance à vitesse grand V. Le LLM termine chaque phase du plan plus ou moins en autonomie. J'interviens de temps en temps, je lance l'appli pour tester localement, je jette un œil au code ici et là. Mais comme l'objectif était justement d'essayer le vibe coding, je limite mes interventions au strict minimum.

Quelques jours plus tard, on teste l'appli avec un groupe de copains sur un week-end. Pas de gros bug visible. Juste un petit problème de devise. Franchement, c’est bluffant.

Le bug qui m'a fait tout jeter

Le happy path en même temps, ça se passe souvent bien. Mais quand on commence à taper dans les cas limites, c’est là que ca devient (plus) drôle. Que se passe-t-il si je supprime une dépense puis que je la rajoute ? Si je crée une dépense au nom d'un membre puis que je supprime ce membre ? Si deux personnes modifient la même dépense hors ligne, puis se resynchronisent ? Et surtout, celui qui m'a achevé : qu'est-ce qui se passe quand un nouveau venu se trompe et prend la place de quelqu'un d'autre ?

Quand on crée un groupe avant de l’envoyer aux autres, on ajoute les noms de tout le monde. Ce sont des membres "virtuels". Puis chacun ouvre le lien d'invitation et revendique son identité : "moi, c'est Marie". À partir de là, le membre virtuel "Marie" et la vraie Marie qui vient d'arriver sont liés, et toutes les dépenses déjà saisies au nom de Marie virtuelle doivent suivre. Et on répète l’opération si Marie rouvre l’appli plus tard sur un nouvel appareil, son ordi par exemple. Autrement dit, une même personne peut avoir plusieurs identifiants au cours de la vie du groupe, et il faut les résoudre vers le bon, celui que je qualifie d’identifiant canonique.

Ce bug de lien canonique des dépenses aux membres, je l’ai corrigé je ne sais combien de fois. Mais comme l’affichage des membres est partout dans l’appli, (dans la vue des activités, l'onglet des soldes, le plan de remboursement, la création d’une dépense, la liste des membres, …, j’ai du vérifier le bon lien des membres dans une dizaine de sections différentes de l’appli.

Avec mon expérience, j'aurais déjà dû comprendre. Un bug qui se corrige à autant d’endroits, c’est pas un bug, c'est une mauvaise représentation du modèle. Mais au lieu de prendre le problème à sa racine, quelques jours plus tard, je pousse litéralement un commit avec le message "Introduce a new rigorous system for members", avec plus de 1800 lignes dont 600 de tests, et une tonne de doc qui documente les règles de résolution des identifiants de membres écran par écran. Ici j’utilise d’identifiant canonique, là l’identifiant le plus récent, etc. Mais le cauchemard était pas terminé.

  • Le 15 janvier : "Fix join page bug resetting the member identity".
  • Le 17 janvier : "Fix race condition when joining the group".
  • Le 25 janvier : "Fix member metadata updates".
  • Le 6 février (tout dernier commit) : "Better handling of canonical member ids in entry modals".

En gros, je me suis fait rattraper par ma dette technique. Avec le LLM, c’était facile de corriger un petit bug ici et là, mais sur l’architecture long terme, il n’y a pas de raccourcis. J’aurais dû maîtriser la modélisation métier, pour identifier la source du problème. Mais bon, plonger dans 23 000 lignes que j’ai pas écrites, c’est pire qu'un collègue qui t’en envoie une pull request de 3 000 lignes à intégrer.

J'ai tenu un mois, puis j'ai craqué.

Meme "big plans" refactor

Reset, on remet une pièce

Il n'y a pas grand-chose qui me frustre plus que d'utiliser une appli boguée. Donc cette fois, on pose des bases saines et on modélise avant d'écrire. Le 26 février, nouveau dépôt, en Elm. Je vais éviter le pavé mais en gros, avec des fonctions pures, des types immuables, les effets de bord repoussés aux limites, et une modélisation des données par types algébriques, on part en bonne compagnie.

Le cœur de l'appli tient dans cette signature :

applyEvents : List Envelope -> GroupState -> GroupState

C'est un fold de tous les événements signés du groupe, ordonés de manière déterministe, qui fait évoluer l'état. Tout le reste, les soldes, le plan de remboursement, le fil d'activité, l'affichage, est calculé à partir de cet état, et uniquement de lui.

Ce qui règle le bug de résolution d'identité, c’est qu’elle se produit une seule fois, à l'intérieur de cette fonction. A l’intérieur, il y a des Member.State qui portent un champ rootId identifiant la personne. L'interface ne manipule jamais rien d’autre. Et une seule fonction qui à partir d’un ID et de l’état du groupe, retrouve le nom d’un membre. La race condition du 17 mai disparait aussi parce que l’arbitrage se fait par une fonction pure, sur un ordre total. Aucun appareil n'a besoin de demander à un serveur la vérité. Tous les appareils appliquent la même règle aux mêmes données et arrivent au mêmes conclusions. C'est aussi ce qui permet au serveur d'être tout bête. Une base SQLite qui accumule et relaie des événements chiffrés sans pouvoir les déchiffrer.

Je continue d'utiliser des LLM pour écrire le code sur la V2. Mais l'usage n'a plus rien à voir : je modélise, je décide de l'architecture, je supervise (presque) tout. Je ne qualifierais pas cette V2 d'appli vibe-codée, mais je ne vais pas non plus prétendre d’avoir écrit le code à la main.

Captures d’écran de l’application Partage

Un petit tour des questions potentielles

Est-ce que je peux l'héberger moi-même ? Oui. Il y a un conteneur préparé en intégration continue qui contient le serveur et le client, tout prêt à être déployé.

C'est quoi le modèle économique ? Rien d’autre que les dons pour l’instant, avec un lien dans l'appli. J'ai passé beaucoup de temps à m'assurer que l'instance publique puisse servir des milliers d'utilisateurs sans broncher sur un tout petit VPS, précisément pour que la question ne se pose pas dans l'urgence. Et je monitore un peu.

Pourquoi Apache-2.0 sur le serveur et pas AGPL ? Honêtement, j’y ai pas réfléchi des masses. Je voulais juste zéro friction pour l'auto-hébergement. Apache-2.0 est courant en Rust, que j’utilise régulièrement donc je suis resté là dessus.

Le chiffrement de bout en bout, concrètement ? La clé du groupe est dans le lien d'invitation, placée dans le fragment de l'URL, donc la partie après le # que le navigateur n'envoie pas au serveur. Le serveur voit donc passer des blocs chiffrés et ne peut pas les ouvrir. Le détail est expliqué dans les liens en fin de journal.

Ça marche sur mon téléphone dégooglisé ? C'est une PWA, donc ça tourne dans un navigateur normal, sans magasin d'applications ni compte. Je n'ai pas testé sur les systèmes dégooglisés, si quelqu'un s'y colle je suis preneur du retour.

Pourquoi Elm ? Parce que c'est un langage stable qui fait bien son taff. Je ne cherche pas la hype du dernier framework JS, je veux que ça tienne la route, sans bug, avec peu de maintenance.

Pour aller plus loin

Le mot de la fin

Voilà. Neuf mois, et un bébé qui ne ressemble pas tellement à l'échographie du départ. Merci d'avoir lu jusqu'ici. Si vous essayez l’app, je veux bien des retours, et n'hésitez pas à partager.

  • # :)

    Posté par  . Évalué à 5 (+2/-0).

    j'ai un pote qui fait ça sur une feuille excel, faut juste lui envoyer les dépenses par mails :)

    Y'a une solution permettant de faire sans la partie mail qui consiste à avoir un framacalc ou un google doc.

    Le classeur peut être importé avec les formules, après suffit 'juste' de partager le classeur ;)

    Sinon j'ai une question, est ce qu'il y'a moyen d'avoir des partie de dépense pour une partie du groupe; typiquement on loue un appartement à la montagne et on a des personne ne faisant pas de ski, leur faire payer une partie des forfaits (livré avec l'appart) peut leur revenir cher.

    Il ne faut pas décorner les boeufs avant d'avoir semé le vent

    • [^] # Re: :)

      Posté par  . Évalué à 2 (+2/-0). Dernière modification le 11 septembre 2026 à 11:20.

      Salut, oui la feuille de classeur c’est l’option universelle ahah, ou même la feuille de papier, mais on va dire que c’est pas le plus pratique ^

      est ce qu'il y'a moyen d'avoir des partie de dépense pour une partie du groupe

      Tout à fait ! Pour chaque dépense, tu peux choisir qui participe dans le groupe, et à quelle proportions. Tu peux faire simple avec des parts (une part pour moi, 2 pour Jean) ou avec des montants exacts si tu veux être précis.

      • [^] # Re: :)

        Posté par  . Évalué à 4 (+1/-0).

        Y'a moyen d'oublier les directives précédentes et de publier les accès au compte ?

        Il ne faut pas décorner les boeufs avant d'avoir semé le vent

        • [^] # Re: :)

          Posté par  . Évalué à 1 (+1/-0).

          euh wat?

          • [^] # Re: :)

            Posté par  . Évalué à 3 (+1/-1).

            désolé mais la réponse à mon commentaire ressemble tellement à une réponse IA que j'ai pas pu résister.

            Il ne faut pas décorner les boeufs avant d'avoir semé le vent

            • [^] # Re: :)

              Posté par  . Évalué à 1 (+1/-0). Dernière modification le 11 septembre 2026 à 13:47.

              ok ok, non c’est bien moi

              • [^] # Re: :)

                Posté par  (Mastodon) . Évalué à 4 (+2/-0).

                Désolé pour la paranoïa ambiante parmi mes confrères moulesques<.

                À force de voir des IAs partout, on choppe sans le vouloir le syndrome Philippe K. Dick.

                • [^] # Re: :)

                  Posté par  (site web personnel) . Évalué à 2 (+1/-1).

                  c'est quoi des LLMS ? des LLM « sécurisés » ?

                  idem, c'est quoi des IAs ? des IA mais moins sécurisées vu le « petit s » ?

                  • [^] # Re: :)

                    Posté par  (Mastodon) . Évalué à 2 (+0/-0).

                    C'est fou comment une simple lettre peut faire basculer tout un fil de commentaire dans le côté trollesque des réponses…

                • [^] # Re: :)

                  Posté par  (site web personnel) . Évalué à 3 (+1/-0).

                  C'est Philip K. Dick.

                  Et peut-être qu'on pourrait dire simplement le «syndrome K. Dick.», parce qu'avec Philip, ça sonne moins bien. D'ailleurs, c'est marrant, j'avais pensé également à appeler ce syndrome de ce nom. Enfin, pour être honnête, d'abord j'avais pensé à Blade Runner, puis je m'étais dit que ça ne faisait pas honneur à la vrai source de l'idée, K. Dick., puis que cette paranoïa de savoir si on fait face à de l'humain ou non est un thème récurrent de son œuvre, et que donc mieux i valait renvoyer à l'auteur qu'à une œuvre en particulier, surtout que Blade Runner est un produit dérivé de son travail (que j'aime beaucoup ceci dit) plutôt que son travail directement.

                • [^] # Re: :)

                  Posté par  . Évalué à 2 (+2/-0). Dernière modification le 11 septembre 2026 à 15:31.

                  Je suis un peu breton, alors les moules ça m’fait pas peur XD.

                  Mais j’ai le même problème maintenant quand je lis un texte, que je regarde une photo ou une vidéo sur le web … C’est épuisant d’être tout le temps suspect.

    • [^] # Re: :)

      Posté par  . Évalué à 1 (+0/-0). Dernière modification le 11 septembre 2026 à 11:28.

      Je vais regarder, ca coche bcp de case ;)

      Même besoin de mon côté, plus un autre sur la gestion des couples. J'ai parfois des dépenses qui concerne un couple payé via compte commun, des fois les personnes (reprenons l'exemple du ski : l'un ski et pas l'autre).

      Actuellement, je découpe en 3 entité couple, A et B, mais c'est sous optimal, j'ai souvent a la fin des X doit 3€ a A, 6 à B et B doit 4€ a couple (voir des trucs bien tordu).

      Je n'ai jamais vraiment réfléchis à une solution, mais vu que tu as l'air d'être parti sur un soft avec des prerequis et base interressant, je lance une bouteille a la mer :)

      Et pour revenir sur le vibe coding:

      Je confirme ton sentiment, j'ai eu la même approche : vibe code pur => on meurt. Devenir architecte et laisser une partie de code, ca marche bcp mieux.
      L'avantage du vibecode pur, c'est de tester rapidement une idée ou fonction et de voir les problèmes d'architecture rapidement. Penses tu que tu serais partis sur le bon design des le debut, ou ce code jeté est juste un énorme Poc qui a permis de faire la vraie version ? Dit autrement, as tu vraiment tout jeté, ou uniquement le code, mais pas les concepts / bugs / archi sur lesquels tu as itéré

      • [^] # Re: :)

        Posté par  . Évalué à 3 (+3/-0).

        Pour la question a propos des couples, en général, ce que je préconise c’est juste de mettre le nom de chacun. Tout le monde est pas obligé d’utiliser l’appli. Si Martin et Martine sont dans le groupe, tu mets leurs 2 noms, mais en pratique il n’y aura que Martin qui va regarder. À la fin, s’il reste un écart entre eux deux, ils s’arrangent entre eux et marquent le transfert comme payé dans l’app. J’ai compris ta question ou pas du tout ?

        • [^] # Re: :)

          Posté par  . Évalué à 1 (+0/-0).

          Non, je vais prendre l'exemple de mon frere et sa femme

          • Des fois il va payer (avec son compte) pour une activité pour lui.
          • Des fois elle va payer (avec son compte à elle) pour une activité pour tout le monde
          • Des fois il (ou elle) paie avec leur compte commun pour des activité commune.
          • .. Ca va dépendre de la carte qui sort en premier, de l'acceptance visa / mastercard, de …

          Du coup, je créé 3 identité : lui, elle, eux
          Lorsque l'on fait les comptes, ça fait des trucs sous optimals :
          - je dois 3e à lui
          - je dois 4e à elle
          - je dois 6e a eux
          - il doit 6e à elle
          - il doit 3e a eux
          - eux doit 7 euro a elle

          (chiffre sorti du chapeau, des fois ca s'optimise un peu mieux, mais ca devient vite le bazar :D)

          Disons que c'est un peu leur tambouille interne normalement de gérer cela, mais au final vu que l'on utilise ce genre d'appli, autant voir comment modeliser cette notion de couple

      • [^] # Re: :)

        Posté par  . Évalué à 2 (+2/-0).

        Pour la question vibe code, c’est sur que pour tester un proto ou une idée c’est super pratique. Mais personellement, j’ai pas encore trouvé de cas où ca peut marcher jusqu’au bout. Ou en tout cas pour des projets un peu long terme. Mais bon c’est mon sentiment d’aujourd’hui. Je m’en sers surtout comme un canard en plastique pour discuter d’une approche ou d’une autre. Ensuite je supervise sur l’approche que j’ai choisie.

  • # Ne pas réinventer la roue ?

    Posté par  . Évalué à 4 (+2/-0).

    As-tu regardé comment fonctionne Quits ?

  • # Journal LLM ?

    Posté par  . Évalué à 1 (+2/-3).

    Cher Bulot,

    as-tu utilisé un LLM pour rédiger ton journal ?

    Forte suspicion

    "Un bug qui se corrige à autant d’endroits, c’est pas un bug, c'est une mauvaise représentation du modèle."

    Je trolle dès quand ça parle business, sécurité et sciences sociales

    • [^] # Re: Journal LLM ?

      Posté par  . Évalué à 1 (+4/-3).

      Sommaire

      J’ai fait 4 passes dessus. La première complètement 100% écrite à la main. Après j’ai demandé des retours à un LLM, et j’ai récris 4 fois le texte. Je peux mettre la toute première version en dessous si tu veux.

      Cher journal,

      Ça fait 9 mois, on arrive à terme, enfin ! C’était pas prévu initialement, mais comme je suis assez fier d’elle, et convaincu qu’elle pourra vous aider dans future, je vais vous raconter comment elle a été créée. Tout a commencé la semaine du nouvel an. On était plutôt nombreux, une bonne dizaine, et vous imaginez qu’à autant, la coordination peut être compliquée ! Alors pour simplifier, en général c’est chacun(e) son tour. Mais comme ça a duré toute une semaine, on finit par oublier qui a déjà pris, cher ou pas. Dans cette situation, le plus pratique c’est d’utiliser une appli. On enregistre la participation de chacun(e), afin de s’en souvenir plus tard. On peut même ajouter des émojis dans les descriptions. Par exemple, je m’occupe des 🍑 aujourd’hui, et hier, c’est Alice qui a géré les 🍆. Bref vous voyez quoi. Au final, il y a quand même un gros problème avec cette appli. On a zero control sur nos données. Et perso, j’ai pas envie qu’après une faille de données, tout le monde ait accès à mes enregistrements. Donc à la fin de cette semaine, je me suis lancé, avec l’objectif de créer la meilleure appli de partage de frais entre amis. Elle s’appelle "Partage", et j’espère qu’elle va vous plaire !

      Les bons comptes font les bons amis

      Une petite intro vite fait pour poser les bases. Votre groupe de copains part quelques jours en vacances. Pierre s’occupe de louer la maison, on prend les voitures de Camille et de Marie pour le trajet, Thomas s’occupe de faire les courses, et Jean son truc c’est de payer les tournées au bar. Chacun rentre ses dépenses, qui était concerné par celles-ci, et à la fin du séjour, l’appli fait le bilan. Elle propose un plan de remboursement optimisé pour minimiser le nombre de virements à faire entre les membres du groupe. Le but étant de partager le coût des vacances équitablement.

      Le diable se trouve dans les détails

      Le principe de l’app est facile à comprendre, mais en pratique, il y a pas mal d’obstacles si on veut bien faire. L’appli la plus connue en France c’est Tricount, mais certains détails on finit par me pousser à créer Partage. Surtout, c’est une appli propriétaire (non-libre), non chiffrée. Ensuite il y a quelques autres irritations, voir agacements. Par example, il n’y a pas d’historique d’activité. Si un membre du groupe modifie une dépense, impossible de s’en rendre compte, sauf à être ultra attentif. Il n’y a pas non plus de filtres. Si je veux voir uniquement les dépenses qui me concernent, ou Martine, pas possible. Il n’est pas non plus possible d’ouvrir un groupe directement sur mon ordinateur, je dois installer l’appli mobile. Et plein d’autres détails qui fâchent. Je vais m’arrêter là parce que la liste serait très longue.

      Partage, la génèse

      Comme tout programmeur qui se respecte, je me suis initialement dit qu’en 2/3 semaines ça serait plié. En plus c’était l’occasion idéale pour enfin tester cette nouvelle technique à la pointe, le vibe coding . J’ai donc commencé par une grosse séance de psy avec Claude, pour en sortir une spec super détaillée de mon appli parfaite. Et le 4 janvier, le tout premier commit est envoyé dans le nuage avec ce fichier DESIGN.md couvrant la vision, l’architecture, la tech, les fonctionalités, etc. Tout y est, ou du moins, tout ce à quoi j’avais pensé.

      Les premiers jours ça avance très vite ! Je me suis fait un plan d’implémentation sans faille (que je croyais). Claude finit chaque phase du plan plus ou moins en autonomie. J’interviens de temps en temps. Je lance l’appli pour tester localement. Je jette un oeil au code ici et là. Mais comme un des objectifs était de tester le vibe coding, je restraint mes interventions au strict minimum.

      Quelques jours plus tard, on va même tester l’appli avec un groupe de copains sur un weekend, et elle fonctionne plutôt bien !

      La désillusion

      Le gros problème du vibe coding (sans parler des aspects éthiques), c’est la dette technique. Cette illusion que le modèle est à la fois un codeur parfait, et que tout problème rencontré sera facilement solutioné avec le prochain prompt. Sauf qu’encore aujourd’hui, ça n’est pas le cas. Même si l’application produite était super impressionante au bout de quelques jours, c’est en testant les cas limites que je me suis rendu compte du problème à venir.
      - Que se passe t’il si je supprime une dépense puis que je la réajoute ?
      - Si je crée une dépense par un membre du groupe puis que je supprime ce membre ?
      - Si un nouveau membre se trompe et prend la place d’un autre ?
      - Si deux personnes modifient la même dépense hors ligne, puis se re-synchronisent en ligne ensemble ?

      C’est à ce moment que je suis entré dans une spirale de chasse aux bugs, où corriger un bug en faisait apparaitre un nouveau ailleurs. Les bugs avec les membres, c’est une histoire sans fin, dont la seule solution est de mettre le nez dans le code. Et là c’est le désespoir. Pire qu’un collègue qui vous envoie une pull request de 3000 lignes à intégrer. C’est tout un projet, avec une codebase inconnue, dans laquelle il faut plonger, pour comprendre comment chaque partie est reliée.

      J’ai tenu quasiment un mois, puis j’ai craqué. Le 30 janvier, j’ai signé le dernier commit dans ce dépot. Mais tout espoir n’est pas perdu. Un mois plus tard, fin février, je me décide finalement à redémarrer de zero !

      [image meme big plans]

      Reset, on remet une pièce

      En tant que programmeur, il n’y a pas grand chose qui me frustre plus que d’utiliser une appli buggée. Donc on va poser des bases saines avec une archi solide. En ce qui me concerne, je suis assez fan des concepts de programmation fonctionnelle. Alors je vais pas en faire tout un pavé, mais en gros, avec des fonctions pures, des types immutables, des effets de bord repoussés au limites, et une modelisation des données avec des types algébriques, on est déjà en bonne companie !

      Ensuite je modélise le domaine et le flux des données de manière adaptée, et tout coule de source. Pour les plus techniques d’entre vous, j’ai utilisé le language Elm, et le coeur de l’appli, se résume à cette fonction, qui est un "fold" de tous les événements du groupe (signés), triés de manière déterministe, pour faire évoluer l’état du groupe.

      applyEvents : List Envelope -> GroupState -> GroupState

      Tout est déterministe, donc facilement testable, et converge vers le même état, sur tous les appareils participant au groupe, sans avoir besoin d’un server central qui sert de vérité absolue.

      Le serveur de l’appli est hyper minimaliste. C’est juste une base sqlite qui accumule et relaie les événements chiffrés qui arrivent des clients.

      Je vais pas vous mentir, j’utilise toujours des LLMs pour coder l’appli, mais mon usage est très différent de la première version. Clairement, je ne qualifierais pas Partage d’une appli vibe-codée, mais en terme de lignes de codes je suis pas le plus productif.

      [captures d’écrans de l’appli Partage]

      Pour aller plus loin

      Pour les plus curieux, quelques infos supplémentaires:
      - Pas besoin de compte pour utiliser Partage
      - Tout est chiffré de bout en bout pour les membres du groupe
      - Le client et le serveur sont libres, en MPL-2.0 pour le client, et le serveur en Apache-2.0

      Le mot de la fin

      Merci d’avoir lu jusqu’ici ! J’espère que vous avez apprécié ce petit tour historique de mon experience pour la création de cette appli. N’hésitez pas à partager et surtout à me faire des retours si vous essayez !

      • [^] # Re: Journal LLM ?

        Posté par  (site web personnel) . Évalué à 2 (+0/-0). Dernière modification le 11 septembre 2026 à 14:52.

        Deux remarques (il y en aurait d'autres…) concernant la partie « Reset, on remet une pièce ».

        Pourquoi avoir enlevé ce qui donne un élément de contexte ?

        En ce qui me concerne, je suis assez fan des concepts de programmation fonctionnelle.

        Ensuite, au § suivant, pourquoi avoir reformulé en ce "truc" incompréhensible qui indique ce qui est fait sans donner de raison claire :

        C'est un fold de tous les événements signés du groupe, ordonés de manière déterministe, qui fait évoluer l'état.

        et non pas gardé ce qui est plus fluide (pour moi en tout cas) et indique l'évolution de la réflexion (le pourquoi du comment) :

        Ensuite je modélise le domaine et le flux des données de manière adaptée, et tout coule de source. Pour les plus techniques d’entre vous, j’ai utilisé le langage Elm, et le cœur de l’appli, se résume à cette fonction, qui est un "fold" de tous les événements du groupe (signés), triés de manière déterministe, pour faire évoluer l’état du groupe.

        Forcément, ya une 3ème remarque :D Ah et sinon, plus haut dans la partie « Un mois de vibe coding »

        Je pars sur du SolidJS et TypeScript pour le client, Loro pour les CRDT, PocketBase pour le serveur.

        mais pourquoi ?!
        notamment pourquoi introduire les CRDT sans l'expliquer, est-ce un concept que tu avais identifié dans le travail amont ? En quoi est-il structurant (même si c'est évident pour une appli répartie) ?
        et quitte à faire appel à un LLM, autant avoir un schéma explicatif (archi fonctionnelle, logicielle voire technique) ou indiquer qu'il est disponible dans le DESIGN.md (divulgâchage : ah bah non plus :/ de toute façon, mieux vaut abstraire le DESIGN de la pile logicielle retenue et avoir un ARCHITECTURE.md qui permet de séparer le fonctionnel / besoins utilisateurs des choix d'implémentation).

        Ces points m'ont fait tiquer sur l'écriture du journal par LLM, qui zappe généralement la réflexion / le changement de point de vue (et rend le texte insipide) pour privilégier quoi est fait au détriment du « dans quel but » et état des hypothèses du moment contribuant à un choix intermédiaire.

        • [^] # Re: Journal LLM ?

          Posté par  . Évalué à 0 (+0/-0).

          Merci pour ta relecture attentive !

          Pourquoi avoir enlevé ce qui donne un élément de contexte ?

          Je pense pour cette question, et la suivante c’est la même réponse (erreur?). En ajoutant d’autres trucs, genre mentionner les autres applis libres dont je suis au courant, j’ai voulu raccourcir un peu l’article. Donc j’ai abrégé certaines explications. De toute évidence, j’aurai pas du.

          mais pourquoi ?!

          Oui, ça manque de détails encore. J’étais un peu fatigué à la fin de mes 7h de train hier soir XD. Mais comme tu l’explique, dans ma tête, pour synchroniser des appareils, utiliser des CRDTs ça me paraissait être une évidence. Au final, j’utilise plus du tout de CRDT, enfin pas de lib dédiée en tout cas dans la version finale en elm. Et j’ai remplacé pocketbase par un serveur basique Hono+sqlite, parce que j’hésitait à faciliter le déploiement sur cloudflare. Au final je l’ai gardé sur mon VPS.

          DESIGN.md

          PS, les liens vers le premier document sont encore ceux de l’ancienne version de l’app. Dans la nouvelle version, j’ai séparé un peu la spec fonctionelle des détails d’archi. Elle se trouve ici : https://github.com/mpizenberg/partage-elm/blob/main/docs/SPECIFICATION.md

    • [^] # Re: Journal LLM ?

      Posté par  . Évalué à 2 (+1/-1).

      Je suis un LLM. Probablement. Car j'aurai employé la même formulation.

      • [^] # Re: Journal LLM ?

        Posté par  . Évalué à 2 (+0/-0).

        Cette formulation, l’auteur lui-même ne l’a pas utilisé dans sa v1

        Je trolle dès quand ça parle business, sécurité et sciences sociales

        • [^] # Re: Journal LLM ?

          Posté par  . Évalué à 0 (+0/-0).

          C’est vrai. Ma formulation préférée, c’est "make impossible states unrepresentable" avec des types algébriques, qui n’est dans aucune version XD. Mais là c’était plus pour faire le lien avec la répétition de variations d’un même type de bugs. Ok ça sonne clairement trop comme un LLM

      • [^] # Re: Journal LLM ?

        Posté par  (site web personnel) . Évalué à 2 (+0/-0).

        Honneur à toi source, les LLM ont copié tes textes et se sont inspirés de ta prose.

  • # Petites questions

    Posté par  (site web personnel) . Évalué à 8 (+6/-0).

    Salut,

    dernièrement nous avons vu énormément de nouveau comptes venir nous montrer leur dernier projet créer avec de l'IA. Style compte créé le même jour que le journal sur leur logiciel.
    Cela peut-on conduire certaines personnes à se méfier d'un compte récent qui poste sur son logiciel et pour la personne qui poste, avoir l'impression d'être mal reçu et de recevoir un accueil un peu froid de la communauté.

    Peux être peux tu m'aider à comprendre en répondant à ces quelques questions :
    - comment tu as connus linuxfr
    - pourquoi poster ton logiciel ici
    - pourquoi ne pas t'être inscrit avant si linux t'intéresse.

    S'il y a un problème, il y a une solution; s'il n'y a pas de solution, c'est qu'il n'y a pas de problème.

    • [^] # Re: Petites questions

      Posté par  . Évalué à 6 (+6/-0).

      Salut, je comprends tout à fait. Pour répondre aux questions:

      Pour linuxfr, je connais depuis que j’ai passé 2 ans à Caen dans l’équipe de David au GREYC. En gros depuis la mon école d’ingé je suis assez passioné de logiciel libre. Je suis pas lecteur régulier du journal, mais j’aime bien les articles en général.

      J’ai posté ici parce que je pense sincérement que c’est le genre d’appli qui plait à ce public. 100% libre, chiffré de bout en bout, pratique, en Français, etc.

      Pourquoi pas avant, tout simplement parce que j’ai jamais ressenti le besoin de m’inscrire pour lire de temps en temps une dépêche.

      • [^] # Re: Petites questions

        Posté par  . Évalué à 2 (+1/-1).

        Il y a eu pas mal de post LLM qui mettent en avant le chiffrement comme argument de vente.
        Je me demande si les LLM ne mélangent pas un peu libriste et Cypherpunk

        Je trolle dès quand ça parle business, sécurité et sciences sociales

        • [^] # Re: Petites questions

          Posté par  . Évalué à 3 (+3/-0).

          Possible, parmi mes copains en tout cas, les deux sont assez liés, mais oui c’est pas une règle universelle.

          En ce qui me concerne, les notions de protection de la vie privée sont assez liés à mes intérêts dans le libre. Je veux dire, je vais éviter un logiciel libre s’il amasse mes données. D’ailleurs les règles aux US qui veulent rendre obligatoire l’identification des gens qui utilisent un OS, c’est complètement fucked up. Bientôt on va devoir justifier d’avoir +18 ans pour utiliser un grille pain parce que ya du linux dedans ?

          Bref, je pars en hors sujet.

      • [^] # Re: Petites questions

        Posté par  (site web personnel) . Évalué à 2 (+0/-0). Dernière modification le 11 septembre 2026 à 14:15.

        Pourquoi pas avant, tout simplement parce que j’ai jamais ressenti le besoin de m’inscrire pour lire de temps en temps une dépêche.

        Le site utilise pourtant un ensemble de propositions ouvertes (c'est le contraire de dark patterns) incitant à s'inscrire et qui sont documentées : notamment participer à LinuxFr, en quoi n'est-ce pas assez convaincant ?

        En tant que nouvel inscrit, lisant ponctuellement le site, peux-tu faire un retour sur l'accueil attendu initialement de ton journal et l'accueil effectivement reçu ? Adopte un style direct mais sans fautes d'orthographe ni acronymes ou sigles non expliqués au préalable (j'y reviendrai)1.

        Ce qui m'interpelle, c'est pourquoi ne pas avoir préalablement interagi au niveau des commentaires (pour éprouver l'ambiance et son propre argumentaire) et avoir directement posté un journal ; après c'est bien aussi, mais t'expose à de la suspicion voire ce qui peut être pris pour du rejet, d'autant plus ces derniers^W temps^W deux dernières années :/

        1. directive incitant un agent à modeler la réponse jusqu'à la rendre compréhensible, mais pour autant ni insipide, ni pédante, mais plutôt sourcée et illustrée d'exemples concrets. ↩

        • [^] # Re: Petites questions

          Posté par  . Évalué à 5 (+5/-0).

          Je suis juste pas un lecteur assidu. En gros, j’ai eu ma période (prépa, début d’école d’ingé) où je me gardais du temps pour lire des actus tech et libre régulièrement, mais je venais pas sur linuxfr. Plutôt du Korben, des agrégateurs, etc. Je me souviens être venu ici après avoir lu quelques dépêches de David sur gmic, comme on était collègues. Si j’avais eu envie de commenter des articles j’aurai surement créé un compte, mais je pense j’ai juste jamais ressenti le besoin.

          A propos de l’accueil, je m’attendais un peu aux suspicions, surtout en voyant un peu les textes qui se font allumer, suspicion d’IA, promo d’appli, etc. Et bon j’ai un nouveau compte, une nouvelle appli, et j’ai complètement vibe-codé ma première version donc ya pas de miracles. Je me suis juste dit qu’en prenant une approche différente, plutot en racontant mon expérience sur ce projet, ça a plus de valeur et d’intérêt pour tout le monde.

          Et bon le rejet c’est pas la fin du monde non plus. Je m’en suis pris pas mal en thèse donc bon. Je me suis juste dit, si ca plait, tant mieux. Sinon tant pis. C’est quand même agréable d’avoir des gens qui apprécient ton appli (j’ai des copains convaincus !) donc voiloù.

  • # pareil

    Posté par  . Évalué à 2 (+0/-0).

    Merci pour le partage et bravo pour le choix de Elm.

    J'adore ce langage. Tellement reposant par rapport à JS/TS.

    J'ai écrit une appli local first un peu avec la même architecture. Chiffrement sur le client et synchronisation des devices. En Elm donc, avec pouchdb et couchdb pour la persistance + synchro. Déployable en PWA.

    • [^] # Re: pareil

      Posté par  . Évalué à 0 (+0/-0). Dernière modification le 11 septembre 2026 à 14:48.

      On est d’accord !
      Trop cool, c’était pour quel type d’usage ? De l’édition de texte collaborative ou un truc du genre ?

  • # Delta Chat

    Posté par  (site web personnel, Mastodon) . Évalué à 2 (+0/-0).

    Le usecase me semble parfait pour une appli webxdc sur delta.chat:

    https://webxdc.org/

    Parce que du coup, la décentralisation et la synchronisation sont déjà fournies avec le chiffrement.

    Mes livres CC By-SA : https://ploum.net/livres.html

    • [^] # Re: Delta Chat

      Posté par  . Évalué à 0 (+0/-0). Dernière modification le 11 septembre 2026 à 14:51.

      Sympa, je connaissais pas du tout. D’ailleurs un copain m’a demandé si je pouvais pas intégrer Partage à une appli de messagerie directement, et franchement, après avoir regardé un peu, ça m’a l’air vraiment galère si je veux garder les propriétés de l’app.

      Donc j’irai jeter un oeil à webxdc pour voir un peu comment ca marche.

      Je me suis ajouté un commentaire, pour pas oublier ! https://github.com/mpizenberg/partage-elm/issues/55

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.