L'IA n'est pas seulement un partenaire de codage, elle peut aussi être un partenaire de déploiement

SECTION 1

Introduction

L'IA peut nous aider à écrire du code rapidement, ce n'est probablement une nouvelle pour personne. Mais elle peut également nous aider à configurer et déployer un système plus efficacement, en d'autres termes, elle peut faire du DevOps autant que du développement.

C'est quelque chose que j'ai découvert en tentant de déployer une plateforme de microservices événementielle sur AWS. Devant donner vie à une nouvelle plateforme modernisée sur AWS mais manquant d'expérience tant en cloud qu'en plateforme, je me suis tourné vers l'IA pour m'aider.

SECTION 2

Quelques éléments de contexte…

Nous travaillions pour un client du secteur automobile qui avait besoin de moderniser une plateforme. En utilisant un processus de développement accéléré par l'IA, nous avons construit une nouvelle plateforme de microservices événementielle. Elle consistait en cinq microservices prêts pour la production et plus de 50 000 lignes de code. L'une des principales exigences était que cette plateforme soit intégrée au système Dealers Touch Point (DTP) existant via une API SOAP pour recevoir les demandes de financement des clients. Cela signifiait que le déploiement cloud était crucial, nous avions besoin de scalabilité et de flexibilité.

Ce n'est que le prologue. Ce qui suit est l'histoire de comment je me suis associé à un copilote IA pour déployer la plateforme et les leçons que j'ai apprises en la mettant en ligne en seulement trois jours.

SECTION 3

Gérer la complexité architecturale

Pour commencer, examinons les composants que je devais déployer. C'était loin d'être une simple application d'exemple :

Cinq microservices. Chacun avait des exigences uniques. Un service, par exemple, nécessitait Amazon S3 pour le stockage de documents, un autre s'intégrait à un bureau de crédit tiers et un troisième utilisait une fonction OCR externe pour la vérification de documents. Cela impliquait de gérer plusieurs ensembles de credentials d'API externes. Un noyau événementiel. Les services étaient conçus pour communiquer de manière asynchrone en utilisant Apache Kafka. Un frontend React. Celui-ci était hébergé sur S3 et servi mondialement via CloudFront. Conteneurisation. L'ensemble du système était conçu pour fonctionner sur ECS Fargate pour l'orchestration de conteneurs serverless, avec des images stockées dans ECR.

### Dépendances externes et stratégie de mocks

Un défi majeur était que nous dépendions de systèmes externes tiers pour des fonctions critiques comme les vérifications de bureaux de crédit et le traitement OCR.

Pour atténuer notre dépendance à ces API externes, nous avons mis en œuvre une stratégie astucieuse : nous avons construit des fonctions Lambda mock placées derrière une API Gateway.

Ces mocks imitaient parfaitement le comportement et les réponses des systèmes tiers réels, et permettaient à l'équipe de construire et tester nos services dans un environnement rapide, isolé et économique.

SECTION 4

L'IA comme architecte cloud : générer le blueprint Terraform

Ma stratégie de déploiement consistait à diviser la configuration en deux parties distinctes : l'infrastructure fondamentale (VPC, ALB, Kafka) et les microservices eux-mêmes. Cette approche nous permettrait de créer une plateforme stable et réutilisable avant de déployer tout code applicatif.

Pour générer le code Terraform, j'ai travaillé dans mon éditeur en utilisant le plugin Cline VS Code, qui me permettait d'envoyer des prompts détaillés à mon LLM de choix, Claude. D'abord, j'ai confié à l'IA la tâche de scripter l'ensemble de l'infrastructure fondamentale.

Une fois cette plateforme de base en ligne, je me suis concentré sur le déploiement d'un seul microservice. J'ai de nouveau utilisé la combinaison Cline et Claude pour générer la configuration Terraform pour ses besoins spécifiques, une base de données RDS, un dépôt ECR et une définition de service ECS Fargate.

### La revue humaine avant application

Avant d'appliquer quoi que ce soit, j'ai méticuleusement examiné la sortie terraform plan. Cette étape avec humain dans la boucle était critique. Je répétais le cycle de planification et de révision jusqu'à ce que j'aie confiance que les changements étaient corrects et rentables. Ce premier microservice est devenu notre template.

@cite:comment-la-configuration-backend-partielle-de-terraform

SECTION 5

Validation des solutions avec Gemini

Pour compléter la génération de code de Claude, j'ai utilisé Gemini comme analyste de recherche dédié pour valider mes choix architecturaux.

