Ce tutoriel vous guide tout au long de l’exécution d’un pilote de bout en bout : définition d’un budget, activation de la fonctionnalité pour un groupe autonome, surveillance des résultats et utilisation des preuves pour prendre et signaler une décision d’aller ou de no-go.
Avant de commencer votre projet pilote
Avant d’activer quoi que ce soit, vérifiez que vous avez évalué la fonctionnalité ou le modèle et confirmé qu’il répond à vos exigences de conformité. Consultez « Préparation des nouvelles fonctionnalités et modèles ».
Si vous ne savez pas si une fonctionnalité ou un modèle est sûr à activer, vérifiez avec les équipes de sécurité et de conformité de votre entreprise avant de commencer le pilote.
Définir à quoi ressemble la réussite
Définissez ce qui constitue un « go » avant de commencer, afin d’évaluer le projet pilote par rapport à un plan plutôt qu’a posteriori. Notez quelques critères concrets de réussite qui couvrent l’adoption (par exemple, une part minimale des utilisateurs actifs), le coût (rester dans le plafond que vous définissez) et les commentaires qualitatifs (par exemple, la plupart des participants recommanderaient la fonctionnalité). Vous allez vérifier les résultats réels du pilote par rapport à ces critères dans Prendre une décision de poursuite ou d’abandon.
Planifiez également la durée de la phase pilote. Les budgets et la réserve partagée de AI credits sont réinitialisés à chaque cycle de facturation ; prévoyez donc que le pilote s’étende sur au moins un cycle de facturation complet, généralement de quatre à six semaines, car une période plus courte peut vous laisser avec trop peu de données sur les coûts et l’adoption pour tirer une conclusion fiable.
Choisir qui inclure dans votre groupe pilote
Étant donné que les fonctionnalités et les modèles sont activés au niveau de l’organisation, tout le monde qui reçoit sa Copilot licence par le biais de cette organisation aura accès, pas seulement un sous-ensemble sélectionné à la main, et pas nécessairement tout le monde qui est membre de celui-ci. Au lieu de sélectionner des personnes, recherchez une organisation dont la population sous licence reflète déjà les critères ci-dessous :
- Les développeurs effectuant des travaux réels et significatifs. Les participants à la phase pilote doivent utiliser la fonctionnalité avec les langages, les frameworks et les référentiels qui comptent pour votre organisation, et non sur des projets sans importance. Les signaux d’utilisation et de coût ne sont fiables que s’ils proviennent d’un travail authentique.
- Mélange de compétences et de niveaux d’ancienneté. Incluez à la fois des ingénieurs expérimentés et des personnes plus récentes dans votre codebase ou à Copilot. Différents niveaux d’expérience utilisent la fonctionnalité différemment et découvrent différentes valeurs et différents problèmes.
- Une gamme d’équipes et de flux de travail. Une fonctionnalité qui aide le flux de travail d’une équipe peut ne pas aider les autres. Le fait d’impliquer quelques équipes vous donne une vue d’ensemble plus fiable des domaines où la fonctionnalité apporte de la valeur et de ceux où elle n’en apporte pas.
- Les gens prêts à donner des commentaires. Une grande partie de la valeur d’un pilote provient de commentaires qualitatifs, pas seulement des métriques. Choisissez des participants qui s’impliqueront, indiqueront ce qui fonctionne et ce qui ne fonctionne pas, et répondront lorsque vous leur demanderez leur avis.
Si aucune de vos organisations ne convient, par exemple, si la combinaison appropriée de personnes est dispersée dans plusieurs organisations ou si vos organisations sont trop volumineuses pour servir de pilote autonome, vous pouvez créer une organisation dédiée et y ajouter uniquement vos utilisateurs choisis. Cela vous donne un contrôle précis sur les personnes incluses, mais cela signifie migrer ou dupliquer l’accès au référentiel pour ces utilisateurs, et cela peut ne pas fonctionner correctement pour les fonctionnalités telles Agent cloud Copilot que celles qui dépendent du contexte au niveau du référentiel profond. Ce tutoriel suppose que vous utilisez une organisation existante ; si vous optez pour une organisation dédiée, considérez sa configuration et l’ajout de membres comme une étape supplémentaire avant d’activer la fonctionnalité pour votre groupe pilote.
Estimer les coûts et définir un plafond budgétaire
La plupart des fonctionnalités et modèles que vous souhaitez piloter sont facturés par le biais de l’utilisation. Par conséquent, les dépenses ne sont pas fixes par le nombre de licences que vous attribuez.
Une poignée de développeurs actifs utilisant un modèle de pointe ou une fonctionnalité basée sur un agent pourraient consommer davantage que vous ne l’imaginez. Calculez une estimation approximative de ce que le pilote pourrait coûter et décidez d’un plafond que vous êtes prêt à dépenser avant d’activer la fonctionnalité.
Commencez par comprendre comment la fonctionnalité ou le modèle est facturé. Les fonctionnalités basées sur l’utilisation consomment GitHub AI Creditset le coût de chaque interaction dépend du modèle et du nombre de jetons consommés. Pour comprendre quelles fonctionnalités comptent pour l’utilisation, comment les crédits inclus sont regroupés dans votre entreprise et comment les dépassements sont facturés, consultez Facturation basée sur l’utilisation pour les organisations et les entreprises.
Pour produire une estimation, combinez trois nombres :
- Nombre de personnes dans votre groupe pilote, que vous avez défini dans la section précédente.
- Combien vous vous attendez à ce qu’ils utilisent la fonctionnalité. Vous ne le saurez pas tant que les gens ne l’utiliseront pas, alors choisissez une estimation délibérément haut de gamme plutôt que d’essayer de la prédire précisément. Si vous avez déjà déployé une fonctionnalité ou un modèle comparable, utilisez son utilisation réelle comme point de référence. Si ce n’est pas le cas, supposons une utilisation fréquente et intensive par développeur, car les fonctionnalités agentiques et les modèles frontière coûtent plus cher par interaction qu’une question de conversation rapide. Un petit groupe qui utilise intensivement la fonctionnalité peut coûter plus cher qu’un grand groupe qui l’utilise occasionnellement.
- L’allocation incluse que vous pouvez utiliser. Chaque licence attribuée est fournie avec une quantité mensuelle d’éléments inclus AI credits qui sont regroupés au niveau de l’entreprise, de sorte que certaines des utilisations du pilote peuvent être couvertes avant que tout dépassement ne soit facturé.
Utilisez-les pour définir un plafond : le maximum que vous êtes prêt à dépenser sur le pilote avant de vouloir suspendre et réévaluer. Choisissez un montant qui laisse au projet pilote une marge suffisante pour générer des données d’utilisation pertinentes, tout en limitant votre exposition si la consommation est plus élevée que prévu. Si vous ajustez la taille de votre groupe pilote ultérieurement, réexévez cette estimation.
Par exemple, supposons que vous pilotez une fonctionnalité agentique avec 20 développeurs sur Copilot Business. Chaque licence inclut 1,900AI credits par mois, de sorte que votre groupe pilote tire parti d’un pool partagé de 20 × 1,900 inclus AI credits avant le début des frais mesurés. Si vous attendez une utilisation intensive d’environ 3 000 AI credits par développeur ce mois-ci, estimez l’utilisation totale de 20 × 3 000. Soustrayez le forfait inclus pour estimer l’utilisation facturée au compteur, puis multipliez par $0.01 USD pour estimer le coût du dépassement et définissez votre plafond légèrement au-dessus de cette estimation. Vous allez créer le budget qui applique ce plafond après avoir activé la fonctionnalité, dans Définir un budget pour limiter les coûts du pilote.
Activer la fonctionnalité pour votre groupe pilote
Maintenant que vous avez estimé les coûts et que vous avez choisi qui inclure, vous pouvez activer la fonctionnalité de manière autonome. L’objectif est de donner à votre groupe pilote une expérience réelle et correctement régie tout en conservant le reste de votre entreprise non affectée.
Vous allez effectuer cette opération en quatre étapes :
- Confirmez l’appartenance à l’organisation et l’attribution de licence.
- Configurez les stratégies qui régissent la fonctionnalité.
- Activez la fonctionnalité pour cette organisation uniquement.
- Définir un budget pour limiter les coûts du pilote.
Confirmer l’appartenance à l’organisation et l’attribution de licence
Le simple fait d’être membre ne suffit pas : la plupart des Copilot stratégies s’appliquent selon l’organisation qui attribue la licence Copilot d’un utilisateur, et non pas simplement selon les organisations auxquelles l’utilisateur appartient. Si une personne appartient à plusieurs organisations, vérifiez que sa licence est attribuée par l’intermédiaire de l’organisation pilote spécifiquement. S’il est attribué par le biais d’un autre, les stratégies de l’organisation pilote ne régissent pas leur accès, et l’activation des fonctionnalités dans ce didacticiel ne s’applique pas à eux.
Si l’un de vos utilisateurs pilotes ne sont pas encore membres, ou s’ils sont membres, mais reçoivent leur licence ailleurs, ajoutez-les à l’organisation pilote et attribuez-lui leur Copilot licence avant de continuer.
Configurer des stratégies avant d’activer la fonctionnalité
Copilot les stratégies contrôlent les fonctionnalités et les modèles auxquels vos utilisateurs peuvent accéder et comment leurs données sont gérées. Configurez ces stratégies pour l’organisation pilote avant d’activer la fonctionnalité, afin que les utilisateurs pilotes obtiennent une expérience régie correctement à partir de leur première interaction plutôt que d’une brève fenêtre où la fonctionnalité est disponible sans les garde-fous que vous envisagez.
Déterminez les fonctionnalités et les modèles que le pilote doit autoriser et définir les stratégies au niveau de l’organisation afin que la modification affecte uniquement votre organisation pilote ; les stratégies définies au niveau de l’entreprise s’appliquent à chaque organisation de votre entreprise. Si votre stratégie d’entreprise n’autorise pas les organisations à définir leur propre valeur, un propriétaire d’entreprise doit le modifier avant de pouvoir continuer. Pour comprendre comment les stratégies se cascadent de l’entreprise aux organisations et qui peuvent remplacer les paramètres à chaque niveau, consultez stratégies de GitHub Copilot pour les entreprises et les organisations.
Activer la fonctionnalité pour une seule organisation
En tant que propriétaire de l’organisation, activez la fonctionnalité ou le modèle spécifique pour l’organisation pilote uniquement, à partir des paramètres de stratégie de Copilot l’organisation. Pour connaître les étapes complètes, consultez Gestion des stratégies et des fonctionnalités pour GitHub Copilot dans votre organisation. Vérifiez que le paramètre s’applique à l’organisation pilote et non à l’entreprise dans son ensemble avant de l’enregistrer.
Définir un budget pour limiter les coûts du pilote
Auparavant, vous avez décidé d’un plafond de dépenses pour le pilote. Vous allez maintenant créer le budget qui l’applique.
Tout d’abord, comprenez ce que fait un budget d’organisation. Il limite les frais mesurés uniquement et devient actif uniquement après l’épuisement du AI credits pool partagé. Il ne limite pas les dépenses totales, donc définissez la limite sur le montant de dépassement que vous êtes prêt à payer au-delà de l’allocation incluse, et non au coût total du pilote. Critiquement, un budget n’est pas un arrêt difficile par défaut : les frais continuent d’accumuler au-delà de la limite, sauf si vous activez l’option Arrêter l’utilisation lorsque la limite budgétaire est atteinte lorsque vous la créez.
En tant que propriétaire ou responsable de facturation de l’organisation, créez un budget limité à l’organisation pilote, définissez sa limite sur le plafond de dépassement que vous avez choisi et activez l’arrêt de l’utilisation lorsque la limite budgétaire est atteinte.
Si vous souhaitez empêcher qu’un seul utilisateur pilote ne fasse grimper la consommation, définissez également un budget global par utilisateur. Il s’agit du seul contrôle qui constitue toujours un blocage strict, et il comptabilise la consommation d’un utilisateur provenant à la fois du pool partagé et de l’utilisation mesurée dans la même limite. Définissez-le à un niveau modeste qui permet aux participants d’effectuer un véritable travail, tout en empêchant un seul utilisateur d’accaparer une part disproportionnée du budget du pilote.
Pour savoir comment les budgets mesurent et bloquent l’utilisation à l’utilisateur, à l’organisation et aux niveaux d’entreprise, consultez Budgets de facturation basée sur l’utilisation.
Surveiller le pilote
Tout au long du pilote, suivez l’adoption, collectez les commentaires des développeurs et observez les coûts et l’activité agentique par rapport aux critères de réussite que vous avez définis au début. Ensemble, ces signaux vous aident à décider s’il faut développer la fonctionnalité.
Suivez l’adoption et l’utilisation à l’aide de Copilot métriques
Utilisez Copilot les métriques d’utilisation pour voir le nombre d’utilisateurs pilotes actifs, la fréquence à laquelle ils utilisent la fonctionnalité et la tendance de ces chiffres au cours de la période pilote. L’adoption qui est stable ou augmente est un signal fort ; l’utilisation qui pointe, puis disparaît peut signifier que la fonctionnalité n’est pas adaptée aux flux de travail réels des développeurs.
- Pour comprendre ce que couvrent les métriques et comment les interpréter, consultez Métriques d’utilisation GitHub Copilot.
- Pour afficher le tableau de bord de votre organisation ou de votre entreprise, consultez Affichage du tableau de bord des métriques d’utilisation Copilot.
Collecter les commentaires des développeurs à partir de votre groupe pilote
Les métriques vous indiquent si les utilisateurs utilisent la fonctionnalité, mais pas pourquoi ou comment cela fonctionne bien pour eux. Rassemblez des commentaires qualitatifs pour combler cet écart. Exécutez des enquêtes courtes, maintenez des archivages réguliers ou configurez un canal dédié où les utilisateurs pilotes peuvent signaler ce qui fonctionne et ce qui n’est pas le cas.
C’est là que les participants que vous avez choisis pour leur volonté à faire des retours portent leurs fruits. Posez des questions précises : dans quels cas la fonctionnalité a permis de gagner du temps, dans quels cas elle a produit de mauvais résultats, et si elle a changé leur façon de travailler. Ces commentaires présentent souvent des problèmes et des opportunités que les chiffres seuls ne révèlent pas, et vous donnent des exemples concrets à partager avec le leadership plus tard.
Surveiller les coûts et l’activité agentique dans les budgets et le journal d’audit
Gardez un œil sur les dépenses par rapport au budget que vous avez créé tout au long du pilote, pas seulement à la fin. Si l’utilisation approche de votre plafond plus tôt que prévu, c’est une preuve précoce utile de ce qu’un déploiement plus large coûterait. Pour connaître les étapes permettant de surveiller ce que vous avez dépensé par rapport au budget, consultez Suivi de votre utilisation de GitHub AI Credits. Pour le suivi des dépenses au fil du temps, consultez Gestion des dépenses de votre entreprise sur GitHub Copilote.
En plus des coûts, vérifiez si la fonctionnalité est utilisée en toute sécurité. C’est la troisième question que le leadership posera, et le pilote a la chance de le répondre avec des preuves plutôt que des assurances. Pour les fonctionnalités agentiques, passez en revue les sessions d’agent pour comprendre ce que fait la fonctionnalité en fait au nom de vos développeurs et pour intercepter tout comportement inattendu ou indésirable ; le journal d’audit enregistre lorsque la fonctionnalité est activée ou désactivée, mais ne capture pas ce niveau de détail. Vérifiez que les politiques et les budgets que vous définissez se comportent comme prévu, et notez tout ce qui aurait besoin de garde-fous plus serrés à grande échelle. Consultez « Surveillance de l’activité agentique dans votre entreprise ».
Prendre une décision de poursuite ou non
À la fin du pilote, vérifiez vos résultats par rapport aux critères de réussite que vous avez définis à l’avant et décidez si vous souhaitez développer la fonctionnalité, stocker et collecter plus de données ou le restaurer. Prenez la décision délibérément et documentez la preuve derrière elle.
Confirmer que vous avez suffisamment de preuves pour décider
Avant de décider, vérifiez que le projet pilote a été mené pendant la durée prévue et a produit suffisamment de données pour étayer une conclusion solide.
L’utilisation du pilote puise d’abord dans le pool partagé (sans coût supplémentaire) avant le début de la facturation à l’usage ; il est donc normal qu’aucune dépense (0 $) ne soit enregistrée au début du pilote, et une durée d’exécution plus courte peut rendre les données sur les coûts trompeuses.
Vous êtes prêt à prendre une décision lorsque :
- Des métriques d’adoption qui montrent une tendance stable plutôt qu’un pic initial isolé.
- Données de coût réelles, couvrant au moins un cycle de facturation, que vous pouvez comparer à votre estimation.
- Commentaires d’un éventail représentatif de vos utilisateurs pilotes.
Si l’un de ces éléments est insuffisant, par exemple si l’utilisation continue d’augmenter ou si seuls quelques participants ont pris part au projet, envisagez de prolonger le projet pilote plutôt que de prendre une décision sur la base d’éléments incomplets. Une décision que vous pouvez étayer par des données est bien plus facile à défendre auprès de la direction et bien moins susceptible de devoir être remise en cause.
Signaler à la direction
Pour justifier votre décision et établir un cas pour un déploiement plus large, signalez les résultats du pilote au leadership.
Identifier les données à partager
Rassemblez les signaux que vous avez rassemblés pendant le pilote :
- Métriques d’adoption, montrant le nombre d’utilisateurs pilotes actifs et la tendance de l’utilisation au fil du temps.
- Coût réel par rapport au budget, comparant ce que le pilote a dépensé au plafond que vous avez défini et à votre estimation initiale.
- Thèmes de commentaires, résumé où les participants ont trouvé de la valeur et où ils ont rencontré des problèmes.
- Observations sur la sécurité et la gouvernance, y compris tout ce que vous avez appris dans le journal d’audit ou dans la façon dont les stratégies et les budgets se comportent.
Évaluez l’adoption, le coût et la sécurité au regard du retour sur investissement
Présentez les données en termes métier plutôt que comme des chiffres bruts. Connectez l’adoption et les commentaires à la valeur fournie par la fonctionnalité, comme le temps économisé, le travail débloqué ou la qualité améliorée, et pesez cela par rapport à son coût réel et à toutes les considérations de gouvernance ou de risque que vous avez observées.
Fermez avec une recommandation claire : développer, maintenir ou arrêter, et ce qu’il coûterait de déployer plus largement. Présenter le projet pilote sous l’angle du retour sur investissement, de coûts prévisibles et d’un risque maîtrisé donne à la direction les éléments nécessaires pour approuver un déploiement plus large en toute confiance.
Agir sur votre décision
Prenez l’étape suivante en fonction des preuves que vous avez recueillies et de la décision que vous avez prise.
Développer le déploiement dans votre entreprise
Si les éléments le justifient, élargissez le déploiement par étapes plutôt que d’un seul coup. Étendez la stratégie de fonctionnalité à davantage d’organisations, puis uniquement au reste de votre entreprise une fois que chaque étape semble saine. Lorsque vous ajoutez d’autres utilisateurs, augmentez ou ajoutez des budgets afin que vos contrôles de dépense soient mis à l’échelle avec la population la plus grande et continuez à surveiller l’adoption et le coût à chaque étape.
Pour obtenir des conseils plus larges sur la gestion d’un déploiement dans votre entreprise, consultez Déploiement GitHub Copilot à grande échelle.
Restaurer et désactiver la fonctionnalité correctement
Si les éléments recueillis indiquent qu’il ne faut pas poursuivre, désactivez proprement la fonctionnalité afin d’éviter tout coût résiduel ou toute confusion. Désactivez la stratégie de fonctionnalité ou de modèle pour l’organisation pilote et indiquez à vos participants que le pilote s’est terminé et pourquoi, alors ils ne se demandent pas pourquoi la fonctionnalité a disparu.
Vérifiez qu’il n’existe aucune utilisation restante qui pourrait continuer à facturer votre budget et à examiner ou supprimer le budget pilote afin qu’il n’affecte pas les rapports futurs. Conservez les données et les commentaires que vous avez collectés : même un no-go est un résultat utile pour partager avec le leadership, et il peut informer une nouvelle évaluation ultérieure lorsque la fonctionnalité mûrit.