Le développement produit agentique consiste à structurer l'ensemble du cycle de livraison logicielle de sorte que des agents IA prennent en charge l'échafaudage, le transfert de contexte et la génération de code, tandis que les ingénieurs se concentrent sur le jugement, la revue et les décisions. Cette approche fonctionne mieux lorsque les fondations sont solides et le contexte explicite.
Des phases structurées produisent de meilleurs résultats pour les agents
Les agents IA produisent de meilleurs résultats lorsqu'ils disposent d'un contexte clair et de limites bien définies. Des instructions vagues génèrent du code générique. Des spécifications détaillées produisent du code adapté à votre base de code, conforme à votre système de design et respectueux de vos conventions.
Cela a conduit les équipes à revenir vers des phases de livraison linéaires et structurées : la découverte d'abord, puis le design, puis le développement. La logique est simple. Lorsque vous consolidez tout le contexte et toutes les décisions avant le début de la livraison, les agents de codage disposent de tout ce dont ils ont besoin. Plus de suppositions, d'improvisation ni d'allers-retours en cours de sprint.
Automatiser la couche administrative
Lorsque vous cartographiez chaque étape d'un processus produit classique, la majeure partie du travail s'avère être du méta-travail : rédiger des comptes rendus, créer des documents de passation, structurer des actions et transférer le contexte entre les personnes. E-mails, tableurs, présentations de handoff. Nécessaire, mais ce n'est pas là que la valeur est créée.
Les équipes qui utilisent efficacement les agents ont automatisé cette couche administrative et réinvesti ce temps dans les échanges où les décisions produit se prennent réellement : explorer le domaine, les priorités et les contraintes avec les parties prenantes.
Une couche de contexte qui prévient la dégradation lors des transferts
Le principal problème structurel du développement produit est la dégradation du contexte. Chaque transfert entraîne une perte d'information. Entre la découverte et le design. Entre le design et le développement. Entre une réunion et la suivante.
Une couche centrale d'ingénierie du contexte, construite avec des agents et des serveurs MCP, répond directement à ce problème. Les agents se connectent aux outils de découverte, récupèrent des données de session non structurées et les structurent automatiquement en briefs produit, tableaux de fonctionnalités et matrices de priorités. Ce contexte structuré alimente les outils de design, où les agents échafaudent de vrais composants à partir du système de design existant. De là, il transite vers les tickets de développement avec les critères d'acceptation et les références de design.
Aucune copie manuelle d'informations entre les outils. Le contexte circule au lieu de se dégrader.
Cela rend également l'exploration parallèle viable. Cinq directions de solution peuvent être prototypées simultanément à partir de composants réels du système de design et des données de découverte, puis examinées ensemble. Construire cinq prototypes manuellement prendrait des semaines. Les agents gèrent l'échafaudage ; les ingénieurs exercent leur jugement.
Développement piloté par les spécifications
La façon dont le travail de développement est défini a évolué parallèlement à la façon dont il est exécuté. Les tickets traditionnels décrivent des critères d'acceptation : quand cette tâche est-elle terminée ? Les équipes agentiques évoluent vers des spécifications. Plutôt que de lister ce qu'une fonctionnalité doit faire, une spécification décrit le résultat attendu sous la forme d'un workflow complet, y compris les cas limites.
L’agent déroule cette spécification et valide lui-même son résultat en la prenant comme référence. Cela ne fonctionne que parce que le contexte issu de la phase de discovery et du design est déjà chargé. L’agent travaille face à un objectif clairement défini. À lire aussi : le prompt engineering est-il encore utile ?.
Ce qui échoue réellement
Le mode d'échec n'est pas que les agents écrivent du mauvais code. C'est qu'ils écrivent du code plausible. Du code qui s'exécute, du code qui passe une revue rapide, mais qui, en dessous, repose sur des hypothèses qui ne tiennent pas, référence des API qui n'existent pas dans votre version, ou résout un problème d'une façon qui en casse trois autres.
On a observé des agents utiliser avec assurance une documentation obsolète, inventer des colonnes de base de données, et construire des solutions élégantes qui ignorent complètement l'architecture existante.
Le vrai danger, c'est qu'à mesure que la qualité des productions des agents s'améliore, la rigueur de la revue diminue. Les équipes commencent à faire confiance à l'agent. Elles survolent au lieu de lire. Elles approuvent au lieu de questionner. On parle parfois d'AI slop, et le prévenir fait désormais partie du rôle de l'ingénieur au même titre que la création de fonctionnalités. La revue du code généré par l'IA demande un effort actif : trois niveaux fonctionnent bien en pratique. L'agent écrit. Une revue automatisée filtre. Un ingénieur humain tranche en dernier ressort. Pour en savoir plus sur ce qui a changé à ce sujet, consultez ce qui a changé dans la revue de code.
Les meilleurs ingénieurs dans un workflow agentique ne sont pas les meilleurs codeurs. Ce sont les meilleurs penseurs.
Votre organisation n'est peut-être pas prête
Tout ce qui précède ne fonctionne que si vos bases sont en ordre.
L'absence de design system signifie que les agents produisent des designs incohérents. L'absence de base de code modulaire signifie une production non maintenable. L'absence de documentation structurée signifie que la couche de contexte n'a rien sur quoi s'appuyer.
Les équipes qui veulent adopter le développement agentique, mais qui travaillent sur un code legacy, doivent d'abord remettre l'existant dans un état exploitable. Une approche concrète : écrire une suite de tests qui couvre l'ancien code en détail, puis laisser des agents le refactoriser vers une stack moderne en validant leur travail avec ces tests. Les tests deviennent la référence. Si le code refactorisé les passe, vous savez qu'il fonctionne. C'est une forme de human-in-the-loop engineering appliquée au niveau de l'architecture.
Les organisations qui tirent le meilleur parti du développement agentique ont d'abord investi dans le travail de fond : une architecture propre, des conventions documentées, du code modulaire, un système de design que les agents peuvent étendre. L'outil ne vaut que ce que vaut le système construit autour de lui.
Dans une équipe AI-native
Les AI-native engineers qui travaillent dans des pipelines agentiques passent plus de temps à lire et à vérifier du code qu'à en écrire de zéro, car les agents peuvent générer des modules entiers plus vite que n'importe quel individu ne peut les saisir. L'ingénierie du contexte, et pas seulement la rédaction de prompts, devient une compétence centrale : la qualité de ce qu'un agent produit dépend en grande partie de la façon dont la documentation, les conventions et les spécifications environnantes sont structurées. Les équipes ont également besoin d'une responsabilité claire à l'étape de révision, car le volume de code généré par les agents peut facilement dépasser la capacité de contrôle manuel si personne n'en est explicitement chargé.
Ce que nous évaluons
Pour évaluer les ingénieurs destinés à des postes agentiques, nous faisons passer deux évaluations, décrites dans notre processus de sélection. La première porte sur les fondamentaux, sans outils d'IA, et vérifie que l'ingénieur sait lire et analyser du code seul. La seconde est une évaluation AI-native, où il travaille avec des agents sur une tâche réaliste. Elle teste le jugement en conditions réelles : sait-il repérer une API inventée par le modèle, détecter une hypothèse d'architecture qui ne tient pas, vérifier du code généré qu'il n'a pas écrit ? Ces compétences déterminent l'efficacité d'un ingénieur dans une équipe agentique. La vitesse de codage brute pèse peu.
