VS Code 1.144 prolonge la session de développement au-delà de la fermeture du portable

Vous commencez une tâche de développement à votre bureau, la consultez depuis un autre appareil et revenez plus tard examiner les différences. L’expérience utile est celle d’un seul travail qui se poursuit, avec les mêmes instructions et des décisions visibles. Reconstituer une conversation après chaque changement d’appareil constitue une autre forme de travail de développement.

VS Code 1.144 est devenu une version stable le 28 octobre 2026. Ses notes de version rapprochent continuité des sessions d’agents et gestion à distance, avec des fonctionnalités portant individuellement les mentions Preview ou Experimental. Les sessions cloud s’exécutent sur l’infrastructure GitHub : leur travail peut donc continuer lorsque le portable de développement est hors ligne. Notes de version officielles.

Ce guide explique la différence entre un client et le lieu où le travail s’exécute, l’apport d’Agent Host Protocol et la manière d’évaluer une session continue à travers une véritable transmission pour revue de code.

Capture officielle de Remote Environments dans Visual Studio Code 1.144. Used with permission from Microsoft. Source de l’image · Licence et précisions sur l’image.

Fermer une fenêtre et arrêter un processus de travail sont deux événements différents

Une interface de développement affiche messages, fichiers et demandes d’approbation. Le processus qui réalise la tâche peut se trouver ailleurs. Une fois ces rôles séparés, fermer l’interface ne signifie plus nécessairement abandonner la tâche, à condition que l’hôte et son environnement restent disponibles.

La présentation Universe de Microsoft du 28 octobre décrit l’Agent Host comme un processus indépendant gérant sessions, environnements de pilotage, modèles, fichiers et terminaux. Elle indique qu’Agent Host Protocol a atteint la version 1.0 et relie les clients à l’état persistant des sessions. Cette distinction architecturale aide à évaluer ce que signifie réellement « continuer à travailler ».

Un hôte local dépend toujours de la machine locale. Un hôte distant dépend de sa machine distante et de ses modalités de connexion. Une session cloud possède un environnement hébergé séparément. Choisissez le lieu d’exécution en fonction de ce qui doit rester disponible lorsque le client disparaît.

Imaginez le client comme une fenêtre donnant sur une salle de contrôle. Une autre fenêtre peut montrer le même travail sans déplacer les machines sous-jacentes. Un téléphone qui affiche une session ne transforme pas un ordinateur local en veille en serveur toujours allumé.

Notre avis : la persistance devient utile lorsque l’identité de la tâche survit avec son exécution. La session qui se poursuit doit indiquer clairement quel dépôt elle utilise, quelles modifications elle a produites et quelle décision elle attend. Maintenir seulement un processus en vie est un résultat plus limité.

Explication originale de la répartition des responsabilités entre client et hôte, éclairée par la présentation VS Code Universe. Il s’agit d’un modèle simplifié de préparation, pas d’une topologie réseau.

AHP synchronise la session observée par les interfaces

Le site officiel d’Agent Host Protocol, consulté le 2 novembre, décrit AHP comme un protocole d’affichage bidirectionnel fondé sur l’état. Les clients travaillent sur un état de session partagé ; l’hôte diffuse les actions et arbitre les conflits. À la reconnexion, les actions manquées ou un instantané actuel peuvent être transmis pour remettre une interface à jour.

Cela compte, car une session d’agent contient davantage qu’une transcription de conversation. Elle peut inclure une action en attente d’approbation, un terminal actif ou un fichier modifié. Si deux interfaces affichent des versions incohérentes de ces faits, la personne qui pilote la session peut prendre une mauvaise décision même si la génération de code est bonne.

Les exemples de reconnexion du protocole montrent la réconciliation des actions clientes en attente avec l’état de l’hôte. L’implication pratique est simple : la reconnexion doit retrouver la situation actuelle du travail, y compris le sort d’une demande antérieure. Elle ne doit pas obliger à deviner si une approbation est arrivée avant la coupure réseau.

Un protocole commun établit aussi une frontière pour l’interopérabilité des clients. Un client doit comprendre l’état de session et les actions qu’il affiche. L’existence d’un protocole ne signifie pas que tous les outils peuvent déjà se connecter à tous les fournisseurs ou présenter chaque fonction de façon identique.

Pour comparer des interfaces en équipe, examinez les décisions importantes dans votre processus. Le client alternatif affiche-t-il une demande d’autorisation en attente ? Identifie-t-il les fichiers modifiés et l’état actuel de la tâche ? Le retour dans l’éditeur conserve-t-il le même travail plutôt que de lancer une deuxième conversation ?

Version stable et capacité en aperçu sont deux étiquettes distinctes

La page de VS Code 1.144 identifie la version comme Stable, tandis que Cloud Automations, la génération d’images et les connecteurs Copilot restent en Preview ; l’utilisation de l’ordinateur et les fonctions de working set portent la mention Experimental. L’expérience des sessions cloud nécessite une offre Copilot payante et reste soumise à la politique de l’organisation. État de la version et des fonctionnalités, 28 octobre, consulté le 2 novembre.

