Nous laissons notre IA écrire du code, examiner les PR et se déployer elle-même.

La boucle qui s’est refermée

3 février 2026. Le message de commit indique : “feat(ci) : ajout de la validation en boucle fermée pour Claude autonome dans GitHub Actions.”

Ce commit a complété un circuit qui se construisait depuis des semaines. Le résultat : une boucle de développement entièrement autonome où l’IA écrit du code, le teste, le révise, crée une PR et valide le résultat — le tout sans qu’un humain touche au clavier.

Voici à quoi ressemble la boucle :

1. Un problème est signalé sur GitHub
2. Claude lit le problème et le code
3. Claude écrit un correctif sur une nouvelle branche
4. Claude exécute les tests
5. Si les tests échouent, Claude lit les erreurs et corrige le code
6. Lorsque les tests passent, Claude crée une PR avec un résumé
7. Une instance séparée de Claude examine la PR
8. Un humain passe en revue le tout et décide s’il faut fusionner

Les étapes 1 à 7 se déroulent automatiquement. L’étape 8 est la seule intervention humaine.

Comment nous en sommes arrivés là

Cela ne s’est pas fait en un jour. Cela a été construit progressivement sur six semaines, une capacité à la fois.

Semaine 1 : Résolution des problèmes (25 décembre). Nous avons commencé avec la version la plus simple : Claude lit un problème GitHub, écrit un correctif et pousse une branche. Pas de tests. Pas de révision. Juste “voici une branche avec un correctif potentiel, jetez un œil.”

Semaine 2 : Création de PR (26-27 décembre). Au lieu de simplement pousser une branche, Claude crée une véritable demande de tirage avec un titre, une description et un problème lié. Maintenant, le correctif est visible pour l’équipe sans avoir à vérifier manuellement les branches.

Semaine 3 : Révision de code (début février). Un flux de travail séparé de Claude se déclenche sur les nouvelles PR. Il examine le code à la recherche de bugs, de problèmes de sécurité et de violations de style. Des commentaires apparaissent sur la PR tout comme ceux d’un réviseur humain.

Semaine 4 : Validation en boucle fermée (3 février). La dernière pièce : Claude exécute les tests avant de soumettre la PR. Si les tests échouent, il lit la sortie d’erreur, modifie le code et essaie à nouveau. La PR n’est créée que lorsque la suite de tests réussit.

Chaque semaine a ajouté une couche. Chaque couche a rendu l’ensemble du système plus fiable.

Ce que nous avons appris sur le développement alimenté par l’IA

L’IA a besoin de contraintes, pas de liberté. Au début, Claude “corrigeait” parfois un petit bug d’interface utilisateur en refactorisant trois modules et en changeant le schéma de la base de données. Nous avons appris à ajouter des contraintes explicites : “Modifiez uniquement les fichiers directement liés au problème. Ne refactorisez pas. N’ajoutez pas de fonctionnalités. Corrigez le bug.”

Des résumés concis valent mieux que des explications détaillées. Les premières descriptions de PR de Claude faisaient 2 000 mots. Personne ne les lisait. Nous avons ajusté le prompt pour exiger des résumés de moins de 200 mots. “Qu’est-ce qui a changé et pourquoi” en deux phrases. C’est tout ce dont un réviseur a besoin pour commencer sa révision.

La révision de code détecte de réels problèmes. Nous étions sceptiques quant à la capacité d’une IA à examiner du code généré par une autre IA et à trouver quelque chose d’utile. Elle le fait. Gestion des erreurs manquante. Références nulles potentielles. Imports inutilisés. Problèmes de sécurité. Le réviseur de code IA n’est pas parfait, mais il détecte 80 % des problèmes que les humains repèrent en un coup d’œil — et il le fait en quelques secondes.

La séparation des préoccupations est importante. L’IA qui écrit le code et l’IA qui révise le code doivent être séparées. Même modèle, contexte différent, prompt différent, préoccupations différentes. L’écrivain est optimiste (“voici ma solution”). Le réviseur est sceptique (“qu’est-ce qui pourrait mal tourner ?”). Les deux perspectives sont nécessaires.

La méta réalité

Disons-le clairement : nous construisons une plateforme pour des agents IA autonomes, et nous utilisons des agents IA autonomes pour la construire.

Nos utilisateurs exécutent des agents IA qui exécutent du code dans des environnements isolés, lisent et écrivent des fichiers, et accomplissent des tâches de manière autonome. Notre processus de développement exécute des agents IA qui exécutent du code dans des environnements CI, lisent et écrivent des fichiers, et accomplissent des tâches de manière autonome.

La différence est superficielle : nos utilisateurs utilisent l’interface web de LikeClaw, et notre CI utilise GitHub Actions. Le schéma sous-jacent est identique : définir une tâche, laisser l’IA l’exécuter, examiner les résultats.

Ce n’est pas une coïncidence. Nous avons construit le pipeline de développement en utilisant les mêmes principes que nous enseignons à nos utilisateurs. Et les choses que nous apprenons en exécutant ce pipeline améliorent le produit que nous construisons pour eux. C’est un cycle vertueux.

Les chiffres

Depuis l’activation du pipeline de développement autonome :

• PR créées par l’IA : des dizaines
• Temps moyen de l’incident à la PR : minutes, pas heures
• Échecs de tests détectés avant soumission : plusieurs par semaine
• Incidents de production causés par du code écrit par l’IA : zéro (jusqu’à présent)

Ce dernier chiffre est celui qui compte le plus. Zéro incident de production. Chaque changement écrit par l’IA est passé par des tests, une révision par l’IA et une révision humaine avant fusion. Le filet de sécurité à trois couches fonctionne.

Ce n’est que le début

Aujourd’hui, l’IA gère les corrections de bugs, les mises à jour de dépendances et les implémentations de fonctionnalités simples. Demain, elle gérera des tâches plus complexes : refactorisation multi-fichiers, optimisation des performances, génération de tests.

L’idée clé n’est pas que l’IA puisse écrire du code. C’est que l’IA peut participer à un flux de travail de développement avec des garde-fous appropriés. Tests, révisions et supervision humaine rendent le code généré par l’IA sûr. Supprimez l’une de ces couches et vous avez un risque. Gardez les trois et vous avez un outil qui multiplie la production de votre équipe.

Nous sommes une petite équipe livrant 7,5 commits par jour. Certains de ces commits sont écrits par des humains. D’autres sont écrits par l’IA. Tous sont approuvés par des humains.

C’est l’avenir du développement logiciel. Pas l’IA remplaçant les développeurs. L’IA accélérant les développeurs. Avec des garde-fous appropriés. À 3 heures du matin. Pendant que l’équipe dort.