PHP 4 a été mis en fin de vie en 2008. Pourtant, en 2026, des milliers de serveurs web tournent encore avec du code qui date de cette époque — voire d’avant. Des fonctions dépréciées, des fichiers d’upload sans validation, des eval() balancés là parce que « ça marchait à l’époque ». La dette technique, on la connaît tous. On la mesure en « on verra plus tard », en branches git jamais mergées, et en commits dont le message est juste « fix ».
Ce que change l’IA dans ce tableau, c’est la vitesse à laquelle elle retrouve ces cadavres dans le placard. Des outils de sécurité dopés à des modèles de langage parcourent désormais des codebases entiers en quelques heures et remontent des vulnérabilités que personne n’avait jamais formalisées — pas parce qu’elles étaient invisibles, mais parce qu’aucun humain n’avait la patience de les chercher systématiquement.
Une analyse publiée par IEEE Spectrum illustre ça très concrètement avec les vulnérabilités PHP-to-shell : ces chemins d’attaque qui permettent d’exécuter du code arbitraire côté serveur via du PHP mal sécurisé. Rien de nouveau techniquement. Mais l’IA vient de les cataloguer à une échelle industrielle, et le résultat est inconfortable pour beaucoup d’équipes.
TL;DR — Les outils d’analyse de sécurité basés sur l’IA détectent aujourd’hui des vulnérabilités dans du code legacy vieux de 20 ou 30 ans. Ce n’est pas une surprise technique : c’est un réveil forcé. La dette technique ne disparaît pas, elle attend juste d’être trouvée — et l’IA vient de rendre cette attente beaucoup plus courte.
PHP-to-shell : le cas d’école qui résume 30 ans de mauvaises pratiques
La classe de vulnérabilités PHP-to-shell est aussi ancienne que le web dynamique. Le principe : un attaquant parvient à faire exécuter une commande système via du code PHP insuffisamment sécurisé. Les vecteurs classiques incluent les fonctions exec(), system(), shell_exec() ou passthru() appelées avec des paramètres non sanitisés. Rien que ça, c’est dans les OWASP Top 10 depuis des années.
Voici un exemple qui ne choquait personne en 2003 mais qui fait froid dans le dos aujourd’hui :
Ce bout de code vit encore dans des plugins WordPress abandonnés, des scripts d’administration bricolés à la main, des CMS custom que personne ne touche depuis 2011 « parce que ça tourne ». La requête d’attaque, elle, reste enfantine : GET /script.php?file=../../etc/passwd. On remonte dans l’arborescence, on lit ce qu’on n’est pas censé lire, et dans le pire des cas on écrit ce qu’on veut. L’IA n’a pas inventé cette attaque. Elle a industrialisé sa détection à grande échelle, sur des millions de dépôts publics et privés.
Ce qui est nouveau, c’est l’échelle. Des modèles entraînés sur de grands volumes de code reconnaissent ces patterns à une vitesse qu’aucune équipe de pentesters humains ne peut égaler. Et quand on multiplie cette capacité par l’ensemble du web, le volume de vulnérabilités non corrigées qui remonte à la surface est vertigineux.
Ce que l’IA change vraiment dans les audits de sécurité
Les scanners de sécurité traditionnels — SAST, DAST et leurs équivalents — font ça depuis longtemps. SonarQube remonte des warnings sur shell_exec() depuis des années. La différence avec les outils basés sur des LLMs, c’est leur capacité à comprendre le contexte du code, pas juste à matcher des patterns sur du texte brut.
Un scanner classique repère un pattern dangereux. Un outil IA, lui, peut raisonner sur le flux de données : est-ce que cette variable vient bien d’un input utilisateur ? Est-ce qu’elle passe par une validation quelque part avant d’arriver là ? Est-ce que ce paramètre sanitisé à l’entrée est « recontaminé » plus loin dans le code, dans une autre fonction, dans un autre fichier ? C’est ce raisonnement sémantique sur plusieurs couches qui change la donne.
DÉCOUVREZ NOS RÉALISATIONS
SP Distribution
Logiciel web PWA pour un reseau de pizzerias a Saint-Berthevin (53). Gestion du catalogue, commandes, stocks et facturation.
Voir le projet →Des outils comme CodeQL (GitHub), Snyk Code, ou les nouveaux agents de sécurité autonomes tracent maintenant des chemins d’attaque complets : « ce paramètre GET atteint cette fonction dangereuse via ces 7 fonctions intermédiaires, dont 3 dans des fichiers différents ». Un humain pourrait le faire — mais sur une codebase de 500 000 lignes, il lui faudrait des semaines. L’outil : quelques heures.
⚠️ Le volume de vulnérabilités détectées par ces outils n’explose pas parce qu’il y en a plus qu’avant. Il explose parce qu’on a enfin les outils pour les voir — et pour prouver qu’elles existaient depuis le début. C’est une différence importante du point de vue légal et réglementaire.
La dette technique : un problème économique avant tout
On parle de « 40 ans de dette technique » parce que les premiers systèmes Unix datent des années 80, les premiers scripts CGI des années 90, et PHP lui-même fête ses 30 ans cette année. Cette accumulation n’est pas le résultat d’une incompétence généralisée des développeurs — c’est le résultat de contraintes économiques très concrètes que tout le monde a vécues.
Un bug non exploité n’est pas un bug prioritaire. La dette technique existe parce que les équipes sont sous-staffées, les délais courts, et les audits de sécurité coûteux. « On n’a pas le budget pour ça » est une phrase qu’on entend régulièrement. Et elle est souvent vraie. Le calcul rationnel était : le coût d’un audit dépasse la probabilité perçue d’une attaque réussie.
L’IA ne crée pas de nouvelles vulnérabilités. Elle transforme l’ignorance plausible en négligence documentée.
L’IA retire précisément cet argument du coût. Si un outil peut auditer 100 000 lignes de code en 20 minutes et générer un rapport priorisé, l’excuse « on n’a pas le temps de vérifier » tient de moins en moins. Les RSSI le savent. Les équipes légales commencent à le savoir aussi — et dans un contexte réglementaire de plus en plus exigeant (NIS2, RGPD, DORA), « je ne savais pas » devient un argument difficile à tenir face à des outils de détection gratuits et accessibles.
Le code legacy ne vieillit pas bien, et il ne t’attend pas
La mauvaise nouvelle, c’est que corriger du code PHP legacy de 2003 avec des outils modernes, c’est souvent découvrir que le problème est architectural. On ne peut pas juste « patcher » un eval() si tout le système repose sur du dynamic code loading sans sandboxing. L’audit IA devient alors le déclencheur d’une refonte qu’on repoussait depuis des années — et qui était probablement inévitable depuis le début.
La bonne nouvelle : les meilleurs outils ne font pas que trouver les problèmes. GitHub Copilot Autofix propose des corrections directement dans le repo sous forme de PR. Snyk génère des patches contextuels. Ce n’est pas parfait — tu dois toujours comprendre ce que tu valides, et certaines corrections automatiques introduisent de nouveaux problèmes — mais ça change l’équation du temps de façon significative.
Pour les projets trop chargés en dette pour être patchés proprement, la question devient : est-ce qu’on continue à maintenir ce code sous perfusion, ou est-ce qu’on engage une stratégie de maintenance et de sécurité proactive qui inclut un plan de migration réaliste ? C’est inconfortable à entendre en réunion de direction, mais c’est souvent la seule réponse honnête.
WESTCODE BY LEB
Studio web en Mayenne — On crée des outils numériques qui transforment
Que faire concrètement cette semaine
Pas besoin d’attendre un audit IA complet pour commencer à réduire la surface d’attaque. Quelques actions à fort impact, dans l’ordre du ratio effort/résultat :
- Inventorier les versions PHP en production. PHP 7.x est en fin de support depuis fin 2022. Si tu tournes encore dessus, tu accumules des CVE non patchés sans correctif officiel disponible.
- Activer les checks de sécurité GitHub/GitLab. GitHub Advanced Security est gratuit pour les repos publics. Pour les repos privés, le coût est justifié au regard du risque.
- Chercher les fonctions dangereuses. Un simple
grep -rn "shell_exec\|exec\|system\|passthru\|eval" .te donne un premier état des lieux en 30 secondes sur n’importe quel projet. - Mettre en place une politique de dépendances. Dependabot ou Renovate automatisent les mises à jour de librairies, ce qui couvre une partie importante de la surface d’attaque à coût quasi nul.
Pour les projets neufs ou en cours de refonte, intégrer la sécurité dès la phase de conception est infiniment moins cher que de corriger après coup. Quand on développe une application sur mesure, les checks de sécurité font partie du pipeline CI/CD dès le premier sprint, pas en option après la mise en prod. C’est ce qui évite de se retrouver à corriger des shell_exec() non sanitisés trois ans plus tard.
✅ Un scan SAST automatisé sur chaque pull request coûte zéro en temps développeur et peut bloquer une vulnérabilité avant qu’elle n’atteigne la production. C’est probablement le meilleur ratio effort/impact qui existe en sécurité applicative — et pourtant, moins d’une équipe sur deux l’a mis en place.
On entre dans une période de purge technique, et c’est tant mieux
L’IA en sécurité n’est pas là pour faire peur. Elle est là pour accélérer ce qu’on savait déjà mais qu’on repoussait : ces vulnérabilités ont toujours existé, elles ont juste eu la patience d’attendre qu’on les regarde en face. Pendant 20 ans, le calcul économique penchait du côté de l’évitement. Ce calcul est en train de changer, et assez vite.
Les projets qui ont accumulé de la dette pendant 10 ou 15 ans sans jamais la rembourser vont se retrouver face à des choix difficiles : patcher à la hache, refondre, ou assumer le risque. Et « assumer le risque » va devenir difficile à défendre juridiquement quand les outils qui auraient permis de détecter le problème étaient disponibles gratuitement. Les attaquants utilisent, eux aussi, l’IA pour trouver ces mêmes vulnérabilités — souvent plus vite que les défenseurs. L’asymétrie était déjà là ; elle s’accentue.
La vraie question n’est plus « as-tu des vulnérabilités dans ton code ? » Tout le monde en a. La vraie question, c’est : combien de temps encore tu peux faire semblant de ne pas le savoir ?
