Au cours des mois qui ont suivi, nous avons appliqué des techniques de développement agentique à un nombre croissant de projets clients et internes. Le projet X, un projet récent où cette évolution est encore en cours, offre un angle d’analyse utile sur ce que nous avons appris de manière plus générale. La leçon la plus importante n’était pas simplement que les agents pouvaient écrire du code plus rapidement. Elle résidait dans le fait que nos plateformes de développement et nos pratiques de livraison existantes n’étaient pas conçues pour les encadrer tout au long du cycle de vie du développement.
Dans le cadre du projet X, les implémentations générées par les agents ont franchi les contrôles de qualité traditionnels tout en s’écartant de l’architecture, de l’intention de l’exigence ou de l’exigence métier sous-jacente. Le code était bien formé, mais ce n’était pas toujours le bon code. À mesure que les agents vont au-delà de la saisie semi-automatique et commencent à planifier le travail, à modifier le code et à ouvrir des pull requests, les contrôles conçus pour les équipes de développement humaines ne suffisent plus automatiquement.
Cet écart — entre le fait de passer tous les contrôles et celui de construire réellement ce qu’il faut — s’est avéré être le véritable enjeu de ces neuf derniers mois. Le combler nous a amenés à nous poser une question bien plus vaste concernant la plateforme que ce à quoi nous nous attendions, et c’est celle que nous aborderons lors de notre webinaire du mois d’août.
Nous avions également prédit que la génération de code deviendrait de plus en plus compressible, tandis que la compréhension du problème et l’élaboration de la bonne solution ne le seraient pas. Les développeurs passeraient moins de temps à produire une première ébauche et davantage à réviser le travail généré par l’IA. Nous avions avancé que les développeurs juniors auraient encore besoin de l’expérience acquise en écrivant et en révisant eux-mêmes le code — cette mémoire musculaire qui permet de reconnaître une mauvaise implémentation au premier coup d’œil — et que la programmation en binôme devrait évoluer vers une révision en binôme. Les workflows axés sur le texte et privilégiant les spécifications nécessiteraient également des boucles de rétroaction plus serrées afin de préserver la compréhension commune traditionnellement construite par la conversation.
Telles étaient nos prévisions en octobre. Au fil des missions menées depuis lors, tant pour nos clients qu’en interne, elles sont progressivement devenues des réalités opérationnelles.
Comment cela s’est concrétisé dans le cadre du Projet X
Le projet X n’a pas débuté comme une expérience visant à déterminer la quantité de travail que nous pouvions confier à des agents. Il a démarré comme tout projet produit bien mené, avec des exigences détaillées, un plan de MVP qui y était lié et un rythme hebdomadaire de traitement des éléments du backlog classés par ordre de priorité.
Ce qui a changé, c’est la manière dont l’équipe a fait passer chaque élément de l’exigence à la mise en œuvre. Un développeur a travaillé avec l’IA pour rédiger l’histoire et le plan de mise en œuvre, en s’appuyant à la fois sur les exigences du projet, son architecture et ses attentes en matière de conception. Nous avons ensuite utilisé des contrôles distincts basés sur des agents pour vérifier le scénario et le plan afin de détecter d’éventuelles lacunes avant même que le code ne soit écrit. Une fois le travail suffisamment défini, un agent d’exécution utilisant Devin ou GitHub Copilot pouvait le mettre en œuvre.
C’était là le « travail compressible » dont nous avions parlé en octobre : traduire un plan bien défini en code. Mais comme nous l’avons constaté sur le Projet X et dans d’autres travaux de développement par agents, la rapidité de production du code a mis en évidence un autre problème. Plus les agents implémentaient rapidement, plus il devenait important de vérifier s’ils avaient bien implémenté ce qu’il fallait.
La dérive que les contrôles de qualité traditionnels ne pouvaient pas détecter
Nos contrôles de qualité existants faisaient exactement ce pour quoi ils avaient été conçus. Les vérifications de style, le linting, la vérification des types et les tests automatisés pouvaient nous indiquer si le code était bien formé et si les comportements connus fonctionnaient toujours. Ils ne pouvaient toutefois pas déterminer si une implémentation reflétait l’intention de l’exigence, répondait à l’exigence sous-jacente ou restait cohérente avec l’architecture.
En conséquence, certaines implémentations générées par des agents passaient tous les contrôles automatisés traditionnels tout en nécessitant encore des corrections importantes. Le problème ne résidait pas nécessairement dans la qualité du code. Il s’agissait d’un problème d’alignement.
Dans un cas précis, un agent a créé des tests front-end en simulant l’intégralité d’un module de données partagé au lieu d’utiliser l’infrastructure de simulation de requêtes établie par le projet. Les tests ont réussi, mais cette approche risquait de permettre à des simulations incomplètes d’atteindre des API réelles et rendait la suite de tests fragile à mesure que la couche de données évoluait. Un linter ou un vérificateur de types n’aurait pas signalé cette implémentation, car le code était valide et les tests réussis. Une revue tenant compte de l’architecture aurait pu reconnaître qu’elle contournait le modèle de test prévu par le projet.
Cela a mis en évidence une nouvelle responsabilité de la plateforme. Nous avions besoin de contrôles capables d’évaluer la pull request par rapport au ticket associé, aux critères d’acceptation, aux exigences du projet et à l’architecture. En d’autres termes, nous devions vérifier si l’agent avait construit la bonne chose, et pas seulement s’il l’avait construite correctement.
Combler cette lacune est devenu l’objectif principal de nos investissements en outils au cours des mois suivants.
Comment la plateforme a évolué autour des agents
L’historique des outils du projet X montre une progression claire. Chaque étape a ajouté des capacités aux agents et mis en évidence une nouvelle lacune en matière de confiance.
Avril 2026 : mise en place d’un contexte partagé.
Nous avons introduit des règles partagées, des compétences réutilisables, des commandes de base, ainsi que l’infrastructure d’intégration continue (CI) et de synchronisation des tickets, afin que les agents disposent dès le départ des mêmes connaissances sur le projet qu’un développeur humain.
Mai 2026 : amélioration de la qualité des spécifications.
Les agents ont contribué à la rédaction des stories, des éléments de dette technique, des plans de mise en œuvre et des mises à jour de la documentation. Nous avons ajouté des contrôles indépendants chargés de vérifier ces artefacts avant leur mise en œuvre.
Juin 2026 : Standardisation des comportements et ajout d’une révision indépendante.
Nous avons regroupé les mêmes compétences dans tous les environnements de développement et introduit des contrôles de qualité basés sur l’IA dans l’intégration continue (CI). Ceux-ci comprenaient des revues d’architecture, des vérifications des critères d’acceptation par rapport au ticket associé, ainsi que des contrôles de préparation avant la mise en œuvre.
Juillet 2026 : Garantir la fiabilité de l’état du projet.
Nous avons mis en place des fonctionnalités de préparation et de synchronisation permettant de concilier les exigences, les plans, la documentation et le code. Les développeurs pouvaient également vérifier les critères d’acceptation avant d’ouvrir une pull request.
Cette progression s’est articulée autour du contexte partagé, de la qualité des spécifications, de la révision indépendante et de la synchronisation au niveau du projet. Chaque étape a élargi les capacités de l’agent et comblé un déficit de confiance mis en évidence par l’étape précédente.
De « l’humain dans la boucle » à « l’humain sur la boucle »
Grâce à ces outils, les agents pouvaient mener à bien des tâches définies tout au long de la mise en œuvre, de la création de pull requests et des réponses aux revues. Les vérifications de préparation, d’écarts et d’architecture nous ont fourni un moyen pratique de résoudre les problèmes d’alignement.
Cela a ouvert la voie à un modèle opérationnel différent. Au lieu de lancer et d’approuver chaque étape, un humain pouvait superviser le travail de routine et gérer les escalades. Le modèle « l’humain sur la boucle » ne supprime pas la responsabilité humaine. Ce sont toujours les personnes qui définissent les objectifs, les priorités, les limites architecturales et de sécurité, ainsi que les droits de décision. L’agent opère dans le cadre de ces limites et signale les exceptions, les ambiguïtés et les compromis importants.
Il restait à éviter qu’un agent ne détermine la stratégie produit. Il s’agissait de réduire la coordination manuelle encore nécessaire pour faire passer un élément éligible du backlog de la planification à la mise en œuvre.
Prochaine étape : les boucles de planification délimitées
C’est la nouvelle frontière sur laquelle nous travaillons actuellement et le sujet que nous souhaitons approfondir en août. La prochaine étape ne consiste pas simplement à laisser un agent écrire davantage de code. Il s’agit de permettre à l’agent d’intervenir plus tôt dans le cycle de vie, tout en restant dans le cadre des objectifs et des droits de décision définis par l’humain.
La boucle de planification vers laquelle nous tendons commence par un backlog hiérarchisé et des exigences établies par l’équipe. Dans ces limites, un agent identifie la prochaine story éligible, rédige la story et le plan de mise en œuvre, puis évalue ces deux éléments au regard de l’état de préparation du projet et des vérifications des écarts. S’il rencontre des exigences floues, des priorités contradictoires, des exceptions architecturales ou des décisions hors de son champ de compétence, il transmet le dossier à un humain.
Une fois qu’une story et un plan ont passé ces contrôles, ils peuvent être transmis à un agent de la boucle de développement qui :
Écrira le code.
Valide le résultat par rapport aux objectifs énoncés dans l’exigence et l’histoire. Il vérifie non seulement si les tests sont réussis, mais aussi s’ils évaluent le bon comportement.
Confirme que l’implémentation respecte notre architecture et nos normes de codage.
Ouvre la pull request.
À chaque étape, l’agent n’agit que dans les limites de ses compétences définies et fait appel à un intervenant humain lorsque son jugement est nécessaire. Une fois que la personne a résolu le problème, le processus peut reprendre. C’est ce qu’on appelle l’« intervention humaine dans la boucle », appliquée tout au long du cycle de vie de la livraison, et pas seulement à la génération de code.
Pourquoi est-ce important pour August ?
La leçon va au-delà du projet X. Dans l’ensemble de nos travaux de développement axés sur les agents, les contrôles entourant l’agent se sont avérés tout aussi déterminants que la capacité de l’agent à générer du code. À mesure que les agents commencent à planifier le travail, à modifier le code, à ouvrir des pull requests et à effectuer des validations, la plateforme de développement doit faire plus que simplement aider les équipes humaines à livrer des logiciels. Elle doit également gérer les identités des agents, leurs autorisations, leurs environnements d’exécution, l’accès au code et aux données, ainsi que le parcours d’une modification proposée jusqu’à sa mise en production.
La plupart des plateformes de développement d’entreprise n’ont pas été conçues en tenant compte de cet acteur. De nombreuses pratiques de gestion des secrets ont été élaborées autour d’un développeur humain ou d’une identité de pipeline prévisible, et non d’un agent autonome capable de choisir et d’invoquer des outils. Les contrôles de développement sécurisés partent souvent du principe qu’une personne inspectera une modification avant sa mise en production. Les configurations par défaut des organisations GitHub partent du principe qu’un développeur effectue un push d’un commit et attend que le processus de révision établi prenne le relais. Les agents fonctionnent différemment, et ces hypothèses peuvent se traduire par des failles de contrôle.
Pour combler ces lacunes, des contrôles explicites sont nécessaires en matière de protection des branches, d’autorisations d’accès aux dépôts, d’authentification des agents, d’auditabilité, de périmètre des secrets et d’analyse des secrets. Les applications GitHub, les jetons d’accès personnels à granularité fine, les environnements GitHub Actions, Azure Key Vault et HashiCorp Vault ont tous un rôle à jouer, en fonction de l’environnement et des exigences réglementaires.
Le développement par agents relève donc de la plateforme et du modèle opérationnel, et non d’un simple choix d’outils de développement. Les responsables de la plateforme, du DevOps, de l’architecture, de la sécurité et de l’ingénierie doivent déterminer comment les agents fonctionneront avant que ceux-ci ne soient autorisés à participer à grande échelle au processus de livraison.
L’évolution du projet X illustre également l’ modèle d’amélioration de la maturité de l’IA, le cadre en huit étapes que nous avons présenté le 8 juin 2026 — la même semaine, comme par hasard, où l’évolution des outils du Projet X montre l’apparition de contrôles de qualité de l’IA dans l’intégration continue (CI). Le projet a débuté aux alentours de l’étape 3, avec un agent accomplissant une tâche définie et un humain vérifiant le résultat. Les contrôles ajoutés par la suite ont fait évoluer le modèle de livraison vers les étapes 5 et 6, où les équipes délèguent des objectifs et laissent les agents coordonner le travail dans des limites définies.
L’important n’est pas le numéro de l’étape en soi. Chaque augmentation de l’autonomie des agents nécessite une augmentation correspondante de la maturité de la plateforme, de la gouvernance et de la supervision. Les organisations ne peuvent pas passer en toute sécurité de l’assistance à la délégation en se contentant d’étendre les capacités des agents.
En octobre, nous avons demandé si l’IA pouvait créer une fonctionnalité avec nous, en direct et en public. En août, nous aborderons une question plus difficile : la plateforme sur laquelle reposent les agents de développement est-elle prête à soutenir et à réguler ce qu’ils sont en train de devenir ?
Voici quelques questions sur lesquelles il convient de s’attarder d’ici là :
Que signifie l’accès avec le moins de privilèges possible pour un acteur capable de choisir ses propres outils et d’interagir avec plusieurs systèmes en une seule exécution ?
Votre équipe serait-elle capable de répondre, dès maintenant, à ce qu’un agent a fait et pourquoi — sans attendre qu’un incident se produise ?
Parmi vos processus de validation actuels, lesquels sont adaptés au rythme humain, et lesquels deviennent discrètement un goulot d’étranglement — ou un angle mort — dès que le code s’exécute dix fois plus vite ?
Nous n’avons pas encore toutes les réponses non plus. C’est justement l’objet du webinaire du mois d’août.
Si vous préférez en discuter plus tôt, nous proposons également un entretien de 30 minutes sur la préparation à la plateforme de développement « agentic » pour les équipes qui utilisent, testent ou évaluent actuellement GitHub Copilot. Pour les équipes qui en sont encore aux prémices de l’adoption, cet entretien est également la porte d’entrée vers notre atelier GitHub Copilot Accelerator — une session pratique animée par des experts visant à permettre aux développeurs d’utiliser Copilot efficacement avant d’aborder les questions de gouvernance soulevées dans cet article.
Si votre organisation passe d’un développement assisté par l’IA à des agents capables de planifier le travail, de modifier le code et de participer à la livraison, rejoignez-nous le 5 août à 12 h 30 (heure de l’Est) pour « Construire la plateforme de développement pour les agents IA ».
Inscrivez-vous à « Construire la plateforme de développement pour les agents IA »
