Des exigences en entrée, de l’infrastructure en sortie : un service managé passe au développement agentique

Plus tôt cette année, nous avons aidé un prestataire de services managés (MSP) à déplacer le développement de sa plateforme principale, l’infrastructure as code (IaC) qui déploie et maintient l’infrastructure cloud et les charges de travail de ses clients sur Azure, d’Azure DevOps vers GitHub Enterprise, et à reconstruire la façon de travailler de son équipe autour d’agents IA. Les membres de l’équipe livrent désormais de vrais changements d’infrastructure en décrivant ce dont ils ont besoin. Les ingénieurs seniors gardent le contrôle par la revue et l’approbation. Voici ce qui a changé.

Le point de départ

La plateforme a commencé comme un environnement Azure DevOps : une infrastructure écrite en Terraform pour les clients des services managés, validée et déployée par des pipelines CI/CD dans Azure DevOps. Cela fonctionnait, mais cela évoluait avec les personnes, pas avec la demande. Un ingénieur senior ne pouvait prendre en charge qu’un nombre limité de tâches complexes à la fois. La livraison passait par des centaines de fichiers de pipeline, pour la plupart des copies propres à chaque client, de sorte que chaque changement transversal devait être répété dans chacun d’eux. Contribuer supposait de connaître Terraform, les règles de nommage, la structure du dépôt et sa logique. Le savoir vivait dans une seule tête.

La migration

Nous avons d’abord mis la GitHub Enterprise elle-même sous code, puis déplacé le dépôt de la plateforme avec tout son historique et migré l’ensemble des pipelines vers GitHub Actions en une seule semaine. Les centaines de fichiers de pipeline se sont réduits à un seul modèle de déploiement réutilisable, qui se décline sur chaque client et chaque environnement à partir de la configuration, plus un workflow léger par fonctionnalité. Un changement qui s’éditait autrefois dans chaque copie s’édite désormais une seule fois. L’intégration d’un client est devenue un fichier de configuration, et ce fichier est créé par un agent IA à partir d’une demande en langage courant, formulée comme un ticket (issue) GitHub.

La gouvernance en tant que code

Les identités, les équipes et les permissions viennent de Microsoft Entra ID et sont créées par du code. La protection des branches est définie au niveau de l’organisation et aucun administrateur de dépôt ne peut l’assouplir : chaque changement exige une revue approuvée, et les déploiements en production passent par une approbation humaine. Les règles sont les mêmes pour une personne et pour un agent, et une personne garde toujours le contrôle.

Un seul règlement pour les personnes et les agents

L’équipe entretient un jeu central d’instructions que chaque agent reprend pour toute tâche qu’il exécute : l’organisation du dépôt, les conventions de nommage, les outils à utiliser, la manière de tester un changement et de rédiger une pull request. Les mêmes règles s’exécutent comme des contrôles sur chaque pull request et comme des hooks sur la machine de chaque développeur, de sorte qu’une règle qui compte est appliquée, et pas seulement écrite.

Ces garde-fous sont ce qui permet à des collègues moins expérimentés de contribuer en toute sécurité : l’agent suit le règlement, les contrôles attrapent ce qu’il fait de travers, et un ingénieur senior a le dernier mot.

La nouvelle façon de travailler

N’importe qui dans l’équipe décrit son besoin sous forme de ticket GitHub, souvent rédigé avec GitHub Copilot, et l’assigne à un agent de codage. L’agent ouvre une pull request. Les contrôles s’exécutent. Un ingénieur senior relit, demande des modifications si nécessaire et approuve ; l’agent itère dans la même pull request. La fusion déclenche le déploiement, et la production attend toujours une approbation humaine. Dans la première étape, personne ne touche au code.

Les ingénieurs seniors utilisent des assistants IA de manière interactive pour la conception, le débogage, la revue et l’exploitation, et ce travail arrive sous forme de pull requests relues, comme tout le reste.

Ce qui a changé

• Vélocité. Dans le premier mois suivant la migration, les agents ont livré seuls des dizaines de changements fusionnés, et ils n’ont pas cessé depuis. Aujourd’hui, environ un tiers de tous les changements fusionnés sont écrits par des agents, et la plupart sont acceptés après un seul tour de revue.
• Délai de mise en production. Une demande bien décrite passe généralement du ticket au changement fusionné en une journée, le déploiement suivant automatiquement, et nombre de ces demandes sont terminées le jour même.
• Complexité. Des centaines de fichiers de pipeline sont devenus un modèle. La mise en forme, la documentation et les rapports d’état sont assurés par des bots. Un déploiement nocturne en échec ouvre son propre ticket au lieu d’attendre qu’on le remarque. Les ingénieurs seniors auraient pu construire tout cela eux-mêmes ; ce que l’IA a changé, c’est le calendrier, en terminant dans un délai qu’aucune équipe humaine n’aurait pu tenir.
• Qualité. Chaque changement, qu’il vienne d’une personne ou d’un agent, passe les mêmes contrôles et la même revue. Les règles vivent dans le dépôt, et la piste d’audit va de la demande à la production.
• Capacité de l’équipe. L’ingénieur qui écrivait autrefois l’essentiel du code relit et décide désormais. La contribution d’un deuxième ingénieur a été multipliée par plus de dix. Deux autres collègues livrent des changements en les décrivant. Le point unique de défaillance a disparu.

Ce que cela a permis d’économiser

À titre d’estimation, les seuls changements écrits par les agents représentent environ deux à trois mois-ingénieur sur les huit premiers mois, une fois déduit le temps de revue qu’ils exigent. Le gain le plus important est plus difficile à compter : du temps senior consacré à la conception et à la revue plutôt qu’à des changements routiniers, et un backlog qui n’attend plus une seule personne.

Ce que nous avons appris

• Les agents ont besoin de règles applicables, pas de prose. Chaque consigne qui comptait est devenue un contrôle.
• La qualité de la demande décide de la qualité du résultat. Rédiger des critères d’acceptation est la nouvelle compétence clé.
• La revue est là où la séniorité paie. L’équipe a placé ses meilleurs éléments au point de plus fort levier.

Nous montrons l’exemple

Notre propre infrastructure, notre documentation, notre site web et notre organisation GitHub fonctionnent de la même manière : les demandes deviennent des tickets, les agents font le travail, chaque changement est une pull request relue derrière des contrôles automatisés, et un journal des décisions et des runbooks conservent la piste d’audit. La page que vous lisez a été produite ainsi.

L’IA ne remplace pas la séniorité, et ne l’exclut pas non plus. Elle multiplie ce qu’une équipe peut livrer quand les règles sont claires et que les ingénieurs seniors gardent le dernier mot. Découvrez notre offre en IA et IA agentique et en montée en compétences.