Comme mon collègue Stéphane et probablement beaucoup de geeks, j’ai commencé à tâter le terrain du vibe coding en début d’année. Cette pratique qui consiste à écrire des apps en utilisant uniquement des intelligences artificielles génératives, souvent sans même regarder la moindre ligne de code, a gagné d’un coup en efficacité avec l’émergence de modèles sensiblement plus puissants à partir de la fin de l’année 2025. Pour ma part, c’est surtout l’arrivée de l’app Codex proposée par OpenAI qui m’a mis le pied à l’étrier. Je l’ai d’abord testée pour écrire un article et puis je me suis pris au jeu en l’utilisant pour des projets personnels.
Après quelques mois, j’ai vibe codé plusieurs automatisations parfois très sophistiquées pour Home Assistant, améliorant au passage ma gestion au quotidien de la maison connectée. Dans cet article, je voulais présenter un autre projet qui a vidé mes quotas plus vite que l’éclair. J’ai créé une app en Swift destinée à un usage interne chez MacGeneration afin de remplacer un vieil AppleScript que j’avais bricolé il y a bien des années et qui dépendait de Rosetta.
En deux semaines de développement par petites sessions, j’ai obtenu une app pour macOS et iOS qui reprend toutes les fonctionnalités de l’ancien script et en fait même bien plus. Elle est fonctionnelle et suffisamment soignée à mon goût et mes collègues de la rédaction peuvent aussi en profiter par le biais de TestFlight.
L’objectif : remplacer un AppleScript côté macOS et une automatisation Raccourcis côté iOS
Chez MacGeneration, nous utilisons un dispositif assez original pour gérer les tâches de la rédaction. Après avoir testé de nombreuses solutions sur le marché, de l’historique Daylite au très regretté Wunderlist, nous avons finalement opté pour un système atypique, mais qui tient depuis maintenant près de dix ans. Nous détournons les issues d’un projet hébergé par notre instance GitLab (concurrent de GitHub qui peut être installé sur son propre serveur) en guise de gestionnaire de tâches.
Si vous ne connaissez pas le domaine, les issues ne sont clairement pas faites pour ça. À la base, ces tickets associés à un dépôt Git permettent de remonter les bugs ou des demandes de fonctionnalités pour un projet de développement. C’est un outil très utilisé par les développeurs, pour enregistrer les bugs et répondre aux demandes d’utilisateurs, notamment dans le monde de l’open source. Comme je l’expliquais en 2020, ce n’était pas le choix idéal pour nous, plutôt un pis-aller en attendant de trouver mieux.
Les services internes préférés de MacGeneration
Mais comme on n’a rien trouvé de mieux en dix ans, GitLab reste notre gestionnaire de tâches. Un de ses défauts par rapport à un véritable outil dédié concerne l’ajout des tâches et c’est ce qui nous ramène au sujet. Pour créer une issue, on doit normalement utiliser une interface web et même si elle est assez bien pensée dans l’ensemble, elle n’est pas optimale pour ajouter rapidement un article à la pile de tâches. Depuis un navigateur, il faut copier le titre depuis un onglet, le coller dans un autre onglet qui affiche le formulaire, puis revenir sur le premier pour récupérer l’URL et la coller dans le deuxième.
Ce n’est pas l’idéal sur un Mac, c’est encore pire sur un iPhone où les allers et retours et copier-coller sont pénibles. C’est pourquoi j’ai créé deux briques supplémentaires associées lors de notre bascule sur GitLab, en commençant par un script en AppleScript pour faciliter l’ajout depuis le Mac. J’affectionne tout particulièrement ce langage bizarre, avec sa syntaxe drôlement proche de l’anglais, et c’est ainsi assez naturellement que je me suis tourné vers lui. Si c’était le candidat naturel pour récupérer les données nécessaires des navigateurs web (URL, titre et même sélection du contenu), il lui manquait la partie interface pour composer un formulaire simple à utiliser.
C’est pourquoi j’ai aussi utilisé Pashua, en complément du code en AppleScript. Cette app propose depuis 2003 de créer des interfaces décrites avec du texte, ce qui est parfait dans ce contexte. Le script contient la liste des champs, avec d’éventuelles valeurs prédéfinies (comme les membres de la rédaction pour assigner une tâche), et on peut préremplir le formulaire par le script. Même si c’est du bricolage, c’est un bricolage qui a tenu dix ans, ce qui n’est pas si mal.
Cette solution va toutefois sans doute disparaître prochainement. Le développeur de Pashua a abandonné son app depuis 2018, si bien qu’elle n’a jamais connu la transition vers les puces Apple Silicon. La disparition de Rosetta 2, prévue pour macOS 28 dans un an, signera probablement sa fin définitive. Son code source étant ouvert, quelqu’un pourrait théoriquement reprendre le flambeau, mais cela reste improbable étant donné son caractère ultra-niche. Qui a encore besoin d’interfaces pour des AppleScript en 2026 ?
Rosetta 2 disparaîtra à la sortie de macOS 28
Du côté d’iOS, la situation n’a jamais été aussi favorable. J’avais écrit un long article en 2017 sur la création d’une automatisation avec l’app qui se nommait encore Workflow et qui est devenue Raccourcis suite à son acquisition par Apple. Comme je le décrivais, on était loin d’avoir quelque chose d’aussi optimal à cause de la fermeture d’iOS et cela ne s’est jamais amélioré. Je dirais même que la gestion depuis Cupertino a empiré la situation, avec tant de bugs bloquants à chaque mise à jour majeure d’iOS que j’ai été contraint de replonger bien trop souvent à mon goût dans cette automatisation longue et complexe.
Automatisation : Workflow, après des années d’AppleScript
Cette longue présentation permet de définir le cadre de ce projet de vibe coding. Je ne suis pas parti de zéro avec un simple concept, j’avais une idée bien précise en tête : remplacer un AppleScript parfaitement fonctionnel, mais condamné à terme, ainsi qu’une automatisation iOS trop bancale par une app native et moderne.
Le travail : beaucoup d’allers et retours avec les modèles et énormément de lignes de code
Même si je ne suis pas développeur et que je n’ai jamais suivi de formation pour écrire des lignes de code, je bricole suffisamment dans le domaine depuis aussi longtemps que j’ai un ordinateur (ou même une calculatrice graphique quand j’étais lycéen) pour me qualifier de codeur du dimanche. J’ai écrit des dizaines de scripts en AppleScript pour le travail et mes propres besoins, j’ai aussi plusieurs scripts Shell à mon actif pour gérer des serveurs et j’ai même bricolé au fil des années plusieurs apps utilisées en interne. Ce qui m’a toujours manqué pour créer une app dédiée à l’ajout de tâches à GitLab, c’est d’abord le temps.
