Claude s’invite dans le matériel, pas seulement dans le code

Claude Code ne sert plus seulement à écrire du logiciel : Christian Schaller, directeur ingénierie chez Red Hat, l’a utilisé pour faire fonctionner un scanner et une caméra récalcitrants sous Linux. Dans les deux cas, l’agent a comparé le comportement du matériel avec celui de pilotes Windows pour proposer des corrections exploitables. L’enjeu dépasse le bricolage individuel : cette méthode pourrait accélérer le portage de périphériques vers Linux, sans promettre la magie. Le scanner, lui, n’avait pas reçu le mémo du monde libre.

Quand l’agent sert de caméra d’appoint

Le premier chantier de Schaller concernait un scanner Plustek OpticFilm 8200i annoncé comme compatible, mais équipé d’un chipset que le pilote Linux ne reconnaissait pas. Après plusieurs essais infructueux, il a fini par donner à Claude Code un environnement plus riche : un Windows driver à observer, des captures USB et un système de comparaison entre l’implémentation du fabricant et son propre code. Résultat, il a obtenu une première numérisation exploitable en quelques heures, puis l’infrarouge de suppression des poussières. Schaller a ensuite publié l’approche sous forme de projet open source, hw-harness, sous licence MIT.

Le principe est simple à décrire, mais moins à mettre en œuvre. L’outil fait tourner le pilote Windows dans une machine virtuelle KVM, capture les échanges via usbmon sur l’hôte Linux, puis laisse l’agent repérer où le pilote expérimental diverge. Schaller inclut aussi des scripts pour récupérer des descripteurs de périphériques, des entrées de registre, des tables ACPI et des fichiers INF. L’idée n’est pas de fabriquer un pilote parfait d’un seul coup, mais d’arriver à un code qu’un mainteneur puisse intégrer sans lever les yeux au ciel.

Le driver qui avance plus vite qu’un humain fatigué

Schaller a aussi mesuré les performances. Sur son test d’une seule image, son pilote a terminé un scan en 34,6 secondes, contre 54,4 secondes pour la version amont SANE, avec la même finesse de détail à 3 600 dpi. Son code gère aussi la correction infrarouge, l’exposition pour les négatifs denses, ainsi que la couleur et le niveau de gris jusqu’à 7 200 dpi. Un autre développeur avait déjà ajouté la prise en charge du nouvel OpticFilm 8200i à SANE en septembre 2026, ce qui réduit l’intérêt d’une branche concurrente à terme, mais pas celui de la démonstration.

Schaller a construit autour de ce travail une application GNOME baptisée Negative Vibes, écrite en Rust avec l’aide de Claude. Elle conserve les données 16 bits d’origine, y compris le canal infrarouge, puis permet de retirer la poussière, d’ajuster l’image et d’exporter en TIFF, JPEG, PNG ou DNG. Ici, l’IA n’a pas remplacé l’expertise matérielle ; elle a surtout accéléré la rétro-ingénierie. C’est moins spectaculaire qu’un robot qui comprend tout, mais nettement plus utile.

Une caméra ThinkPad, puis des correctifs pour le noyau Linux

Le second cas d’usage est encore plus parlant. Sur son Lenovo ThinkPad X1 Carbon Gen 14 Aura Edition, la caméra interne produisait sous Linux des images trop sombres, avec des coins très assombris et une dominante jaune-verte. Schaller ne disposait pas de trafic USB à analyser, car il s’agissait d’un capteur MIPI interne, pas d’un périphérique USB classique. Il a donc fourni à Claude des fichiers de configuration Windows, des entrées de registre, des tables ACPI et des propriétés matérielles, puis a ajouté une webcam USB de référence. En fin de journée, il avait des patches pour le noyau Linux et pour libcamera.

Les corrections touchent plusieurs points : un bug de sélection de recadrage, un registre de motif de test mal défini et une limite de gain analogique qui faisait perdre environ 1,8 stop de sensibilité. Côté traitement d’image, Claude a aussi aidé à corriger l’absence de lens-shading correction, responsable de coins environ 2,7 stops plus sombres que le centre, ainsi qu’un écart de calcul sur le niveau noir. En faible lumière, la luminosité des images est passée de 31,1 à 90,9, et les couleurs se sont rapprochées de la webcam de référence. Les patches n’ont pas encore été fusionnés, mais ils sont en revue chez Nvidia et Red Hat.

Ce que cette méthode change pour les pilotes matériels

Cette séquence dit quelque chose de plus large sur l’usage des agents de code. Leur intérêt n’est pas seulement d’écrire du code plus vite ; ils savent aussi explorer un système à partir d’indices hétérogènes, comparer des traces, proposer des corrections et garder la mémoire du contexte mieux qu’un humain qui a laissé passer trois semaines. Pour les équipes qui maintiennent des pilotes, des couches d’accès matériel ou des outils de bas niveau, cela peut réduire le temps passé à reconstituer un protocole propriétaire. Reste une limite simple : un correctif utile doit encore passer la revue, les tests et la validation sur le terrain.

De quoi intéresser les développeurs système, les mainteneurs Linux et, plus largement, tous ceux qui travaillent sur des périphériques mal documentés. Le modèle ne remplace ni le matériel, ni la patience, ni les captures USB. Il les met juste en ordre plus vite.