Cette combinaison est courante dans un éditeur extensible : une application stable peut contenir des fonctionnalités de maturités différentes. La bonne décision d’adoption concerne la fonction et le processus, pas seulement le numéro de version.

Ce tableau compare les conditions opérationnelles, sans promettre un comportement identique entre environnements. Les exigences d’une extension, d’un modèle et d’un environnement de pilotage donnés restent importantes. Testez la combinaison que votre équipe compte utiliser.

Pour une capacité expérimentale, choisissez un exercice distinct et réversible. Pour évaluer la continuité de base, commencez par le plus petit processus qui démontre la transmission. Combiner plusieurs nouvelles fonctions rend plus difficile l’identification de celle qui a produit un résultat inattendu.

Trois tâches illustratives montrent où la continuité aide

Un développeur peut déléguer une correction délimitée et l’examiner plus tard

Imaginons un développeur demandant à une session cloud de corriger un test d’analyseur en échec dans un dépôt. L’instruction précise l’échec, le comportement concerné et la vérification attendue. Le développeur consulte ensuite l’avancement depuis un autre client pris en charge avant de revenir dans l’éditeur pour la revue.

Le critère d’acceptation doit rester celui de toute modification : la correction traite le comportement, les vérifications pertinentes réussissent et les différences sont appropriées. Pouvoir continuer alors que le portable est fermé est utile parce que cela change le moment où le travail peut avancer. Cela ne prouve pas que le résultat peut être fusionné.

Pour la transmission, demandez à la session de conserver la commande exacte du test et son résultat. « Les tests ont réussi » est plus difficile à évaluer qu’une vérification nommée liée à une révision précise. Le responsable de la revue a besoin de suffisamment de preuves pour comprendre le résultat sans reconstituer toute la conversation.

Si la tâche est bloquée par une approbation ou un service manquant, la session doit rendre cet état visible. Un travail qui reste actif mais ne peut pas progresser diffère d’un travail qui avance utilement. Cette visibilité aide le développeur à décider s’il doit intervenir, modifier le périmètre ou laisser la tâche en attente.

Un responsable de maintenance peut enquêter sur plusieurs problèmes sans mélanger les fichiers

À titre d’illustration, un responsable pourrait demander à une session de reproduire un bogue pendant qu’une autre examine la documentation. Cela peut bien employer le temps d’attente si les tâches sont clairement délimitées. Il faut aussi conserver chaque résultat avec son espace de travail et son contexte de revue.

Définissez les responsabilités avant de commencer. Précisez les fichiers ou le sous-système, la branche ou l’espace de travail et le résultat attendu de chaque session. Si deux tâches doivent toucher au même contrat, décidez comment rapprocher leurs conclusions avant d’appliquer les deux modifications.

Examinez un résultat par rapport à un état connu du dépôt. Sinon, un test réussi peut dépendre de modifications non relues issues d’une autre session. La séparation des espaces de travail aide à établir l’origine d’un résultat positif.

Le bénéfice est une file de revue plus claire, pas simplement davantage d’agents simultanés. Deux enquêtes bien délimitées peuvent réduire l’incertitude ; plusieurs modifications qui se chevauchent peuvent l’accroître. L’interface Agents est utile lorsqu’elle aide le responsable à voir laquelle de ces situations se développe.

Une équipe peut tester une tâche cloud récurrente avant de se fier au calendrier

Pour un pilote illustratif d’automatisation, prenons une revue périodique des liens documentaires nécessitant une intervention. Commencez par un rapport en lecture seule et un résultat précis. Faites examiner le résultat par une personne avant d’élargir la tâche à la création de modifications.

Le statut Preview de Cloud Automations compte ici, car un travail récurrent ajoute une responsabilité opérationnelle. Une tâche qui se comporte correctement une fois peut encore nécessiter des limites de fréquence, un responsable et une réponse claire aux échecs avant d’être planifiée. Testez ces exigences indépendamment de la qualité de sa production linguistique.

L’équipe doit savoir où chaque exécution consigne la révision du dépôt, ses constatations et ses requêtes externes. Si elle ne peut pas finir, le compte rendu doit indiquer ce qui reste non résolu. Une tâche récurrente devient utile lorsque son responsable distingue une situation inchangée d’une vérification échouée.

Commencez avec un dépôt et un périmètre modeste. Élargissez uniquement après avoir observé des exécutions ordinaires, une exécution volontairement bloquée et une revue du document produit. Ce sont des étapes de pilote proposées, pas des affirmations d’essais pratiques de cette version.

Le travail non commité exige une transmission explicite

Les notes de version 1.144 précisent que les sessions cloud utilisent un espace distinct et ne copient pas automatiquement les modifications locales non commitées. Depuis Chat ou Agents, l’utilisateur peut sélectionner Cloud, choisir un dépôt GitHub, poursuivre les échanges, répondre aux approbations et examiner les modifications ; les sessions existantes peuvent être rouvertes depuis la liste. Instructions des sessions cloud.

