🎁 Perplexity PRO offert

30 jours gratuits

Téléchargez Comet, connectez votre compte et posez votre première question.

Activer l'offre →

Rigueur du Code vs Chaos de l’IA : Faut-il réinventer nos standards PHP pour les marchands PrestaShop ?

🎯 Introduction : L’art du développement PHP moderne

On ne va pas se mentir, le développement PHP moderne est devenu une forme d’art.

Si vous êtes comme moi, vous avez passé les dix dernières années à célébrer la montée en puissance de notre langage favori. Avec PHP 7, puis PHP 8, nous avons enfin eu les armes pour nous battre à armes égales avec Java ou C#. Nous avons adopté le typage strict (declare(strict_types=1)), nous avons construit des architectures hexagonales, nous avons sanctifié les Value Objects et banni les données “floues”.

Nous avons construit des forteresses. Et c’était nécessaire pour la stabilité de nos boutiques PrestaShop.

Mais voilà… L’Intelligence Artificielle est entrée dans la pièce. 🤖

Et l’IA, par nature, est un invité turbulent. Elle ne respecte pas nos types stricts. Elle est probabiliste, créative, et parfois, franchement bordélique.

Récemment, j’ai lancé un petit pavé dans la mare sur LinkedIn en suggérant que le “Loose Typing” (le typage faible) de PHP, souvent décrié, pourrait être notre meilleur allié face à l’incertitude des LLM. Une idée qui a fait réagir (à juste titre !) un confrère, qui résumait parfaitement la pensée “puriste” :

“Je préfère remettre en question ≈10 ans d’améliorations de PHP […] plutôt que d’écrire des Value Objects et des DTO qui feront correctement le travail de casting.”

Sa remarque est excellente. Elle pose la vraie question qui nous anime aujourd’hui : Doit-on sacrifier la rigueur de notre ingénierie logicielle pour satisfaire les caprices de l’IA et les besoins d’automatisation des marchands ?

Spoiler : La réponse n’est pas binaire. C’est une troisième voie.

⚔️ Partie 1 : Le Choc des Cultures (L’Ingénieur vs Le Robot)

Pour comprendre la friction actuelle, il faut regarder d’où l’on vient.

Dans l’écosystème PrestaShop, la stabilité est la clé. Une erreur de type sur un prix, et c’est le panier moyen qui s’effondre ou une commande qui passe à 0€. C’est pour cela que nous avons, collectivement, durci nos codes. Nous voulons de la prédictibilité. Si une fonction attend un float, elle doit rejeter une string. C’est sain. C’est propre.

Mais le LLM s’en moque.

Quand vous branchez un agent IA (via n8n, Make ou un module custom) pour automatiser la création de fiches produits, vous ne dialoguez pas avec une base de données structurée. Vous dialoguez avec un modèle de langage.

Si vous demandez à l’IA un poids pour l’expédition, elle peut vous répondre :

0.5 (Parfait) “0.5” (String, ça passe) “0,5 kg” (Aïe) “environ 500 grammes” (Catastrophe)

Le problème : Si votre code est une forteresse rigide qui lève une TypeError à la moindre virgule de travers, votre automatisation échoue.

Pour le développeur, l’exception est une sécurité. Pour le marchand PrestaShop, l’exception est une perte de productivité.

Le marchand se fiche que votre DTO soit pur. Il veut que ses 10 000 descriptions produits soient générées et importées pendant qu’il dort. Si l’IA envoie “10 euros” au lieu de 10.0, il ne veut pas que le script plante. Il veut que le système “comprenne”.

🤝 Partie 2 : Le Retour du “PHP Diplomate”

C’est là que ma théorie du PHP Diplomate entre en jeu. Et c’est là qu’on doit nuancer nos “bonnes pratiques”.

PHP possède une super-pouvoir historique que d’autres langages stricts nous envient secrètement : la Type Coercion (la coercition de type). Cette capacité à dire : “Ok, tu m’as donné la chaîne de caractères ‘15.5’, je vais faire l’effort de la traiter comme le nombre 15.5 pour que le calcul se fasse.”

