IA et développement logiciel avec Claude Code

TL;DR

L’IA dans le développement logiciel n’est pas l’ancienne chaîne avec un assistant boulonné dessus. Trois phases changent de forme : la spécification devient la partie coûteuse, la revue devient le goulot, et la planification de capacité passe des sièges aux tokens par minute. Sautez la refonte de la revue et le débit baisse au lieu de monter.

Quelles phases changent réellement ?

Trois phases changent : spécification, revue et planification de capacité. L’implémentation accélère, et c’est précisément cette vitesse qui sature les deux phases de part et d’autre. Build, test et déploiement restent largement inchangés, parce qu’ils étaient déjà automatisés.

Le mécanisme est simple. Si le temps d’implémentation est divisé par deux et que la capacité de revue reste fixe, la file d’attente devant la revue double. Les équipes qui ne mesurent aucun gain de productivité après un déploiement de Claude Code présentent presque toujours cette forme : plus de pull requests, autant de relecteurs, délai global plus long.

Ce que chaque phase exige :

Phase	Ce qui change	Ce qu’il faut refondre
Spécification	Devient la contrainte qui borne la qualité du résultat	Écrire critères d’acceptation et cibles de vérification dans le ticket
Implémentation	Plus rapide, plus parallèle, plus de travail jetable	Rien, cette partie fonctionne
Revue	Devient le goulot	Séparer revue mécanique et revue de jugement
Test	Peu changé	Ajouter des tests que Claude ne voit pas en écrivant le code
Capacité	Passe des sièges aux tokens par minute	Modéliser les limites au niveau de l’organisation, pas les effectifs
Reporting de coût	Passe des licences à la consommation	Attribution par utilisateur dans votre propre stack

Pourquoi la revue décide-t-elle du résultat ?

La revue décide parce que c’est la seule phase où un humain doit encore comprendre chaque ligne, et comprendre n’accélère pas. La refonte qui marche sépare la revue en un passage mécanique porté par l’outillage et un passage de jugement porté par une personne, puis finance correctement le second.

Le passage mécanique appartient aux hooks et à la CI, pas à la tête d’un relecteur. Anthropic documente un motif de hook PreToolUse pour exactement ce type de travail : plutôt que de laisser Claude lire un journal de 10 000 lignes pour trouver les erreurs, le hook filtre sur ERROR et ne renvoie que les correspondances, ce qui réduit le contexte de dizaines de milliers de tokens à quelques centaines. Le même motif vaut pour les portes de revue. Ce qu’un script peut vérifier doit échouer avant qu’une personne regarde.

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          { "type": "command", "command": "~/.claude/hooks/filter-test-output.sh" }
        ]
      }
    ]
  }
}

Le passage de jugement exige deux changements. D’abord, donner au relecteur la spécification et pas seulement le diff, car la question est de savoir si le code fait la chose convenue, non s’il compile. Ensuite, exiger des tests que le modèle n’a pas vus en écrivant l’implémentation, car un modèle qui écrit le code et ses tests les met d’accord.

Quatre règles que nous appliquons au code généré en revue, par rendement décroissant :

Rejeter toute modification dont le ticket ne porte aucune cible de vérification. Sans elle, le relecteur ne peut pas juger la correction, et le modèle ne pouvait pas non plus.
Lire le test pour ce qu’il n’assertionne pas. Les tests générés couvrent le cas nominal en détail et les bords pas du tout.
Vérifier chaque appel externe sur la gestion des erreurs, car c’est là que le code généré est le plus faible.
Traiter un gros diff comme un défaut de spécification, pas comme un problème de revue. Le renvoyer pour découpage.

Notre guide sur la sécurité de Claude Code traite les permissions et le bac à sable qui bornent ce que la phase d’implémentation peut toucher.

Que faut-il au-delà d’une installation locale ?

Quatre choses : une politique livrée de façon centralisée, l’attribution des coûts par utilisateur, des limites de débit modélisées au niveau de l’organisation, et une route conforme à votre engagement d’hébergement. Les quatre ont des mécanismes concrets, et trois se trompent facilement.

