Pourquoi cette mise à jour est importante pour les ingénieurs seniors
GitHub a mis en avant-première publique l’utilisation sur ordinateur de GitHub Copilot CLI et de l’application GitHub Copilot sur macOS et Windows. Concrètement, Copilot peut désormais lire certaines parties des applications de bureau locales, inspecter le contexte visuel, cliquer sur des commandes, saisir du texte, appuyer sur des touches, faire défiler, glisser et naviguer dans des workflows qui étaient auparavant invisibles pour l’automatisation classique des développeurs. Cela peut sembler être une simple fonctionnalité de plus, jusqu’à ce que l’on réfléchisse aux lacunes quotidiennes d’un workflow d’ingénierie : un outil d’administration interne sans API, une console fournisseur qui n’expose qu’une interface web ou de bureau, un utilitaire Windows hérité qui exporte des données de test, une liste de contrôle de mise en production cachée dans une interface graphique, ou encore une présentation nécessitant une mise à jour de dernière minute après la modification d’un résultat de build.
Pour un développeur expérimenté, l’intérêt ne réside pas dans le fait que « l’IA puisse cliquer sur des boutons ». Ce qui est intéressant, c’est que la frontière entre l’automatisation du code et celle des workflows opérationnels est en train de bouger. Nous avons passé des années à tout encapsuler dans des scripts, des interfaces en ligne de commande (CLI), des API, des GitHub Actions, Terraform, des cibles Make et des serveurs MCP. Cela reste la bonne approche par défaut. Les interfaces structurées sont reproductibles, observables, vérifiables et généralement plus sûres. Mais les véritables organisations d’ingénierie ont toujours un « reste » désordonné : des outils achetés plutôt que développés en interne, des portails de conformité qui ne peuvent pas être automatisés par script, des tableaux de bord nécessitant une inspection visuelle, et des processus de gestion des incidents ou de mise en production qui recoupent plusieurs applications. L’utilisation de l’ordinateur vise précisément ce « reste ».
La leçon relative à l’intervention humaine est essentielle. Il ne s’agit pas d’une fonctionnalité à laisser libre cours sur les systèmes de production. La documentation de GitHub elle-même souligne que l’utilisation de l’ordinateur est désactivée par défaut, nécessite une activation explicite, suit les paramètres d’autorisation des outils, peut être bloquée par la politique d’entreprise et peut être interrompue. C’est là le bon modèle mental : l’agent peut devenir un opérateur compétent, mais l’ingénieur reste le maître de l’intention, des contraintes, de la validation et de la vérification finale. Bien utilisée, l’utilisation de l’ordinateur peut soulager un ingénieur senior des tâches fastidieuses de coordination. Utilisée sans précaution, elle peut automatiser des erreurs dans les mêmes applications où une erreur humaine serait coûteuse.
En quoi consiste cet outil
L’utilisation de l’ordinateur est une fonctionnalité de Copilot permettant d’interagir avec des applications graphiques locales. Au lieu de s’appuyer uniquement sur les fichiers du référentiel, les outils de terminal, les outils de navigateur, les API GitHub ou les intégrations MCP, Copilot peut utiliser des informations d’accessibilité et des captures d’écran lorsque le contexte visuel est nécessaire. Il peut sélectionner des contrôles, saisir du texte, modifier, naviguer et déplacer des informations d’une application à l’autre. GitHub le positionne pour des flux de travail dans des logiciels de bureau ou exclusivement basés sur une interface graphique (GUI) qui ne fournissent pas d’API, d’interface en ligne de commande ou d’intégration MCP.
Cette distinction est importante. Si une tâche peut être effectuée via une API déterministe, une commande de terminal, une migration de base de données, un test d’automatisation de navigateur ou un petit script, les ingénieurs seniors devraient privilégier la voie déterministe. L’utilisation de l’ordinateur constitue une solution de secours pour les aspects récalcitrants du travail où l’écran est la seule interface. Elle permet à l’agent d’apporter son aide sans attendre qu’une équipe de plateforme développe une intégration dont le coût pourrait ne jamais se justifier.
Cette fonctionnalité est actuellement disponible dans les sessions locales sous macOS et Windows via Copilot CLI et l’application Copilot. Dans l’interface CLI, elle est contrôlée à l’aide de commandes « / ». Vous pouvez vérifier l’état à l’aide de /computer show, l’activer avec /computer on, et la désactiver avec /computer off. Sous macOS, la configuration guide l’utilisateur à travers les autorisations d’accessibilité et d’enregistrement d’écran, car l’agent a besoin d’un accès au niveau du système d’exploitation pour inspecter les fenêtres et interagir avec elles. L’application Copilot propose le même concept via ses paramètres.
Copilot demande également une autorisation avant de contrôler une application, en fonction du mode d’autorisation de l’interface sur laquelle la session s’exécute. Un utilisateur peut autoriser l’accès pour la session en cours, autoriser systématiquement une application spécifique ou refuser la demande. GitHub précise que les autorisations enregistrées sont locales et partagées entre la CLI Copilot et l’application Copilot sur la même machine. Les règles de refus ont la priorité, et les paramètres gérés par l’organisation peuvent désactiver complètement cette fonctionnalité. Ces contrôles ne sont pas superflus. Ils font la différence entre un assistant de flux de travail utile et un enregistreur de macros incontrôlé doté d’une confiance dans le modèle linguistique.
Comment l’installer ou y accéder
Le chemin d’accès commence par la CLI GitHub Copilot ou l’application GitHub Copilot. Pour la CLI, la documentation de configuration de GitHub répertorie plusieurs options d’installation. Sur les systèmes équipés de Node.js 22 ou d’une version ultérieure, la commande npm est la suivante :
npm install -g @github/copilot
Sous macOS ou Linux, Homebrew est également pris en charge :
brew install --cask copilot-cli
GitHub fournit également un script d’installation pour macOS et Linux :
curl -fsSL https://gh.io/copilot-install | bash
Les utilisateurs de Windows peuvent procéder à l’installation via WinGet, et les exécutables sont disponibles sur la page des versions de Copilot CLI. Après l’installation, les premières utilisations déclenchent des invites d’authentification ; GitHub prend également en charge l’authentification par jeton pour les environnements nécessitant un contrôle accru. Si Copilot est fourni par une organisation, celle-ci ou l’entreprise doit autoriser l’utilisation de la CLI Copilot. Ce point est important pour les responsables techniques : le déploiement n’est pas seulement une préférence des développeurs, c’est une décision stratégique.
Une fois la CLI disponible, démarrez une session interactive et vérifiez si l’utilisation sur l’ordinateur est autorisée :
/computer show
Activez-la ensuite explicitement :
/computer on
Si l’organisation a désactivé la fonctionnalité, la CLI devrait signaler qu’elle est bloquée par des paramètres gérés. Si la fonctionnalité est activée mais ne fonctionne pas, GitHub recommande de vérifier le plugin « Utilisation de l’ordinateur » fourni et son serveur MCP à l’aide des vues « Plugins » et « MCP ». Sous macOS, vérifiez que l’assistant dispose à la fois des autorisations « Accessibilité » et « Enregistrement d’écran ». Pour interrompre une opération depuis la CLI, appuyez Esc deux fois.
Sa place dans le flux de travail d’un développeur senior
Les cas d’utilisation les plus productifs ne sont pas les plus prestigieux. Ce sont les tâches fastidieuses, récurrentes et impliquant plusieurs applications qui détournent l’attention de la conception et de la révision. Un ingénieur senior peut déjà utiliser des agents pour rédiger du code, modifier des tests, générer des plans de migration, résumer des pull requests et explorer des dépôts. L’utilisation de l’ordinateur étend cette assistance jusqu’à la dernière étape du travail local : ouvrir une interface graphique, consulter un panneau d’état, copier un résultat dans un rapport, mettre à jour une liste de contrôle ou transférer des données d’une application à une autre sous supervision.
Un cas d’utilisation concret concerne les outils de mise en production hérités. De nombreuses entreprises disposent encore d’applications internes de déploiement ou de packaging antérieures aux API modernes. L’ingénieur de mise en production peut avoir besoin d’ouvrir un outil, de sélectionner une branche, de vérifier un numéro de build, d’exporter un manifeste ou de comparer les paramètres entre différents environnements. Grâce à l’utilisation de l’ordinateur, l’ingénieur peut décrire le résultat souhaité et les contraintes : ouvrir l’outil, lire les métadonnées de la version candidate actuelle, ne rien soumettre ni modifier, et résumer l’état visible. L’agent peut effectuer la navigation tandis que l’ingénieur vérifie le résultat avant toute action irréversible.
Un deuxième cas d’utilisation concerne la vérification des produits exclusivement basés sur une interface graphique. Supposons qu’une équipe gère une application de bureau, mais que la plupart des tests automatisés couvrent les services et les bibliothèques. Un développeur corrigeant un bug peut demander à l’agent d’ouvrir l’application, d’accéder à un écran spécifique, de collecter les libellés visibles et de les comparer au comportement attendu décrit dans le ticket. Cela ne remplace pas une véritable suite de tests automatisés de l’interface utilisateur. Cela peut toutefois accélérer la vérification exploratoire et faciliter la saisie des observations pendant que le développeur est encore en phase de codage.
Un troisième cas d’utilisation concerne la documentation et la communication relative aux versions. Les ingénieurs seniors perdent souvent du temps à changer de contexte pour mettre à jour une diapositive, une feuille de calcul ou un wiki interne après un changement technique. Si la source de vérité est une commande de terminal ou une pull request GitHub, l’utilisation de scripts peut s’avérer plus efficace. Mais si la destination est un éditeur de documents exclusivement graphique ou une application d’entreprise verrouillée, l’utilisation d’un ordinateur peut faciliter le transfert des informations finales pendant que l’ingénieur vérifie l’exactitude du libellé et des chiffres.
Un quatrième cas d’utilisation concerne la gestion des incidents. Lors d’un incident, les ingénieurs peuvent avoir besoin de consulter simultanément des tableaux de bord, des systèmes de tickets, des clients VPN de bureau, des fenêtres de chat et des consoles de fournisseurs. C’est également là que la prudence est de mise. Une bonne instruction pourrait demander à Copilot de résumer l’état visible d’une application de surveillance sans modifier les filtres, accuser réception des alertes ni envoyer de messages. L’avantage est une prise de conscience plus rapide de la situation. La mesure de sécurité consiste à indiquer explicitement une intention en lecture seule et à prévoir une vérification humaine avant toute action.
Un cinquième cas d’utilisation concerne l’intégration à des logiciels opérationnels peu familiers. Les nouveaux cadres supérieurs recrutés possèdent souvent de solides compétences techniques, mais sont ralentis par les outils spécifiques à l’entreprise. Un agent à qui l’on peut demander d’inspecter une fenêtre, de résumer l’état actuel et d’expliquer quels champs semblent pertinents peut raccourcir la courbe d’apprentissage. L’humain doit tout de même apprendre à maîtriser le système ; l’agent réduit simplement les difficultés rencontrées lors des premières utilisations.
Modèles d’invite permettant à l’ingénieur de garder le contrôle
L'utilisation de l'ordinateur fonctionne mieux lorsque l'instruction est précise sur le plan opérationnel. Les développeurs seniors devraient rédiger leurs instructions comme ils rédigent des guides d'exécution sécurisés : objectif, périmètre, contraintes, condition d'arrêt et vérification. Au lieu de « mettre à jour l’outil », utilisez « ouvrir le tableau de bord des versions, lire la version candidate actuelle et l’état du déploiement, ne pas appuyer sur les boutons Soumettre, Approuver, Supprimer, Déployer ou Enregistrer, et s’arrêter après avoir généré un résumé ». La différence n’est pas d’ordre stylistique ; elle modifie le profil de risque.
Parmi les contraintes utiles, on peut citer : nommer les applications concernées, préciser si la tâche est en lecture seule, énumérer les actions interdites, spécifier d’où et vers où les données peuvent être copiées, et exiger un point de contrôle avant toute étape modifiant l’état du système. Si une tâche concerne l’environnement de production, les données clients, les finances, l’identité, les documents juridiques ou les communications externes, le mode par défaut doit être « révision uniquement ». Si l’agent doit modifier l’état, demandez-lui de s’arrêter et sollicitez une autorisation immédiatement avant la modification.
Il est également judicieux de séparer l’observation de l’exécution. Demandez d’abord à l’agent d’inspecter et de résumer la situation. Demandez-lui ensuite de proposer un plan étape par étape. Ce n’est qu’alors que vous approuverez une action ciblée. Cette approche reflète la manière dont les ingénieurs expérimentés examinent les migrations de bases de données ou les plans de déploiement : rassembler les faits, élaborer un plan, vérifier l’ampleur des répercussions, exécuter l’étape minimale nécessaire et observer le résultat.
Limites et risques
L’utilisation d’un ordinateur hérite de toute la fragilité des interfaces graphiques. Les boutons se déplacent. Des boîtes de dialogue modales apparaissent. Le focus de la fenêtre change. Les applications se comportent différemment après les mises à jour. Les arborescences d’accessibilité peuvent omettre des informations importantes. Les captures d’écran peuvent prêter à confusion. Des problèmes de synchronisation peuvent entraîner des clics répétés ou des saisies manquées. Des contrôles non standard peuvent perturber l’automatisation. Un appel d’API déterministe aboutit ou échoue de manière structurée ; une interaction sur le bureau peut échouer en effectuant une action erronée dans une fenêtre d’apparence plausible.
Le risque de sécurité est également bien réel. Un bureau peut contenir des informations sensibles provenant d’applications sans rapport avec la tâche en cours. Si un agent peut voir l’écran, il risque de recevoir un contexte qui n’était absolument pas prévu pour la tâche. Si un agent peut contrôler une application autorisée, une invite inappropriée ou un contenu inattendu pourrait entraîner des modifications indésirables. L’option « Toujours autoriser » est pratique, mais doit être réservée aux applications à faible risque. Pour tout ce qui concerne des informations confidentielles, des identifiants, des paiements, des données clients, des consoles de production ou des panneaux d’administration privilégiés, une autorisation valable uniquement pour la session est plus sûre.
Il existe également une lacune en matière d’auditabilité. Les modifications de code laissent des traces. Les commandes CLI peuvent être journalisées. Les appels API peuvent être tracés. Les interactions via l’interface graphique peuvent être moins visibles, à moins que l’outil ne capture une transcription utile. Les équipes adoptant l’utilisation d’ordinateurs doivent décider comment elles documentent ce qui s’est passé. Une règle simple suffit : chaque session d’utilisation informatique significative doit se terminer par un résumé des applications utilisées, des actions effectuées, des données modifiées et des vérifications réalisées. Si le résultat a une incidence sur une version, un incident ou le workflow d’un client, conservez ce résumé avec le ticket ou la pull request.
Gains de productivité à espérer
Le gain de productivité réaliste réside dans la réduction des changements de contexte, et non dans une autonomie miraculeuse. Les ingénieurs seniors passent un temps surprenant à faire le lien entre les systèmes : du code au ticket, de l’intégration continue (CI) à la note de version, du tableau de bord au canal d’incident, de l’application locale aux preuves de test, de la console d’entreprise au commentaire de pull request. L’utilisation de l’ordinateur peut réduire ces transferts de tâches. Même un gain de cinq ou dix minutes par workflow répétitif compte lorsque la tâche est effectuée quotidiennement par toute une équipe.
Cette fonctionnalité peut également rendre les flux de travail des agents plus complets. Un agent chargé du codage peut déjà modifier du code et exécuter des tests, mais une tâche réelle se termine souvent en dehors du référentiel : vérifier le comportement dans une application, contrôler un tableau de bord, mettre à jour un enregistrement, préparer un artefact lisible par l’humain ou collecter des preuves. L’utilisation de l’informatique permet à ce même assistant de franchir cette dernière étape, tout en conservant l’intervention humaine pour la révision et la validation.
Les équipes qui en tireront le plus grand bénéfice seront celles qui associeront l’utilisation de l’ordinateur à une discipline d’ingénierie. Privilégiez les API et les scripts. Utilisez des serveurs MCP lorsqu’une intégration structurée existe. Réservez l’utilisation de l’informatique aux flux de travail qui, sans cela, seraient manuels. Définissez les politiques d’autorisation de manière centralisée. Apprenez aux développeurs à définir des contraintes explicites. Exigez des contrôles humains avant tout changement d’état. Enregistrez des résumés. Considérez cette fonctionnalité comme un opérateur supervisé, et non comme un collègue autonome.
Conclusion
L’utilisation de GitHub Copilot arrive à point nommé, car les outils de développement basés sur l’IA dépassent désormais la simple génération de code pour offrir une assistance de bout en bout aux flux de travail. C’est utile, mais cela place la barre plus haut en matière de jugement technique. Les meilleurs développeurs chevronnés ne céderont pas le contrôle aveuglément. Ils utiliseront cette fonctionnalité pour éliminer les tâches mécaniques de faible valeur, explorer plus rapidement les interfaces héritées et relier la boucle de codage aux outils opérationnels, tout en veillant à ce que l’intention, les autorisations, la vérification et la responsabilité restent fermement entre les mains de l’humain.
