Vos agents IA ont un serveur MCP. Ont-ils les bonnes exigences?

L'agent avait tout ce qu'il fallait. Accès en lecture au ticket, aux cas de test liés, à l'epic parent, aux critères d'acceptation, le tout livré par un pipe MCP propre en quelques centaines de millisecondes. Il a généré le module en quatre minutes, et le module était bon: typé, testé, documenté, conforme à chaque ligne du ticket qu'on lui avait pointé. Le ticket était mauvais. Trois personnes dans l'édifice auraient pu le dire en une phrase, et personne ne leur avait demandé.

C'est la forme du problème que personne ne chiffre encore, maintenant qu'un serveur MCP peut livrer vos exigences à un agent sur demande. Pas l'accès. Pas la latence. Pas la capacité du modèle à lire un référentiel d'exigences, parce qu'il en est évidemment capable, et la plomberie qui lui permet de le faire proprement est une vraie avancée d'ingénierie qui mérite l'attention qu'elle reçoit. La question en dessous est plus plate et pas mal plus chère: est-ce que la chose qu'il a lue méritait d'être exécutée?

C'est quoi, un serveur MCP pour les exigences?

Une prise standard. Le Model Context Protocol donne à un agent une façon structurée et permissionnée de lire les données d'un système sans que quelqu'un code une intégration sur mesure pour chaque outil, et les plateformes d'exigences ont commencé à livrer leurs propres serveurs. Jama Software a annoncé le sien le 4 mai 2026, en décrivant Jama Connect comme le premier logiciel de gestion d'ingénierie à livrer un serveur MCP. C'est un vrai jalon et il faut le dire clairement.

Lisez leur annonce comme il faut, par exemple. La portée de l'affirmation est étonnamment honnête. Le serveur, dans leurs mots, applique les permissions existantes, les flux de cycle de vie et les exigences d'audit, ce qui maintient la gouvernance de l'IA et la conformité réglementaire. Permissions. Flux. Audit. Chacun de ces mots dit qui a le droit d'atteindre quoi, et ce qui est enregistré quand il le fait, et aucun ne dit si l'exigence au bout du pipe décrit quelque chose que l'entreprise veut vraiment.

Je veux être prudent ici, parce que c'est exactement là que l'argument dérape d'habitude et vire en attaque facile contre un fournisseur. Jama a bien fait. Un pipe gouverné vaut mieux que le pipe improvisé avec un jeton personnel et un script de fin de semaine, et le fait qu'un fournisseur sérieux ait limité sa promesse à l'accès plutôt que de sur-promettre la justesse, ça révèle une équipe produit mature, pas un trou dans le produit.

Regardez ce que cette deuxième phrase décrit. Les permissions par rôle et la journalisation d'audit répondent toutes les deux à la question « qui a touché à ça, et avait-il le droit ». Bonnes réponses. C'est aussi, ensemble, toute la posture de sécurité d'une grande partie du marché, ce qui veut dire que l'industrie s'est entendue tranquillement sur l'idée que le risque de brancher un agent sur les données d'entreprise est un risque de portée.

Est-ce que l'accès rend les exigences meilleures?

Non. Il les rend plus rapides à exécuter, ce qui est une autre propriété qui a l'air de la même quand la démo va bien.

Pensez à ce qui change vraiment au moment où la prise est branchée. Avant, un développeur lisait un ticket mal écrit, sentait un doute quelque part vers le troisième critère d'acceptation, et allait voir quelqu'un, et cette marche-là était un contrôle qualité non budgété sur lequel l'organisation s'appuyait depuis des années sans jamais l'écrire nulle part. Après, l'agent lit le même ticket, n'a aucun doute, et livre. La vitesse a monté. Le doute est tombé à zéro. Une seule de ces deux affaires est une bonne nouvelle.

L'économie de ça n'est pas subtile. Une exigence fautive coûtait un après-midi de développeur avant que quelqu'un l'attrape, parce que le débit était limité par la vitesse de frappe des humains et par la fréquence à laquelle ils s'interrompaient pour se valider entre eux. Maintenant elle coûte une implémentation complète, testée, documentée, de la mauvaise affaire, livrée avant que personne ait eu le temps de la lire. Même défaut. Rayon d'explosion différent.

Un déploiement à 97 % et une valeur à 23 %, c'est un écart dans lequel on fait passer un cycle budgétaire au complet. Et les chiffres de supervision en dessous, ce sont ceux que je mettrais devant un conseil: plus du tiers des dirigeants n'ont aucun plan formel pour superviser les agents qu'ils ont déjà déployés, ce qui n'est pas un problème de technologie mais de gouvernance, arrivé plus vite que l'organigramme pouvait l'absorber.

Où est-ce que MCP aide, et où est-ce qu'il n'aide pas?

Il aide énormément sur une catégorie de douleur précise et bien réelle. Contexte périmé, dérive de copier-coller entre un ticket et un prompt, agents qui hallucinent une exigence parce que personne ne leur a donné la vraie, traçabilité qui se défait dès que le travail sort de l'outil de référence. Ce sont de vrais échecs et un protocole gouverné les règle comme il faut, ce qui explique la vitesse d'adoption: 26 % des organisations logicielles rapportent MCP en production limitée et 19 % de plus en production large, dans le même sondage Stacklok. La plomberie marche.

