Un message Slack a vibré dans ma poche un mardi soir, 23h34, fin avril. Un ami qui dirige l'ingénierie de plateforme dans une fintech de Montréal venait de présenter à son conseil un « stack SDLC agentique » : agent de planification, agent de codage, agent de tests, agent de déploiement. Six pull requests livrées en un après-midi, toutes vertes. Son message disait : « C'est fou. Pis je suis terrifié. »
Bon. Voici une opinion qui dérange, après 25 ans à livrer du logiciel d'entreprise. Le SDLC agentique, celui que PwC, IBM et Deloitte appellent tous le mouvement déterminant de 2026, est bien réel. Ça marche. Et ça s'en va amplifier chaque problème d'exigences que votre boîte tolère silencieusement depuis le jour de sa fondation. Pas régler. Amplifier.
Trois chiffres, après je sors de la partie statistique. Selon le rapport PwC 2026 « Agentic SDLC in practice », 70 % des équipes logicielles utilisent maintenant l'IA générative à un niveau modéré à élevé, et les équipes Pionnières livrent environ 74 versions par année. Les transformations numériques ratées coûteraient maintenant à l'économie mondiale environ 2,3 billions de dollars par année. Et en 2026, environ 70 % des initiatives de transformation n'atteignent toujours pas leurs objectifs. On s'apprête à verser des agents autonomes par-dessus le deuxième chiffre tout en applaudissant le premier. Moi non plus, je ne trouve pas ça réconfortant.
Le SDLC agentique selon PwC, c'est quoi au juste?
Un SDLC agentique veut dire des agents IA autonomes qui gèrent plusieurs étapes de la livraison logicielle (planification, conception, code, tests, déploiement, ops) avec un minimum d'intervention humaine entre les étapes. Version courte. PwC divise les équipes en trois : Pionnières (GenAI dans six étapes ou plus), Adoptantes, et Observatrices (zéro ou une étape). Les Pionnières atteignent ce fameux rythme de 74 versions par année, et on présente leur cadence comme le nouveau benchmark que chaque CTO doit poursuivre.
IBM livre l'exemple d'entreprise le plus visible. À Think 2026, la compagnie a annoncé que plus de 80 000 de ses propres employés (plus du quart de son effectif) utilisent maintenant un agent interne appelé Bob, avec un gain de productivité moyen rapporté de 45 % sur les tâches du cycle de développement. Bob écrit du code, exécute des tests, ouvre des pull requests, parle à d'autres Bob. Et Deloitte ajoute le chiffre côté demande : 25 % des entreprises qui utilisent la GenAI devraient déployer des agents en 2025, et ce chiffre devrait grimper à 50 % d'ici 2027. Donc ce n'est pas hypothétique. C'est une vague.
Voici la partie que les decks de présentation oublient. Tous ces agents en aval de « l'Étape 1 : Exigences » exécutent ce qu'un humain (ou un autre agent) a déposé dans la spec. Cette poignée de main est cassée depuis la première fois qu'un analyste d'affaires s'est assis devant un architecte logiciel, dans un bureau de la rue Saint-Laurent en 1998, pour découvrir que les deux avaient en tête trois modèles mentaux différents de la même fonctionnalité. La livraison agentique ne règle pas ça. Elle roule juste plus vite en aval.
Pourquoi la génération rapide de PRD ne sauvera pas votre SDLC agentique
C'est ici que je m'attends à du désaccord, y compris de la part de gens que j'estime. Des outils comme Eltegra.ai proposent une réponse propre : réduire de 75 % le temps de création d'un PRD, générer le document complet à partir d'une conversation, puis envoyer ces PRD dans le pipeline agentique. Je vais accorder un point à Eltegra tout de suite : leur travail de cartographie de la conformité (HIPAA, ISO 26262, et le reste) est franchement utile, surtout pour des équipes sans expertise réglementaire à l'interne. Donc ce n'est pas une attaque gratuite contre un concurrent.
C'est plutôt mon argument qu'ils règlent le mauvais goulot. La partie lente d'une exigence, ça n'a jamais été la frappe au clavier. N'importe qui qui a déjà regardé un analyste d'affaires sénior rédiger une spec sait que le document se tape en quatre heures, après douze semaines de conversations, trois rencontres qui ont mal fini, deux parties prenantes qui ne s'entendent pas sur ce que « temps réel » veut dire, et un product owner qui présume tranquillement que le système va s'intégrer à un ERP legacy dont personne n'a parlé aux architectes. Douze semaines. Quatre heures. Le goulot, c'était la découverte, pas la documentation.
Générer un PRD bien tourné en 30 minutes à partir d'un mémo vocal de 90 secondes, ça ne comprime pas ces douze semaines. Ça les cache. Le PRD a l'air complet parce que le modèle de langage est franchement excellent pour faire avoir l'air complet. Titres, critères d'acceptation, cas limites, drapeaux de conformité, tout est joliment placé. Mais les hypothèses cachées sont encore cachées. Sauf qu'elles sont maintenant cachées à l'intérieur d'un document que tout le monde dans la salle approuve d'un hochement de tête, parce qu'il est propre, structuré et confiant. Ensuite, un pipeline agentique le ramasse et le livre. À 74 versions par année. Sur plusieurs fonctionnalités en parallèle. Sans jamais poser la question que l'architecte original aurait posée autour d'un café : « Attends, qu'est-ce que tu veux dire au juste par temps réel? »
Je disais plus tôt que c'était contrarien. Honnêtement, plus je l'écris, plus ça me semble évident. Plus de débit en aval d'un problème non résolu, ça multiplie le problème. C'est vrai en manufacture, c'est vrai dans les compilateurs, c'est vrai dans le journalisme, c'est vrai ici. Le pitch d'accélération des PRD prend la lunette par le mauvais bout.
L'ambiguïté à grande échelle, c'est différent comment?
L'ancien SDLC avait une valve de sécurité intégrée. C'était le dev qui lisait la spec. Quand un humain tombait sur une exigence vague, il faisait ce que font les humains : il s'arrêtait, ouvrait Slack, et demandait au PM ce que la spec voulait vraiment dire. Cette micro-friction (achalante, lente, coûteuse) jouait un rôle de filtre. Elle attrapait probablement 40 % des mauvaises hypothèses avant qu'elles deviennent du mauvais code.
Les agents ne s'arrêtent pas. C'est le pitch au complet. Ils livrent.
Ce que prouve vraiment le succès d'AtlantiCare
Je veux prendre au sérieux un cas réel de succès agentique, parce que le scénario optimiste n'est pas de la fiction. AtlantiCare, un réseau de santé du New Jersey, a déployé Oracle Health Clinical AI Agent pour la génération ambiante de notes cliniques. Dans les données publiées par Oracle, 80 % des fournisseurs qui ont testé l'outil l'ont adopté. Le temps de documentation a chuté de 41 %, ce qui représente environ 66 minutes économisées par fournisseur, par jour. Ce ne sont pas des chiffres marketing. Ce sont des résultats mesurés dans un réseau hospitalier qui a désespérément besoin de moins de paperasse.
Lisez ces chiffres d'AtlantiCare attentivement. Le fournisseur entre dans une salle. Un patient décrit un symptôme. L'agent transcrit la conversation et produit une note SOAP : Subjectif, Objectif, Évaluation, Plan. Cet acronyme de quatre lettres est l'épine dorsale structurelle de la documentation clinique depuis que le Dr Lawrence Weed l'a standardisé dans les années 1960. Soixante ans de convention. Des décennies de données d'entraînement. Un format d'entrée clair, bien borné, que chaque clinicien d'Amérique du Nord connaît déjà.
Autrement dit : les exigences étaient déjà réglées. L'agent n'a pas eu à inventer ce que « une bonne documentation » veut dire. La profession médicale a répondu à cette question en 1968 et la réponse n'a pas beaucoup dérivé depuis. L'agent d'Oracle fait un travail brillant, oui, mais sur un problème dont l'amont est exceptionnellement propre.
Les exigences logicielles ne commencent presque jamais comme ça. Demandez à trois product owners ce que « une bonne expérience d'onboarding » veut dire, et vous allez recevoir cinq réponses, dont deux contredisent les trois autres. Il n'existe pas d'équivalent SOAP pour « le système doit être intuitif ». C'est exactement la zone que le scénario optimiste évacue tranquillement.
Donc quand quelqu'un pointe AtlantiCare et déclare « l'IA agentique fonctionne à l'échelle », je suis d'accord. Avec une nuance. Ça fonctionne quand l'amont est structuré. Verse la même énergie agentique sur une demande de fonctionnalité typique d'entreprise (« on veut un portail client moderne et libre-service »), et tu vas obtenir un portail. Peut-être plusieurs portails. Aucun ne sera ce que quelqu'un voulait vraiment, parce que le brief original était un test de Rorschach, pas une spécification.
Que faire en 2026 si le SDLC agentique est réel?
Je ne suis pas anti-agent. Que ce soit clair avant que quelqu'un sorte une phrase de son contexte. Specira utilise l'IA de façon massive et je pense que le virage agentique est un des changements architecturaux les plus importants de ma carrière. Mais l'ordre de déploiement compte, et là, la plupart des équipes l'ont à l'envers.
Trois choses, dans cet ordre :
1. Auditez votre processus de découverte des exigences avant d'adopter quoi que ce soit. C'est la partie que personne ne met sur un Gantt. Passez deux semaines à observer comment votre équipe passe vraiment de « on veut une affaire » à « le dev code l'affaire ». Où est-ce que les hypothèses s'infiltrent? C'est qui, la personne goulot d'étranglement qui répond à toutes les questions de désambiguïsation? Quand cette personne est en vacances, qu'est-ce qui casse? Cartographiez ça. Écrivez-le. Montrez-le à votre CFO. La plupart des équipes découvrent que leur processus de découverte tient avec un ou deux séniors et environ six cents conventions non écrites.
2. Décidez quelles décisions les agents ne peuvent pas prendre. Pas « ne devraient pas ». « Ne peuvent pas ». Il y a une différence. Compromis de prix, frontières de sécurité, interprétation réglementaire, langage contractuel client : ces choses-là appartiennent aux humains, point final. Faites la liste. Défendez-la quand quelqu'un voudra effacer un item au trimestre prochain, parce que quelqu'un va essayer. Une fois que la frontière est réelle, le reste du pipeline peut tourner agentiquement sans empêcher personne de dormir.
3. Ensuite, déployez les agents en aval de ces points de décision. C'est la partie qui m'enthousiasme vraiment. Une pile agentique qui commence avec des exigences structurées, validées, ancrées dans l'humain, c'est un avantage structurel. Une équipe Pionnière au sens de PwC, mais avec l'amont effectivement réglé. La plupart des compagnies qui adoptent le SDLC agentique en 2026 font l'étape trois sans faire les étapes un et deux. Celles qui inversent cet ordre vont manger discrètement le reste du marché au cours des trois prochaines années.
La vraie occasion du SDLC agentique
L'histoire que les analystes racontent à propos de 2026, c'est « les agents sont le nouveau briseur de goulots ». L'histoire que votre équipe ops va raconter en 2027 dépend de si vous avez réglé l'Étape 1 avant d'accélérer les Étapes 2 à 6. Mêmes outils agentiques. Résultats radicalement différents.
C'est le fil rouge qui traverse nos autres textes sur l'intelligence des exigences, les agents IA et les bonnes questions, et la règle du 29x. Les agents ne remplacent pas la pensée. Ils amplifient ce qui a été pensé avant qu'on les lâche dans la nature.
Quelles sont les questions les plus fréquentes sur le SDLC agentique et les exigences?
