Un rapport de bug reste en général des jours dans le suivi avant que quelqu'un ouvre le fichier où il se cache. Et le correctif lui-même, quand on s'y met vraiment, est souvent le chapitre le plus court de toute l'histoire. Ce qui dévore l'agenda, c'est tout ce qui entoure : créer une branche, écrire un message de commit qui explique pourquoi le changement existe, pousser, ouvrir une pull request, décrire le diff assez bien pour que la personne en face n'ait pas à reconstituer l'intention, attendre, puis traiter les remarques et pousser à nouveau. Aucune de ces étapes n'est difficile. Empilées, elles découpent une journée en morceaux trop petits pour y penser.

C'est exactement sur ce milieu morcelé que vise l'agent de codage de GitHub Copilot. La présentation officielle mérite d'être prise au mot, parce qu'elle place l'attente au bon endroit : ce n'est pas la zone de saisie dans l'éditeur qui attend la question suivante, c'est un rôle qui prend une tâche en charge et la mène jusqu'au bout tout seul, en arrière-plan, pendant que vous faites autre chose.

Confier un ticket, récupérer une pull request

La mécanique est simple. On assigne un ticket à Copilot, ou on lance une tâche depuis le panneau d'agent de n'importe quelle page. Il part du titre, du corps et des commentaires déjà présents, explore le dépôt dans son propre environnement de développement temporaire, construit un plan, modifie le code et ouvre une pull request. À la fin, il vous inscrit comme relecteur et déclenche une notification, pour que la passation arrive là où vous la verrez vraiment.

Cet environnement est piloté par l'intégration continue. Les tests et les vérifications statiques du projet peuvent donc tourner avant que vous n'ayez regardé le résultat, et l'espace de travail peut être préparé d'abord selon les étapes que le dépôt documente déjà. Si un test n'est vert qu'avec une base de données et deux services d'arrière-plan actifs, cette préparation ne relève pas de la devinette.

Un détail fait trébucher quand les exigences bougent. Les commentaires ajoutés au ticket après l'assignation ne sont pas pris en compte. Les demandes complémentaires vont dans la pull request qu'il a ouverte. Laissez-y une note, et il ouvre une session fraîche pour la traiter ; comme le contexte des sessions précédentes sur la même pull request est conservé, la deuxième demande arrive généralement plus vite et avec moins de contresens que la première. Le même canal sert quand une exécution d'intégration continue échoue : on lui passe l'échec, il enquête et pousse la réparation.

Se relire avant que les autres ne lisent

Ce qui fatigue dans la relecture de modifications écrites par une machine, ce n'est pas qu'elles soient visiblement cassées. C'est qu'elles ont l'air de tourner, alors que personne dans l'équipe ne les aurait écrites ainsi. La construction officielle répond à cela en faisant relire son propre patch à l'agent avec la capacité de revue de code avant l'ouverture de la pull request, puis en itérant sur les retours reçus. Quand vous êtes inscrit comme relecteur, un passage a déjà eu lieu.

Le même flux lance l'analyse de code, la détection de secrets et le contrôle des vulnérabilités connues dans les dépendances. Une dépendance porteuse d'un problème connu, ou une chaîne dans le diff qui ressemble à un identifiant commité par accident, est signalée avant que la pull request ne devienne visible, et non après qu'un relecteur soit tombé dessus.

Écrire les habitudes de l'équipe dans un fichier de configuration

Un prompt court laisse beaucoup de place au jugement du moment, et le jugement du moment ne correspond pas toujours à la façon dont l'équipe travaille réellement. Les agents personnalisés servent à fixer cette part. Un fichier de configuration dans le dépôt permet de préciser dans quel ordre une catégorie de tâches doit être menée. Un agent dédié à la performance, par exemple, mesure d'abord, modifie ensuite le code, remesure pour prouver que le changement a produit un effet, et n'ouvre la pull request qu'après. La même configuration se partage à l'échelle d'une organisation, si bien que des équipes distinctes suivent une procédure au lieu d'en entretenir plusieurs versions privées.

Sur le bureau, les sessions se placent côte à côte

Dès que plusieurs tâches tournent en même temps, la difficulté se déplace vers la manière de les tenir séparées. L'application de bureau lance du travail depuis un ticket, une pull request, une phrase ou une session précédente, et peut faire tourner plusieurs sessions d'agent en parallèle. Chacune reçoit son propre arbre de travail et sa propre branche, de sorte que les fichiers, la conversation et l'état de la tâche restent étanches au lieu de se mélanger. Des versions existent pour Windows, macOS et Linux, les changements se vérifient dans le terminal intégré et dans le navigateur, et les pull requests produites passent toujours par les règles de revue, de vérification et de fusion que l'équipe applique déjà.

Agent de codage prend une tâche en arrière-plan et la conduit de la branche au commit puis à la pull request sans être poussé pas à pas.

Auto-vérification avant livraison améliore d'abord par la revue de code, puis lance les analyses de code, de secrets et de dépendances.

Sessions parallèles donnent à chaque session de bureau son arbre de travail et sa branche, de manière à ne jamais toucher les mêmes fichiers en même temps.

Comment le tarif fonctionne

Les offres individuelles sont passées à une facturation à l'usage en juin 2026, et la gamme va d'un palier gratuit à Pro, Pro+ et Max. Le palier gratuit comprend une quantité limitée de complétions ainsi qu'un usage limité du chat et de l'agent, et il inclut toujours l'outil en ligne de commande et le mode agent, donc un essai ne coûte rien au départ. Sur les paliers payants, la quantité de base correspond directement au prix de l'abonnement, avec par-dessus une enveloppe souple qui évolue avec le coût ; les complétions et les suggestions de modification suivante y sont illimitées et ne consomment pas cette enveloppe. Pour les paliers et les chiffres exacts, la page tarifaire officielle reste la seule source fiable.

Écrire le code n'est que la moitié du travail. L'autre moitié consiste à faire passer le changement par la revue, les vérifications et la fusion, et ce dispositif prend aussi cette moitié-là, ce qui laisse les humains n'apparaître que là où un jugement est réellement nécessaire.