Nous utilisons des cookies pour vous garantir une expérience optimale. Si vous acceptez, vous êtes en accord avec cette utilisation. Pour plus d'informations, veuillez consulter notre politique de confidentialité.

Comment nous utilisons des agents d’IA pour réduire la friction en livraison logicielle

Evan Glicakis
Evan Glicakis
6
min read

Chaque projet logiciel vient avec une couche de travail qui entoure le code : transformer des décisions en tickets, garder la documentation à jour, configurer les dépôts, préparer les pull requests, faire avancer les tâches dans les différents flux de travail et reconstruire le contexte à travers les équipes et les outils. Pris individuellement, ces efforts peuvent sembler minimes. Ensemble, ils mobilisent l’attention des équipes et ralentissent la livraison.

C’est le défi à l’origine d’Ambrosia, une initiative née dans notre Hub R&D pour explorer comment des agents d’IA pourraient travailler aux côtés des équipes de développement. Aujourd’hui, les systèmes et les pratiques développés avec Ambrosia sont utilisés en production et intégrés à des environnements clients.

L’objectif n’est pas simplement de générer plus de code. Il s’agit de réduire la friction opérationnelle autour du développement pour aider les équipes à passer de l’intention à la livraison avec plus de clarté et de fluidité.

Alors que nous continuons à déployer et à raffiner ces approches, nous lançons une série sur l’ingénierie agentique afin de partager ce que nous construisons, ce que nous apprenons et ce que les organisations devraient considérer avant d’intégrer des agents à leurs propres processus de livraison logicielle.

De l’assistant au système de livraison

Au cours des dernières années, une grande partie des discussions sur l’IA en développement logiciel s’est concentrée sur la productivité individuelle : suggestions de code, soutien à la documentation, recherche plus rapide et autocomplétion plus performante.

Ces outils sont utiles, mais nous voulions explorer une autre question : que se passe-t-il lorsque les agents d’IA deviennent partie intégrante du processus de développement?

Ambrosia est né de cette volonté d’explorer la question dans un véritable contexte de livraison logicielle. Depuis, l’initiative a évolué vers une approche prête pour la production, que nous appliquons à nos propres projets et adaptons aux réalités des environnements logiciels de nos clients.

Plutôt que d’utiliser l’IA uniquement comme outil individuel, Ambrosia explore comment des agents spécialisés peuvent aider une équipe à faire avancer le travail. Ils peuvent interpréter la documentation d’un projet, créer des tickets structurés, mettre la documentation à jour, préparer des pull requests, réviser des changements et faire progresser les tâches dans des flux de travail définis.

L’objectif n’est pas seulement d’automatiser certaines parties du développement. Il est aussi de réduire le bruit opérationnel qui l’entoure, tout en gardant les personnes responsables de la direction, de la qualité, du jugement et des décisions.

Pourquoi une approche multiagents est importante

L’un des choix importants derrière Ambrosia est d’utiliser plusieurs agents spécialisés plutôt qu’un seul assistant qui essaie de tout faire.

La livraison logicielle est composée de nombreuses activités distinctes, mais interconnectées. Certaines demandent un jugement technique approfondi. D’autres sont plus répétitives ou davantage liées aux processus. En donnant des responsabilités plus ciblées aux agents, leur travail devient plus structuré, plus facile à évaluer et plus simple à réviser.

Cette approche permet aussi de travailler en parallèle. Plusieurs agents peuvent contribuer simultanément à différentes tâches tout en demeurant dans des limites clairement définies.

C’est là que l’ingénierie agentique devient particulièrement intéressante pour nous. Il ne s’agit pas de demander à l’IA de « tout construire », mais plutôt de concevoir un système dans lequel des agents peuvent soutenir l’équipe de façon ciblée et utile.

Moins d’administration, plus d’ingénierie

La valeur d’Ambrosia ne se résume pas à la vitesse. Elle vient aussi de la réduction de la friction.

