Trois logiciels en un mois : ce que les agents changent sur Linux

Bon, déjà, cet article est la suite de celui-ci.

Il faut qu'on parle de la fin de mon mois d'août.

Les agents et le code natif sur les plateformes propriétaires

En août, les gens ne font rien, ils sont à la plage... ce n'est pas mon truc, je préfère bricoler des trucs dans mon coin.

Première expérience, j'avais une idée d'application iOS qui pouvait m'être utile, mais rien de plus qu'une vague idée.

Je voulais juste essayer un truc, l'idée était simple : un appareil photo avec des fonctionnalités en plus... en Swift.

Pour ça, j'ai préparé mon plan, puis j'ai confié l'exécution à plusieurs agents qui tournaient sur Codex-5.6-Sol, du haut de gamme, quoi.

Que ce soit Opus, Fable ou Sol, j'ai l'habitude de travailler avec eux sur toutes sortes de choses, je connais bien leurs capacités.

Mais là, ne serait-ce qu'arriver à la première version, c'était déjà bien plus laborieux que sur mes autres projets (Rails, Symfony, Django et Next.js).

Le résultat final faisait « très IA », l'expérience utilisateur était une catastrophe malgré mes instructions... bref, j'ai essayé d'itérer un peu, mais j'ai vite compris que GPT n'était tout simplement pas d'humeur.

Ensuite, deuxième tentative, je voulais modifier Capso.

L'idée, c'était de pouvoir envoyer des captures d'écran sur Dropbox. Oui, Dropbox a déjà cette fonctionnalité, mais Capso (et ce que j'utilise à la base, CleanShot X) permet de retoucher l'image avant de l'envoyer, très pratique quand je dois expliquer des choses à des clients, rien ne vaut l'enregistrement d'écran.

Bref, même histoire : j'arrive à ajouter la fonctionnalité (vous pouvez d'ailleurs la voir sur GitHub), mais je ne sais pas, je n'aime pas la sensation, l'expérience n'est pas aussi fluide que ce dont j'ai l'habitude. D'habitude, j'ai 5 ou 6 agents qui tournent en parallèle, c'est fluide, pas de longues phases de « cogitation », les tests passent bien... là, je le sens ramer, et cette fois c'était un mélange de Claude Fable et d'Opus 5.

Je n'aime pas non plus le résultat final, il n'y a pas à tortiller, ce n'était qu'un petit projet de loisir, mais arriver à une expérience utilisateur qui me plaise vraiment prendrait un temps monstre... et je n'en avais pas particulièrement envie à ce moment-là.

J'utilise macOS et iOS depuis des années, mais je n'ai jamais vraiment rien construit pour la plateforme. Je ne suis pas très fan de son côté fermé et du contrôle total d'Apple dessus, et je ne me vois pas bâtir une activité là-dessus, le web ouvert me va très bien.

Le post qui m'est resté dans la tête

Oui, ce post sur X de DHH, qui parle des agents et du code source du noyau Linux. Quand on y réfléchit, c'est assez évident... bien sûr qu'ils ont tout ce code dans leurs données d'entraînement...

Du coup... quand ils travaillent dans cet environnement, ils sont davantage « chez eux ».

La hype Omarchy

Fin août, DHH sort sa distribution « Omarchy Quattro », et dire que « la hype était intense » ne rendrait même pas justice à ce qui s'est passé ensuite...

Les premiers jours, j'ai regardé de loin, mon Mac me convient pour l'instant, et changer de système d'exploitation, ce n'est pas encore d'actualité. J'ai trop de workflows sur ma machine qu'il faudrait adapter, et il faudrait aussi prendre de nouvelles habitudes.

Puis quelques jours plus tard, je télécharge l'ISO et je l'installe sur ma machine, parce que bon... il faut bien que je voie par moi-même. Pourquoi tout ce bruit ?

Que dire ? Le travail est excellent, DHH a choisi les bons outils et ajouté les siens pour créer un ensemble cohérent, mais comme je le dis dans mon article sur Omaport, cette cohérence s'arrête dès qu'on utilise un logiciel qui n'a pas été « pensé pour Omarchy ».

Et ça me donne des idées...

Mes Omatrucs

Alors, pour Omaport, on a déjà écrit un article dessus, on ne va pas y revenir. Le construire a été un jeu d'enfant. Linux, basé sur rclone, avec les fenêtres dessinées avec Qt 6, une stack entièrement open source. Opus était complètement chez lui, sans le moindre stress... le résultat final était presque bon du premier coup, quelques tours de tournevis et j'avais une expérience qui me plaisait vraiment, que j'ai commencé à utiliser moi-même tous les jours, parfait.

Sauf que voilà, Omaport est simple, c'est tout l'intérêt. On monte un peu le curseur de la complexité ?

Omatable

Je n'aime pas phpMyAdmin, je ne l'utilise plus depuis des années, j'aime regarder mes bases de données dans une belle interface, claire, rapide, native.

Sur macOS, j'utilisais Sequel Ace, puis TablePlus.

