Pourquoi les évaluations IA ne suffisent pas à garantir la fiabilité

L’IA peut franchir le contrôle et quand même décevoir le client

Une évaluation de l’IA réussie constitue une preuve limitée de ce qu’un client vivra réellement en production. En juillet, 49% des 108 personnes interrogées par VB Pulse dans des entreprises d’au moins 100 salariés ont déclaré que leur organisation avait rencontré un problème visible par le client après qu’un agent IA ou une fonctionnalité alimentée par un LLM a franchi les tests internes. En juin, ce chiffre était de 50%, et 24% des répondants de juillet ont indiqué que cela s’était produit plus d’une fois.

Ce que mesure le chiffre de 49% détermine jusqu’où ce résultat peut aller. Il recense les organisations ayant connu au moins un incident répondant aux critères au cours de l’année précédente ; il ne mesure pas la part des exécutions individuelles d’agents ayant échoué ni le taux d’échec d’un produit d’évaluation. Comme une entreprise qui déploie de nombreux agents a davantage d’occasions de connaître un incident, l’exposition en production peut influer sur son appartenance à ce groupe.

Dans cette limite, le résultat restreint tout de même le niveau de responsabilité que les entreprises peuvent faire porter à un contrôle de mise en production. Les tests d’évaluation internes comparent le comportement à des critères définis à l’avance et peuvent aider à décider si un système d’IA poursuit vers le déploiement, mais environ la moitié des organisations interrogées dans les deux vagues avaient vu un système réussir ces tests avant de créer ensuite un problème visible par le client. Une évaluation réussie, à elle seule, ne permet pas d’établir la fiabilité en production.

La confiance progresse tandis que le taux d’échec déclaré reste stable

Cette limite rend l’évolution de la confiance plus frappante. En juillet, 13% des répondants ont exprimé une confiance totale dans l’évaluation automatisée, contre 5% en juin, tandis que la part citant le mauvais alignement entre les tests et les résultats réels comme principale préoccupation est passée de 29% à 19%. La mesure des incidents n’a évolué que d’un point de pourcentage sur la même période.

Ces évolutions montrent une meilleure perception de l’évaluation automatisée sans changement comparable dans l’ampleur de ce résultat particulier visible par le client. Comme la mesure des incidents enregistre l’expérience des organisations, elle ne peut pas montrer à quelle fréquence les échecs se sont produits au sein de chaque organisation. Elle montre en revanche que la proportion d’entreprises interrogées signalant au moins un tel échec est restée pratiquement stable.

La stabilité de la mesure des incidents prolonge ce que l’étude de juin de VentureBeat appelait le « fossé de l’évaluation en entreprise ». En juin, l’autonomie des agents augmentait plus vite que la capacité des entreprises à les tester de manière fiable. Juillet ajoute une autre observation : les organisations peuvent déclarer une confiance accrue dans l’évaluation automatisée alors que la part signalant au moins un système approuvé par les tests ayant ensuite causé un problème client évolue peu.

La conception de l’enquête maintient cette comparaison dans un cadre étroit, car l’expérience organisationnelle diffère d’un test contrôlé de la qualité de l’évaluation. Davantage de déploiements créent plus d’occasions d’enregistrer au moins un incident, et les changements dans les systèmes déployés par les entreprises peuvent modifier cette exposition. Les résultats de juillet établissent une divergence entre la confiance déclarée et la prévalence des organisations signalant ce type d’échec ; ils n’en établissent pas la cause.

D’autres évolutions d’un mois sur l’autre apportent du contexte à l’évolution de l’environnement d’achat. VentureBeat Intelligence a identifié quatre développements : la confiance totale dans l’évaluation automatisée a augmenté, l’inquiétude liée au mauvais alignement avec la réalité a diminué, davantage de répondants ont choisi la facilité d’intégration comme facteur d’achat décisif, et Braintrust a gagné des parts comme plateforme principale. Les deux premiers suivent le déplacement de confiance décrit plus haut, tandis que la facilité d’intégration et Braintrust montrent que les préférences d’achat en matière d’évaluation évoluaient en même temps.

