Scrum reste pertinent face à l’ingénierie agentique

L’ingénierie agentique ne rend pas Scrum obsolète. Elle révèle plutôt à quel point une mise en œuvre efficace de Scrum dépend d’humains qui comblent des lacunes jamais formalisées : exigences ambiguës, contexte architectural, décisions informelles, jugement en revue de code et compréhension intuitive de ce que signifie « terminé ». Dès lors que des agents prennent en charge une part importante du travail de delivery, les équipes doivent transformer ces dépendances cachées en artefacts et en contrôles que les logiciels peuvent récupérer, exécuter et vérifier.

La distinction commence par ce que fait un agent. L’IA en pair programming assiste un développeur sur une tâche en cours, tandis que le développement agentique peut coordonner un travail délimité sur plusieurs étapes de delivery. La définition donnée par Simon Willison en 2026 décrit l’ingénierie agentique comme un développement logiciel dans lequel des agents de codage génèrent et exécutent du code, puis itèrent de manière autonome au lieu d’attendre une intervention humaine à chaque étape.

Cette portée plus large apparaît dans plusieurs modèles du secteur, chacun produit par une organisation ayant intérêt aux logiciels ou services agentiques. Seven Peaks, une entreprise de services technologiques pouvant bénéficier de l’adoption de ces pratiques, a décrit en 2025 un flux représentatif : spécification → décomposition → tests → code → vérification, avec peu d’intervention humaine pendant l’exécution. LangChain, qui développe une infrastructure pour agents et bénéficie d’une adoption plus large de ces derniers, a prolongé cette idée dans son modèle 2026 avec des membres d’équipe numériques aux rôles définis, une mémoire partagée et de l’observabilité sur l’ensemble du delivery. Microsoft, qui commercialise les plateformes Azure et GitHub utilisées dans son modèle, va encore plus loin avec un « AI-led SDLC » de 2026 qui place des agents dans la planification, le codage, les tests et le déploiement au sein de cet environnement. Dans l’ensemble de ces modèles, les agents reçoivent une autonomie plus large dans le delivery, tandis que la structure globale d’inspection et d’adaptation reste en place.

La boucle d’inspection et d’adaptation subsiste même si les mécanismes sous-jacents évoluent

Le modèle de Microsoft illustre cette distinction parce que ses agents occupent des étapes d’un cycle de vie de développement logiciel existant. La planification précède toujours l’implémentation, le code doit toujours être testé et le déploiement en production reste un événement contrôlé. Les agents modifient qui ou quoi exécute le travail à l’intérieur de ces étapes ; les équipes sont donc confrontées à un problème d’ingénierie au sein du framework de delivery, et non à une raison de l’abandonner.

Cette distinction rend les incréments bornés de Scrum utiles lorsque les agents exécutent une plus grande part du travail. Hackernoon a identifié l’intégration comme le principal défi des équipes d’agents en 2025 et a signalé des problèmes avec les approches qui accordent aux agents une large autonomie. Encadrer le travail et créer des points de contrôle fréquents donne aux équipes des moments où inspecter le comportement des agents avant qu’une décision locale ne se propage plus loin dans le système.

Les échanges entre praticiens apportent des éléments connexes, même s’ils reflètent l’expérience du terrain plutôt qu’une recherche formelle. Les conversations sur la communauté r/agile de Reddit en 2026 se sont concentrées sur la réallocation de l’attention humaine au sein des frameworks existants plutôt que sur l’abandon de Scrum. Le rythme des sprints et le time-boxing continuent de définir des périmètres gérables, tandis que l’inspection et l’adaptation fournissent le mécanisme permettant de corriger ce qui se passe à l’intérieur.

Ces points d’inspection préservent aussi la finalité des rétrospectives et du Product Ownership. Quelqu’un doit toujours décider quels résultats comptent, quel travail mérite la priorité et ce que l’équipe doit changer après un incrément. Une autonomie d’exécution accrue rend la priorisation humaine plus déterminante, car un agent peut mettre en œuvre plus vite qu’une équipe conventionnelle une décision mal cadrée.

La persistance de ces mécanismes Scrum crée une objection apparente à l’idée que l’ingénierie agentique modifie fortement Scrum. Le rythme des sprints, le time-boxing, les rétrospectives, le Product Ownership, l’inspection, l’adaptation et la priorisation humaine restent utiles, si bien que le framework lui-même peut sembler largement inchangé. Le changement se situe en dessous : la préparation, le contexte, la justesse et l’achèvement doivent devenir beaucoup plus explicites pour permettre une exécution autonome.

