[Proposition] Une plateforme de petites annonces simple, compatible Duniter V2 sondage d'intérêt avant de coder

R&D
,
1

Bonjour à tous,

Avec l’arrêt de la V1 et le passage à Duniter V2, Gchange se retrouve sans backend fonctionnel depuis un moment. Le sujet Gchange v2 : modération ou/et fédération ? posait déjà la question il y a plus d’un an, sans qu’un projet concret n’émerge à ma connaissance. Je voudrais relancer la discussion avec une proposition concrète et volontairement simple, et avoir vos retours avant de me lancer dans le développement avec Claude AI.

Pourquoi repartir de zéro plutôt que d’adapter Gchange

L’architecture historique (pod Cesium+/Gchange en Java + ElasticSearch + fédération multi-pods) est lourde à maintenir pour ce que fait réellement le service : afficher des annonces et permettre une mise en relation. Avec Duniter V2 :

  • Le format d’identité change (adresses plutôt que clés publiques brutes), donc une bonne partie du code client est à refaire de toute façon.
  • Les paiements restent strictement wallet-to-wallet, on-chain. Le site n’a jamais besoin de toucher à des fonds ni même de connaître un solde, il affiche juste une adresse Ğ1 et un montant indicatif. Ça simplifie énormément ce qu’on doit construire : pas de logique de paiement à sécuriser, juste de la donnée hors-chaîne (texte, photos, géoloc).
  • ElasticSearch est un service supplémentaire à opérer pour un volume de données qu’une recherche full-text PostgreSQL classique (tsvector + index GIN) gère très bien à l’échelle de la communauté Ğ1.

Proposition d’architecture

  • Backend : Node.js/Express + PostgreSQL (recherche full-text native, pas d’ES).
  • Authentification : signature de message avec le wallet (pas de mot de passe), à la manière de “Sign-In with Ethereum”, possession de la clé = preuve d’identité.
  • Statut de membre : interrogation directe d’un nœud Duniter V2 (RPC Substrate) pour afficher un badge “membre certifié”, sans dépendre d’un pod tiers ni dupliquer la toile de confiance.
  • Paiement : génération d’un lien/QR code pré-remplissant une transaction (montant + adresse + référence) que l’acheteur ouvre dans son wallet (Cesium²/Ğecko). Le site n’orchestre rien, il ne fait qu’assister la saisie.
  • Photos : stockage simple sur le serveur ou un object storage S3-compatible.
  • Hébergement : une seule instance pour démarrer. Pas de fédération multi-pods dans une v1, on pourra en rediscuter si plusieurs instances voient le jour, mais je pense que ça peut attendre.

Claude AI a esquissé un premier schéma de base de données (wallets, annonces, catégories, photos, messages, avis) je peux le partager en réponse si ça intéresse quelqu’un.

Ce que je cherche avec ce post

Avant d’investir du temps de développement, j’aimerais avoir vos retours sur :

  1. Existe-t-il déjà un projet en cours que je ne connaîtrais pas (au-delà du sujet de 2025 cité plus haut) ?
  2. Le choix techno (Node/Express/PostgreSQL plutôt que Java/ES) vous semble-t-il pertinent, ou y a-t-il des raisons de garder l’architecture pod/ES que je n’aurais pas en tête ?
  3. L’authentification par signature de wallet : des retours d’expérience de ceux qui l’ont déjà implémentée sur Duniter V2 ?
  4. La modération : avec un seul site centralisé (pas de fédération), comment gériez-vous ça sur Gchange ? Des pièges à éviter ?

Je ne suis pas développeur de métier (chef de projet digital de profil, avec 20 ans d’XP web/WordPress/SEO) j’avance avec l’aide d’IA pour la partie code, donc toute relecture technique sera particulièrement bienvenue.

Merci d’avance pour vos retours !

2

As-tu vu le dernier point que j’ai ajouté sur la charte ? Charte du Forum - #6 by HugoTrentesaux

