7 points par GN⁺ 2026-01-29 | 4 commentaires | Partager sur WhatsApp
  • Un navigateur capable de rendre du HTML et du CSS a été implémenté directement en Rust en seulement 3 jours par une personne et un agent LLM
  • Le projet a été mené à bien avec environ 20 150 lignes de code et inclut des fonctions de base comme le défilement, le retour arrière et le mode headless
  • Conçu pour fonctionner sur Windows, macOS et Linux sans bibliothèque Rust externe
  • Le développement s’est déroulé en collaboration avec l’agent Codex : l’humain s’occupait de la coordination et de la validation, tandis que l’agent écrivait le code
  • Au final, c’est un exemple qui montre que la combinaison « une personne + un agent » est plus efficace qu’un grand nombre d’agents

Vue d’ensemble du projet

  • L’objectif était de créer entièrement de zéro un navigateur basique capable de rendre du HTML et du CSS
    • JavaScript n’est pas pris en charge
    • Le développeur dit avoir commencé « pour le plaisir », puis a poursuivi en collaboration avec un agent LLM (Codex)
  • Des contraintes avaient été fixées : terminer en 3 jours, interdiction des dépendances Rust externes, prise en charge des 3 grands OS, etc.
  • Le navigateur dispose de son propre moteur de rendu et inclut une fonction de capture d’écran, le clic sur les liens et des tests de régression

Jour 1 – Implémentation initiale

  • Le travail a commencé avec le rendu de « Hello World », puis l’ajout de la gestion des balises imbriquées et de la fonction de capture d’écran
  • Les spécifications HTML/CSS ont été définies et une comparaison d’images a été introduite pour les tests E2E
  • En une seule journée, le projet est arrivé à un stade où il pouvait récupérer et afficher des sites web via X11 et cURL
    • La base de code atteignait environ 7 500 lignes, avec tous les fichiers maintenus sous les 1 000 lignes
    Publicité

Jour 2 – Extension des fonctionnalités

  • Ajout du mode --headless pour résoudre le problème des fenêtres qui s’ouvraient pendant les tests
  • Améliorations sur le redimensionnement de la fenêtre, la compatibilité, les performances et le rendu des polices
  • Le workflow consistait à partager des captures d’écran de sites web, puis à demander à Codex de les reproduire
    • La majeure partie du code était écrite par l’agent, l’humain se chargeant de la revue et de l’approbation

Jours 3~4 – Finalisation et support multiplateforme

  • Ajout de fonctions essentielles au navigateur comme le défilement, les logs de débogage et le bouton retour arrière
  • Mise en place du support de macOS et Windows et validation des tests
  • Intégration CI et build de release terminées, pour un temps de développement total d’environ 72 heures
Publicité

Résultats et statistiques du code

  • La base de code finale compte environ 20 150 lignes réparties dans 72 fichiers
  • Parmi les principaux fichiers figurent les modules layout, style, platform et browser
  • Cargo.lock est vide, ce qui signifie qu’il peut être exécuté de manière totalement autonome sans package Rust externe
  • Les binaires générés par la CI et le code source peuvent être téléchargés directement sur GitHub

Principaux enseignements

  • La combinaison « une personne + un agent » est plus efficace que l’utilisation de milliers d’agents
  • Un seul agent peut travailler longtemps sur une même base de code et produire de réels progrès
  • Il existe un potentiel d’extension vers un modèle où plusieurs personnes disposent chacune de leur propre agent
  • Ralentir peut en réalité produire des résultats plus rapides et meilleurs
  • Le rôle de l’humain qui pilote l’agent peut être plus important que la conception du système elle-même
  • En conclusion, à la question « injecter plusieurs agents accélère-t-il le développement ? », cet exemple montre qu’une collaboration entre un seul humain et un seul agent peut être plus réaliste et plus efficace

4 commentaires

 
pkj3186 2026-01-29

Je ne suis pas très au fait, donc je me pose la question : quel genre de blog est le blog de simon, souvent mentionné dans les avis sur Hacker News... ?

 
laeyoung 2026-01-29

