Le ROI du développement web agentique : comment Claude Code modifie l'économie de l'e-commerce

Toutes les équipes e-commerce avec lesquelles j’ai travaillé ont ce même document quelque part. Une liste de fonctionnalités utiles, classées selon la conviction de chacun, dont deux seulement sont prévues ce trimestre.

La liste n’est pas courte faute d’idées. Elle l’est à cause de l’arithmétique. Une fonctionnalité prend un certain nombre de jours d’ingénierie, ces jours coûtent, donc la plupart attendent.

Ce qui a changé ces deux dernières années, c’est ce second chiffre. Et ce n’est pas marginal.

Ce que « agentique » signifie ici

Beaucoup d’équipes ont déjà testé la complétion de code par IA, qui suggère la ligne suivante pendant la saisie. C’est vraiment utile pour la vitesse de frappe. Cela ne change pas le budget, car la saisie n’a jamais été la partie coûteuse.

Claude Code fonctionne autrement. C’est un outil agentique, c’est-à-dire qu’il accède à l’ensemble de votre code et agit au lieu de suggérer. Décrivez un bug, il en remonte la cause et applique un correctif. Décrivez une fonctionnalité, il planifie l’approche, modifie tous les fichiers nécessaires, exécute la suite de tests, corrige les erreurs, puis remet une branche à relire.

Vous pouvez l’exécuter depuis le terminal, une extension native VS Code ou un plugin JetBrains, une application de bureau ou dans le navigateur. Il fonctionne aussi sans interface en CI via le mode print (claude -p), ce qui compte plus qu’il n’y paraît — nous y reviendrons.

Exemple concret : quinze jours deviennent deux

Les pourcentages de productivité n’aident pas à valider un budget, donc voici un cas précis et courant : un module « Fréquemment achetés ensemble » sur la fiche produit, avec tarification automatique du bundle, gestion du stock, et ajout au panier en un clic.

Rien de complexe. La plupart des boutiques le souhaitent. Beaucoup ne l’ont pas, pour des raisons familières.

La méthode classique : comptez 15 jours ouvrés

• Jours 1–2 · Découverte. Lecture du code existant du catalogue, du panier et de la tarification pour comprendre l’interaction entre variantes, taxes et remises.
• Jours 3–4 · Spécification. Spécifications techniques, choix du modèle de données, transmission au design, estimation.
• Jours 5–9 · Backend. Requête de recommandation, nouvel endpoint, règles de tarification du bundle, et gestion avec les promotions existantes.
• Jours 10–12 · Frontend. Composant, états responsives, gestion du chargement et des erreurs, intégration panier.
• Jour 13 · Tests. Souvent la première chose supprimée quand le planning dérape.
• Jour 14 · QA et corrections. Variantes en rupture, multi-devises, tarification TTC.
• Jour 15 · Déploiement. Suivi et documentation.

Deux ou trois personnes impliquées sur trois semaines calendaires. Aux tarifs moyens d’agence ou internes, cela représente une fonctionnalité à cinq chiffres, ce qui explique précisément pourquoi elle reste sur la liste.

La même chose avec un agent — environ 2 jours

Jour un, matin. Quelqu’un rédige une vraie spécification : règles métier, gestion des prix, cas limites pertinents. Claude Code analyse la base de code et propose un plan — fichiers à modifier, intégration dans la logique panier existante, points de risque identifiés. Vous corrigez le plan avant toute écriture de code. Ces quatre-vingt-dix minutes sont la phase la plus déterminante du projet, et relèvent entièrement du jugement humain.

Jour un, après-midi. Le travail s’exécute en parallèle. Claude Code propose plusieurs méthodes intégrées pour cela : sous-agents pour des tâches ciblées avec retour, vue agent pour lancer des sessions en arrière-plan, workflows dynamiques pour les tâches plus larges, et worktrees qui attribuent à chaque session son propre checkout git afin d’éviter les conflits sur les fichiers. Il existe aussi un mode expérimental d’équipes d’agents avec liste de tâches partagée, désactivé par défaut et à considérer comme précoce.

Un flux sur la logique endpoint et tarification, un sur le composant frontend, un sur les tests. La phase de découverte, qui prenait deux jours manuellement, a duré environ vingt minutes, car l’agent a lu la base de code au lieu de l’apprendre.

Jour deux, matin. Relecture. C’est ici que l’intervention de votre ingénieur senior est requise : vérification de la logique de prix selon les règles de promotion réelles, gestion des cas où un article du bundle est épuisé en cours de session, contrôle du traitement fiscal. Les corrections sont renvoyées et reviennent en quelques minutes.

