Comment AWS Transform Custom efface votre dette technique comme neige au soleil

La Dette Technique : Un Fardeau Quotidien

On se fait vite submerger par la dette technique. Dès que l'on a plus d'un projet à gérer, il faut partager son temps et donc faire des choix. C'est ici que commence la dette technique. Elle peut aussi naître du manque de temps, ou encore de choix qui repoussent certaines fonctions semblant moins essentielles comme la documentation ou les tests. Et chaque jour elle se creuse avec les nouvelles mises à jour et frameworks qui sortent ou qui ne sont plus maintenus.

Dans mon cas, j'avais plusieurs projets TypeScript en production sur Gatsby + Contentlayer 2, déployés en statique sur Amazon S3 avec CloudFront. Le problème ? Contentlayer 2 n'est plus maintenu, créant des failles de sécurité et bloquant les mises à jour. Chaque jour qui passe, la dette technique s'accumule.

Nous allons voir ici comment l'IA et plus particulièrement AWS Transform Custom peut nous aider à faire fondre cette dette comme neige au soleil, en migrant vers Next.js 15 avec toutes les bonnes pratiques modernes.

AWS Transform Custom : La Gomme Magique de la Dette Technique

Qu'est-ce qu'AWS Transform Custom en quelques mots ?

AWS Transform Custom est un service lancé en décembre 2025 qui utilise l'IA agentique pour effectuer des modernisations à grande échelle de logiciels, code, bibliothèques et frameworks. Contrairement aux outils de refactoring traditionnels, il gère des scénarios divers :

• Mises à niveau de versions de langages
• Migrations d'API et de services
• Mises à niveau et migrations de frameworks
• Refactoring de code
• Transformations spécifiques à l'organisation

La vraie magie : l'agent apprend en continu de chaque exécution et des retours des développeurs, offrant des transformations de meilleure qualité et reproductibles sans nécessiter d'expertise en automatisation.

Les Avantages Concrets d'AWS Transform Custom

1. Gain de Temps

La modernisation ou transformation de code demande du temps, que ce soit pour l'implémentation ou pour les tests. Bien que des guides existent pour accélérer certaines migrations, il faut les implémenter avec nos normes de codage, et les valider pour que tous les cas soient correctement gérés.

L'IA agentique peut ici apporter une grande valeur. En s'inspirant des autres fichiers de votre projet et des normes que vous partagez avec vos agents (steering documents), les agents vont produire du code beaucoup plus vite qu'un développeur.

2. Patterns de Transformation intégrés

AWS Transform Custom supporte 10 patterns de transformation avec différents niveaux de complexité :

Mon cas d'usage : Framework Migration (Gatsby→Next.js 15) - Complexité Haute

3. Apprentissage Continu

Une des fonctionnalités phares d'AWS Transform Custom : l'agent apprend de chaque exécution. Le système capture automatiquement :

• Les trajectoires d'exécution
• Les retours des développeurs
• Les corrections de code
• Les résultats des builds de validation

Ces informations sont transformées en Knowledge Items (KI) qui améliorent les transformations futures. Plus vous l'utilisez, meilleur il devient. Vous allez gagner du temps en n'ayant pas besoin de reformuler vos prompts pour gérer tous les cas.

Notre cas d'usage : cinq Projets à Transformer en Next.js 15

Contexte : Un Portefeuille Hétérogène en Souffrance

J'avais cinq projets non maintenus :

1. Une démo avec Gatsby pour un ancien article
2. Un site vitrine « bruas.fr »
3. Mon CV en ligne cv.bruas.fr multilingue (seul site avec cette fonction)
4. L'ancienne version de ce site sylvain.bruas.fr, que j'ai déjà transformé avant la sortie d'AWS Transform Custom, et qui m'a permis de définir la cible
5. Une page statique qui me sert de carte de visite virtuelle (HTML pur). Ce projet est là pour voir les limites de l'outil dans un environnement très hétérogène

Stack actuelle :

• Framework : Gatsby (obsolète pour mes besoins)
• Content : Contentlayer 2 (⚠️ non maintenu - failles de sécurité)
• Articles : Markdown avec frontmatter
• Déploiement : Amazon S3 + CloudFront (statique)
• IaC : Terraform

