Pourquoi l’IA agentique change l’évaluation des fournisseurs

Un fournisseur ayant passé l’évaluation n’est peut-être plus celui que vous avez évalué

Un fournisseur tiers peut réussir une évaluation, puis ajouter par la suite des capacités qui modifient la base sur laquelle le produit a été approuvé. Gartner appelle l’une des versions de ce problème l’AI creep : les fournisseurs ajoutent des capacités d’IA à des produits existants alors que les clients peuvent ne pas comprendre pleinement ce qui a changé. Les capacités agentiques augmentent les enjeux, car elles permettent à l’IA de passer à l’action. À mesure que les fournisseurs ajoutent rapidement ces capacités, une évaluation peut décrire une version antérieure du produit plutôt que celle qu’une organisation utilise désormais.

Cet écart a été un sujet clé lors de la conférence Enterprise Risk, Audit & Compliance 2026 de Gartner, où plusieurs sessions ont examiné comment l’ajout de capacités d’IA élargit la surface de risque IA d’une organisation. La surface de risque IA correspond à l’ensemble des fonctions d’IA susceptibles de créer un risque de sécurité, de conformité, opérationnel ou de gouvernance. Dans des entretiens avec TechTarget, les analystes Gartner Devanshu Mehrotra et Kjell Carlsson ont expliqué comment l’évolution des capacités remet en cause les pratiques établies d’assurance tierce. Gartner vend des services de recherche et de conseil en technologie, y compris des recommandations sur le risque et la gouvernance ; l’entreprise a donc un intérêt commercial à ce que les organisations recherchent des conseils sur ces problèmes.

La difficulté commence par l’absence d’un événement unique qui déclenche systématiquement une réévaluation. Un fournisseur peut ajouter un chatbot, améliorer la recherche, introduire un agent ou élargir progressivement ce qu’un agent existant peut faire. Chaque version peut sembler incrémentale, alors même que le produit acquiert une autorité et un comportement sensiblement différents de ceux de la version approuvée par les équipes IT et risque. L’assurance a besoin d’un moyen de détecter les changements pertinents entre les cycles d’évaluation formels.

L’AI creep fait voler en éclats les hypothèses de l’assurance à un instant donné

Détecter ces changements met sous pression trois hypothèses qui sous-tendent l’assurance tierce traditionnelle, selon Devanshu Mehrotra, senior director et analyste chez Gartner. Les capacités des fournisseurs peuvent ne pas évoluer assez lentement pour que des revues périodiques restent représentatives, les divulgations contractuelles peuvent ne pas faire remonter les changements significatifs, et les attestations des fournisseurs peuvent ne pas décrire avec précision ce qui se passe à l’intérieur du produit. L’IA agentique peut fragiliser ces trois hypothèses, car les fonctionnalités et les comportements peuvent évoluer une fois le travail d’assurance terminé.

La première pression concerne la durée de validité d’une évaluation, car un produit peut obtenir un nouvel accès aux données ou une nouvelle autorité après la revue. Les conclusions décrivent toujours l’état évalué par les équipes, mais le produit en exploitation l’a déjà dépassé. Mehrotra a décrit ce problème de temporalité dans son entretien avec TechTarget : « Parfois, les capacités évoluent plus vite que le fournisseur ne peut suivre. » Les clients peuvent donc se retrouver face à un écart entre le comportement actuel du produit et ce que leur processus d’assurance a formellement évalué.

Le problème de temporalité affecte aussi la divulgation, car un changement significatif peut s’accumuler au fil de plusieurs versions. Un ajout important, clairement annoncé, peut déclencher une revue juridique, sécurité ou risque, tandis que des changements plus modestes peuvent chacun rester en dessous du seuil d’action d’une organisation, même lorsque leur effet combiné modifie l’usage des données, l’autorité ou les conséquences. La matérialité doit donc tenir compte du changement cumulé. Sans cette règle, les équipes peuvent approuver chaque étape tout en passant à côté de ce que ces étapes produisent ensemble.

