Extensions PHP vers App Builder : Adobe confie la conversion à des agents IA

Toute discussion de replatforming Magento finit par buter sur le même mur : les extensions. Une boutique de dix ans transporte des dizaines de modules PHP — développés en interne, achetés puis retouchés — qui vivent dans le processus même du cœur. C'est précisément ce code que la déclinaison SaaS, Adobe Commerce as a Cloud Service, n'accepte plus : toute personnalisation doit être réécrite à l'extérieur, en App Builder. Jusqu'ici, cette conversion se chiffrait à la main, module par module, et c'est souvent elle qui enterrait le dossier. Adobe a décidé d'outiller le chantier avec deux briques complémentaires : un agent de migration hébergé, et des skills officiels pour les assistants de code que vos équipes utilisent déjà.

Un agent qui travaille sur plan approuvé

Le Commerce Developer Agent est un outil hébergé par Adobe, accessible après connexion avec un compte Adobe, qui couvre deux scénarios : créer une application App Builder depuis une page blanche, ou convertir une extension Commerce existante. Sa particularité intéresse directement les décideurs : il ne génère rien sans plan validé. L'agent produit d'abord un blueprint — un plan d'architecture découpé en phases — que le développeur relit, corrige et approuve avant toute écriture de code. La génération s'appuie ensuite sur les squelettes App Builder officiels : abonnements aux événements Commerce, webhooks, écran de réglages pour le marchand, persistance des données. Le résultat s'exporte en archive, prêt à rejoindre votre dépôt et votre chaîne de livraison.

La documentation est tout aussi claire sur les limites, et c'est à son honneur. Tout code généré doit être relu avant d'approcher la production : Adobe présente l'agent comme un générateur de point de départ, pas comme un développeur autonome. Il ne fabrique ni votre intégration continue, ni votre environnement local, ni les raccordements API Mesh ; une session ne traite qu'un projet à la fois, et une génération peut demander environ cinq minutes.

Des skills ouverts pour vos propres assistants

Le second volet est peut-être le plus intéressant pour les équipes déjà équipées. Adobe publie des skills officiels : des modes d'emploi exécutables qui enseignent à un assistant de code les patterns App Builder corrects — initialiser une application, s'abonner aux événements, poser des webhooks, créer la configuration marchand, la persistance ou une interface d'administration, et convertir un projet existant. Ils suivent le standard ouvert agentskills.io et s'installent en une commande (npx skills add adobe/skills) dans Claude Code, Cursor, VS Code Copilot ou Gemini CLI. Le dépôt public adobe/skills, sous licence Apache 2.0, en compte déjà plusieurs dizaines — Commerce, mais aussi AEM, Analytics ou Workfront.

La nuance est stratégique. L'agent hébergé vous fait entrer dans l'outil d'Adobe ; les skills font entrer le savoir d'Adobe dans votre outil. Pour une équipe qui a déjà sa discipline de revue, ses conventions et son pipeline, la seconde voie s'adopte sans rien changer au delivery — et sans dépendre de la feuille de route d'un portail.

Ce que cela change dans un dossier de migration

Le chiffrage change de nature. La bonne question n'est plus « combien de jours pour tout réécrire », mais « combien de mes modules tiennent dans les patterns couverts » : événements, webhooks, configuration, stockage, écran d'administration. Ceux-là se convertissent vite et à coût prévisible ; ce qui modifie le processus de commande au cœur du logiciel reste un vrai projet d'architecture.
La relecture devient le premier poste de coût. Le code arrive plus vite, mais chaque ligne doit être revue ; vos développeurs seniors passent d'auteurs à relecteurs. Sans porte de revue solide — tests d'acceptation, intégration continue, règle du « jamais en production sans relecture » — un générateur ne fait que produire de la dette plus vite.
Le verrou fournisseur se discute pièce par pièce. Les skills suivent un standard ouvert et fonctionnent dans l'assistant de votre choix ; le code cible, lui, reste App Builder, donc l'infrastructure d'Adobe. La conversion est un engagement de plateforme : décidez-le pour la plateforme, pas pour la commodité de l'outil.

Par où commencer

Inventoriez vos extensions et triez-les en deux colonnes : couvertes par les patterns ci-dessus, ou ancrées dans le processus du cœur. La seconde colonne mesure votre vraie distance au SaaS.
Pilotez sur une seule extension de complexité moyenne : blueprint, génération, puis mesure honnête du temps de relecture et de mise au niveau. C'est votre coût unitaire de conversion ; le multiplier vaut mieux que toute estimation abstraite.
Posez les garde-fous avant d'accélérer : tests rejouables sur les parcours critiques, revue obligatoire, interdiction de production sans relecture. La vitesse de génération ne vaut que ce que vaut votre contrôle qualité.

Dévoilé au Summit au printemps, l'agent est passé en disponibilité générale fin septembre, et App Management a désormais son entrée dans l'administration de Commerce. Le message d'Adobe pour 2027 est limpide : la réécriture de vos extensions n'est plus une raison de repousser la décision — l'éditeur fournit les ouvriers. Reste à fournir ce qui ne se génère pas : le chef de chantier.