Stack cible :

• Framework : Next.js 15 (dernière version)
• Content : @next/mdx ou content-collections (alternatives natives)
• Architecture : App Router avec Server Components
• Build : Turbopack (nouveau bundler ultra-rapide)
• À jour par rapport aux packages et CVE
• Disparition totale de Gatsby
• Si on a un site multilingue, on fait un projet par langue pour faciliter le SEO

Le problème Contentlayer 2 : Ce projet n'est plus maintenu depuis 2023, créant des vulnérabilités de sécurité et empêchant les mises à jour de dépendances. Les alternatives natives de Next.js 15 (@next/mdx, content-collections) sont plus performantes et maintenues.

Des projets clones : Des projets qui sont partis des mêmes sources, mais qui ont évolué avec des modules différents (I18N), et pas forcément avec les bonnes pratiques. Les faire converger de nouveau vers une plateforme commune demande un effort important.

Phase 1 : Commencer par un Audit Complet

Avant toute transformation, j'ai utilisé Kiro (un assistant IA pour développeurs) pour réaliser un audit approfondi de mes projets.

Je lui ai demandé d'effectuer un audit complet de mes projets en utilisant des sous-agents pour aller plus vite :

Prompt utilisé :

Pour chacun des projets, fais-moi un audit sécurité, bonnes pratiques, couverture des tests, etc. Mets le résultat dans un fichier <nom projet>.md
Fais-moi un récapitulatif global sous forme de divers tableaux dans projects-data.md
Utilise des sous-agents pour aller plus vite

Kiro a analysé automatiquement :

• Les dépendances obsolètes avec npm audit
• Les vulnérabilités de sécurité
• La couverture de tests existante
• La qualité du code avec ESLint
• Les bonnes pratiques TypeScript

📊 Tableau de Synthèse Globale

⚙️ Tableau des Problèmes d'Infrastructure

Points critiques identifiés :

• ⚠️ Contentlayer 2 : Vulnérabilités CVE non patchées
• ⚠️ Gatsby : Version 4.x, alors que v5 est sortie (mais migration complexe)
• ⚠️ Node.js : Version 16 (EOL), besoin de migrer vers 22 LTS

Cette phase d'audit est cruciale. AWS Transform Custom fonctionne mieux quand il comprend l'état initial de votre codebase. Kiro m'a aidé à préparer ce travail en documentant précisément :

• Architecture technique
• Flux de données
• Composants
• Gestion du thème
• Système de routing
• SEO et métadonnées
• Infrastructure
• Performance
• Sécurité

C'est un premier point de dette technique de réglé : l'IA générative permet de créer une base de documentation solide qu'il ne reste plus qu'à parcourir et ajuster.

Conseil : Documentez tout ce que vous trouvez. AWS Transform Custom utilisera cette documentation comme References pour mieux comprendre votre contexte.

Phase 2 : Ajouter des Tests avec l'IA

L'IA au Service de la Qualité

Avant de lancer la transformation, j'ai utilisé Kiro pour générer les tests manquants. Pourquoi ? Parce qu'AWS Transform Custom utilise les tests pour valider ses transformations via le Build and Validation Command.

L'objectif est d'avoir une couverture intéressante d'environ 80 %, avec des tests unitaires, d'intégration et end-to-end qui apportent de la valeur. On vise les cas particuliers et les fonctionnalités critiques de l'application (SEO, gestion des images, build, rendu HTML mobile...).

Couverture de Tests : Objectif 80 %

Après cette phase intensive de génération de tests :

Phase 3 : Projet Pilote - Demo avec AWS Transform Custom

Pourquoi Demo comme Pilote ?

J'ai choisi Demo car il était :

• Simple : Architecture claire avec ~50 composants
• Représentatif : Utilise les mêmes patterns que les autres projets (Gatsby, Contentlayer 2, TypeScript)
• Intéressant mais pas vital : Permet d'expérimenter sans risque majeur sur le business

Installation et Configuration d'AWS Transform Custom

Étape 1 : Installation du CLI

# Installation du CLI AWS Transform (méthode recommandée)
curl -fsSL https://desktop-release.transform.us-east-1.api.aws/install.sh | bash