Un ticket qui manque de contexte ralentit tout le monde. Une documentation désuète crée de la confusion. La configuration manuelle d’un projet prend du temps. Les petites tâches de coordination interrompent la concentration. Les pull requests doivent être préparées, révisées et acheminées aux bonnes étapes.

Pris séparément, ces éléments semblent rarement majeurs. Ensemble, ils influencent directement le rythme et la qualité de la livraison.

Avec Ambrosia, nous avons développé et déployé des agents capables de prendre en charge une partie de ce travail dans de véritables environnements de livraison. Un agent peut, par exemple, transformer des notes brutes ou de la documentation de projet en tickets plus clairs. Un autre peut mettre la documentation à jour ou préparer une pull request pour révision.

Les agents peuvent également parcourir de grandes quantités d’information, notamment de la documentation technique, des transcriptions de rencontres, des décisions de projet, des tickets et des spécifications logicielles, afin de faire ressortir le contexte pertinent au moment où les développeur·euse·s en ont besoin.

Ce contexte peut ensuite être utilisé pendant l’implémentation et la révision. Un agent de développement peut interpréter la documentation logicielle, les tickets, les connaissances propres au domaine et les conventions du projet lorsqu’il corrige un bogue ou développe une fonctionnalité. Un agent de révision peut évaluer les changements en fonction des critères d’acceptation, des exigences logicielles, des décisions architecturales et des autres informations liées au travail.

Avec le temps, les agents peuvent ainsi agir moins comme des assistants génériques et davantage comme des collaborateurs techniques qui comprennent le contexte propre à chaque projet.

Pour les développeur·euse·s, cela peut signifier moins de temps passé à reconstruire le contexte entre des systèmes déconnectés et plus de temps consacré à l’architecture, à la résolution de problèmes, aux compromis techniques et au contexte client. Autrement dit, au travail où leur expérience et leur jugement ont le plus de valeur.

Ambrosia en pratique

Ambrosia est déjà utilisé dans six projets, autant pour du travail client que pour des initiatives internes, des preuves de concept et des projets de démonstration. Au moment d’écrire ces lignes, les équipes l’utilisent depuis des périodes allant d’environ une semaine à cinq mois, avec des niveaux d’adoption qui varient d’un projet à l’autre.

Plutôt que d’appliquer la même configuration partout, les équipes adaptent le cadre d’orchestration d’Ambrosia aux besoins, aux outils et aux pratiques de développement propres à chaque projet. Cela nous permet d’explorer où les agents apportent le plus de valeur à différentes étapes du cycle de livraison logicielle.

Jusqu’à maintenant, Ambrosia a notamment été utilisé pour soutenir :

  • Les flux de développement : implémenter des tickets, générer des tests, appliquer les pratiques de programmation propres à un projet, préparer des pull requests, mettre à jour le statut des tickets, faire respecter les conventions de contribution et valider l’infrastructure.
  • La gestion de projet : connecter les outils de suivi de projet, les systèmes de gestion de versions et les agents de programmation afin d’aider à rédiger, structurer et créer des tickets.
  • La qualité du code : réviser les changements en fonction des critères d’acceptation, évaluer l’impact des refactorisations, soutenir le développement piloté par les tests et garder la documentation alignée avec la base de code.
  • L’implémentation du design : transformer des maquettes Figma en composants React tout en respectant la mise en page, les espacements, la typographie, les couleurs et les autres détails visuels.
  • La documentation : produire et maintenir une documentation de projet structurée de façon cohérente.
  • L’architecture et l’expérimentation : aider les équipes à réfléchir aux approches techniques et à développer des solutions dans des domaines moins familiers.

Ces déploiements en sont encore à différents stades, alors nous demeurons prudents avant d’en tirer des conclusions générales. Ils commencent toutefois à nous montrer que la valeur de l’ingénierie agentique va bien au-delà de la génération de code.

Les équipes trouvent des occasions d’utiliser les agents dans plusieurs aspects du processus de livraison, particulièrement lorsque le contexte doit circuler entre différents outils, que certaines étapes répétitives peuvent être automatisées ou que les connaissances propres à un projet doivent être appliquées de façon cohérente.

