Dans chaque langage, il existe un écart entre ce qui est correct aujourd'hui et ce qui a été le plus documenté. Pour PHP, cet écart est inhabituellement large, car le langage a profondément évolué entre les versions 5.x et 8.x, alors qu'Internet a conservé tous les tutoriels publiés entre-temps.
La conséquence pour le développement assisté par IA est précise et prévisible : le PHP généré reproduit les pratiques de l'époque la plus documentée, qui n'est pas celle dans laquelle vous travaillez. Le code paraît conventionnel — c'est précisément le problème — et il véhicule parfois des hypothèses qui ne sont plus sûres depuis plusieurs versions majeures.
Il ne s'agit pas de déconseiller ces outils, mais de savoir ce qu'il faut surveiller — et, pour PHP, la liste est courte et stable.
Pourquoi PHP en particulier
Trois facteurs se cumulent.
- Le volume d'ancien contenu est immense. PHP a été le langage web par défaut pendant plus de dix ans, période durant laquelle une quantité considérable de tutoriels, réponses de forums et articles ont été publiés — rarement mis à jour.
- Le langage a plus changé que la plupart. Types scalaires, types de retour, énumérations, propriétés readonly, promotion des constructeurs, callables de première classe et un modèle d'erreur bien plus strict sont arrivés après la majorité de cette documentation.
- L'ancien code fonctionne toujours. Contrairement à d'autres langages où une version majeure a forcé l'écosystème à avancer, une grande partie du code PHP 5 fonctionne encore aujourd'hui, ce qui maintient les anciens schémas dans la documentation actuelle comme dans l'historique.
Le résultat : une prépondérance de schémas syntaxiquement valides, immédiatement exécutables, mais qui ne correspondent plus à la façon d'écrire du PHP aujourd'hui.
Schémas à surveiller
1. Requêtes construites par concaténation de chaînes
Le point le plus critique. Pendant dix ans, les tutoriels montraient l'accès à la base de données en concaténant des variables dans une chaîne de requête, et ce schéma est très représenté. Le code généré utilisera souvent un générateur de requêtes correctement, puis repassera à l'interpolation brute pour le cas où le générateur est moins pratique — un ORDER BY dynamique, une liste de colonnes calculée, une clause IN.
Cela fonctionne, passe les tests, mais ouvre une faille d'injection. Toute requête brute dans du code généré doit être revue comme si elle venait d'un inconnu — c'est effectivement le cas.
2. Comparaisons lâches et conversions de type implicites
PHP 8 a corrigé le pire des comparaisons chaîne/entier, mais le code généré continue d'utiliser == là où === est requis, notamment dans les contrôles d'authentification et d'autorisation, où l'enjeu est maximal. L'ancien contenu utilisait la comparaison lâche parce que cela fonctionnait la plupart du temps.
3. Échappement manuel au lieu des outils du framework
Échappement manuel, gestion des en-têtes à la main, fonctions de nettoyage sur mesure : nécessaires avant les frameworks, ces pratiques contournent aujourd'hui les protections natives. Un code généré qui échappe lui-même la sortie, alors que le moteur de templates le fait déjà, signale un recours à une pratique dépassée.
4. Cryptographie et gestion des mots de passe obsolètes
Tout ce qui touche au hachage, aux jetons ou à l'aléatoire mérite une attention particulière. Les anciens tutoriels montrent des méthodes qui étaient recommandées à l'époque et sont aujourd'hui à proscrire. PHP moderne propose des outils fiables et simples ; le code généré ne les utilise pas systématiquement.
5. Accès non validé aux superglobales
Lire directement les données de la requête et les utiliser sans validation, alors que le framework propose une couche de validation, est le schéma qui trahit le plus sûrement une génération issue de contenus pré-framework.
6. Signatures non typées
Ce n'est pas une faille, mais une érosion progressive : le code généré omet fréquemment les types de paramètres et de retour, ce qui retire à l'analyse statique des contrôles utiles. Sur quelques centaines de fonctions générées, la couverture typée du projet diminue, sans qu'aucun changement isolé ne semble problématique.
Pourquoi cela échappe à la revue
Le problème n'est pas que le code paraît suspect. C'est qu'il paraît ordinaire.
- Il est stylistiquement cohérent. Le code généré est conventionnel par construction, ce qui rend les anomalies difficiles à repérer lors d'une revue.
- Il fonctionne. Le comportement est correct pour les entrées testées par le développeur.
- Le relecteur examine un diff, pas une conception. Un risque d'injection dans une méthode de quinze lignes ressemble à quinze lignes banales.
- Le volume dépasse l'attention. Plus de code est produit par heure de revue qu'auparavant, et la qualité de la relecture baisse logiquement avec la quantité.
Le risque s'aggrave sur les anciens projets, là où l'IA est le plus sollicitée parce que le code est mal connu. Le modèle génère un code de style « legacy » qui s'intègre parfaitement, et rien ne semble anormal.
Comment s'en prémunir
Presque tout cela est détectable automatiquement, donc la défense doit être automatisée, pas laissée à la vigilance humaine.
- Analyse statique avancée, blocage en CI. PHPStan ou Psalm détectent l'absence de types, les hypothèses risquées et une grande partie des comparaisons lâches avant toute revue humaine.
- Un jeu de règles orienté sécurité ou taint-analysis, conçu pour repérer les requêtes construites par concaténation de chaînes.
- declare(strict_types=1) partout, pour que les erreurs de typage échouent bruyamment, pas silencieusement.
- Analyse des dépendances et des vulnérabilités en CI, car le code généré peut proposer un paquet abandonné ou une version vulnérable.
- Une courte checklist de revue pour le code généré : requêtes brutes, comparaisons dans les chemins d'authentification, tout ce qui est cryptographique, toute lecture directe des données de requête.
- Un second relecteur pour les modifications touchant à la frontière de sécurité, quel que soit l'auteur, humain ou automatisé.
Et la solution structurelle, qui profite à tout le reste : mettre la base de code à jour. Une version récente de PHP avec des types stricts, un framework maintenu et une couverture élevée d'analyse statique réduit considérablement le risque de code plausible mais erroné, car la plupart des anciens usages ne compilent plus, échouent à l'analyse ou produisent des erreurs évidentes.
C'est le même raisonnement que nous appliquons à la lisibilité du code dans notre politique de revue Laravel assistée par IA, et c'est aussi pourquoi la question de la version dans PHP est-il toujours le bon choix compte davantage que celle du langage.
La position de la gouvernance
Pour un CTO ou VP Engineering qui doit pouvoir justifier sa position sur ce sujet :
- Ne l'interdisez pas. Les équipes utilisent ces outils de toute façon, et une interdiction remplace une pratique contrôlable par une pratique cachée.
- Exigez la transparence, afin que les relecteurs sachent quels changements nécessitent une vérification approfondie.
- Automatisez tout ce qui peut l'être. Chaque règle transférée d'un document de politique à un job CI ne dépend plus de l'attention humaine.
- Gardez des humains sur la frontière de sécurité. Authentification, autorisation, paiements, données personnelles.
- Investissez dans la modernisation. Le moyen le plus efficace de limiter le mauvais code généré est une base de code où ce code ne passe pas la chaîne d'outils.
C'est ce que nous faisons via notre activité de développement PHP et notre modernisation PHP sur mesure. Cela rejoint la question plus large de la place réelle de l'IA dans la livraison — notre activité d'intégration IA et équipe d'ingénierie IA couvrent cet aspect.
Questions fréquentes
Le code PHP généré par l’IA comporte-t-il des failles de sécurité ?
Oui, et ces failles sont prévisibles : requêtes construites par concaténation de chaînes, comparaisons lâches dans les chemins d’authentification, conseils cryptographiques obsolètes, et absence de validation des données reçues. Toutes proviennent d’une même cause : une décennie de documentation antérieure aux mécanismes de sécurité modernes de PHP.
Pourquoi la situation est-elle plus problématique en PHP que dans d’autres langages ?
Parce que PHP a évolué plus que la plupart des autres langages entre les versions 5.x et 8.x, tout en conservant un volume considérable de documentation jamais mise à jour. Beaucoup de code écrit à l’époque de PHP 5 est encore en production. La majorité du contenu disponible est donc ancien, plus que dans les écosystèmes plus récents.
Comment détecter ces failles lors de la revue de code ?
Ne vous fiez pas uniquement à la revue : le code paraît ordinaire, ce qui fait que les anomalies échappent à l’œil du relecteur. Imposer des types stricts et un niveau élevé d’analyse statique en CI, ajouter un jeu de règles de sécurité pour détecter les requêtes construites par chaînes, et tenir une liste courte des quelques schémas à surveiller.
Faut-il arrêter d’utiliser les outils d’IA sur du PHP hérité ?
Non, mais considérez ces bases de code comme plus risquées. Le code généré qui s’aligne sur le style hérité est le plus difficile à repérer ; c’est la modernisation — version à jour, types stricts, analyse statique — qui rend l’IA utile et sûre, pas seulement rapide.
Cela concerne-t-il aussi les frameworks comme Laravel et Symfony ?
Moins fortement, car les conventions de ces frameworks sont solides et bien documentées, mais le même problème se manifeste sous forme d’idiomes issus d’anciennes versions : helpers obsolètes, syntaxe de validation dépassée, schémas remplacés par des fonctionnalités natives. La solution reste la même : imposez-la dans la chaîne d’outillage.
Automatiser avec la chaîne d’outils
Nous mettons en place l'analyse statique, les règles de sécurité et les contrôles CI qui font échouer automatiquement ce type de problème, sans dépendre de la vigilance d'un relecteur. Contactez notre équipe ; nous répondons sous un jour ouvré.