L’IA d’entreprise plafonne et AWS veut débloquer le potentiel

Les preuves de concept de l’IA d’entreprise aboutissent rarement à la production

De nombreuses entreprises jouent avec l’intelligence artificielle. Elles intègrent de grands modèles de langage dans des expériences ponctuelles, automatisent des bribes de flux de travail et lancent des PoC pour explorer les cas d’utilisation potentiels. Mais selon IDC, seuls 12 % de ces PoC atteignent un environnement de production complet. Il ne s’agit pas seulement d’inefficacité, mais aussi de perte de temps, de talent et d’opportunités.

Ce n’est pas parce que les équipes à l’origine de ces PoC manquent de compétences. Le problème réside dans la manière dont ces preuves de concept sont conçues. La plupart sont conçues pour impressionner lors des démonstrations, et non pour fonctionner dans un environnement de production désordonné et imprévisible. Elles fonctionnent dans des conditions propres en utilisant des données limitées, un seul agent et, souvent, des autorisations exagérées, juste pour que cela fonctionne. C’est très bien pour les premières explorations. Mais ces mêmes conditions s’effondrent lorsque vous essayez de passer à l’échelle supérieure.

Lors du déploiement en production, vous n’avez plus affaire à un seul agent de test. Vous orchestrez des milliers, voire des dizaines de milliers, d’agents d’IA qui fonctionnent tous ensemble, se coordonnent, transmettent des données et réagissent à des signaux en temps réel dans les systèmes de votre entreprise. Vous devez faire face à la complexité de l’intégration, aux couches d’authentification et aux problèmes de données réels tels que les incohérences, les champs incomplets et les entrées en constante évolution.

Swami Sivasubramanian, vice-président de l’IA agentique chez Amazon Web Services (AWS), l’a clairement indiqué lors de son discours d’ouverture à AWS re:Invent. L’obstacle à la production n’est pas la technologie, c’est la fondation. Les PoC doivent être conçus dès le départ dans une optique de production. Si ce n’est pas le cas, vous ne validez pas une solution, vous ne faites que répéter un produit qui ne peut pas être mis à l’échelle. Et c’est un luxe que très peu d’entreprises peuvent se permettre si elles veulent vraiment rendre l’IA opérationnelle.

Les environnements de test et de production sont fondamentalement différents, et c’est là le problème.

La déconnexion entre les PoC et la production est plus importante que la plupart des gens ne le pensent. Lorsque vous testez dans un environnement de laboratoire, vos données sont propres, vos flux de travail sont linéaires et vos entrées se comportent comme vous le souhaitez. Mais l’environnement de production n’est pas aussi indulgent. Il est rempli de cas limites, d’enregistrements contradictoires, de formats inattendus et de dépendances système qui feraient planter la plupart des prototypes.

Dans un PoC, les ingénieurs ignorent souvent ces variables pour accélérer la livraison. Ils alimentent les modèles avec des données nettoyées, définissent des entrées d’invite rigides et exécutent manuellement des tâches par le biais d’API scriptées. Cela fonctionne, mais seulement à l’intérieur de la bulle. En production, la même configuration échoue parce qu’il n’y a pas deux utilisateurs qui se comportent de la même manière, que les pipelines de données sont obstrués, que les entrées sont imprévisibles et que les API ne répondent pas toujours comme vous le souhaitez.

L’un des défis les plus négligés est la gestion des identités et des accès. Les environnements de test bénéficient souvent d’une liberté d’action, de comptes de service uniques et sur-autorisés qui peuvent faire tout ce qui est nécessaire pour que les choses avancent. Vous ne pouvez pas appliquer ce modèle à la production. Vous avez besoin de contrôles d’accès stricts. Pour qui l’agent peut-il parler ? Quels systèmes peuvent être déclenchés en son nom ? Comment gérez-vous l’expiration des jetons ou les autorisations interservices sur AWS et les fournisseurs tiers ?

Swami Sivasubramanian le souligne clairement : les systèmes de production exigent une gestion de l’accès solide comme le roc, une intégration transparente entre les outils et des architectures d’agents qui tombent en panne de manière gracieuse, et non catastrophique. Un PoC qui tombe en panne et redémarre manuellement est tolérable dans le cadre d’un test. Mais si votre système s’arrête à chaque fois qu’une intégration a un problème, vous n’êtes pas prêt pour la production.

Les cadres supérieurs doivent le reconnaître : la différence n’est pas seulement technique, elle est aussi architecturale. Les systèmes de production exigent une planification, un outillage et une résilience d’un genre différent. Il ne suffit pas de prouver que quelque chose fonctionne une fois. Vous devez prouver qu’il fonctionnera de manière cohérente, à grande échelle, avec des données désordonnées, des entrées incertaines et dans des environnements où les temps d’arrêt ne sont pas envisageables. Si vous ne commencez pas avec cet objectif final en tête, vous ne ferez que des expériences, vous ne construirez pas de systèmes.

AWS rationalise la transition du PoC à la production grâce à un outillage ciblé