Sauf pour les crowdfunding.

Ça impose des contraintes sur la modération.

  • rate limiting / quota par clé ?
  • toute clé est autorisée à poster ou seulement sur invitation ?
  • qui est dans l’équipe de modération et qui a le droit de supprimer une annonce de vente d’arme ?

Oui, de mon côté je travaille sur un framework d’indexeur distribué et un ré-écriture de Ğchange pour la démo, mais c’est pas mature ni certain d’aboutir, donc je n’en parle pas pour l’instant.

Ça c’est une question de goût, pas de nécessité de conserver l’existant, mais une remarque quand même : avec l’archi actuelle c’est très simple d’ajouter un modèle de document (par exemple les notifs de commentaire à une annonce, les like sur un profil / annonce…), alors que là il faut écrire une nouvelle table et faire une migration. Pas de soucis sur une instance unique car une seule personne s’occupe des mises à jour, mais plus difficilement compatible avec un fonctionnement décentralisé donc potentiellement limitant pour des évolutions futures.

C’est Ğ1companion qui est le plus en pointe là dessus (projet à l’arrêt), mais on peut aussi adapter Duniter Connect à ce cas d’usage.

Pour moi c’est le gros point (j’ai répondu au fil de ma lecture, voilà pourquoi je l’aborde plus haut). De mémoire de ce que j’ai compris, mais à vérifier en lisant le code, une instance Gchange/Cesium+ nomme des modérateurs par clé publique et accepte des opérations particulières de suppression de contenu. Il faut faire confiance à ses modérateurs ou alors mettre un système de relecture : deux ou trois signatures sont nécessaires pour supprimer un profil / une annonce.

Je pense que tu arriveras plus vite au bout avec une approche centralisée que moi avec une approche indirecte où je commence par faire un framework pour ensuite coder une appli décentralisée. Je serai ravi de te faire des retours au fur et à mesure si je constate que tu fais des efforts de conception et que tu ne te contentes pas de vibecoder sans réfléchir :smiley:

3

Merci pour ces retours précieux !
Effectivement, le point noir si je m’y mets et que j’aboutie à quelque chose de correcte sera la modération, je ne sais pas encore comment “choisir, sélectionner” une équipe de modérateurs-trices…

Je ne pense pas migrer toutes les annonces actuelles de Gchange, je pense qu’il vaut mieux repartir de zéro et que les gens prennent le temps de poster de nouvelles offres/demandes.

Autre point, lié aussi à la modération finalement, je pense, c’est que cela ne reparte pas avec toutes ces annonces de “soins” de tous types comme soulevé sur l’autre forum qui fait couler beaucoup d’encre…

Pour les crowdfunding en monnaie libre, je ne suis pas certain que cela a sa place dans un site de petites annonces, je pense qu’un outil dédié est plus judicieux, à mon humble avis.

Je prends bien notes de tes réflexions, merci encore. :slight_smile:

4

@HugoTrentesaux Comme tu le mentionnes dans la charte qu’effectivement je n’avais pas vu, voici une autre réponse formulée par Claude AI en fonction des ressentis et de mes questionnements :

5

pour etre passée par là en fait il faut ajouter des quote avant et apres
![quote=“Claude”]
texte
[/quote]

enlève le ! avant
pour obtenir

6

Je viens d’essayer en éditant mon message mais ça ne fonctionne pas…

7

J’ai galéré un moment avant d’y arriver et ça fonctionne si tu passes en version édition le M a gauche du A. En fait il ne faut aucune amélioration de texte sinon ça capote. Sur l’ordi tu as une deuxième fenêtre qui s’affiche avec le résultat

8

Tu as mis des $$, c’est pour le

\int_0^\infty \LaTeX

Pour les quote, il faut :

[quote="Claude"]
[/quote]

Autour du texte.

9