Cet espace séparé est important pour qui travaille dans une copie locale très active. Un fichier local peut être essentiel à la tâche tout en étant absent de l’état du dépôt visible par la session cloud. Avant de transmettre, identifiez la révision source prévue et la manière autorisée de fournir les éléments supplémentaires.

Ne confondez pas un changement d’interface et un transfert de fichiers. Poursuivre la même conversation ne prouve pas que tous les fichiers locaux ou services actifs ont été déplacés. Une session peut conserver son intention tout en ayant besoin d’un accès explicite aux éléments nécessaires pour l’exécuter.

Pour un signalement de bogue illustratif, incluez l’entrée en échec sous une forme approuvée et reproductible. Précisez si l’agent doit utiliser des jeux de test commités ou de nouveaux éléments fournis. La session dispose ainsi d’un point de départ concret et évite une longue enquête sur un état du dépôt qui n’a jamais contenu le problème.

La revue finale doit vérifier la même frontière dans l’autre sens. Déterminez où se trouvent les modifications proposées et comment elles entreront dans la branche de travail. Préservez les modifications locales actives pendant l’examen et l’application du résultat. Le bénéfice d’un espace distant ne doit pas se payer par une incertitude sur le travail local.

Parcours d’acceptation original pour une tâche de développement continue. Il combine la frontière documentée de l’espace cloud avec une revue d’ingénierie habituelle ; il ne rapporte aucun résultat d’essai indépendant.

Une visite de dix minutes prouve moins qu’une tâche menée à terme

Il est facile d’évaluer les éléments visibles de la continuité : une session apparaît dans une liste, un client se reconnecte, un message arrive. Ces vérifications sont utiles, mais le but du développeur est un travail terminé dont l’état survit à la transmission.

Choisissez une petite tâche pouvant aboutir à un résultat inspectable. Un jeu de test, une correction documentaire ou une correction de comportement isolée conviennent si le dépôt possède une vérification évidente. La tâche doit être assez significative pour exposer l’état de l’espace et les autorisations, sans rendre le premier essai inutilement large.

1. Mettez à jour et vérifiez la version installée. Utilisez la recherche de mises à jour de VS Code et confirmez la version. Examinez les mentions propres à chaque fonctionnalité dans les notes officielles.
2. Choisissez un environnement d’exécution autorisé. Confirmez l’accès au dépôt, l’éligibilité de l’offre et la politique de l’organisation. Décidez si la tâche relève d’un hôte local, distant ou cloud.
3. Consignez l’état de départ. Notez le dépôt et la révision. Préservez les modifications locales et identifiez les entrées nécessaires à l’espace choisi.
4. Donnez une instruction délimitée. Précisez le comportement attendu, le périmètre et la commande de vérification. Définissez le résultat que vous comptez examiner.
5. Exercez la transmission. Quittez le client et reconnectez-vous par une interface disponible et prise en charge. Vérifiez l’état de la même session, ses approbations en attente et son nouveau travail.
6. Revenez au code. Examinez les différences et les preuves de vérification. Confirmez que les contrôles s’appliquent à la révision relue.
7. Consignez le résultat et les limites restantes. Distinguez reconnexion réussie, tâche terminée et modification acceptée. Ce sont des étapes liées, mais étayées par des preuves différentes.

Si l’essai échoue, diagnostiquez la frontière en cause. Un jeu de test absent appelle une réparation de l’espace de travail ; un appel d’outil bloqué appelle une décision d’autorisation ; un hôte indisponible appelle une décision sur l’environnement d’exécution. Répéter la même consigne résout rarement un problème extérieur à la consigne.

Gardez ce premier résultat précis. « Cette tâche s’est poursuivie dans cet environnement et a produit ces modifications relues » est une conclusion opérationnelle utile. Elle indique à un collègue ce qui est reproductible et quelles conditions comptent.

Une session persistante doit rendre les responsabilités plus faciles à suivre

VS Code 1.144 place davantage du processus des agents dans un espace qui perdure : l’endroit où les instructions deviennent des actions et les actions des modifications vérifiables. AHP ouvre une voie d’état partagé pour les clients, tandis que le lieu d’exécution détermine ce qui peut continuer après la déconnexion d’un appareil.

L’amélioration significative est un travail que l’on peut quitter, retrouver et encore comprendre. Lorsque la session préserve son état source, ses décisions et ses vérifications, fermer le portable devient un détail d’organisation plutôt que la limite du travail.

Sources

• Notes de version de Visual Studio Code 1.144, version Stable du 28 octobre 2026 ; consultées le 2 novembre 2026.
• VS Code Wrapped : GitHub Universe 2026, 28 octobre 2026.
• Microsoft Agent Host Protocol, spécification v1.0.0 et présentation de l’état partagé, consultées le 2 novembre 2026.

Conserver les éléments qui fondent une décision

Telli.sh est une option pour conserver des sources dont l’utilisation est autorisée aux côtés des notes que vous avez révisées. Créer un espace de notes.