Retour à l'accueil

SDLC sur l'IA : 5 prompts pour l'automatisation du développement

L'article décrit le pipeline SDLC basé sur l'agent IA Claude Code composé de cinq commandes : clarify, design, implement, verify, document. Cette approche accélère le développement d'applications serverless 5 fois. Décomposition détaillée des étapes en utilisant l'exemple AWS/.NET/Angular.

SDLC automatisé : chaîne de 5 commandes IA
Advertisement 728x90

Pipeline SDLC piloté par un agent IA : cinq étapes de la spécification au déploiement

Un agent IA basé sur Claude Code peut automatiser l'ensemble du cycle de développement en 3-4 heures au lieu d'une semaine de travail manuel. Une chaîne de cinq commandes traite les tâches étape par étape : clarification des exigences, conception, implémentation, vérification et documentation. L'intervention humaine n'est nécessaire que pour la supervision et les ajustements entre les étapes. L'approche a été testée sur une application serverless avec AWS, .NET et Angular.

Les écueils du "vibe coding" et leur solution

Les prompts standards pour les grandes tâches entraînent des réécritures de code, des hallucinations d'API et des exigences ignorées. Causes : spécifications floues, manque de décomposition, contexte limité du modèle. La solution est une décomposition granulaire en étapes avec vérification.

Principes clés du processus :

Google AdInline article slot
  • Exigences claires et testables dans la spécification.
  • Plan étape par étape avec détails des fichiers et contrats.
  • Approche TDD : rouge-vert-refactor.
  • Revue multi-niveaux avec agents parallèles.
  • Mises à jour automatiques de la documentation du projet.

Exemple de pile technologique

Application web serverless : AWS CDK pour l'infrastructure, Lambda .NET avec une architecture à trois couches (Data-Domain-API), SPA Angular avec Syncfusion, Playwright pour les tests E2E. Données dans DynamoDB, ressources statiques sur S3.

Exemple de tâche : masquer l'édition de couleur pour Task, synchroniser avec le parent Trade côté backend, remplacer le sélecteur par une palette de 256 couleurs, passer la grille en sélection par ligne.

Ébauche de fonctionnalité (draft.md) :

Google AdInline article slot
Besoin d'améliorer un sélecteur de couleurs pour SoW.
1. Le sélecteur de couleurs est disponible uniquement pour les Trades.
2. La couleur est affichée uniquement pour les Trades
3. Couleur des Tasks :
- non affichée dans l'interface
- une fois créée - la couleur est définie comme celle du Trade associé
- si la couleur du Trade est modifiée - elle change pour toutes les Tasks associées
- toute manipulation de couleur - côté BE.
4. Améliorer le sélecteur de couleurs pour les Trades : utiliser une palette personnalisée avec 256 couleurs classiques
5. Configurer la grille Trade pour ne pas sélectionner les cellules - uniquement les lignes

Configuration de l'agent IA

Claude Code avec serveurs MCP de awslabs/mcp et plugins. Frontend : Syncfusion Angular Assistant, Angular CLI MCP. AWS : api-mcp-server, documentation-mcp-server, cdk-mcp-server, dynamodb-mcp-server, etc. Tests : Playwright MCP. Plugins : code-review, typescript-lsp, aws-serverless.

Commandes personnalisées (/clarify, /design, etc.) orchestrent le processus, chargeant le contexte depuis les fichiers CLAUDE.md.

Étape 1 : /clarify — Génération de la spécification

Analyse draft.md et CLAUDE.md. Phases : collecte de contexte, clarification des ambiguïtés, formation du modèle.

Google AdInline article slot

Le modèle inclut :

  • Exigences testables.
  • Cas d'utilisation pour les tests E2E.

La spécification est sauvegardée dans le dépôt pour édition manuelle.

Étape 2 : /design — Plan détaillé

Génère des étapes avec fichiers, lignes, contrats API/DTO. Auto-revue avec une checklist : couverture des exigences, évitation de la surcomplexité.

Le plan couvre les tests unitaires/E2E, l'infrastructure, le schéma de données. Les couches sont indépendantes grâce à des contrats bien définis.

Étape 3 : /implement — Implémentation

Suivant TDD : tests → code minimal → refactorisation. Prédiction des résultats des tests, comparaison avec la réalité. MCP pour la documentation des bibliothèques, CLAUDE.md pour les conventions.

L'implémentation peut être couche par couche ou en une seule fois.

Étape 4 : /verify — Revue multi-niveaux

Vérifie :

  • Build, tests unitaires/E2E.
  • Analyse du code mort.
  • Revue parallèle : revue de code, types, couverture, sécurité (IAM, injections).
  • Vérification par rapport à la spécification.
  • Dérive de la documentation.

Rapport structuré.

Étape 5 : /document — Mise à jour de la documentation

Met à jour CLAUDE.md pour les itérations futures. La fonctionnalité est prête à fusionner.

Limites de l'approche

Changements granulaires (jusqu'à 15-50% du contexte). Une architecture stable est obligatoire. Non adapté aux systèmes legacy avec couches ou nouveaux frameworks sans mises à jour des commandes.

Points clés à retenir

  • Granularité : La décomposition en étapes minimise les erreurs de contexte.
  • Contrôle : Édition manuelle des spécifications et plans.
  • Revue automatisée : Les agents parallèles réduisent l'erreur humaine.
  • Documentation : CLAUDE.md est le fondement de la stabilité du pipeline.
  • Efficacité : 3-4 heures contre 15-20 heures manuellement.

— Editorial Team

Advertisement 728x90

Lire ensuite