Utiliser GitHub Copilot

Copilot est rapide, et c'est précisément cette rapidité qui le rend dangereux quand vous arrêtez de lire. L'assistant prédit du code plausible à partir de ce qui est dans son contexte. Plausible est le piège, car un code plausible compile, semble idiomatique et passe un coup d'œil, tout en faisant discrètement la mauvaise chose.

Considérons une développeuse, Maya, qui est en train de configurer un nouvel endpoint. Elle tape un nom de fonction, Copilot propose un bloc soigné qui appelle un client HTTP, et elle appuie trois fois sur Tab pour l'accepter. Ça semble correct. La construction est réussie. La pull request est fusionnée. Deux jours plus tard, le déploiement en staging échoue parce que la suggestion a importé axios-retry, un package que le dépôt n'a jamais utilisé ni installé. Copilot avait vu ce modèle dans des milliers d'autres projets et l'a proposé comme la ligne suivante évidente. Le véritable coût était la construction brisée, l'heure de confusion, et la dépendance maintenant à moitié intégrée dans le code, qui a éclipsé les quelques secondes de frappe qu'elle a économisées.

Cela arrive assez souvent pour qu'on s'y prépare. Les linter et les scanners automatisés attrapent la majorité des problèmes, mais des études sur le code généré par l'IA estiment que les dépendances hallucinées, les noms de packages qui n'existent pas ou n'ont jamais été approuvés, se retrouvent dans environ 1 échantillon sur 5. Un chèque vert vous indique que le code a été exécuté dans le pipeline, mais la correction, la sécurité et l'intention sont des questions distinctes auxquelles vous devez encore répondre.

Le bénéfice d'une bonne utilisation de Copilot est réel. Il élimine le boilerplate, les modifications répétitives et l'échafaudage de première ébauche qui drainent l'attention. Le lecteur qui garde le contrôle obtient cette rapidité sans les échecs au ralenti. Le contrôle vient de trois leviers : le contexte que vous fournissez, la portée que vous définissez avant qu'il n'écrive, et le diff que vous révisez avant de conserver quoi que ce soit. La section suivante décompose les surfaces sur lesquelles ces leviers agissent.

Copilot est un ensemble de surfaces qui partagent un modèle et diffèrent par la mesure dans laquelle elles touchent votre code sans demander. Savoir sur quelle surface vous vous trouvez vous indique combien de révision la sortie nécessite.

• Complétion en ligne. Au fur et à mesure que vous tapez, Copilot prédit les lignes suivantes à partir du code autour de votre curseur. Vous acceptez avec Tab. C'est la surface la moins risquée, mais la plus susceptible de laisser passer une importation ou un modèle indésirable parce que l'acceptation se fait en une seule frappe.
• Suggestions de prochaine édition (NES). Au lieu de compléter uniquement là où vous tapez, NES lit vos récentes modifications et prédit le prochain changement et son emplacement, y compris une suppression ou une modification ailleurs dans le fichier. Il est conçu pour l'effet d'une renommée ou d'un changement de signature.
• Mode question. Le chat répond à une question et peut proposer un extrait. Il ne modifie pas les fichiers. Utilisez-le pour comprendre le code ou évaluer une approche avant tout changement.
• Mode édition. Le chat applique une modification aux fichiers que vous nommez et montre un diff en ligne que vous approuvez avant qu'il ne sauvegarde. Vous gardez le dernier mot sur chaque fragment.
• Mode agent. Le chat raisonne à travers le projet, modifie plusieurs fichiers, exécute des commandes terminales, vérifie la sortie, et boucle jusqu'à ce que la tâche réussisse ou qu'il ait besoin de vous. Il met en avant les commandes risquées pour confirmation.

La distinction qui décide du succès est de faire correspondre la surface à la taille de la tâche. Une correction d'une ligne veut une complétion en ligne ou le mode édition, où le diff est petit et vous lisez tout. Un changement qui s'étend réellement sur plusieurs fichiers et nécessite l'exécution de commandes veut le mode agent. Opter pour le mode agent sur une modification triviale est l'erreur courante, car cela transforme un changement de la taille d'un coup d'œil en un diff tentaculaire que vous devez maintenant auditer.

