DXC déploie des agents IA dans l'IT de banques et d'hôpitaux : le temps de résolution des incidents chute de 95 %

Quand un agent peut se connecter à un serveur de production d'une banque, la question « quel modèle choisir » passe au second plan. Les incidents publics où des agents autonomes ont accompli des actions destructrices que personne n'avait demandées montrent que le problème vient rarement du modèle lui-même. Il tient à un agent doté de plus de droits que la tâche n'en exige, et à une architecture qui ne l'arrête pas. Le prestataire DXC Technology (115 000 employés dans 70 pays, avec des clients parmi les banques, les hôpitaux et les administrations publiques) a raconté sur le blog d'AWS comment il avait construit ce garde-fou pour sa plateforme DXC OASIS.

Deux couches : le substrat et le harnais

L'idée est simple : la question « quel modèle » est séparée de la question « comment le travail est fait ». DXC appelle la couche basse le substrat (substrate). C'est Amazon Bedrock : une API unique vers Claude, Amazon Nova, Meta Llama et les familles open-weight. Par-dessus se trouvent les Bedrock Guardrails, avec filtrage de contenu, suppression des données personnelles et sujets interdits, identiques pour tous les modèles. Le trafic d'inférence passe par PrivateLink à l'intérieur du VPC du client, et le modèle serverless supprime le parc de GPU propre comme point de défaillance.

La couche haute est le « harnais » (harness) de DXC lui-même. L'orchestration repose sur LangGraph, en open source : un agent superviseur découpe la tâche et la répartit entre des agents spécialisés. C'est dans le harnais que se trouvent le contexte opérationnel de 60 ans de runbooks et de données ITSM, la vérification des politiques à chaque requête et le journal des actions.

Un détail important : l'endroit où passe la frontière. Les Guardrails filtrent l'entrée et la sortie du modèle, mais ne peuvent pas limiter ce que l'agent a le droit de faire sur un serveur. Seul le harnais en est capable, car cela dépend du contexte et de la responsabilité de chaque client.

À quoi cela ressemble sur un incident

Dans l'environnement de démonstration d'une compagnie aérienne fictive, le serveur FlightOps manque d'espace disque et le runbook n'aide pas. Le CIO voit l'alerte comme un risque métier, tandis que l'ingénieur Linux reçoit les mêmes données avec les détails techniques. Le superviseur établit un plan et mobilise les agents Metrics, Linux System et ITSM. Le premier confirme que le disque est rempli à 99 % et renvoie à des articles de la base de connaissances ; le second trouve un fichier temporaire de 5 Go.

Vient ensuite le moment clé : l'agent présente le plan complet, et rien n'est exécuté tant que l'ingénieur n'a pas confirmé. Il peut diagnostiquer librement, mais ne peut modifier la production qu'avec une approbation enregistrée. Le journal (ce qui a été lancé, où, qui a validé, quand) est produit par le harnais, et non par un compte rendu de l'agent lui-même.

Les pouvoirs sont organisés en quatre paliers : observer, proposer, agir avec approbation, agir dans un périmètre défini. Chaque persona démarre en read-only, et l'extension des droits est une décision délibérée, un palier à la fois.

Les chiffres et comment les lire

Depuis sa disponibilité générale (GA) en mars 2026, OASIS sert 12 personas opérationnelles (Linux, Windows, SAP, réseaux, sauvegardes, AWS, Azure et autres). D'après DXC, le temps moyen de résolution a baissé de 95 % sur 56 scénarios mesurés. Un incident de système de fichiers prenait auparavant 53 à 90 minutes, contre 3 à 6 aujourd'hui. Problèmes de base de données : de 2–3 heures à 5–12 minutes. Problem management complexe : de 2–6 jours à 8–10 minutes. La précision du diagnostic atteint 92 % et plus par rapport à l'évaluation d'ingénieurs seniors.

Ces chiffres appellent la prudence. Il s'agit d'un billet commun d'AWS et du fournisseur, sans vérification indépendante, la méthodologie de mesure « avant/après » n'est pas divulguée, et 92 % de précision signifie qu'un cas sur douze peut aboutir à un diagnostic erroné. L'approbation humaine n'est donc pas ici une simple formalité.

Conclusions pratiques pour ceux qui construisent des agents destinés à la production :

• Gardez le choix du modèle, l'orchestration et l'environnement de déploiement comme des décisions indépendantes. Ainsi, une panne du fournisseur ou la dépréciation d'un modèle se règle par un ajustement du routage. Mais une API identique ne garantit pas un comportement identique : avant d'intégrer un nouveau modèle au routage, testez-le sur vos propres jeux de tâches.
• Ne comptez pas sur le modèle pour se limiter lui-même. Les droits, les paliers d'autonomie et l'audit doivent vivre en dehors du modèle, dans le code et les politiques.
• Commencez en read-only et étendez l'autonomie tâche par tâche, et non par défaut.
• Tenez compte de la dépendance : tout le dispositif repose sur Bedrock, et l'éventail de modèles disponibles dépend de la région AWS.

La leçon principale ne concerne pas un service cloud en particulier. La sécurité d'un agent dépend de ce qu'il a le droit de faire, pas de l'intelligence du modèle. Tant que cette frontière n'est pas tracée explicitement, il est trop tôt pour déployer des agents à grande échelle sur des systèmes en production.