Les entreprises ayant connu des échecs d’évaluation sont plus sceptiques et plus automatisées

Le tableau croisé de juillet accentue la divergence, car l’expérience directe est associée à une confiance bien plus faible. Parmi les entreprises où une fonctionnalité IA testée a ensuite déçu un client, seules 4% accordaient une confiance totale aux contrôles automatisés. Parmi les organisations n’ayant signalé aucun incident comparable, 24% le faisaient, soit un écart d’un facteur six.

Les effectifs derrière ces pourcentages montrent la taille des groupes comparés. Deux des 53 entreprises déjà confrontées à ce type de problème ont exprimé une confiance totale dans les contrôles automatisés, contre 10 des 41 entreprises n’ayant identifié aucun échec de test comparable. L’association est claire : les répondants ayant vu le contrôle de mise en production manquer un problème visible par le client étaient beaucoup moins susceptibles d’accorder une confiance totale à l’automatisation.

Une confiance plus faible, toutefois, ne correspondait pas à un moindre intérêt pour le déploiement autonome. Dans l’ensemble de l’échantillon de juillet, 67% autorisaient déjà un agent à pousser du code ou à modifier un système sans validation humaine dans certains cas à faible risque, ou modifiaient leurs pipelines pour le permettre au cours de l’année à venir. La proportion globale était inchangée par rapport à juin, avec 37% autorisant déjà cette pratique dans des cas limités et 30% supplémentaires en train de s’y préparer.

Dans cette dynamique, le groupe ayant connu un échec poursuivait ce modèle plus agressivement. Parmi les entreprises ayant connu un système approuvé par les tests qui a ensuite déçu un client, 85% poursuivaient un déploiement sans validation humaine dans les cas concernés, contre 61% parmi les entreprises ne signalant aucun incident comparable. L’expérience d’un échec d’évaluation est donc associée à une confiance plus faible dans les contrôles automatisés et à une recherche plus active d’autonomie de déploiement.

La même relation apparaît parmi les répondants rejetant l’automatisation complète du déploiement pour les années à venir. Seuls 11% des répondants ayant connu un échec rejetaient l’automatisation de bout en bout, contre 24% des répondants n’ayant pas connu d’échec. Dans cet échantillon, un échec visible par le client était donc associé à un moindre rejet de l’automatisation de bout en bout.

Cette association rend importante la distinction entre validation humaine et évaluation automatisée. Une organisation peut perdre confiance dans la capacité d’un contrôle automatisé à capter chaque échec en production tout en concluant qu’exiger qu’une personne approuve chaque changement de production à faible risque n’est pas un modèle opérationnel adapté. Les résultats de juillet ne tranchent pas les raisons de ce jugement, mais ils montrent que les échecs constatés de première main n’ont pas stoppé le mouvement vers une plus grande autonomie.

La corrélation ne permet pas de trancher la cause

Le mouvement plus marqué vers l’autonomie parmi les entreprises ayant connu un échec ne montre pas que cet échec a provoqué ce mouvement. La relation à 85% pourrait refléter une plus grande appétence au risque ou d’autres différences entre les groupes. La maturité du déploiement pourrait aussi y contribuer, car les organisations exploitant davantage d’agents à plus grand volume ont plus d’occasions de rencontrer un incident, tandis que ces mêmes organisations peuvent disposer d’une infrastructure d’ingénierie qui facilite la mise en œuvre du déploiement automatisé.

La taille des sous-groupes limite encore davantage les conclusions sur la cause. Les comparaisons entre groupes ayant connu ou non un échec reposent sur des groupes allant de 41 à 53 répondants, tandis que d’autres tableaux croisés utilisent des groupes de 40 à 68. VB Pulse reposait sur un échantillon auto-sélectionné plutôt que probabiliste ; les résultats apportent donc des indications directionnelles, mais ne peuvent pas être simplement projetés à l’ensemble des entreprises.

Les comparaisons d’un mois sur l’autre font face à une autre contrainte, car le profil des répondants de juillet différait de celui de juin. La participation des secteurs technologie et logiciel a reculé de neuf points de pourcentage à 14%, tandis que la participation des secteurs retail et grand public a progressé de quatre points à 19%. Les changements entre les deux vagues peuvent donc refléter l’évolution de l’échantillon autant que des changements dans les attitudes ou les pratiques des entreprises.