Ce qui casse d’abord, c’est le contexte tacite : les agents ne peuvent pas déduire l’histoire derrière l’histoire

Le problème de mise en œuvre apparaît immédiatement dans un élément ordinaire du backlog : « En tant qu’utilisateur, je veux filtrer les résultats par plage de dates. » Un développeur humain peut interpréter la formule générique « en tant qu’utilisateur, je veux… » à partir de l’historique produit et des conventions existantes, puis combler les lacunes par des échanges informels ou une question rapide. Le ticket lui-même peut contenir bien moins d’informations que celles que le développeur utilisera finalement pour l’implémenter.

Ces informations supplémentaires parviennent aux équipes humaines par plusieurs canaux. Les standups diffusent le contexte récent, les design reviews communiquent le raisonnement, la responsabilité du code apporte une connaissance accumulée du système, et le jugement individuel résout des ambiguïtés qui n’atteignent jamais le backlog. Ensemble, ces mécanismes permettent à un ticket sous-spécifié de produire un logiciel acceptable parce que le processus d’implémentation ajoute silencieusement de l’information.

Les agents ont besoin de ces hypothèses sous une forme qu’ils peuvent exploiter. Pour le ticket sur le filtre par date, un agent a besoin de critères d’acceptation explicites et de conditions limites afin que le comportement attendu puisse être évalué. Les contrats d’entrée/sortie, qui spécifient les structures échangées entre composants, et les schémas, qui définissent la forme et les règles des données, doivent aussi décrire ce que l’agent consomme et produit. Une hypothèse qui ne reste que dans la tête d’un développeur peut sinon devenir un défaut dans la sortie de l’agent.

Cette exigence fait de la Definition of Ready, le standard de l’équipe pour décider si un travail est prêt à être exécuté, une surface de contrôle importante. Un élément prêt doit disposer des contrats, schémas, critères d’acceptation et cas limites nécessaires pour établir une complétion testable par machine avant le début de l’exécution du sprint. L’effort humain se déplace donc en amont, car rédiger une spécification utile consiste de plus en plus à définir les limites comportementales dans lesquelles un agent peut travailler.

Les spécifications au niveau du ticket dépendent toujours du contexte au niveau du système. L’architecture, les règles métier et les décisions de conception antérieures doivent disposer de représentations accessibles à la machine, car ces contraintes déterminent si un code localement correct s’intègre au système dans son ensemble. Les fichiers AGENTS.md, les plan files et la documentation des schémas fournissent aux agents des éléments concrets à exploiter, tandis que des systèmes de retrieval peuvent fournir le contexte pertinent pendant l’exécution.

Dès lors que la connaissance du système doit pouvoir être récupérée, son rôle d’ingénierie change. Une décision architecturale communiquée lors d’une design review peut influencer les personnes présentes, tandis qu’un agent ne peut agir dessus qu’une fois la décision rendue accessible à son environnement d’exécution. En pratique, le changement va au-delà de tickets plus longs : le contexte tacite humain devient une partie de l’environnement conçu dans lequel le delivery s’effectue.

Une vérification fiable devient la contrainte de passage à l’échelle

Une fois qu’un agent dispose d’assez de contexte pour générer un travail utile, la contrainte se déplace en aval vers la vérification. DevelopersDigest a affirmé en 2026 que les agents peuvent produire « dix pull requests dans le temps qu’un humain en écrit une ». Ce chiffre correspond à l’affirmation de débit de DevelopersDigest plutôt qu’à un benchmark général, mais il illustre le problème opérationnel : la capacité de génération peut croître plus vite que la capacité de revue.

Ce déséquilibre peut ralentir le merge gate alors même que la production de code s’accélère. Si les personnes doivent toujours lire chaque ligne générée, la capacité de revue devient rare et les pull requests s’accumulent en attente. Une vitesse de génération plus élevée ne produit des gains de delivery utiles que si une vérification fiable peut se développer au même rythme.

La conclusion antérieure de HackerNoon sur l’intégration renforce la même contrainte : une large autonomie des agents crée des problèmes d’intégration, donc une exécution plus sûre nécessite des tâches bornées avec des résultats mesurables. La séquence opérationnelle est la suivante : périmètre borné → évaluation comportementale → résultat mesurable. Une équipe confie à un agent une responsabilité définie, évalue ce que l’agent fait réellement, puis n’autorise la progression que lorsque le résultat satisfait à des critères explicites.

