Développer sous WordPress et PrestaShop avec l'IA en 2026

Mis à jour le 1er novembre 2026. Article réécrit : contexte de WordPress 7.0 et de PrestaShop 9.2, exemple du client d’IA de WordPress, risques classés selon l’OWASP et section sur les licences complétée.

Les assistants de code interviennent aujourd’hui à chaque étape d’un projet WordPress ou PrestaShop : fonctions, tests, relecture, documentation, mises à jour. Ils déplacent le travail vers le cadrage, la vérification et la décision. Cet article présente les usages utiles, le cadrage des demandes, les contrôles de sécurité, les licences et ce qui reste à l’équipe.

Où en est-on fin 2026

L’usage est massif et la confiance faible : un code presque juste est le plus coûteux, car il passe les premiers essais.

WordPress 6.9 a introduit l’API Abilities, un registre des actions qu’un site expose, avec un contrôle des droits. WordPress 7.0 ajoute un client d’IA indépendant du fournisseur et un écran Réglages > Connecteurs pour les clés. PrestaShop 9.2 livre Ask AI, un assistant du back-office fondé sur le serveur MCP de PrestaShop, qui demande une confirmation avant toute modification. Ces briques changent la manière d’écrire une extension, pas les règles de sécurité.

Usages utiles sur WordPress et PrestaShop

La sortie d’un assistant est un brouillon, à lire, exécuter et valider avant tout déploiement.

Écrire des fonctions et des requêtes

Sur WordPress, un assistant peut proposer un hook, un shortcode ou un point d’entrée AJAX ; sur PrestaShop, un contrôleur, un service, un hook de module ou une requête. Demandez explicitement les garde-fous : contrôle des droits, validation des entrées, échappement des sorties, requêtes protégées. Sans cette consigne, le code peut fonctionner tout en restant vulnérable. Voici un gestionnaire AJAX qui applique ces règles :

<?php
add_action( 'wp_ajax_maj_titre_contenu', 'mon_plugin_maj_titre' );

function mon_plugin_maj_titre() {
    check_ajax_referer( 'mon_plugin_nonce', 'nonce' );

    $post_id = absint( $_POST['post_id'] ?? 0 );
    $titre   = sanitize_text_field( wp_unslash( $_POST['titre'] ?? '' ) );

    if ( ! $post_id || ! current_user_can( 'edit_post', $post_id ) ) {
        wp_send_json_error( 'Accès refusé.', 403 );
    }

    if ( '' === $titre ) {
        wp_send_json_error( 'Titre vide.', 400 );
    }

    wp_update_post( array(
        'ID'         => $post_id,
        'post_title' => $titre,
    ) );

    wp_send_json_success();
}

Relisez-le en vous demandant qui peut appeler cette action et sur quel objet. La documentation de WordPress est explicite : un nonce ne sert jamais à l’authentification ni au contrôle d’accès. C’est current_user_can( 'edit_post', $post_id ) qui répond à la question des droits ; un contrôle sur le seul rôle ne le garantit pas.

Côté PrestaShop, la même logique vaut pour les requêtes :

<?php
$reference = pSQL(Tools::getValue('reference'));
$idProduit = (int) Tools::getValue('id_product');

$existe = (int) Db::getInstance()->getValue(
    'SELECT COUNT(*) FROM `' . _DB_PREFIX_ . 'product`
     WHERE `reference` = \'' . $reference . '\'
     AND `id_product` != ' . $idProduit
);

pSQL() protège la chaîne et (int) force l’identifiant en entier. Un point souvent manqué par les assistants : dans PrestaShop 9.2, Db::insert() et Db::update() n’échappent pas les valeurs qu’on leur passe. Chaque chaîne doit passer par pSQL() avant l’appel.

Utiliser le client d’IA de WordPress 7.0

Pour une extension qui appelle elle-même une IA, WordPress 7.0 évite de gérer la clé dans le code du plugin : l’administrateur configure le fournisseur dans les Connecteurs, et le plugin passe par wp_ai_client_prompt(). La note de développement recommande de tester la prise en charge avant l’appel et d’exprimer une préférence de modèle plutôt qu’une exigence.

<?php
add_action( 'wp_ajax_mon_plugin_resume', 'mon_plugin_resume' );

