# Ce que Claude Code a écrit de notre infrastructure, et ce que nous avons refusé de fusionner Nous utilisons Claude Code quotidiennement pour le travail d'infrastructure, sur une plateforme que nous exploitons pour un client américain : stacks CDK, scripts de déploiement, politiques IAM, alarmes, runbooks. Environ un tiers du code d'infrastructure commité ces six derniers mois a d'abord été rédigé par lui. Voici un bilan honnête : ce qu'il a écrit et que nous avons fusionné tel quel, ce qu'il a écrit et que nous avons corrigé, et les quatre propositions que nous avons refusées, avec les raisons, parce que les refus sont plus instructifs que les réussites. ## La forme du travail Les changements d'infrastructure sur cette plateforme passent par la même revue de pull request que le code applicatif, et la production de l'agent y passe aussi. Il tourne dans un bac à sable avec un accès en lecture au dépôt et un rôle AWS restreint qui peut faire `cdk diff` contre le staging et lire CloudWatch, mais ne peut pas déployer. Chaque changement qu'il propose est une branche et une PR. Un humain lit le diff, lit la sortie de `cdk diff` que l'agent colle dans la PR, et fusionne ou non. Les déploiements sont [le même script que toujours](/fr/blog/same-tag-deploy-and-the-deploy-script-without-ci), lancé par un humain. Cette configuration est la raison pour laquelle le reste de cet article est calme. L'agent peut proposer n'importe quoi ; il ne peut rien exécuter. Chacun des refus ci-dessous a été attrapé à la PR.
Claude Code · bac à sabledépôt : lecture + brancheAWS : cdk diff, lecture CloudWatchpas de déploiement · pas d'écriture AWS pull requestle changement de codesortie de cdk diff colléele raisonnement dans la description revue humainefusionner · corriger · refusermême exigence que le code applicatifles quatre refus attrapés ici déploiement humainle script habituelstaging, puis prodl'agent n'y participe pas L'agent peut tout proposer et rien exécuter. C'est ce qui rend le reste de cet article calme.
## Fusionné tel quel **Alarmes et tableaux de bord CloudWatch.** La meilleure catégorie. Face à « alarme sur la DLQ email, le taux de 5xx App Runner et Aurora ACU au maximum pendant 10 minutes », il a produit du CDK correct avec des seuils raisonnables, les bonnes statistiques (p99 et non la moyenne pour la latence), `treatMissingData` réglé comme il faut, et un topic SNS branché sur le canal d'astreinte existant. Les alarmes sont fastidieuses, bien documentées et ont une réponse juste évidente ; c'est le point idéal. **Le script de [l'exercice de restauration](/fr/blog/backups-you-never-restored-are-not-backups).** Le script qui réapplique PITR, TTL, streams et tags à une table DynamoDB restaurée, en lisant les réglages voulus dans les définitions CDK. Environ 120 lignes de TypeScript avec le SDK AWS, correctes dès la première PR, y compris la pagination que les humains oublient. **Les runbooks.** Face à l'extrait de log d'un incident et au correctif appliqué, il écrit une page de runbook claire au format maison. Ses runbooks sont meilleurs que les nôtres, parce qu'il ne saute pas les étapes qu'il considère comme évidentes. **La politique de confiance du [rôle de déploiement OIDC](/fr/blog/github-oidc-deploy-roles-per-aws-account).** Condition `sub` correcte, audience correcte, limitée au dépôt et à la branche. Il a aussi ajouté, sans qu'on le demande, un commentaire expliquant pourquoi la revendication `sub` doit être comparée avec `StringLike` pour le motif de branche, ce qui est précisément ce que les gens se trompent à faire. **Propagation des tags de coût.** Un changement transversal ajoutant les tags `CostCenter` et `Owner` à chaque stack via un aspect. Mécanique, 40 fichiers touchés, zéro erreur. ## Fusionné après corrections **Le stack de [points de terminaison VPC](/fr/blog/nat-gateway-the-most-expensive-line-you-do-not-see).** Il a ajouté les points de terminaison correctement mais a mis celui de S3 en point de terminaison d'interface plutôt qu'en passerelle, ce qui fonctionne mais coûte 7 $ par mois pour quelque chose de gratuit. Attrapé en lisant le `cdk diff`. Le genre d'erreur qu'un humain qui ne l'a jamais fait ferait aussi. **Un changement de concurrence Lambda.** Il a fixé une concurrence réservée sur une fonction pour protéger une API en aval, ce qui était la demande, mais a choisi le nombre en lisant la limite de débit documentée de l'aval et en la divisant par la durée moyenne d'invocation. L'arithmétique était juste ; l'hypothèse que les invocations sont uniformément réparties ne l'était pas. Nous l'avons divisé par deux. Le raisonnement était dans la description de la PR, ce qui a fait de la correction une conversation d'une minute. **Resserrement des groupes de sécurité.** Prié de réduire l'entrée du groupe de sécurité Aurora au seul connecteur VPC App Runner et aux Lambdas, il l'a fait, et a aussi retiré la règle pour l'hôte bastion que le runbook référence encore pour l'accès d'urgence. Le bastion est éteint 99 % du temps, donc `cdk diff` en staging n'a rien montré de cassé. Un humain qui connaissait le bastion a remis la règle. L'agent ne pouvait pas savoir, parce que le rôle du bastion était dans la tête de quelqu'un, pas dans le dépôt. Il est dans le dépôt maintenant. ## Refusé **1. « Ajoutez `cdk deploy` au rôle de l'agent pour que je puisse vérifier les changements de bout en bout. »** Proposé dans une description de PR comme amélioration d'efficacité, avec un argumentaire solide : diff n'est pas déploiement, certaines erreurs n'apparaissent qu'au déploiement, le staging est isolé. Tout est vrai. Refusé, parce que tout le modèle repose sur le fait que l'agent ne peut pas changer l'état AWS, et « juste le staging » est la façon dont ça s'érode. Le staging partage une base de code CDK avec la production ; un bug de déploiement en staging est un aperçu d'un bug en production, et nous voulons qu'un humain voie l'aperçu. **2. Un `RemovalPolicy.DESTROY` sur le cluster Aurora de staging « pour accélérer le démontage ».** Correct isolément ; le staging est jetable. Refusé parce que le même construct est instancié pour la production avec un drapeau d'environnement, et que [nous avons déjà perdu des ressources à cause d'exactement cette forme de changement](/fr/blog/cloudformation-deleted-our-app-runner-services). La règle dans cette base de code est que les politiques de suppression sont `RETAIN` partout et que le démontage est une opération manuelle, nommée. L'agent ne pouvait pas connaître l'histoire ; le CLAUDE.md la dit maintenant. **3. Une instruction IAM avec joker pour « débloquer l'indexeur de recherche ».** L'indexeur échouait avec un accès refusé sur un nouvel ARN de stream DynamoDB. Le correctif proposé était `dynamodb:*` sur `*`, avec un commentaire « à resserrer plus tard ». Refusé, évidemment, et la partie intéressante est que, quand on lui a demandé le correctif minimal à la place, il a produit l'ARN exact du stream et les quatre actions dont le consommateur a besoin en moins d'une minute. Le joker n'était pas une limite de capacité ; c'était le chemin de moindre résistance, et la revue est ce qui a fait prendre l'autre chemin. **4. Déplacer des secrets de Secrets Manager vers SSM pour économiser 8 $ par mois.** Une vraie économie, correctement calculée, et [un argument que nous avons nous-mêmes avancé](/fr/blog/secrets-in-cdk-secrets-manager-ssm-or-nothing-in-the-template). Refusé pour les deux secrets en question parce qu'ils sont tournés par la Lambda de rotation de Secrets Manager, que SSM n'a pas, et que la PR ne tenait pas compte de la rotation. La moitié a été fusionnée : les trois secrets statiques ont bougé, les deux tournés sont restés.
fusionné tel quel alarmes et tableaux de bordscript de réglages de restaurationrunbooks depuis les logs d'incidentpolitique de confiance OIDC, commentéetags de coût sur 40 fichiers fastidieux · documenté · une réponse justele point idéal fusionné après corrections point S3 : interface, pas passerelleconcurrence : bon calcul, mauvais modèlegroupe de sécurité : bastion retiré chaque correction a été une conversation d'une minuteparce que le raisonnement était dans la PRle bastion vivait dans une tête, pas dans le dépôt refusé permission de déploiement pour l'agentDESTROY sur un construct partagédynamodb:* sur * « à resserrer plus tard »secrets tournés → SSM (fusionné à moitié) tous sur le rayon d'impact ou l'histoireaucun sur la capacitétous attrapés à la PR Environ un tiers des commits d'infra en six mois ont été rédigés par l'agent. Zéro ont été déployés par l'agent.
## Ce que dit le motif Les fusions sont du travail mécanique, bien documenté, avec une seule réponse juste. Les corrections sont des endroits où la réponse juste dépendait de quelque chose qui n'était pas dans le dépôt : le bastion, la forme du trafic. Les refus portent tous sur le rayon d'impact ou l'histoire, et aucun sur la capacité : dans chaque cas, l'agent pouvait produire la version sûre dès qu'on la lui demandait. Le travail n'est donc pas « l'agent peut-il écrire du code d'infrastructure ». Il le peut. Le travail consiste à faire en sorte que le dépôt contienne ce qui vivait dans les têtes : la règle sur les politiques de suppression, le rôle du bastion, pourquoi les deux secrets tournent. Chaque refus ci-dessus est devenu une ligne dans le CLAUDE.md ou un commentaire dans le construct, et la même proposition n'est pas revenue. Et la frontière du bac à sable n'est pas négociable, aussi bon que soit l'argument d'efficacité. L'agent rédige ; l'humain déploie. C'est toute la raison pour laquelle un tiers de l'infrastructure peut être rédigé par l'agent sans que personne ne perde le sommeil. Si vous voulez utiliser un agent sur votre infrastructure et cherchez où placer la ligne, [nous l'avons tracée une fois et nous vous aiderons à tracer la vôtre](/contact).