Pour vendre son nouvel agent Codex aux utilisateurs de PC, OpenAI a diffusé lors du Super Bowl 2026 une publicité montrant… une interface macOS maquillée sur un ordinateur Windows. Un faux raccord repéré par les internautes, qui trahit sûrement un retard technique.
Avec un tel intitulé, le premier ticket ouvert dans le dépôt GitHub de CCC n’est pas passé inaperçu. Il faut dire que le projet lui-même a particulièrement attiré l’attention. Et pour cause : Claude est parvenu à créer son propre compilateur C.
Un ingénieur d’Anthropic est à l’origine de la démarche. Il lui aura fallu deux semaines, environ 2000 sessions Claude Code et près de 20 000 $ de coûts d’API pour la mener à bien, explique-t-il. Au final, il y a environ 100 000 lignes de code Rust… et la capacité à compiler Linux 6.9 sur x86-64, i686, AArch64 et RISC-V 64, sans dépendances.
GCC comme oracle et un lieur qui fait encore défaut
La compilation se fait sans erreurs (ce qui est notable), mais l’assemblage et l’édition de liens – composantes cruciales d’un compilateur – ne sont pas stables. Par ailleurs, les niveaux d’optimisation doivent encore être implémentés.
Si la supervision humaine fut minimale (pas de consignes de débogage, notamment, ni de fourniture de feed-back sur la qualité du code), Claude n’a pas été tout à fait autonome. Outre les tests qui ont permis de le garder sur les rails au fil du projet, un algorithme de synchronisation a évité que des agents tentent de résoudre le même problème en même temps.
CCC (Claude’s C Compiler) a effectivement exploité des instances parallèles de Claude Opus 4.6. L’approche a favorisé la spécialisation des tâches : un agent pour fusionner le code en double, un deuxième pour écrire la doc, un troisième pour analyser la conception du projet point de vue d’un développeur Rust, etc.
L’algo en question pose des verrous sur des tâches en écrivant des fichiers texte dans un dossier current_tasks/. Les conflits de merge sont fréquents, mais Claude sait les gérer, nous affirme-t-on. À chaque session, tous les agents ont leur propre conteneur Docker avec une copie locale du repo Git.
Ce système a fonctionné pour compiler de « petits » projets open source (SQLite, QuickJS, mbedTLS, libpng…), chaque agent pouvant se concentrer sur l’un d’entre eux. Avec Linux, ils ont fini par converger sur la même tâche. Et donc à se « marcher sur les pieds ». Le compilateur GCC a alors été utilisé comme oracle. Le tout sans orchestrateur : chaque agent décide de ses actions, en documentant ses éventuels échecs.
Une compilation moins efficace…
Claude Opus 4.5 fut le premier LLM d’Anthropic capable de produire un compilateur réussissant les suites de tests référentes, fait remarquer l’ingénieur. L’apport de Claude Opus 4.6 est le passage à l’échelle, sur un projet de l’ampleur du noyau Linux.
Le code généré n’est cependant pas très efficace, reconnaît-il. Même avec toutes les optimisations possibles, on n’atteint pas ce que GCC délivre sans.
Un comparatif tiers le confirme. Son auteur a analysé, d’une part, la compilation de Linux 6.9 (x86-64). De l’autre, celle de SQLite 3.46.0. Son setup : deux VM Debian sous Proxmox, chacune sur son nœud physique (6 vCPU, 16 Go de RAM, 100 Go NVMe).
Avec GCC 14.2.0, la compilation de SQLite prend 64,6 s. Il en faut 87 avec CCC.
Sans optimisation, GCC produit un binaire de 1,55 Mo. Contre 4,27 Mo pour CCC. Le premier consomme au maximum 272 Mo de RAM ; le second, 1616 Mo.
… et surtout une exécution beaucoup plus lente
L’écart est beaucoup plus net sur le temps d’exécution : 10,3 secondes avec GCC sans optimisation… contre 2 h 6 min avec CCC. Cette lenteur n’est pas uniforme. Elle est moindre sur des requêtes somples comme la suppression de tables ou l’ajout de lignes. Elle est au contraire bien plus importante avec les opérations qui impliquent des boucles imbriquées.
Cette différence s’explique entre autres par une mauvaise allocation des registres CPU (CCC éparpille les variables sur la pile). La taille du code généré joue aussi : elle favorise les défauts de cache d’instructions (le CPU ne peut pas tout conserver en L1/L2). De surcroît, la production de pointeurs corrompus et l’absence de génération de tables de symboles rend le profilage et le débogage impossibles.
Pour ce qui est du kernel, CCC compile tous les fichiers sources sans erreur, mais échoue au niveau du lieur. Il génère, en particulier, des entrées de relocalisation incorrectes pour les jump labels.
Vous rêvez de pouvoir dire à une IA "va sur ce site, remplis ce formulaire avec mes infos, et clique sur le gros bouton rouge" et que ça se fasse tout seul pendant que vous allez vous chercher un café ? Hé bien c'est exactement la promesse de BrowserWing, un petit outil open source qui fait le pont entre vos modèles de langage (via les API d'OpenAI, Claude, DeepSeek...) et votre navigateur Chrome ou Chromium.
En fait BrowserWing va enregistrer vos actions dans le navigateur (clics, saisies, navigation), les transformer en scripts, puis les convertir en commandes MCP (Model Context Protocol). Pour ceux qui débarquent, le MCP c'est le nouveau standard qui permet aux IA de discuter avec des outils externes. Vraiment c'est super pratique comme protocole. Je l'utilise tous les jours, et je vous recommande vraiment de vous y intéresser.
Du coup, grâce à ça, vos agents IA peuvent ensuite rejouer ces actions. C'est comme si vous créiez des macros pour le web, mais intégrables dans un flux piloté par l'intelligence artificielle.
Attention toutefois, on est sur une version très précoce (v0.0.1), donc le jeu de commandes est encore limité et les choses peuvent bouger mais l'idée est là...
Voilà, c'est parfait pour simplifier l'automatisation de toutes ces tâches répétitives et reloues qu'on se cogne quotidiennement sur le web. On peut envisager du scraping, du remplissage de formulaires, ou même des workflows qui enchaînent plusieurs sites et l'avantage par rapport à un script Selenium ou Playwright classique, c'est que l'IA peut potentiellement mieux digérer les petits changements visuels et comprendre le contexte de la page.
Comment l'installer sans se brûler les ailes
Pour tester la bête, vous avez deux options. La plus simple, c'est de récupérer le binaire précompilé directement sur la page Releases du projet GitHub. Vous prenez celui qui correspond à votre OS, et hop, c'est parti.
Sur Linux ou macOS :
chmod +x ./browserwing
./browserwing --port 8080
Sur Windows :
./browserwing.exe --port 8080
Une fois que le serveur tourne, il suffit d'aller sur http://localhost:8080 pour accéder à l'interface. Pour les plus barbus qui aiment bien compiler eux-mêmes (je sais qu'il y en a parmi vous), c'est aussi possible via un petit make install et make build-embedded, à condition d'avoir Go 1.21+ et pnpm 9 sous le coude.
Le futur de la navigation assistée ?
Une fois l'interface lancée, le workflow est plutôt intuitif. Vous ouvrez un navigateur piloté par BrowserWing, vous cliquez sur "Enregistrer", et vous faites votre petite popote habituelle. Une fois fini, l'outil vous génère un script que vous pouvez éditer visuellement avant de le transformer en commandes MCP exploitables par n'importe quel agent compatible.
Le truc vraiment cool, c'est que BrowserWing gère la persistance des cookies entre les sessions. Ça veut dire que vous pouvez automatiser des actions sur des sites où vous devez être connecté sans avoir à vous retaper l'authentification à chaque fois. L'IA peut ensuite combiner plusieurs scripts et prendre des décisions en fonction du contenu de la page. C'est plus souple qu'un script codé en dur qui panique au moindre popup inattendu.
Bref, si vous passez vos journées à faire du copier-coller entre des sites web ou que vous voulez voir ce que l'automatisation par IA a vraiment dans le ventre (même si c'est encore "work in progress"), allez jeter un œil à BrowserWing. C'est sous licence MIT, c'est gratuit, et ça pourrait bien vous sauver quelques heures de vie par semaine à l'avenir. D'ailleurs, ça me rappelle un peu ce que je vous disais sur
Chrome-GPT
à l'époque, mais en beaucoup plus moderne grâce au MCP.
Un immense merci à Lorenper pour le partage de cette pépite !