Imaginez : 7 slides et dix minutes pour raconter l'adoption des agents de développement comme Claude Code dans votre entreprise. Comment cela se passe-t-il ? Quels sont vos succès ? Qu'est-ce qui marche moins bien ?

Back Market a réuni plusieurs entreprises à Paris, pour partager leur retour d'expérience :

• BlaBlaCar

• Brevo

• Padoa

• Doctolib

• Qonto

• Ledger

• … et Back Market

L'idée de ce moment « off the record » était de partager une vision, de prendre la mesure des pratiques et des changements en cours dans notre industrie. Le public était majoritairement composé de Staff Engineers, les premiers sollicités sur ces sujets.

Ce que nous pouvons partager (sans entrer dans trop de détails)

• Toutes ces entreprises ont adopté l'IA générative pour coder.

• L'adoption va de 70 % à 100 % de la Tech.

• Plusieurs entreprises intègrent les équipes Produit dès la phase de conception.

• Claude Code revient le plus souvent, mais d'autres outils comme GitHub Copilot, Cursor et Dust sont également cités.

• L'adoption reste irrégulière.

• Les budgets mobilisés ont fortement augmenté, passant de 0 à 500 k€ par an pour certaines entreprises. L’investissement moyen oscille entre 50 et 200 € par utilisateur et par mois

• Les bonnes pratiques (skills, rules, agents) gagnent à être partagées dans un dépôt commun, ce qui soulève toutefois des questions de gouvernance.

• Plusieurs entreprises ont décrit l'effort nécessaire pour que le cycle de développement logiciel embarque les contributions des agents d'égal à égal avec celles des développeurs.

• Le rôle des équipes Plateforme devient encore plus important : il faut adapter l'outillage (intégration continue) et les processus en amont (PRD, ARD, spécifications, tickets).

• Au-delà de l'outillage, l'organisation elle-même évolue. Certaines entreprises repensent leurs rôles et leurs responsabilités : redéfinition des postes, dispatching de la charge cognitive (Staff+ et guildes), recours aux Team Topologies. L'arrivée des agents n'est plus seulement une question d'outils, mais aussi de structure.

Les difficultés, ou ce qui marche un peu moins bien

• Le Spec-Driven Development, pensé pour une personne seule, ne passe pas à l'échelle d'une équipe : il génère trop d'artefacts. Pour une entreprise, imposer cette méthode aux équipes Produit et Tech a été un échec.

• Mal utilisée, l'IA générative tend à faire fortement augmenter le nombre de pull requests à relire. On limite cet effet avec des règles de « bonnes pratiques », comme sur un projet open source, et des règles de contribution. Le risque de « review fatigue » ne doit pas être sous-estimé ; renforcer le contrôle avant l'ouverture de la PR réduit la friction.

• Tout le monde n'atteint pas le même niveau de maîtrise en même temps, ce qui peut entraîner des dépenses importantes en tokens. Le « token maxing » s'invite aussi comme un piège culturel : croire que cramer des tokens revient à être plus performant.

• Le ROI est difficile à mesurer. Se focaliser sur la quantité (le nombre de PR) est un mauvais indicateur. Une entreprise suit le nombre de points de complexité effectivement livrés en production pour quantifier l'impact — positif. Les outcomes comptent plus que l'output. Les gains en documentation, process, organisation et le nombre de petits projets effectivement livrés, sont de meilleurs indicateurs sur le ROI.

• On produit plus, c'est certain — mais produit-on mieux ? Rien n'est moins sûr. Le code avance vite, mais le pipeline global, lui, ne suit pas forcément : à qualité égale, le gain de fonctionnalités effectivement livrées aux utilisateurs n'est pas garanti.

• L'atrophie des compétences et la « dette de connaissances » inquiètent. Plusieurs entreprises observent une dépendance excessive à l'IA — la « cognitive surrender » — et s'interrogent sur la place des juniors. Certaines choisissent délibérément de limiter l'autonomie des agents sur les sujets complexes, pour préserver l'expertise.

• Évaluer des produits agentiques en production constitue un défi à part entière. Quand une IA pilote des fonctionnalités sensibles, la productivité décuplée multiplie aussi les opportunités de régression. Automatiser l'évaluation à chaque commit (analyse de la PR, exécution des tests, report des résultats en CI) sans en faire un nouveau goulot d'étranglement reste un chantier ouvert.

• Les coûts, et donc les budgets, sont difficiles à maîtriser. Freiner l'adoption pour des raisons budgétaires empêche de mesurer les changements.

Côté budget

Le contrôle est plus simple avec des souscriptions fixes, comme Claude Max, qu'avec un modèle « pay-as-you-go ». Certains évoquent le risque de dépendre d'Anthropic ou d'OpenAI, que l'on pourrait atténuer avec des LLM locaux — une piste qui reste encore expérimentale.

En conclusion

La soirée l'a montré : la question de l'adoption reste entière, et elle entraîne des changements, pour les développeurs comme pour d'autres métiers tels que le design ou le Produit. Intégrer les agents demande un effort de documentation, d'industrialisation et de gouvernance et, de plus en plus, une réorganisation des équipes et des responsabilités. Aujourd'hui, plus personne ne se demande si un agent peut coder une fonctionnalité. La question est plutôt : quand pourra-t-il le faire seul, et comment contrôler son travail ? La notion d'orchestration prend de plus en plus d'importance et mobilisera les équipes Plateforme dans toutes ces entreprises.

Enfin, par leur rôle et les attentes de leurs pairs, les Staff Engineers sont en première ligne de cette transformation. Merci à toutes les personnes venue, nous ne manquerons pas de renouveler l'expérience en fin d'année.