Cet effet cumulatif relie l’évolution technique à la conception des contrats. Mehrotra a déclaré : « Ayez une liste claire de ce qui est contractuellement autorisé et non autorisé, ainsi qu’une définition de ce qu’est un changement matériel, car une série de changements incrémentaux peut finir par constituer un changement matériel. » Un seuil défini de changement matériel donne aux équipes achats, IT et risque une base commune pour décider à quel moment des ajouts successifs d’IA exigent un nouvel examen. La décision dépend alors de leur effet combiné plutôt que de l’importance apparente d’une seule version.

Les artefacts à un instant donné présentent une limite connexe, car les attestations des fournisseurs, les rapports SOC, les questionnaires et les contrats décrivent ou encadrent un produit à un stade particulier. Ils restent des éléments utiles pour les décisions de risque tiers, mais une capacité d’IA ajoutée ultérieurement peut rendre certaines conclusions antérieures obsolètes. Les équipes peuvent conserver ces contrôles tout en ajoutant des mécanismes pour détecter les changements, obtenir des divulgations et recueillir des preuves sur le comportement actuel. Le fait d’avoir complété les artefacts d’origine ne suffit pas, à lui seul, à établir que l’ensemble des capacités restera stable jusqu’à la prochaine évaluation.

Une fois que ces artefacts deviennent une base de référence, l’assurance peut poser une question récurrente plus utile : quel changement matériel est intervenu depuis leur production ? Y répondre exige de la visibilité sur les nouvelles fonctionnalités d’IA, des critères pour décider quand une nouvelle revue est justifiée, et des preuves de ce que font les systèmes du fournisseur en exploitation. Les évaluations périodiques peuvent rester des points de contrôle planifiés, tandis que la supervision se poursuit entre elles. Une vigilance continue n’exige pas une surveillance littéralement en temps réel de chaque système fournisseur.

Les secteurs fortement réglementés appliquent déjà ce principe de gouvernance. Mehrotra a cité l’industrie pharmaceutique, où l’approbation initiale est suivie d’un suivi des performances, d’une évaluation des nouvelles informations et d’un examen des changements significatifs. Appliqué à la gouvernance de l’IA, ce modèle préserve la décision initiale tout en permettant à des éléments ultérieurs de modifier ce que les décideurs doivent évaluer.

Le risque suit l’accès et l’autorité de la capacité d’IA

Une fois que l’assurance suit l’évolution dans le temps, les équipes ont besoin d’une unité d’évaluation plus précise. Une même application peut contenir plusieurs capacités d’IA présentant des risques très différents, car leur accès et leur autorité diffèrent. Kjell Carlsson, vice-président analyste chez Gartner, soutient que les DSI devraient examiner ce que les fonctionnalités d’IA peuvent réellement faire au sein des produits tiers. Les classifications applicatives existantes, à elles seules, ne permettent pas de décrire le risque créé par chaque capacité qu’elles contiennent.

Les agents autonomes rendent cette différence concrète. Mehrotra a donné l’exemple d’un agent qui provisionne les accès utilisateurs : si son autorité ou son comportement est erroné, il pourrait accorder à quelqu’un un accès inapproprié à des informations sensibles. Un agent qui résume les e-mails chaque matin a des conséquences potentielles bien plus limitées. Ce sont tous deux des agents d’IA intégrés à des logiciels d’entreprise, mais les actions qu’ils peuvent effectuer et les ressources affectées par ces actions créent des risques différents.

Cette différence fait de l’accès, de l’autorité et des conséquences des éléments centraux de l’évaluation au niveau des capacités. Les équipes doivent déterminer à quelles données de l’entreprise une capacité d’IA peut accéder, quelles opérations elle peut effectuer et ce qui se passe lorsque ces opérations sont incorrectes ou inappropriées. Dans l’exemple du provisionnement des accès, l’IA peut modifier les autorisations d’une autre personne ; dans l’exemple des e-mails du matin, sa fonction principale est de produire un résumé. Le comportement de la capacité fournit des informations qu’un simple nom d’application ne peut pas donner.

