![]() |
![]() |
Quel intérêt « d’accuser » un langage quand c’est le developpeur derrière qui est responsable du problème.Que 75% des app PHP comporte des failles XSS comparé à seulement 31% en javascript veux seulement dire que les dév JS sont plus sensibilisé à cette problématique particulière.Quelle est l’échantillon analysé ? Y’a t’il autant d’application de chaque langage ? Parce que si dans le lot j’ai 50% de wordpress pas à jour forcément ca fausse les résultats.
Est ce que c’est que du backend ? Front + back ? Parce que par exemple ne pas voir de problème de XSS sur du C++ alors qu’il n’y a pas nativement de solution ca me fait doucement rire.
![]() |
![]() |
C’est vrai que comparer directement le nombre de bug n’est pas forcément pertinent vu que généralement ils ne sont pas utilisés dans le même contexte. Par contre, comparer les types d’erreur par langage a beaucoup de sens car certains types d’erreurs sont moins facile voire impossible a faire dans certains langages, c’est utile de savoir où porter son attention en priorité suivant le langage qu’on utilise.
![]() |
![]() |

Personnellement, j’aurais bien voulu mais je refuse de laisser mon mail pour vérifier si une boite qui vend de la sécurité a raison de nous alarmer sur le manque de sécurité.
![]() |
![]() |
Ce n’est clairement pas ce qu’on peut déduire de ce rapport qui traite uniquement de code dans le cloud et ne le compare pas avec du code développé de manière classique. Vous n’aimez pas le cloud, peut-être avec de bonnes raison, mais ça n’est pas le sujet ici.
Je pense pas que le but soit de dire que tous les logiciels sont défaillants. Normalement tout les développeurs sont au courant, même si ça ne semble pas totalement inutile à rappeler.
Le but de la publication de ce rapport est en bien sûr avant tout publicitaire. Si la société présente bien gracieusement ses résultats, c’est une manière de mettre en avant son produit d’analyse. Il ne s’agit pas d’une analyse scientifique rigoureuse. Juste des chiffres brut des résultats de l’outil sans analyse des biais possibles dans les entrées.
Ça fait beaucoup de conditions dont certaines sont à peu près sures de ne pas être remplies dans la pratique, parce que le nombre de développeurs de disponibles qui maitrisent parfaitement un sujet est limité, et que même les experts ne sont pas infaillible et finiront par laisser passer des erreurs sur une base de code suffisamment complexe. Donc avoir des outils et des langages qui peuvent empêcher certaines erreurs peut toujours s’avérer utile.
Le domaine à son importance : c’est sur qu’on aura pas d’erreur XSS dans une appli non web. Mais même dans un domaine identique le langage a un impact. Pour une appli identique en C++ ou en Java, on pourra avoir des problèmes de sécurité dus à un buffer overflow en C++ alors qu’en Java c’est strictement impossible.
Je crois surtout que c’est l’article qui essaie de faire dire des choses au rapport qu’il ne prétend pas. Il ne s’agit en aucun cas d’une étude scientifique rigoureuse mais d’un rapport des résultats d’un outil sur la base de code soumise par les clients. Ces chiffres peuvent être intéressant mais il faut prendre en compte tous les biais possible que cette situation entraine.
Je me suis fait la même remarque. Si le Java et le C# offrent quand même un langage plus structuré qui peut prévenir certaines erreurs, le JavaScript n’offre pas plus que le PHP du point de vue sécurité.
Je pense que ça doit s’expliquer par un biais quelconque dans les données en entrée du rapport. Encore une fois une vraie étude devrait faire attention de traiter des données comparables, ici ça n’est pas le cas. Vu que la qualité du code soumis n’est pas forcément similaire, on peut par exemple supposer que les application PHP correspondent a des projet plus anciens qui datent d’une époque ou la sécurité n’était pas un préoccupation. Si le nombre de client étudiés n’est pas assez élevé il peut aussi tout simplement y avoir un facteur chance. Le rapport ne montre que les erreurs relevés par l’outil. On peut aussi supposer que l’outil est plus efficace pour détecter des erreurs PHP que JavaScript.
Globalement, je pense que ce rapport n’est pas vraiment intéressant pour comparer les langage entre eux vu que les projets comparés ne sont pas forcément équivalent.
![]() |
![]() |

on peut te retourner ton argument : plus 1 langage est facile à prendre en main, et plus il y a des « juniors » qui l’utilisent (<- c’est d’ailleurs le but recherché)
C’est le cas du PHP
Python est aussi 1 langage facile à apprendre. Mais je pense que c’est le domaine (R&D) qui fait que de bons développeurs l’utilisent. JavaScript me semble à 1 sale réputation et est « transcompilé » avec TypeScript.
Bof il faut remarquer que seul le C++ à des problèmes/ erreurs liés au « matériel » (dépassement de tampon, gestion des erreurs, …)
Les autres qui sont derrière des machines virtuelles ou des serveurs, ont tous des problèmes/ erreurs MÉTIER.
Donc, oui le langage est important . Et ce n’est pas pour rien que depuis 2011 le C++ évolue tous les 3 ans (C++11, C++14, C++17, C++20) pour supprimer cet écueil pour arriver à ce que les développeurs ne se concentrent que sur le métier.
On peut aussi parler des « sucres syntaxiques ». Par exemple le langage go c’est du C qui permet de faire du concurrentiel très facilement.
![]() |
![]() |

Comparer des défaillances des langages sans parler du champ d’utilisation des logiciels fait avec ces langages ne permet pas de conclure quoi que se soit, sauf comme dit scandinave qu’un langage utilisé pour A aura plus de failles liées à A et qu un autre pour B aura des failles pour B…
![]() |
![]() |

Histoire d’être un peu plus constructif que cette assertion qui n’engage que toi, je dirais plutôt : passer d’un client lourd à une appli web dans le cloud expose les développeurs à tout un tas de nouveaux problèmes. Mais aussi à tout un tas d’avantages.
Chaque approche a ses avantages et inconvénients, ses coûts et bénéfices. Peser le pour et le contre de chaque solution, argumenter de façon factuelle ses choix d’archi, c’est précisément là que se trouve l’aspect ingénierie de notre métier. Ca va de pair avec une vision stratégique claire et précise du projet, d’où l’importance de la communication entre les équipes. Beaucoup d’échecs sont à chercher de ce côté là plus que dans une façon de coder. Ou dit autrement : la bonne utilisation d’une techno adaptée au besoin dépend beaucoup de la culture d’entreprise en place.
![]() |
![]() |

Voilà, faut arrêter d’être extrémiste mais comme ce boulot est blindé de commerciaux (je parle commerciaux aussi dans le sens un petit chef IT qui croit qu’il est balaise et vend ça à la direction pour avoir du budget et donc augmenter sa visibilité) qui veulent vendre tout et n’importe quoi, tu te retrouves avec des applications web là où c’est pas forcément nécessaire (au hasard une appli intranet qui remplace un classeur Excel que gère 10 gus dans un open space ).
![]() |
![]() |

Cessons de nous voiler la face, passer d’un client lourd à une appli web dans le cloud apporte plus de problèmes que cela n’en résout. Le troll ultime, c’est de devoir maîtriser 3 langages (HTML/CSS/JS) rien que pour faire une UI correcte, là où il existe des éditeurs visuels qui rendent la conception de l’interface triviale pour les applis de bureau.
![]() |
![]() |
Sent with Reeder