Un gâteau. Tous les gros programmes de modernisation que j'ai côtoyés finissent par en acheter un, et c'est toujours pour la même sorte d'occasion : après deux ou trois ans à traîner une plateforme plus vieille que la moitié de l'équipe vers quelque chose qui va encore être supporté en 2030, une affaire marche enfin du premier coup. Cette fois-là, l'affaire, c'était l'automatisation. Une demande de changement rentre, et au lieu qu'un analyste passe son mardi à fouiller dans quatre outils pour savoir quelles exigences elle touche, une chaîne les trace, vérifie la couverture de tests, rédige les éléments de travail et sort un sommaire pour la revue. Quelques minutes.
Après ça, douze semaines passent. Une exigence revient, de la même forme que celle qui avait tranquillement fait dérailler la tentative de migration précédente, et personne dans la salle la reconnaît, parce qu'elle arrive pas avec une étiquette d'avertissement. Elle arrive bien faite. Description structurée, critères d'acceptation testables, lien de traçabilité vers la demande de changement qui l'a créée, journal d'audit qui montre exactement qui y a touché et quand, et elle traverse la chaîne dans une fraction du temps que l'ancien processus prenait. Plus vite. C'est la phrase sur laquelle il faut s'asseoir, et rien là-dedans n'est un reproche à l'automatisation.
Qu'est-ce que l'automatisation agentique des exigences règle vraiment?
La taxe de coordination. Le prix est plus gros qu'il en a l'air. Le 18 juin 2026, IBM a publié les notes de version d'Engineering AI Hub 1.3, décrit dans ses propres mots comme une plateforme d'automatisation agentique unifiée et extensible pour IBM Engineering Lifecycle Management, et la liste de fonctionnalités se lit comme un inventaire précis des endroits où les grandes organisations d'ingénierie perdent leurs semaines. Un point d'accès Model Context Protocol géré donne un accès gouverné aux données du cycle de vie. La prise en charge d'agents conformes à A2A permet aux agents d'IBM de participer à des flux multiagents sur mesure bâtis sur des standards ouverts. Amazon Bedrock rejoint watsonx.ai dans la liste des fournisseurs approuvés, et la plateforme se déploie maintenant sur Kubernetes CNCF et dans des installations coupées du réseau, ce qui a l'air d'une note de bas de page jusqu'au moment où votre programme de modernisation vit dans l'aérospatiale, la défense ou le matériel médical.
L'exemple donné par IBM vaut la peine d'être cité, parce que c'est exactement le travail qui gruge les analystes. Un flux multiagent peut « évaluer une demande de changement, repérer les exigences liées, examiner les éléments de travail touchés, vérifier la couverture de tests et préparer un sommaire pour la revue d'ingénierie » (traduction libre), d'un seul coup. N'importe qui qui a monté ça à la main, dans quatre systèmes plus une page Confluence modifiée pour la dernière fois en 2019, sait ce que ça vaut. Ça vaut cher. L'agent de rédaction d'éléments de travail en dessous est arrivé avant, annoncé le 19 février 2026 avec une disponibilité générale prévue le 26 mars, et il rédige des ébauches d'épopées, de fonctionnalités et de récits utilisateur directement dans l'interface Engineering Workflow Management. La version 1.3 le prolonge : on peut personnaliser les invites et obtenir des ébauches dans le langage de la maison plutôt que dans un langage générique.
Soyons clairs, parce que le reste de l'article va compliquer l'affaire. C'est de la bonne infrastructure, bâtie par du monde qui comprend visiblement l'ingénierie réglementée, et IBM reste prudent sur ce qu'il promet : « Engineers remain in control, while agents reduce the manual effort required to gather, connect and interpret lifecycle information. » Autrement dit : rassembler, relier, interpréter. Lisez les verbes. Aucun ne veut dire décider, et IBM ne prétend pas le contraire, ce qui est pas mal plus de discipline que le reste du marché en montre.
Plus de 65 %
des équipes d'ingénierie qui utilisent le codage agentique traiteront leur environnement de développement intégré comme optionnel d'ici 2027, « shifting control, governance and validation to automated platforms », selon Gartner. Notez deux affaires : c'est une prédiction, pas une mesure, et regardez où la validation est censée s'en aller. Sur la plateforme. Une plateforme peut valider bien des choses. La véracité d'une exigence n'en fait pas partie.
Source : communiqué Gartner, Gartner Says the Market for Enterprise AI Coding Agents Is Entering a New Phase of Expansion and Competitive Realignment, Stamford, 20 mai 2026, citant l'analyste principal Philip Walsh. Prédiction, pas des données de sondage.
Pourquoi les programmes de modernisation échouent encore, même quand l'automatisation mûrit?
Parce que la contrainte n'a jamais été le débit. Ça fait vingt ans que les programmes de modernisation reçoivent du meilleur outillage chaque année, meilleur contrôle de version et meilleurs pipelines et meilleurs cadres de test et meilleure traçabilité et meilleur tout, et la distribution des résultats est restée remarquablement indifférente à toute la parade. Autre chose les tue. C'est habituellement une décision que personne n'arrivait à énoncer précisément, prise par du monde qui n'a jamais eu trente minutes avec la seule personne qui savait pourquoi l'ancien système se comportait de même, puis exécutée avec une vraie compétence.
On a fait une première version de cet argument en juillet : le cycle de développement agentique est arrivé pas mal plus vite que les exigences qui l'alimentent se sont améliorées. La modernisation d'un système légué, c'est le cas extrême de cet écart, parce qu'un vieux système, c'est vingt ans de sédiments, et les raisons derrière la plupart sont sorties de la bâtisse avec le monde qui a pris les décisions. Le code n'est pas l'exigence. Le code, c'est ce que quelqu'un a fait avec une exigence en 2004, façonné par les contraintes de 2004, patché en 2011 par un consultant dont personne ne se rappelle le nom, et il n'y a aucun moyen fiable de relire l'intention là-dedans. Le comportement se lit. L'intention, c'est une autre matière, et elle vit dans des conversations.
Sur le terrain
Le Québec a passé un an et demi à examiner un de ces programmes en public, sous serment, et la transcription est instructive pour quiconque s'apprête à industrialiser une chaîne de modernisation. La Commission d'enquête sur la gestion de la modernisation des systèmes informatiques de la Société de l'assurance automobile du Québec, présidée par le juge Denis Gallant, a été créée le 24 mars 2025 avec le mandat d'identifier les causes et circonstances des problèmes de gestion et de réalisation du programme CASA, l'effort de modernisation derrière la plateforme SAAQclic, tels que constatés par la Vérificatrice générale du Québec. Elle a siégé 75 jours d'audience entre le 24 avril et le 24 octobre 2025 et entendu 129 témoins. Un seul programme. Le rapport a été publié le 16 février 2026. Dans sa couverture, Le Devoir rapporte que le virage numérique a été jugé « trop vaste, trop ambitieux », et le remède structurel de la commission est la partie à copier : parmi 26 recommandations, elle propose une entité centralisée en transformation numérique de l'État dont les organismes publics devraient obtenir l'avis avant tout projet d'envergure, et elle recommande de favoriser de plus petits projets, plafonnés sous les 50 millions de dollars. Lisez ça comme une recommandation d'ingénierie, pas comme une recommandation politique. La réponse de la commission à un programme trop gros pour être compris, ce n'est pas du meilleur outillage. C'est des morceaux de travail assez petits pour qu'un humain les tienne encore dans sa tête le temps de les vérifier.
Sources : Commission d'enquête sur la gestion de la modernisation des systèmes informatiques de la SAAQ (mandat, dates d'audience, 129 témoins, 75 jours d'audience, rapport publié le 16 février 2026) et la couverture des 26 recommandations par Le Devoir, 16 février 2026. Secteur public, Québec.
Avant, je lisais ces cas-là comme des échecs de gouvernance, point final, et j'avais tort en partie. La gouvernance était dans le portrait. Ça, oui. Mais la gouvernance, c'est un système pour s'assurer que les décisions sont consignées et escaladées, et ça ne dit strictement rien sur la justesse de la décision au moment où quelqu'un l'a prise, ce qui veut dire qu'un programme peut être gouverné de façon impeccable et bâtir la mauvaise affaire à pleine vitesse. Ajouter des agents là-dedans ne change pas la direction. Ça change la vitesse, et le journal d'audit devient bien meilleur pour documenter exactement comment on s'est rendu là.
Quelle est la seule question que l'automatisation ne peut pas trancher?
Ça devrait-tu être vrai? C'est toute la question, et écrite de même elle a l'air tellement simple qu'on manque son poids : pas si l'exigence est bien formulée, pas si elle est traçable, pas si elle est testable, mais si la prétention dedans décrit fidèlement ce dont cette entreprise a besoin, et qui dans la bâtisse s'y opposerait si on la lui mettait devant les yeux.
Un agent peut faire énormément avec cette exigence une fois qu'elle existe. Il peut sortir les exigences liées, signaler les conflits avec tout ce qui est déjà dans le dépôt, repérer le critère d'acceptation manquant, vérifier si un test la couvre, et il va faire ça plus régulièrement à 16 h un vendredi que n'importe quel humain fatigué. Du vrai travail utile. Ce qu'il ne peut pas faire, c'est descendre deux étages et découvrir que la règle que tout le monde cite comme une obligation réglementaire est en fait un contournement inventé en 2009 pour un système décommissionné en 2014, gardé en vie depuis parce que la remettre en question n'a jamais été la job de personne. Ce fait-là existe à une seule place, dans la tête de quelqu'un, et un tuyau gouverné vers votre dépôt d'exigences va récupérer tout sauf ce que personne n'a écrit.
40 % contre 23 %
Les praticiens tracent déjà la ligne eux-mêmes. Dans le sondage BMC Mainframe 2026, 40 % accepteraient que l'intelligence artificielle recommande une action de gestion de code, alors que seulement 23 % la laisseraient l'exécuter, et on retrouve la même forme pour les réorganisations de bases de données : 43 % veulent une recommandation, 21 % sont à l'aise de laisser le système la réaliser. Pas de la technophobie. C'est une distinction de travail entre l'analyse et le jugement, tenue par du monde qui fait rouler ces systèmes pour vivre.
Source : BMC Software, Trust Powers AI on the Mainframe, 1er septembre 2026, rapportant le sondage BMC Mainframe annuel : plus de 1 300 praticiens et décideurs mainframe dans le monde, sondés du 24 mars au 20 avril 2026. Sondage mené par un fournisseur; BMC vend des logiciels d'automatisation mainframe.
Où la validation des exigences doit-elle se placer par rapport à une chaîne agentique?
En amont, structurellement, avant que le premier élément de travail existe. La plupart des programmes traitent la validation comme une étape de revue, ce qui la place après que l'exigence a déjà été écrite, présentée, estimée et à moitié engagée, et rendu là, la question honnête est devenue socialement chère à poser. Trop tard. La validation appartient au moment où la prétention est encore pas chère à perdre, et le test pratique se fait cette semaine. Prenez cinq exigences de votre carnet actuel. Pour chacune, répondez à trois questions :
- Quelle personne nommée a confirmé cette exigence?
- À quoi, précisément, l'a-t-on invitée à s'opposer?
- Si elle avait dit non, est-ce que quelque chose en aval aurait changé?
Comptez. Si vous ne pouvez pas répondre aux trois pour au moins quatre exigences sur cinq, l'étape de validation n'existe pas encore dans votre processus, peu importe ce que le diagramme sur le mur raconte.
La mécanique est moins évidente que le principe. Un analyste qui interviewe une partie prenante produit un cadrage, filtré par ce que cet analyste croyait déjà en entrant dans la salle, et c'est exactement comme ça qu'un contournement se retrouve consigné comme règle d'affaires et qu'une contrainte réglementaire dure se retrouve consignée comme une préférence. Une passe, un biais. Plusieurs spécialistes qui interrogent les mêmes entrevues, les mêmes billets et les mêmes politiques depuis des positions expertes volontairement différentes produisent quelque chose de plus solide, parce que leurs questions se rentrent dedans, et les collisions sont l'endroit où une hypothèse jamais dite finit par sortir. Specira fait rouler cinq agents sur ce matériel : quatre analystes qui le travaillent sous des angles distincts, plus un Red Team Critic dont la seule job est d'attaquer ce que les quatre autres ont produit. C'est le produit que je bâtis, alors pesez le pitch en conséquence et jugez le mécanisme plutôt que la marque. Le critique, c'est la pièce qui compte pour cet argument, parce que c'est celle qui demande pourquoi une règle existe plutôt que si la règle est bien écrite.
Après ça, automatisez tout ce qui est en aval, à fond, avec la plateforme que votre organisation a standardisée. Ce n'est pas un plaidoyer sentimental pour garder des humains dans la boucle, et ce n'est pas l'argument voulant que l'analyste d'affaires est à l'abri parce que les machines ne peuvent pas faire le travail. Les machines peuvent en faire une grosse partie. Elles devraient. La portion qui ne s'automatise pas est plus petite que le monde pense et plus importante que les budgets le reflètent : décider, avec une vraie partie prenante dans la salle, si l'affaire que vous vous apprêtez à bâtir à la vitesse de la machine vaut la peine d'être bâtie.
À retenir
L'automatisation agentique des exigences, c'est de la vraie infrastructure, et les gros programmes de modernisation devraient l'adopter, parce que la taxe de coordination qu'elle enlève est énorme et complètement inutile. Remarque ce qu'elle déplace. Et ce qu'elle ne déplace pas. Elle industrialise tout ce qui arrive à une exigence après que quelqu'un l'a affirmée, et n'affirme rien sur la vérification de cette affirmation, ce qui veut dire qu'une exigence non validée dans une chaîne agentique bien gouvernée ne devient pas plus sûre. Elle devient plus rapide, mieux documentée, et pas mal plus dure à remettre en question.
Qu'est-ce qui doit arriver à une exigence avant qu'elle entre dans un pipeline automatisé?
La validation, d'abord. Le planificateur, c'est l'endroit le moins cher pour le découvrir, il renvoie les sections de charte qui ont aucun objectif et aucune contrainte dedans, une liste qu'une plateforme d'automatisation générera jamais parce qu'elle voit juste ce que vous lui avez déjà donné. La découverte referme ces trous avec cinq agents sur la même conversation. Les intégrations poussent ensuite la version validée en aval et le paquet d'export transporte les livrables, regroupés par l'agent responsable de chacun, vers la suite du pipeline.
Ce que vous voyez. Le planificateur, c'est la vérification qui arrive avant le pipeline, les intégrations, c'est là que l'exigence validée y entre, et le paquet d'export, c'est l'ensemble de livrables qui en sort.
Apportez une exigence du carnet de modernisation que vous allez automatiser. On vous montre ce que le pipeline aurait supposé.
Réserver une démoÉcrans tirés d'un espace de démonstration Specira; compteurs et scores sont des données d'exemple.
Quelles sont les questions les plus fréquentes sur l'automatisation agentique en modernisation?