Le plus grand progrès de l’IA n’est pas algorithmique, il est opérationnel. Vous pouvez construire l’agent le plus intelligent de manière isolée, mais si vous ne pouvez pas l’intégrer dans des équipes, des systèmes et des scénarios imprévisibles, vous avez essentiellement construit une démo. AWS s’attache désormais à combler cette lacune opérationnelle en intégrant l’aptitude à la production dans le processus de développement lui-même, en éliminant les goulets d’étranglement techniques avant qu’ils ne vous ralentissent.

Swami Sivasubramanian, vice-président de l’IA agentique chez AWS, a été clair sur ce point : le succès ne viendra pas de l’assemblage manuel de boîtes à outils. Il s’agit de donner aux équipes des modules intelligents sur lesquels elles peuvent s’appuyer sans être entraînées dans la complexité. C’est l’objectif qui sous-tend le nouvel ensemble d’outils d’AWS, notamment la mémoire épisodique dans Bedrock AgentCore, la personnalisation de modèles sans serveur dans SageMaker et la prise en charge du Reinforcement Fine-Tuning (RFT).

La mémoire épisodique permet aux agents de capturer et de comprimer les interactions précédentes en « épisodes » utilisables, qui peuvent être récupérés dans des tâches futures. Au lieu d’obliger les équipes d’ingénieurs à coder et à maintenir leur propre échafaudage de mémoire, comme les magasins de vecteurs personnalisés et la logique d’extraction, le système gère le contexte automatiquement, ce qui rationalise le développement sans compromettre les capacités. Cela permet de raccourcir les boucles de rétroaction et de préserver la cohésion des agents dans des flux de travail complexes.

Côté modèle, la personnalisation sans serveur dans SageMaker automatise la préparation des données, l’entraînement, l’évaluation et le déploiement. Les équipes n’ont pas besoin de provisionner l’infrastructure ou d’affiner manuellement les hyperparamètres. Et grâce à la formation sans point de contrôle dans SageMaker HyperPod, le temps de formation est réduit, ce qui permet aux développeurs d’avancer plus rapidement sans attendre des redémarrages complets après des perturbations.

Ces mesures sont axées sur la réduction de la charge opérationnelle. Scott Wheeler, Cloud Practice Leader chez le cabinet de conseil en IA Asperitas, a fait écho à ce point, affirmant que l’automatisation d’AWS supprimera d’importants frais généraux MLOps, donnant aux équipes la liberté d’itérer plus rapidement, en particulier lors du déploiement de plusieurs agents à l’échelle.

Les dirigeants qui développent l’IA dans les unités opérationnelles devraient en prendre note. Ce n’est pas en augmentant les effectifs que vous obtiendrez la vélocité à grande échelle, mais en supprimant les frictions entre l’idée et le déploiement fiable de la production. Les outils d’AWS sont conçus pour permettre ce changement.

La résilience et la gouvernance sont désormais au cœur de la stratégie de déploiement de l’IA d’AWS.

Une fois que les agents passent à la production, les exigences changent. Il ne s’agit pas seulement de fiabilité, mais aussi de gouvernance, de conformité et d’intégrité au niveau du système. Toute défaillance peut avoir un impact sur plusieurs flux de travail. AWS a réagi en ajoutant des fonctions de contrôle plus strictes à sa plateforme d’agents pour s’assurer que ces systèmes fonctionnent comme prévu dans des conditions de charge de travail réelles.

La passerelle Bedrock AgentCore inclut maintenant des outils de politique et d’évaluation, tous deux conçus pour détecter les problèmes avant qu’ils n’entrent dans un environnement réel. La Politique donne aux développeurs la possibilité de définir des garde-fous et d’appliquer des limites sur les outils que les agents peuvent utiliser ou sur la façon dont ils peuvent se comporter. Quant à l’évaluation, elle simule les interactions réelles, permettant aux équipes de surveiller les défaillances, les baisses de performance ou les actions involontaires avant qu’elles n’atteignent les utilisateurs finaux.

Cela est important car la plupart des PoC ne s’engagent pas dans une véritable gestion des erreurs ou dans une simulation en aval. En production, cette négligence devient une véritable responsabilité. Un agent connecté à un système dynamique doit répondre aux cas limites et à la latence du système sans se bloquer ni rompre les pipelines de données. Et s’il accède à des outils externes, il doit s’authentifier de manière fiable et gérer les conditions d’échec en toute sécurité.

Swami Sivasubramanian l’a dit clairement : les agents de production ne sont pas isolés. Ils font partie de systèmes plus vastes qui doivent rester stables dans des conditions variables. Les nouvelles capacités permettent de s’assurer que les agents n’agissent pas seulement de manière intelligente, mais qu’ils opèrent dans des limites clairement définies et qu’ils réagissent de manière prévisible, même lorsque les services externes se comportent de manière incohérente.

Du point de vue de la direction, ce passage de la performance à la responsabilité est essentiel. L’IA qui ne respecte pas son contexte, échoue à la vérification ou viole les conditions de contrôle de base devient un risque, qu’il soit technique, de réputation ou les deux. Ces nouvelles fonctionnalités d’AWS ne sont pas de simples compléments opérationnels ; ce sont des outils structurels pour un déploiement résilient et évolutif de l’IA au sein de systèmes réglementés et critiques. Si vous ne construisez pas en gardant ce type de contrôle à l’esprit, vous augmentez l’exposition de votre organisation, au lieu de la réduire.