Sur Linux, il y a DBeaver, mais je ne l'aime pas, il est moche. Il y a aussi une version totalement abandonnée de TablePlus, sans doute parce qu'ils n'ont pas d'utilisateurs.

Et c'est là que l'idée d'Omatable m'est venue.

Le truc, c'est qu'Omaport était le plus facile à faire... ce qui m'intéresse avec Omatable, c'est qu'on monte d'un petit cran.

D'abord, la compatibilité : je travaille principalement avec MySQL, PostgreSQL et Redis, donc Omatable doit être à l'aise avec ces trois-là.

Ensuite, il doit être utilisable essentiellement au clavier, pour coller à tout ce que fait Omarchy...

Une fois de plus, le développement s'est bien passé, après 24 à 48 heures j'avais quelque chose de sympa. Évidemment, je ne l'ai pas testé sur des bases de production au début (à la fin, si... parce que ça marchait du tonnerre).

Bref, que dire ? J'ai tout ce qu'il me faut en 48 heures, compatible avec les moteurs que je veux (évidemment, on utilise les bibliothèques système pour aller plus vite, on n'a pas réimplémenté le protocole, vous savez, l'open source...).

J'ai les connexions « par SSH », la compatibilité avec 1Password, qui gère ma clé SSH privée (on a ça dans Omaport aussi, d'ailleurs).

Un cran bien au-dessus, et toujours inachevé : Omapixel

Alors, pour le troisième projet (et le dernier pour l'instant, parce qu'il faut que je passe à autre chose), j'ai décidé de voir grand : Omapixel. L'idée est simple, il n'y a pas de bon éditeur d'images simple sur Linux. Il y a des choses... mais je ne suis pas graphiste, je fais quelques petites retouches de temps en temps, il faut que ce soit simple, rapide et efficace, comme Pixelmator Pro sur mon Mac.

Alors, vous dire que ça s'est aussi bien passé que pour les deux autres, ce serait clairement exagéré...

D'abord, le moteur, c'est essentiellement GEGL, qui est disponible sous licence GPLv3. C'est d'ailleurs pour ça qu'Omapixel utilise cette licence lui aussi, certaines fonctionnalités de GEGL ne se débloquent que si vous avez également une licence GPLv3. Ce n'est pas un projet commercial, c'est un jouet, donc bon, le type de licence, je m'en moque un peu.

Bref, revenons à nos agents.

Au début c'était plutôt rude, j'avais des problèmes de performance délirants, c'était inutilisable, j'ai dû faire venir Fable en renfort pour comprendre pourquoi c'était aussi lent.

Après quelques itérations, on finit avec quelque chose de bien plus agréable à utiliser... mais tout seul dans son coin.

Dans la première version, il y a un format de fichier spécifique à Omapixel, mais le problème, c'est que j'ai 10 ans de fichiers Photoshop / Pixelmator Pro...

Ce serait COMPLÈTEMENT dingue de pouvoir les ouvrir dans Omapixel, non ?

Eh bien... on peut.

Et non, je n'ai rien fait d'illégal sur aucun des trois projets, pas de code copié, pas de rétro-ingénierie de logiciel propriétaire, nada, absolument rien.

J'ai simplement utilisé mes fichiers enregistrés, que j'accumule depuis des années.

Pour rendre Omapixel compatible avec les formats PSD et PXD, j'ai simplement donné à un agent des fichiers accumulés au fil du temps, tous entièrement les miens (par exemple, toutes les illustrations de mon blog, des publicités que j'ai faites... etc.).

Et je lui ai demandé de déduire le format à partir de ce gros jeu de données. Il l'a compris très vite... et le PSD était plus facile parce que le format est bien documenté et qu'il existe déjà des projets open source (en Python) qui le gèrent bien (pas complètement, bien sûr).

Il y a eu quelques ratés : de l'opacité qui n'était pas la bonne, du texte au mauvais endroit. Pour ça, j'ai fait simple, j'ai ouvert le fichier dans le logiciel d'origine (Photoshop et Pixelmator) et j'ai pris des captures d'écran que j'ai données à Fable, en lui demandant de creuser pour comprendre d'où venaient ces différences.

Après quelques heures, les fichiers avaient la même tête dans Omapixel que dans le logiciel d'origine...

C'est quand même assez incroyable.

Alors, les agents sur Linux ?

Eh bien, ils sont clairement chez eux...

Le résultat parle de lui-même, et Omarchy Quattro est d'ailleurs construit autour de ça. L'agent est au cœur du système et peut tout modifier, parce que sur Linux, tous les réglages sont facilement accessibles dans des fichiers texte...

C'est drôle, parce que Linux a longtemps été boudé sur le desktop précisément pour cette raison, parce qu'il fallait aller fouiller dans des fichiers pour changer des choses sur son ordinateur.

Et aujourd'hui, c'est sa plus grande force (ça, et le fait que tout repose sur du code que n'importe qui peut lire, y compris les agents...).

Pour l'anecdote, j'ai aussi essayé les agents sur du .NET par le passé, bon, ça marche, mais ce n'est pas aussi bluffant. Quand on est sur Linux, avec de l'open source, je pense que c'est d'un autre niveau.

Bisous.