Le 11 juin 2026, Anthropic a annoncé une alliance pluriannuelle avec DXC Technology qui fait entrer Claude dans le genre de systèmes où « aller vite » veut généralement dire « rédiger d’abord un plan de rollback ». DXC affirme que Claude est déjà le modèle de fondation par défaut des workflows agentiques DXC OASIS, que Claude a contribué à accélérer la livraison logicielle d’OASIS d’un facteur estimé à 10, et que plus de 95 % du code d’OASIS a été généré par Claude avant revue par des ingénieurs (Anthropic, PRNewswire).
C’est ça, la partie intéressante. Pas « l’AI écrit du code ». Tout le monde a déjà vu cette démo. La vraie histoire, c’est que DXC emmène la génération de code agentique dans les banques, les compagnies aériennes, les assureurs, les industriels et les agences gouvernementales, là où les vrais problèmes s’appellent archéologie des dépendances, gouvernance des releases, auditabilité, sécurité, et ne pas casser un traitement batch vieux de 30 ans qui règle de vraies transactions à 2 h du matin.
Le Signal : l’AI entre dans la couche managed services
DXC a lancé OASIS le 28 avril 2026 comme plateforme d’orchestration intelligente pour les services managés. Sa mission déclarée : servir de couche gouvernée et sécurisée au-dessus du patrimoine IT existant d’une organisation, pour faire passer les opérations du support réactif à l’exécution en temps réel (DXC).
C’est important parce que, dans les secteurs réglementés, la modernisation commence rarement avec un dépôt propre et une cible greenfield. Elle commence avec :
- des jobs batch que plus personne ne possède vraiment
- des serveurs applicatifs sortis des fenêtres de support normales
- du COBOL, du Java EE, du PL/SQL, du shell et de la glue de workflows éditeurs
- des contrôles de conformité à moitié dans le code et à moitié dans des runbooks
- des intégrations fragiles aux systèmes de paiement, de sinistres, de réservation, d’inventaire, d’identité ou de gestion de dossiers
Mettre Claude dans OASIS signifie que DXC ne traite pas le modèle comme un chatbot posé à côté du travail. Il place le modèle dans des workflows d’orchestration qui connaissent déjà les incidents, les fenêtres de changement, le contexte des tickets, les runbooks, les environnements et les contraintes client. C’est la différence entre « générer un refactor » et « générer un refactor capable de survivre à une revue CAB ».
Anthropic indique que DXC formera des dizaines de milliers d’ingénieurs déployés sur le terrain et certifiés Claude via Anthropic Academy, DXC ajoutant son propre cursus pour les systèmes critiques (Anthropic). C’est la bonne forme. La modernisation réglementée a besoin de gens capables de lire le système, pas de touristes du prompt.
Ce que les développeurs devraient copier
Le modèle DXC est utile même si vous ne travaillez pas à l’échelle de DXC. La leçon n’est pas « laissez le modèle posséder le dépôt ». La leçon, c’est : encadrez le travail du modèle dans un workflow où le contexte, les contraintes, la revue et les preuves sont des objets de première classe.
Un agent de modernisation legacy sérieux ne devrait pas commencer par « réécris ce service en Go ». Il devrait commencer par un plan contraint :
1. Inventory modules, entry points, data stores, and external contracts.
2. Identify dead code and risk hotspots.
3. Propose the smallest behavior-preserving refactor.
4. Generate tests around current behavior before changing code.
5. Open a reviewable patch with traceable rationale.
6. Attach evidence: tests, static analysis, dependency impact, rollback notes.Ça paraît ennuyeux. Parfait. C’est avec de l’ennui qu’on modifie des systèmes réglementés.
Les chiffres publics de DXC sont agressifs : livraison logicielle estimée 10 fois plus rapide et plus de 95 % de code généré par Claude pour OASIS, revu par des ingénieurs (Anthropic). Prenez-les comme des affirmations propres à un déploiement, pas comme une constante universelle de productivité. Pour les développeurs, le point clé est le modèle opérationnel : forte contribution du modèle, revue humaine obligatoire, et une plateforme qui enregistre le travail.
Pour une migration de cœur bancaire, cela peut vouloir dire que des agents cartographient les flux de transaction et génèrent des tests de caractérisation. Pour une compagnie aérienne, des agents pourraient démêler des workflows de réservation ou de maintenance tout en préservant les formats de messages externes. Pour un assureur, ils peuvent comparer les règles d’administration des polices au comportement des sinistres. Pour les industriels, ils peuvent tracer les dépendances ERP, MES et supply chain avant de toucher au code.
Le choix du modèle devient une décision d’architecture
Deux jours avant l’annonce DXC, Anthropic a lancé Claude Fable 5 et Claude Mythos 5 le 9 juin 2026. Fable 5 est le modèle de classe Mythos généralement disponible d’Anthropic, tandis que Mythos 5 est restreint via Project Glasswing et des programmes d’accès de confiance. Anthropic affiche Fable 5 à 10 $ par million de tokens en entrée et 50 $ par million de tokens en sortie, avec une fenêtre de contexte de 1M de tokens et une sortie maximale de 128k dans la documentation API actuelle (Anthropic, Claude Docs).
Un aperçu compact des prix tiré de la vue d’ensemble des modèles d’Anthropic :
| Modèle | Entrée | Sortie | Contexte | Sortie max |
|---|---|---|---|---|
| Claude Fable 5 | $10 / MTok | $50 / MTok | 1M tokens | 128k |
| Claude Opus 4.8 | $5 / MTok | $25 / MTok | 1M tokens | 128k |
| Claude Sonnet 4.6 | $3 / MTok | $15 / MTok | 1M tokens | 64k |
| Claude Haiku 4.5 | $1 / MTok | $5 / MTok | 200k tokens | 64k |
La mauvaise conclusion serait « utilisez toujours le modèle le plus puissant ». La meilleure architecture, c’est le routage de modèles.
Utilisez le modèle le plus puissant pour le raisonnement au niveau système : découverte de dépendances, planification de migration, frameworks inconnus, refactors multi-dépôts et analyse de pannes. Utilisez des modèles moins chers pour la synthèse, la génération de tests simples, le nettoyage de documentation et les modifications mécaniques. Entourez les deux de tools déterministes : compilateurs, test runners, tools de diff de schémas, SAST, génération de SBOM et contrôles de politique.
Anthropic indique aussi que Fable 5 dispose de garde-fous qui basculent vers Claude Opus 4.8 pour certaines requêtes liées à la cybersécurité, à la biologie, à la chimie ou à la distillation, et que les premières données montrent que plus de 95 % des sessions Fable n’ont aucun fallback (Anthropic). Pour les développeurs en environnement réglementé, ce n’est pas une note de bas de page. Si un workflow touche à la remédiation sécurité, à l’analyse de vulnérabilités ou à de la recherche sensible, votre runtime agentique doit détecter le fallback de modèle, le journaliser et décider si la sortie obtenue respecte encore votre niveau d’assurance.
La revue humaine est le produit, pas la taxe
L’expression « plus de 95 % de code généré par Claude » fera les gros titres. L’expression « puis revu par des ingénieurs logiciel » est la partie qui rend tout ça déployable.
Dans la modernisation réglementée, la revue n’est pas une approbation cérémonielle de pull request. Elle doit répondre à des questions concrètes :
- Le comportement a-t-il changé, et où sont les preuves de test ?
- Quels contrats de données, schémas, APIs et fichiers batch sont touchés ?
- Le patch modifie-t-il l’autorisation, la rétention, la journalisation ou les traces d’audit ?
- Existe-t-il un chemin de rollback ?
- Une personne qui n’a pas écrit le changement peut-elle comprendre dans six mois pourquoi il existe ?
C’est là que les workflows agentiques battent le chat libre. Un bon workflow peut obliger chaque patch généré à porter sa propre explication, son plan de test, sa classification de risque et sa carte des systèmes affectés. Il peut aussi bloquer les merges quand le modèle n’a pas inspecté un service dépendant ou quand les tests générés ne prouvent que le happy path.
La compétence développeur se déplace : on ne tape plus chaque ligne, on conçoit des paquets de travail revoyables. C’est toujours de l’ingénierie. Dans beaucoup de patrimoines legacy, c’est même l’ingénierie qui manquait.
Un petit pattern pour la modernisation agentique
Si je devais construire ça dans une équipe logicielle réglementée, je demanderais à chaque tâche de modernisation de produire quatre artefacts avant la revue de code :
inventory.md: points d’entrée, dépendances, configs, data stores, contrats externes.risk.md: processus métier affecté, contrôles de conformité touchés, notes de rollback.tests/: tests de caractérisation qui verrouillent le comportement actuel.patch.diff: le plus petit changement qui préserve le comportement.
Le modèle peut générer les quatre. Les ingénieurs devraient revoir les quatre. La CI devrait faire respecter les parties ennuyeuses.
Pour des expériences locales, Claude Fable 5 est aussi disponible comme endpoint Anthropic Messages compatible via OneHop. La page Fable 5 de OneHop liste actuellement l’endpoint https://api.onehop.ai/anthropic, le nom de modèle anthropic/claude-fable-5, et un crédit de 10 $ pour les nouveaux comptes sans carte requise ; le prix promotionnel affiché est de 5 $ en entrée et 25 $ en sortie par million de tokens, soit plus de 30 % sous le prix catalogue Anthropic de 10 $/50 $ (OneHop).
from anthropic import Anthropic
client = Anthropic(
base_url="https://api.onehop.ai/anthropic",
api_key="<ONEHOP_KEY>",
)
message = client.messages.create(
model="anthropic/claude-fable-5",
max_tokens=1024,
messages=[{"role": "user", "content": "Map risks in this legacy migration plan."}],
)Utilisez ce genre d’endpoint pour les prototypes et les harnais d’évaluation. Pour les workloads réglementés en production, la partie difficile reste vos contrôles : traitement des données, rétention, accès, preuves, routage de modèles et validation humaine.
Le vrai pari : la modernisation devient continue
La plupart des entreprises traitent la modernisation legacy comme un programme qu’on lance une fois par décennie. Gros budget. Gros intégrateur. Gros risque. Puis la nouvelle plateforme commence à vieillir dès le premier jour.
L’histoire OASIS de DXC pointe vers un meilleur modèle : la modernisation comme workflow continu de managed service. Les agents inspectent, proposent, testent, refactorent, documentent et routent le travail vers les ingénieurs. Les ingénieurs relisent, contraignent et approuvent. La plateforme conserve les preuves. Le système s’améliore par incréments plus petits et plus sûrs.
C’est pour ça que cette alliance mérite d’être suivie. La bonne question n’est pas de savoir si Claude peut écrire du code. Il le peut. La bonne question est de savoir si une organisation peut transformer du code généré en changement gouverné, revoyable et sûr pour la production, à travers des systèmes qui ne peuvent pas tomber.
DXC revendique de premiers signaux montrant que cela peut fonctionner à grande échelle : 115 000 employés dans 70 pays, OASIS en production chez plus de 50 clients, des dizaines de milliers d’ingénieurs déployés sur le terrain et certifiés Claude prévus, et Claude comme modèle par défaut dans les workflows agentiques OASIS (Anthropic, PRNewswire).
Pour les développeurs, le mouvement est clair : arrêtez de penser l’AI comme de l’autocomplete. Commencez à concevoir des workflows agentiques qui laissent derrière eux des tests, des diffs, des explications et des traces d’audit. C’est ce dont la modernisation legacy a toujours eu besoin. Le modèle rend enfin la paperasse et le mouvement du code assez peu coûteux pour les faire en continu.
Si vous voulez tester la partie routage de modèles sans monter toute une stack enterprise, commencez avec un dépôt étroit, une tâche de tests de caractérisation, et un endpoint Fable 5 comme Claude Fable 5 sur OneHop. Gardez la porte de revue humaine. Mesurez les diffs acceptés, les tests échoués, le temps de revue, la qualité du rollback et le coût par changement mergé. Ensuite, décidez si le workflow a mérité un système plus grand.