Cela m'a permis de confirmer rapidement que S3 avec CloudFront était notre solution d'hébergement UI la plus rentable et que l'utilisation des règles de listener Application Load Balancer était le pattern standard et le plus sécurisé pour nos besoins de communication service-à-service.

Gemini a fourni la confiance basée sur les données pour avancer rapidement sur ces décisions critiques.

SECTION 6

Leçons clés

### Coûts et agilité

Leçon n°1 : L'IA est un générateur brillant mais a besoin d'un comptable de coûts humain.

Le code initial généré par l'IA était "de niveau entreprise" par défaut : grandes tâches Fargate et instances RDS Multi-AZ. Bien que robuste, ce n'était pas rentable. Mon premier et plus crucial travail était d'agir en tant qu'architecte senior, en examinant méticuleusement chaque terraform plan pour dimensionner correctement l'infrastructure et réduire drastiquement les coûts inutiles. Cette supervision humaine est cruciale pour gérer les dépenses cloud.

Leçon n°2 : L'infrastructure agile est un superpouvoir pour les exigences évolutives.

Après avoir déployé les deux premiers services, une nouvelle exigence est apparue : le Service A devait effectuer un appel API direct au Service B. Au lieu d'une implémentation complexe de service discovery, j'ai simplement mis à jour notre code Terraform pour ajouter de nouvelles règles de listener Application Load Balancer. En utilisant le routage basé sur les chemins, j'ai activé une communication service-à-service sécurisée en quelques minutes. Cela a prouvé l'incroyable flexibilité d'une configuration IaC, elle pouvait être adaptée à la volée.

### Les limites opérationnelles de l'IA

Leçon n°3 : L'IA ne peut pas prédire tous les pièges opérationnels.

Le système était en ligne et stable, mais quelques jours plus tard, une histoire d'horreur cloud familière a commencé : la facture explosive. Mes coûts CloudWatch montaient en flèche.

Ce "piège" du monde réel était un rappel puissant que l'IA n'a pas encore d'expérience opérationnelle. Les coupables étaient des tentatives infinies de Kafka, une journalisation verbeuse et des Container Insights au niveau du cluster, tous nécessitant un expert humain pour diagnostiquer et corriger.

SECTION 7

Du code au cloud : le README généré par IA

L'une des parties les plus époustouflantes de ce processus était que le LLM n'a pas seulement écrit le code Terraform. Je lui ai demandé : "Crée un README étape par étape pour qu'un développeur déploie ce service."

Il a produit un fichier markdown parfait avec les commandes exactes pour notre workflow, qui utilisait notre plugin Cline VS Code, activé avec le serveur AWS Terraform MCP, pour appliquer les configurations. Il incluait également des instructions pour construire une image Docker et la pousser vers ECR. Cette documentation générée par IA est devenue notre manuel officiel.

### Un environnement éphémère et reproductible

La confiance que ce workflow assisté par IA m'a donnée était immense. Je pouvais détruire l'ensemble de la pile de services et d'infrastructure avec terraform destroy et tout remettre en ligne parfaitement quelques minutes plus tard.

Ce n'était pas juste un déploiement ; c'était un environnement véritablement éphémère, reproductible et résilient, construit et documenté avec l'aide de l'IA en heures, pas en semaines.

@cite:resoudre-les-defis-de-securite-mcp-avec-le-modele

SECTION 8

Mon enseignement final : IA + expert = vélocité sans précédent

Cette expérience était un aperçu profond de l'avenir de l'ingénierie cloud. L'IA ne m'a pas remplacé. Elle m'a augmenté. Elle a assumé différents rôles, un générateur de code, un analyste de recherche, un rédacteur de documentation, ce qui m'a permis de me concentrer sur les tâches à plus haute valeur : architecture, optimisation, sécurité et contrôle des coûts.

En associant mon expertise à la vitesse de l'IA, j'ai pu déployer une plateforme cloud sophistiquée avec des dépendances complexes à un rythme qui aurait été de la pure science-fiction il y a quelques années seulement.

L'avenir ne concerne pas le remplacement des développeurs par l'IA ; il concerne les développeurs qui savent manier l'IA et deviennent les acteurs les plus précieux de l'industrie.

Une version antérieure de cet article est parue sur Medium.

Avertissement : Les déclarations et opinions exprimées dans cet article sont celles de l'auteur ou des auteurs et ne reflètent pas nécessairement les positions d'Adservio.

FAQ

Questions fréquentes