GitHub Copilot CLI se lance avec copilot dans le dossier d’un projet Next.js et agit comme un agent de code dans le terminal. Ce guide montre comment configurer le projet, rédiger les instructions, boucler sur des petites étapes et vérifier les changements avec les tests, le lint et le build, que vous utilisiez l’App Router ou le Pages Router. Consultez aussi la page dédiée à GitHub Copilot CLI.
Pourquoi GitHub Copilot CLI convient au travail Next.js
Next.js mélange du rendu serveur, des composants client et serveur, des route handlers et des phases de build. GitHub Copilot CLI est pertinent parce qu’il vit dans le terminal : il peut lancer npm run lint, npm run test ou npm run build, lire les erreurs, puis modifier directement les fichiers concernés. Il connaît les conventions de Next.js, comme la séparation entre app/ et pages/, les Server Components et les fichiers route.ts. Au lieu de décrire un correctif, vous lui demandez de l’appliquer et de vérifier le résultat avec les commandes du projet.
Configurer le projet pour l’agent
Pour que l’agent comprenne votre projet, placez un fichier .github/copilot-instructions.md à la racine ou un AGENTS.md. Ce fichier doit rester court et factuel : commandes de build, de test et de lint, conventions de dossiers, et règles spécifiques à Next.js. Un exemple réaliste :
# Instructions pour GitHub Copilot CLI
## Commandes
- Install : npm install
- Lint : npm run lint
- Tests unitaires : npm run test
- Tests E2E : npm run test:e2e
- Build : npm run build
## Conventions
- Projet App Router ; les routes sont dans `app/`, le dossier `pages/` est obsolète ici.
- Les composants sont serveur par défaut. Ajoute `\"use client\"` uniquement si le composant utilise des hooks, `window` ou des événements.
- Les route handlers sont dans `app/api/.../route.ts`. Retourne des objets `NextResponse.json` typés.
- Les appels réseau et les secrets restent dans le code serveur. Ne jamais exposer une clé privée côté client.
- Ne modifie pas `next.config.*` ni `middleware.ts` sans demander confirmation.
- ESLint doit passer sans warning avant de proposer un diff.
- Vitest couvre les utilitaires et les composants purs ; Playwright couvre les parcours critiques.
La clé est d’indiquer les commandes exactes et les pièges propres à votre dépôt. Pour un point de départ plus détaillé sur la prise en main, le guide Utiliser GitHub Copilot CLI : le guide pas à pas est utile.
Boucle de travail : planifier, modifier, vérifier
Utilisez l’agent en petites étapes, pas en demandes ouvertes. Une boucle efficace : décrivez le comportement attendu, demandez un plan court, laissez l’agent modifier un fichier à la fois, lancez les tests et le lint, puis relisez le diff avant d’itérer. Exemples d’invites adaptées à Next.js :
- « Ajoute une route handler
GET /api/healthqui renvoie{ status: 'ok' }avec un type de retour explicite. » - « Transforme ce Server Component pour qu’il récupère ses données depuis
fetchavecrevalidate: 60, sans ajouter\"use client\". » - « Écris un test Vitest pour la fonction
calculateTotalavec les cas limite et ajoute-le àsrc/utils/__tests__. » - « Lance
npm run lint, corrige les erreurs ESLint et explique la cause racine de chaque correction. » - « Ajoute un test Playwright qui vérifie la navigation depuis la page d’accueil vers la page produit. »
Ce que l’agent gère bien et les pièges à surveiller
L’agent est efficace sur les tâches répétitives et structurelles : créer des routes, ajouter des Server Actions, générer des tests, corriger des types TypeScript ou des erreurs ESLint. Il se trompe plus souvent sur les frontières client/serveur et sur le cache. Voici quelques cas concrets :
| Tâche Next.js | Bonne invite | Piège à surveiller |
|---|---|---|
| Créer une route API | « Ajoute une route handler GET /api/health… » | Runtime par défaut, typage de NextResponse, en-têtes CORS. |
| Modifier un Server Component | « Ajoute un fetch avec revalidate… » | Ne pas transformer en Client Component sans raison, éviter de fuiter des secrets. |
| Corriger un bug d’hydratation | « Trouve l’origine du mismatch… » | Utilisation de Date, Math.random, window ou localStorage pendant le rendu serveur. |
| Ajouter un test navigateur | « Écris un test Playwright… » | Le serveur de dev doit démarrer, les ports et les attentes réseau doivent être stables. |
Sur un projet Next.js, surveillez particulièrement les variables d’environnement : seules celles préfixées NEXT_PUBLIC_ sont exposées au client. L’agent peut créer un code correct côté serveur puis l’importer dans un composant client sans s’en apercevoir. Relisez toujours les modifications qui touchent app/, les Server Actions et la configuration.
Tests et vérification pour Next.js avec l’agent
Faites de la vérification une condition de fin de tâche. Demandez explicitement à l’agent de lancer la commande de test adaptée, de lire la sortie et de corriger les échecs avant de proposer le diff. Pour un projet Next.js, la séquence minimale est npm run lint, npm run test et npm run build. Le build est important car il détecte les erreurs de typage, les problèmes de génération statique et les incompatibilités de rendu. Pour les parcours navigateur, Playwright est mieux adapté que des tests unitaires, car il exécute l’application dans un vrai navigateur. Les tests navigateur avec un agent IA : il vérifie votre app sont détaillés ici.
Exécuter plusieurs agents sur un projet Next.js avec AgentVera
Quand un projet Next.js grossit, AgentVera permet de lancer plusieurs agents en parallèle, chacun dans son propre worktree Git, ce qui évite qu’un agent écrase les fichiers d’un autre pendant qu’il travaille sur une page ou un route handler. La revue automatique de code par un second modèle est précieuse pour détecter les erreurs de frontière client/serveur, avec des liens vers file:line. Les checkpoints par tour offrent un filet de sécurité : une refactorisation risquée peut être annulée en un clic et rejouée. Enfin, les budgets de jetons empêchent un agent de dériver sur un long build.
En résumé
GitHub Copilot CLI devient un bon exécutant sur un projet Next.js à condition de cadrer le contexte : instructions courtes, boucle planifier-modifier-vérifier, et relecture des frontières client/serveur. La vraie valeur se voit sur les routes, les tests et les corrections répétitives, pas sur les décisions d’architecture. Avec ces repères, vous pouvez lui confier des étapes concrètes et garder la main sur le diff.