Au-delà de l'éditeur se trouve l'agent de codage cloud. Vous assignez un problème GitHub à Copilot, mentionnez @copilot dans une pull request, ou le démarrez depuis le panneau des agents sur GitHub.com. Il fonctionne alors dans un environnement GitHub Actions éphémère, explore le dépôt, effectue des modifications sur une branche, exécute des tests et des linter, et ouvre une pull request. Les tâches sont limitées (un dépôt, une branche et une PR par tâche), l'étape de configuration de l'environnement est limitée dans le temps, et il ne peut pas contourner vos protections de branche. À travers toutes ces surfaces, la constante est le fichier d'instructions personnalisé, que la section suivante met en œuvre dans une tâche réelle.

Maya doit changer un comportement dans un dépôt réel. La fonction parseDate() dans src/lib/dateParser.ts génère une erreur sur une chaîne vide, et le formulaire d'inscription a besoin qu'elle retourne null à la place pour que le champ puisse rester optionnel. Elle veut le changement, un test, et rien d'autre.

1. Définir les règles une fois. Avant de toucher à quoi que ce soit, elle ouvre .github/copilot-instructions.md et confirme qu'il indique que le projet utilise Vitest, interdit les nouvelles bibliothèques de dates, et inclut un test avec chaque changement de comportement. Ainsi, elle n'a pas à répéter cela dans chaque prompt.
2. Choisir la bonne surface. Cela touche un fichier plus son test, une tâche qui convient au mode édition, donc elle reste en dehors du mode agent. Elle attache dateParser.ts et dateParser.test.ts avec des références # pour que le chat lise le vrai code.
3. Définir la portée du prompt. Elle écrit : "Dans dateParser.ts, faire en sorte que parseDate retourne null pour une chaîne vide au lieu de générer une erreur. Garder le comportement existant pour les entrées valides inchangé. Ne pas ajouter de nouvelle dépendance. Ajouter un test pour le cas de la chaîne vide." La contrainte concernant les entrées valides est importante, car elle indique à Copilot ce qui doit rester le même.
4. Lire le diff. Copilot propose une garde de deux lignes en haut de parseDate et un nouveau test. Le diff est petit, donc Maya lit chaque ligne. La garde retourne null avant que le chemin d'analyse existant ne s'exécute, et la branche pour les entrées valides reste inchangée. Elle accepte.
5. Vérifier. Elle exécute npm test. Le nouveau test pour la chaîne vide passe et les tests existants restent verts, confirmant que le changement préserve le comportement pour les entrées valides.
6. Committer petit. Un commit ciblé : la garde et son test. Le réviseur voit un diff de cinq lignes avec une intention évidente qui se lit exactement comme la correction de bug qu'il prétend être.

Comparez cela avec la version où elle aurait sauté la portée et tapé seulement "corriger la gestion des dates". Copilot, avec de la place pour interpréter, aurait probablement refactorisé le parseur, remplacé par une bibliothèque de dates, et réécrit deux appelants. Chaque ligne pourrait sembler raisonnable, et le diff serait maintenant de soixante lignes qu'elle doit défendre en revue. Même modèle, même dépôt. La différence était le contexte et la portée qu'elle a définis avant qu'il n'écrive. Cet écart entre un prompt serré et un prompt lâche est là où se trouvent la plupart des pièges.

Chacun de ces éléments semble être un progrès sur le moment, c'est pourquoi ils passent inaperçus.

