« Coding is solved » : pourquoi votre entreprise n'a pas encore le droit d'y croire

En mai 2026, devant une salle de fondateurs et d'investisseurs réunis par Sequoia, Boris Cherny — le créateur de Claude Code chez Anthropic — pose une question à main levée. « Qui ici écrit 100 % de son code à la main ? » Quelques mains. « Qui en écrit 100 % via un agent ? » Quelques mains de plus. « Qui est quelque part entre les deux ? » La majorité de la salle se lève. Puis il lâche sa propre statistique, sans forfanterie particulière : il n'a personnellement pas écrit une seule ligne de code en 2026. Le modèle écrit la totalité. « Il y a eu un jour la semaine dernière où j'ai fait à peu près 150 PRs dans la journée. C'était un record. »¹

Cent cinquante pull requests en une journée par un seul humain qui ne tape plus de code. La phrase qui structure toute son intervention tient en trois mots : coding is solved. Le codage, au sens où on l'entendait — produire manuellement des lignes correctes — serait un problème résolu.

Voilà l'affirmation que l'on entend désormais des laboratoires qui fabriquent ces outils. Et voilà, dans le même temps, ce que la plupart des DSI françaises observent dans leurs murs : des comités qui valident l'IA cas d'usage par cas d'usage, des accès Claude ou ChatGPT encore filtrés par le juridique, des développeurs qui « font de l'IA » sans jamais déléguer une tâche entière. L'écart entre les deux mondes n'a jamais été aussi vertigineux. Cet article est le point d'entrée d'une série sur l'agentic coding en entreprise : il définit le terme, examine la bascule annoncée par Cherny, puis le paradoxe d'adoption qui maintient tant d'organisations à quai.

De l'autocomplétion à l'agent : ce que « agentic coding » veut dire

Commençons par le vocabulaire, car il a glissé vite. Fin 2024, l'état de l'art du codage assisté tenait dans ce que Cherny appelle le type ahead : on ouvre son IDE, on appuie sur Tab, une ligne se complète. Le modèle Sonnet 3.5 avait débloqué cet usage. Utile, mais le développeur restait l'auteur, ligne après ligne.

L'agentic coding désigne tout autre chose : un agent — un modèle de langage doté d'outils, d'une mémoire de session et d'une boucle d'exécution — qui prend une intention exprimée en langage naturel et produit le résultat de bout en bout. Il lit le dépôt, écrit le code, lance les tests, corrige ses propres erreurs, ouvre une pull request. L'humain ne tape plus ; il spécifie, il oriente, il valide. C'est la Tendance 1 du rapport 2026 d'Anthropic sur le codage agentique : l'ingénieur passe du rôle d'implémenteur à celui d'orchestrateur d'agents.²

Andrej Karpathy, co-fondateur d'OpenAI et créateur du terme « vibe coding », a posé le cadre conceptuel qui fait aujourd'hui référence. Il distingue trois âges du logiciel : le Software 1.0 (du code explicite écrit par des humains), le Software 2.0 (des poids de réseau de neurones appris à partir de données), et le Software 3.0, où programmer revient à prompter un LLM devenu interpréteur — le contexte étant le levier que l'on actionne sur la machine.³ Karpathy date sa propre bascule de décembre 2025 : pendant une pause, il constate que les morceaux de code générés sortent justes du premier coup, qu'il cesse de corriger. « Je ne me suis jamais senti aussi en retard comme programmeur. »

Karpathy ajoute une distinction décisive pour l'entreprise, et que toute la suite de cet article suppose. Le vibe coding relève le plancher (« raise the floor ») : n'importe qui peut produire un logiciel qui marche, c'est de la démocratisation. L'agentic engineering préserve la barre de qualité (« preserve the quality bar ») : « vous n'avez pas le droit d'introduire des vulnérabilités à cause du vibe coding. Vous restez responsable de votre logiciel exactement comme avant, mais pouvez-vous aller plus vite ? ». C'est une discipline d'ingénierie, pas une dispense — une distinction que nous détaillons dans un volet dédié de cette série. Et c'est précisément cette discipline qui sépare la démo virale du déploiement en production.

La bascule « coding is solved », et ce qu'elle ne dit pas