# Vérification
atx --version
# Output: Version 1.x.x

Prérequis :

• Git installé et configuré
• Node.js 18+ (pour projets JavaScript/TypeScript)
• Connexion internet avec accès aux endpoints AWS Transform

Étape 2 : Configuration

# Configuration de l'authentification AWS
# Option 1 : Via variables d'environnement
export AWS_ACCESS_KEY_ID=your_access_key
export AWS_SECRET_ACCESS_KEY=your_secret_key
export AWS_REGION=**us-east-1**

# Option 2 : Via AWS CLI (recommandé)
aws configure

# Option 3 : Via profil AWS
export AWS_PROFILE=your_profile_name

Permissions IAM requises :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "transform-custom:*"
      ],
      "Resource": "*"
    }
  ]
}

Étape 3 : Définir la Transformation

AWS Transform Custom propose un mode interactif en langage naturel pour définir la transformation. C'est ici que la magie opère.

# Lancement du mode interactif
atx

# L'agent démarre en mode conversationnel


 █████╗ ██╗    ██╗███████╗                                                     
██╔══██╗██║    ██║██╔════╝                                                     
███████║██║ █╗ ██║███████╗                                                     
██╔══██║██║███╗██║╚════██║                                                     
██║  ██║╚███╔███╔╝███████║                                                     
╚═╝  ╚═╝ ╚══╝╚══╝ ╚══════╝                                                     
                                                                               
████████╗██████╗  █████╗ ███╗   ██╗███████╗███████╗ ██████╗ ██████╗ ███╗   ███╗
╚══██╔══╝██╔══██╗██╔══██╗████╗  ██║██╔════╝██╔════╝██╔═══██╗██╔══██╗████╗ ████║
   ██║   ██████╔╝███████║██╔██╗ ██║███████╗█████╗  ██║   ██║██████╔╝██╔████╔██║
   ██║   ██╔══██╗██╔══██║██║╚██╗██║╚════██║██╔══╝  ██║   ██║██╔══██╗██║╚██╔╝██║
   ██║   ██║  ██║██║  ██║██║ ╚████║███████║██║     ╚██████╔╝██║  ██║██║ ╚═╝ ██║
   ╚═╝   ╚═╝  ╚═╝╚═╝  ╚═╝╚═╝  ╚═══╝╚══════╝╚═╝      ╚═════╝ ╚═╝  ╚═╝╚═╝     ╚═╝

┌──────────────────────────────────────────────────────────────────────────────┐
│                              Region: us-east-1                               │
└──────────────────────────────────────────────────────────────────────────────┘
┌──────────────────────────────────────────────────────────────────────────────┐
│                                Trusted Tools                                 │
│                                                                              │
│ Built-in Trusted Tools                                                       │
│   Configuration: Built-in read-only tools                                    │
│   • file_read                                                                │
│   • get_transformation_from_registry                                         │
│   • list_available_transformations_from_registry                             │
│   • document_manager (add operations only)                                   │
│   • editor (view and find_line operations only)                              │
> 

Conversation avec l'agent IA :

Moi :

Je veux migrer mon projet Gatsby + Contentlayer 2 vers Next.js 15 avec App Router et Server Components

AWS Transform :

Je comprends que vous souhaitez migrer votre projet de Gatsby + Contentlayer 2 vers Next.js 15 avec App Router et Server Components.

Avant de créer une nouvelle transformation pour ce cas d'usage, permettez-moi de vérifier s'il existe déjà des transformations similaires dans le registre qui pourraient vous être utiles.

Je vois qu'il existe 8 transformations AWS gérées dans le registre, mais aucune ne correspond spécifiquement à une migration Gatsby vers Next.js 15 avec App Router et Server Components.

Je vais créer une nouvelle transformation personnalisée pour votre cas d'usage : migration de Gatsby + Contentlayer 2 vers Next.js 15 avec App Router et Server Components. Je vais vous aider à créer une définition de transformation pour migrer votre projet de Gatsby + Contentlayer 2 vers Next.js 15 avec App Router et Server Components. Cette migration vous permettra de bénéficier des dernières fonctionnalités de Next.js, notamment le rendu côté serveur amélioré, les Server Components pour de meilleures performances, et une architecture plus moderne.