Les développeur·euse·s comme orchestrateur·rice·s

À mesure que les agents deviennent plus performants, le rôle des développeur·euse·s évolue.

Les compétences techniques demeurent essentielles. Mais il devient aussi important de savoir bien définir le travail, fournir le bon contexte, réviser les résultats, valider les décisions et reconnaître les moments où une intervention humaine est nécessaire.

Dans un processus agentique, le rôle du développeur ou de la développeuse ne consiste plus uniquement à produire du code. Il consiste aussi à orchestrer le travail.

Ce changement est important. Il demande aux équipes de développer de nouvelles habitudes autour de la clarté, de la révision et de la responsabilisation. Il crée aussi un nouveau type de levier : une personne qui sait bien guider les agents peut aider son équipe à avancer plus rapidement sans faire de compromis sur la qualité.

Cela change également la valeur des informations qui alimentent le travail. Des tickets clairs, des décisions documentées, des conventions bien définies et des connaissances du domaine facilement accessibles deviennent encore plus importants lorsque les personnes et les agents s’appuient sur les mêmes informations pour prendre des décisions.

Intégrer la gouvernance dès le départ

Des agents capables d’agir ont besoin de limites claires.

En développement logiciel, un agent peut interagir avec des bases de code, des outils en ligne de commande, de la documentation, des tickets et différents environnements de projet. Sans une conception réfléchie du système, cela crée de véritables risques.

Avec Ambrosia, la gouvernance fait partie de l’architecture. Les agents ont besoin de limites, d’environnements contrôlés et des bonnes permissions pour chaque tâche. Ils doivent aussi respecter la même logique de travail que l’équipe.

C’est particulièrement important dans les projets clients, où la gestion du contexte, des accès et de la séparation des données est essentielle.

Pour nous, une approche responsable de l’ingénierie agentique ne consiste pas à donner le plus de pouvoir possible aux agents. Il s’agit de leur donner la bonne portée et les bons contrôles pour qu’ils puissent être utiles sans créer de risques inutiles.

Ce que nous apprenons

Ambrosia a commencé comme une initiative interne de R&D. En passant vers la production et les projets clients, l’initiative nous a amenés à nous poser des questions plus larges sur la façon dont les équipes logicielles devraient s’organiser dans un environnement agentique :

  • Comment concevoir les flux de travail lorsque certaines tâches peuvent être réalisées en parallèle par des agents?
  • Comment former les développeur·euse·s à travailler efficacement avec des systèmes agentiques?
  • Comment maintenir la qualité lorsque les humains et l’IA contribuent tous les deux à la livraison?
  • Comment préserver la responsabilisation lorsque des agents peuvent agir à travers plusieurs outils?
  • Comment structurer les connaissances d’un projet lorsque les personnes et les agents en dépendent?

Ce sont des questions auxquelles nous nous attaquons en continuant à développer et à déployer Ambrosia.

Nous voyons l’ingénierie agentique comme une nouvelle façon de structurer le travail. Lorsqu’elle est bien intégrée, elle peut réduire la friction, faciliter l’accès au contexte et donner aux développeur·euse·s plus de temps pour le travail qui demande du jugement humain.

Cet article est le premier d’une série dans laquelle nous partagerons ce que nous apprenons à mesure que nous déployons, raffinons et faisons évoluer nos pratiques d’ingénierie agentique dans de véritables environnements logiciels.

Pour les organisations qui explorent comment les agents pourraient améliorer leurs propres processus de livraison logicielle, notre équipe peut vous aider à identifier les bons cas d’usage et à transformer ces possibilités en systèmes prêts pour la production. Communiquez avec notre équipe si vous avez des questions.

Evan Glicakis
About the author
Evan Glicakis
Lead Developer
The R&D hub by Osedea
A place where we transform ambiguity into clarity, helping you make confident decisions and scale what works.