Le comportement peut toutefois rester difficile à voir, car l’AI creep n’arrive pas toujours sous la forme d’un agent autonome bien visible. Carlsson cite les chatbots et les outils de création d’agents comme exemples visibles, tandis que la recherche alimentée par l’IA et la détection d’anomalies peuvent introduire l’IA via des fonctions moins évidentes. Un processus de gouvernance centré uniquement sur les interfaces d’IA les plus visibles peut donc passer à côté de changements dans la manière dont les données de l’entreprise sont traitées ou dont les décisions sont appuyées. La visibilité doit s’étendre aux fonctions d’IA intégrées plus profondément dans le produit.

Pour les DSI, les responsables engineering et les équipes risque, cette visibilité change la question pratique lors de l’évaluation d’un fournisseur. Savoir qu’un produit « utilise l’IA » en dit peu sur l’autorité d’une capacité particulière. Les équipes doivent établir à quoi la capacité peut accéder, ce qu’elle peut faire avec cet accès, qui en est responsable et quelles conséquences organisationnelles découlent d’un changement de son comportement. Ces réponses constituent la base permettant de décider quels changements côté fournisseur exigent une assurance supplémentaire.

Transformer l’assurance en un processus continu de preuve et de divulgation

L’évaluation au niveau des capacités rend la supervision continue plus précise, car les équipes peuvent surveiller les changements d’accès et d’autorité. Les équipes IT et risque peuvent suivre les capacités d’IA qu’un fournisseur ajoute, ce que chacune peut faire et comment une extension modifie le risque pour l’organisation. Si un agent obtient l’accès à un autre jeu de données ou l’autorité d’effectuer une autre action, cette nouvelle capacité devient un événement d’assurance. Les équipes peuvent alors en évaluer l’importance au regard de l’état qu’elles avaient précédemment approuvé.

L’évaluation de cet événement exige des preuves opérationnelles de ce qui se passe dans les systèmes du fournisseur. Mehrotra recommande de rechercher ce type de preuves en complément de l’assurance à un instant donné, afin que les équipes puissent examiner le comportement du système une fois l’évaluation terminée. Les rapports SOC, les questionnaires et les attestations fournissent des preuves formelles, tandis que les informations opérationnelles aident à montrer si le comportement actuel correspond toujours aux hypothèses et aux autorisations qui sous-tendaient l’approbation. Ces deux formes de preuve couvrent des moments différents dans la vie du produit.

Les contrats peuvent transformer ces observations en attentes opposables. Les exigences imposées aux fournisseurs peuvent préciser quand les changements matériels des capacités d’IA doivent être divulgués, définir quels comportements sont contractuellement autorisés ou interdits, et établir ce qui constitue un changement matériel. Cette définition doit aussi tenir compte du changement cumulé, car plusieurs ajouts incrémentaux peuvent finir par créer suffisamment d’accès, d’autonomie ou de conséquences pour justifier une nouvelle revue. Le langage contractuel fournit alors le seuil à partir duquel les équipes peuvent juger les nouvelles preuves opérationnelles.

Les questions de Carlsson donnent aux DSI un framework récurrent pour porter ce jugement. Ils peuvent poser les mêmes questions lorsqu’une capacité apparaît pour la première fois, puis à nouveau lorsque son accès aux données, son autorité, sa finalité ou la gouvernance du fournisseur changent :

• « Où vont les données de l’entreprise ? »
• « Qui est impliqué et responsable ? »
• « À quoi l’IA peut-elle accéder et que peut-elle faire ? »
• « Pourquoi cette capacité a-t-elle de la valeur ? »
• « Quand le fournisseur informera-t-il les clients des changements matériels ? »
• « Comment l’organisation sait-elle que l’IA reste fiable et gouvernée ? »

Ces questions dissocient les éléments de la décision afin que les équipes puissent voir ce qui a changé. La localisation et l’accès aux données établissent l’exposition, la responsabilité identifie qui assume les décisions et les conséquences, et la valeur établit pourquoi l’organisation accepte le risque lié à la capacité. Les modalités de notification déterminent comment les clients sont informés des changements significatifs côté fournisseur, tandis que la dernière question appelle des preuves continues que l’IA reste fiable et gouvernée. Revenir sur chacun de ces éléments permet de maintenir l’évaluation alignée sur le comportement actuel de la capacité.

