Guide d'étude GH-600 : préparer l'examen de développeur IA agentique de GitHub

Le profil de public de Microsoft pour cet examen décrit une personne experte dans l'exploitation, l'intégration, la supervision et l'encadrement d'agents IA au sein de workflows SDLC de niveau production, avec GitHub comme système de référence et plan de contrôle. Les responsabilités de cette personne, telles que le guide d'étude les formule, comprennent l'exploitation de workflows d'agents dans le SDLC, la supervision du comportement autonome avec les contrôles propres à GitHub, l'évaluation et le réglage des productions des agents à partir d'analyses et d'artefacts, la configuration d'agents personnalisés et la coordination sûre de l'exécution multi-agents. Elle travaille aux côtés d'architectes, d'ingénieurs plateforme, d'ingénieurs DevOps, de développeurs d'applications, de product managers et d'ingénieurs sécurité.

Côté expérience, le guide d'étude attend une bonne connaissance du cycle de développement logiciel, des workflows et contrôles GitHub, de la qualité du code, de la sécurité et des pratiques de revue, ainsi qu'une pratique concrète des agents de code, dont GitHub Copilot, les serveurs MCP et la personnalisation d'agents : instructions personnalisées, agents personnalisés, outils et étapes de configuration de Copilot. Côté logistique : l'examen est surveillé, planifié via Pearson VUE, dure deux heures, coûte US$165 (le prix varie selon le pays ou la région), est proposé en anglais et demande un score pondéré de 700 ou plus pour être réussi. Un échec peut être repassé 24 heures plus tard ; les pages de Microsoft ne publient ni nombre de questions ni taux de réussite, et ce guide n'en invente donc pas.

Chaque fait de cette page a été vérifié sur deux pages consultées directement lors de la rédaction : le « Study guide for Exam GH-600: Developing in Agentic AI Systems » de Microsoft Learn et sa page « GitHub Certified: Agentic AI Developer », toutes deux sur learn.microsoft.com, lues le 26 octobre 2026. Si l'une de ces pages modifie une pondération, un prix ou un domaine, cette page doit changer aussi ; rien ici ne provient d'un site d'examens blancs tiers ni d'un message de forum.

Ce domaine porte sur la place d'un agent dans votre processus de développement, pas seulement sur le fait qu'il fonctionne. Le guide d'étude de Microsoft le découpe en trois volets : intégrer les agents au SDLC (identifier les étapes qu'un agent doit réaliser, repérer les anti-patterns courants et définir dès le départ entrées, sorties et critères de réussite) ; séparer la planification de l'exécution (configurer un agent pour qu'il produise un plan structuré, valider ce plan et empêcher l'agent d'agir tant que le plan n'est pas vérifié et approuvé) ; et configurer l'observabilité et le contrôle (régler le bon degré d'autonomie, produire des artefacts inspectables dans vos outils habituels et prévoir une intervention humaine sans ralentir la livraison à l'extrême).

L'exercice de la semaine : choisissez une vraie tâche que vous confieriez à un agent de code. Avant de le laisser toucher quoi que ce soit, faites-lui écrire le plan en premier, en texte simple : les fichiers qu'il va modifier, l'ordre des étapes et à quoi ressemble « terminé ». Lisez ce plan et approuvez-le ou rejetez-le avant la moindre modification. C'est exactement la frontière que teste ce domaine : un plan produit par l'agent, et un humain (ou une règle) qui le vérifie avant le début de l'exécution.

Ce domaine porte sur ce qu'un agent retient et pendant combien de temps. Il couvre le choix entre mémoire court terme, long terme et externe, et le cadrage de la mémoire à ce qui est pertinent pour la tâche, avec des règles pour son expiration, son élagage ou sa réinitialisation ; la persistance de l'état et la gestion de la dérive de contexte, c'est-à-dire consigner avancement et décisions dans des artefacts durables pour qu'un agent puisse reprendre le travail sans répéter des étapes ni contredire des décisions antérieures, et repérer la dérive pendant une longue exécution ; et la cohérence de la mémoire et de l'état entre outils et environnements, pour que les agents partagent l'état sans conflit ni contexte périmé.

L'exercice de la semaine : avant de commencer une tâche en plusieurs étapes avec un agent, créez un court fichier d'état (du texte simple suffit) qui note l'objectif, les décisions prises jusque-là et ce qu'il reste à faire. Mettez-le à jour après chaque étape plutôt que de vous fier à la mémoire de la conversation côté agent. Fermez la session, rouvrez-la quelques jours plus tard et voyez si ce seul fichier suffit pour reprendre exactement là où vous en étiez.

Ce domaine couvre l'exécution de plusieurs agents à la fois sans qu'ils se gênent. Le guide d'étude de Microsoft le regroupe en : exploitation de workflows multi-agents (appliquer un modèle d'orchestration, isoler les agents pour l'exécution en parallèle, détecter et résoudre les conflits comme des modifications de code qui se chevauchent ou des productions contradictoires) ; configuration de l'observabilité entre agents (produire des artefacts propres à la revue et à l'audit, documenter les passations et les décisions) ; détection et traitement des défaillances multi-agents (repérer les exécutions bloquées ou dégradées et appliquer des schémas de reprise, dont le retour arrière et l'humain dans la boucle) ; et gestion du cycle de vie des agents dans un workflow sans le perturber.

L'exercice de la semaine : donnez à deux agents de code le même dépôt, chacun dans sa propre branche, avec une modification qui se chevauche (même fichier, modifications différentes). Laissez-les finir tous les deux, puis résolvez vous-même le conflit de fusion et écrivez une phrase sur le chevauchement que vous éviteriez la prochaine fois, en cantonnant un agent à un autre fichier ou en séquençant les deux tâches au lieu de les lancer en parallèle.