8 points par GN⁺ 2025-06-19 | 1 commentaires | Partager sur WhatsApp
  • Scrappy est un outil de création artisanale de logiciels qui aide même les non-spécialistes à créer facilement eux-mêmes de petites apps
  • Contrairement aux grandes apps commerciales ou aux apps d’entreprise, il permet de résoudre librement des problèmes modestes, personnels et créatifs
  • Il propose une interface sur canvas, une édition de code simple, ainsi que des fonctions de collaboration et de partage en temps réel, pour être utilisable aussi par des non-programmeurs
  • Toutes les apps (Scrapps) sont par défaut dans un environnement multijoueur, et peuvent être utilisées et modifiées en collaboration immédiatement, sans création de compte
  • Contrairement à la génération de code par IA ou à d’autres outils existants, Scrappy met l’accent sur la manipulation directe par l’utilisateur et la propriété

Présentation et contexte

  • La plupart des logiciels sont conçus soit pour la vente au grand public, soit comme grandes apps sur mesure
  • Pourtant, les petites apps personnalisées répondant aux besoins réels de chacun restent très rares
  • Scrappy est un prototype de recherche qui aide n’importe qui à créer lui-même des apps simples et créatives pour ses amis et sa famille
  • L’objectif de Scrappy est de concrétiser une vision dans laquelle davantage de personnes peuvent créer des logiciels créatifs et personnalisés, même sans expertise en programmation

Qu’est-ce que Scrappy ?

  • Une app créée dans Scrappy s’appelle un Scrapp
  • Exemples représentatifs :
    • App d’exercices d’arithmétique pour élèves du primaire : difficulté ajustable
    • Compteur de participants pour un événement local : gestion des entrées et sorties depuis plusieurs accès
    • Horloge de calcul du coût des réunions : estimation en temps réel du coût d’une réunion
    • Gestion hebdomadaire des tâches ménagères : gestion souple du planning par membre du foyer

L’expérience de création d’apps dans Scrappy

  • Scrappy fonctionne avec un canvas infini similaire à Figma, Miro et Google Slides, sur lequel on place des objets comme des boutons ou des champs de texte
  • Les propriétés peuvent être modifiées directement dans le panneau Inspector, et des scripts JavaScript peuvent aussi être reliés à des éléments comme les boutons
  • La création d’une app se fait progressivement, en répétant des étapes de glisser-déposer, de modification des propriétés et d’insertion de code

Caractéristiques principales :

  • Configuration des comportements de base : on place des champs et des boutons, puis on leur relie immédiatement des actions
  • Formules réactives : implémentation de changements de propriétés en temps réel selon certaines conditions
  • Synchronisation multijoueur : l’état est toujours enregistré et synchronisé en temps réel
  • Édition live : modification possible à tout moment, sans séparation entre exécution et édition
  • Partage sélectif : possibilité de partager et relier séparément seulement certaines parties de l’app
  • Manipulation visuelle des données : débogage et modification en visualisant les données comme dans un tableur

Pourquoi Scrappy a été développé

  • Scrappy s’inscrit dans des tendances comme le programmation pilotée par l’utilisateur, le « small computing », la « casual programming » et le « home-cooked software »
  • Il suit une voie différente de la programmation visuelle traditionnelle (blocs, nœuds et connexions), en combinant manipulation intuitive et scripting
  • Il s’inspire de HyperCard, Visual Basic et des médias en ligne collaboratifs, tout en accordant une grande importance à l’expérience des outils de productivité sur canvas et de la collaboration en temps réel (Google Docs, Figma, etc.)
  • Contrairement aux grandes apps commerciales ou aux approches de génération automatique par IA, Scrappy maximise le contrôle utilisateur, la personnalisation, le plaisir et la créativité
  • Même sans générer directement du code, il propose une expérience de création d’apps plus simple et plus humaine.

Utilisateurs visés par Scrappy

  • Optimisateurs de processus métier : personnes qui veulent améliorer des flux de travail complexes sans aide d’experts
  • Enseignants et étudiants : possibilité de se concentrer sur l’essence de la programmation sans compétences annexes (ligne de commande, configuration d’environnement)
  • Développeurs amateurs : personnes souhaitant explorer rapidement plusieurs projets en échappant à la complexité des apps grand public
  • Adeptes du DIY : utilisateurs qui veulent créer eux-mêmes leurs propres apps, comme ils le feraient pour leur maison ou leurs loisirs

