Notre IA résout ses propres problèmes GitHub à 3h du matin.

Jour de Noël, 2025

La plupart des équipes prennent le 25 décembre de congé. Nous aussi — en quelque sorte. Mais notre IA ne l’a pas fait.

Le jour de Noël, nous avons poussé un commit intitulé “ajouter le résolveur automatique de problèmes de Claude.” C’était un workflow GitHub Actions qui faisait quelque chose d’inhabituel : lorsqu’un nouveau problème était signalé dans notre dépôt, Claude lisait automatiquement le problème, analysait le code, écrivait un correctif, créait une branche et ouvrait une demande de tirage.

Pas d’humain dans la boucle. L’IA lit le rapport de bogue. L’IA corrige le bogue. L’IA soumet le correctif pour révision.

Nous sommes revenus de vacances pour trouver des demandes de tirage en attente. Rédigées par une IA. À 3 heures du matin.

Pourquoi nous avons construit cela

Nous sommes une petite équipe qui construit une plateforme complexe. Avec 632 commits en 84 jours, nous livrons rapidement. Mais la vitesse crée un défi de maintenance : les bogues n’attendent pas les heures de bureau.

Un utilisateur à Shanghai signale un problème à 14 heures, heure locale. Cela fait 1 heure du matin pour nous. Avec un workflow traditionnel, le bogue reste sans réponse pendant 8 heures jusqu’à ce que quelqu’un se réveille, lise le problème et commence à travailler dessus.

Avec le résolveur automatique de problèmes, Claude prend en charge le problème en quelques minutes. Au moment où nous nous réveillons, il y a une demande de tirage en attente avec un correctif, une description de ce qui a été changé et pourquoi, et une révision de code automatisée.

Nous ne remplaçons pas les développeurs. Nous leur donnons une longueur d’avance. Au lieu de “lire le problème, comprendre le bogue, écrire le correctif, créer la PR,” le workflow du matin devient “réviser la PR, approuver ou demander des modifications, fusionner.”

L’évolution : du résolveur de problèmes à un pipeline CI complet

Le commit du jour de Noël n’était que le début. Au cours des semaines suivantes, nous avons construit l’ensemble du pipeline de développement autonome :

Résolution automatique des problèmes. Claude lit les nouveaux problèmes, analyse le code pertinent, écrit un correctif et crée une PR. Les messages de commit font référence au numéro du problème. La description de la PR explique le changement.

Révision de code automatisée. Lorsqu’une PR est créée — par un humain ou par Claude — une instance distincte de Claude révise le code. Elle vérifie les bogues, les problèmes de sécurité, les violations de style et la couverture des tests. La révision apparaît sous forme de commentaires sur la PR, tout comme celle d’un réviseur humain.

Validation en boucle fermée. Claude n’écrit pas seulement du code. Il exécute les tests. Si les tests échouent, il lit l’erreur, corrige le code et essaie à nouveau. La PR n’est soumise que lorsque les tests réussissent.

Création automatique de PR. Lorsque Claude pousse une branche, il crée automatiquement une PR avec un résumé des changements. Aucune étape manuelle requise.

Le moment méta

Il y a quelque chose de profondément satisfaisant à propos d’une plateforme IA qui utilise l’IA pour se construire elle-même.

Notre produit permet aux utilisateurs d’exécuter des agents IA qui exécutent du code, gèrent des fichiers et automatisent des tâches. Et notre processus de développement utilise des agents IA qui exécutent du code, gèrent des fichiers et automatisent des tâches.

Nous consommons notre propre cuisine. Chaque jour.

Lorsque Claude résout un problème dans notre dépôt, il utilise les mêmes modèles que nos utilisateurs lorsqu’ils exécutent des agents IA sur LikeClaw. Exécution en bac à sable. Accès au système de fichiers. Appel d’outils. La différence est que nos agents orientés utilisateur s’exécutent dans des bacs à sable E2B dans le cloud, tandis que notre agent CI s’exécute dans GitHub Actions.

Mêmes principes. Même capacités. Même modèle de confiance : l’IA fait le travail, les humains examinent les résultats.

Ce que nous avons appris

Des résumés de PR concis comptent. Au début, Claude écrivait des descriptions de PR de 2 000 mots pour un correctif de trois lignes. Nous avons ajusté les invites pour imposer des résumés concis. “Qu’est-ce qui a changé et pourquoi” en deux phrases, pas deux pages.

L’IA a besoin de contraintes. Sans garde-fous, Claude “corrigeait” parfois un problème en refactorisant la moitié du code. Nous avons ajouté des règles : ne changer que les fichiers directement liés au problème. Ne pas refactoriser. Ne pas ajouter de fonctionnalités. Corriger le bogue.

La révision de code détecte de vrais problèmes. La révision de code automatisée a détecté de réels bogues — risques de pointeur nul, gestion des erreurs manquante, problèmes de sécurité potentiels. Ce n’est pas un remplacement pour la révision humaine, mais c’est un premier passage significatif.

Le correctif à 3 heures du matin est réel. Nous nous sommes réveillés avec des demandes de tirage qui ont corrigé des problèmes signalés pendant la nuit. Nous avons examiné le changement. Nous l’avons fusionné. Le bogue était corrigé avant que notre café du matin ne soit froid. C’est l’avenir du développement logiciel.

C’est à cela que servent les agents IA

Pas à générer du lorem ipsum. Pas à écrire des lettres de motivation. Pas à résumer des articles que vous pourriez lire vous-même.

Les agents IA sont faits pour faire du vrai travail, de manière autonome, à grande échelle, 24 heures sur 24. Corriger des bogues pendant que l’équipe dort. Réviser du code avant que l’auteur ne termine son déjeuner. Créer des demandes de tirage à partir de descriptions de problèmes sans qu’un humain tape une seule ligne.

Nous avons construit cela pour nous d’abord. Maintenant, nous le construisons pour tout le monde.