L’échantillon complet montre l’ampleur et le contexte décisionnel de ces limites. Les deux vagues VB Pulse de VentureBeat Intelligence totalisent 265 réponses d’entreprises : 157 en juin et 108 en juillet. Dans l’échantillon de juillet, 63% travaillaient dans des organisations de 100 à 2 499 salariés, et 69% se décrivaient comme décideurs finaux pour les achats d’IA ou comme personnes recommandant ou influençant les achats d’IA. Ces répondants rendent les conclusions pertinentes pour les décisions technologiques des entreprises, tandis que l’auto-sélection et l’évolution de la répartition sectorielle limitent les conclusions plus larges sur le marché.

Dans ces limites, l’association reste importante pour les responsables de l’ingénierie, car le fait de connaître un incident visible par le client ne semble pas arrêter le mouvement vers l’autonomie de déploiement. Les données ne permettent pas de trancher entre l’imprudence, la maturité et d’autres explications possibles de cette association. Elles montrent plutôt que le scepticisme à l’égard de l’évaluation et le déploiement automatisé peuvent coexister au sein des mêmes organisations.

Les agents complexes rendent plus difficile le maintien d’évaluations exhaustives avant la production

Cette coexistence soulève une question pratique : quels contrôles peuvent soutenir davantage d’autonomie lorsque les tests préproduction ne peuvent pas anticiper tous les comportements ? Raindrop.ai, une plateforme automatisée de surveillance et d’atténuation des erreurs d’agents, affirme voir les entreprises changer leur approche de l’évaluation, selon son CTO Ben Hylak. Raindrop.ai vend des solutions de surveillance et d’atténuation des erreurs d’agents ; l’entreprise a donc un intérêt commercial à ce que les entreprises accordent plus de valeur à la détection continue. Dans un message direct à VentureBeat, Hylak a déclaré : « Nous assistons au grand déclin des évaluations telles que nous les connaissons », décrivant un changement qui, selon lui, s’est développé depuis « il y a seulement quelques mois ».

Hylak relie ce changement revendiqué aux grandes entreprises et à la complexité croissante des systèmes. « Les Fortune 100 réduisent de plus en plus leurs ensembles d’évaluation et dépriorisent leur maintenance. À mesure que les systèmes deviennent plus complexes (MCP, sous-agents, etc.), il devient impossible d’énumérer complètement les cas d’échec. À la place, elles s’appuient sur des solutions de détection d’anomalies et de problèmes, avant comme après la production. » Hylak présente cela comme un schéma que Raindrop.ai dit observer dans l’ensemble de cette cohorte.

La complexité décrite par Hylak vient de l’éventail de comportements que peuvent produire des composants en interaction. Les intégrations MCP, ou Model Context Protocol, peuvent connecter les systèmes d’agents à des outils et des données externes, tandis que les sous-agents répartissent le travail entre des agents supplémentaires. À mesure que ces composants interagissent, maintenir un ensemble d’évaluation fini, c’est-à-dire une collection bornée de tests prédéfinis, couvrant tous les cas d’échec pertinents devient progressivement plus difficile, car l’organisation doit anticiper des combinaisons de comportements avant le déploiement.

Cette difficulté modifie la finalité de la détection d’anomalies et de problèmes. Un ensemble d’évaluation fini demande si des tests connus sont réussis à un moment défini avant la mise en production, tandis que la détection continue recherche des comportements inattendus ou problématiques autour de la production, y compris des cas que les concepteurs n’ont pas énumérés à l’avance. Dans le récit de Hylak, les entreprises du Fortune 100 déplacent leurs efforts de maintenance vers ces mécanismes de détection avant comme après la production.