Je n’ai aucun avis technique sur les solutions à adopter pour le remplaçant à Gchange. Juste 2 ou 3 tips:

1: la mise à jour doit pouvoir être faite par n’importe quel développeurmodérateur

2: l’application ne doit pas dépendre d’un seul serveur pour éviter les shut down

3: la messagerie pair à pair doit permettre d’initier l’échange ou n’importe quel dialogue entre 2 interlocuteurs (c’est, à mon sens, ce qui crée actuellement le plus de casse dans l’upgrade de la bockchain)

4: quant au fait d’interdire les propositions alternatives de soins, ne serait-il pas plus judicieux de les faire taguer comme «soins alternatif» ou autre dénomination? Car si je ne suis pas client, je respecte néanmoins les besoins de chacuns, tant que les propositions sont bien identifiées. Imho

4: remplacer tous les « doit » ou autre injonction impérative par « serait souhaitable » :wink:

10

Sur les soins alternatif, je rejoins @Iznogood : sur le fait d’avoir un tag plutôt que de chercher à les interdire.
Selon moi, il sera bien plus facile de masquer la catégorie aux personnes que ça n’intersse pas si ces offres sont correctement catégorisé que si justement elles n’ont pas de catégorie et donc que les offrant les insèrent de manière détourner et donc bien plus difficile à cibler.

Si je prend l’analogie avec les contenu pornographique, c’est plus simple d’avoir une catégorie NSFW et de la masquer par défaut et de demander une vérification d’age pour la dévérouiller que de devoir analyser chaque contenu avec des algo de reconnaissance certe relativement performant, mais qui risque de ne pas différencier pornographie, et photo d’environnement natursite (sans dimension sexuelle), ou tableau d’art représentant du nue… (alors que que fournir des tag pour ça permet de catégoriser assez simplement, et de choisir ce qui est afficher ou masqué par défaut).

Je rejoins @HugoTrentesaux sur le fait que développer un site de petite annonce centralisé ira bien plus vite que de concevoir ça de manière décentralisé. En revanche, je préfère m’atteller à la seconde plutôt que de m’engouffrer dans la première pour les raisons suivantes :

  • sauf à s’être accordé sur une structure de contenu signé par les auteurs pour pouvoir décentraliser ensuite, le jour où une plateforme décentralisé est développé, pour qu’elle prenne il faudra que chaque offre soit re-saisie par les vendeurs. Et si le marché est déjà trop petit pour avoir régulièrement des acheteur pour ses offres, la motivation à s’inscrire et à re-saisir ses annonces sur N site risque de chuter.
  • si le site centralisé marche bien, son hébergeur (qui est peut-être aussi l’auteur) risque de devenir réticent à “perdre son bébé” en le rendant décentralisé, voir pire, il risque de vouloir tirer profit de la communauté capturé par la centralisation, et faire évoluer son site d’une manière où les intérêt de la communauté ne priment plus sur ceux du concepteur/hébergeur. C’est ce qui s’est passé pour covoiturage.fr (devenu blablacar), mais aussi pour couchsurfing, dans une certaine mesure aussi pour le site de Woofing… Bref, le pouvoir corrompt et la centralisation donne du pouvoir, donc je préfère prendre le temps de construire quelque chose de différent plutôt que de m’empresser de refaire ce qui produit les travers que je souhaite combattre.

Mais si tu veux t’y essayer, libre à toi, peut-être me montreras-tu que mes vigilances étaient superflues.

11

Salut @1000i100 merci pour ton retour.
Je comprends ton point de vu sur les annonces de soins et sur le fait de faire ou pas un site d’annonce centralisé ou décentralisé…
En fait, pour le côté centralisé, c’est juste que cela serait plus simple pour moi qui suit non-développeur. Effectivement quand on construit seul un site de A à Z en centralisé, en général c’est notre bébé comme tu le dis, donc, je vais peut-être m’abstenir et vous laissez faire ce qui est le mieux pour la communauté.
Bien à toi, Francis

