Un gestionnaire de presse-papiers macOS qui empile les éléments copiés un par un pour pouvoir les choisir et les réutiliser plus tard.
Je l’ai conçu avec l’idée de le monétiser. Dès le premier jour, la question du prix est apparue, et trois jours plus tard j’avais décidé du modèle de vente ; ce n’est donc pas un projet hobby mis en ligne un peu par hasard. Mais une fois terminé, c’est moi qui l’utilise le plus. C’est ce qui me satisfait le plus.
Le meilleur moment, c’était quand je travaillais avec l’IA. Quand je lançais plusieurs prompts ou que je demandais de sortir les résultats dans le presse-papiers, tout s’empilait proprement, et je ne ratais rien même en faisant autre chose entre-temps.
On peut modifier les contenus accumulés. La plupart des gestionnaires de presse-papiers ne proposent qu’un historique en lecture seule ; ici, on ouvre un élément, on le modifie directement, puis on l’enregistre avec ⌘S. Il y a des numéros de ligne, une recherche avec ⌘F et un remplacement avec ⌘R. Ne plus avoir à transférer ce qu’on a copié dans un éditeur, le corriger puis le recopier change plus de choses qu’on ne l’imagine.
J’y ai aussi intégré de petites choses dont j’avais besoin en développant. Formatage JSON·SQL·Mongo, XML↔YAML, décodage JWT, encodage Base64/URL, timestamp Unix, SHA-256, AES, diff ligne par ligne avec ⌘D après avoir choisi deux cartes. Des choses créées parce que j’avais la flemme d’ouvrir un onglet de navigateur.
Par défaut, il ne demande aucune autorisation système. Toutes les données sont chiffrées et stockées uniquement en local, sans analytics, suivi ni serveur.
Journal des 24 jours
Je l’ai construit avec Claude Code. Comme l’historique des conversations était conservé, je l’ai ouvert : il y avait 310 échanges sur 24 jours. En les classant, j’ai compté 28 signalements de défauts et 15 propositions refusées ou annulées. Dans l’ordre chronologique, cela donne ceci.
05/07 (30 échanges) — La première consigne était : « précise les exigences en me posant des questions ». Dans la journée, nous avons choisi le nom et le bundle ID, ajouté base64 et beautify, puis ajouté la vue détaillée avec ⌘⏎. La remarque « ce ne serait pas une app à 4,99 $ sur l’App Store ? » est aussi arrivée ce jour-là. Et j’ai retiré la fonction de collage automatique. « Ça risque de coller quelque chose sans qu’on le veuille, retirons-la »
06/07~07/07 — La question « où est stocké le contenu du presse-papiers ? » a conduit à l’ajout du chiffrement local. J’ai corrigé un bug où les copies depuis Excel étaient reconnues comme des images, et j’ai suivi pendant deux jours le raccourci ⌘⇧V qui ne fonctionnait plus. Je récupérais moi-même les logs avec log show pour les lui transmettre.
08/07 — J’ai arrêté le modèle de vente. Entre faire payer dès le départ, ou proposer gratuitement puis faire payer dans l’app, la discussion est passée par « et si on le vendait simplement payant dès le début ? avec seulement 30 jours gratuits » → nous avons choisi l’essai de 30 jours. Et j’ai rétabli le collage automatique retiré trois jours plus tôt. À l’usage, « ne pas coller immédiatement après sélection » s’est révélé pénible.
11/07 — J’ai créé une fonction de snippets, puis je l’ai tuée. « L’ergonomie est nulle » → « propose des pistes d’amélioration ; si c’est mauvais, on supprime la fonction » → « non, supprime-la ». Décider de jeter ce qu’on a déjà construit a été le plus difficile.
12/07~16/07 — Après avoir étudié Lemon Squeezy et PayPal pour la distribution des licences, j’ai tout ramené vers l’App Store. Ensuite, cela a été une succession d’échecs de validation d’adresse, de codes bancaires, de W-8BEN et de réflexions sur l’immatriculation d’entreprise. Cela a pris plus de temps que le code.
19/07 — L’app avait déjà été soumise à la revue, mais en regardant la capture d’écran du launcher, j’ai découvert qu’elle s’installait sous le nom DevClip-AppStore. J’ai annulé la soumission et refait un build.
25/07 — Rejet. Guideline 2.4.5 (Performance: Hardware Compatibility).
Rejet, puis décision bouclée en 24 jours
La cause du rejet était précisément cette fonction. Le 5 juillet, je l’avais retirée moi-même parce que je la jugeais risquée, puis trois jours plus tard je l’avais rétablie parce qu’elle était trop pratique à l’usage : le « collage immédiat ». Elle utilise l’autorisation Accessibilité, et Apple l’a considérée comme un « usage non lié à l’accessibilité ».
La retirer aurait été simple, mais comme je l’avais déjà retirée puis rétablie parce qu’elle était nécessaire, j’ai décidé cette fois de la défendre. J’ai plutôt modifié la manière de demander l’autorisation.
Même à l’origine, elle était désactivée par défaut et la demande n’apparaissait que lorsque l’utilisateur l’activait lui-même. Le problème était que rien à l’écran ne permettait à l’examinateur de le vérifier. J’ai donc fait en sorte qu’en activant le toggle, l’app n’ouvre pas directement la fenêtre d’autorisation système, mais affiche d’abord une fenêtre d’explication dans l’app. Elle explique par exemple que cela sert uniquement à envoyer un ⌘V juste après le choix d’un élément, et que l’app ne lit pas le contenu des autres applications ; il faut appuyer sur « Continuer » pour passer à la fenêtre d’autorisation système.
Dans la note de revue, j’ai indiqué le chemin de reproduction : « vous pouvez le vérifier en allant dans Réglages > Général et en appuyant dessus vous-même », puis j’ai resoumis. C’est passé.
« Cela fonctionne déjà ainsi » et « l’utilisateur peut le vérifier » sont deux problèmes différents.
Ma façon de travailler avec l’IA
Je n’ai presque pas écrit de code moi-même. Mon rôle consistait à lire et juger ce qui était implémenté à partir de prompts ; je suis bien ingénieur, mais cette fois j’ai en pratique surtout fait de la conception produit et de la QA.
Tout ne s’est pas bien passé. L’absence de drag d’image a été corrigée trois fois par hypothèse, et à chaque fois c’était à moi de vérifier. Ce n’est qu’après avoir dit « fais un peu des tests, que je n’aie pas à tout vérifier à la main » que la méthode a changé : vérifier avec de vraies données avant de corriger. Ensuite, chaque bug trouvé manuellement a été figé sous forme de test, et une bonne partie des 270 tests actuels vient de là.
Au final : 87 commits, environ 10 000 lignes de Swift et 3 700 lignes de tests.
Toutes les fonctions sont gratuites pendant 30 jours. Ensuite, les fonctions de base restent gratuites, et Pro n’est pas un abonnement mais un achat unique.
2 commentaires
Il semble prendre en charge presque toutes les fonctionnalités présentes dans Raycast ; quelles sont les différences, le cas échéant ?
Oui, si on ne considère que l’historique du presse-papiers, il y a pas mal de recoupements. Mais Raycast ne fait pas que le presse-papiers, il a aussi beaucoup d’autres fonctions, donc je le trouvais un peu trop chargé.
Voici les points auxquels j’ai fait attention.
D’abord, que ce soit léger et que cela ne gère que l’historique du presse-papiers ; pour l’instant, ça fait environ 2 Mo.
Ensuite, on peut modifier le contenu enregistré dans la vue détaillée avant de le réutiliser. Je trouvais ça pratique pour relire plusieurs prompts et les retoucher un peu à l’avance.
J’ai aussi porté une attention particulière à la recherche et au rangement par dossiers. En travaillant, j’ai essayé de faciliter la gestion des informations utiles, qu’elles soient ponctuelles ou pénibles à retrouver plus tard.
La recherche fonctionne par contenu, tags, titre, etc.
Plus tard, j’aimerais permettre d’ajouter directement des fonctions ou des agencements via des plugins, mais ce n’est pas encore vraiment défini.
Je pense aussi que Raycast est une bonne application, et j’aimerais faire en sorte que le choix puisse simplement relever des préférences de chacun.
Merci pour votre avis.