Politique livrée de façon centralisée. Les managed settings sont le véhicule : réglages gérés côté serveur, politique MDM, managed-settings.json ou programme d’aide à la politique. Un réglage mérite d’être déployé tôt : modelPricing fait afficher à chaque chiffre de coût vu par un développeur vos tarifs contractuels plutôt que les tarifs catalogue. Il exige Claude Code v2.1.242 ou plus récent et change l’affichage, pas la facturation. Sans lui, les développeurs voient des tarifs catalogue, la finance des tarifs contractuels, et personne ne fait confiance à l’un ou à l’autre.

Attribution des coûts par utilisateur. Cela dépend entièrement de la route, et le piège est net. Sur Amazon Bedrock, Google Cloud et Microsoft Foundry, Claude Code n’envoie aucune métrique à Anthropic, donc les tableaux de bord Anthropic et la Claude Code Analytics API ne couvrent pas cet usage du tout. L’export OpenTelemetry fonctionne sur toutes les configurations et reste la seule option qui diffuse des métriques de tokens et de coût par utilisateur en quasi temps réel vers votre propre stack d’observabilité. Si vous êtes sur une route cloud et attendez quelque chose des tableaux de bord Anthropic, vous attendrez. Notre guide de la télémétrie Claude Code décrit les métriques OpenTelemetry et leur acheminement.

Limites de débit au niveau de l’organisation. Les limites s’appliquent par organisation et non par développeur, et les quotas recommandés par utilisateur baissent avec la taille de l’équipe, car la simultanéité ne croît pas linéairement :

Taille d’équipe	TPM par utilisateur	RPM par utilisateur
1 à 5 utilisateurs	200k à 300k	5 à 7
5 à 20 utilisateurs	100k à 150k	2,5 à 3,5
20 à 50 utilisateurs	50k à 75k	1,25 à 1,75
50 à 100 utilisateurs	25k à 35k	0,62 à 0,87
100 à 500 utilisateurs	15k à 20k	0,37 à 0,47
500 utilisateurs et plus	10k à 15k	0,25 à 0,35

L’exemple chiffré d’Anthropic : 200 utilisateurs à 20 000 TPM chacun font 4 millions de TPM au total. Demandez la capacité avant le déploiement, et davantage pour les formations, où la simultanéité monte autrement que dans le travail courant.

Une route conforme à l’engagement d’hébergement. Pour les organisations qui doivent faire passer l’inférence par leur propre fournisseur cloud, le Claude apps gateway est le motif pris en charge. C’est un binaire Linux unique auto-hébergé devant Bedrock, Claude Platform on AWS, Google Cloud ou Microsoft Foundry, avec authentification SSO, accès aux modèles par groupe et télémétrie OTLP portant par défaut les comptes de tokens, le modèle, l’identité de l’utilisateur et la latence. Ses prérequis sont précis : Claude Code v2.1.195 ou plus récent sur le serveur et sur chaque poste de développeur, un fournisseur d’identité OIDC (SAML et LDAP ne sont pas pris en charge), PostgreSQL 11 ou plus récent, et un nom d’hôte qui ne résout que vers des adresses privées. Le démarrage est fail-closed : le gateway s’arrête sur une configuration erronée ou un fournisseur d’identité injoignable plutôt que de servir en mode dégradé.

Une limite du gateway appartient à la conception dès le premier jour : il n’existe aucun flux de jeton de service pour les pipelines non supervisés. L’authentification passe toujours par le flux device du navigateur, donc un job de CI sans personne pour approuver ne peut pas s’authentifier. Configurez la CI directement contre le fournisseur cloud et gardez les réglages du gateway hors des runners. Notre guide de la passerelle LiteLLM pour l’UE traite la route proxy alternative.

Combien coûte la chaîne refondue ?

