GitHub Copilot

Comment ça marche

GitHub Copilot vit dans deux endroits. Dans l’éditeur de code, il complète, répond aux questions, et en mode agent modifie plusieurs fichiers et lance des commandes. Sur GitHub, il relit les pull requests et propose des corrections, et surtout l’agent de code prend une tâche assignée (une issue), travaille dans un environnement isolé, et ouvre une pull request avec son raisonnement, à relire et à fusionner par un humain.

Pour une entreprise, l’intérêt est l’intégration : les droits d’accès de GitHub s’appliquent à l’agent, les revues passent par le circuit habituel, les statistiques d’usage sont centralisées, et le choix du modèle se fait par politique. C’est l’outil des équipes techniques qui veulent de l’IA sans sortir de leur plateforme. Les gestes sont ceux de tout agent de code : des consignes écrites dans le dépôt, des tâches cadrées, une relecture systématique.

Un exemple concret

1. Le problème : 80 tickets de maintenance en attente depuis des mois : petits bugs, mises à jour de dépendances, documentation manquante. Personne n’a le temps.
2. La méthode : le responsable technique écrit un fichier de consignes dans le dépôt (conventions, tests à lancer, zones interdites) et assigne 30 tickets bien décrits à l’agent Copilot, en une après-midi.
3. Le lendemain : 30 pull requests, chacune avec le raisonnement de l’agent et le résultat des tests. L’équipe les relit : 22 fusionnées telles quelles, 6 corrigées en commentaire et reprises par l’agent, 2 fermées (tickets mal décrits).
4. La règle qui a tenu : aucune pull request de l’agent n’est fusionnée sans relecture humaine. La protection de branche l’impose techniquement.
5. Le résultat : le retard de maintenance résorbé en trois semaines, à raison d’une demi-journée de relecture par semaine.

Les deux tickets fermés étaient ceux que personne n’aurait su traiter non plus : ils étaient mal écrits. L’agent l’a révélé.

Ce que ça change pour une équipe

• L’agent travaille dans le circuit existant. Issues, pull requests, revues, permissions : rien de nouveau à mettre en place.
• Le retard de maintenance devient traitable. Les tâches bien décrites, longtemps repoussées, partent en lot.
• La qualité des tickets compte. Une tâche bien décrite est bien traitée. L’agent oblige à écrire clairement.
• Le choix du modèle est une politique. L’entreprise décide des modèles autorisés, de façon centralisée.

Les limites et les erreurs fréquentes

• Fusionner sans relire. La protection de branche qui exige une revue humaine n’est pas optionnelle.
• Assigner des tickets vagues. « Améliorer les performances » donne une pull request inutile. Une tâche, un résultat attendu, un test.
• Oublier les coûts d’usage. Les plans avancés facturent les requêtes premium au-delà d’un quota. Suivi mensuel.
• Croire que l’intégration dispense de former. Les gestes de l’agent s’apprennent : consignes, périmètre, relecture. Une demi-journée pour l’équipe.