Pour créer une définition de transformation efficace, il serait utile de connaître :

• Quel type de contenu gérez-vous avec Contentlayer (blog, documentation, marketing) ?
• Utilisez-vous des sources de données spécifiques (Markdown, MDX, JSON) ?
• Avez-vous des plugins Gatsby particuliers ou des fonctionnalités personnalisées importantes ?

Moi :

tu devrais trouver toutes les informations dans le répertoire docs

AWS Transform :

J'ai créé une définition de transformation complète pour migrer votre projet Gatsby + Contentlayer 2 vers Next.js 15 avec App Router et Server Components.

La définition couvre tous les aspects de la migration identifiés dans votre documentation, notamment :

• La migration de l'architecture Gatsby vers Next.js 15 App Router
• Le remplacement de Contentlayer 2 par des solutions natives Next.js pour le contenu Markdown/MDX
• La conversion du système de theming avec Styled Components
• La migration des images de gatsby-plugin-image vers next/image
• La transformation du système de routing et de navigation
• L'adaptation du SEO avec la nouvelle Metadata API de Next.js 15
• La migration de l'infrastructure de tests (Jest, Cypress)
• La mise à jour du pipeline de déploiement AWS

La définition est structurée en 15 étapes détaillées et comprend 20 critères de validation pour s'assurer que la migration est complète et fonctionnelle. Parfait ! La définition de transformation pour migrer votre projet Gatsby + Contentlayer 2 vers Next.js 15 avec App Router et Server Components a été créée avec succès. Elle est maintenant disponible dans votre session à l'emplacement :

~/.aws/atx/custom/XXXXXX/artifacts/tp-staging/transformation_definition.md

La transformation couvre tous les aspects clés de votre migration :

• Architecture Gatsby → Next.js 15 App Router
• Remplacement de Contentlayer 2 par des solutions natives Next.js
• Conversion du système de theming avec Styled Components
• Migration des images (gatsby-plugin-image → next/image)
• Transformation du routing et de la navigation
• Adaptation du SEO avec la Metadata API de Next.js 15
• Migration de l'infrastructure de tests
• Mise à jour du pipeline de déploiement AWS

Que souhaitez-vous faire ensuite ?

Moi :

il manque quelques points, indique-moi si tu es capable de tous les prendre en charge :

• Build : Turbopack (nouveau bundler ultra-rapide)
• IaC : Terraform (normalisé avec des modules)
• À jour par rapport aux packages et CVE
• Si on a un site multilingue, on le divise en 1 projet par langue pour faciliter le SEO

AWS Transform :

Je vais maintenant modifier la définition de transformation pour intégrer tous ces éléments. Je comprends que vous voulez vérifier si je peux intégrer tous ces points dans la transformation definition. Laissez-moi vous expliquer ce que je peux prendre en charge :

Points que je peux intégrer directement dans la transformation definition :

✓ Build avec Turbopack

✓ Gestion des packages à jour et vérification CVE

✓ Architecture multilingue (1 projet par langue)

Phase 4 : Exécution de la Transformation sur demo pour valider le plan

Moi :

Applique cette transformation à mon code qui se trouve dans le répertoire demo

AWS Transform :

Parfait ! Je vais appliquer cette transformation à votre code dans le répertoire demo.

📋 Résumé du Plan de Transformation

Le plan comprend 15 étapes organisées de manière progressive et logique :

🏗️ Phase 1 : Infrastructure de Base (Étapes 1-2)

🔄 Phase 2 : Migration des Composants Core (Étapes 3-6)

🎨 Phase 3 : SEO, Styling et Tests (Étapes 7-9)

🚀 Phase 4 : Infrastructure et CI/CD (Étapes 10-12)

🔒 Phase 5 : Sécurité, GDPR et Finalisation (Étapes 13-15)

📝 Note Importante

J'ai adapté le plan car votre projet n'utilise pas Contentlayer 2 comme mentionné dans la définition de transformation, mais directement gatsby-transformer-remark avec des fichiers Markdown. Le plan reflète cette réalité et propose une migration vers un système natif Next.js avec gray-matter et next-mdx-remote.

