« Ça marche en prod » : ce que c’est, pourquoi cela arrive et en quoi c’est dangereux

Que signifie l’expression « ça marche en prod »

« Ça marche en prod » — c’est une expression bien établie dans le milieu des développeurs, désignant une situation où le code fonctionne sur le serveur de production mais refuse de fonctionner dans l’environnement de test ou sur la machine locale d’un collègue. Extérieurement, cela sonne comme « pas de problème » alors qu’en réalité le problème existe — il ne se reproduit tout simplement pas dans l’environnement de production. La racine de la divergence réside dans la différence de configurations, de versions et de données entre les environnements.

L’expression est née comme l’antithèse d’une autre excuse bien connue — « Ça marche chez moi en local ». Si un développeur dit « ça marche en local », le bug n’existe que chez les autres. Et si « ça marche en prod » — le bug n’existe que sur la staging ou l’environnement de test, mais la production est saine. Ironie du sort : dans les deux cas, le problème est réel, il se manifeste simplement chez quelqu’un d’autre. Selon l’étude DevOps Research and Assessment (DORA) 2023, les équipes ayant un haut niveau d’automatisation du déploiement rencontrent ces divergences 3 fois moins souvent.

Du point de vue commercial, la situation « ça marche en prod » est plus dangereuse qu’il n’y paraît. Si un bug est présent sur la staging mais pas en prod, le développeur peut l’ignorer — et lors du prochain déploiement, l’erreur passera en production. Un soulagement temporaire se transforme en un problème futur qu’il faudra corriger sous la pression des utilisateurs.

Pourquoi les développeurs disent « ça marche en prod »

La raison psychologique de la persistance de cette expression — le réflexe de défense. Un développeur qui voit un bug sur la staging mais pas en prod peut inconsciemment minimiser le problème : « puisque tout va bien en production, ce n’est pas urgent ». Un biais cognitif classique — l’erreur du survivant, où le succès visible de la production l’emporte sur la menace potentielle d’une future panne.

La deuxième raison — la responsabilité diluée. Si la production fonctionne mais pas la staging, l’environnement est en faute, pas le code. Le développeur se décharge de la responsabilité du bug en la transférant à l’ingénieur DevOps ou à l’administrateur. Selon l’Atlassian State of DevOps 2022, dans les équipes sans environnement de déploiement unifié (Docker, Kubernetes), ces transferts de responsabilité se produisent 60 % plus souvent.

La troisième raison — la peur d’une release sans temps d’arrêt. Si un développeur corrige le bug sur la staging et déploie la correction, cela nécessite une nouvelle relecture de code, des tests et un déploiement. L’expression « ça marche en prod » permet de reporter la correction à la prochaine version, réduisant la charge actuelle. Une correction différée — l’une des principales causes d’accumulation de dette technique dans les équipes.

Différence entre les environnements de développement et de production

La production et la staging ne sont jamais totalement identiques — c’est techniquement impossible en raison des différences d’échelle, de charge et de données. Cependant, les paramètres clés doivent coïncider : version du système d’exploitation, compilateur, interpréteur, base de données, serveur web et toutes les dépendances du projet. Si au moins un paramètre diffère — le comportement du code peut changer.

Les principales différences entre les environnements incluent :

• Matériel — processeur, quantité de RAM, type de disque (SSD vs HDD) peuvent influencer les temps d’exécution et le fonctionnement du multithreading
• Environnement réseau — firewall, DNS, proxy, répartiteurs de charge ne sont présents qu’en prod
• Données dans la BDD — la staging contient généralement des données de test, tandis que les enregistrements utilisateurs réels ont des schémas inattendus
• Versions des dépendances — même une mise à jour mineure d’une bibliothèque peut modifier le comportement du code
• Variables d’environnement — clés API, jetons, indicateurs de fonctionnalités peuvent différer entre les environnements

La conteneurisation résout la plupart de ces problèmes. L’image Docker construite pour la production doit être utilisée également sur la staging. La seule différence — les variables d’environnement et les montages de volumes. Selon le Docker State of Application Development 2023, les équipes utilisant une image unifiée pour tous les environnements réduisent le nombre de divergences de 74 %.

Causes typiques des écarts de comportement en prod