L’observation de ce fournisseur doit rester distincte des conclusions de VB Pulse, car les deux sources de preuve répondent à des questions différentes. L’enquête établit les attitudes des entreprises et les incidents déclarés, plutôt que des changements dans la taille des ensembles d’évaluation, l’adoption de Raindrop.ai ou les raisons du déplacement vers la détection d’anomalies. Le récit de Hylak décrit de même un schéma de surveillance que son entreprise dit observer à mesure que les systèmes d’agents deviennent plus difficiles à énumérer de façon exhaustive, plutôt qu’une explication causale de l’évolution des chiffres de confiance de l’enquête.

Un déploiement plus autonome élargit le périmètre de sécurité

Le mouvement vers le déploiement autonome rend plus importants les contrôles situés au-delà d’une seule décision de mise en production. Si le volume de déploiement augmente tandis que la probabilité d’échec par déploiement reste constante, le nombre absolu d’incidents pourrait augmenter même si le pourcentage d’entreprises connaissant au moins un incident reste stable. Comme juillet mesure si une organisation a connu un incident répondant aux critères plutôt que le volume total d’incidents, cette hausse constitue un risque implicite plutôt qu’un résultat observé.

Ce risque élargit la réponse opérationnelle au-delà de la décision d’approbation. La validation humaine peut être un contrôle, tandis que la détection avant et après la mise en production peut repérer les problèmes à mesure que les systèmes automatisés effectuent davantage de changements. Les organisations qui accroissent l’autonomie de déploiement ont donc besoin de moyens pour identifier des comportements que les tests préproduction n’ont pas anticipés et réagir lorsqu’ils apparaissent en production.

Le modèle opérationnel plus large modifie aussi ce que doit couvrir la « sécurité ». Les évaluations restent utiles pour les comportements connus et les critères de mise en production, mais un score de réussite apporte peu d’informations sur les conditions que les tests n’ont pas captées. À mesure que le déploiement devient plus autonome, la charge de fiabilité s’étend à l’ensemble du cycle de vie du système déployé, avec une détection opérant de part et d’autre de la production.

Points clés à retenir pour les dirigeants

• Considérez les évaluations réussies comme une preuve limitée : Environ la moitié des entreprises interrogées ont signalé un problème visible par le client après qu’un système d’IA a franchi les tests internes. Les responsables IA peuvent utiliser les évaluations préproduction pour les comportements connus tout en maintenant des contrôles pour les échecs que ces tests ne couvrent pas.
• Conciliez la hausse de la confiance avec la persistance des échecs : La confiance totale dans l’évaluation automatisée est passée de 5% à 13%, tandis que la part signalant au moins un échec visible par le client est restée pratiquement stable à 49%. Les responsables technologiques peuvent suivre les résultats en production en parallèle des scores d’évaluation avant d’accroître leur dépendance aux contrôles automatisés.
• Préparez l’autonomie à des évaluations imparfaites : Parmi les entreprises ayant connu un échec d’évaluation, 85% poursuivaient un déploiement sans validation humaine dans les cas concernés, contre 61% des entreprises n’ayant signalé aucun échec. Les organisations d’ingénierie qui accroissent leur autonomie ont besoin de mécanismes de détection et de réponse opérant après la mise en production.
• Évitez de tirer des conclusions causales de l’enquête : Le lien entre des échecs antérieurs de l’IA et une plus grande autonomie de déploiement peut refléter l’échelle des déploiements, la maturité, la tolérance au risque ou d’autres facteurs. Les décideurs doivent considérer ces résultats comme directionnels, car l’enquête reposait sur un échantillon auto-sélectionné et les sous-groupes étaient de petite taille.
• Étendez l’évaluation à la détection continue : Les systèmes complexes utilisant des outils, des intégrations MCP et des sous-agents créent des combinaisons de comportements que des ensembles d’évaluation finis deviennent plus difficiles à énumérer. Les équipes plateforme peuvent associer des tests préproduction définis à l’avance à une détection d’anomalies et de problèmes avant et après le déploiement.
• Élargissez le périmètre de sécurité avec l’autonomie de déploiement : Un volume plus élevé de déploiements automatisés crée davantage d’occasions d’incidents même lorsque le taux d’échec par déploiement ne change pas. Les organisations qui retirent les validations humaines des changements à faible risque ont besoin de contrôles sur l’ensemble du cycle de vie pour détecter les comportements inattendus et permettre une réponse rapide en production.