GitHub Copilot dans VS Code : coordonner sessions, navigateur et coûts

En juin et début juillet 2026, GitHub a élargi le flux agent de Copilot dans Visual Studio Code (VS Code). Les nouveautés comprennent un navigateur intégré, des sessions parallèles, une visibilité sur la consommation et des améliorations d'Autopilot. Ces fonctions changent la coordination, pas la responsabilité sur le code.

Le cas pratique contient deux tâches indépendantes : créer une carte pour l'index du blog et concevoir une page 404 localisée. Chacune aura ses fichiers et ses critères. Elles ne seront intégrées qu'après avoir passé leurs tests.

Les nouveautés élargissent l'espace de travail agent

Au 15 juillet 2026, GitHub indiquait que les outils de navigateur agent étaient disponibles de façon générale dans VS Code. L'agent pouvait naviguer, inspecter du contenu, capturer des écrans et valider des applications web. Le navigateur intégré offrait aussi historique, recherche et permissions contrôlées.

La fenêtre Agents permettait de maintenir des sessions en parallèle et plusieurs conversations dans une session. GitHub affichait également le coût total, l'usage supplémentaire et la consommation des sous-agents. Autopilot pouvait avancer avec moins d'intervention, tout en restant dans les permissions et la configuration.

La vue d'ensemble de dépôt disponible sur GitHub.com ajoutait des repères sur l'objectif, les technologies et la contribution. Utilisez-la comme carte initiale. Lisez ensuite routes, tests et règles qui gouvernent le changement réel.

Divisez par contrat et par dépendance

La carte de blog touche la liste, ses styles et le test de lien. La page 404 utilise une autre route, des messages localisés et son propre parcours. Aucune n'a besoin du résultat non intégré de l'autre : elles forment donc de bonnes candidates à des sessions séparées.

Avant de commencer, écrivez le contrat de chaque tâche. La carte doit afficher titre, résumé, date et lien correct ; la 404 doit expliquer l'erreur, offrir une navigation utile et fonctionner en trois langues. Ajoutez les fichiers autorisés et les commandes de test.

Ne parallélisez pas deux tâches qui modifient le même schéma, état global ou contrat de route. Le conflit sémantique peut exister même si Git fusionne les lignes sans protester. Le guide des agents IA développe cette différence entre autonomie et permissions.

Isolez chaque session et sa preuve

Attribuez une branche ou un espace de travail par tâche. Chaque session doit connaître son objectif, ses fichiers autorisés, ses tests et sa condition d'arrêt. Évitez que les deux éditent des styles globaux si elles peuvent utiliser des classes distinctes ou une décision préalable.

La session de la carte reçoit un article d'exemple et la route de l'index. La session de la 404 reçoit les messages existants et les routes de navigation autorisées. Toutes deux peuvent lire des règles communes, mais n'écrivent que dans leur périmètre.

Demandez un livrable concret : liste de fichiers, explication du changement, tests exécutés et limites. Si l'agent découvre une dépendance partagée imprévue, il doit s'arrêter et demander une coordination. Il ne doit pas la résoudre en élargissant ses permissions.

Vérifiez la carte dans le navigateur

Les tests de composant peuvent confirmer titre, résumé et lien. Le navigateur doit ouvrir l'index, focaliser la carte au clavier et suivre le lien jusqu'à l'article. Répétez le parcours à 390 px et vérifiez qu'un texte long ne provoque pas de débordement.

Contrôlez aussi les thèmes clair et sombre, la console et le chargement de l'image. Une belle capture ne prouve ni le focus, ni l'URL, ni l'absence d'erreurs d'hydratation. Les outils de navigateur agent aident à réunir cette preuve, mais vous devez relire quel parcours ils ont exécuté.

La session livre des résultats et n'intègre pas d'elle-même. Si un test échoue, corrigez dans la tâche ou déclarez le blocage. Le cycle de vibe coding applique la même séquence de brouillon et de vérification.