12

Oui mais ces gens de pouvoir utilisent la flemme et le conformisme, donc les premiers à mettre en place une plateforme raflent la mise pour l’éternité, donc jamais mobicoop montera, etc… je caricature.

Je ne suis pas sûr que dans la june cette théorie de la flemme fonctionne, on voit comment gecko ou d’autres peuvent augmenter leur base d’utilisateurs.

13

@fdrubigny j’aurais bien plus envie de t’encourager à travailler avec nous à une version décentralisé plutôt que de te dissuader avec mes propos :confused:
Autant je comprends que les briques socles de gestion des données en décentralisé puisse être difficile pour un non dev, autant tout ce qui est conception de l’interface, je pense qu’on peut y travailler ensemble, ou faire chacun à notre gout, mais avec la même couche de données derrière, donc afficher les mêmes annonces depuis une interface différente. un peu comme capitain-train et sncf-connect ou le site des TER qui sont des sites différents, avec des interfaces différentes, mais qui présente et agissent sur les même données (bon dans leur cas c’est pas décentralisé, c’est seulement une api vers un même centre sous le capot, mais ça permet d’avoir une idée).

En gros, déployer notre créativité dans l’UX/Design/ergonomie, tout en gardant l’interopérabilité des données pour qu’une annonce saisie via un des sites soi visible et utilisable via tout les autres, ça, ça me semble top, que ce soit pour faire des portails spécialisé (RbNjune pour le logement, mais en décentralisé pour qu’il ne subisse pas le même sort que l’actuel, junted pour les fringue…), mais que s’il y a une ou plusieurs version généraliste à la gchance, elle affiche aussi le même catalogue. Résultat, au lieu de capturer la communauté en ayant leur donnée au dépend des autres plateformes, ont mutualise les données et on facilite l’émergence d’intiative qui améliore plutôt que de les faire se heurter au fait que si on trouve rien sur leur site la commun continue d’aller sur le site historique, même si son interface est moins bonne.

@hypericum justement, si gecko avec sa propre blockchain et ne donnais pas accès au compte accessible via cesium, qui irais sur gecko en repartant à 0 ? C’est bien parceque gecko est une interface vers des données décentralisé que c’est selon moi une avancée plutôt qu’une régression. Je suis peu enthousiaste à reprendre une toile de confiance à zero :wink:

Du coup, pareil coté annonce, si on peut avoir une couche de données commune, je pense qu’on s’en portera beaucoup mieux, et ça pourra permettre d’avoir des site/app/interface qui filtre les annonce de soin alternatif sans les afficher, et d’autres qui y soit dédié si quelqu’un veux en développer une.

14

C’est quoi leur sort actuel ? Les deux sont toujours maintenus et focntionnels…

15

Le sort que j’avais constaté il y a quelque temps ne concernait pas junted mais seulement airbnjune et de ce que j’avais compris, le développeur était injoignable et le site en partie planté (les email ne partaient plus pour avertir les hébergeurs des demandes si j’ai bien suivi, bref le site parraissait fonctionnel tant qu’on le regarde mais ne l’était pas quand on voulais l’utiliser, il y a 6 mois ou 1 ans je dirais). Et il y avais un projet de reprendre le concept et de faire un nouveau airbnjune, avec un dev actif derrière, ou un collectif. Je ne sais pas si c’est toi le nouveau dev qui à repris, ou si c’est toi qui était réputé injoignable et qui est revenu.
Je n’ai pas suivi de très près, donc j’ai peut-être compris des choses de travers, désolé de t’avoir peut-être vexé/offensé.

