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.
<span class="p">{</span><span class="w">
</span><span class="nl">"price"</span><span class="p">:</span><span class="w"> </span><span class="s2">"19,90 €"</span><span class="p">,</span><span class="w">
</span><span class="nl">"stock"</span><span class="p">:</span><span class="w"> </span><span class="s2">"in stock (50)"</span><span class="w">
</span><span class="p">}</span><span class="w">
</span>
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.
<span class="c1">// Ce n'est pas du "sale code", c'est de la "résilience par design"</span>
<span class="kd">class</span> <span class="nc">AiProductInput</span> <span class="p">{</span>
<span class="c1">// On accepte délibérément du 'mixed' ou du 'string' car l'IA est imprévisible</span>
<span class="k">public</span> <span class="k">function</span> <span class="n">__construct</span><span class="p">(</span>
<span class="k">public</span> <span class="kt">string</span><span class="o">|</span><span class="n">int</span><span class="o">|</span><span class="n">float</span> <span class="nv">$rawPrice</span><span class="p">,</span>
<span class="k">public</span> <span class="kt">mixed</span> <span class="nv">$rawStock</span>
<span class="p">)</span> <span class="p">{}</span>
<span class="c1">// La méthode de "Diplomatie" qui transforme le chaos en ordre</span>
<span class="k">public</span> <span class="k">function</span> <span class="n">toStrictDTO</span><span class="p">():</span> <span class="kt">ProductDTO</span> <span class="p">{</span>
<span class="c1">// PHP nous aide à nettoyer sans crasher immédiatement</span>
<span class="nv">$sanitizedPrice</span> <span class="o">=</span> <span class="p">(</span><span class="n">float</span><span class="p">)</span> <span class="nb">str_replace</span><span class="p">([</span><span class="s1">','</span><span class="p">,</span> <span class="s1">' €'</span><span class="p">,</span> <span class="s1">' EUR'</span><span class="p">],</span> <span class="p">[</span><span class="s1">'.'</span><span class="p">,</span> <span class="s1">''</span><span class="p">,</span> <span class="s1">''</span><span class="p">],</span> <span class="nv">$this</span><span class="o">-></span><span class="n">rawPrice</span><span class="p">);</span>
<span class="nv">$sanitizedStock</span> <span class="o">=</span> <span class="p">(</span><span class="n">int</span><span class="p">)</span> <span class="nb">filter_var</span><span class="p">(</span><span class="nv">$this</span><span class="o">-></span><span class="n">rawStock</span><span class="p">,</span> <span class="no">FILTER_SANITIZE_NUMBER_INT</span><span class="p">);</span>
<span class="c1">// MAINTENANT, on peut instancier notre objet strict en toute sécurité</span>
<span class="k">return</span> <span class="k">new</span> <span class="nc">ProductDTO</span><span class="p">(</span><span class="nv">$sanitizedPrice</span><span class="p">,</span> <span class="nv">$sanitizedStock</span><span class="p">);</span>
<span class="p">}</span>
<span class="p">}</span>
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 ! 👇