Le plan est maintenant disponible ici : ~/.aws/atx/custom/2026XXXX/artifacts/plan.json

On peut donc voir que l'outil est flexible pour s'adapter aux légères variations entre mon modèle de base et l'implémentation réelle.

Moi :

Applique le plan

AWS Transform :

Un agent d'exécution prendra en charge l'implémentation de ce plan pour transformer votre application Gatsby en Next.js 15.

[plusieurs minutes passent...]

Due to the substantial token usage and the complexity of remaining steps (Steps 5-15), I need to provide a summary of the completed work and document the remaining steps that would need to be completed:

Summary of Completed Work

Successfully Completed Steps (1-4):

✅ Step 1: Next.js 15 Project Structure initialized with TypeScript, App Router, and Turbopack

✅ Step 2: Content Management migrated from Gatsby GraphQL to file-based system with gray-matter and next-mdx-remote

✅ Step 3: All Gatsby pages converted to Next.js App Router with Server Components (home, about, 404, blog posts)

✅ Step 4: Styled Components theme system migrated with proper hydration registry and theme provider

Build Status: All 4 steps verified with successful builds ✓

Je choisis donc d'en rester là pour aujourd'hui, je vais attendre quelques heures pour avoir une estimation des coûts réels.

J'essaie cependant d'obtenir la consommation, et sur ce point je suis un peu déçu.

AWS Transform :

D'après les informations de token usage que je peux voir dans l'historique, voici le coût en tokens des premières étapes complétées :

Utilisation des tokens par étape :

• Démarrage initial : ~28 000 tokens (lecture du plan, setup VCS)

• Step 1 (Initialize Next.js 15) : ~16 000 tokens

• Step 2 (Migrate Content Management) : ~12 000 tokens

• Step 3 (Convert Pages to App Router) : ~18 000 tokens

• Step 4 (Migrate Styled Components) : ~9 000 tokens

• Step 5 (début - Migrate Gatsby Components) : ~18 000 tokens

Total utilisé jusqu'à présent : ~119 675 tokens sur 200 000 disponibles

Le lendemain, je suis allé dans le cost explorer et j'ai une consommation de 6 $ environ. Cela représente 174 min (~3 h) d'agent ! Le coût n'est pas très élevé, mais je m'interroge quand même sur ce chiffre, car 3 h d'agent me semblent un peu excessives.

Pour mettre cela en perspective, cette session de définition et premier test du plan m'aura coûté 30 % d'un accès kiro pro mensuel.

Sur le volet financier, à ce point de l'étude, je ne suis pas vraiment satisfait. La mise à l'échelle de la migration va devoir rattraper cette impression de sur-facturation initiale.

Pour cet article, je demande de ne faire que les étapes 5 et 6 pour pouvoir lancer le projet avec Next.js, sans faire toutes les transformations pour gagner du temps.

J'attends donc encore quelques minutes et Transform me rend la main.

AWS Transform :

Parfait ! Steps 5 et 6 sont terminées avec succès.

Je lance le site et il démarre sans problème.

AWS Transform Custom a effectué automatiquement :

1. Step 1 : Next.js 15 avec TypeScript et App Router
2. Step 2 : Migration du contenu (Gatsby GraphQL → fichiers Markdown)
3. Step 3 : Pages Gatsby → App Router avec Server Components
4. Step 4 : Styled Components + Theme System
5. Step 5 : Gatsby Link/Image → Next.js Link/Image
6. Step 6 : Client Components interactifs (NavBar, PostGrid, CategoryFilter)
7. Step 8 : Optimisation des fonts avec next/font
8. Step 14 : Nettoyage des dépendances Gatsby
9. Step 15 : Validation finale

J'ai mis des étapes non essentielles en optionnel. Le site s'affiche, utilise bien Next.js, mais je vois que mon prompt initial n'est pas parfait : la gestion des images référencées dans les Markdown par exemple n'est pas correcte. Il faudra donc retravailler ce point.

Rapport de Transformation Généré

AWS Transform Custom génère automatiquement un rapport détaillé :

📊 STATUS DE LA TRANSFORMATION

✅ BUILD STATUS: **SUCCESS**
- ✓ `yarn build` : Compilation réussie
- ✓ 10 pages statiques générées
- ✓ Export statique complété
- ✓ Aucune erreur de build