• Accepter avec Tab en pilote automatique. La complétion est une frappe, donc une longue suggestion entre sans être lue. La solution est de traiter une complétion multi-lignes comme une pull request : lisez-la avant d'appuyer sur Tab, et méfiez-vous de toute ligne import que vous n'attendiez pas.
• Mode agent pour une ligne. Un changement trivial devient un diff multi-fichiers parce que l'agent a trouvé du travail "lié" à faire. La solution est d'adapter la surface à la tâche et d'utiliser le mode édition pour tout ce que vous pourriez décrire en une phrase.
• Fusionner sur le chèque vert. Un pipeline réussi confirme que le code a été exécuté, tandis que sa correction reste une question ouverte. La solution est de lire le diff et la liste des dépendances de toute PR d'agent de codage avant d'approuver, et de poser la question "qu'est-ce que ce code suppose, et est-ce sûr ?" comme question de révision qui vaut son pesant d'or.
• Réenseigner la même règle. Corriger une convention dans le chat à chaque session gaspille la correction. La solution est de l'écrire une fois dans copilot-instructions.md ou AGENTS.md pour que chaque futur prompt l'hérite.

Deux véritables cas limites nécessitent un jugement. La dépendance hallucinée. Copilot importera parfois un package qui n'existe pas ou n'a jamais été approuvé, et cela semblera tout à fait ordinaire dans le diff. Quand Maya voit une importation inconnue, la règle est de traiter un nom confiant comme non vérifié et de le vérifier par rapport au manifeste du projet et au registre avant d'accepter.

La grande PR d'agent de codage. Une réalité de 2026 est que l'agent cloud peut renvoyer un diff plus grand que vous ne pouvez lire attentivement en une seule fois, donc la capacité de révision est maintenant le goulot d'étranglement, avant le volume brut de code. La gestion consiste à définir la portée des problèmes pour que la PR résultante reste petite, et à repousser avec un commentaire @copilot demandant de diviser le travail quand une PR dépasse ce qu'un réviseur peut retenir dans sa tête. Ces habitudes deviennent plus difficiles, et plus précieuses, dès qu'une équipe partage le dépôt, ce qui est la dernière section.

Un développeur solo peut garder les conventions du projet en tête. Une équipe ne le peut pas, et Copilot générera volontiers du code dans cinq styles différents à moins que les règles ne vivent quelque part de durable. L'artefact qui corrige cela est un fichier d'instructions versionné, intégré dans le dépôt pour qu'il voyage avec le code et apparaisse en revue comme tout le reste.

Une chef d'équipe, Priya, met en place l'équipe de cette manière. Elle commet .github/copilot-instructions.md avec les choix de cadre, les dépendances interdites, le test runner, et la nomenclature maison. Pour un grand monorepo, elle ajoute des fichiers AGENTS.md imbriqués pour que le dossier backend et le dossier frontend portent chacun leurs propres règles, avec le fichier le plus proche prenant le pas. Comme il s'agit de simples fichiers Markdown sous contrôle de version, un changement aux conventions arrive sous forme de pull request révisée que toute l'équipe peut voir, plutôt que de vivre comme un paramètre privé dans l'éditeur de quelqu'un.

Le deuxième artefact est la discipline de révision autour de l'agent de codage. GitHub en impose une partie : la personne qui a créé un problème ne peut pas être l'approbateur final de la pull request de l'agent, donc un pair ou un réviseur désigné doit approuver. Priya s'appuie là-dessus. Son équipe garde les PR d'agent de codage sous 400 lignes, une taille liée à des cycles de révision environ 30-40% plus rapides, et la description de la PR enregistre que Copilot l'a écrite et ce que le problème demandait, pour qu'un réviseur lise avec les bonnes attentes.

La validation de sécurité s'exécute automatiquement sur la sortie de l'agent avant qu'un humain ne la voie. Copilot exécute CodeQL pour les vulnérabilités, vérifie les nouvelles dépendances ajoutées par rapport à la base de données des avis GitHub, et scanne les secrets exposés, et ces vérifications sont activées par défaut. Elles constituent un plancher sur lequel la lecture humaine doit encore se construire, car elles attrapent les modèles connus et manquent la logique erronée mais plausible que seul un réviseur remarque.

Le principe durable, quelle que soit la taille de l'équipe : Copilot propose, vous décidez, et la décision se fait sur le diff. Commencez par une petite chose. Écrivez un seul copilot-instructions.md pour un dépôt cette semaine, gardez vos prochains changements Copilot assez petits pour être lus en entier, et laissez l'habitude se développer à partir de là.