@STPo @premartinpatrick le toot initial m’a fait tiquer, étant visé de part ma profession.

100% de mes collègues et des gens du métier que je côtoie en dehors militent pour:

• des meilleures specifications
• des formats de document de travail qui permettent d’aligner pour chaque spécification, des cas de tests précis et pouvant être passés en revue

Je sais pas trop quelle vision ont les gens de mon travail, mais chez les éditeurs de logiciel, c’est pas le développeur qui décide de ça ou qui prend des décisions incohérentes qui génèrent des cas non-gérés (et donc autant de failles de sécurité potentielles). Le développeur, il reçoit une spécification de ce que le logiciel doit faire et dans quelles contraintes. Il apporte des solutions techniques autour de ces problèmes. Bien sur les solutions techniques peuvent être nulles*, mais dans mon expérience, les problématiques viennent surtout d’un manque de vision d’ensemble de ce que le logiciel doit faire ce qui produit à la fin du projet un empilement propice au chaos technique. Le développeur se retrouve donc à combler les trous sans forcément documenter ce qu’il fait dans les contraintes de temps et de moyens qui lui sont alloués, et c’est la que les problèmes apparaissent.

Le jour où on aura des deadlines tenables (pour faire tout ce qui doit être fait et pas seulement aligner des lignes de code) et des specs bien écrites, y’aura bcp moins de soucis. Mais ça, c’est pas tellement dans nos mains.

*Les protections contre les solutions techniques nazes sont plutôt simple à mettre en œuvre: documentation des choix et de leurs raisons (ADR) et revue par les pairs du code produit. Rédaction des cas de test par des tiers non développeurs ou TDD. Mais pareil ça demande du temps qu’on a presque jamais.