Jour deux, après-midi. QA, préproduction, déploiement. Les tests et la documentation existent déjà, car leur production a coûté presque rien.

Où sont passés les treize jours

Cela mérite attention, car cela explique tout le changement :

• Archéologie de la base de code. Un agent lit le code bien plus vite qu’une personne ne l’assimile.
• Génération de code standard — endpoints, structure, gestion d’état, erreurs.
• Rédaction de tests, désormais assez abordable pour devenir systématique.
• Documentation, qui devient un sous-produit plutôt qu’une tâche à part.
• La phase de débogage, puisque l’agent exécute les tests et corrige ses propres erreurs avant que quiconque ne voie la branche.

Ce qui n’a pas été compressé : décider quoi construire, définir les règles, relire le résultat. Ces tâches restent humaines. Elles représentent aussi désormais une part bien plus importante du travail.

Ce n’est pas qu’un exercice théorique

Rakuten — qui gère plus de 70 activités dans l’e-commerce, le voyage, la fintech et les communications — a publié ses chiffres avec Anthropic.

Time to market

24 jours → 5

Réduction

79%

Codage autonome

7 heures en continu

Précision du code

99.9%

Les 7 heures correspondent à un projet de refonte complexe en open source, mené de bout en bout, avec 99,9 % de précision sur les modifications de code produites. La réduction de 15 à 2 évoquée plus haut se vérifie donc déjà à grande échelle.

D’autres résultats publiés sont plus mesurés, ce qui mérite d’être signalé. L’agence de développement Boldare a constaté une augmentation de la vélocité de sprint jusqu’à 31 % sur un trimestre, avec l’IA impliquée dans environ 75 à 85 % du nouveau code et des tests. HubSpot a vu la résolution de problèmes techniques complexes passer de trois à cinq jours à moins d’une heure, et a utilisé Claude Code pour accélérer une migration frontend lors d’un rebranding qui aurait pris des mois autrement. HubSpot précise que ces chiffres proviennent d’analyses internes sur des cas sélectionnés et sont donnés à titre indicatif.

Le volume, pas seulement l’économie

Voici l’aspect souvent oublié dans les discussions sur les coûts.

Prenez un développeur travaillant sur des fonctionnalités de cette taille. À quinze jours chacune, il en livrera environ seize par an. À trois jours en moyenne — certaines plus rapides, d’autres plus lentes — ce chiffre approche quatre-vingts.

Lisez ces chiffres comme un rapport, pas comme une prévision de capacité. Aucun développeur ne consacre 240 jours par an uniquement à de nouvelles fonctionnalités : il y a la maintenance, les incidents, les réunions, les congés. Les deux lignes sont gonflées par la même hypothèse, donc leur rapport reste valable même si aucun chiffre ne tiendrait sur un vrai sprint board. Et quatre-vingts fonctionnalités par an dépassent la capacité de relecture de la plupart des équipes, ce qui constitue une contrainte à laquelle je reviendrai.

Aucun effectif n’a changé. Le budget non plus. Ce qui change, c’est le nombre d’essais possibles.

C’est important car l’optimisation du taux de conversion relève fondamentalement d’un problème de recherche. Personne ne sait à l’avance quelle modification aura un impact. On le découvre en déployant et en mesurant, et l’équipe qui peut se permettre plus d’essais trouve la bonne solution plus vite.

Réfléchissez à ce qu’une boutique peut soudainement justifier de développer :

• Alertes de retour en stock sur chaque variante en rupture
• Un configurateur de lots ou un module « compléter le look »
• Gestion autonome des retours et échanges, pour réduire les tickets au support
• Guides des tailles avec données réelles, qui font généralement baisser le taux de retour
• Données structurées sur l’ensemble du catalogue pour des résultats de recherche enrichis
• Une liste d’envies qui envoie un e-mail lors d’une baisse de prix
• Optimisation de la vitesse des pages sur les modèles qui en ont le plus besoin
• Améliorations du paiement invité et relance des paniers abandonnés avec segmentation appropriée
• Outils internes de tarification, pour que les équipes merchandising n’aient plus à ouvrir de tickets pour chaque règle

Pris isolément, ce sont de petits leviers, chacun valant une fraction de pour cent. Sur un an, ils s’additionnent — et c’est précisément ce que l’ancienne structure de coûts empêchait. À quinze jours par élément, cette liste représente plusieurs années de feuille de route. À trois jours, c’est l’affaire de quelques trimestres.