L’automatisation est utile, mais elle ne remplace pas les problèmes difficiles liés au déploiement de l’IA.

AWS s’efforce à juste titre de faciliter le déploiement de l’IA. L’automatisation de la mémoire, de l’entraînement, de l’inférence et du contrôle d’accès supprime d’importantes couches de complexité. Mais si cela réduit les frictions en surface, cela n’efface pas les problèmes plus difficiles qui décident de la réussite d’un projet à l’échelle.

D’un point de vue technique, la mémoire épisodique est une amélioration significative. Elle permet aux agents d’IA de conserver un contexte utile sans que les développeurs aient à le gérer manuellement. Mais comme l’a expliqué David Linthicum, consultant indépendant et ancien Chief Cloud Strategy Officer chez Deloitte, sa valeur dépend entièrement de la capacité de l’entreprise à capturer, classer et gouverner efficacement les données comportementales. Sans cette base de données, la fonction de mémoire est sous-utilisée ou inefficace.

Il en va de même pour le Reinforcement Fine-Tuning (RFT). Sur le papier, il simplifie la manière dont les développeurs façonnent le comportement des modèles en utilisant les principes de l’apprentissage par renforcement (RL). Mais l’automatisation ne dispense pas les équipes de définir des fonctions de récompense de haute qualité, de calculer les résultats commerciaux réels ou de gérer la dérive du modèle en production. Ces étapes restent essentielles. Linthicum l’a dit clairement : c’est là que la plupart des PoC échouent. Non pas dans l’exécution technique, mais dans l’incapacité à refléter la valeur réelle.

Cela devient encore plus compliqué dans les industries hautement réglementées. La personnalisation des modèles sans serveur couvrant désormais tout, de la synthèse des données à l’évaluation des modèles, les équipes de gouvernance sont sous pression pour assurer la supervision. Les questions surgissent rapidement : Quelles données ont été générées ? Qu’est-ce qui a été affiné, et pourquoi ? Comment le modèle a-t-il été évalué et qui a approuvé les critères ?

Scott Wheeler, d’Asperitas, a répondu directement à cette préoccupation. Selon lui, si l’automatisation réduit le temps d’exécution du pipeline, elle ne remplace pas le besoin d’auditabilité humaine. Dans des secteurs comme la santé, la finance ou la défense, la vitesse seule ne constitue pas un avantage concurrentiel si elle n’est pas accompagnée de transparence et de contrôle.

Pour les responsables de haut niveau, la conclusion ne doit pas être que l’automatisation d’AWS est insuffisante, car ce n’est pas le cas. Les outils sont précieux. Ce qui compte, c’est de reconnaître le terrain que l’automatisation ne couvre pas encore : la gouvernance, l’explicabilité et l’alignement stratégique avec la valeur de l’entreprise. C’est là que les dirigeants doivent déployer des efforts, car ces lacunes ne peuvent pas être comblées par les seules fonctionnalités des logiciels. Elles nécessitent des politiques solides, des processus clairs et une responsabilisation tout au long du cycle de vie du déploiement.

Principaux enseignements pour les dirigeants

• La plupart des projets de démonstration de faisabilité en matière d’IA s’arrêtent avant la production : Seuls 12 % des projets d’IA en entreprise dépassent le stade de la validation du concept. Les dirigeants doivent tester sous pression l’évolutivité des projets à un stade précoce afin d’éviter les investissements inutiles et les retards opérationnels.
• Les PoC ne reflètent pas les réalités de la production : Les PoC échouent souvent parce qu’ils sont construits avec des données irréalistes, des flux de travail simplifiés à l’extrême et une sécurité laxiste. Les dirigeants devraient exiger que les conceptions pilotes reflètent dès le départ les conditions réelles de production.
• AWS cible les frictions opérationnelles avec des outils : AWS réduit les frictions liées au déploiement de l’IA grâce à des outils tels que la mémoire épisodique, l’entraînement automatisé des modèles et la personnalisation sans serveur. Les dirigeants devraient évaluer comment ces capacités peuvent réduire les frais généraux d’ingénierie et accélérer la livraison.
• La stabilité et la gouvernance sont désormais intégrées : les nouvelles fonctionnalités d’AWS, telles que la politique et l’évaluation, ajoutent des garde-fous et des tests de pré-déploiement afin d’éviter les défaillances du système à grande échelle. Les décideurs devraient privilégier les outils qui intègrent la fiabilité et la conformité directement dans les flux de travail.
• L’automatisation ne résoudra pas les défis fondamentaux de l’IA : Des fonctionnalités telles que la RFT et la formation sans serveur facilitent la configuration, mais n’éliminent pas le besoin de supervision humaine, de définition des récompenses ou de gouvernance. Les dirigeants doivent investir dans une ingénierie des données robuste, la transparence et l’examen interfonctionnel pour atténuer les risques à long terme.