AWS Prescriptive Guidance a formalisé une grande partie de ce modèle opérationnel en 2026 via AWS AgentOps, des recommandations liées à la plateforme cloud commerciale d’AWS et donc à l’intérêt d’AWS à voir ses clients exécuter des systèmes d’agents sur ses services. AWS traite chaque agent, outil et configuration mémoire comme un artefact versionné avec une intégration continue et un déploiement continu dédiés, ou CI/CD. Une étape d’évaluation comportementale devient alors une porte de passage vers la production, de sorte qu’un prompt, un outil ou une configuration mémoire modifiés voient leur comportement testé dans le cadre du processus de release.

Ces pipelines ont besoin de contrôles visant le comportement des agents autant que celui des applications. Les tests de régression de prompt détectent les dérives comportementales après un changement, tandis que les golden tests exécutent des entrées connues et comparent les résultats aux sorties attendues. Les accuracy gates et les contrôles d’hallucination évaluent le comportement des réponses ; les tests de régression ordinaires protègent les fonctionnalités établies ; la validation de l’Infrastructure-as-Code vérifie les définitions d’infrastructure lisibles par machine ; et les tests d’intégration par étapes exposent les interactions entre composants avant la production.

Le contrôle de production se poursuit après ces vérifications automatisées, car une suite de tests réussie n’autorise pas à elle seule une mise en production. Les approval gates préservent l’autorité humaine sur les changements destinés à la production, tandis que les smoke tests post-déploiement vérifient si le système déployé exécute toujours ses opérations essentielles. Les composants au comportement variable ont donc besoin d’un pipeline de release plus riche que les systèmes de delivery reposant principalement sur une automatisation déterministe.

Ce pipeline plus riche élargit la Definition of Done, c’est-à-dire les conditions qui établissent l’achèvement. La sortie d’un agent doit être revue au regard de ses contrats, réussir l’évaluation comportementale, avoir une observabilité et un tracing confirmés, et comporter une procédure de rollback documentée. L’observabilité expose l’état du système via des signaux opérationnels, tandis que le tracing enregistre le chemin qu’une opération emprunte à travers les composants. Ensemble, ces contrôles font de « terminé » une condition que le système de delivery peut tester et que les opérateurs peuvent maîtriser.

Même une solide porte de contrôle comportementale a une limite, car les tests n’établissent le comportement que pour les conditions qu’ils exercent. Des tests réussis montrent que le logiciel s’est comporté correctement pour les entrées testées ; la cohérence architecturale, la maintenabilité à long terme et la compatibilité avec chaque choix de conception à l’échelle du système exigent toujours un jugement distinct. La vérification automatisée peut absorber un plus grand volume de revue, tandis que le jugement architectural reste une responsabilité d’ingénierie à part entière.

Prenons l’exemple hypothétique d’une fintech de 300 personnes exploitant douze microservices. Un agent implémente une fonctionnalité et inclut une migration de base de données dans sa pull request ; sans garde-fous adaptés, cette migration peut atteindre l’environnement de staging avant que quiconque n’en reconnaisse la conséquence plus large. Avec des contrôles de régression et un approval gate, le changement est signalé pour revue humaine et testé sur un golden dataset, un jeu de données de référence fixe au comportement attendu connu, avant de progresser.

L’exemple de la fintech montre pourquoi un reviewer automatisé fonctionne mieux avec une responsabilité étroite. Techstack a conçu un reviewer de couverture de tests intégré à la CI qui utilise AWS Bedrock et Claude pour analyser les pull requests à la recherche de scénarios de test manquants. Techstack fournit des services technologiques et peut tirer un bénéfice commercial de la démonstration d’implémentations agentiques réussies ; ses résultats publiés décrivent donc sa propre implémentation. Le système renvoie directement les constats de tests manquants comme feedback de PR, faisant de l’analyse des lacunes de test une opération CI bornée au lieu de donner à un agent une large autorité pour décider si un changement est acceptable.

Techstack indique que cette implémentation a réduit le temps de revue manuelle jusqu’à 40 % et amélioré la couverture de tests de 20 à 30 %. Ces chiffres décrivent l’implémentation de Techstack, tandis que la conception montre comment une tâche définie au niveau de la PR peut produire une sortie mesurable. L’automatisation peut faire passer à l’échelle une partie précise de la vérification pendant que les ingénieurs conservent la responsabilité d’une justesse plus large.

