Claude Code chez Goldman Sachs : accès restreint
Pourquoi Goldman Sachs réserve-t-elle Claude Code à ses ingénieurs ? Analyse des risques, des usages métier et des règles à poser avant de déployer un agent IA.
Goldman Sachs reprend Claude Code aux traders : le vrai sujet, c'est la responsabilité
Donner un agent de programmation à un trader peut sembler être une façon simple de gagner du temps : la personne la plus proche du problème produit un premier outil, puis les équipes techniques le consolident. Chez Goldman Sachs, cette logique a pourtant été stoppée net.
D'après Bloomberg, des consignes internes mises à jour en octobre réservent Claude Code et les outils de programmation de GitHub aux ingénieurs. Les banquiers et la majorité des traders n'y auraient donc plus accès, même si certains s'en servaient déjà pour suivre des flux clients ou modéliser des positions.
Le contraste est frappant : en juillet, le directeur informatique de la banque, Marco Argenti, saluait encore des outils créés par des équipes non techniques avec l'IA. Ici, ce n'est pas seulement un changement de produit. Le sujet, c'est la gouvernance : qui a le droit de laisser un agent produire du code, qui vérifie ce code, et qui porte la responsabilité quand il s'en sert dans une activité sensible. C'est aussi ce que cette décision met en lumière : comment encadrer ces usages sans étouffer les gains de terrain.
Pourquoi Goldman Sachs a-t-elle restreint Claude Code ?
Bloomberg indique que les consignes d'octobre limitent l'accès à Claude Code et aux outils de programmation de GitHub aux ingénieurs de Goldman Sachs. Les équipes de « strats » - à l'interface entre trading, recherche quantitative et développement logiciel - conserveraient cet accès. Concrètement, la restriction vise surtout les collaborateurs qui utilisent ces agents sans appartenir à une équipe d'ingénierie.
La banque ne présente pas la mesure comme un rejet de l'IA en général. Nick Carcaterra, son porte-parole, affirme que certains outils restent mis à disposition des employés pour identifier des cas d'usage. Goldman garde aussi un assistant interne basé sur des modèles fournis par plusieurs acteurs. La différence est importante : la règle concerne les agents tiers capables d'écrire et d'exécuter du code, pas tous les outils d'IA générative.
Un changement de périmètre, pas un abandon de l'IA
Entre un assistant qui répond à des questions et un agent qui lit des fichiers, produit un programme puis l'exécute, le niveau de risque n'est pas le même. Le second peut agir sur des données et des systèmes, avec les autorisations de la personne qui le pilote. C'est justement pour ça qu'une entreprise peut garder un assistant conversationnel tout en restreignant un agent de programmation.
Le même raisonnement se retrouve dans d'autres restrictions appliquées selon le contexte. En avril, Goldman avait retiré Claude de sa plateforme interne pour ses banquiers à Hong Kong. Le Financial Times expliquait alors que l'interprétation du contrat avec Anthropic entrait en jeu ; Anthropic indiquait de son côté que Claude n'avait jamais été officiellement pris en charge dans cette région. ChatGPT et Gemini restaient accessibles. Et, selon les informations disponibles à l'époque, JPMorgan avait aussi retiré Claude de sa liste d'outils approuvés à Hong Kong en juin.
Bref : en avril, le facteur déterminant était le lieu et le cadre contractuel ; en octobre, c'est le rôle. Dans les deux cas, le vrai nerf de la guerre est le même : définir où l'outil peut être utilisé, avec quelles données, et sous quelle responsabilité. Une politique floue finit forcément soit par bloquer des usages utiles, soit par laisser des risques sans propriétaire clairement identifié.
Quels risques pose le vibe coding sur un desk ?
Ici, le « vibe coding » désigne le fait de créer un logiciel en décrivant une tâche à un agent, qui génère ensuite le code. Pour obtenir un prototype vite fait, c'est redoutablement efficace. Le problème, c'est que le résultat n'est pas automatiquement fiable, compréhensible, ni adapté à un usage régulier.
Sur un desk, un petit script peut rapidement devenir un outil quotidien, sans passer par les étapes que l'entreprise réserve d'ordinaire aux logiciels : revue, tests, validation, déploiement contrôlé.
Les traders qui auraient utilisé ces outils s'en servaient notamment pour surveiller les flux de négociation des clients, modéliser des mouvements de marché ou des positions, et préparer des documents écrits ou des visuels. Ce sont des besoins concrets. Et ce sont aussi des domaines où une erreur de calcul, une hypothèse mal traduite en code ou un accès trop large aux données peut coûter cher - financièrement, opérationnellement, et même en termes de conformité.
Le code hérite des droits de son utilisateur
Un agent de programmation peut manipuler les fichiers accessibles à la personne qui le pilote. Si cette personne a accès à des informations sensibles, l'agent peut potentiellement les lire ou les intégrer à un traitement. D'où l'idée à retenir : ces outils ne devraient pas être traités comme de simples fenêtres de discussion.
Dans une banque, il faut garder les barrières d'information entre équipes. Les informations détenues par une équipe impliquée dans une opération ne doivent pas circuler sans contrôle vers des activités de marché qui pourraient en tirer profit. Un code bricolé sur un poste de travail n'est pas forcément conçu pour respecter ces séparations. Et si une revue technique arrive trop tard, elle ne sert qu'à constater le problème - encore faut-il que le code ait été déclaré et transmis aux équipes responsables.
Un code qui fonctionne n'est pas forcément un code maîtrisé
Même un développeur expérimenté peut avoir du mal à expliquer tous les choix d'un programme généré automatiquement. Pour un utilisateur sans formation en développement, vérifier les cas limites devient encore plus difficile. Or, sur un desk, les cas rares sont souvent ceux qui posent les vrais problèmes : format de données inattendu, marché très volatil, instrument atypique, ou résultat qui ne correspond plus à la réalité mais qu'on continue d'utiliser comme s'il était à jour.
À cela s'ajoute le coût. Les agents peuvent être facturés selon leur consommation, notamment en jetons. Si l'usage se diffuse sans suivi, la facture peut monter sans rapport clair avec la valeur produite.
Au fond, le risque n'est pas uniquement « l'IA peut se tromper ». Il faut évaluer l'accès aux données, la robustesse du résultat, la traçabilité, le coût - et la capacité à arrêter ou corriger l'outil quand quelque chose cloche.
Pourquoi la décision semble-t-elle contradictoire ?
En juillet, Marco Argenti décrivait favorablement les outils que des équipes de métiers utilisaient déjà avec l'IA. Selon Bloomberg, ces équipes pouvaient produire une première version, puis la transmettre aux ingénieurs pour amélioration. En octobre, les consignes réservant les agents de code aux ingénieurs et à certaines équipes de strats créent un contraste réel. Mais ça ne prouve pas, à lui seul, que la banque renonce à ces usages.
Le modèle de départ répond à une difficulté classique dans les grandes entreprises : les équipes d'ingénierie ne peuvent pas absorber toutes les demandes au rythme des métiers. L'utilisateur le plus proche peut préciser le besoin et bâtir un prototype sans attendre une place dans la file de développement. Ça crée une boucle de retour utile : le prototype rend la demande plus concrète, et aide à prioriser.
Le prototype et l'outil de production ne sont pas la même chose
Là où ça se complique, c'est quand une version exploratoire devient un outil régulier. Un script de suivi utilisé une fois pour tester une idée n'a pas le même impact qu'un outil sur lequel une équipe s'appuie tous les jours, pour décider ou communiquer. La frontière peut être franchie progressivement : pas besoin d'une décision formelle, parfois c'est juste parce que ça marche et que ça fait gagner du temps.
Une restriction globale est alors compréhensible côté contrôle : elle réduit le nombre de personnes capables de produire du code exécutable. Mais elle peut aussi couper des usages utiles sans proposer de solution de remplacement. Les traders frustrés - selon une source citée par Bloomberg - signalent peut-être autant un besoin opérationnel qu'une attache à un outil précis. Et si la banque ne capte pas ces besoins, ils peuvent rester dans des tableurs, des scripts non suivis ou des processus manuels moins visibles.
Le contexte commercial ne suffit pas à expliquer
À l'automne, Goldman et Morgan Stanley étaient présentés comme chefs de file de l'introduction en Bourse d'Anthropic, d'après le dépôt de documents mentionné dans les informations disponibles à ce moment-là. Anthropic envisageait une cotation au Nasdaq sous le symbole ANT avant fin novembre. Forcément, ça donne l'impression qu'on a affaire à un paradoxe : des banquiers susceptibles de commercialiser les titres d'une entreprise dont l'agent de code n'est, pour beaucoup, plus accessible.
Mais cette proximité ne permet pas de conclure que la restriction est motivée par le lien avec Anthropic, ni qu'elle vise à soutenir un concurrent. Les éléments rapportés pointent plutôt vers un arbitrage entre productivité et risques. La leçon pour les dirigeants reste assez générale : quand on passe d'une phase d'expérimentation encouragée à de nouvelles règles, il faut expliquer ce qui change - clairement - et distinguer les usages. Sinon, tout le monde interprète la décision comme une punition, pas comme une mise en conformité.
Ce que les banques doivent décider avant de déployer un agent
Goldman compte environ 12 000 ingénieurs sur quelque 47 000 salariés, selon les chiffres mentionnés dans le contexte de l'annonce. Marco Argenti décrivait l'adoption de l'IA comme un mouvement « par vagues », la première regroupant les développeurs. Les consignes d'octobre rapprochent les autorisations de ce périmètre.
Barclays, de son côté, a indiqué vouloir équiper une partie importante de ses développeurs de Claude Code, tout en annonçant des suppressions de postes. Ces approches différentes rappellent une chose : l'agent peut être vu à la fois comme un outil de productivité et comme un facteur de réorganisation des équipes.
Pour les établissements européens, la question ne peut pas se résumer à choisir un modèle. Il faut décider qui peut lancer l'agent, où il s'exécute, à quelles données il accède, comment ses actions sont enregistrées, et qui répond du résultat. Les mêmes questions reviennent que ce soit un grand groupe bancaire, une fintech française, ou une équipe métier qui automatise une tâche avec un outil de génération de code.
Une décision pratique à prendre en cinq points
Avant d'ouvrir l'accès à un agent de programmation, une équipe dirigeante peut vérifier :
- Usage défini : quelle tâche précise l'agent doit-il accélérer, et quel indicateur montrera le gain ?
- Données autorisées : l'agent peut-il lire des informations clients, des données de marché ou des documents internes ? Les règles varient selon l'environnement et le fournisseur.
- Niveau d'action : l'outil suggère-t-il seulement du code, ou peut-il aussi l'exécuter et modifier des fichiers ? Plus il agit, plus les contrôles doivent être stricts.
- Responsable identifié : qui vérifie l'outil et répond de son usage une fois la personne qui l'a créé partie ?
- Coût et arrêt : comment mesurer la consommation, repérer les usages sans valeur et suspendre rapidement l'agent en cas de problème ?
Et lorsqu'un accès est retiré, il faut aussi documenter les tâches qui dépendaient de cet accès. Dans le cas de Goldman, les usages évoqués concernaient notamment le suivi des flux clients et la modélisation de positions. Les besoins ne disparaissent pas avec l'outil : il faut décider s'ils repassent du côté de l'ingénierie, s'ils sont couverts par une solution approuvée, ou s'ils sont abandonnés parce que le risque l'emporte sur le bénéfice.
À retenir : un agent de code ne doit pas être gouverné uniquement par le métier ou uniquement par l'IT. Le métier précise le besoin ; l'ingénierie s'assure que le logiciel reste compréhensible et maintenable ; les fonctions de contrôle fixent les conditions d'usage adaptées au risque.
Conclusion
La décision de Goldman Sachs met en évidence un problème de gouvernance plus large que le simple choix de Claude Code : des outils capables d'écrire et d'exécuter du code ne se gèrent pas comme de simples assistants de rédaction. Ils peuvent accélérer l'expérimentation, mais aussi produire des logiciels plus difficiles à auditer, avec des accès et des effets bien réels.
Réserver ces agents aux ingénieurs peut être une mesure de prudence raisonnable. Mais si la restriction doit durer, il faut aussi un processus clair : recueillir les besoins côté métier, distinguer le prototype de la production, et attribuer une responsabilité nette sur le code. Avant de déployer un agent, décidez donc qui peut l'utiliser, sur quelles données, avec quel niveau de contrôle - et au nom de qui. C'est ce choix, plus que le nom du modèle, qui dira si le gain de productivité tient dans le temps.
Comment encadrer les agents de code en entreprise ?
La réponse n'est pas forcément de donner un agent à tout le monde, ni de le réserver définitivement aux développeurs. Le bon réflexe, c'est de répartir les droits selon la capacité d'action de l'outil et la sensibilité de l'usage. Un collaborateur peut être autorisé à produire un prototype local à partir de données fictives, sans être autorisé à connecter l'agent à des données clients, ni à utiliser le résultat dans une décision opérationnelle.
Cette séparation aide à garder la proximité métier sans mélanger expérimentation et production. Mais elle ne tient pas toute seule : il faut des règles explicites. Une politique du type « utilisez l'IA de manière responsable » ne dit ni quelles données sont autorisées, ni quel niveau de contrôle est requis, ni qui doit valider avant la mise en service.
Un parcours en quatre niveaux
Une organisation peut classer les usages selon leur impact, puis ajouter des contrôles proportionnés :
Ce cadre évite de demander le même niveau d'effort pour un graphique interne et pour un calcul de position susceptible d'influencer une transaction. Il rend aussi la discussion plus factuelle : à quel niveau l'outil se situe, et qu'est-ce qui doit changer pour passer au niveau suivant ?
Nommer un responsable avant le passage en production
Dès qu'un outil quitte le stade du prototype, il doit avoir un propriétaire métier et un responsable technique. Le premier valide le besoin, les utilisateurs visés et les conséquences d'une erreur. Le second valide la conception, les tests, les accès et la maintenance.
Dans un environnement régulé, les équipes sécurité, conformité ou gestion du risque doivent être impliquées selon la nature des données et des décisions.
Et surtout : les contrôles existants doivent s'appliquer au code généré par l'agent. Cela inclut séparation des rôles, autorisations sur les données, revue logicielle, suivi des changements, et possibilité de revenir à une version connue. Le RGPD et les exigences européennes de résilience opérationnelle - notamment DORA pour les entités concernées - ne se limitent pas à une validation d'un outil d'IA. Ils font partie d'un ensemble de responsabilités plus large : données, prestataires, systèmes.