function mon_plugin_resume() {
    check_ajax_referer( 'mon_plugin_resume', 'nonce' );

    $post_id = absint( $_POST['post_id'] ?? 0 );
    if ( ! $post_id || ! current_user_can( 'edit_post', $post_id ) ) {
        wp_send_json_error( 'Accès refusé.', 403 );
    }

    if ( ! function_exists( 'wp_ai_client_prompt' ) ) {
        wp_send_json_error( 'Client IA indisponible : WordPress 7.0 requis.', 501 );
    }

    $contenu = wp_strip_all_tags( get_post_field( 'post_content', $post_id ) );
    $builder = wp_ai_client_prompt( 'Résumez ce texte en deux phrases : ' . $contenu )
        ->using_temperature( 0.3 );

    if ( ! $builder->is_supported_for_text_generation() ) {
        wp_send_json_error( 'Aucun fournisseur d\'IA configuré.', 503 );
    }

    $texte = $builder->generate_text();
    if ( is_wp_error( $texte ) ) {
        wp_send_json_error( 'Génération impossible.', 502 );
    }

    wp_send_json_success( array( 'resume' => sanitize_textarea_field( $texte ) ) );
}

La réponse de l’IA est traitée comme une entrée utilisateur : elle est nettoyée avant d’être renvoyée. Le contenu de l’article est lui aussi une donnée non fiable, qui peut contenir des instructions destinées au modèle. Sur PrestaShop, le même schéma (droits, file, validation humaine) est détaillé dans la création d’un module PrestaShop connecté à une API d’IA.

Écrire et compléter les tests

Un assistant propose des cas limites souvent oubliés : valeur vide, identifiant inexistant, utilisateur sans droit. Un test généré doit échouer quand vous cassez volontairement la règle contrôlée ; sinon, il valide peut-être un comportement faux. Les parcours complets se vérifient sur une préproduction.

Relire le code

Demandez-lui de signaler les sorties non échappées, les requêtes non protégées ou les fonctions dépréciées : des pistes, pas un verdict. Complétez par une analyse statique reproductible, par exemple les WordPress Coding Standards avec PHP_CodeSniffer.

Documenter et préparer une montée de version

L’assistant rédige vite docblocks et README, mais décrit parfois le comportement souhaité plutôt que réel : relisez contre le code. Pour une mise à jour, fournissez-lui les notes de version officielles plutôt que de compter sur sa mémoire. Exemple concret : dans PrestaShop 9, FrameworkBundleAdminController est déprécié au profit de PrestaShopAdminController, et l’annotation @AdminSecurity devient l’attribut PHP #[AdminSecurity].

Cadrer les demandes

Donner le contexte du projet

Indiquez les versions de WordPress, de PHP et de PrestaShop, le thème enfant ou le module visé, le préfixe des fonctions, options et tables, ainsi que les bibliothèques autorisées. Sans préfixe, les noms produits risquent d’entrer en collision avec ceux d’autres extensions.

Écrire des consignes durables

Placez les règles dans un fichier d’instructions versionné, lu par les outils qui le prennent en charge. La documentation de GitHub cite .github/copilot-instructions.md, des fichiers AGENTS.md, ou un CLAUDE.md ou GEMINI.md à la racine du dépôt. Exemple de contenu :

# Règles du dépôt
- Cibles : WordPress 6.9+ et PHP 8.1+ ; PrestaShop 9.x pour les modules.
- Préfixe obligatoire : monplugin_ (fonctions, options, tables).
- Ne jamais modifier le cœur de WordPress ni les fichiers du cœur de PrestaShop.
- PrestaShop : module et hooks d'abord ; une surcharge doit être justifiée.
- Toute entrée est validée, toute sortie échappée ; droits vérifiés côté serveur.
- Aucun secret dans le code : utiliser des marqueurs comme <CLE_API>.
- Chaque fonction modifiée s'accompagne d'un test PHPUnit.

Relisez ce fichier à chaque revue : il fait partie du code.

Limiter le périmètre

Demandez une modification par fonction ou par fichier : une demande large produit un diff difficile à relire. Pour PrestaShop, précisez le mécanisme attendu. La documentation développeur qualifie les surcharges d’exclusives et risquées, déconseille leur usage dans un module distribué et les interdit dans les modules partenaires.

Risques à maîtriser

Secrets dans les prompts

Ne collez jamais une clé d’API, un mot de passe, un jeton, le contenu de wp-config.php ou du fichier app/config/parameters.php de PrestaShop, ni un export contenant des données clients. Utilisez des marqueurs, par exemple <CLE_API>. Si une clé a fuité, révoquez-la aussitôt. Vérifiez aussi les conditions de conservation des données du fournisseur au regard de vos obligations au titre du RGPD.

Licences et propriété du code

La propriété et la licence d’un code généré ne se présument pas. Si un extrait reproduit du code existant, la licence de la source s’applique. Les licences des deux écosystèmes diffèrent :

Les règles du répertoire WordPress ne parlent pas du code généré par IA : elles demandent seulement de vérifier la licence de tous les fichiers inclus. Pour un thème ou un module commercialisé, faites valider ce point par un juriste.