La raison pour laquelle le billet de blog publié par Simon Willison est probablement autant mentionné sur Hacker News, c’est sans doute que

  1. il y a une raison au fait qu’il écrive si bien, si vite et si souvent sur l’IA. Même le fameux test de performance des IA consistant à dessiner un « pélican à vélo » semble avoir été lancé par lui en premier (https://simonwillison.net/search/?q=pelican)
  2. il est aussi connu pour être le créateur de Django.
 
qyurila 2026-01-29

C’est apparemment le blog classé n°1 parmi les blogs les plus populaires sur Hacker News en 2025. Entre sa réputation et le volume considérable d’articles publiés, j’ai l’impression que, du point de vue d’un utilisateur moyen de Hacker News, c’est le blog que l’on visite le plus souvent, ce qui explique qu’il soit naturellement considéré comme un indicateur de référence.

 
GN⁺ 2026-01-29
Commentaires sur Hacker News
  • Je pense que c’est une démo de navigateur généré par du code bien meilleure que FastRender de Cursor
    C’est bien plus petit, autour de 20 k lignes en Rust, n’utilise que les bibliothèques système pour le rendu d’images et de texte, et le code est facile à lire
    Par exemple, le code d’implémentation de flexbox est très clair
    J’ai aussi publié une capture d’écran du rendu de mon blog : les dégradés CSS et les icônes SVG passent bien, mais les PNG échouent
    Je pensais qu’un navigateur de rendu HTML+CSS était une tâche parfaite pour démontrer des agents en parallèle, et c’est surprenant de voir qu’un seul agent de code a suffi

    • D’un point de vue ingénierie, je trouve la conception bien plus aboutie que celle du navigateur de Cursor
      L’important n’est pas simplement de consommer beaucoup de tokens, mais de savoir utiliser efficacement les agents
      Moi aussi, il m’est arrivé de générer plusieurs projets puis de les abandonner quelques jours plus tard. Sans feedback, les agents font seulement ce qu’on leur demande, donc s’ils partent dans la mauvaise direction, ils ne font que creuser davantage
    • Je pense que la collaboration entre humain et agent fait toute la différence décisive
      Même si Claude part dans une direction absurde, avec la bonne structure d’agents, on peut le remettre sur les rails
      Je mène actuellement une expérience où je sépare les agents évaluateur, chercheur et implémenteur
      Je leur fais étendre les tests en fonction d’un score ou enquêter sur les causes d’échec, puis je jette le commit s’il n’y a pas d’amélioration
      Ce type de structure est bien plus favorable au contrôle de la qualité du code
      À une époque où le code est peu coûteux et jetable, le workflow lui-même doit changer
    • Le fait qu’embedding-shapes ait construit cela lui-même à la main est impressionnant
      On a l’impression d’une histoire « David contre Goliath » où 1 personne + 1 agent bat un navigateur à 5 millions de dollars et 1,6 million de LOC
      L’IA reste une boîte noire, donc tout le monde expérimente encore pour trouver la bonne direction
      Nous ne sommes qu’à un mois de 2026, et je suis curieux de voir quelles expériences vont encore apparaître
      Ce serait amusant que Simon revoie régulièrement le fil HN des prédictions pour 2026
  • Il s’était fixé comme règle une limite de 3 jours et le support de X11/Windows/macOS en n’utilisant aucune crate tierce Rust, seulement les bibliothèques de base de l’OS
    Le projet a été achevé en environ 20 k LOC, dont 14 k pour le moteur et 6 k pour le code de support des plateformes
    Le code source et les binaires ont été publiés

    • Quand je contribuais à KHTML/konqueror il y a 20 ans, même implémenter le rendu de base prenait des mois
      Aujourd’hui, c’est bien plus efficace grâce aux suites de tests lisibles par machine
      À l’époque, le comportement d’IE faisait pratiquement office de standard, alors qu’aujourd’hui Google, Apple et d’autres contribuent à la standardisation, ce qui améliore beaucoup les choses
    • Je me demande quel modèle a été utilisé et quel a été le coût en tokens
    • Excellentes contraintes
  • Au-delà des fonctionnalités, je me demande ce que donnerait un audit de sécurité de ce type de codebase
    Rust aide sans doute, mais je me demande si les garanties du langage suffisent à elles seules

    • La sécurité n’a pas du tout été prise en compte. Ouvrir des sites web arbitraires sans sandbox est dangereux
      Rust empêche seulement les erreurs mémoire de base, pas des choses comme l’accès aux fichiers locaux
      Comme il n’y a pas de moteur JS, l’exfiltration de données est plus difficile, mais un audit trouverait probablement plusieurs vulnérabilités graves
  • La communauté attendait browserBench, et je suis heureux de voir que ça démarre enfin
    Les navigateurs font partie des logiciels les plus complexes, donc ce type d’essai servira de point de référence pour évaluer les limites

  • J’ai du mal à imaginer qu’on puisse faire un navigateur en 20 k lignes
    Rien que zlib fait 12 k lignes, donc j’ai l’impression qu’il manque quelque chose
    Je me demande si ça se contente d’appeler les fonctions de rendu de l’OS

    • Sous Linux, il lie 78 bibliothèques dynamiques pour X11, glib, les formats graphiques, le chiffrement, etc.
    • Il n’y a pas de dépendances Rust, seulement les frameworks fournis par l’OS
      Les bibliothèques utilisées sont indiquées dans le README
  • Quand je l’exécute, le rendu me semble assez chaotique
    La couleur des liens et leur soulignement ne sont pas cohérents, et sous Windows, le bouton retour ne fonctionne pas
    Malgré cela, la page d’accueil de HN et le blog de Simon sont plutôt bien rendus

    • Ce navigateur est moins un produit autonome qu’un projet-réponse à l’article de Cursor sur les scaling-agents
      L’objectif était d’implémenter des fonctionnalités comparables avec moins de LOC
      Il n’y a pas de feuille de style par défaut, d’où l’incohérence des couleurs de liens
      Sous Windows 11, le bouton retour fonctionne. Si vous êtes sur Windows 10, cela peut venir de là
  • Rendre le blog de Simon risque de devenir l’objectif emblématique des navigateurs IA
    Mais pour l’instant, on est plus proche d’un moteur de rendu que d’un vrai navigateur
    Il serait plus impressionnant de voir l’IA compléter l’implémentation d’API dans des projets comme Servo

    • D’accord. C’est insuffisant pour l’appeler un navigateur, il ne rend même pas correctement du HTML basique et plante souvent
      Cela dit, c’est mieux que l’essai de Cursor, et le fait que « ça compile » constitue au moins un progrès minimal
  • Je me demande combien de temps cela aurait pris en le faisant seul
    Pour comprendre l’aide apportée par l’agent, j’aimerais connaître la profondeur d’expertise impliquée dans ce guidage

    • Seul, cela aurait probablement été impossible
      Je connais Rust, mais pas X11, ni les API macOS ou Windows, donc il aurait été difficile ne serait-ce que de commencer
      En revanche, mon expérience des tests, de l’infrastructure et de la conception a beaucoup aidé pour collaborer avec l’agent
    • En le calculant avec l’outil sloccount,
      ce projet est estimé à 4,58 années-personne et 610 k dollars selon les critères de 2000,
      et à 5,6 ans et 1,38 million de dollars selon ceux de 2025
  • Ce qui rend cet article intéressant, ce n’est pas le résultat, mais le fait qu’il se concentre sur le processus de fabrication et les contraintes
    La plupart des articles se focalisent sur le résultat ou sur l’auteur, alors qu’ici on obtient des enseignements centrés sur le processus

    • En tant que personne ayant aussi écrit sur Cursor, je comprenais de moins en moins ce qu’ils voulaient dire par « succès »
      J’ai donc eu le sentiment qu’il était plus pertinent d’explorer ce qui est réellement difficile et quelles parties du processus ont mal tourné
  • Travail impressionnant
    Je me demande comment on pourrait implémenter l’accessibilité (Accessibility) sans dépendances Rust
    Sous Windows/macOS, c’est possible avec UI Automation et NSAccessibility, mais sous X11, il y a

    1. réimplémenter AT-SPI via D-Bus
    2. utiliser une bibliothèque C D-Bus existante
    3. ou passer par GTK ou Qt