Comment nous détectons une fuite mémoire PHP avant qu'elle ne fasse tomber un site

Une fuite mémoire dans un worker PHP-FPM, c’est le genre d’incident qui ne réveille personne — jusqu’à ce qu’il s’aggrave. Le site fonctionne. Les temps de réponse sont corrects. Puis, trois jours plus tard, l’OOM killer se déclenche au pire moment, et le client agence reçoit un appel le dimanche matin.

Cet article décrit comment nous attrapons ces dérives avant qu’elles ne deviennent des incidents.

Le signal que personne ne regarde

La plupart des stacks de supervision graphent deux choses sur PHP-FPM : le nombre de processus actifs, et le temps de traitement moyen. C’est utile, mais insuffisant.

Ce qui fuit dans un PHP-FPM mal configuré ou dans un plugin WordPress mal écrit, ce n’est pas le CPU. C’est la mémoire résidente (RSS) accumulée par chaque worker entre deux requêtes, quand la directive pm.max_requests est trop élevée ou absente.

Le graphique de la mémoire résidente moyenne des workers PHP-FPM, sur un pool sain, ressemble à une ligne horizontale avec un léger bruit. Sur un pool qui fuit, c’est une rampe lente et régulière.

Ce que Prometheus nous remonte

Nous exposons pour chaque cluster un exporter maison qui publie :

phpfpm_worker_rss_bytes{pool="client42",worker="0"} 128401408
phpfpm_worker_rss_bytes{pool="client42",worker="1"} 131072000
phpfpm_worker_requests_total{pool="client42"} 1842319

Une règle d’alerte Prometheus détecte une pente positive sur la moyenne RSS d’un pool :

- alert: PhpFpmMemoryDrift
  expr: |
    deriv(avg_over_time(phpfpm_worker_rss_bytes[1h])[6h:5m]) > 100000
  for: 2h
  labels:
    severity: warning
  annotations:
    summary: "Dérive mémoire PHP-FPM sur {{ $labels.pool }}"

En clair : si la moyenne mobile sur une heure dérive positivement de plus de 100 Ko/s pendant deux heures d’affilée, on déclenche un warning. Ça donne plusieurs heures d’avance sur l’OOM, parfois une journée entière.

Où l’agent IA intervient

L’alerte Prometheus dit qu’il y a une fuite. Elle ne dit pas pourquoi. C’est là que notre agent IA prend le relais.

À réception de l’alerte, l’agent déclenche une procédure d’analyse :

1. Il récupère la liste des plugins installés sur le site (WordPress, Drupal ou Symfony selon le cas) et leurs versions exactes.
2. Il interroge sa base interne de CVE et de comportements connus.
3. Il compare la version installée avec la dernière version stable du plugin.
4. Il produit un rapport court adressé à l’agence cliente — jamais au client final.

Exemple de rapport réel (anonymisé) :

Pool client-XX présente une dérive RSS de +180 Ko/s depuis 4h.

Suspects identifiés par ordre de probabilité :

• Plugin woocommerce-custom-product-addons v4.2.1 — bug connu sur la gestion du panier en session, fixé en v4.3.0.
• Extension Imagick v3.6.0 — fuite documentée sur clone() en PHP 8.2, contournement par destroy() explicite.

Recommandation priorisée : mise à jour du plugin en v4.3.0 sur environnement de staging, puis en production. Procédure détaillée en annexe.

L’agent ne touche jamais au code ni aux dépendances sans validation humaine. Il documente, il priorise, il propose. L’agence décide.

Ce que ça change concrètement

Sans cette chaîne, voici le scénario classique :

• J+0 : la fuite commence, invisible.
• J+3 : le serveur sature, le site ralentit.
• J+3 au soir : le client final appelle l’agence en panique.
• J+3 nuit : intervention en urgence, diagnostic long, redémarrage brutal.

Avec la chaîne exporter → Prometheus → alerte → agent IA :

• J+0 matin : la fuite commence.
• J+0 après-midi : alerte warning reçue par l’équipe Reagency.
• J+0 fin de journée : rapport d’agent envoyé à l’agence cliente avec la cause probable et la procédure.
• J+1 matin : l’agence planifie la mise à jour, tout passe en staging, puis en prod.
• Pas d’incident. Pas d’appel nocturne. Pas de facture surprise.

C’est ce genre de quotidien — pas les grandes promesses — qui justifie l’audit IA en continu. Une fuite mémoire détectée à temps, c’est une heure de lecture de rapport contre une nuit de crise.

Ce qu’on ne fait pas (encore)

Soyons honnêtes sur les limites actuelles :

• L’agent ne corrèle pas encore automatiquement avec les logs d’erreur PHP. Il les lit sur demande explicite.
• Il n’attribue pas de causalité certaine — il propose des suspects probables.
• Il ne patche rien. Jamais.

Ces trois points sont sur notre feuille de route produit. Nous préférons avancer lentement et sans fausse promesse plutôt que vendre un agent « magique ».

---

Si votre agence gère un portefeuille de sites PHP et que ce genre d’incident vous coûte des nuits, parlons-en. Un audit IA d’un site est offert aux agences qui nous consultent pour la première fois.