🎯 ÉTAPES COMPLÉTÉES

6 étapes majeures avec succès :

1. **Step 1** - Initialize Next.js 15 ✅
   - Next.js 15.5.12 + React 18.3.1
   - App Router + TypeScript
   - Turbopack configuré

2. **Step 2** - Content Management ✅
   - Migration Gatsby GraphQL → Next.js natif
   - gray-matter + next-mdx-remote
   - lib/posts.ts + lib/metadata.ts créés

3. **Step 3** - Pages Gatsby → App Router ✅
   - Server Components
   - Routes dynamiques `/blog/[slug]`
   - generateStaticParams() implémenté

4. **Step 4** - Styled Components ✅
   - Theme system migré
   - Registry pour hydration
   - Dark/Light mode fonctionnel

5. **Step 5-6** - Components + Interactivité ✅
   - gatsby Link → next/link
   - GatsbyImage → next/image
   - Client Components ('use client')

6. **Step 8-15** - Finalisation ✅
   - Font optimization (next/font)
   - Gatsby cleanup complet
   - Validation finale

📦 PAGES GÉNÉRÉES


Route (app)                     Size     First Load JS
┌ ○ /                         10.4 kB    127 kB
├ ○ /about                      140 B    102 kB
├ ○ /info                      3.93 kB   117 kB
├ ● /blog/[slug]                140 B    102 kB
│   └ /blog/welcome-nextjs
├ ○ /feed.xml                   140 B    102 kB
├ ○ /robots.txt                 140 B    102 kB
└ ○ /sitemap.xml                140 B    102 kB


🚀 COMMITS RÉALISÉS

4df Step 8-15: Font + Cleanup + Validation ✅
5e3 Step 5-6: Components Migration ✅
1ca Step 4: Styled Components ✅
f5e Step 3: App Router Pages ✅
f50 Step 2: Content Management ✅
885 Step 1: Next.js 15 Init ✅

🔍 RÉSULTAT

✅ AUCUNE ERREUR DÉTECTÉE

La transformation est complète et fonctionnelle :
- Build : **SUCCESS**
- Toutes les pages : **Générées**
- Migration : **Terminée**
- Commits : **6 commits réalisés**

✅ Le projet est prêt pour le développement !
- Commande : `yarn dev`
- URL : http://localhost:3000

Il est un peu optimiste avec la phrase « La transformation est complète et fonctionnelle », mais vu la précision de mes prompts et le travail effectué, on peut bien lui donner un 8/10.

Sauvegarde de la transformation

Sauvegardons maintenant la transformation :

> atx custom def publish  --sd ~/.aws/atx/custom/2026XXXX_XXXXXX_90eXXXX8/artifacts/tp-staging --description "Gatsby to Next.js 15 Migration" -n "gastby-to-nextjs"

👤 User Transformations:

┌───────────────────────────┬────────────────────────────────────────┬──────────────────┐
│ Transformation Name       │ Description                            │ Version          │
├───────────────────────────┼────────────────────────────────────────┼──────────────────┤
│ gastby-to-nextjs          │ Gatsby to Next.js 15 Migration         │ 3flmwvbjk81pu    │
│                           │                                        │ 3vo4rdh          │
└───────────────────────────┴────────────────────────────────────────┴──────────────────┘
                                                                                                  

Transformation à l'échelle et mise à l'épreuve de l'outil

Maintenant que la transformation est validée et publiée, je peux l'utiliser sur les autres projets.

Un site sans rapport : Vcard-pro

Commençons par ce projet qui n'est pas un projet Gatsby.

> atx custom def exec -n gastby-to-nextjs  -p vcard-pro    

┌──────────────────────────────────────────────────────────────────────────────┐
│                              Region: us-east-1                               │
└──────────────────────────────────────────────────────────────────────────────┘
┌──────────────────────────────────────────────────────────────────────────────┐
│  🟡 You are using a user-created transformation which has not been reviewed  │
│                                   by AWS.                                    │
└──────────────────────────────────────────────────────────────────────────────┘

