Pourquoi Claude est-il une application Electron ?

 (dbreunig.com)
10 points par GN⁺ 2026-02-22 | 1 commentaires | Partager sur WhatsApp
  • Electron est un framework basé sur HTML, CSS et JS qui permet de créer des applications desktop compatibles simultanément avec Windows, Mac et Linux ; de nombreuses applications comme Slack, Discord et VS Code l’utilisent
  • Cependant, comme chaque application embarque séparément le moteur Chromium, leur taille est importante, des problèmes de latence et de non-réponse surviennent, et l’intégration aux fonctions de l’OS reste limitée
  • Avec l’arrivée des agents de codage, capables de générer du code natif par plateforme à partir de spécifications et de tests, les avantages d’Electron semblent diminuer
  • Mais en pratique, les agents ne peuvent automatiser que 90 % du développement, et les 10 % restants liés aux cas d’exception et à la maintenance restent difficiles et dépendent encore fortement de l’intervention humaine
  • Ainsi, comme le montre l’application Claude d’Anthropic, il existe toujours des raisons pragmatiques d’utiliser Electron, même avec les progrès des technologies d’agents

Avantages et limites d’Electron

  • Electron permet de créer des applications desktop multiplateformes avec des technologies web
    • Une seule base de code permet de prendre en charge Windows, Mac et Linux
    • Le code d’une application web existante peut être réutilisé, ce qui améliore l’efficacité du développement
  • Ses inconvénients incluent une augmentation de la taille des applications et une baisse des performances
    • Chaque application intègre son propre moteur Chromium, ce qui porte souvent la taille à plusieurs centaines de Mo
    • Cela entraîne des problèmes comme une réactivité moindre et une intégration insuffisante avec les fonctions du système d’exploitation
  • Certains de ces problèmes peuvent être atténués par des optimisations propres à chaque OS, mais les avantages structurels d’Electron n’incitent pas réellement à aller dans ce sens

L’émergence des agents de codage et les attentes qu’ils suscitent

  • Récemment, les agents de codage ont montré leur capacité à automatiser des implémentations entre différents langages et plateformes à partir de spécifications (spec) et de tests
  • En théorie, un seul ensemble de spécifications et de tests permettrait de générer des applications natives pour chaque plateforme
  • Cela ouvre la possibilité pour des équipes réduites et très ciblées de proposer des applications natives hautes performances sur un marché étendu

Le cas de Claude et d’Anthropic

  • Anthropic a implémenté, avec un agent de codage, un compilateur C basé sur Rust, mais s’est heurté à des limites dans la phase finale
    • Lors de l’ajout de nouvelles fonctionnalités ou de la correction de bugs, des régressions cassaient régulièrement les fonctions existantes
    • Le résultat était impressionnant, mais jugé inadapté à un usage réel
  • L’application desktop Claude est elle aussi basée sur Electron et est décrite comme une application lente, pleine de bugs et volumineuse

La difficulté des « 10 % restants »

  • Les agents de codage peuvent traiter rapidement les 90 % initiaux du développement, mais
    la gestion des cas d’exception et la maintenance en environnement réel restent complexes et nécessitent encore une intervention humaine
  • Dans un environnement utilisateur réel, les scénarios imprévus s’accumulent et le développement ne se termine jamais vraiment
  • Si l’on crée une application distincte pour chaque plateforme, les bugs et le périmètre de support sont multipliés par trois, ce qui alourdit fortement la maintenance
    • Electron atténue en partie ce problème grâce à un wrapper commun

Pourquoi Electron continue d’être utilisé

  • Même si le développement piloté par spécifications devient possible, le coût des 10 % restants et la charge de maintenance demeurent
  • Malgré les progrès des technologies d’agents, l’avantage d’une base de code unique d’Electron reste concrètement valable
  • À l’heure actuelle, Electron est encore considéré comme un choix rationnel
  • Les agents de codage progressent de manière spectaculaire, mais ils restent encore insuffisants comme solution de remplacement complète

À lire aussi