Prévoyez trois lignes de consommation : les tokens par développeur, le coût du parallélisme, et la capacité de revue qu’il faut financer. Les deux premières ont des chiffres publiés. La troisième manque dans la plupart des plans et c’est en général la plus lourde.

La page des coûts indique environ 13 USD par développeur et par jour actif et 150 à 250 USD par développeur et par mois sur l’ensemble des déploiements en entreprise, en restant sous 30 USD par jour actif pour 90 pour cent des utilisateurs. Pour une organisation de 40 développeurs, cela représente environ 72 000 à 120 000 USD par an.

C’est sur le parallélisme que les budgets cassent. Les équipes d’agents consomment environ 7 fois plus de tokens qu’une session standard en mode plan, car chaque coéquipier maintient sa propre fenêtre de contexte et tourne comme une instance distincte. Elles sont désactivées par défaut et exigent CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1. Laissez-les éteintes jusqu’à ce qu’une équipe ait une raison, puis surveillez l’attribution.

Les leviers qui déplacent vraiment le chiffre, par effet décroissant :

Levier	Effet	Où il se trouve
Choix du modèle	Sonnet contre Opus, facteur 2 en entrée et en sortie	`/model`, configuration des sous-agents, managed settings
Vider entre les tâches	Évite de renvoyer un contexte périmé à chaque requête	`/clear`, habitude
Mise en cache des prompts	Une lecture de cache coûte une fraction de l’entrée de base	Automatique, cassée par un changement de définitions d’outils
Hooks de prétraitement	Réduit des dizaines de milliers de tokens à quelques centaines	Hooks `PreToolUse`
Garder CLAUDE.md petit	Il se charge au démarrage, pertinent ou non	Sous 200 lignes
Niveau d’effort	Les tokens de réflexion sont facturés en sortie	`/effort`, `MAX_THINKING_TOKENS`

La capacité de revue est la ligne sur laquelle il faut discuter. Si le débit d’implémentation monte et que vous ne financez aucune revue supplémentaire, le délai se dégrade. Notre position : prévoir un jour de revue supplémentaire par semaine pour cinq développeurs au premier trimestre, puis mesurer et ajuster. C’est notre recommandation et non une référence sourcée, mais c’est moins cher que l’alternative, qui consiste à découvrir la file d’attente en production.

Pour la mesure, le tableau de bord d’analytique rapporte les pull requests créées dans Code, les membres actifs hebdomadaires, le niveau d’adoption et le temps économisé estimé, avec export CSV et actualisation quotidienne. Complétez avec /insights, qui analyse jusqu’à 200 sessions locales encore non vues par exécution et rapporte des points de friction comme les demandes mal comprises et le code défectueux plutôt que des comptes de tokens. Le rapport de friction est l’entrée la plus utile dans une refonte de processus.

Refondre en interne ou externaliser ?

Refondez le processus vous-même. Il touche votre format de ticket, votre culture de revue et votre définition du fini, et rien de tout cela ne se livre depuis l’extérieur. Faites venir de l’aide pour la couche plateforme : déploiement du gateway, chaîne OpenTelemetry, modèle de limites de débit et diffusion des managed settings, tous spécialisés, finis et bien documentés.

Ce que le travail demande, comme notre estimation et non comme référence sourcée :

Chantier	Effort	Responsable
Concevoir et diffuser les managed settings	5 à 10 jours	Ingénierie plateforme
Chaîne OpenTelemetry et tableaux de bord	10 à 15 jours	Observabilité
Mettre le Claude apps gateway en production	10 à 20 jours	Plateforme et identité
Modèle de limites de débit et demande de capacité	2 jours	Ingénierie plateforme
Format de ticket et cibles de vérification	5 jours, puis en continu	Management de l’ingénierie
Refonte de la revue et formation des relecteurs	10 jours, puis en continu	Tech leads

