De lecteur à maker : mon métier de créatif technologique expliqué par l'exemple.

Vis-ma-vie : j'utilise une Kindle depuis 2011. Et j'avais déjà un écran e-ink à la maison (ok, c'était du vieux matériel pas du tout efficace).

Pas par fascination technologique, mais par nécessité pratique. L'e-ink me permet de lire pendant des heures sans fatigue oculaire. C'est un outil qui résout un problème concret.

Déjà que je suis myope, si je peux garder quelques années de plus mes yeux, je ne dis pas non.

Mi-octobre 2024, je découvre r/xteinkereader à force de voir des photos passer d'une liseuse de toute petite taille. C'est une communauté active, avec des gens qui partagent des astuces, des fichiers de langue, des petits hacks. L'ambiance classique d'une communauté de niche passionnée.

Je me renseigne un peu, je trouve un usage à cette tablette et bon ... je commande une X4 le 24 octobre et je la reçois le 31 octobre.

En quelques jours d'utilisation et de lurking sur le subreddit, je remarque le pattern habituel de fragmentation :

• Quelqu'un demande comment installer un fichier de langue français
• Réponse avec un lien Google Drive
• Trois semaines plus tard, le lien est mort
• Un autre cherche des astuces pour améliorer les PDF
• Les réponses sont dispersées dans 14 threads différents sur 8 mois

Je connais ce cycle. Je l'ai vu des dizaines de fois dans d'autres communautés. Enthousiasme initial, création de contenu intense, puis fragmentation progressive et perte d'information.

L'idée : créer quelque chose qui fonctionne, rapidement

Mon métier, c'est de créer des prototypes fonctionnels. Des MVP pour valider des concepts. Pas des produits parfaits, des produits testables. La nuance est importante.

L'idée me vient naturellement : créer une plateforme centralisée pour cette communauté. Un seul endroit où toutes les ressources seraient accessibles, où les contributions ne disparaîtraient pas dans le flux Reddit.

Mais avec une contrainte forte : pas de projet à rallonge.

Pas de développement qui s'étale sur 6 mois. Un prototype fonctionnel en quelques jours. C'est ma méthode de travail : tester vite pour valider ou invalider rapidement.

Objectif personnel : prouver en temps réel que je suis capable de créer une communauté et une plateforme fonctionnelle en peu de temps, avec des résultats mesurables.

TL;DR: les résultats après 10 jours

Voici en quelques points ce que vous trouverez dans cet article qui décortique ce que j'ai fait pour avoir :

• Plus de 60 000 vues sur le subreddit
• Plus de 300 téléchargements du guide PDF en 48 heures
• Des centaines de participations à la carte mondiale
• Des dizaines d'interactions quotidiennes dans les discussions

Ces chiffres ne sont pas là pour l'autopromotion. Ils documentent que le concept fonctionne, que la communauté en avait besoin, et que le prototype remplit son objectif.

Voici comment concrétiser vos idées, avec les outils et les méthodes à appliquer.

Les choix techniques : privilégier la simplicité

Premier réflexe de développeur (mon métier initial) : monter une base de données bien robuste, un backend Node.js, gérer l'authentification et le CRUD, le stockage de fichiers avec de la redondance.

Sauf que c'est exactement ce qu'il ne faut PAS faire pour un prototype.

Airtable comme backend

J'ai choisi Airtable. La raison est pragmatique : c'est rapide à mettre en place, l'interface de gestion est intuitive, et ça fait office d'API sans coder quoi que ce soit côté serveur.

En 30 minutes, j'ai une base de données opérationnelle :

• Table pour les ressources (fichiers, plugins, documentation)
• Table pour les tips & tricks
• Table pour la carte mondiale des utilisateurs
• Vues filtrées et triées automatiquement
• Formulaire de soumission intégré nativement

Les utilisateurs peuvent soumettre leurs créations directement. Je n'ai même pas besoin de gérer l'upload de fichiers, Airtable s'en occupe grâce aux formulaires intégrés et disponibles en webview.

Je crée quand même un endpoint custom /ddl?record=[recordId] qui pointe vers les pièces jointes Airtable pour un suivi des téléchargements (avec Cursor : 5 minutes top chrono). C'est fait et c'est fini.

React + TypeScript pour le frontend

Application web classique avec React et TypeScript. Sans fioritures techniques. Wouter pour le routing (plus léger que React Router), shadcn pour les composants UI (je ne perds pas de temps à designer des boutons), Lucide pour les icônes.

Le design s'inspire des e-reader : noir et blanc, minimaliste, lisible. L'information avant l'esthétique.

Avec un bon brief, Replit s'en sort très bien. Il faut juste le guider et bien connaître ses (nombreux) défauts. Mais avec un peu d'expérience, une version initiale peut voir le jour en 1 heure. Le tout étant d'arriver à bien l'aiguiller techniquement.

Le vibe coding ne fait pas tout.

D'ailleurs, j'ai un super livre blanc sur le sujet sur Generative101.club.

Hébergement et déploiement

Déploiement sur un hébergeur avec pipeline CI/CD automatique. Je pousse sur la branche main, le déploiement se fait automatiquement. Aucune configuration serveur complexe. À la limite, le plus dur était de trouver le nom de ce projet. 😅

Temps total pour avoir une version 1 fonctionnelle avec des tests et des données fictives / réalistes : moins d'une journée.

Le guide des 160+ astuces : détourner les outils pour gagner du temps

Avant le développement de la plateforme, j'ai pu passer mes soirées à parcourir le subreddit. Et depuis, je note systématiquement toutes les questions récurrentes, toutes les astuces partagées dans les commentaires, tous les problèmes mentionnés.

Même si c'est un peu décousu par moment.

Astuce : utiliser Perplexity pour structurer l'information

Plutôt que de copier-coller manuellement chaque astuce, j'ai détourné Perplexity pour faire le gros du travail. Je lui donne des threads Reddit spécifiques et lui demande d'extraire les conseils pratiques dans un format JSON structuré.

Oui, même là, le mieux est toujours de bien guider l'IA qui travaille avec vous.

En quelques minutes, j'obtiens un JSON propre avec :

• Catégories cohérentes
• Tips organisés par thème
• Sources référencées
• Compatibilité testée ou non

Ce détournement d'usage me fait gagner facilement 10 heures de travail manuel. Le JSON est directement exploitable pour alimenter la base Airtable et générer l'interface web.

Mon but a toujours été que les outils communiquent facilement entre eux. Pas de devoir créer des moulinettes pour transformer des infos pour plaire à un autre système.

Claude pour la génération du PDF

Une fois le contenu structuré, j'utilise Claude pour générer le contenu d'un PDF téléchargeable. Pas un export basique, un vrai guide de 40 pages :

• Respect de la langue anglaise
• Mise en page lisible et minimaliste
• Sections organisées pour une lecture efficace
• Format optimisé pour la consultation hors ligne

L'avantage de cette approche : j'ai un contenu propre à partir de ce que j'ai validé. Pas de mise en page manuelle, pas de logiciel complexe. Juste un prompt bien construit et Claude qui fait le reste.

La suite pour arriver sur un PDF ? Un passage dans Ulysses pour un export qui respecte vraiment les bonnes pratiques (et envisager une version ePub, j'avoue).

Le déclic

Résultat concret : plus de 300 téléchargements du guide PDF en 48 heures après la publication sur Reddit.

Encore mieux : sur le même délai plus de 4000 consultations des astuces en ligne sur la page dédiée.

Ce chiffre me confirme quelque chose d'important : les gens ne veulent pas chercher pendant des heures. Ils veulent une ressource complète, organisée, qu'ils peuvent consulter hors ligne.

La technologie n'est que l'outil. La vraie valeur réside dans la curation et l'organisation de l'information.

La carte mondiale : créer du lien au-delà des fonctionnalités

Une idée me vient en observant les discussions sur le subreddit : visualiser la répartition géographique des utilisateurs de liseuse Xteink. Pas pour faire de l'analyse marketing, mais pour matérialiser l'échelle de la communauté.

Je crée un sélecteur de pays simple. L'utilisateur choisit son pays, l'information s'enregistre dans un simple Json, et un tableau affiche la distribution mondiale. Que du déclaratif, rien de vérifié. Avec une "sécurité" côté navigateur pour éviter des déclarations en masse.

Ce qui fonctionne dans cette fonctionnalité

• Elle donne une conscience de l'ampleur de la communauté
• Elle permet de découvrir des utilisateurs dans sa région
• Elle crée un effet "nous sommes nombreux" sans effort
• Elle génère de l'engagement sans friction (aucune inscription requise)

C'est simple, c'est visuel, et surtout, ça crée un sentiment d'appartenance à quelque chose de plus grand qu'un simple forum.

Transparence radicale : assumer la nature du projet

Un principe me tient particulièrement à cœur : ne jamais induire les utilisateurs en erreur sur ce qu'est réellement la plateforme.

Xteink Community Hub est non officiel. C'est un projet communautaire, pas un site officiel du fabricant. Les ressources so/nt créées par des utilisateurs, sans validation par une équipe de contrôle qualité officielle.

Je mets cette information en avant dès la page d'accueil. Pas en caractères minuscules dans les CGU. En gros, visible, assumé.

Les disclaimers sont explicites

• "Utilisez ces ressources à vos risques et périls"
• "Sauvegardez votre appareil avant toute modification"
• "Vérifiez la compatibilité avec votre modèle"
• "Ce n'est pas un site officiel"

Cette transparence radicale n'est pas une option, c'est la seule façon de construire une confiance durable. Les utilisateurs ne sont pas naïfs. Ils savent qu'installer un fichier personnalisé comporte des risques. Ce qu'ils attendent, c'est de l'honnêteté sur ces risques.

Pas de marketing rassurant. Pas de "100 % sûr et testé". Juste la réalité : voici ce qui existe, voici les risques, à vous de décider en connaissance de cause.

Design minimaliste : l'information avant tout

Le design est minimaliste : noir et blanc, typographie claire, aucune fioriture visuelle superflue.

Ce choix est pragmatique : le design minimaliste est le plus efficace à mettre en place tout en conservant une apparence professionnelle.

Autre raison : sur une liseuse e-ink, l'écran est noir et blanc. Avoir un site web aux couleurs assorties crée une cohérence visuelle qui résonne avec la communauté.

Principes appliqués : pas de pop-ups, pas de cookies de tracking, pas de bannières d'inscription à la newsletter. Juste l'information recherchée, accessible directement.

Pourquoi ce projet reste gratuit

Aucun modèle économique. Pas de publicité, pas de version premium, pas d'abonnement. Le projet est gratuit et le restera.

La raison est simple : ce n'est pas un business, c'est une démonstration de compétences. Je ne vais pas monétiser les contributions d'une communauté qui partage gratuitement son travail.

D'un point de vue pragmatique, je n'ai pas besoin que ce projet génère du revenu. Ce qu'il m'apporte est plus précieux : la démonstration en temps réel que je suis capable de :

• Identifier un problème communautaire concret
• Créer une solution fonctionnelle rapidement
• Générer un engagement mesurable
• Construire quelque chose qui apporte une vraie valeur

C'est un portfolio vivant. Les 60 000 vues et les 300 téléchargements en 48 heures ont plus de valeur qu'un hypothétique revenu mensuel modeste.

Ce que ce projet démontre

J'ai créé Xteink Community Hub en quelques jours. Pas des mois de planification, quelques jours d'exécution. Et le résultat fonctionne, génère du trafic, de l'engagement, et crée de la valeur pour les utilisateurs.

Ma méthode de travail en pratique

Je ne passe pas trois mois à analyser le marché et à créer des personas détaillés. Je teste vite. Je valide ou j'invalide rapidement. Un prototype fonctionnel donne plus d'informations qu'un prototype Figma parfait.

Je ne code pas un backend complexe quand Airtable résout le problème en deux heures. La technologie n'est qu'un outil au service du problème à résoudre, pas une fin en soi.

Je ne crée pas de solutions compliquées pour démontrer une maîtrise technique. Je crée des solutions simples qui fonctionnent.

Ici : Airtable + React + hébergement automatisé. Point. Et ça marche.

Pour les clients potentiels

Ce projet prouve concrètement que je peux créer un MVP fonctionnel et validé par les utilisateurs en quelques jours, pas en plusieurs mois. Que je sais identifier ce qui apporte de la valeur réelle et ce qui n'est que du bruit technique. Que je sais générer de l'engagement autour d'un produit.

C'est exactement ma méthode dans les missions de prototypage : transformer une idée en quelque chose de testable, rapidement, avec des résultats mesurables et exploitables.

Si vous voulez reproduire cette approche

L'approche est transposable à n'importe quelle communauté de niche. Voici ma méthodologie, étape par étape.

1. Identifiez le problème réel

Pas ce que vous pensez être le problème. Le problème réellement vécu par les utilisateurs. Dans mon cas : les ressources sont éparpillées et deviennent inaccessibles. Pas "la communauté manque d'engagement" ou une autre métrique abstraite.

Passez du temps à observer les discussions. Notez les questions récurrentes, les frustrations exprimées, les solutions de contournement que les gens créent.

2. Utilisez des outils existants

N'inventez pas la roue. Airtable pour la base de données, React ou du vibe coding pour l'interface. Tout existe déjà. Votre valeur n'est pas dans le code original, elle est dans la curation et l'organisation intelligente.

Évitez le "syndrome du backend parfait". Vous n'avez pas besoin d'une architecture microservices avec Kubernetes pour gérer 200 fichiers et 1 000 utilisateurs.

3. Créez un MVP en quelques jours

Pas quelques mois. Quelques jours d'exécution concentrée. Si votre projet prend plus longtemps, c'est probablement que vous essayez de faire trop de choses d'un coup.

Mon MVP pour Xteink Hub : page d'accueil, galerie de ressources, page de tips, carte mondiale. Le reste est venu après, en fonction des retours utilisateurs.

4. Lancez et mesurez rapidement

Publiez votre prototype sur Reddit, Discord, le forum de votre communauté. Récupérez les retours. Ajustez en fonction. Demandez simplement ce qui peut être amélioré !

Les analytics ne mentent pas. Si personne n'utilise votre solution, soit le problème n'existait pas vraiment, soit votre solution ne l'adresse pas correctement.

5. Soyez transparent sur les limites

Indiquez clairement que c'est un projet communautaire, non officiel, avec des risques potentiels. Les utilisateurs apprécient l'honnêteté bien plus que les promesses marketing.

Les difficultés rencontrées (et comment je les gère)

Créer la plateforme technique était relativement simple. Les vrais défis apparaissent ailleurs.

La modération du contenu

Le problème : qui vérifie que les fichiers partagés ne sont pas malveillants ou incompatibles ?

Ma solution actuelle : je compte sur les disclaimers clairs et la responsabilisation des utilisateurs. Chaque page affiche des avertissements visibles sur les risques potentiels.

Ce qui reste à faire : pour un projet à plus grande échelle, il faudrait mettre en place un système de review communautaire ou désigner des membres de confiance pour valider les ressources. Mais pour un prototype, l'approche actuelle est suffisante.

La maintenance à long terme

Le problème : je suis actuellement la seule personne à maintenir la plateforme. Que se passe-t-il si je n'ai plus le temps ou l'intérêt pour ce projet ?

Ma réflexion : la solution logique serait d'open-sourcer le code et de documenter l'infrastructure complète. Ainsi, quelqu'un d'autre pourrait reprendre le projet.

La réalité : soyons honnêtes, la plupart des projets communautaires s'éteignent quand le mainteneur principal part. C'est un risque assumé. Au pire, tout sera sur GitHub.

Le problème du scaling

Le problème : Airtable a des limites techniques. Si la communauté explose avec 10 000 ressources et 100 000 utilisateurs actifs, il faudra migrer vers une vraie base de données.

Mon approche : c'est un problème de réussite, pas un blocage immédiat. Pour l'instant, Airtable gère la charge largement. Je m'occuperai du scaling quand ce sera nécessaire, pas avant.

Le versioning des ressources

Le problème : comment gérer les fichiers obsolètes quand de nouveaux modèles de liseuses sortent ? Comment marquer clairement qu'une ressource est dépréciée ?

Ma solution actuelle : je compte sur les utilisateurs pour signaler les problèmes dans les commentaires du subreddit. Ça fonctionne moyennement bien.

Ce qui manque : un système de tags par modèle et de statut (actif, déprécié, obsolète) serait plus robuste. C'est sur ma liste d'améliorations futures.

Ces limites ne bloquent pas l'utilité du prototype. Ce sont des axes d'amélioration à considérer si le projet continue de grandir.

Les leçons principales de cette expérience

Pourquoi ça a fonctionné ? Parce que la plateforme résout un problème réel vécu par de vraies personnes. L'engagement organique est le seul qui compte sur le long terme. Si vous devez forcer les gens à utiliser votre produit, c'est probablement que votre produit n'apporte pas assez de valeur.

La perfection est l'ennemi de l'action

Mon design n'est pas parfait. Mon code pourrait être optimisé. Il y a des bugs mineurs. Et alors ?

La plateforme fonctionne. Elle apporte de la valeur mesurable. C'est ce qui compte pour un prototype destiné à valider un concept.

Les projets parfaits qui ne voient jamais le jour ne valent rien. Un prototype imparfait qui fonctionne vaut infiniment plus qu'un projet parfait qui reste dans un Figma.

La transparence génère la confiance

J'aurais pu cacher le caractère non officiel du projet. J'aurais pu minimiser les risques dans les disclaimers. J'aurais pu laisser croire qu'il y a une équipe derrière.

À la place, j'ai choisi l'honnêteté totale : projet solo, non officiel, utilisez à vos risques et périls. Et les utilisateurs ont apprécié cette transparence radicale.

La technologie reste un moyen, jamais une fin

Airtable, React, TypeScript ... Ce ne sont que des outils interchangeables. Ce qui compte, c'est ce que vous construisez avec, pas les outils eux-mêmes.

J'aurais pu monter une architecture complexe avec Kubernetes, microservices, et autres technologies à la mode. Ça m'aurait pris trois mois et n'aurait apporté aucune valeur supplémentaire pour les utilisateurs.

Le bon outil, c'est celui qui résout le problème le plus rapidement et le plus efficacement possible.

Pourquoi je partage ce retour d'expérience

Ce projet illustre exactement ma méthode de travail dans mes missions de prototypage et de conseil.

Je ne vends pas de la technologie pour de la technologie. Je vends la capacité à valider rapidement des idées avec des prototypes fonctionnels et des résultats mesurables.

Xteink Community Hub est ma démonstration en temps réel. En quelques jours, j'ai :

• Créé une plateforme fonctionnelle utilisable immédiatement
• Généré un engagement communautaire mesurable (60 000 vues, 300 téléchargements)
• Apporté une valeur concrète et documentée aux utilisateurs
• Constitué un portfolio vivant de mes compétences techniques et stratégiques

Si vous avez une idée de produit, de service ou d'outil, et que vous voulez savoir si elle tient la route avant d'investir des mois de développement : c'est exactement ce type de mission que je réalise.

Je crée des MVP testables en quelques jours, je mesure les résultats réels au-delà des métriques de vanité, et je vous dis la vérité sur ce qui fonctionne et ce qui ne fonctionne pas.

En bref : de l'idée à la reconnaissance communautaire en 10 jours

La création de Xteink Community Hub m'a rappelé plusieurs principes fondamentaux :

• Résoudre un problème réel vaut mieux que créer une solution techniquement brillante
• La rapidité d'exécution surpasse la planification excessive
• La transparence construit une confiance plus durable que le marketing
• Les prototypes fonctionnels enseignent plus que les analyses théoriques

En 10 jours, je suis passé de simple membre à référent communautaire sollicité. Pas par autopromotion, mais en résolvant un problème réel avec une solution concrète.

Cette expérience continue d'évoluer. La plateforme est vivante, la communauté grandit, et de nouvelles fonctionnalités apparaîtront en fonction des besoins exprimés.

C'est exactement comme ça que l'innovation devrait fonctionner : itérative, pragmatique, centrée sur les utilisateurs réels.

Ressources et contact

• Xteink Community Hub : https://xteink.dontthinkjustbuild.com
• Communauté : r/xteinkereader
• Me contacter : u/iamkxrz sur Reddit

Si ce retour d'expérience vous parle, si vous avez un projet à prototyper rapidement, ou simplement des questions sur l'approche, n'hésitez pas à me contacter. Les discussions avec d'autres makers sont toujours enrichissantes.