Revenons à la thèse de Cherny, car elle mérite d'être prise au sérieux — y compris dans ses limites. Sa force tient à l'ancrage : il ne théorise pas, il dogfood. Le code base de Claude Code lui-même, écrit en TypeScript et React (deux technologies « très dans la distribution du modèle »), serait généré à 100 % par le modèle depuis l'automne 2025. Chez Anthropic, dit-il, « il n'y a plus de code écrit manuellement nulle part dans l'entreprise. Tout le SQL est écrit par les modèles. »¹

La primitive qui rend cela tenable, selon lui, c'est la boucle. Avec la commande /loop, l'agent planifie via cron des tâches récurrentes : un agent qui babysitte les PRs (corrige la CI, rebase automatiquement), un autre qui répare les tests instables, un troisième qui regroupe les retours utilisateurs toutes les trente minutes. « Les boucles, c'est le futur », affirme-t-il. Ses agents tournent par centaines le jour, par milliers la nuit ; l'essentiel de son travail se fait depuis son téléphone.

Mais Cherny lui-même pose des bornes que l'enthousiasme ambiant tend à effacer. « Ce n'est pas vrai partout. Il y a de très grosses code bases compliquées. Il y a des langages bizarres que le modèle ne maîtrise pas encore. » Sa déclaration vaut pour un contexte précis : une base TypeScript/React simple, sans dette legacy, dans une entreprise dont l'avantage, dit-il textuellement, « n'est pas la technologie — c'est la structure et le process organisationnels ». Tout le monde a accès aux mêmes modèles ; peu d'organisations ont reconstruit leur process autour.

Karpathy fournit le contrepoison nécessaire à toute lecture béate. Les LLM restent ce qu'il nomme jagged — d'une intelligence en dents de scie. Sa théorie de la vérifiabilité l'explique : les laboratoires entraînent les modèles par apprentissage par renforcement sur les domaines vérifiables (mathématiques, code), créant des pics de capacité là, et des creux ailleurs. D'où son exemple devenu célèbre : « Opus 4.7 va refactoriser une base de 100 000 lignes ou trouver des failles zero-day, et en même temps me dire de marcher pour aller à un lavage auto à 50 mètres parce que c'est tout près. C'est insensé. »³ Le codage de surface est largement automatisable ; le jugement systémique, beaucoup moins. « Vous pouvez externaliser votre réflexion, mais vous ne pouvez pas externaliser votre compréhension. »