Le souci que j’ai en revanche, qui pour l’instant n’est pas bien grave mais que je trouve domage à terme, c’est que les catalogues de ces sites (juneted, airbnjune) sont spécifiques au site, donc si demain je fait un portail généraliste, il va commencer vide plutôt que de pouvoir hériter des annonces existantes sur ces deux sites (sauf à faire du scrapping), et si sur le portail généraliste des utilisateurs ajoute des vêtements, ou des offres d’hébergement, elles ne seront pas automatiquement reprises et inséré sur juneted ou aribnjune selon les cas (sauf scraping du portail généraliste par ces deux sites spécialisé) Et même avec du scrapping, ça ne permettrait que d’avoir les annonces, probablement pas de pouvoir contacter le vendeur derrière.

Bref, le découplage “catalogues/comptes” → décentralisé et interface (centralisé ou non, ça à moins d’importance) me semble essentiel pour construire un écosystème coopératif plutôt que concurrentiel.

16

Salut @1000i100 c’était en 2024 où j’étais en formation et en mauvaise santé que j’ai répondu aux gens sur Airbnjune avec beaucoup de retard… effectivement le système d’envoie des emails depuis le site était KO et je l’ai corrigé avec un relai SMTP…
J’ai créé le site de A à Z et je le maintien toujours depuis à jours, je réponds aux emails des utilisateurs, je créé les comptes “propriétaires ou owner sur le site”, je valide les annonces quand le minimum requis est là etc. Bref, je ne suis jamais ni parti ou revenu, juste un temps de réponse plus long aux gens pendant quelques mois, rien de bien grave à mon sens, je ne suis pas un service client rémunéré comme tel.

Revenons à nos moutons.

J’ai commencé à faire coder Claude IA, je souhaitais pouvoir faire en sorte que les gens puissent se connecter avec leur Wallet, mais pour se faire il faut avoir l’extension de navigateur Duniter Connect d’installé.
Pour ma version locale, j’ai donc installé Duniter Connect, j’ai renseigné ma phrase seed mais à l’étape suivante, cela mouline en recherchant les Wallets associés à cette phrase…
De plus on est obligé de taper la phrase seed en anglais, il n’accepte pas le français, donc il faut passer la phrase par le convertisseur : multilang-mnemonic-converter-4cc524.pages.duniter.org

Du coup Claude IA me dit que tant que cela n’est pas stable du côté de Duniter Connect, je ne peux pas avoir cette fonction de se connecter au site via mon Wallet.

Il me propose, pour la version test en local de simplement modifier le fichier de connexion en mettant simplement l’adresse Ğ1 mais cela implique qu’il n’y a plus la signature… c’est pas terrible à mon sens.

Saurais-tu débuguer Duniter Connect ?

Bel après-midi.

Edit:

Pour Duniter Connect, en fait c’était juste le endpoint dans les paramètres qui n’est pas joignable, je peux donc continuer mes tests…

17

C’est même plus général, ça touche à toutes les données hors chaîne, dont Cesium plus.

Moi aussi je voudrais avancer sur la discussion des Nodes > Datapods avec une proposition concrète, mais pas simple car je veux du p2p et que le p2p c’est pas simple et très différent de ce dont on a l’habitude.

Et moi je voulais pas “occuper l’espace” comme je l’ai fait avec les datapods v1 avant d’avoir une PoC qui m’inspire confiance pour construire dessus pour la suite, donc j’ai fait bosser Claude en secret.

Parce que le mécanisme de synchronisation des pods Cesium/Gchange me semblait trop lourd et hasardeux, et ne répondait pas aux enjeux du p2p en pratique, ce qui nous a forcé à dépendre de peu d’instances plus ou moins bien maintenues. J’ai voulu repartir de zéro sur des primitives plus ancrées sur l’existant (IPFS, Iroh) avec les innovations nécessaires à notre cas d’usage.

Pour moi ça n’a aucune importance tant que la crypto utilisée est la même, en l’occurrence ed25519. J’ai fait le choix de partir sur ed25519 seul, mais on pourra introduire du multi-algo en temps opportun.