Pendant 10 ans, on nous a appris à détester cette fonctionnalité car elle cachait des bugs. Mais dans un monde piloté par l’IA, elle devient un atout d’ingestion.

Il ne s’agit pas de régresser, mais d’amortir.

Je ne dis pas qu’il faut supprimer les types stricts de nos Cœurs de Domaine (Core Domain). Surtout pas ! Nos calculs de taxes, nos gestions de stocks dans PrestaShop doivent rester d’une rigueur absolue.

Par contre, nous devons construire une nouvelle couche, un “Sas de Décompression”.

Imaginez votre application comme un château fort :

La Salle du Trône (Le Core) : Ici, tout est strict. On parle en Value Objects, en types forts. On ne plaisante pas avec la donnée.

Le Pont-Levis (L’Input Layer / L’IA) : C’est là que l’IA arrive avec ses bottes pleines de boue. Si on garde le pont-levis fermé (Strict Types), rien ne rentre.

La solution n’est pas d’ouvrir le pont-levis et de laisser la boue entrer dans la salle du trône (ce que craignait Francescu). La solution est de créer un sas où l’on utilise la souplesse de PHP pour nettoyer les bottes avant d’entrer.

🔧 Partie 3 : Application Concrète (Le “Fuzzy DTO”)

Comment cela se traduit-il dans le code d’un module PrestaShop moderne ?

Au lieu de faire entrer la donnée de l’IA directement dans un ProductPriceVO strict, nous allons passer par un intermédiaire que j’appelle le Fuzzy DTO (Data Transfer Object “Flou”).

Le scénario classique qui échoue

L’IA génère un JSON pour un produit.

{
  "price": "19,90 €",
  "stock": "in stock (50)"
}

Si vous mappez ça directement dans PrestaShop avec du typage strict… Fatal Error. Le marchand vous appelle, furieux.

L’approche “Orchestrateur”

Nous allons utiliser la souplesse de PHP à l’entrée pour “masser” la donnée.

// Ce n'est pas du "sale code", c'est de la "résilience par design"

class AiProductInput {
    // On accepte délibérément du 'mixed' ou du 'string' car l'IA est imprévisible
    public function __construct(
        public string|int|float $rawPrice,
        public mixed $rawStock
    ) {}

    // La méthode de "Diplomatie" qui transforme le chaos en ordre
    public function toStrictDTO(): ProductDTO {
        // PHP nous aide à nettoyer sans crasher immédiatement
        $sanitizedPrice = (float) str_replace([',', ' €', ' EUR'], ['.', '', ''], $this->rawPrice);

        $sanitizedStock = (int) filter_var($this->rawStock, FILTER_SANITIZE_NUMBER_INT);

        // MAINTENANT, on peut instancier notre objet strict en toute sécurité
        return new ProductDTO($sanitizedPrice, $sanitizedStock);
    }
}

Voyez la nuance ?

On ne sacrifie pas la qualité du modèle final (ProductDTO restera strict). Mais on accepte que l’interface d’entrée (le point de contact avec l’IA) doit être tolérante.

C’est ça, répondre au besoin du marchand. C’est créer un système qui ne plante pas à la première hallucination mineure de ChatGPT, mais qui la corrige silencieusement pour que le business continue de tourner.

🚀 Partie 4 : Vision & Avenir (De Développeur à Architecte de Flux)

Cette discussion dépasse largement le cadre du declare(strict_types=1). Elle touche à l’évolution même de notre métier.

L’automatisation et l’IA générative (GenAI) sont en train de transformer le développeur PrestaShop. Nous ne sommes plus seulement des pisseurs de code qui validons des formulaires. Nous devenons des Orchestrateurs de Flux.

Le développeur de demain (et d’aujourd’hui, en fait) est celui qui sait marier :