Ce qui reste humain

• Architecture : extension existante ou développement sur mesure, découpage en modules, frontière entre thème, extensions et serveur. Ces choix engagent la maintenance sur plusieurs années.
• Sécurité : droits, nonces, permissions du back-office PrestaShop, validation, échappement, fichiers téléversés. Ils se vérifient, ils ne se délèguent pas. Le retour technique sur la faille d’injection SQL de PrestaShop en 2022 montre ce que coûte une requête non protégée.
• Revue et tests : vérifier que le code répond à la demande et ne contient aucune logique non demandée, sur une préproduction sans données clients non maîtrisées.
• Mises à jour : sauvegarde, tests de non-régression et choix du moment de mise en production. La méthode est détaillée dans la mise à jour sécurisée de PrestaShop et WordPress sur un VPS.

Démarche recommandée

1. Définissez la tâche, son périmètre et les versions visées.
2. Rédigez la demande avec le contexte du projet, sans secret, en exigeant les garde-fous de sécurité.
3. Relisez le résultat ligne à ligne, exécutez les tests et l’analyse statique.
4. Vérifiez chaque dépendance ajoutée et chaque fonction appelée dans la documentation officielle.
5. Testez sur préproduction, suivez les anomalies après mise en production et ajustez le fichier de consignes.

Pour exposer une boutique à un assistant plutôt que de l’utiliser pour coder, voyez le guide du serveur MCP de PrestaShop ; pour WordPress, les changements du plugin AI 1.5.0. Si vous préférez confier un développement relu et testé, décrivez votre besoin dans notre formulaire de demande de développement sur mesure.

Questions fréquentes

L’assistant peut-il écrire un module PrestaShop ou un plugin WordPress complet sans relecture ?

Non. Le code doit être relu, testé sur une préproduction et contrôlé sur les points de sécurité avant toute mise en production. Il sert de base de travail, pas de livrable.

Faut-il communiquer le contexte du projet à l’assistant ?

Oui, sans jamais y joindre de secret. Indiquez les versions, le préfixe et les règles de l’équipe, de préférence dans un fichier d’instructions versionné, et remplacez clés, mots de passe et données clients par des marqueurs.

Les tests générés suffisent-ils à valider une fonctionnalité ?

Non. Un test peut confirmer un comportement actuel erroné. Vérifiez qu’il échoue lorsque la règle est volontairement cassée, puis complétez par des tests manuels sur une préproduction.

Le client d’IA de WordPress 7.0 dispense-t-il de gérer la sécurité ?

Non. Il dispense le plugin de stocker les clés, puisque l’administrateur les saisit dans les Connecteurs. Le contrôle des droits, le nonce, le nettoyage de la réponse et la protection contre les contenus piégés restent à la charge du plugin.

Sources

• Stack Overflow, Developer Survey 2025, section IA : https://survey.stackoverflow.co/2025/ai
• WordPress, page de la version 7.0 : https://wordpress.org/documentation/wordpress-version/version-7-0/
• Make WordPress Core, « Introducing the AI Client in WordPress 7.0 » (24 mars 2026) : https://make.wordpress.org/core/2026/03/24/introducing-the-ai-client-in-wordpress-7-0/
• WordPress Developer Resources, Abilities API : https://developer.wordpress.org/apis/abilities-api/
• WordPress Developer Resources, Nonces : https://developer.wordpress.org/apis/security/nonces/
• WordPress, Detailed Plugin Guidelines : https://developer.wordpress.org/plugins/wordpress-org/detailed-plugin-guidelines/
• GitHub Docs, instructions personnalisées de dépôt : https://docs.github.com/en/copilot/how-tos/configure-custom-instructions/add-repository-instructions
• PrestaShop DevDocs, Admin controllers (9.x) : https://devdocs.prestashop-project.org/9/modules/concepts/controllers/admin-controllers/
• PrestaShop DevDocs, Overrides : https://devdocs.prestashop-project.org/9/modules/concepts/overrides/
• E-commerce Nation, PrestaShop 9.2 : https://www.ecommerce-nation.fr/prestashop-9-2-one-page-checkout-ia-extra-properties/
• OWASP, Top 10 for LLM Applications 2025 : https://genai.owasp.org/llm-top-10/
• Code source de PrestaShop 9.2.0 (installation locale) : classes/db/Db.php, docs/licenses/LICENSE.txt, en-têtes des modules natifs.

L'équipe Genisoft Agence web PrestaShop & WordPress

Agence web spécialisée PrestaShop et WordPress : création, maintenance, sécurité, performance et référencement. Nos tutoriels sont issus de nos interventions sur de vraies boutiques.

L'agence Genisoft → LinkedIn →