Favoriser l’adoption par l’équipe de GitHub Copilot agentique

Une fois que les développeurs utilisent Copilot, un déploiement ciblé peut aider les équipes établies à ajouter GitHub Copilot app et Copilot CLI à leur travail quotidien. Ces outils complètent le chat de l’IDE et le mode agent. L’objectif est d’aider les équipes à créer des workflows agentiques reproductibles avec l’outil qui convient le mieux à chaque tâche.

Ce guide s’adresse aux personnes qui coordonnent l’adoption de Copilot pour les équipes en place. Il vous guide tout au long d’un sprint d’intégration de deux semaines pour tester l’ajustement du flux de travail et établir des habitudes d’utilisation. Un sprint de deux semaines fournit un signal précoce d’adoption, pas assez de preuves pour prouver l’impact sur la productivité à long terme ou les coûts.

Avant le sprint

Identifiez un coordinateur de déploiement et les personnes responsables des stratégies, des licences, des métriques, de la sécurité, du support et des dépenses. Convenez de qui peut suspendre le sprint ou désactiver l’accès si vous constatez un problème inattendu lié aux règles, à la sécurité ou aux coûts.

Sélectionner et équiper une équipe initiale

Commencez par une équipe ou un petit groupe d’équipes établies. Les participants sont plus susceptibles d’apprendre les uns des autres, et vous pouvez distinguer les pratiques d’équipe des préférences individuelles.

Choisissez les équipes qui ont :

Un manager ou chef d’équipe qui montrera l’exemple dans l’utilisation et en discutera lors des réunions d’équipe
Un ou plusieurs contributeurs expérimentés qui peuvent tester des flux de travail avancés, prendre en charge des pairs et transformer des expériences réussies en conseils d’équipe
Travail se prêtant aux outils agentiques, comme l’analyse d’une base de code, la réalisation de modifications coordonnées dans plusieurs fichiers, l’exécution de tests ou la préparation de pull requests
Métriques de remise stables que vous pouvez utiliser comme base de référence

Évitez de sélectionner uniquement les passionnés. Incluez un mélange représentatif de niveaux d’expérience afin que le sprint révèle les barrières courantes d’installation, de confiance et de flux de travail.

Sélectionnez un projet réel avec suffisamment de travail adapté pour que les participants utilisent des outils agentiques plusieurs fois pendant le sprint. Préparez ensuite l’accès :

Vérifiez que chaque participant reçoit sa Copilot licence par l’intermédiaire de l’organisation dont les stratégies régissent le sprint.
Collaborez avec les propriétaires d’entreprise et d’organisation appropriés pour activer les stratégies distinctes pour GitHub Copilot app et Copilot CLI.
Vérifiez l’étendue avant d’activer une stratégie. Les stratégies d’organisation s’appliquent à tous ceux qui reçoivent leur licence par le biais de cette organisation, et non seulement à l’équipe sélectionnée. Les stratégies d’entreprise peuvent également restreindre les paramètres que les propriétaires de l’organisation peuvent modifier. Pour plus d’informations, consultez « stratégies de GitHub Copilot pour les entreprises et les organisations ».
Demandez aux participants d’installer et de se connecter aux deux outils avant le lancement. Consultez Prise en main de l’application GitHub Copilot et Configuration de l’interface CLI GitHub Copilot.
Vérifiez que chaque participant peut accéder au projet et utiliser les outils sous les stratégies et paramètres gérés prévus.
Accordez à la personne qui mesure le sprint l’accès aux métriques d’utilisation Copilot. Pour le rôle requis, consultez Métriques d’utilisation de GitHub Copilot.

Si vous activez ces outils pour la première fois, traitez le sprint dans le cadre d’un pilote de fonctionnalités plus large. Avant le lancement, estimez les coûts basés sur l’utilisation, définissez un budget approprié avec le comportement d’arrêt prévu et prévoyez de surveiller les dépenses pendant le sprint. Pour un processus complet, consultez Pilotez une nouvelle fonctionnalité ou modèle de Copilot dans votre entreprise.

Définir des cibles d’activation et de résultat

Définissez une cible d’activation pour le sprint d’intégration. Par exemple, définissez une cible pour chaque participant à utiliser Copilot app ou Copilot CLI sur au moins trois jours distincts chaque semaine du sprint. L’utilisation répétée donne aux participants le temps d’essayer les outils sur différentes tâches et de décider où ils s’intègrent dans le travail quotidien.

Associez la cible d’activation avec un ou deux résultats qui comptent pour l’équipe. Par exemple:

Réduisez le temps entre le début du travail et l’ouverture d’une pull request.
Effectuez davantage de tâches de maintenance sans retarder le travail de fonctionnalité planifié.
Réduisez le temps consacré à l’examen du code inconnu.
Maintenez ou améliorez la qualité de la révision tout en augmentant le débit des demandes de tirage.