Voici la frontière honnête. MCP est une couche de transport et de permission. Elle répond à « est-ce que cet agent peut lire cet artefact, sous quelle autorité, et est-ce que c'est enregistré ». Elle ne répond pas, et n'a jamais été conçue pour répondre, à « est-ce que cet artefact est une description juste et complète de ce dont l'entreprise a besoin ». Deux questions différentes, deux propriétaires différents. Les confondre, c'est comme ça qu'une équipe finit par croire qu'elle a gouverné quelque chose qu'elle a seulement branché.

Je corrige quelque chose que j'ai dit plus haut, parce que « non » était trop propre. L'accès améliore les exigences à la marge, d'une façon étroite: quand un agent voit le graphe de traçabilité au complet, il peut parfois faire ressortir une contradiction qu'un humain qui survole un seul ticket manquerait, en signalant qu'une story contredit son epic parent. C'est réel. C'est un bénéfice de validation qui vient gratuit avec de la bonne plomberie. C'est aussi de la cohérence structurelle, pas de la justesse. Un ensemble d'exigences parfaitement cohérent peut encore décrire un produit que personne n'a demandé.

Gouverner l'accès agentique aux exigences, ça demande quoi au juste?

Trois couches. La plupart des organisations en ont bâti exactement une.

La première, c'est la couche d'accès, et c'est celle sur laquelle tout le monde travaille. Qui lit quoi. Sous quelle identité. Avec quoi d'enregistré. Permissions par rôle, journaux d'audit, jetons à portée limitée, capacité de révoquer. C'est bien compris, les fournisseurs le livrent avec compétence, et si vous arrêtez là vous allez passer un nombre surprenant de revues internes tout en restant complètement exposé au vrai mode de défaillance.

La deuxième, c'est la couche de validation, et presque personne ne l'a. Avant qu'une exigence devienne atteignable par quelque chose qui exécute à la vitesse machine, est-ce que quelqu'un a établi qu'elle est complète, non ambiguë, cohérente avec les exigences qu'elle touche, et endossée par le monde qui va vivre avec le résultat? Cette question-là précède l'intelligence artificielle d'à peu près quarante ans. Rien de neuf. Les agents ont simplement enlevé le jeu qui la cachait.

La troisième, c'est la couche d'imputabilité, et c'est là que le 36 % devient inconfortable. Personne ne l'assume. Quand un agent construit correctement la mauvaise affaire, qui est responsable, et en combien de temps peut-on l'arrêter? Le tiers des dirigeants a dit ne pas pouvoir débrancher immédiatement un agent devenu incontrôlable, et un agent incontrôlable au sens qui compte le plus est rarement spectaculaire. C'est habituellement un agent obéissant, qui exécute une mauvaise instruction, très bien, à grande échelle.

Comment valider avant de brancher?

Commencez plus petit que vous en avez envie. L'instinct, c'est d'ouvrir le référentiel au complet à l'agent parce que c'est ce qui rend la démo impressionnante, et c'est exactement à l'envers.

Quatre affaires, dans l'ordre:

1. Limitez le pipe à ce qui a été validé. Pas le backlog au complet. Le sous-ensemble qui a passé une vraie revue, marqué d'une façon que le serveur MCP peut filtrer. Si ce sous-ensemble est gênant de petitesse au jour un, vous venez d'apprendre la chose la plus utile que l'exercice pouvait vous montrer.
2. Rendez l'ambiguïté visible par la machine. Les exigences échouent selon des patrons: termes non définis, voix passive qui cache l'acteur, critères d'acceptation intestables, un « devrait » qui fait la job d'un « doit ». Ça se détecte avant qu'un agent les lise, et détecter est une activité différente de servir.
3. Interrogez sous plus qu'un angle. Un seul réviseur, humain ou modèle, reproduit ses propres angles morts à grande vitesse. C'est l'argument pour plusieurs perspectives spécialisées qui challengent une exigence avant qu'elle devienne exécutable, dont une dont la job est de plaider contre.
4. Gardez la trace de la décision, pas juste le journal d'accès. Votre piste d'audit devrait montrer pourquoi une exigence a été acceptée et par qui, pas seulement quel agent l'a lue à quelle heure. La piste d'audit qui compte est celle qui capture le jugement.

Rien là-dedans ne plaide contre le branchement des agents sur les données d'exigences. Branchez-les. Le pipe est bon, le protocole est bon, et les équipes qui refusent de brancher quoi que ce soit vont perdre contre celles qui le font, et c'est la partie que le commentaire prudent manque tout le temps. Mettez juste une barrière devant, en sachant que la barrière est une pièce d'ingénierie différente du pipe.

Nicolas Payette

Fondateur et PDG de Specira AI. 25 ans dans la livraison de logiciels d'entreprise, dont une bonne partie à regarder du code correct s'écrire contre des exigences incorrectes. Specira travaille la couche au-dessus du code, là où l'exigence que personne n'a validée est encore juste une phrase.