Ça va même plus loin que ça : le site n’a besoin d’aucun lien avec la Ğ1, il peut être totalement indépendant. Mais ces fonctionnalités peuvent être apportées plus tard via un connecteur par exemple. Il faudrait donc brancher les données de la blockchain sur le système de données. Cela permettrait notamment de suivre l’avancement d’un financement participatif.

Je suis d’accord dans un premier temps, cela pourrait suffire. À terme il faudrait réfléchir à une alternative p2p à meilisearch, si ça se montre nécessaire et possible.

  • Backend : Rust Iroh + base de données requérable par SQL mais sur prolly tree content addressed.
  • Authentification : signature cryptographique de chaque action, tout comme les extrinsics
  • Statut de membre : pas dispo avant le connecteur Duniter, mais toile de confiance simplifiée intégrée pour les “inscriptions”.
  • Paiement : comme toi, lien/QRcode du type Ğ1lien ouvrant un wallet tiers avec paiement prérempli, en attendant qu’on intègre ça à l’appli (assez simple avec la Ğ1 lib ou Polkadart)
  • Photos : sur le blocstore Iroh comme tout. MAIS : c’est le plus lourd (33 Go pour les photos de Ğchange par exemple), donc il faut que ce soit stockable sur des nœuds spécialisés. Pour l’instant ça reste gérable, avec 1To, on devrait couvrir les besoins de la communauté pendant un moment, mais il faut prévoir :
    • un système de nettoyage pour que les photos soient supprimées quand elles deviennent inutiles
    • un système de thumbnailing pour les vues listes
    • un système de quota / paiement de stockage pour les utilisateurs qui abusent du système gratuit qu’on leur offre
      À noter que comme c’est en p2p, tant qu’un utilisateur sert les photos sur le réseau, elles seront récupérables.
  • Hébergement : j’hébergerai et maintiendra une instance principale de bootstrap, mais encouragerai et formerai d’autres à lancer les leurs. Chaque appli desktop sera un nœud utile au réseau. Les applis mobiles seront aussi p2p mais en mode “léger”, elles participeront moins au réseau. Donc hébergement distribué à plusieurs niveau de responsabilité. Registre des clés publiques des hébergeur intégré.

Claude a entièrement codé un prototype que je vais vous présenter sous peu (j’espère avant l’Ağora 2026).

Signaler à la communauté Ğ1 que je pense toujours à elle. J’ai donné mon avis sur les annonces Ğchange, notamment l’excès de soins douteux et les problématiques de harcèlement dans les commentaires. Je souhaite apporter des solutions à ces problèmes en mêlant les aspects techniques et humains comme je l’ai toujours fait. Je respecte les gens qui ne pensent pas comme moi et tiens absolument à leur liberté d’expression. Mais je souhaite également protéger les personnes à qui je recommande la monnaie libre des escrocs et charlatans. J’ai trouvé une manière de concilier les deux, je vous la présenterai.

Je ne suis pas développeur de formation, mais grâce à la monnaie libre le suis devenu de métier. Je suis reconnaissant envers toutes les personnes patientes qui ont contribué à me former en échangeant avec moi et en me faisant des retours, notamment @gerard94 @poka @elois @cgeek @Pini @aya @1000i100.

J’ai hâte de pouvoir dire ça en présentant Ğchange v2 :wink:

  • raison 0 : le p2p m’amuse, le centralisé m’ennuie
  • raison 1 : je ne veux que la responsabilité technique, pas celle de la modération (cf mon article de blog)
  • raison 2 : je pense que c’est une garantie démocratique et une condition pour arriver à fédérer une gauche qui est d’accord sur la fin mais pas sur les moyens