Enregistrez une base de référence pour les résultats avant le sprint.

N’utilisez pas la quantité de code généré comme cible de réussite. Le code généré ne crée pas nécessairement plus de valeur et peut augmenter le travail de révision ou de maintenance.

Préparer les flux de travail, le suivi et les protections

Au lieu de demander aux participants d'« utiliser davantage l’IA », donnez à l’équipe deux ou trois flux de travail approuvés qui correspondent à leur travail actuel. Par exemple:

Utilisez Copilot CLI pour analyser un échec, planifier une modification portant sur plusieurs fichiers, exécuter des tests ou passer en revue les modifications locales.
Utilisez Copilot app pour travailler à partir d’un ticket, apporter des modifications dans une session d’agent et ouvrir une pull request.
Passez d’un outil à l’autre si nécessaire, par exemple en ouvrant Copilot app depuis copilot app avec Copilot CLI.

Pour chaque flux de travail, documentez les étapes d’évaluation, de test et d’approbation requises. Si votre entreprise utilise des instructions personnalisées, des agents, des paramètres managés ou des serveurs MCP (Model Context Protocol) approuvés, configurez-les avant le sprint.

Déterminez comment l’équipe partagera des exemples et effectuera le suivi de la progression. Vous pouvez:

Ajoutez un libellé temporaire de pull request, tel que copilot-pilot, afin que les participants puissent trouver et discuter d’exemples pertinents.
Ajoutez un marqueur cohérent aux messages de validation pertinents, tels que Copilot-Assisted: true, si votre organisation analyse déjà les métadonnées de validation.
Préparez un tableau de bord d’équipe qui montre la part des participants actifs sur l’un ou l’autre des outils sur trois ou plusieurs jours par semaine.
Choisissez une réunion ou un canal d’équipe existant dans lequel les participants peuvent partager la tâche, le flux de travail et le résultat sans partager les invites susceptibles de contenir des informations sensibles.

Les étiquettes et les marqueurs de message de validation fournissent un contexte autodéclaré, et non des données d’utilisation faisant autorité. Utilisez-les pour rechercher des exemples et démarrer des conversations. Utilisez Copilot les métriques d’utilisation pour mesurer l’activité.

Avant le lancement, documentez :

Qui examinera l’accès, le comportement de stratégie, l’activité de l’agent, les problèmes de support et les dépenses pendant le sprint
Comment les participants signalent un comportement inattendu ou non sécurisé
Conditions qui interrompent ou arrêtent le sprint, comme une étendue de stratégie inattendue, des résultats dangereux répétés ou des dépenses approchent de la limite acceptée
Comment le propriétaire responsable désactive les outils ou supprime la configuration spécifique à sprint

Pendant le sprint

Dans la première semaine, supprimez les obstacles de configuration et créez des expériences partagées. Au cours de la deuxième semaine, renforcez les flux de travail réussis et résolvez les obstacles.

Semaine 1 : Lancer et terminer les premiers flux de travail

Lancer avec toute l’équipe. Expliquer les résultats que vous souhaitez améliorer, la cible d’activation et les garde-fous que les participants doivent respecter.
Démontrer un travail réel. Demandez au responsable, responsable d’équipe ou contributeur expérimenté d’effectuer l’un des flux de travail sélectionnés dans le codebase de l’équipe. Indiquez où l’examen humain et l’approbation restent requis.
Effectuez une première tâche ensemble. Constituez des binômes afin que tout le monde commence une session dans Copilot app ou Copilot CLI et effectue une petite tâche à faible risque.
Utilisez les outils pendant le travail normal. Demandez aux participants d’utiliser au moins un workflow sélectionné pendant au moins le nombre de jours défini dans votre objectif d’activation. Évitez de créer des exercices artificiels après la première tâche.
Vérifiez les opérations. Vérifiez que les stratégies et les paramètres managés se comportent comme prévu. Passez en revue les rapports de support et de sécurité et vérifiez les dépenses basées sur l’utilisation par rapport à la limite acceptée.

Semaine 2 : Renforcer les flux de travail utiles