La variable de productivité qui en résulte est la relation entre capacité de génération et capacité de vérification fiable. Augmenter la seule capacité de génération crée des files d’attente et accroît la quantité de sorties d’agents en attente de jugement humain. Un système de delivery agentique mature doit donc concevoir le débit de vérification avec la même attention qu’il accorde au débit de génération.

La connaissance organisationnelle devient une infrastructure que les agents peuvent récupérer et tester

La vérification s’étend aussi aux informations consommées par les agents, car le contexte encodé peut être incomplet, obsolète ou mal récupéré. Les exemples précédents de standups et de design reviews montraient comment les personnes comblent les lacunes contextuelles grâce à une histoire partagée et à la conversation. Une fois cette connaissance capturée pour les agents, un système de retrieval devient une partie de l’infrastructure de delivery, et sa sortie doit pouvoir être évaluée.

La base de connaissances interne de Techstack fournit une implémentation concrète provenant de la même entreprise de services technologiques ayant un intérêt commercial. Techstack a construit une architecture RAG multi-vectorielle, où le retrieval fournit à un système d’IA des éléments organisationnels pertinents au moment où il formule une réponse. Techstack a associé cette couche de retrieval à une suite de benchmark automatisée d’assurance qualité, afin que l’équipe puisse évaluer de manière répétée la qualité des réponses obtenues.

Techstack rapporte l’évolution suivante :

Ces résultats relient l’ingénierie de la connaissance à la vérification dans l’implémentation de Techstack. Une base d’expertise rend la connaissance organisationnelle capturée accessible via le retrieval, et la suite de benchmark vérifie si ce retrieval produit des résultats utiles. Un meilleur prompting ne peut pas fournir des règles d’architecture, un contexte métier ou des décisions institutionnelles qui n’ont jamais été encodés pour que le système puisse les récupérer.

L’exemple de Techstack complète le modèle AWS AgentOps présenté plus haut, mais à une autre couche. AWS rend les agents, outils et configurations mémoire versionnables et soumet leur comportement à des portes d’évaluation, tandis que Techstack rend l’expertise organisationnelle récupérable et évalue automatiquement les réponses obtenues. Les deux approches transforment des entrées auparavant implicites ou des comportements variables en sujets d’ingénierie pouvant être observés et testés, même si elles traitent de parties différentes du système de delivery.

Les rôles Scrum demeurent, mais leur effet de levier se déplace vers la conception de la justesse

Une fois que le contexte et la vérification deviennent des artefacts d’ingénierie, les Product Owners gagnent en levier plus tôt dans le delivery. La définition des objectifs et la priorisation déterminent où va l’effort d’implémentation généré rapidement, tandis que les critères d’acceptation déterminent sur quoi un agent sera évalué. À mesure que le temps d’implémentation diminue, la question la plus déterminante pour le Product Owner devient : « avons-nous décrit la bonne chose ? »

Cette focalisation en amont modifie l’endroit où les ingénieurs seniors appliquent leur jugement. Leur travail inclut de plus en plus les spécifications, contrats, schémas, test harnesses, critères d’évaluation, frontières d’intégration et revue architecturale. La production de code applicatif reste une partie du delivery, tandis que le jugement d’ingénierie se concentre sur la définition de la justesse et sur la décision de savoir si une sortie localement réussie a sa place dans le système global.

Le même changement donne aux Scrum Masters des signaux de processus supplémentaires à inspecter. « avons-nous terminé le sprint ? » reste important, mais l’achèvement seul ne peut pas révéler si l’augmentation de la sortie des agents crée une contrainte cachée dans le delivery. Les questions supplémentaires sont « les portes comportementales sont-elles franchies ? La capacité de vérification suit-elle le rythme de la génération ? » car ces signaux révèlent si une vitesse de production plus élevée produit un travail publiable ou augmente le volume de travail en attente de contrôle.

Ces signaux donnent aux rétrospectives de nouveaux modes d’échec à examiner sans en changer la finalité de base. Une équipe peut inspecter la dérive des spécifications, la dette de vérification, les lacunes de couverture et l’architecture non documentée, puis modifier l’incrément suivant en fonction de ce qu’elle constate. L’inspection et l’adaptation continuent d’opérer parce que les équipes disposent désormais d’artefacts d’ingénierie et de contraintes de delivery supplémentaires à inspecter.