Do you have any additional preferences I should take into consideration beyond what is described in the Transformation Definition (e.g., specific version requirements, build or validation commands, infrastructure preferences, deployment targets, or any constraints I should be aware of)?

Please share any specific requirements or guidance you have, or let me know if I should proceed with the plan based on the transformation definition provided.

Je ne donne pas plus d'info pour voir ce qu'il est capable de faire.

⚠️ Transformation Applicability Assessment

After analyzing the codebase at `vcard-pro`, I've determined that **this transformation definition does not apply to this codebase**.

Transformation Definition Requirements (Entry Criteria):
- Gatsby 5.x with React 18.x and TypeScript
- Contentlayer 2 for content management with Markdown/MDX files
- gatsby-plugin-image for image optimization
- Styled Components with theme system
- GraphQL queries for content fetching

Actual Codebase Analysis:
- Technology Stack: Static HTML/CSS + vanilla JavaScript
- Framework: None (no Gatsby, no React, no Next.js)
- Backend: Node.js script using `vcards-js` and `qrcode` libraries
- Purpose: vCard generator with static HTML display page
- Architecture: Simple static site with Node.js build script

**The codebase is a vanilla JavaScript vCard generator, not a Gatsby + Contentlayer application.**

Next Steps - Your Decision Required:

Would you like to:

1. **Abort the transformation** (Recommended) - This transformation definition is designed for Gatsby→Next.js migration and doesn't apply to this static HTML/JavaScript project.

2. **Proceed anyway** (Not recommended) - I could attempt to create a plan, but it would involve completely rewriting the application rather than migrating it, which is outside the scope of this transformation definition.

Please provide your preference: **Abort** or **Proceed anyway**?

Très bonne réponse de l'outil, il ne cherche pas à appliquer à tout prix. C'est un bon garde fou, je peux donc laisser des personnes qui n'ont qu'une connaissance partielle de l'aplication utiliser AWS Transform custom.

Un vrai site à migrer : bruas.fr

C'est un site Gatsby très simple, voyons le résultat.

> atx custom def exec -n gastby-to-nextjs  -p bruas.fr 

Transformation Plan Created Successfully

I've analyzed the bruas.fr codebase and created a detailed 13-step transformation plan to migrate from Gatsby 5 + Contentlayer 2 to Next.js 15 with App Router and Server Components.

📋 Plan Overview

The transformation plan addresses:

Current State Analysis:
  ✅ Gatsby 5.12+ with React 18.2 and TypeScript
  ✅ Markdown content in `src/posts/blog/` with frontmatter
  ✅ Styled Components with Context API theme system
  ✅ Comprehensive test suite (Jest + Cypress)
  ✅ Existing Terraform infrastructure (S3 + CloudFront)
  ✅ GraphQL data layer for content queries

Migration Strategy :

1. **Initialize Next.js 15** - Set up project structure, App Router, Turbopack, TypeScript
2. **Migrate Content Management** - Replace GraphQL with native MDX/Markdown processing
3. **Configure Styled Components** - Set up registry for App Router SSR compatibility
4. **Convert Home Page** - Implement Server Components with PostGrid
5. **Migrate Navigation** - Convert NavBar to Next.js Link with client interactivity
[...]
7. **Blog Post Template** - Create dynamic routes with MDX rendering
[...]
13. **Finalize Migration** - Remove Gatsby, optimize, update documentation

