L’augmentation considérable de la vitesse d’écriture des logiciels n’est plus le seul défi auquel sont confrontées les équipes de développement. Alors que des outils comme Cursor passent de simples suggestions de code dans l’environnement de développement à l’exécution de tâches complètes à partir de spécifications et de tickets, le problème pourrait désormais résider dans la capacité de l’organisation à déterminer ce qui mérite d’être construit, à le tester, à le déployer en toute sécurité, puis à l’exploiter et à en assurer la maintenance.
C’est le thème de la présentation de Hannah Foxwell intitulée « Réinventer l’équipe de développement », qui s’intéresse davantage à l’impact de la programmation agentique sur les personnes et les processus qu’aux capacités des agents eux-mêmes. Foxwell fonde son analyse sur trois piliers qui, selon elle, restent importants quelle que soit l’accélération des outils.
Du manque de vitesse à l’excès de capacité
Foxwell décrit un parcours qui a commencé avec des équipes déployant des logiciels deux fois par an, puis qui est passé, grâce à Agile, au cloud computing, au DevOps et à la livraison continue, à plusieurs déploiements par jour. Elle estime que ce qui était présenté comme un objectif lointain, à savoir une grande vitesse, est en train de devenir une réalité que les organisations ne savent pas encore comment exploiter.
Dans le modèle de la programmation agentique, les agents peuvent décomposer les spécifications, écrire le code et les tests, puis contribuer au déploiement et à la supervision. Mais cette capacité peut créer une pression inverse sur la gestion des produits : les équipes de développement pourraient exécuter le travail plus rapidement que l’organisation ne peut fournir des exigences claires et qualifiées. Foxwell ne considère donc pas que la solution consiste à accepter chaque idée ou chaque demande, car cela pourrait conduire à des produits hypertrophiés et manquant de cohérence.
Premier pilier : construire ce qui mérite de l’être
Foxwell souligne que le code n’est pas une fin en soi, mais un moyen de résoudre un problème réel pour l’utilisateur. Alors que le coût de test des idées diminue, il devient préférable de créer des prototypes et de les tester auprès des utilisateurs avant d’en faire un engagement à long terme au sein du produit.
L’article présente notamment le modèle du « chef de produit qui programme des prototypes », afin de réduire la distance entre l’idée et le test, ou celui qui consiste à associer le chef de produit à un développeur lorsque l’idée dépasse les capacités de prototypage rapide. Il évoque également le rôle de l’ingénieur de terrain, un ingénieur qui travaille au plus près du client et dispose du mandat nécessaire pour résoudre ses problèmes, ainsi que celui de « l’ingénieur produit », qui participe à la conception du produit parce qu’il l’utilise ou qu’il est proche de ses utilisateurs.
Foxwell présente des expériences visant à repenser la taille et la composition des équipes. Plutôt que le modèle d’une équipe composée de six à huit développeurs et d’un seul chef de produit, certaines organisations testent des équipes plus petites, tandis qu’Andrew Ng a proposé un modèle inverse comprenant deux chefs de produit pour un développeur capable de coordonner une flotte d’agents. Ces modèles ne sont pas présentés comme des règles fixes, mais comme des expériences reflétant le déplacement du goulet d’étranglement : de la capacité de développement vers la clarté des exigences et la rapidité des décisions.
À l’inverse, l’article met en garde contre des pratiques telles que livrer une fonctionnalité puis passer immédiatement à une autre tâche sans examiner son utilisation, accepter chaque demande d’un client ou considérer l’opinion de la personne la mieux rémunérée comme critère de priorité. Dans un environnement où l’écriture de logiciels devient plus rapide, la recherche utilisateur, l’expérience utilisateur et la capacité à vérifier la valeur pourraient devenir des facteurs de différenciation plus importants que la vitesse d’exécution elle-même.
Deuxième pilier : la vitesse a besoin de sécurité
L’augmentation du volume des changements nécessite un processus de production capable de suivre le rythme. Foxwell avertit que les lacunes dans la couverture des tests et les étapes manuelles peuvent transformer le processus de déploiement en goulet d’étranglement, entraînant l’accumulation des changements avant leur arrivée auprès des utilisateurs.
L’article établit donc un lien entre la vitesse et les tests automatisés, en citant des exemples d’utilisation des agents pour créer des tests continus et aider les équipes à traiter la dette technique, à migrer depuis des plateformes anciennes et à refactoriser les bases de code. L’idée n’est pas d’ajouter de l’intelligence artificielle à un processus lent, mais de réingénier le chemin vers la production afin qu’il puisse supporter le nouveau rythme de changement.
Foxwell insiste sur le fait que la fiabilité et la sécurité ne sont pas des compromis acceptables en échange de la vitesse. Elle propose de s’appuyer sur des indicateurs, des objectifs de niveau de service et des budgets d’erreur, avec une politique écrite définissant ce que fera l’organisation lorsque le niveau d’échec acceptable sera dépassé, par exemple ralentir les mises en production ou affecter les ressources à la fiabilité et à la résilience.
Elle estime également que les déploiements progressifs, les feature flags, les tests A/B et les déploiements blue-green contribuent à gérer de nombreux changements sans les exposer d’un seul coup à l’ensemble des utilisateurs. Elle repense le rôle des équipes d’ingénierie de la fiabilité des sites et des plateformes internes, en les considérant comme des fonctions de conseil et d’habilitation qui fournissent aux équipes de développement un chemin sûr et préparé.
Qu’est-ce qui change concrètement ?
La conclusion éditoriale de la présentation est que les agents ne prouvent pas à eux seuls que les équipes de développement deviendront plus petites ou que des emplois disparaîtront. Ce qui est certain, c’est que les goulets d’étranglement se déplaceront : de la production de code vers le choix des problèmes, la validation de la valeur, l’extension des tests, le contrôle de la fiabilité et la prise de décision rapide.
La question reste ouverte de savoir si les organisations utiliseront cette nouvelle capacité pour construire de meilleurs produits et tester leurs idées, ou si elles y répondront en accumulant davantage de fonctionnalités. De même, les nouveaux ratios entre développeurs, chefs de produit, équipes de plateforme et équipes de fiabilité restent des expériences, et non des résultats établis. C’est pourquoi l’adoption de la programmation agentique exige de mesurer son impact sur la qualité du produit, les incidents et l’expérience utilisateur, plutôt que de se contenter de compter le nombre de lignes ou la vitesse des mises en production.