Goldman Sachs, Claude Code et le paradoxe des entreprises qui veulent innover

En juillet 2026, Marco Argenti, directeur des systèmes d'information de Goldman Sachs, expliquait avec enthousiasme comment des traders et des banquiers utilisaient l'intelligence artificielle pour développer leurs propres outils. Ils identifiaient un problème, construisaient un prototype grâce au vibe coding, puis le transmettaient aux ingénieurs pour le perfectionner.

Trois mois plus tard, changement de direction.

Selon Bloomberg, Goldman Sachs a modifié ses directives internes en octobre pour réserver l'accès à Claude Code et à certains outils GitHub à ses ingénieurs, avec une exception pour les profils hybrides appelés strats. Des collaborateurs qui utilisaient ces outils pour suivre des flux de transactions, modéliser des positions ou produire des analyses se retrouvent privés de certains de leurs moyens de travail.

La banque invoque une évaluation de la productivité et des risques. Elle continue par ailleurs de développer ses propres solutions d'intelligence artificielle.

Il ne s'agit donc pas d'un renoncement à l'IA.

Mais cet épisode révèle une tension qui dépasse largement le secteur bancaire : les entreprises veulent que leurs collaborateurs innovent grâce à l'intelligence artificielle, sans avoir nécessairement adapté leur organisation à ce qu'ils deviennent désormais capables de faire.

Une décision qui peut parfaitement se défendre

Il serait trop facile de présenter Goldman Sachs comme une organisation conservatrice qui aurait pris peur devant l'innovation.

Une banque d'investissement n'est pas un terrain d'expérimentation ordinaire. Les données clients sont sensibles, les transactions financières sont réglementées et certaines informations doivent rester strictement séparées entre les différentes activités.

Claude Code n'est pas simplement un assistant conversationnel. C'est un outil capable de lire des fichiers, de produire du code et d'exécuter des opérations dans les limites des autorisations qui lui sont accordées.

Entre demander à une IA de résumer un rapport financier et lui permettre de développer puis d'exécuter un programme manipulant des données de marché, la différence est considérable.

Un modèle incorrect, une mauvaise gestion des accès ou une automatisation insuffisamment contrôlée peuvent avoir des conséquences sérieuses.

Restreindre l'utilisation de ces outils peut donc être une décision parfaitement rationnelle.

Mais une décision rationnelle du point de vue du contrôle peut également produire des conséquences indésirables sur l'innovation.

Et c'est là que le cas devient intéressant.

Les collaborateurs viennent de découvrir qu'ils pouvaient construire

Pendant des décennies, le développement d'applications a largement reposé sur une séparation des responsabilités.

Les métiers exprimaient leurs besoins. Les équipes informatiques les analysaient, les priorisaient et développaient les solutions. Les délais dépendaient des ressources disponibles, de la complexité technique et des arbitrages organisationnels.

Cette séparation avait ses raisons d'être. Elle avait aussi ses limites.

Combien d'idées utiles n'ont jamais dépassé le stade d'une demande parce qu'elles étaient jugées trop petites, trop spécifiques ou insuffisamment prioritaires ?

L'IA générative change une partie de cette équation.

Un responsable commercial, un analyste financier ou un directeur opérationnel peut désormais décrire un problème dans son propre langage, explorer plusieurs approches et produire un premier prototype sans maîtriser les langages de programmation.

Cela ne fait pas de lui un ingénieur logiciel. Et cela ne garantit ni la qualité ni la sécurité de ce qu'il construit.

Mais cela change profondément son rapport à la technologie.

Il ne se contente plus de demander une solution. Il peut participer directement à sa création.

Ce déplacement est potentiellement plus important que les gains de productivité habituellement associés à l'IA.

Car les personnes les plus proches d'un problème sont souvent celles qui en connaissent le mieux les subtilités, les exceptions et les conséquences opérationnelles.

Elles ne savent pas nécessairement construire un système industriel fiable. Mais elles peuvent désormais démontrer beaucoup plus rapidement ce qui mérite d'être construit.

Le risque d'une gouvernance qui arrive après l'innovation

L'un des aspects les plus révélateurs de l'affaire Goldman Sachs est sa chronologie.

En juillet, les initiatives de vibe coding étaient présentées favorablement. En octobre, les accès étaient restreints.

Nous ne connaissons pas les détails des évaluations internes ayant conduit à cette décision. Rien ne permet d'affirmer qu'elle résulte d'un incident de sécurité, d'une dérive financière ou d'un échec particulier.

Il serait également excessif de conclure que la banque n'avait prévu aucun mécanisme de contrôle.

Mais cette succession d'événements soulève une question essentielle : que se passe-t-il lorsqu'une organisation encourage l'expérimentation avant d'avoir défini les conditions de son développement à grande échelle ?

Les collaborateurs découvrent de nouveaux usages, investissent du temps, développent des méthodes de travail et commencent à entrevoir des possibilités qu'ils n'imaginaient pas quelques mois auparavant.

Puis les règles changent.

Même lorsque ces règles sont justifiées, le signal envoyé peut être ambigu.

D'un côté, l'organisation demande aux collaborateurs d'être curieux, entreprenants et innovants. De l'autre, elle peut donner le sentiment que leurs initiatives deviennent problématiques dès qu'elles dépassent le cadre initialement prévu.

Le danger n'est pas seulement de ralentir quelques projets.

C'est de fragiliser la confiance nécessaire à l'expérimentation.

