Envoyé par
Louis Griffont
Maintenant, c'est assez gonflant d'entendre le même refrain : «Les produits fermés sont buggués, plein de failles de sécurité et jamais corrigés», alors que «les logiciels open-source sont parfaits, et si jamais quelqu'un trouvait un bug, une faille, elle serait corrigée avant même de dire "ouf"».
Je ne diabolise pas plus l'un que je n'idéalise l'autre.
Ce que je dis, c'est que
quand il y a une faille, il y a plus de chances d'obtenir une correction
rapide avec les produits open-source, simplement parce le nombre de personnes capables d'apporter la réponse et leur situation géographique fait que tu as beaucoup plus de chance de trouver quelqu'un qui est justement en pose et qui se sente concerné dans la communauté open-source.
De plus, les développeurs open-source sont, généralement, les utilisateurs des produits auxquels ils participent, et, comme tout utilisateurs, ils souhaitent avoir des produits de qualité.
Ils se sentent donc plus impliqués par la qualité de leur développement.
Pour les produit fermés, tu as beaucoup plus de chances de te trouver face à une situation dans laquelle un produit donné est le résultat d'une "commande" d'un client, et où les commandes s'enchainent.
Il est donc plus difficile pour le type capable d'apporter une solution de, tout simplement, trouver le temps de le faire, parce qu'il est sans doute déjà sur un autre projet.
Faut pas prendre les gens pour des c**s, merci !
Aucune société n'aime avoir des bugs, mais hélas, les développeurs et les concepteurs étant encore des humains, l'erreur est inévitable.
Je suis tout à fait d'accord avec toi...
Dire que ces sociétés ne les corrigent pas est tout aussi faux. Dire que les corrections sont lentes, hé bien je dirais que pour ma part, (au vue de mes modestes programmes) quand un bug nous est signalé, on évalue son impact, puis ce qu'implique sa correction (corrélation avec le reste du/des programmes) et que la rapidité de la mise en place va dépendre de tout ça.
Certaines entreprises sont, je te l'accorde, particulièrement réactives
Mais ils s'agit, le plus souvent, de sociétés qui ont mis un petit nombre de produits au point, et qui "passent leur temps" à essayer de les améliorer.
C'est caricatural, sans doute, mais finalement fort proche de la vérité
J'ai du mal à imaginer qu'une société comme Microsoft ne corrige pas un bug, juste par négligence. Le problème est que l'on parle de logiciels distribués à des millions d'exemplaires de part le monde, et qu'une correction mal faite, à l'impact sous-estimé, peut finalement être plus dommageable que le fait de laisser le bug quelques jours de plus.
Et pourtant...
Récemment encore, quelqu'un de chez google a présenté une PoC sur une faille importante sous XP qui n'avait pas été réglée en 60 jours...
Et, comme par hasard, le correctif est sorti en une semaine juste après (avec au passage quelques noms d'oiseaux échangés).
Je ne suis pas de ceux qui s'écrient volontiers "comment, après plus de 9 ans, il y a encore des failles !!!", car je peux le concevoir si personne ne l'a détectée avant, mais ce que je ne pourrai jamais concevoir c'est qu'aucune solution ne soit apportée en 60 jours alors que la faille a été identifiée et que, comme par hasard, on y trouve une solution endéans la semaine quand une PoC est diffusée.
Je suis désolé, mais ca fait un peu "foutage de gueule".
Le bug dont je parlais voici quelques interventions a bel et bien eu lieu et tous les journaux en ont fait leurs choux gras, il y a quelques années.
Je n'irai pas dire que c'est de la pure négligence, ni même essayer de trouver une raison, autre que le manque de temps des développeurs pour y apporter une solution, mais ce sont des exemple vécus.
Mais j'ai, malgré tout, parfois l'impression que microsoft part du principe que "tant que ce n'est pas connu, autant laisser les choses en l'état".
Je suis souvent abasourdi de constater qu'une faille qui traine en étant connue depuis longtemps est, comme par hasard, colmatée dans la semaine qui suit une grosse attaque qui en profitait
Maintenant, là ou l'argument pour l'open-source fait peur, c'est qu'à vous entendre, le mec dans son garage qui découvre un bug, le corrige, et hop, la version se retrouve chez tous les utilisateurs, sans contrôle, sans vérification,...
Rassurez-nous, messieurs. Rassurez-nous !
On peut te rassurer sur ce point, il y a bien un cycle de contrôle et de vérification qui est effectué.
Mais encore une fois, le nombre est un avantage important, parce qu'on réduit la possibilité que l'un des intervenants dans le cycle de correction de contrôle et de vérification soit, par malheur, indisponible pour la tâche.
Comprend moi: imagine une petite structure composée, entre autres de deux développeurs/programmeurs, deux personnes responsables des tests et deux personnes responsables du déploiement.
Quand un bug est signalé, il y a de grandes chances que les deux dev soient occupés à autre chose: il mettent la résolution du problème dans leur "to do list", éventuellement triés selon l'urgence.
Ils ne s'attaquent donc au problème que... quand ils ont fini ce qui était plus urgent, mais cela occasionne un premier délais (parfois important).
Quand ils ont (ou pensent avoir) apporté une solution, il filent le tout aux gens responsables des tests "préprod", qui ont peut être eux aussi des choses plus importantes à faire.
Cela occasionne un nouveau délais, qui peut, ici encore, parfois être important.
Même en considérant que la solution apportée est tout de suite validée, il passeront le relais aux gens responsables du déploiement auront peut être eux aussi des choses plus importantes à faire, avec donc, ici aussi, un nouveau délais peut être important supplémentaire.
Si tu as dix dev, dix personnes qui peuvent s'occuper des tests et dix personnes qui peuvent s'occuper du déploiement, tu réduis déjà considérablement le risque de les voir tous occupés quand "la patate chaude" se présente, surtout si leur répartition géographique est d'ordre mondial.
Si tu multiplies encore les gens qui peuvent prendre le problème en charge, et que tu trouve une personne susceptible de le faire par fuseau horaire (par exemple), tu as la quasi certitude qu'il y aura en permanence quelqu'un susceptible d'intervenir.
Les délais de réaction seront alors, fatalement, réduit au stricte minimum, et seul le temps "réel" de correction, de contrôle et de validation sera nécessaire pour apporter la solution.
Je ne le répéterai jamais assez: en tant que développeur, je peux concevoir qu'il y ait des bugs ou des failles, et je peux même concevoir qu'ils (elles) trainent pendant des années, si c'est le temps qu'il faut pour les identifier.
Par contre, ce que je trouve inacceptable, en tant qu'utilisateur, c'est qu'une solution au problème ne soit pas apportée dans les plus brefs délais:
Qu'il faille du temps pour s'assurer que la solution envisagée est viable et correcte est une chose que j'accepte sans difficulté, mais que le délais "explose" littéralement parce que celui qui peut résoudre le problème a "autre chose à faire" -- ou pire, parce qu'il s'en fout royalement: son projet est livré, c'est tout ce qui lui importe
... Je sais que c'est rare, mais ca arrive -- est quelque chose que je n'accepterai jamais.
2 |
0 |
« Dans 5 ans, logiciels et hardwares seront gratuits », prédit la Fondation Linux
(Ouf, je suis sous Windows)
