Déployer : intégration CI/CD et mise en production

Objectifs

À l’issue de cette leçon, vous serez capable de :

• Faire intervenir Claude en mode non interactif dans la chaîne CI/CD, dans un environnement isolé
• Exposer le déploiement par MCP, avec une autonomie graduée selon l’environnement

Ce qui change

Traditionnellement, les chaînes CI/CD exécutent des scripts déterministes, et tout ce qui demande du jugement attend un humain : trier un test instable, rédiger le journal des modifications, comprendre pourquoi le build a cassé. Le déploiement et le retour arrière sont des procédures qu’un humain suit sous pression.

Dans un cycle AI-native, Claude intervient en mode non interactif dans la chaîne pour les étapes de jugement, dans un bac à sable avec des identifiants limités. Le déploiement lui est exposé par MCP, si bien que le même flux qui a écrit et testé le changement peut le livrer et le retirer, à l’intérieur de portes que l’organisation définit par environnement.

Pour démarrer

• Prérequis : l’IA dans la boucle de revue (leçon 10) et les hooks comme points d’approbation (leçon 11) : les portes doivent exister avant que l’automatisation n’accélère quoi que ce soit à travers elles.
• Infrastructure : une CI avec claude-code-action, ou tout exécuteur capable de lancer claude -p ; l’accès aux modèles par l’API, ou via Amazon Bedrock, Microsoft Foundry ou l’Agent Platform de Google Cloud (ex-Vertex AI) si le trafic doit rester dans le contrat cloud de l’organisation ; des serveurs MCP pour les cibles de déploiement ; un profil de bac à sable pour les tâches d’agent, sans identifiants permanents de production.

Mise en œuvre

1. Commencez par les étapes de jugement : claude -p dans une tâche de la chaîne pour trier un build en échec, résumer un test instable ou rédiger le journal des modifications.
2. Gardez la branche principale protégée : tout ce que l’agent écrit arrive en pull request, à travers la protection de branche ; l’agent n’a aucun moyen de pousser sur la branche principale.
3. Isolez l’exécution : les tâches d’agent tournent dans des conteneurs, sous une politique réseau, avec des jetons courts et limités, et aucun identifiant de production par défaut.
4. Exposez le déploiement par MCP : déployer, consulter l’état et revenir en arrière deviennent des outils, distincts par environnement. Les pouvoirs de l’agent deviennent une liste d’autorisations, et non un script shell muni d’identifiants.
5. Graduez l’autonomie par environnement : en développement, l’agent déploie librement ; en préproduction, il déploie depuis la branche principale ou avec l’accord de l’ingénieur ; en production, il prépare la mise en production et le responsable l’autorise, la porte étant imposée par le hook de la leçon 11.
6. Répétez le retour arrière avant que l’agent n’en ait besoin : la boucle de maintenance (leçon 13) l’invoquera quand une bande de contrôle sera franchie.

- name: Trier un build en échec
  if: failure()
  run: >
    claude -p "Lis le journal de build dans out/build.log. Identifie la cause la plus probable,
    dis si l'échec semble instable ou réel, et écris un résumé de trois lignes pour la PR." >> tri.md

Pour une tâche de mise en préproduction, la commande liste explicitement les seuls outils MCP autorisés (--allowedTools), et le mode dontAsk refuse tout appel qui demanderait une confirmation : un outil hors liste est refusé, et la tâche n’attend jamais de réponse. Un appel approuvé par un hook PreToolUse reste possible : en production, avec l’outil de mise en production retiré de la liste, l’autorisation du hook est le seul chemin, et la production échoue fermée si le hook ne s’exécute pas. Le retour arrière reste dans la liste : c’est une procédure approuvée à l’avance.

Gouvernance et mesure

Le principe directeur : l’agent peut agir jusqu’à la porte de production, pas la franchir. La protection de branche transforme tout ce qu’il écrit en pull request ; le bac à sable et les jetons limités bornent ce qu’il peut atteindre ; les outils MCP par environnement et le hook de production définissent ce qu’il peut livrer.

• Indicateur avancé : la part des étapes de jugement de la chaîne traitées par Claude, et le délai de tri d’un build en échec.
• Indicateur retardé : le délai de mise en production et le délai de retour arrière, avec un taux d’échec des changements stable ou en baisse.

À vous de jouer

Une étape de jugement dans la chaîne. Dans un dépôt de test, ajoutez à la CI une étape qui lance claude -p quand le build échoue, pour en résumer la cause en trois lignes. Puis, pour chacun de vos environnements, écrivez la liste exacte des outils que l’agent aurait le droit d’appeler, et la porte qui l’arrêterait. Où se trouve aujourd’hui votre procédure de retour arrière, et a-t-elle été répétée ?

Sources officielles : CI/CD integration and deployment (Claude Academy) · The AI-native SDLC playbook — Stage 5: Deploy · Claude Code GitHub Actions · Permission modes · Third-party integrations

Points clés à retenir

• claude -p dans la chaîne pour les étapes de jugement, dans un bac à sable sans identifiants de production
• Tout ce que l’agent écrit passe par une pull request et la protection de branche
• Le déploiement exposé par MCP, outil par outil et environnement par environnement
• L’agent agit jusqu’à la porte de production ; la production échoue fermée sans l’approbation du hook