Le 14 mars 2023 à 9h12, la mise en ligne d’une refonte de catalogue produit pour une fromagerie en vente directe a été déclenchée juste après une recette client validée sans réserve la veille au soir. À 9h19, les premières pages produit renvoyaient une erreur 500, sans qu’aucun test de recette n’ait laissé présager quoi que ce soit d’anormal.
L’incident a duré 47 minutes avant qu’une cause précise soit identifiée : une limite de mémoire PHP différente entre l’environnement de recette et l’environnement de production, invisible tant qu’aucune page ne dépassait ce seuil pendant les tests.
Ce que la recette avait validé
La checklist de recette portait sur les parcours fonctionnels : affichage du catalogue, filtres par catégorie, fiche produit, ajout au panier. Chaque page testée manuellement avait répondu correctement, avec des données de test représentatives d’une trentaine de produits. Rien dans le protocole de recette ne prévoyait de tester le comportement avec le volume réel de plus de 400 références du catalogue final, chargé seulement au moment de la bascule en production.
Ce qui a cassé, et pourquoi la recette ne l’a pas vu
La nouvelle page catalogue chargeait l’ensemble des produits d’une catégorie pour calculer côté PHP des filtres dynamiques (allergènes, mode d’affinage, région). Avec une trentaine de produits en recette, ce calcul restait largement sous la limite de mémoire configurée. Avec les 400 références réelles de production, la consommation mémoire dépassait la limite memory_limit définie côté serveur :
PHP Fatal error: Allowed memory size of 134217728 bytes exhausted
(tried to allocate 20480 bytes) in class-catalogue-filtres.php on line 88
L’environnement de recette avait été provisionné avec une configuration memory_limit de 256 Mo, héritée d’un ancien projet sur le même serveur mutualisé de préproduction. L’environnement de production, lui, respectait la configuration standard de l’hébergeur, fixée à 128 Mo. Personne n’avait vérifié que les deux valeurs correspondaient, parce que la recette portait sur le comportement fonctionnel, jamais sur la configuration serveur sous-jacente.
La correction appliquée dans l’urgence
Le correctif immédiat a consisté à paginer le calcul des filtres par lots de 50 produits plutôt que de charger la catégorie entière en mémoire, ce qui a résolu l’incident en production sans dépendre d’une modification de configuration serveur, potentiellement plus longue à obtenir chez l’hébergeur.
Ce qui a changé dans le processus après l’incident
- La configuration
php.inieffective de la recette est désormais comparée à celle de la production avant chaque mise en ligne, via une simple pagephpinfo()protégée par mot de passe sur les deux environnements. - Le jeu de données de recette est importé à partir d’un export anonymisé de la production réelle, plutôt que constitué à la main avec un volume arbitraire.
- Un test de charge minimal sur la page la plus consommatrice en mémoire est ajouté au protocole de recette, avec le volume de données réel du client.
Ce que cet incident ne remet pas en cause
La recette fonctionnelle elle-même n’était pas en cause : les parcours testés fonctionnaient bien tels qu’ils avaient été testés. Le problème n’était pas la qualité de la checklist de recette, mais son périmètre, qui ne couvrait ni le volume de données réel ni la configuration serveur de destination.
Pourquoi l’écart était passé inaperçu pendant des mois
La configuration mémoire de 256 Mo sur l’environnement de recette datait d’un projet antérieur hébergé sur le même serveur mutualisé de préproduction, augmentée à l’époque pour résoudre un tout autre incident, puis jamais réajustée ni documentée. Aucun des projets suivants, dont celui de la fromagerie, n’avait de raison de remettre en question une configuration héritée qui fonctionnait sans erreur visible en recette. C’est justement cette absence d’erreur qui a masqué l’écart : rien ne signalait qu’un seuil différent existait tant que le volume de données restait sous la barre critique.
Une recette valide un comportement dans un environnement donné ; elle ne garantit rien sur un environnement qu’elle n’a jamais observé.
En résumé
L’écart entre recette et production ne se limite pas au code déployé : la configuration serveur, le volume de données et les ressources allouées font partie intégrante de ce qui doit être aligné avant une mise en ligne. Depuis l’ajout de la comparaison de configuration au protocole, aucun incident de ce type n’a été observé sur les dix mises en ligne suivantes de l’agence.