Une organisation qui souhaite développer l'initiative doit pouvoir expliquer clairement où se situent les limites, pourquoi elles existent et comment les idées prometteuses peuvent continuer à progresser.

Il existe une troisième voie entre laisser faire et interdire

Le débat est souvent présenté comme une opposition entre innovation et contrôle.

C'est une mauvaise manière de poser le problème.

La véritable question n'est pas de savoir si tous les collaborateurs doivent disposer des mêmes outils et des mêmes autorisations.

La question est de concevoir une organisation dans laquelle chacun peut contribuer à l'innovation à un niveau compatible avec ses compétences, ses responsabilités et les risques associés.

Cela suppose de distinguer trois étapes.

Ces trois étapes ne nécessitent ni les mêmes compétences ni les mêmes règles.

Le rôle de la gouvernance est précisément de permettre leur articulation.

Un prototype ne devrait pas pouvoir devenir silencieusement une application critique. Mais une idée pertinente ne devrait pas non plus être abandonnée simplement parce que son auteur ne possède pas de formation informatique.

Entre ces deux extrêmes, il existe un espace considérable pour de nouvelles formes de collaboration entre les métiers et les équipes techniques.

Le véritable changement concerne aussi le leadership

On pourrait considérer cette question comme un sujet réservé aux DSI, aux responsables de la cybersécurité et aux équipes informatiques.

Ce serait sous-estimer sa portée.

Lorsqu'un collaborateur peut concevoir une solution qu'il aurait auparavant dû demander à un autre service, les relations de travail évoluent.

Les responsabilités doivent être clarifiées. Les processus de validation doivent être adaptés. Les managers doivent apprendre à évaluer des initiatives qui n'entrent pas nécessairement dans les catégories habituelles.

Et les dirigeants doivent arbitrer entre des objectifs qui peuvent sembler contradictoires : accélérer l'innovation, protéger l'entreprise, développer l'autonomie et maintenir une maîtrise suffisante des opérations.

Ce ne sont pas seulement des décisions technologiques.

Ce sont des décisions de leadership.

Elles demandent une compréhension pratique des outils, mais également du jugement, de la confiance et une vision de l'organisation que l'on souhaite construire.

Une entreprise peut distribuer des licences d'IA à des milliers de collaborateurs sans transformer profondément sa manière de fonctionner.

À l'inverse, une organisation qui apprend à faire émerger, évaluer et développer les initiatives de ses collaborateurs peut transformer son fonctionnement sans multiplier indéfiniment les outils.

La transformation ne réside pas dans le nombre de personnes qui utilisent l'IA, mais dans ce que l'organisation apprend à rendre possible grâce à elles.

Ce que les dirigeants devraient examiner dès maintenant

Le cas Goldman Sachs invite à poser quelques questions très concrètes.

Savons-nous ce que nos collaborateurs construisent déjà avec l'intelligence artificielle, y compris en dehors des projets officiellement identifiés ?

Avons-nous défini la différence entre une expérimentation individuelle, un prototype partagé et une application utilisée dans les opérations courantes ?

Les métiers disposent-ils d'un moyen simple de faire examiner leurs prototypes et de solliciter les équipes techniques lorsqu'une idée mérite d'être développée ?

Qui devient responsable d'une solution lorsqu'elle dépasse le stade expérimental ?

Et surtout, lorsque nous décidons de restreindre un outil, prenons-nous le temps de comprendre les problèmes que les collaborateurs cherchaient à résoudre avec lui ?

Cette dernière question mérite une attention particulière.

Une restriction peut être nécessaire. Mais les besoins opérationnels qui ont conduit les collaborateurs à adopter un outil ne disparaissent pas avec la restriction.

Ils restent présents.

Une gouvernance efficace doit donc protéger l'organisation tout en préservant les apprentissages issus de l'expérimentation.

L'enjeu n'est plus seulement d'adopter l'IA

Depuis plusieurs années, les entreprises cherchent à accélérer l'adoption de l'intelligence artificielle. Elles mesurent le nombre de licences déployées, les utilisateurs actifs, les heures économisées et les gains de productivité.

Ces indicateurs ont leur utilité.

Mais ils ne répondent pas à une question plus fondamentale : sommes-nous en train de construire des organisations dans lesquelles les individus peuvent réellement prendre davantage d'initiatives, apprendre et créer de la valeur ?

Goldman Sachs n'a pas nécessairement commis une erreur en restreignant certains outils. Les risques associés aux agents capables d'écrire et d'exécuter du code justifient une gouvernance exigeante.

L'erreur serait de croire que le retour à une séparation stricte entre ceux qui imaginent les solutions et ceux qui les construisent constitue nécessairement la réponse définitive.

L'intelligence artificielle ouvre une possibilité nouvelle : rapprocher l'expérience des métiers et les moyens de création.

Cette possibilité ne dispense pas de rigueur. Elle en exige davantage.

Mais elle mérite mieux qu'un choix binaire entre liberté totale et interdiction.

Les entreprises qui réussiront leur transformation ne seront pas nécessairement celles qui donneront le plus d'outils à leurs collaborateurs. Ce seront celles qui sauront créer les conditions pour qu'ils deviennent des bâtisseurs responsables.

Et cela commence par une décision de leadership, bien avant une décision technologique.

Les faits relatifs à Goldman Sachs reposent principalement sur les informations rapportées par Bloomberg. Les analyses de gouvernance, les interprétations organisationnelles et les recommandations sont celles d'Aligned in Motion.

Aligned in Motion — Executive Advisory · Leadership · AI

A place where experienced minds become builders.