À mesure que ces rôles évoluent, la responsabilité humaine se concentre autour des frontières dont dépend l’exécution autonome : cadrage du problème, points d’intégration, gestion du changement, incidents de production, contrats, tests et évaluations, et jugement architectural. Scrum fournit des points réguliers où les équipes peuvent revoir ces décisions. L’ingénierie agentique modifie ce que les personnes participant à ces points doivent concevoir.

Le gain de productivité crée un risque sur les compétences des ingénieurs juniors que Scrum ne peut pas résoudre à lui seul

Cette concentration du jugement crée un problème pour les ingénieurs juniors en matière de développement des compétences. Un ingénieur incapable de lire avec compétence le code produit par un agent ne peut pas identifier de manière fiable les erreurs dans ce code. La vérification dépend donc d’une compréhension suffisante de l’ingénierie pour reconnaître les cas où des contrôles locaux réussis masquent malgré tout un problème structurel, d’intégration ou de maintenabilité.

Le problème de compétences peut s’aggraver lorsque l’automatisation supprime une partie de l’activité de production de code par laquelle les ingénieurs juniors ont traditionnellement développé le jugement qu’on attend ensuite d’eux dans les travaux de revue et de vérification. Les équipes se retrouvent alors face à une tension entre productivité immédiate et développement des compétences à plus long terme. Le framework d’inspection et d’adaptation de Scrum ne précise pas en lui-même comment les ingénieurs acquièrent le jugement technique nécessaire pour inspecter un travail autonome.

La conclusion qui en résulte concerne donc la formation des compétences plutôt qu’une prévision de déplacement des profils débutants. Les éléments disponibles établissent un risque d’écart de compétences sans établir combien d’ingénieurs juniors y seront confrontés, comment le marché du travail réagira ni quel workflow de formation de remplacement émergera. Les équipes qui adoptent des agents doivent toujours faire face à l’exigence sous-jacente : la capacité future de vérification dépend du fait que des personnes développent un jugement d’ingénierie suffisant pour savoir quand un logiciel généré est erroné.

Points clés

• Préserver la boucle de contrôle de Scrum : Le rythme des sprints, le Product Ownership, les rétrospectives, l’inspection et l’adaptation restent utiles à mesure que les agents prennent en charge davantage de travail de delivery. Les responsables du delivery peuvent utiliser des incréments bornés et des points de contrôle fréquents pour contenir le risque d’intégration et corriger tôt le comportement des agents.
• Concevoir le contexte tacite : L’exécution autonome exige des critères d’acceptation, des contrats, des schémas, des cas limites et des décisions architecturales sous une forme accessible à la machine. Les équipes produit et ingénierie peuvent renforcer la Definition of Ready afin que les agents reçoivent le contexte nécessaire à une exécution fiable.
• Faire évoluer la vérification au rythme de la génération : Le débit des agents ne crée de valeur que si la capacité de vérification suit. Les équipes plateforme et ingénierie peuvent ajouter des évaluations comportementales, des tests de régression, des approval gates, de l’observabilité et des contrôles de rollback, tout en réservant le jugement humain à l’architecture et à une justesse plus large.
• Traiter la connaissance organisationnelle comme une infrastructure : Les agents dépendent d’une connaissance récupérable et à jour de l’architecture, des règles métier et des décisions passées. Les responsables de la connaissance et de la plateforme peuvent versionner ces entrées et benchmarker la qualité du retrieval afin que le contexte peu fiable devienne mesurable.
• Déplacer l’effort d’ingénierie vers la définition de la justesse : Les Product Owners gagnent en levier grâce à des résultats précis et à des critères d’acceptation, tandis que les ingénieurs seniors façonnent de plus en plus les contrats, les critères d’évaluation, les frontières d’intégration et l’architecture. Les Scrum Masters peuvent suivre la capacité de vérification, la dérive des spécifications et les lacunes de couverture en parallèle de l’achèvement des sprints.
• Protéger le développement des compétences des juniors : Une automatisation accrue peut supprimer le travail de codage qui aide traditionnellement les ingénieurs juniors à développer le jugement nécessaire pour revoir les logiciels générés. Les managers d’ingénierie peuvent mettre en place des pratiques délibérées d’apprentissage et de revue qui développent les compétences de lecture de code, de débogage, d’intégration et de raisonnement architectural.