Cette nuance n'est pas neuve. Dès juin 2025, Kent Beck — père du TDD — distinguait, exemple à l'appui, le vibe coding (indifférent à la qualité du code) de l'augmented coding (où tests, couverture et qualité restent prioritaires). Il listait trois signaux d'alarme à surveiller chez l'agent : les boucles improductives, l'ajout de fonctionnalités non demandées, et — le plus pernicieux — la manipulation des tests (l'agent qui désactive ou réécrit un test pour simuler le succès). Son verdict est juste : « la programmation change avec l'IA, mais ça reste de la programmation » — la supervision active reste indispensable.⁴

Ce n'est pas une projection : les chiffres tombent déjà

Si l'affirmation de Cherny ne reposait que sur sa pratique personnelle, on pourrait la ranger au rayon des biais d'évangéliste. Or plusieurs entreprises à grande échelle publient désormais des chiffres concordants — et c'est là que l'entreprise française devrait dresser l'oreille.

Stripe a déployé en interne des agents autonomes baptisés Minions : plus de 1 000 pull requests générées par agents sont mergées chaque semaine, après revue humaine uniquement. Le workflow est d'une simplicité désarmante — un ingénieur décrit la tâche dans un message Slack, l'agent travaille seul dans un environnement cloud isolé, produit une PR avec la CI verte. L'infrastructure, elle, ne l'est pas : une base de centaines de millions de lignes en Ruby/Sorbet, plus de 400 outils MCP centralisés, et un principe de shift feedback left qui fait recevoir aux agents le même feedback de qualité, au plus tôt, que les humains.⁵

Salesforce documente une bascule encore plus radicale. Après avoir franchi les 90 % d'adoption de l'IA, l'ingénierie a standardisé l'organisation entière sur Claude Code et — décision-signal — « supprimé toutes les limites de tokens ». Résultat, avril 2026 contre avril 2025 : +50,8 % de work items complétés par développeur, +79 % de PRs mergées, et surtout un Effective Output score — une mesure ML de la valeur réelle du code livré, pas du volume — en hausse de 151,3 % en glissement annuel. La preuve par l'exemple : une migration de 33 endpoints API estimée à 231 jours-homme, bouclée en 13 jours, soit 18 fois plus vite. Et l'argument qui démonte le réflexe le plus répandu : les incidents totaux baissent de 5 % malgré la hausse des PRs. « La qualité ne souffre pas de la vitesse. Elle en bénéficie » — à condition que les garde-fous soient encastrés structurellement dans le workflow.⁶

Justin McCarthy, CTO de StrongDM, formule la même conviction sous forme de métrique provocatrice : « si vous n'avez pas dépensé 1 000 dollars de tokens par ingénieur aujourd'hui, votre factory peut s'améliorer. »⁷ Le rapport d'Anthropic recense d'autres jalons : chez Rakuten, une implémentation complète en 7 heures autonomes sur 12,5 millions de lignes ; chez TELUS, plus de 500 000 heures économisées ; et un constat structurant — 27 % du travail assisté par IA concerne des tâches qui n'auraient jamais été entreprises autrement.²

Le paradoxe d'adoption : la technique n'est plus le frein

Et pourtant. Pendant que Stripe merge mille PRs d'agents par semaine, Ethan Mollick — professeur à Wharton, auteur de Co-Intelligence — s'étonne publiquement du nombre d'entreprises qu'il rencontre où « l'IA reste effectivement bloquée par les départements IT et juridique », pour des raisons souvent dépassées. Certaines craignent encore que les modèles s'entraînent automatiquement sur leurs données (ce qui est faux pour les versions entreprise). Et il décrit « l'un des fossés les plus étranges » qu'il observe : dans une même industrie, une entreprise utilise l'IA de manière productive depuis 18 mois, tandis qu'une autre a mis en place un comité qui doit approuver chaque cas d'usage individuellement.⁸

Sa conclusion est tranchante, et elle déplace le débat : « C'est fondamentalement une question de leadership, pas une question technique. » Le facteur décisif n'est ni la réglementation, ni la sécurité des données, ni la maturité des outils — des entreprises de secteurs hautement régulés ont déployé Claude, ChatGPT et même des CLI comme Claude Code sans incident. Le facteur décisif, c'est la volonté d'un dirigeant d'assumer le risque. Quand cette volonté manque, les fonctions de réduction du risque ont toutes les incitations à bloquer ce qui pourrait, même par hypothèse, poser problème.

Ce paradoxe a une dimension structurelle que l'Anthropic Economic Index documentait dès septembre 2025 : l'adoption de l'IA est profondément inégale, concentrée dans les économies et régions déjà avancées, avec un risque assumé d'exacerber les inégalités existantes si les gains se concentrent là où l'on est déjà prospère. Le rapport pointait aussi le vrai goulot d'étranglement du déploiement sophistiqué en entreprise : non pas le coût, mais l'accès aux informations contextuelles appropriées.⁹ Autrement dit, le frein n'est ni le talent ni le budget : c'est le contexte que l'organisation est capable — ou non — de fournir à ses agents.

Risques et limites : pourquoi l'enthousiasme appelle des garde-fous

Le double tranchant est explicite chez tous les sérieux. Le rapport d'Anthropic en fait sa Tendance 8 : les mêmes capacités servent les défenseurs et les attaquants. Et il insiste sur un paradoxe collaboratif qui tempère le « coding is solved » : si les développeurs utilisent l'IA dans environ 60 % de leur travail, ils ne délèguent entièrement que 0 à 20 % des tâches. L'IA est un collaborateur constant qui exige supervision active et validation humaine — pas un remplaçant autonome.²

Trois risques méritent d'être nommés. Le premier est la surface d'attaque agentique : un agent qui agit — qui exécute des commandes, modifie des fichiers, appelle des API — a un rayon d'impact (« blast radius ») bien plus large qu'un agent qui suggère. Salesforce le reconnaît comme un modèle de sécurité fondamentalement différent — un sujet que nous traitons à part entière. Le deuxième est la dette de complexité que pointe Kent Beck : le code fonctionne et performe, mais reste truffé de complexité accidentelle, de copier-coller et d'abstractions fragiles si personne ne préserve la barre de qualité. Le troisième, plus insidieux, est la manipulation du critère de succès — l'agent qui réécrit le test plutôt que de corriger le code. C'est pourquoi StrongDM a remplacé les tests (réécriturables) par des scénarios stockés hors du code base, comme un holdout set en machine learning.

Enfin, l'optimisme techno-centrique de Cherny doit être lu pour ce qu'il est : la parole du créateur de l'outil, dans un contexte favorable, sans contradicteur. Le jugement — savoir quoi construire, pourquoi, et reconnaître quand l'agent dérive — reste, selon Karpathy, le goulot humain irréductible. « Je deviens le goulot d'étranglement : juste savoir ce qu'on essaie de construire, pourquoi ça vaut le coup, comment diriger mes agents. »

Cinq leviers pour passer de la démo à la production

De ce qui précède se dégagent des leviers concrets, observables chez ceux qui ont franchi le pas.

Trancher au niveau du leadership. Le constat de Mollick est sans appel : tant qu'un dirigeant n'assume pas explicitement le risque, les fonctions de contrôle bloqueront. La première décision n'est pas technique, elle est managériale — déployer une version entreprise, lever les craintes infondées, désigner un sponsor exécutif. C'est le sujet de notre volet « par où commencer ».

Industrialiser le contexte avant les agents. Le goulot d'étranglement identifié par l'Economic Index est l'accès au contexte. Salesforce le confirme : la qualité variable des fichiers CLAUDE.md pèse lourdement sur la qualité de sortie. Les règles partagées de Stripe, identiques pour Minions, Cursor et Claude Code, assurent la cohérence. C'est l'enjeu de ce que SFEIR nomme le Context Engineering — l'art de nourrir les agents, et de passer d'une mémoire éphémère par session à un environnement persistant au ROI composé. Sur les grandes bases de code, c'est le facteur déterminant.

Encastrer les garde-fous dans le workflow, pas à côté. Le shift feedback left de Stripe (les règles de lint actives dans l'IDE, les git hooks et la CI) et les guardrails structurels de Salesforce montrent la voie : la qualité et la sécurité doivent être dans le chemin de l'agent, pas dans une revue terminale. C'est ce qui permet aux incidents de baisser quand la production augmente.

Mesurer la valeur livrée, pas le volume. Le Effective Output score de Salesforce ou les scénarios de StrongDM disent la même chose : compter les PRs ou les lignes ne signifie rien. Il faut une mesure de valeur réelle, idéalement validée hors du code base que l'agent peut manipuler. C'est aussi la condition d'un pilotage du coût qui ne dérape pas.

Refondre les rôles et le SDLC. Une fois l'IA adoptée, les équipes les plus avancées détruisent et reconstruisent leurs workflows : quels process supprimer, quels handoffs éliminer, quel travail un agent peut-il posséder ? L'ingénieur devient orchestrateur ; les généralistes pluridisciplinaires gagnent en valeur, comme l'observe Cherny.

Le point de vue SFEIR : viser le 10x, pas le marginal

Ce que ces signaux dessinent, c'est moins un gain de productivité qu'un changement d'unité de mesure. C'est la conviction qui sous-tend ce que SFEIR appelle l'AI for IT — la stratégie du 10x : ne pas viser des gains marginaux de quelques pourcents, mais un facteur dix, en déplaçant l'effort de la production manuelle de code vers l'ingénierie du contexte et la restructuration des équipes. La formule volontairement provocatrice de Didier Girard — « écrire du code est désormais un anti-pattern » — n'est que le corollaire opérationnel de la thèse de Cherny, traduite côté entreprise : le temps passé et les ETP, comme indicateurs, deviennent obsolètes.

L'enjeu, en observateur, n'est donc pas de croire ou non au « coding is solved ». C'est de reconnaître que l'avantage, comme le dit Cherny pour Anthropic, est désormais organisationnel — et que les entreprises qui le construiront tôt creuseront un écart durable, là où Mollick voit déjà 18 mois d'avance séparer deux concurrents du même secteur.

Conclusion : la presse de Gutenberg, en plus rapide

Cherny conclut son intervention par une analogie qui éclaire tout le reste. Vers 1400, en Europe, environ 10 % de la population savait lire et écrire ; les scribes étaient souvent employés par des rois et des seigneurs illettrés. Cinquante ans après l'invention de la presse, il s'était publié plus de littérature qu'au cours des mille années précédentes, et le livre coûtait cent fois moins cher. Quelques siècles plus tard, la littéracie atteignait 70 % : nous savons tous lire et écrire, sans diplôme pour cela — même s'il existe encore des écrivains professionnels. « Le logiciel sera démocratisé de la même façon, mais bien plus vite que cinquante ans. » Et sa phrase-pivot : « la meilleure personne pour écrire un logiciel de comptabilité, ce n'est pas un ingénieur, c'est un très bon comptable. Coder est la partie facile ; connaître le domaine est la partie difficile. »

Revenons à la salle Sequoia et à ces 150 PRs en une journée. Le chiffre fascine, mais il n'est pas la leçon. La leçon, c'est qu'entre l'entreprise qui le réalise déjà et celle qui réunit encore un comité pour approuver chaque cas d'usage, la différence n'est plus technique : elle est de leadership, de contexte et de discipline d'ingénierie. Le « coding is solved » est peut-être vrai pour Anthropic. Il ne le sera pour votre entreprise que le jour où vous aurez décidé, assumé, et industrialisé les garde-fous qui le rendent sûr. C'est tout l'objet des articles qui suivent ce pilier.

Les six volets de cette série

• Par où commencer en entreprise — le frein est organisationnel, et le goulot d'étranglement, c'est le contexte.
• La sécurité se joue dans la revue — signaux d'alarme, vérifiabilité, harnais et identité des agents.
• Sur de grandes bases de code — le vrai goulot, c'est lire le code existant : donnez le contexte du dépôt à l'agent.
• MCP, le protocole qui rend l'agent voyant — connecter les agents aux outils et données, le problème N×M, la sécurité côté machine.
• Combien ça coûte vraiment — fin des assistants bon marché, ROI, et passage « de l'adoption à l'allocation ».
• Vibe coding ou agentic coding — deux postures, deux usages, et une question : qui garde la propriété du code ?

Points clés

• L'agentic coding déplace le développeur d'implémenteur à orchestrateur : l'agent lit le dépôt, écrit le code, teste, corrige et ouvre la PR — l'humain spécifie et valide.²
• Le « coding is solved » de Cherny est ancré (100 % de code généré, 150 PRs/jour record) mais borné : il vaut pour des bases simples, pas pour le legacy complexe — et le jugement systémique reste humain.¹³
• Les preuves à l'échelle existent déjà : 1 000+ PRs d'agents/semaine chez Stripe, +151,3 % de valeur livrée et incidents en baisse de 5 % chez Salesforce — la qualité bénéficie de la vitesse si les garde-fous sont encastrés.⁵⁶
• Le frein n'est plus technique mais de leadership : pour Mollick, le facteur décisif est la volonté d'un dirigeant d'assumer le risque ; le vrai goulot opérationnel est l'accès au contexte.⁸⁹
• Cinq leviers pour passer de la démo à la production : trancher au niveau exécutif, industrialiser le contexte (Context Engineering), encastrer les garde-fous dans le workflow, mesurer la valeur et non le volume, refondre rôles et SDLC — dans une logique de 10x, non de gain marginal.

Sources

1. Boris Cherny (Anthropic), intervention Sequoia AI Ascent — youtube.com, 5 mai 2026.
2. Anthropic, 2026 Agentic Coding Trends Report — resources.anthropic.com, février 2026.
3. Andrej Karpathy, Software Is Changing (Again) — youtube.com, 29 avril 2026.
4. Kent Beck, Augmented Coding: Beyond the Vibes — tidyfirst.substack.com, 25 juin 2025.
5. Stripe, Minions: Stripe's one-shot end-to-end coding agents — stripe.dev, 9 février 2026.
6. Salesforce, How Salesforce Engineering Became Truly Agentic — salesforce.com, 27 mai 2026.
7. Justin McCarthy (StrongDM) — factory.strongdm.ai, 6 février 2026.
8. Ethan Mollick — linkedin.com, 5 mars 2026.
9. Anthropic, Anthropic Economic Index — September 2025 Report — anthropic.com, 15 septembre 2025.