Actuellement, il reste encore difficile pour un débutant complet de créer une app avec Scrappy (quelques connaissances en JavaScript sont nécessaires), mais le partage et le remix sont possibles même pour les non-programmeurs.

Quels types d’apps conviennent bien à Scrappy ?

  • Partage avec des amis ou connaissances : la majorité des Scrapps se prêtent bien au travail collaboratif en temps réel à plusieurs
  • Modification et amélioration continues : modifications immédiates possibles pendant l’utilisation, sans processus de déploiement ni de build
  • Petits calculs ou manipulations simples : plus efficace pour un document partagé avec un peu de computing que pour des systèmes complexes
  • Friction utilisateur minimale : accès et usage via un simple lien, sans étapes inutiles comme la création de compte
  • Petit groupe d’utilisateurs de confiance : moins adapté si le contrôle des permissions ou des usages mission-critical est indispensable

Exemples d’idées d’apps : flashcards personnalisées, agenda de réunion, gestion d’ateliers en ligne, tableau familial, planning de voyage, etc.

Scrappy vs apps grand public

Lorsqu’on ne trouve pas d’app populaire adaptée, ou qu’aucune n’existe, on peut la créer soi-même avec Scrappy puis la partager. Avantages de Scrappy :

  • Uniquement les fonctions nécessaires : aucun élément superflu
  • Une touche personnelle : une app créée soi-même a plus de sens et suscite davantage d’attachement
  • Modifications amusantes : liberté de personnaliser couleurs et mise en page, et même d’ajouter de l’humour
  • Remix et partage faciles : d’autres utilisateurs peuvent facilement modifier et réutiliser l’app
  • Conception orientée collaboration : plusieurs utilisateurs peuvent manipuler et éditer simultanément
  • Utilisation immédiate : un clic sur le lien suffit, sans inscription
  • Propriété des données claire : les données sont stockées localement et restent entièrement sous le contrôle de l’utilisateur

Scrappy vs génération d’apps par IA

L’IA peut générer automatiquement des apps, mais les atouts de Scrappy résident dans la facilité de compréhension, la collaboration en temps réel et le sentiment de propriété créative

  • Structure facile à comprendre : basée sur des objets visuels, sans code complexe
  • Prise en charge du travail collaboratif en temps réel : plusieurs utilisateurs peuvent collaborer et modifier simultanément
  • Plus de plaisir et de créativité : feedback immédiat et satisfaction d’une modification active

Scrappy vs HyperCard et ses successeurs

  • Partage pensé pour Internet : les apps Scrappy peuvent être partagées en ligne via un simple lien
  • Environnement de collaboration en temps réel : édition et exécution simultanées prises en charge
  • UI et interactions modernes : canvas infini et prise en charge de divers objets
  • Scripting en JavaScript : fonctionnement basé sur un langage moderne et largement utilisé
  • Objets interactifs plus variés : prise en charge des chaînes, nombres, dates, JSON, etc.
  • Formules réactives et liaison d’état : possibilité de définir des relations dynamiques similaires à un tableur

Feuille de route

  • Abaisser la barrière d’entrée pour les utilisateurs non programmeurs
    • autocomplétion du code, débogage simplifié, visualisation des relations, messages d’erreur plus clairs, assistant basé sur l’IA
    • partage simple et rapide, galerie publique, meilleur support mobile
  • Renforcer et étendre les fonctionnalités
    • amélioration des collections et du traitement des données, gestion d’objets répétitifs, introduction de composants réutilisables
    • extensibilité de Scrappy (prise en charge de nouveaux objets), amélioration de la cohérence conceptuelle, etc.