La première cause, la plus fréquente — différentes versions des dépendances. Le développeur installe un paquet localement avec le flag --save mais oublie de mettre à jour le package.json ou le lock-file. Lors du déploiement en prod, une version différente est installée qui se comporte autrement. Pour l’écosystème npm, le lock-file résout complètement le problème, pour les autres gestionnaires de paquets — des mécanismes similaires (Gemfile.lock, Podfile.lock, pubspec.lock).

La deuxième cause — variables d’environnement manquantes ou superflues. Le développeur utilise un fichier .env sur sa machine locale mais n’ajoute pas les variables correspondantes dans le pipeline CI/CD ou sur le serveur. Résultat — le code échoue avec une erreur de connexion à l’API ou à la base de données. Selon le GitLab DevSecOps Survey 2023, 27 % des incidents en prod sont liés à des variables d’environnement incorrectes.

La troisième cause — l’état de la base de données. Sur la staging, la BDD peut contenir des enregistrements absents en prod, ou inversement — des migrations manquantes. Scénario typique : le développeur écrit du code qui utilise un nouveau champ dans une table, mais la migration n’a pas encore été appliquée en prod. Une stratégie de migration avec rétrocompatibilité — le seul moyen d’éviter de telles situations.

La quatrième cause — paramètres régionaux et linguistiques. Le formatage des dates, les séparateurs décimaux, l’encodage du texte — tout cela peut différer sur la machine locale du développeur et le serveur. Particulièrement pertinent pour les projets avec internationalisation. Solution — spécifier explicitement la locale dans la configuration de l’application et ne pas se fier aux paramètres système.

Comment diagnostiquer le problème « ça marche en prod »

Première étape — comparer les logs des deux environnements. La différence dans le niveau de journalisation cache souvent la cause : en prod, le niveau INFO peut être activé, et sur la staging, DEBUG. Configurez le même niveau de journalisation et assurez-vous que les deux environnements écrivent dans un format permettant une comparaison automatisée. Utilisez des systèmes centralisés de collecte de logs — Sentry, Datadog, ELK Stack.

Deuxième étape — vérifier les versions des dépendances. Comparez les lock-files, affichez la liste des paquets installés sur les deux environnements. Une différence de version mineure ou de correctif — la cause la plus probable de divergence. Des outils comme npm ls, pip freeze, mvn dependency:tree aideront à identifier rapidement les incohérences.

Troisième étape — reproduire l’environnement de production localement. Utilisez Docker Compose ou des outils similaires pour monter une copie exacte de l’infrastructure de production. Si le bug se reproduit dans un conteneur local — le problème vient du code, pas de l’environnement. S’il ne se reproduit pas — cherchez une différence dans la configuration.

Quatrième étape — vérifier les feature flags et les tests A/B. Il est possible qu’en prod le code fonctionne dans un mode différent parce qu’un mauvais flag est activé. Selon le LaunchDarkly State of Feature Management 2023, jusqu’à 40 % des comportements inattendus en prod sont liés à des valeurs incorrectes de feature flags. Un manifeste unifié des flags pour tous les environnements résout ce problème.

Prévention des divergences d’environnements dans le projet

L’outil principal de prévention — Infrastructure as Code (IaC). Tous les environnements doivent être décrits dans le code : Dockerfile, docker-compose.yml, scripts Terraform ou playbooks Ansible. Les modifications manuelles sur le serveur sont interdites — tout changement de configuration passe par le dépôt et la relecture de code. Cela garantit que tous les environnements ont la même configuration.

Le deuxième outil par ordre d’importance — un pipeline CI/CD unifié. Le même script de construction, de test et de déploiement doit être utilisé pour tous les environnements. La différence — uniquement dans les variables cibles (URL, clés). Si le pipeline pour la staging et la production diffère dans ses étapes — les divergences sont inévitables.

Le troisième outil — la synchronisation automatique des données. Régulièrement (une fois par jour ou selon un calendrier), mettez à jour la staging avec une copie anonymisée de la base de production. Cela permet de tester le code sur des données réelles plutôt que sur des fixtures synthétiques. Outils : pg_dump/pg_restore pour PostgreSQL, mysqldump pour MySQL, des services spécialisés comme DataGrip.

Le quatrième — la surveillance des divergences. Configurez des alertes lors de la détection de différences entre la staging et la production. Un simple script comparant les hachages des fichiers de configuration ou les versions des paquets installés fera gagner des heures de débogage. La prévention est toujours moins coûteuse que le diagnostic : prévenir la divergence des environnements demande moins d’efforts que de rechercher la cause d’un bug « ça marche en prod ».