Notre avis : le gateway est la pièce la plus intéressante à externaliser, car ses prérequis sont précis, ses modes d’échec fail-closed, et une équipe qui le fait pour la première fois passera deux semaines sur la configuration du fournisseur d’identité qu’une personne aguerrie règle en deux jours. La refonte de la revue est la moins intéressante, car une partie externe ne peut pas changer la façon dont vos tech leads relisent le code.

Ce qu’il faut exiger d’une refonte payante :

Une refonte de la revue, pas seulement un déploiement d’outil. Une proposition sans ligne de capacité de revue n’a pas compris le problème.
L’attribution par utilisateur démontrée sur votre route réelle, y compris le trou des tableaux de bord Anthropic sur les routes cloud.
La demande de capacité déposée et accordée avant le déploiement, avec le calcul de TPM montré.
modelPricing déployé pour que les chiffres vus par les développeurs correspondent au contrat.
Un chemin d’authentification CI documenté qui ne dépend pas du gateway.

Notre guide de Claude Code sur Bedrock en Europe traite la route d’hébergement en détail, et les prix de Claude Code pour les équipes comparent les modes de facturation.

FAQ

Qu’est-ce que l’IA change dans le développement logiciel ?

Trois phases : la spécification porte plus de poids, la revue devient le goulot, et la planification de capacité passe des sièges aux tokens par minute au niveau de l’organisation. Build, test et déploiement restent largement inchangés, car ils étaient déjà automatisés. L’implémentation accélère, et c’est cela qui sature la spécification et la revue.

Combien coûte Claude Code par développeur dans une chaîne ?

Environ 13 USD par développeur et par jour actif et 150 à 250 USD par développeur et par mois sur l’ensemble des déploiements en entreprise, en restant sous 30 USD par jour actif pour 90 pour cent des utilisateurs. Les équipes d’agents changent nettement le tableau, avec environ 7 fois plus de tokens qu’une session standard en mode plan.

Pourquoi la revue devient-elle le goulot ?

Parce que l’implémentation accélère et la revue non. Comprendre un diff coûte à un humain le même temps qu’avant, donc un nombre fixe de relecteurs devant une implémentation plus rapide produit une file plus longue et un délai plus mauvais. Séparez la revue en un passage mécanique pour les hooks et la CI et un passage de jugement pour une personne.

Claude apps gateway ou passerelle LLM : que choisir ?

Le Claude apps gateway quand l’inférence doit passer par votre propre fournisseur cloud et que vous voulez authentification SSO, accès aux modèles par groupe et télémétrie OTLP depuis un composant pris en charge. Une passerelle LLM générale comme LiteLLM quand un seul proxy doit couvrir plusieurs éditeurs. Le Claude apps gateway n’a pas de flux de jeton de service, donc la CI s’authentifie directement auprès du fournisseur dans les deux cas.

Comment obtenir un reporting de coût par utilisateur sur Bedrock ?

Par l’export OpenTelemetry, un Claude apps gateway, ou une passerelle LLM qui suit la dépense par clé. Sur Bedrock, Google Cloud et Microsoft Foundry, Claude Code n’envoie aucune métrique à Anthropic, donc les tableaux de bord d’analytique Anthropic et la Claude Code Analytics API ne couvrent pas cet usage.

Quelles limites de débit demander ?

Modélisez par utilisateur et multipliez. Anthropic recommande 50 000 à 75 000 TPM par utilisateur pour 20 à 50 utilisateurs, et 15 000 à 20 000 pour 100 à 500, car la simultanéité baisse avec la taille de l’équipe. L’exemple chiffré est 200 utilisateurs à 20 000 TPM chacun, soit 4 millions de TPM au total. Demandez de la capacité supplémentaire pour les formations.

Sources

Claude Code : maîtriser les coûts (28 octobre 2026)
Claude Code : Claude apps gateway (28 octobre 2026)
Support Anthropic : analytique d'usage Team et Enterprise (28 octobre 2026)
Anthropic : tarifs des modèles (28 octobre 2026)
Support Anthropic : la formule Enterprise (28 octobre 2026)