Mon but avec un système décentralisé sans consensus est que chacun puisse “construire son bébé” mais qu’on partage quand même les données sans avarice de pouvoir. Ce que tu construis sur le modèle “centralisé” sera facile à adapter sur mon système, je ferai ce que je peux pour. Travaille sur les interfaces comme le fait @Chiara07 sur la messagerie Ğecko, et je brancherai mon système de données derrière en conservant toutes les fonctionnalités. Comme @1000i100, je ne veux décourager personne, au contraire, je souhaite encourager à tout niveau. C’est dans la diversité qu’est notre richesse, pas dans un élitisme imaginaire.

Certes, mais je crois en la législation européenne qui va forcer l’interopérabilité. Et sinon je crois au scrapping pirate qui ne leur laissera pas le choix.

Oui, c’est le plus dur mais la plupart d’entre nous souhaitent essayer. Si on y met de la bonne volonté on y arrivera.

:index_pointing_up:

18

Pour info, on discute de ça avec @HugoTrentesaux par échanges de mails depuis quelques jours. Je voulais contribuer à sa PoC, mais il m’a conseillé de plutôt créer ma propre PoC de mon côté. Ça permet de réfléchir en parallèle, de confronter des choix différents et de retenir les meilleurs.

J’utilise également les briques techniques Iroh + ProllyTree. En revanche, j’ai fait des choix différents pour le reste dès le départ. J’espère pouvoir vous partager ma PoC très bientôt, mais voici déjà quelques choix structurants sur lesquels je suis parti :

  • Pas de couche SQL : ma PoC expose directement une API GraphQL, avec un moteur GraphQL interne qui requête directement les ProllyTrees.
  • Intégration des données blockchain dès le départ. Mon objectif à terme est aussi de remplacer l’indexeur Squid, pour n’avoir plus qu’une seule API GraphQL qui expose toutes les données. Cela permettra aux hébergeurs de nœuds de n’avoir à héberger qu’un nœud Duniter miroir + un pod.
  • Tous les documents d’indexation pointent vers un bloc on-chain, ce qui permet de les rattacher à une epoch. Cela optimise le pruning et la découverte P2P (grâce à des racines de ProllyTrees par epoch).
  • Tous les blobs (photos et autres) restent en staging tant qu’ils ne sont pas référencés par un document d’indexation. Les soumissions de nouveaux documents/blobs passent par une API dédiée, ce qui permet de ne propager un blob que lorsqu’au moins un document d’indexation le référence.
  • Les règles d’indexation sont dynamiques, définies dans un langage de script, afin de les rendre personnalisables par pod sans perdre l’effet réseau (un seul et même réseau P2P).

Je reste court pour le moment et je continue d’itérer, en espérant que ça servira :slight_smile:

19

Le mode distribué, façon briar tox etc… c’est du délire pour la june ou ça pourrait servir?

Merci en tout cas

20

Génial ce topic. Merci.

@fdrubigny la décentralisation des données interopérables change tout à la conception des ux. Nous pourrons totalement diversifier les design, les positions “éditoriales”, les spécialisations ou au contraire les agrégations. Il y aura une sorte d’arc électrique entre la production source des données (par exemple une annonce) par les “users”, avec potentiellement le choix de ses canaux vs plate-formes de diffusion, et de l’autre côté l’exploitation de ces données (selon le positionnement du service rendu) par les “éditeurs”, de plus en plus les users eux-mêmes.
Le front devient totalement accessible à tous, donc la richesse de cette diversité n’aura que peu de limites, puisque justement il n’y aura plus la barrière à l’entrée de constituer un territoire ou une audience captive.

Puisque tu utilises claude, si cette conception - réalisation front te branche, n’hésite pas à lui signifier que tu “isoles” le backend pour pouvoir te câbler sur les dev émergents, voire même de challenger les encours de @HugoTrentesaux, @elois et @1000i100 dès que ce sera l’heure pour eux. N’hésites pas non plus, au cas où tu n’aurais pas repéré, à tester claude design, en commençant par “framework”, puis “high fidelity” (ajouter éventuellement “impeccable”) et passer la main à claude code via le handoff.md … pour un saut qualitatif.