1 commentaires

 
GN⁺ 2025-06-19
Avis Hacker News
  • J’aime bien l’orientation du projet, mais j’ai déjà eu le sentiment qu’une approche SaaS hébergée ne correspondait pas à ce que je voulais. Pour un projet d’une journée comme un petit compteur, ça va, mais pour une petite app qu’on veut utiliser pendant des années, la dépendance devient un vrai problème. Même si la courbe d’apprentissage est très basse, elle existe toujours ; au fond, je préfère des options plus accessibles sur la durée, avec des langages simples et des outils auxquels on peut ajouter sa propre GUI. Le code n’a pas besoin d’être totalement caché ; il faut plutôt rendre les choses assez simples pour que les gens puissent réellement s’en emparer. Il suffit de penser au nombre de personnes qui ont appris le CSS avec MySpace : on commence par copier-coller, puis on finit par personnaliser et adapter à sa sauce. En ce moment, j’utilise surtout HTML/CSS/JS, et si j’ai vraiment besoin d’un backend, je prends du PHP pur, sans framework. L’inconvénient, c’est qu’on reste lié au navigateur, mais au travail, de petits projets faits comme ça (y compris avec AutoHotKey) tournent depuis plus de 10 ans avec presque aucune maintenance. En particulier, j’ai arrêté de toucher à mes scripts AutoHotKey il y a 8 ans quand je suis passé à macOS, et pourtant mes collègues les utilisent encore plusieurs fois par jour. Même si AutoHotKey cessait de fonctionner, le code déjà écrit resterait utilisable. Avec une solution SaaS, en revanche, si le fondateur passe à autre chose, il faut tout refaire. Et c’est bien là le point clé : les gens qui cherchent des solutions « scrappy » n’ont pas envie de les reconstruire à chaque fois.

    • Pour ce type de solution, quelque chose à la TiddlyWiki me semblerait plus approprié. TiddlyWiki met toute la web app dans un seul fichier HTML ; à l’origine, quand on modifiait quelque chose, ça s’enregistrait directement dans le fichier HTML lui-même, avec auto-réplication. Plus récemment, il y a aussi eu des variantes avec stockage backend. Avec un fichier HTML auto-réplicant et un accès backend optionnel, cela peut être un choix bien plus fiable pour de petits projets personnels sur mesure. Au minimum, sa grande résilience est un vrai atout.
    • Je recommande codeboot.org, un IDE Python entièrement côté client, avec exécution pas à pas, système de fichiers virtuel non hiérarchique, FFI avec du code JS, et bien d’autres fonctions (voir la doc). Le partage d’apps est aussi extrêmement simple : clic droit sur le bouton Play, copier l’URL, et c’est partagé. Je m’en suis servi pour résoudre plusieurs problèmes, notamment de nettoyage de données, et il m’est souvent arrivé de mettre directement en favori les apps créées ainsi pour les utiliser ensuite. Ça marche vraiment très bien, et si vous êtes curieux, AMA. Le projet est activement développé et de super nouvelles fonctionnalités arrivent.
    • Une autre possibilité serait de publier tout le code du SaaS en open source afin de garantir sa viabilité sur le long terme. Penpot applique bien cette approche. La plupart des gens l’utilisent en mode SaaS, mais l’auto-hébergement est possible. Bien sûr, la certification des distributions ou la signature des apps restent des éléments compliqués, mais une approche type Web3 pourrait peut-être aussi aider. Ou alors, comme PICO-8 ou l’ancien Flash, on pourrait publier le runtime et distribuer des « cartouches » ou des apps. Construire un canal de distribution fiable en dehors du SaaS est assez complexe, mais comme il existe des précédents historiques, ça vaut la peine d’essayer. Voir Penpot / PICO-8
    • En tant que co-créateur de Scrappy, je suis entièrement d’accord sur l’importance de la pérennité du logiciel. Scrappy a été conçu avec une architecture local-first, sans backend traditionnel : la seule dépendance au cloud est un simple serveur de synchronisation. (Après que cette discussion a pris de l’ampleur sur HN, nous avons ajouté à la hâte des détails techniques dans la FAQ.) À mon avis, c’est un point de différenciation technique et financier important par rapport aux outils SaaS low-code/no-code. Dès le début, nous avons expérimenté la sauvegarde des scraps sous forme de fichiers HTML auto-contenus en une seule page, mais cette fonction n’est pas exposée actuellement.
    • Je construis ce genre de choses avec Cursor et une approche vibe coding, et j’en suis vraiment très satisfait. Récemment, j’ai créé un tracker d’avions qui reçoit les infos des routes aériennes au-dessus de chez moi via SDR, ajoute les informations de vol depuis l’aéroport, puis affiche le tout sur un miroir magique dans un style tableau à volets de gare. Je ne connaissais presque pas le JS côté frontend, mais en une dizaine d’heures de code, j’ai obtenu une app plutôt bonne. Avant, cela m’aurait probablement pris plus de deux mois et j’aurais fini par abandonner ; avec le vibe coding, l’expérience a été très amusante et franchement positive. Ça fait environ 1200 sLOC, et je trouve le code quasi professionnel en termes de logs, performances et qualité — meilleur que pas mal de code commercial moyen, à mon avis.
  • CardStock n’est pas mentionné dans l’article, mais ses objectifs et son approche semblent proches de ceux de Scrappy. Contrairement à Scrappy, CardStock est open source et fonctionne aussi en local. Voir CardStock / dépôt GitHub. Decker est lui aussi open source, et il implémente déjà plusieurs besoins de la roadmap de Scrappy (langage de requête pour données tabulaires et widget de grille, abstraction de composants en « Contraption », etc.). Voir Decker.

    • Je cherchais ce type d’outil depuis longtemps, et le fait que CardStock ait une app desktop compte énormément pour moi.
  • Faire en sorte que les apps créées sur mobile fonctionnent bien fait partie de la roadmap, mais l’édition directement sur mobile semble hors du champ envisagé (« un écran tactile de la taille de la paume n’est pas pratique pour éditer des Scrapps »). Pourtant, nous vivons à une époque où beaucoup de gens n’utilisent que le mobile comme unique appareil informatique, et certains y écrivent même du code ou des romans. Donc même si c’est un peu moins confortable, réfléchir à une interface d’édition mobile augmenterait énormément l’impact de cet outil.

  • L’une des meilleures choses que j’ai faites a été de passer une semaine à créer une app simple qui projette les données de marche de l’Apple Watch sur une grande carte unique, puis de la publier sur l’AppStore et de la partager avec mes proches. Un an plus tard, des amis ou des gens qui l’ont découverte par hasard continuent de marcher à travers toute leur ville et m’envoient des messages pour montrer leurs progrès, ce qui me fait vraiment plaisir. Aucun revenu, mais une expérience très gratifiante. Comme le dit l’OP, créer des apps simples pour ses amis, juste pour le plaisir, c’est un des plus grands bonheurs.

    • Je suis curieux d’avoir le lien vers l’app.
    • Quand on imagine tous les murs et tous les obstacles qu’il a fallu franchir pour arriver à ce résultat, on se dit que beaucoup de gens auraient abandonné en cours de route. Au final, l’utilisateur n’a toujours aucun contrôle et reste enfermé dans une dépendance au fournisseur. On se prend à imaginer à quel point le monde serait meilleur si on pouvait simplement demander ça à une IA et le porter librement sur une montre open source.
  • Je n’ai jamais vu d’environnement de programmation réellement aussi utile pour l’utilisateur final qu’un tableur.

    • Comme exemple d’engagement poussé à l’extrême dans cette direction, je recommande pyspread.
    • Pas de tests, pas de contrôle de version, pas de support de bibliothèques : pour moi, c’est non.
    • Au final, autant apprendre à coder directement. Je ne vois pas bien pourquoi apprendre ce genre d’outils. Pour un développeur, il suffit de construire la chose ; avec un LLM, les trucs très simples se font facilement en vibe coding, sans grand risque. Et même pour les non-développeurs, je me demande combien de personnes vont réellement apprendre ces outils — je serais curieux de connaître le TAM. Qui va vraiment se donner la peine d’assembler une app en glisser-déposer ?
  • Le vibe coding ne remplacera pas les développeurs tout de suite, mais pour des systèmes simples comme celui-ci, ce sera son concurrent le plus sérieux. Si on demande à un LLM de créer une petite app simple (HTML + JS embarqué), avec juste quelques retouches, on obtient quelque chose de très abouti, parfois même visuellement meilleur. Voir exemple.

    • Je fais moi aussi un side project en vibe coding. Toutes les quelques heures, je tombe sur un problème que le LLM n’arrive pas à résoudre ; je me dis donc qu’un utilisateur sans expérience en programmation pourrait simplement rester bloqué. J’imagine que ça dépend de la stack utilisée et de l’ampleur du projet.
    • Rapport de bug : si on entre une erreur comme 3 + 2 = 5.1, c’est quand même accepté comme correct.
    • Le vibe coding correspond exactement à l’objectif d’origine, et ce sont des adversaires naturels.
    • Je serais curieux de connaître une stack simple qu’on peut auto-héberger. Personnellement, j’ai besoin de Vue avec authentification, DB hors ligne multijoueur, hébergement statique, hébergement de fichiers et une fonction de filtrage pour empêcher les utilisateurs de voir les données des autres.
    • J’aimerais remplacer les points d’interrogation par des blancs ou des underscores.
  • On aborde ce sujet du point de vue des programmeurs, mais je pense que la vraie opportunité est du côté des communautés. On pourrait par exemple commencer par une sorte d’App Store privé familial, façon Masterson. Sans sécurité puisque tout le monde se connaît, et impossible de contribuer sans invitation. C’est juste une idée lancée comme ça.

  • Si on en arrive à glisser-déposer des éléments d’UI sur une feuille vide, à se battre en permanence avec une grille dont l’alignement ne correspond pas à la taille des éléments, et qu’au final on doit quand même écrire du JavaScript brut sans autocomplétion, ni programmation visuelle, ni aide API, ni assistance IA — est-ce que c’est vraiment le bout du chemin ?

  • Moi aussi, je suis 100 % d’accord avec l’approche « composants scriptables » plutôt que bloc par bloc pour les débutants. Je suis sur mobile là tout de suite, mais je compte essayer sur desktop bientôt. Un point manqué dans l’analyse, c’est que les gens veulent un « partage facile » et un « coût nul ». Construire l’app elle-même est déjà faisable assez facilement dans un environnement minimal, mais le vrai problème, c’est le déploiement (barrières de l’App Store) et l’hébergement ; même famille ou amis hésitent à payer 5 dollars par mois. En réalité, c’est pareil pour les développeurs pros.

    • Il suffit d’auto-héberger chez soi avec un serveur web + DNS dynamique.
    • J’aime bien l’idée du partage, mais l’hébergement et le déploiement gratuits risquent d’être abusés par des utilisateurs malveillants.
  • En voyant des formulations du genre « les ordinateurs devraient travailler pour les gens et devenir une activité universelle comme la cuisine ou le traitement de texte », j’ai trouvé ça trop générique. Avec des trucs du style « mises à jour en direct, tout gratuit. LLM… », et l’usage excessif des tirets cadratins (—), j’ai eu l’impression d’un texte généré par IA. Personnellement, quand je soupçonne un contenu écrit par IA, mon intérêt chute très vite. Ce n’est pas forcément la faute du créateur, mais ce type de copywriting ne m’intéresse pas beaucoup non plus.

    • Ce style avec des tirets cadratins, c’est ma manière d’écrire dans la vraie vie depuis 10 ou 15 ans. Moi aussi, je n’aime pas trop consommer du contenu généré par IA, et si quelqu’un s’est contenté d’écrire un prompt, j’ai l’impression qu’il vaut mieux demander directement au LLM.
    • Si on veut être précis sur l’usage du trait d’union, du tiret demi-cadratin et du tiret cadratin, utiliser le tiret cadratin comme séparateur est parfaitement correct. Je ne suis pas d’accord avec l’idée que ce soit un marqueur d’IA.
    • En tant que co-créateur de Scrappy, je suis un utilisateur de Macintosh de longue date, donc je fais très bien la différence entre trait d’union, demi-cadratin et cadratin :) Je n’ai utilisé l’IA qu’occasionnellement pour du polissage, jamais pour générer le texte. Je l’ai écrit moi-même, donc il y a eu énormément de travail réel derrière (même si, en pratique, Pontus a assuré la plus grosse partie du travail).
    • Pour taper un tiret cadratin, il suffit d’utiliser la touche Compose puis trois traits d’union. — Comme ça. Sur Mac, c’est shift-option-hyphen.