Vérifiez la page 404 comme un parcours indépendant

Ouvrez une URL inexistante dans chaque langue et contrôlez code, contenu et liens. La page doit aider à revenir au produit sans prétendre que la ressource existe. Testez le clavier, une largeur étroite et les textes localisés.

Un test unitaire peut confirmer clés et liens, tandis qu'une requête HTTP vérifie la réponse réelle. Le navigateur ajoute focus, mise en page et console. Les trois couches évitent qu'une page visuellement correcte cache une route mal configurée.

La 404 ne doit pas non plus dépendre de la nouvelle carte. Si les deux sessions ont besoin du même icône ou du même jeton, décidez ensemble avant d'intégrer. Ne copiez pas une seconde version pour contourner le conflit.

Intégrez dans un ordre contrôlé

Relisez d'abord le périmètre de chaque diff. Intégrez une tâche, lancez ses tests, puis incorporez la seconde. À la fin, rejouez la suite et les parcours sur l'état combiné.

Une fusion propre ne garantit pas la compatibilité. Deux changements peuvent introduire des noms de classe, des messages ou des attentes contradictoires sans conflit textuel. La validation postérieure à l'intégration détecte ce type de dérive.

Gardez un moyen d'annuler chaque tâche. Des commits séparés et des critères documentés permettent de retirer la page 404 sans perdre la carte, ou l'inverse. Le parallélisme n'apporte de la vitesse que s'il conserve cette traçabilité.

Le budget limite Autopilot et les sous-agents

La visibilité des coûts permet de comparer sessions complètes et travail délégué. Fixez un budget de crédits ou de temps avant de commencer et une condition d'arrêt à l'acceptation, à la limite atteinte ou devant une décision humaine. N'utilisez pas Autopilot comme une permission indéfinie.

Reliez consommation et résultat. Une session qui produit plusieurs alternatives sans lancer de tests peut dépenser plus et apporter moins de preuves. Examinez l'usage à côté des fichiers, des tentatives et des contrôles réussis.

Si une tâche grossit, redécoupez-la ou réduisez son périmètre. Choisir un autre modèle doit aussi répondre à un test, comme l'explique le guide de GPT-5.6. Le budget ne remplace pas la qualité, mais il rend visible le coût de la coordination.

Les échecs apparaissent dans les contrats partagés

Le premier risque est que les deux sessions modifient navigation, messages ou styles globaux. Isolez ces décisions ou exécutez-les l'une après l'autre. Résoudre des dizaines de conflits à la fin détruit l'avantage du parallélisme.

Un autre risque est de prendre le résumé du dépôt pour une source complète. Il peut orienter, mais ne remplace ni les règles locales, ni les tests, ni le code critique. Confirmez chaque hypothèse avant d'éditer.

Le navigateur agent fonctionne aussi avec des permissions. Caméra, localisation, microphone ou sessions authentifiées exigent des limites explicites. Pour ces deux tâches publiques, n'accordez pas de capacités qui ne participent pas au parcours.

Vérifiez le travail parallèle avant de l'intégrer

Utilisez ces cases pour les deux sessions. Chacune doit livrer sa propre preuve avant d'entrer dans l'état commun.

• Les tâches ne changent pas le même contrat et ne dépendent pas l'une de l'autre.
• Chaque session a branche, fichiers, permissions et critères d'acceptation propres.
• La carte a été testée par composant, clavier, mobile et lien réel.
• La 404 a été testée par langue, HTTP, clavier et navigation de sortie.
• Budget, condition d'arrêt et consommation sont consignés.
• La suite et les deux parcours sont rejoués après l'intégration.

Copilot offre plus de capacité pour diviser, naviguer et avancer. Le bénéfice apparaît quand chaque session conserve une frontière et une preuve. Divisez, isolez, vérifiez et intégrez dans cet ordre.