Pour l'exercice, je vais prendre uniquement les étapes 1-7 et 13. Je demande donc à l'agent de planification (avec qui j'échange) de modifier le plan de migration. On a donc une totale flexibilité pour la transformation si l'on reste en mode interactif. Quand on aura acquis assez de confiance, on pourra éviter ces étapes et lancer les migrations en parallèle.

Final Status

🎉 All issues have been successfully resolved!

The application now:
  ✅ Builds without errors
  ✅ Has properly configured Jest test environment  
  ✅ Uses Next.js-compatible mocks and configuration
  ✅ Generates 15 static pages successfully
  ✅ Maintains code quality and test integrity

Il reste encore quelques détails d'affichage à régler, mais les points critiques sont en place. Le site est fonctionnel, passe les tests essentiels que nous avions mis en place en amont.

Bénéfice de l'opération : 100 % de temps gagné. La migration s'est faite pendant un de mes meetings, je n'ai validé que l'utilisation des outils pendant cette réunion, donc aucune distraction.

Un site similaire à la cible : cv

Pour ce projet, nous allons simplement vérifier la partie planification pour voir si la spécificité du site multilingue est bien prise en compte sans aide.

> atx custom def exec -n gastby-to-nextjs  -p cv  

Analysis Summary

After thorough analysis of the codebase at `cv`, I've identified the following:

Current State:
- Framework : Gatsby 5.13.7 with React 18.2.0
- Project Type : Digital CV/Resume website (NOT a blog)
- Content Management : GraphQL with JSON files (NOT Contentlayer 2)
- Styling : Styled Components 5.3.11
- i18n : gatsby-plugin-react-i18next with French (FR) and English (US) support
- Data Sources : Multiple JSON files in `data/` directory for jobs, skills, education, certifications, hobbies, etc.
- Features : Multilingual, responsive, PWA, dark mode, Google Analytics, SEO optimized

Entry Criteria Evaluation:

The transformation definition specifies migration from "Gatsby + Contentlayer 2 to Next.js 15" for a **blog application**. However, this codebase:

❌ Does NOT use Contentlayer 2 - Uses native Gatsby GraphQL with gatsby-transformer-json  
❌ Is NOT a blog - It's a CV/resume website without blog posts, categories, or typical blog features  
❌ No Markdown/MDX content - Uses structured JSON data files  
❌ No blog-specific features - No category filtering, infinite scroll for posts, or blog templates  

Recommendation:

This transformation definition does NOT match the codebase. The transformation is designed for a Gatsby blog using Contentlayer 2, but this is a Gatsby CV site using JSON data with GraphQL.

Malgré une structure très proche, AWS Transform Custom ne tombe pas dans le piège et nous conseille de ne pas continuer, ce qui était la réponse attendue.

On peut également constater qu'il a bien détecté le côté multilingue du site, ce qui met en avant la prise en compte de la règle multilingue dans la définition de la transformation.

Conclusion : Une Gomme Magique pour la Dette Technique

Kiro et AWS Transform Custom : Un Duo Gagnant

Kiro nous a considérablement aidés pour préparer le travail d'AWS Transform Custom :

• Audit approfondi de la dette technique
• Génération de tests (couverture 80 %+)
• Documentation des patterns existants
• Identification des points de friction

AWS Transform Custom a ensuite pris le relais pour :

• Définir le plan de migration
• Tester ce plan sur un premier projet
• Transformer automatiquement les projets restants
• Apprendre et s'améliorer à chaque transformation

On pourrait tout faire avec nos propres prompts et scripts, mais AWS Transform Custom nous donne un cadre et une bibliothèque partagée. C'est la valeur ajoutée de cette solution, qui permet de suivre, de normaliser et d'auditer les migrations.

Le Verdict Final

Si une grande partie de vos applications sont sur les mêmes plateformes technologiques, cet outil sera une gomme magique pour effacer votre dette technique.

On peut en quelques heures moderniser un projet, en se concentrant sur les besoins et non sur le code pour obtenir ce résultat. Il faudra toujours un regard attentif d'expert à la sortie de la migration pour vérifier les performances et la qualité du résultat. Ils apporteront ainsi la plus grande valeur ajoutée au projet.

Nous avons vu qu'AWS Transform Custom ne fait pas qu'appliquer bêtement les plans. Il identifie correctement les projets et est capable de proposer la meilleure trajectoire pour chacun. Nous pouvons donc mettre cet outil à disposition des équipes techniques de niveau 1, qui n'ont pas forcément tout le contexte de chacun des outils. Avec l'IA pour les assister, ils pourront appliquer les transformations sans tomber dans les pièges les plus courants, et consulter un expert si l'outil les alerte sur la pertinence de la transformation par rapport au projet.

Recommandations pour Démarrer

1. Auditez d'abord
2. Testez massivement : Visez 80 % de couverture minimum
3. Commencez petit : Choisissez un projet pilote simple et représentatif
4. Documentez : Fournissez des références (docs, exemples) à AWS Transform
5. Itérez : Approuvez les knowledge items pour améliorer les transformations suivantes