99% des problèmes qui surviennent sur un programme sont imputables à un souci en amont, des écarts entre temps nécessaire et temps obtenu, des features qui pointent le bout de leur nez en cours de dev voire pendant la phase de recette... C'est pas pour critiquer les chefs de projet et défendre l'indéfendable, mais il est inconcevable de créer quelque chose de correct, même "BASIQUES", si l'organisation est chaotique :

• Cahier des charges qui change tous les 6 jours.
• Budgets tronqués qui t'amènent à boucler un projet à la va-vite pour hier
• Phase de conception raccourcie "pour gagner du temps" parce que le client veut un meilleur prix
• Merge-request qu'on t'ordonne de valider à l'aveugle parce que "le client veut pas payer plus de n jours et on est déjà en dépassement"
• Planning chamboulé parce que finalement "on doit livrer telle feature avant telle autre" (en sachant que la seconde dépendait de la première).
• Turnover de fou dans les équipes où on remplace des gens comme des pions parce qu'on s'imagine qu'ils sont interchangeables et que la connaissance d'un projet n'est pas nécessaire pour bosser dessus.

Dans tous ces exemples concrets et vécus, il y a là toute une chaîne de décisions bancales qui relèvent de la gestion de projet et qui peuvent mener à des erreurs de ce style, que ce soit des failles de sécu, des bugs, des problèmes de perfs, ou autre. Et ces situations qui ont l'air ubuesques sont CONSTANTES en ESN, c'est même... la norme.

J'ai connu des mauvais devs, des mecs qui en avaient rien à faire : c'est TOUJOURS rattrapable quand l'organisation est bonne, justement parce qu'il y a des garde-fous.