À méditer : un concurrent qui mène quatre expérimentations par trimestre contre vos douze n’avance pas trois fois moins vite. Il apprend trois fois moins vite, et cet écart ne se comble pas par des recrutements.

Trois aspects au-delà de la vitesse brute

Le contexte architectural ne part plus avec les personnes

Quand un ingénieur expérimenté s’en va, la perte coûteuse est souvent le contexte, pas le code — pourquoi les choses ont été conçues ainsi. Claude Code aide sur ce point via un fichier CLAUDE.md à la racine du projet, qui centralise les choix d’architecture, bibliothèques privilégiées, conventions et standards de sécurité. Chaque session le lit, donc le code généré respecte vos règles internes plutôt que des modèles génériques.

C’est un moyen raisonnable de rendre le jugement senior durable. Cela réduit aussi nettement l’onboarding, puisqu’un nouvel arrivant peut interroger directement la base de code au lieu de passer des semaines à reconstituer l’intention.

Il gère la complexité côté serveur, pas seulement les interfaces

Scepticisme légitime de la plupart des CTO : utile pour le rendu de composants, mais qu’en est-il des parties qui empêchent de dormir ? En pratique, l’agent est justement le plus utile là où lire du code inconnu coûte le plus. Cartographier les règles de routage des commandes multi-régions. Mettre en place une file d’attente pour absorber un import massif de catalogue. Comprendre pourquoi une promotion s’applique mal sur trois services. Ce sont d’abord des problèmes de contexte, pas de saisie.

Des tâches qui s’exécutent sans intervention humaine

Comme il fonctionne en mode headless avec claude -p, vous pouvez l’intégrer à GitHub Actions ou à n’importe quel pipeline CI, et le déclencher sur les événements déjà émis : par exemple à l’ouverture d’une pull request pour qu’un premier contrôle soit fait avant toute revue humaine, ou lors d’un échec de build pour qu’une analyse soit prête avant même la lecture de l’alerte. Au-delà : audits hebdomadaires de dépendances et de sécurité, synchronisation de la documentation après fusion. Ces routines planifiées tournent dans le cloud, indépendamment de l’activité des postes de travail.

C’est tout un pan de tâches qui nécessitaient auparavant une personne dédiée ou, plus souvent, n’étaient tout simplement pas faites.

Ce qu’il faut anticiper honnêtement

Trois facteurs décideront si vous obtenez les résultats ci-dessus ou un simple essai décevant.

La revue devient le point de blocage. La génération s’est démocratisée ; la revue, non. On observe souvent un bond de productivité initial, suivi d’un ralentissement dès que le code est livré plus vite que l’équipe ne peut le relire, ce qui impose des retouches. Si vous augmentez la production sans adapter la revue, vous déplacez le goulot d’étranglement au lieu de le supprimer. Renforcez les contrôles CI et la revue automatisée avant la montée en charge, pas après : nous avons documenté notre politique de revue de code pour les modifications générées par agent, ainsi que les pratiques de sécurité à rechercher dans le code PHP généré.

L’adoption informelle ne tient pas. Les équipes qui définissent leur fonctionnement — un CLAUDE.md maintenu, planification avant le code, règles claires sur ce qu’un agent peut modifier sans supervision — conservent les gains. Celles qui laissent faire les plus motivés voient un pic, puis un retour progressif à l’ancien rythme. Il s’agit d’un changement de processus, pas d’un simple achat d’outil.

La qualité du cahier des charges devient la limite. Un développement en deux jours n’est possible que si quelqu’un a rédigé un bon cahier des charges. Des instructions vagues produisent rapidement des résultats erronés. La compétence rare n’est plus tant d’écrire le code que de savoir précisément ce qui doit exister, ce qui doit guider vos recrutements et votre formation.

Ce que cela change pour vous

La bonne façon de présenter cela en interne n’est pas « nous pouvons dépenser moins pour la même feuille de route ». C’est qu’une feuille de route que vous jugiez auparavant irréaliste mérite désormais d’être chiffrée sérieusement.

Les deux lectures se défendent. La seconde est celle qui se traduit le plus souvent en chiffre d’affaires.

Chiffrer une feuille de route que vous jugiez irréaliste ?

C’est ainsi que nous travaillons. Si vous avez un backlog en attente de calculs, nous pouvons vous indiquer quelles parties sont désormais atteignables — c’est notre cœur de métier en développement IA et ML et en développement e-commerce. La page services IA appliquée détaille le reste de nos prestations en production. Contactez-nous.