Des agents sans interface dans vos scripts et votre CI

La plupart des agents de code ont un mode non interactif : vous passez un prompt, il travaille, il se termine avec un résultat. Pas de conversation, personne qui regarde.

Ça fait de l’agent une brique de base. Vous pouvez l’appeler depuis un script, une tâche planifiée ou un pipeline de CI, pour les corvées que personne ne veut faire à la main.

Ce qui change quand personne ne regarde

En conversation, vous repérez une mauvaise direction après deux messages. Sans interface, l’agent va jusqu’au bout tout seul. Tout ce que vous corrigiez en direct doit être décidé d’avance : le brief, les actions permises, les vérifications et le format de sortie.

1. ⏰DéclencheurHoraire, étiquette sur un ticket, build en échec
2. ↓→
3. 📄Brief fixeFichier de prompt versionné et intrants
4. ↓→
5. 🤖ExécutionRunner isolé, permissions limitées
6. ↓→
7. ✅VérificationsLes mêmes que pour une PR humaine
8. ↓→
9. 👀PR brouillonUn humain relit et merge

De bonnes premières tâches

Commencez par du travail répétitif, bien défini et facile à vérifier. Les meilleurs candidats ont déjà un succès ou un échec clair.

• Mises à jour de dépendances qui corrigent aussi ce que la mise à jour a brisé, jusqu’à ce que les tests passent.
• Erreurs de linter ou de types après qu’une règle devient plus stricte, par lots.
• Notes de triage sur un nouveau ticket : fichiers probables, tentative de reproduction, plan suggéré.
• Documentation dépassée : comparer la doc de l’API au code et proposer des corrections.

Gardez « implémente cette fonctionnalité à partir du ticket » pour plus tard. Cette tâche demande le pilotage humain vu au module 3.

Le brief devient un fichier

Un prompt sans interface devrait vivre dans le dépôt, relu comme du code. Il a besoin d’encore plus de structure qu’un brief interactif, parce que l’agent ne peut rien vous demander.

Tâche : mettre à jour la dépendance nommée dans DEP_NAME vers la version DEP_VERSION.

À faire :
- Mettre à jour le manifeste et le lockfile.
- Lancer la commande de vérification. Corriger uniquement ce que la mise à jour a brisé.
- Changements minimaux. Pas de refactorisation, pas de ménage non lié.

Arrête-toi et fais un rapport au lieu de deviner si :
- Une correction exige de modifier une API publique.
- Plus de 10 fichiers doivent être modifiés.
- Un test échoue pour une raison sans lien avec la mise à jour.

Sortie : une description de pull request avec ce qui a changé, ce qui a brisé,
comment tu l’as corrigé, et ce qu’un réviseur devrait vérifier deux fois.

Rendez-la observable

Une exécution qui échoue en silence est pire que pas d’automatisation du tout. Conservez la transcription complète de l’agent comme artefact de build, plafonnez son temps et son coût par exécution, et publiez un court résumé là où votre équipe regarde déjà.

Vérifiez vos acquis

🧠 Agents sans interface

Pointage: 0 / 4

1. 1. Quelle est la meilleure première tâche sans interface?

   Implémenter un nouveau parcours d’accueil à partir d’un ticketCorriger les erreurs de types après avoir activé un réglage plus strict du compilateurRevoir le schéma de la base de donnéesDécider quelles fonctionnalités bâtir ensuite

   Répétitif, bien défini, avec un succès ou un échec clair donné par le vérificateur de types. Les autres demandent du jugement humain en cours de route.

2. 2. Pourquoi un brief sans interface a-t-il besoin de conditions d’arrêt explicites?

   Pour économiser des tokensParce que l’agent ne peut pas vous poser de question en cours d’exécution : il doit savoir quand s’arrêter et faire un rapport plutôt que devinerParce que les systèmes de CI l’exigentCe n’est pas nécessaire, un bon modèle s’arrange

   Sans porte de sortie, un agent dans le doute continue et fait un choix que vous auriez refusé.

3. 3. Où devrait aller le résultat d’une tâche sans interface?

   Directement sur main si toutes les vérifications passentDans une pull request brouillon qui lance la CI habituelle et attend un humainDans un commentaire sur l’outil de clavardage, sans codeNulle part, juste dans les journaux

   Une PR brouillon réutilise tout votre processus de revue et de CI. L’agent propose, un humain merge.

4. 4. Une tâche d’agent de nuit est « verte » depuis des semaines, mais rien ne change jamais. Qu’est-ce qui manque?

   Un plus gros modèleDe l’observabilité : des transcriptions conservées et un résumé de ce qu’elle a vraiment faitPlus d’exécutions en parallèleUn prompt plus long

   Vert peut vouloir dire « n’a rien fait » ou « a abandonné en silence ». Conservez la transcription et rapportez les résultats, pas juste les codes de sortie.

↺ Recommencer

Avant de continuer

✅ À retenir

0 / 4 complété

• Mes briefs sans interface vivent dans le dépôt et incluent des conditions d’arrêt explicites.
• Mes premières tâches sans interface sont des corvées répétitives avec un succès ou un échec clair.
• Les tâches sans interface ouvrent des pull requests brouillons. Un humain merge toujours.
• Chaque exécution conserve sa transcription et a un plafond de temps et de coût.

↺ Réinitialiser