David était analyste d'affaires depuis onze ans quand son directeur l'a pris à part après le standup du mardi. La boîte venait d'acheter un nouvel outil d'IA flambant neuf, le genre qui rédige des user stories à partir d'une transcription, et le plan était de couper deux postes d'analyste pour le payer. David n'était pas un des deux. C'était lui qu'on chargeait de faire marcher l'outil. Fait que il lui a donné les notes des parties prenantes, l'a regardé sortir quarante user stories propres en quelques minutes, et il s'est dit, honnêtement, que son directeur avait peut-être raison. Puis la spec a été livrée. Trois semaines plus tard, les opérations étaient en cellule de crise, parce que l'outil avait bâti exactement ce que le prompt décrivait et rien de ce dont le plancher de l'entrepôt avait vraiment besoin. Le trou n'était pas dans le code. Il était dans une conversation qui n'a jamais eu lieu.
C'est ça, la vraie histoire de l'IA et de l'analyste d'affaires. Pas celle des manchettes. La manchette dit remplacement. La réalité dit séparation. La job a toujours eu deux moitiés, et la plupart d'entre nous n'en voyaient qu'une.
L'IA va-t-elle remplacer votre analyste d'affaires?
Non. Elle remplace la moitié documentation de la job, pas l'analyste qui la fait. La façon plus nette de le dire: l'IA est maintenant très bonne pour écrire les exigences et vraiment poche pour les découvrir. Ce sont deux compétences différentes qui ont vécu dans un même titre de poste pendant trente ans, et on les a confondues parce que la même personne faisait les deux. Les outils rapportent aujourd'hui l'analyse des exigences environ 60% plus vite et des user stories à peu près trois fois plus détaillées (SyncSkills, 2026). Tout vrai. Tout sur la moitié qui n'a jamais été le goulot.
Le goulot, ça a toujours été l'autre moitié. Comprendre ce dont l'opération a vraiment besoin, qui est rarement ce que la partie prenante la plus bruyante dit vouloir. J'ai changé d'idée deux fois en écrivant ça, alors soyons précis. Au début je pensais que l'IA allait réduire la job d'analyste d'environ un tiers. Puis j'ai regardé quelques-uns de ces outils sur le terrain et j'ai réalisé quelque chose de plus étrange: l'IA ne réduit pas la job. Elle expose quelle partie était le vrai travail. La frappe n'a jamais été le travail. Le questionnement, oui.
Quelle partie du travail l'IA automatise-t-elle vraiment?
La moitié mécanique, côté sortie. Transformer une entrevue brouillonne en exigences structurées. Rédiger les critères d'acceptation. Reformater un backlog à minuit pour qu'il soit présentable à neuf heures. Résumer un appel de quarante minutes en six décisions qui comptaient. Attraper le trou évident dans une spec écrite, le champ sans règle de validation, le statut sans transition pour en sortir. L'IA excelle là-dedans, et je veux dire vraiment excelle, le genre d'aide qui redonne des heures par semaine à un analyste. C'est cette partie-là que les gens pointent quand ils disent que le rôle se meurt.
Mais regarde la liste de proche. Chaque item part de quelque chose qui existe déjà: une transcription, un brouillon, un backlog, une spec. L'IA est une deuxième passe phénoménale. Elle restructure, accélère et polit ce qui est déjà sur la table. Ce qu'elle ne peut pas faire, c'est inventer la chose qui n'a jamais été mise sur la table, parce qu'aucun modèle ne peut résumer une conversation que personne n'a eue. L'économie de 60% est réelle. C'est aussi une économie sur la moitié pas chère. La moitié chère, la découverte, n'accélère pas juste parce que l'écriture a accéléré. Pire: quand les équipes empochent le temps sauvé et sautent les entrevues, la moitié chère se dégrade en silence.
L'IA a rendu l'écriture des exigences presque gratuite. Elle n'a rien fait pour leur découverte. Et la découverte, ça a toujours été là où les projets se gagnaient ou se perdaient.
Qu'est-ce qu'un prompt d'une ligne ne pourra jamais faire qu'un humain fait?
Poser la question que personne n'a pensé à écrire. C'est ça, au complet, là, juste là. Un bon analyste entend une partie prenante dire « et là ça s'en va juste à l'expédition » et il s'arrête, parce que le mot « juste » cache trois exceptions et un transfert que deux services tiennent chacun pour acquis que l'autre possède. L'analyste suit la réponse vague jusqu'à ce qu'elle devienne concrète. L'IA accepte « ça s'en va juste à l'expédition » comme une exigence complète et bâtit exactement ça, proprement, avec confiance, croche.
Il y a une deuxième affaire, et elle est encore plus dure à automatiser: remarquer un conflit que personne n'a énoncé. Dans la plupart des sessions de découverte, le vrai risque n'est pas une partie prenante qui n'est pas d'accord tout haut. C'est deux parties prenantes qui s'entendent sur les mots et veulent dire des choses complètement différentes, et qui n'ont jamais été dans la même salle pour s'en rendre compte. Un humain attrape le micro-hésitation, le regard de travers, le « ben, ça dépend ». Un prompt n'attrape rien de tout ça, parce qu'un prompt reçoit les mots et jamais la salle.
Une des exigences les plus chères de l'histoire du logiciel, c'était un seul bouton. Un grand détaillant en ligne forçait les nouveaux acheteurs à s'inscrire avant de pouvoir acheter. La spec était claire, l'exigence était documentée, et tout le monde la respectait. Une IA à qui on aurait donné cette spec aurait bâti le mur d'inscription sans cligner, parce que la spec le disait. L'exigence elle-même était l'erreur, et personne dans l'équipe ne la voyait, parce qu'elle était écrite et donc elle avait l'air vraie.
Ça a pris un travail d'utilisabilité, regarder du vrai monde échouer au paiement, pour faire ressortir l'évidence d'après coup: les acheteurs ne voulaient pas de compte, ils voulaient leur commande. L'équipe a remplacé « S'inscrire » par un bouton « Continuer » et a laissé les gens passer à la caisse comme invités. Les achats ont monté de 45%. C'était 15 millions de dollars de plus le premier mois, et 300 millions de plus sur la première année (Jared Spool, The $300 Million Button).
Aucun prompt n'a demandé ce changement, parce que le prompt aurait été bâti à partir de la spec, et la spec était le problème. Un humain qui regardait la découverte a trouvé une question à 300 millions que personne n'avait écrite. C'est ça, la job. Ça a toujours été ça, la job.
J'ai passé assez de temps dans des salles de découverte au fil de mes 25 ans dans la livraison de logiciels d'entreprise pour te dire que le motif est platement constant. L'exigence qui coule le projet, c'est presque jamais celle dont on débat. C'est celle que tout le monde tenait pour réglée, le « c'est évident que ça marche de même » qui finit par vouloir dire deux affaires incompatibles pour deux équipes. Tu ne trouves pas ça avec un crayon plus rapide. Tu le trouves en étant un humain têtu qui refuse d'accepter « juste » comme réponse.
Comment le rôle de l'analyste d'affaires change-t-il au lieu de disparaître?
Il monte dans la pile: de rédacteur de documents à facilitateur de découverte et orchestrateur d'IA. Pense à la courbe de demande, là. Le sondage CIO 2026 de Gartner a trouvé que seulement 17% des organisations ont vraiment déployé des agents IA, alors que plus de 60% prévoient le faire d'ici deux ans, la courbe d'adoption la plus agressive de toutes les technologies qu'ils ont mesurées (Gartner, CIO Agenda 2026). Lis l'écart. Un déluge d'agents s'en vient, et presque personne ne les a en production. Quelqu'un doit décider ce que tous ces agents sont censés faire, les nourrir d'exigences qui valent la peine d'être bâties, et vérifier leur sortie face à une réalité que les agents n'ont jamais vue.
Fait que l'analyste qui essaie de gagner une course de frappe contre l'IA perd, et il le mérite. L'analyste qui monte d'un cran gagne gros. Facilitateur de découverte: la personne qui mène les conversations structurées qui font ressortir les exceptions, les conflits et les raisons. Orchestrateur d'IA: la personne qui briefe les agents, gouverne ce qui entre, et vérifie ce qui sort avant que ça parte. C'est le même virage qu'on a décrit dans pourquoi les agents IA ont besoin des bonnes questions, pas juste du bon code, et ça pointe vers la même cause de fond qu'on ramène toujours dans vos specs sont le problème, pas vos agents IA. La structure n'a jamais été la partie dure. La découverte, oui.
Qu'est-ce que l'intelligence des exigences donne au nouvel analyste d'affaires?
Une boîte à outils bâtie pour la moitié de la job qui survit. L'intelligence des exigences, c'est de la découverte structurée et multi-experte menée de façon délibérée au lieu de par accident. Au lieu d'espérer qu'un analyste curieux trébuche sur l'exception manquante à la cinquante-cinquième minute d'une entrevue, elle interroge le pourquoi exprès, fait ressortir le conflit entre parties prenantes avant qu'une ligne de code soit écrite, et capture le raisonnement derrière chaque exigence comme un artefact à part entière. Puis elle remet à l'IA un brief qui contient déjà les affaires qu'un prompt d'une ligne aurait sautées.
C'est ce partenariat-là qui marche pour vrai. L'IA rédige les quarante user stories en quatre minutes, et elle devrait, c'est une excellente utilisation de quatre minutes. L'analyste passe le temps sauvé à faire la chose que seul un humain peut: s'asseoir avec le superviseur d'entrepôt, regarder le vrai panier, poser la question à 300 millions. Pour un portrait plus complet de ce qu'est cette couche de découverte et comment elle nourrit les agents, vois ce qu'est vraiment l'intelligence des exigences. Le point, c'est pas l'IA contre l'analyste. C'est l'analyste, qui tient la découverte, qui pointe l'IA vers la vérité.
Arrête de demander si l'IA remplace l'analyste. Demande quelle moitié elle remplace.
L'IA automatise la moitié documentation: exigences plus vite, user stories plus détaillées, backlogs plus propres. Cette moitié était du vrai travail, mais elle n'a jamais été le travail qui décidait si un projet réussissait. La moitié découverte, poser la question non écrite et faire ressortir le conflit que personne n'a énoncé, c'est exactement ce qu'un prompt d'une ligne ne peut pas faire.
Fait que l'analyste qui concurrence l'IA sur la sortie perd. Celui qui monte vers facilitateur de découverte et orchestrateur d'IA devient plus précieux que jamais, parce qu'un déluge d'agents s'en vient et que quelqu'un doit leur dire la vérité. L'intelligence des exigences est la boîte à outils de cette nouvelle job. L'analyste tient la découverte. L'IA fait la frappe. Les deux, enfin, à faire ce pour quoi ils sont vraiment bons.
David a gardé sa job, en passant. Il a arrêté d'essayer de battre l'outil à la rédaction et s'est mis à mener les sessions de découverte que l'outil ne pouvait pas faire. La spec suivante a été livrée sans cellule de crise. Même analyste. Autre moitié de la job. Celle qui était le point depuis le début.
Quelles sont les questions les plus fréquentes sur l'IA et l'analyste d'affaires?
