Le lancement devait avoir lieu à 14h. Il est maintenant 16h30 et la nouvelle fonctionnalité n'est toujours pas en ligne. L'équipe tech est en panique mode dans Slack. Vous, designer ou PM, vous observez le chaos sans trop comprendre ce qui bloque.
Voici le problème : vous voulez aider ou au moins comprendre, mais vous ne savez pas quelles questions poser sans passer pour quelqu'un qui ne capte rien. Voici cinq questions qui montrent que vous comprenez le processus — et qui obtiennent des réponses utiles.
🔥 Scénario classique
Votre équipe a développé une nouvelle page de paiement. Les tests locaux fonctionnent. Les tests en staging aussi. Mais au moment de pousser en production, tout explose. Les logs montrent des erreurs cryptiques. Personne ne comprend pourquoi ça marchait il y a cinq minutes et plus maintenant.
Avant même de chercher le problème, vérifiez que le code a bien été déployé. Parfois le pipeline échoue en silence. Le code reste bloqué quelque part entre staging et production.
Pourquoi cette question aide : Elle sépare deux problèmes différents. Soit le déploiement n'a pas eu lieu (problème d'infrastructure), soit il a eu lieu mais le code plante (problème applicatif). Vous ne résolvez pas le même souci dans les deux cas.
Si ça marche en staging mais pas en prod, c'est qu'un élément diffère entre les deux environnements. Une base de données plus grosse. Des variables de configuration différentes. Un service externe qui ne répond pas pareil.
Pourquoi cette question aide : Elle oriente la recherche vers les différences d'environnement plutôt que vers le code lui-même. Souvent, le code n'est pas en cause. C'est le contexte qui change.
Si tout plantait avant et que ça marchait il y a une heure, revenez à cette version. Le rollback rétablit la version stable pendant que l'équipe cherche ce qui a cassé.
Pourquoi cette question aide : Elle rappelle que la priorité est de rétablir le service. Déboguer prend du temps. Les utilisateurs ne peuvent pas attendre. Un rollback ramène la stabilité en quelques minutes.
Les logs enregistrent tout ce qui se passe. Une erreur 500 ne dit rien. Mais un message comme "timeout connection to database" pointe directement vers la base de données.
Pourquoi cette question aide : Elle pousse l'équipe à consulter les logs au lieu de spéculer. Les logs contiennent souvent la réponse. Demander ce qu'ils disent force tout le monde à regarder les faits plutôt que les suppositions.
Un test qui passe en local mais échoue dans le pipeline CI révèle un problème d'environnement. Si tous les tests sont verts et que ça plante quand même, c'est qu'il manque un test.
Pourquoi cette question aide : Elle vérifie si le filet de sécurité a fonctionné. Les tests automatisés sont censés bloquer le code défaillant avant production. S'ils n'ont rien détecté, soit le problème vient d'ailleurs, soit les tests ne couvrent pas ce cas.
Bonus : la question à ne jamais poser
"Pourquoi vous n'avez pas testé avant ?" Cette question n'aide personne. Elle sonne comme un reproche. L'équipe tech sait qu'elle aurait dû tester. Elle cherche à comprendre pourquoi les tests n'ont pas détecté le problème.
Remplacez par : "Comment peut-on éviter ça la prochaine fois ?" Cette formulation oriente vers l'amélioration plutôt que vers le blâme. Elle invite à une discussion constructive sur les processus.
📋 Checklist rapide pour un déploiement qui coince
Ce que ces questions révèlent
En posant ces questions, vous montrez que vous comprenez le flux de déploiement. Vous savez qu'un code passe par plusieurs environnements. Vous comprenez que staging n'est pas production. Vous saisissez que le rollback existe pour une bonne raison.
Ces questions structurent aussi la réflexion de l'équipe. Parfois, les développeurs sont tellement dans le problème qu'ils oublient de vérifier l'évidence. Votre question externe les ramène aux fondamentaux.
À retenir : Un déploiement qui échoue révèle souvent une différence entre environnements plutôt qu'un bug dans le code. Poser les bonnes questions aide l'équipe à identifier rapidement où chercher. Et ça montre que vous comprenez leur processus.
Après l'incident : le post-mortem
Une fois le problème résolu, l'équipe devrait organiser un post-mortem. C'est une réunion où tout le monde analyse ce qui s'est passé, sans blâmer personne. L'objectif : comprendre et améliorer le processus.
En tant que PM ou designer, votre présence à ces réunions est précieuse. Vous apportez une perspective différente. Vous pouvez demander pourquoi certaines décisions ont été prises. Et surtout, vous comprenez mieux comment l'équipe travaille.
La prochaine fois qu'un déploiement coince, vous saurez exactement quoi demander. Et vous aiderez l'équipe à résoudre le problème plus vite.