La robustesse technique (pour que la boutique ne casse pas). L’agilité opérationnelle (pour que l’IA puisse travailler).

Il va falloir apprendre à “lâcher prise” sur certaines dogmes aux frontières de nos applications. Accepter que la donnée entrante soit sale, et construire les machines à laver (les parsers intelligents) les plus robustes possibles.

L’IA ne va pas remplacer le besoin de rigueur. Au contraire, elle rend la rigueur encore plus précieuse, mais elle la déplace. La rigueur ne doit plus être une barrière à l’entrée (“Tu n’as pas le bon format, tu ne rentres pas”), mais un processus de transformation (“Tu n’as pas le bon format, je vais t’aider à le devenir”).

C’est là toute la différence entre un système fragile et un système antifragile.

🎯 Conclusion

Alors, mon confrère a-t-il raison ? Absolument. On ne jette pas 10 ans de sécurité à la poubelle.

Ai-je raison de prôner le “Loose Typing” ? Oui, mais seulement à des endroits stratégiques : aux frontières.

Pour nos marchands PrestaShop, l’objectif est clair : l’efficacité. Ils ont besoin de modules et d’automatisations qui encaissent les chocs, qui pardonnent les erreurs de l’IA et qui délivrent du résultat.

Notre job, c’est de faire en sorte que cette magie opère sans jamais compromettre l’intégrité de la base de données. C’est un nouvel équilibre à trouver. Un équilibre entre le gardien du temple (le code strict) et le diplomate (l’interface IA).

Et vous, dans vos modules, vous êtes plutôt Forteresse imprenable ou Sas de décompression ? Venez on en parle en commentaire, le débat est loin d’être clos ! 👇

Ressources liées

Questions Fréquentes

Faut-il abandonner le typage strict de PHP avec l'arrivée de l'IA ?

Non, il ne faut pas abandonner le typage strict dans le cœur de votre application. L’approche recommandée est de créer une couche intermédiaire (Fuzzy DTO) qui accepte des données flexibles en entrée et les transforme en objets strictement typés pour le reste de l’application. Ainsi, vous conservez la rigueur là où elle compte tout en permettant à l’IA de fonctionner sans plantages constants.

Qu'est-ce qu'un Fuzzy DTO ?

Un Fuzzy DTO (Data Transfer Object “Flou”) est une couche d’entrée qui accepte des types mixtes ou flexibles (mixed, string int float) depuis l’IA, puis les transforme en objets strictement typés pour votre domaine métier. C’est un “sas de décompression” qui nettoie et valide les données avant qu’elles n’entrent dans le cœur de votre application.

Comment gérer les données imprévisibles des LLM dans PrestaShop ?

Créez une couche d’orchestration qui utilise la Type Coercion de PHP pour transformer les données floues (comme “19,90 €” ou “in stock (50)”) en types stricts avant de les injecter dans PrestaShop. Utilisez des fonctions comme filter_var(), str_replace(), et les castings PHP pour nettoyer les données sans faire planter votre application.

Le Loose Typing de PHP est-il un avantage avec l'IA ?

Oui, mais uniquement aux frontières de votre application. La capacité de PHP à faire de la coercition de type (transformer “15.5” en 15.5 automatiquement) devient un atout pour absorber les variations des réponses d’IA. Cependant, cette flexibilité doit rester confinée à la couche d’ingestion des données, pas dans votre logique métier critique.

Comment orchestrer des agents IA avec PrestaShop ?

Utilisez des outils comme n8n ou Make pour créer des workflows d’automatisation qui connectent les LLM (ChatGPT, Claude) à PrestaShop. Implémentez des Fuzzy DTO pour transformer les réponses IA en données compatibles avec vos modules PrestaShop. Assurez-vous d’avoir une validation robuste et des logs pour tracer les erreurs de transformation.

PrestaShop est-il gratuit ?

Oui, PrestaShop est un CMS e-commerce open-source et gratuit. Vous payez uniquement l’hébergement et les modules premium.