Les agents IA planifient, éditent des fichiers et lancent des tests. Journée type, checklist de brief, signaux d’alerte et organisation d’équipe pour garder le contrôle.
Écrit par
Les agents IA ne se contentent plus de répondre : ils planifient, appellent des outils, éditent des fichiers, lancent des tests, parfois ouvrent des PR. Pour un développeur web, le sujet n’est plus « est-ce que ça existe ? » mais comment garder le contrôle sans transformer sa journée en babysitting chaotique.
Ce guide propose une organisation concrète : agents, sous-agents, routines, exemples web, erreurs et bonnes pratiques.
Un chat : vous posez une question, vous obtenez du texte (parfois du code).
Un agent : vous donnez un objectif ; le système enchaîne des actions (lire, chercher, exécuter, écrire) jusqu’à un résultat ou une demande d’aide.
Un sous-agent : une unité déléguée, souvent avec son propre contexte, pour une sous-tâche (explorer le repo, écrire des tests, migrer un fichier). Le parent orchestre.
Une routine / subscription : le travail se déclenche sur un signal (horaire, PR, message Slack) sans nouveau prompt humain à chaque fois — selon les produits (par ex. Cursor Projects).
Le risque classique : multiplier les agents sans critère de done, sans revue, sans budget de tokens / temps. Le bénéfice classique : paralléliser l’exploration et le boilerplate pour vous concentrer sur les décisions.
Utile si les tâches sont isolables : « inventaire des usages d’une API », « générer fixtures », « proposer une migration fichier par fichier ». Moins utile si tout est couplé et demande votre jugement à chaque ligne.
Objectif : thème clair/sombre, persistance préférence, pas de flash incorrect, accessible au clavier.
Découpage agentique :
prefers-color-scheme, stockage.Brief type (à coller) :
Sans ce brief, l’agent ajoutera peut-être une lib entière pour un data-theme. Avec le brief, vous obtenez un diff reviewable.
Copiez cette liste avant chaque run un peu sérieux :
Plus le brief est clair, moins vous passez la journée à corriger des digressions. C’est le même principe qu’avec un freelance junior : le flou coûte cher.
Interrompez ou recentrez si vous voyez :
Un agent n’est pas un stagiaire à qui l’on laisse « apprendre sur le repo ». C’est un exécutant rapide qui a besoin de rails.
Lancer des agents pour « voir »
Le mode exploration libre coûte cher et pollue le repo. Timeboxez.
Accepter des PR énormes
Exigez des PR petites. Un agent peut produire beaucoup ; vous ne pouvez pas review beaucoup.
Oublier secrets et environnements
.env, clés API, bases de prod : hors de portée. Sandbox et comptes de dev.
Empiler les outils sans convention d’équipe
Cursor ici, Bot là, script maison ailleurs : documentez qui fait quoi.
Confondre vitesse de génération et vitesse de livraison
La livraison inclut revue, QA, déploiement, support. L’agent n’efface pas ces étapes.
Négliger l’accessibilité et la perf
Les agents optimisent souvent le « ça marche ». Ajoutez explicitement a11y / perf dans le done.
Fichier de règles projet (conventions, stacks interdites, style de PR). Les agents s’alignent mieux.
« Tests passent », « Lighthouse sur la page X au-dessus d’un seuil défini par l’équipe », « pas de nouvelle alerte a11y critique ». Évitez le vague.
Merge, prod, données utilisateurs : toujours un humain.
Limitez parallélisme et durée. Surveillez l’usage.
Ce qui a marché / échoué. Capitalisez.
Gardez l’ordre sain : compétences, qualité, puis automatisation.
Sur un solo, alternez les casquettes dans le temps : ne mergez pas dans la foulée d’un run de 40 minutes sans pause.
Préférez des commentaires PR et des checklists à des réunions « démo de l’agent ». L’artefact compte plus que le spectacle.
Si l’agent échoue deux fois sur la même tâche, reprenez en manuel ou reformulez le problème. Persister n’est pas une stratégie.
Pour approfondir côté outils, consultez la documentation de l’agent Cursor. Puis :
Non. Un renommage de variable ou une typo se règlent plus vite à la main.
Local : feedback machine réelle, secrets locaux. Cloud : parallélisme, machine allumée sans laptop. Souvent les deux selon la tâche.
Hors-scope écrit, budget de fichiers, « patch minimal ». Interrompez tôt.
Ils changent le métier (plus de revue, plus de cadrage). Ils ne dispensent personne d’apprendre les bases.
Stack, conventions de naming, interdits (pas de X lib), exigences a11y, format de PR.
Travailler avec des agents IA, c’est changer de posture : vous cadrez, vous déléguez par petits lots, vous vérifiez. Un brief clair, un critère de fin observable et une relecture systématique valent mieux que dix runs lancés en parallèle.
Gardez un rituel court, notez ce qui a fait gagner du temps, et conservez des fondamentaux solides pour juger ce que l’agent produit. Academy Yunt peut vous aider à entretenir ce socle.