1 commentaires

 
GN⁺ 2026-02-22
Réactions sur Hacker News

  • C’est Boris de l’équipe Claude Code
    Il y avait auparavant des ingénieurs qui développaient Electron, donc ils préféraient construire l’app autrement qu’en natif
    Cela permet de partager le code entre le web et le desktop et de conserver la même UI/UX
    Bien sûr, tout est affaire de compromis, donc cela pourrait changer à l’avenir

    • En tant qu’utilisateur, je préférerais une UI fluide et sans saccades qui consomme moins de CPU, même avec un peu moins de fonctionnalités
      J’ai l’impression qu’on peut résoudre ça par de l’optimisation des performances sans changer de stack. C’est pareil pour les apps mobiles
    • Si le codage est déjà un problème résolu, je me demande pourquoi ils utilisent encore la stack technique la plus simple
    • Des entreprises comme Anthropic disent que les outils de codage IA facilitent le portage entre langages, mais dans la pratique elles agissent autrement
      La leçon, c’est qu’il faut regarder les actes plutôt que les paroles
    • Quelqu’un a partagé un lien YouTube en disant : « C’est toi ? »
      Puis a plaisanté en disant qu’il suffirait de demander à Claude : « rends ça moins nul »
    • Plus intéressant que le fait que ce soit basé sur Electron, il y a la question suivante : s’il fallait créer des apps natives pour trois plateformes,
      des agents IA pourraient-ils assurer la maintenance à partir des seules specs et des tests ?
      Vu les limites de modèles comme Opus 4.6, je serais curieux de voir le résultat

  • On voit bien pourquoi le code n’est pas gratuit
    Notre équipe a beaucoup utilisé Claude pendant six mois, mais le taux de bugs reste là
    L’IA n’est pas une solution miracle

    • D’ici un an, il est probable que plus personne dans l’équipe ne comprenne l’origine de ces bugs
      Si on sous-traite la réflexion à l’IA, on perd la carte mentale du système
    • Les modèles capables de coder en continu n’existent que depuis environ trois mois, et il y a encore eu une grosse amélioration il y a 15 jours
      Et pourtant on entend déjà : « pourquoi ne pas tout réécrire avec de l’IA ? », ce qui est assez absurde
    • Ça me rappelle le mème de Shen « I’m stupid faster »
      Voir le lien Imgur
      Les agents de codage IA n’en sont pas totalement là, mais il faut se méfier des erreurs simplement plus rapides
    • Du coup, pourquoi Claude ne fait-il pas les tests QA ?

  • Le navigateur d’OpenAI a lui aussi été lancé, et quatre mois plus tard il reste encore réservé à macOS
    Il tourne pourtant déjà sur un moteur cross-platform, donc cette lenteur à s’étendre reste étonnante

    • La cause la plus probable est sans doute une faible adoption par les utilisateurs

  • L’expression « Free as in puppy » était bien trouvée
    Apparemment, le titre original commençait par « If code is free, »

    • Ce commentaire m’a tellement fait rire que je suis allé chercher le blog, et il était vraiment excellent
    • Quelqu’un a répondu en plaisantant : « Je suis un chiot, je ne comprends pas »
    • Puis un autre a enchaîné avec : « C’est comme une vieille voiture allemande gratuite ? »

  • Cet article et l’ensemble du fil ressemblent à un schéma de débat typique de HN
    « L’IA c’est nul », « JavaScript c’est nul », « Electron c’est nul », toujours les mêmes refrains
    Electron est pratiquement devenu une “quatrième plateforme OS”, et beaucoup de développeurs ne le comprennent pas

    • Je pense qu’il faudrait remplacer toutes les apps Electron par du natif
      Aujourd’hui, ces apps ressemblent à des sites web bricolés, avec des incohérences de style et beaucoup de bugs
      Créer une vraie app Mac native est bien plus agréable
    • Le coût, ce n’est pas le code, c’est l’ingénieur
      Electron a des avantages, mais il y a très peu d’optimisation spécifique à chaque OS
      Il existe aussi beaucoup de mauvaises UI natives ; au final, tout dépend de la manière dont les gens écrivent le code
      Si Claude fournit déjà un outil CLI, alors le choix d’Electron est raisonnable
    • En tant qu’auteur de l’article, je n’ai jamais dit que l’IA était mauvaise
      J’ai reconnu les avantages d’Electron et expliqué les raisons de ce choix
      Mais le fait que ce soit lent même sur un Mac Studio avec 64 Go de RAM reste un point intéressant
    • Il est difficile d’accepter qu’une entreprise valorisée à 30 milliards de dollars livre une UX pareille
      Inclure jusqu’aux dépendances npm par défaut donne l’impression d’un manque de fierté technique
      Ça colle mal avec le slogan consistant à « recruter les meilleurs talents »
    • Même mon Mac 24 Go est constamment en swap à cause des apps Electron
      J’aime bien JavaScript, mais l’usage de RAM est délirant

  • Anthropic n’a jamais dit que « le code est gratuit »
    Ils ont mis en avant les gains de productivité, et en pratique ils écrivent déjà la plupart de leur code avec des LLM
    Si on veut les critiquer, il faut pointer les vrais problèmes plutôt qu’un homme de paille

    • Cela dit, une question demeure : « si la productivité est si élevée et que les ingénieurs coûtent si cher,
      pourquoi le résultat n’est-il pas meilleur ? »
    • Le responsable de Claude Code a déclaré il y a quelques jours que « le codage est presque un problème résolu »
      Voir l’interview dans Lenny’s Newsletter
    • En pratique, beaucoup de gens affirment quand même que « le code est presque gratuit »
      Cet article semble viser ce type de discours

  • C’est Felix. Je m’occupe des apps Electron de Claude Code Desktop et Claude Cowork
    Nos apps intègrent aussi pas mal de code Rust, Swift et Go
    Nous avons expliqué en détail pourquoi nous utilisons Electron et pourquoi nous distribuons notre propre moteur
    dans la documentation officielle
    Electron n’est qu’un outil ; si nécessaire, on peut utiliser autre chose

    • En laissant de côté le débat sur Electron, l’app a clairement beaucoup de problèmes de UI/UX et de performances
      Le CEO a dit que « le codage est presque un problème résolu », donc j’aimerais demander pourquoi on obtient ce résultat
    • Certains estiment que si le code avait été entièrement piloté par l’IA, ces compromis n’existeraient même pas

  • J’ai eu des problèmes de connexion à Claude
    Le navigateur entrait dans un chargement infini, et cliquer sur connexion me renvoyait vers l’inscription
    Quand des fonctions aussi basiques sont instables, c’est décevant pour ce qui est censé être « le futur du codage »

  • Le code n’est absolument jamais gratuit
    Au final, on paie toujours le coût sous une forme ou une autre
    Même si l’IA écrit tout le code, il faut quand même quelqu’un pour le comprendre
    Savoir lire les manuels est l’une des forces des hackers,
    et une entreprise qui ne comprend pas comment fonctionne son propre produit est en danger

  • Je pense que si Claude utilise Electron, ce n’est pas un problème technique mais culturel
    Pour une startup, Electron est un choix rationnel,
    mais pour une grande entreprise, il faudrait investir dans la qualité et l’UX d’apps natives
    Le fait de ne toujours pas le faire, même avec le codage automatisé,
    montre que la culture de développement actuelle a perdu la volonté de créer le meilleur logiciel possible