Yandex automatise la mise à jour de Chromium avec un agent LLM

Toutes les quatre semaines, Yandex Browser passe à une nouvelle version de Chromium. L'utilisateur final ne s'en aperçoit pas, mais les développeurs doivent résoudre des milliers de conflits de code et corriger autant d'erreurs de compilation. Yandex a décidé d'automatiser cette routine et a intégré un agent LLM au processus de synchronisation avec l'upstream.

Une mise à jour si vaste qu'elle engloutit des mois

Chaque cycle de mise à jour apporte environ 10 000 commits issus de Chromium principal et quelque 1500 modifications propres accumulées dans le fork de Yandex. Résultat : plus d'un millier de conflits de fusion, plusieurs milliers d'erreurs de compilation et une multitude de dépendances qui ont cessé de fonctionner avec la nouvelle version. Le processus mobilise des dizaines de développeurs de niveaux variés. Le coût total d'un cycle se chiffre en plusieurs mois-hommes. C'est du temps que l'équipe ne peut pas consacrer aux fonctionnalités, à l'optimisation ou aux bugs signalés par les utilisateurs. De la pure routine qui bloque le développement.

Pourquoi un simple chat avec un LLM ne suffit pas

On pourrait croire qu'il suffit de coller l'erreur dans ChatGPT pour obtenir un correctif. En pratique, cela ne marche pas. Yandex n'a pas affaire à des erreurs isolées : il s'agit de la mise à jour régulière d'un gros fork à l'historique de modifications profond.

Il faut traiter des milliers de problèmes simultanément, en tenant compte du contexte de l'upstream et des modifications maison. Une requête LLM standard est inutile ici : le contexte est insuffisant, les solutions se contredisent et chaque étape demande une validation. Yandex est donc allé plus loin : plutôt que de coller les erreurs dans un chat, il a intégré un agent LLM qui comprend la structure du projet et peut analyser et résoudre les conflits de manière autonome.

Comment l'agent résout les conflits

L'agent travaille en deux temps. Il commence par analyser le conflit : ce qui a changé dans l'upstream, ce qui existe dans le fork, pourquoi les deux sont incompatibles et quelles dépendances sont rompues. Il propose ensuite une résolution qui tient compte des deux côtés. Voici les principales tâches que prend en charge l'agent :

• Résolution des conflits de fusion, avec analyse des modifications des deux côtés
• Correction des erreurs de compilation (erreurs de types, d'édition de liens, missing includes)
• Validation des solutions : vérifier que rien n'a cassé dans les modules voisins

L'agent n'est pas parfait : les cas complexes exigent encore un travail manuel. Mais il accomplit seul 70-80 % du travail. Les développeurs passent en mode revue de code plutôt qu'en écriture de code, ce qui est bien plus rapide et efficace.

Ce que cela change pour le développement de navigateurs

Les éditeurs de gros forks (navigateurs, systèmes d'exploitation, noyaux embarqués) entrevoient désormais une voie concrète vers une synchronisation avec l'upstream moins pénible. Les agents LLM trouvent leur place non dans des démos et présentations tape-à-l'œil, mais dans des processus industriels de routine, où ils réduisent réellement les coûts. C'est un signe de maturité des LLM dans le développement : non pas un remplaçant du développeur, mais un assistant intelligent pour la routine, qui libère du temps pour la créativité et les nouvelles fonctionnalités. Yandex tire le maximum de ce qui a été ajouté aux modèles ouverts : pas des hallucinations, mais une systématisation du travail.