Discutez de l’utilisation dans les réunions existantes. Demandez ce que les outils ont aidés, lorsque les participants ont choisi un autre Copilot outil ou fonctionnalité, et ce qui les a bloqués.
Répondez aux obstacles de flux de travail. Utilisez les actions suivantes :
- Un autre outil convient mieux à la tâche : conservez le flux de travail existant pour cette tâche et concentrez le sprint sur le travail qui tire parti des outils sélectionnés.
- Le participant ne savait pas comment démarrer : fournissez une invite de démarrage testée pour l’un des flux de travail sélectionnés.
- L’agent n’a pas de contexte ou produit des résultats médiocres : améliorez les instructions du référentiel, les descriptions des tâches ou les outils disponibles, puis testez à nouveau le flux de travail.
- Le participant n’a pas approuvé le résultat : montrer comment passer en revue les différences, restreindre les autorisations, exécuter des tests et ignorer les modifications indésirables.
- L’outil n’était pas disponible ou bloqué : vérifiez l’attribution de licence, les stratégies, l’installation, l’authentification, l’accès réseau et la configuration des outils approuvés.
Ajustez les instructions de flux de travail. Supprimez les flux de travail qui n’ont pas aidé, résolu les problèmes d’accès ou de configuration, et partagez les pratiques des sessions réussies.
Vérifiez à nouveau les opérations. Passez en revue les rapports de sécurité, l’activité de l’agent, le comportement de la stratégie, les besoins de support et les dépenses. Suspendez le sprint s’il répond à l’une de vos conditions d’arrêt.
Passez en revue les résultats préliminaires. À la fin de la semaine 2, comparez les signaux d’activation et de résultat à la base de référence.

Ne découragez pas l’utilisation normale de l’IDE. L’objectif est d’aider l’équipe à choisir un outil agentique lorsqu’il réduit les efforts ou étend ce qu’il peut accomplir.

Après le sprint

Mesurez les résultats, documentez ce que vous avez appris et décidez de répéter, développer, reconcevoir, suspendre ou arrêter le déploiement.

Mesurer l’utilisation soutenue

Utilisez des rapports quotidiens pour chaque utilisateur à partir de l’API Copilot de métriques d’utilisation :

used_cli et used_copilot_app indiquer si une personne a utilisé chaque outil le jour donné.
totals_by_cli et totals_by_copilot_app fournissent le nombre de sessions, de requêtes et de prompts pour une analyse plus approfondie.

Pour vérifier la cible d’activation :

Filtrez les lignes quotidiennes sur les dates du sprint.
Conservez les lignes où used_cli ou used_copilot_app est true.
Regroupez les lignes par utilisateur et par semaine.
Compter les valeurs distinctes day dans chaque groupe.

Un participant atteint un objectif de trois jours lorsque le décompte est d’au moins trois dans chaque semaine.

Pour afficher ces champs par équipe, rejoignez le rapport des équipes utilisateur avec le rapport d’utilisation par utilisateur. Consultez « Métriques d’utilisation Copilot au niveau de l’équipe ».

Utilisez le tableau de bord d’impact comme vue directionnelle et à long terme de l’adoption globale de l’agent. Les cohortes d’adoption utilisent une fenêtre glissante de 28 jours et peuvent refléter l’activité issue de fonctionnalités agentiques au-delà des deux outils inclus dans ce sprint. N’utilisez pas de changement de cohorte pour attribuer l’impact à ce sprint. Consultez « Affichage du tableau de bord d’impact Copilot ».

Mesurer les résultats de l’équipe

Comparez la période de sprint avec votre base de référence, à l’aide de mesures telles que :

Demandes de fusion fusionnées par développeur
Délai médian avant fusion des pull requests
Taux d’achèvement du travail de maintenance ou de backlog
Défauts, remaniements ou résultats de révision
Confiance et satisfaction des participants à partir d’une courte enquête

Passez en revue les résultats quantitatifs en même temps que les commentaires de l’équipe. Les différences dans la complexité du projet, la dotation et le type de travail peuvent affecter les métriques de remise, donc n’attribuent pas chaque modification à Copilot.

Décider comment passer à l’échelle

Résumer :

Pourcentage de participants ayant atteint la cible d’activation
Flux de travail que les participants ont répétés sans y être invités
La configuration, la gouvernance ou les barrières de confiance les plus courantes
Modifications apportées aux résultats de l’équipe sélectionnée
Coûts basés sur l’utilisation et tout travail opérationnel requis pour prendre en charge le déploiement
Tous les problèmes de sécurité et la façon dont vous les avez résolus

Développez vers une autre équipe établie lorsque l’équipe initiale illustre des flux de travail reproductibles et une qualité, une sécurité, des besoins de support et des coûts acceptables. Si l’activation est faible, identifiez et résolvez les obstacles spécifiques de cette équipe, tels que les problèmes de configuration ou les flux de travail inappropriés. Ne modifiez pas le déploiement des équipes qui ont déjà adopté les outils.

Si vous avez activé les outils spécifiquement pour ce sprint, n’utilisez pas deux semaines de données comme preuve d’impact sur les coûts à long terme. Poursuivez le pilote plus large jusqu’à ce que vous ayez suffisamment de données de cycle de facturation pour prendre une décision d’expansion défendable.

À mesure que vous développez, conservez les mêmes définitions d’activation et de résultat afin de pouvoir comparer les groupes de déploiement. Revisitez les cibles après avoir suffisamment de preuves internes pour définir une utilisation soutenue et précieuse pour votre entreprise.