L’usage répété évite aussi qu’un nouveau questionnaire ne devienne un autre instantané figé. Une capacité peut avoir une réponse acceptable lors de son introduction, puis une réponse différente après que le fournisseur a élargi son accès aux données ou autorisé une action autonome. La supervision continue détecte ces réponses modifiées et les confronte aux seuils contractuels et de risque de l’organisation. La pratique pharmaceutique que Mehrotra a citée offre l’analogie précédente : l’approbation initiale reste utile, tandis que les performances ultérieures, les nouvelles informations et les changements significatifs continuent de faire l’objet d’un examen.

Maintenir un inventaire vivant des capacités et des responsabilités

La revue répétée crée un problème d’information interne, car le nombre et le comportement des capacités d’IA peuvent évoluer dans l’environnement logiciel d’une organisation. Valence Howden, advisory fellow chez Info-Tech Research Group, explique qu’il peut être difficile de suivre ce que les agents d’IA peuvent réellement faire dans cet environnement. Il recommande de tenir un registre des outils et agents d’IA utilisés par l’organisation, de ce que ces systèmes font et de l’endroit où se situe la responsabilité. Info-Tech Research Group vend des services de recherche et de conseil en technologie ; l’entreprise a donc elle aussi un intérêt commercial à ce que les organisations adoptent des pratiques de gestion et de gouvernance technologiques.

Un registre donne à cette revue récurrente une trace interne durable. Lorsqu’un fournisseur modifie une fonction d’IA, l’organisation peut comparer le nouveau comportement à l’état précédemment compris, examiner comment son autorité a changé et identifier le responsable désigné. Les équipes sécurité, engineering, IT et risque peuvent également utiliser ce registre pour relier un changement côté fournisseur aux systèmes, données et décisions internes concernés. Maintenir le registre à jour le rend utile entre les échanges individuels avec les fournisseurs.

Ce registre peut contenir les informations distinctes soulevées par les analystes de Gartner et d’Info-Tech Research Group sans traiter leurs recommandations comme équivalentes. L’accent mis par Mehrotra sur la visibilité continue et les preuves opérationnelles permet d’identifier les changements qui ont pu faire évoluer un produit au-delà d’une évaluation antérieure, tandis que les questions récurrentes de Carlsson identifient les informations que les équipes peuvent réévaluer à mesure qu’une capacité évolue. Le registre de Howden fournit un endroit où conserver les informations sur les capacités, les comportements et les responsabilités à mesure que l’environnement logiciel change. Le dossier d’assurance qui en résulte n’est utile que tant qu’il reflète les capacités des fournisseurs que l’organisation utilise actuellement.

Points clés

• Réévaluer les fournisseurs à mesure que les capacités d’IA évoluent : les DSI et les équipes risque ont besoin d’une visibilité continue sur les ajouts d’IA, car de nouveaux accès, une nouvelle autonomie ou de nouveaux usages des données peuvent rendre obsolète une évaluation antérieure du fournisseur. Définissez à quel moment des changements individuels ou cumulés déclenchent un nouvel examen.
• Évaluer l’accès et l’autorité au niveau des capacités : les équipes risque doivent évaluer à quoi chaque capacité d’IA peut accéder, quelles actions elle peut effectuer et quelles sont les conséquences des erreurs. Les fonctions agentiques ayant autorité sur les autorisations, les données ou les opérations justifient un examen plus poussé.
• Exiger des preuves et des divulgations entre les revues : les équipes achats et risque doivent définir dans les contrats ce qui constitue un changement matériel lié à l’IA, exiger une notification du fournisseur et recueillir des preuves opérationnelles du comportement actuel. Ces contrôles aident à identifier quand des capacités en évolution dépassent les limites précédemment approuvées.
• Maintenir un inventaire vivant des capacités d’IA : les équipes IT et gouvernance doivent consigner les outils et agents d’IA des fournisseurs, leurs fonctions, leurs accès et les responsables désignés. Maintenir ce registre à jour aide à relier les changements côté fournisseur aux systèmes, données et décisions métier concernés.