piratage de logiciels : responsabilite de l'admin reseau
38 réponses
Pisaura Mirabilis
bonjour
je ne suis pas sûr d'être totalement en charte : ma question ne concerne
pas directement le droit d'Internet mais des logiciels de façon plus
général. Pourtant je ne pense pas que fr.misc.droit soit plus indiqué.
Presque tout est dans le titre :
- Dans le cas d'une installation sauvage par un utilisateur d'un logiciel
piraté sur un poste quelle est le responsabilité de l'admin réseau ?
- Existe-t-il une jurisprudence ?
Le contexte qui m'interresse plus particulièrement : les établissements
scolaires ou les admins réseaux sont en général "quasi" bénévoles et pas
forcement très formés tant en droit qu'en info.
Le Mon, 18 Apr 2005 19:37:37 +0200, Emmanuel Dreyfus a écrit :
Patrick Mevzek wrote:
Tu envisages donc le cas d'un developpement sur commande.
Il devrait souvent y avoir des cahiers des charges, tout de même, non :-) ?
Et le developpeur a obligation de moyen de s'y conformer. Et si six mois après avoir accepté le logiciel tu trouves que finnallement ca ne correspond pas au cahier des charges, t'as pas tellement de recours.
Là c'est clairement la responsabilité du donneur d'ordre. (définition du cahier des charges, vérification de l'adéquation du résultat).
Encore une fois, tout développeur, à l'heure actuelle, et notamment sur Internet, devrait être sensibilisé aux problèmes de sécurité, et en faire un *minimum*. Mais même ce minimum est rarement présent.
Souvent, chez le client, le cahier des charges est une notion assez floue... (genre logiciel de gestion immobilière. t'as pas granc chose, toutes les fonctions ne sont pas décrites, souvent pas définies du tout) et c'est au dev de faire un cahier des charges. quand tu connais le métier du client, ca va tu peux t'en sortir, mais quand c'est nouveau, tu perds un temps fou rien que pour le cahier des charges...
-- Séb. www.trouverunemploi.info
Patrick Mevzek a écrit :
Le Mon, 18 Apr 2005 19:37:37 +0200, Emmanuel Dreyfus a écrit :
Patrick Mevzek <pm-N200504@nospam.dotandco.com> wrote:
Tu envisages donc le cas d'un developpement sur commande.
Il devrait souvent y avoir des cahiers des charges, tout de même, non
:-) ?
Et le developpeur a obligation de moyen de s'y conformer. Et si six mois
après avoir accepté le logiciel tu trouves que finnallement ca ne
correspond pas au cahier des charges, t'as pas tellement de recours.
Là c'est clairement la responsabilité du donneur d'ordre.
(définition du cahier des charges, vérification de l'adéquation du
résultat).
Encore une fois, tout développeur, à l'heure actuelle, et notamment sur
Internet, devrait être sensibilisé aux problèmes de sécurité, et en faire
un *minimum*. Mais même ce minimum est rarement présent.
Souvent, chez le client, le cahier des charges est une notion assez floue... (genre logiciel de gestion immobilière. t'as pas granc chose, toutes les fonctions ne sont pas décrites, souvent pas définies du tout) et c'est au dev de faire un cahier des charges. quand tu connais le métier du client, ca va tu peux t'en sortir, mais quand c'est nouveau, tu perds un temps fou rien que pour le cahier des charges...
Le Mon, 18 Apr 2005 19:37:37 +0200, Emmanuel Dreyfus a écrit :
Patrick Mevzek wrote:
Tu envisages donc le cas d'un developpement sur commande.
Il devrait souvent y avoir des cahiers des charges, tout de même, non :-) ?
Et le developpeur a obligation de moyen de s'y conformer. Et si six mois après avoir accepté le logiciel tu trouves que finnallement ca ne correspond pas au cahier des charges, t'as pas tellement de recours.
Là c'est clairement la responsabilité du donneur d'ordre. (définition du cahier des charges, vérification de l'adéquation du résultat).
Encore une fois, tout développeur, à l'heure actuelle, et notamment sur Internet, devrait être sensibilisé aux problèmes de sécurité, et en faire un *minimum*. Mais même ce minimum est rarement présent.
Souvent, chez le client, le cahier des charges est une notion assez floue... (genre logiciel de gestion immobilière. t'as pas granc chose, toutes les fonctions ne sont pas décrites, souvent pas définies du tout) et c'est au dev de faire un cahier des charges. quand tu connais le métier du client, ca va tu peux t'en sortir, mais quand c'est nouveau, tu perds un temps fou rien que pour le cahier des charges...
-- Séb. www.trouverunemploi.info
jpeps
Emmanuel Dreyfus a écrit :
Patrick Mevzek wrote:
[...]. Le concepteur de l'application fournit son logiciel tel quel
> et sans aucune garantie de fonctionnement. C'est ecrit dans toutes > les licenses, et aucun tribunal n'est jamais revenu la dessus à > ma connaissance.
Bonjour
Sur LEGALIS.NET, dans la sélection de l'item RESPONSABILITE, il y a le conflit entre deux fournisseurs "matériel+logiciel" en une société de "mode".
C'était un contrat particulier, mais la "non-responsabilité" semble se chiffrer à 500 000 euros (si j'ai bien lu).
Il me semble qu'il y a eu d'autre cas, avec logiciel du commerce, où la clause de non responsabilité a été jugée contraire au code de la consommation (obligation pour le produit à assurer les fonctions alléguées).
Salutations
JPP
-- Enlevez le NO du spam et .invalid pour me répondre
"Dans les champs de l'observation, le hasard ne favorise que les esprits préparés." Louis Pasteur
Emmanuel Dreyfus a écrit :
Patrick Mevzek <pm-N200504@nospam.dotandco.com> wrote:
[...]. Le concepteur de l'application fournit son logiciel tel quel
> et sans aucune garantie de fonctionnement. C'est ecrit dans toutes
> les licenses, et aucun tribunal n'est jamais revenu la dessus à
> ma connaissance.
Bonjour
Sur LEGALIS.NET, dans la sélection de l'item RESPONSABILITE, il y a le
conflit entre deux fournisseurs "matériel+logiciel" en une société de
"mode".
C'était un contrat particulier, mais la "non-responsabilité" semble se
chiffrer à 500 000 euros (si j'ai bien lu).
Il me semble qu'il y a eu d'autre cas, avec logiciel du commerce, où la
clause de non responsabilité a été jugée contraire au code de la
consommation (obligation pour le produit à assurer les fonctions alléguées).
Salutations
JPP
--
Enlevez le NO du spam et .invalid pour me répondre
"Dans les champs de l'observation, le hasard ne favorise que les esprits
préparés." Louis Pasteur
[...]. Le concepteur de l'application fournit son logiciel tel quel
> et sans aucune garantie de fonctionnement. C'est ecrit dans toutes > les licenses, et aucun tribunal n'est jamais revenu la dessus à > ma connaissance.
Bonjour
Sur LEGALIS.NET, dans la sélection de l'item RESPONSABILITE, il y a le conflit entre deux fournisseurs "matériel+logiciel" en une société de "mode".
C'était un contrat particulier, mais la "non-responsabilité" semble se chiffrer à 500 000 euros (si j'ai bien lu).
Il me semble qu'il y a eu d'autre cas, avec logiciel du commerce, où la clause de non responsabilité a été jugée contraire au code de la consommation (obligation pour le produit à assurer les fonctions alléguées).
Salutations
JPP
-- Enlevez le NO du spam et .invalid pour me répondre
"Dans les champs de l'observation, le hasard ne favorise que les esprits préparés." Louis Pasteur
jpeps
Emmanuel Dreyfus a écrit :
Patrick Mevzek wrote:
Tu serais capable de t'engager sur le fait qu'un logiciel que tu as ecrit n'a pas de vices cachés? Pas de bug dans ton code, ni dans aucune librairie que tu utilise? Pas de bug dans l'OS qui se repercute sur ton application? Pas de bug invisible pendant le developpement et qui se révèle lors d'un changement de config?
Bonjour
Il est possible de conclure des contrats où il existe de telles clauses.
La discussion ne porte alors pas sur la livraison des codes sources, qui est une évidence, mais - sur la précision de définition du matériel, - sur l'intensité de l'audit du code, tant du coté client que fournisseur, - sur l'évolution des versions, et les test de non régressions associés, - sur la validation du logiciel et outils associés, tant que machine de développement que sur machine cible, - sur la complétude des essais avant mise en production.
Le coût du système résultant n'a que peu à voir avec un "PC de Bureau". Mais on commence à voir aujourd'hui des certifications sur des systèmes LINUX.
Salutations
JPP
-- Enlevez le NO du spam et .invalid pour me répondre
"Dans les champs de l'observation, le hasard ne favorise que les esprits préparés." Louis Pasteur
Emmanuel Dreyfus a écrit :
Patrick Mevzek <pm-N200504@nospam.dotandco.com> wrote:
Tu serais capable de t'engager sur le fait qu'un logiciel que tu as
ecrit n'a pas de vices cachés? Pas de bug dans ton code, ni dans aucune
librairie que tu utilise? Pas de bug dans l'OS qui se repercute sur ton
application? Pas de bug invisible pendant le developpement et qui se
révèle lors d'un changement de config?
Bonjour
Il est possible de conclure des contrats où il existe de telles clauses.
La discussion ne porte alors pas sur la livraison des codes sources, qui
est une évidence, mais
- sur la précision de définition du matériel,
- sur l'intensité de l'audit du code, tant du coté client que fournisseur,
- sur l'évolution des versions, et les test de non régressions associés,
- sur la validation du logiciel et outils associés, tant que machine de
développement que sur machine cible,
- sur la complétude des essais avant mise en production.
Le coût du système résultant n'a que peu à voir avec un "PC de Bureau".
Mais on commence à voir aujourd'hui des certifications sur des systèmes
LINUX.
Salutations
JPP
--
Enlevez le NO du spam et .invalid pour me répondre
"Dans les champs de l'observation, le hasard ne favorise que les esprits
préparés." Louis Pasteur
Tu serais capable de t'engager sur le fait qu'un logiciel que tu as ecrit n'a pas de vices cachés? Pas de bug dans ton code, ni dans aucune librairie que tu utilise? Pas de bug dans l'OS qui se repercute sur ton application? Pas de bug invisible pendant le developpement et qui se révèle lors d'un changement de config?
Bonjour
Il est possible de conclure des contrats où il existe de telles clauses.
La discussion ne porte alors pas sur la livraison des codes sources, qui est une évidence, mais - sur la précision de définition du matériel, - sur l'intensité de l'audit du code, tant du coté client que fournisseur, - sur l'évolution des versions, et les test de non régressions associés, - sur la validation du logiciel et outils associés, tant que machine de développement que sur machine cible, - sur la complétude des essais avant mise en production.
Le coût du système résultant n'a que peu à voir avec un "PC de Bureau". Mais on commence à voir aujourd'hui des certifications sur des systèmes LINUX.
Salutations
JPP
-- Enlevez le NO du spam et .invalid pour me répondre
"Dans les champs de l'observation, le hasard ne favorise que les esprits préparés." Louis Pasteur
manu
jpeps wrote:
Il est possible de conclure des contrats où il existe de telles clauses.
La discussion ne porte alors pas sur la livraison des codes sources, qui est une évidence, mais - sur la précision de définition du matériel, - sur l'intensité de l'audit du code, tant du coté client que fournisseur, - sur l'évolution des versions, et les test de non régressions associés, - sur la validation du logiciel et outils associés, tant que machine de développement que sur machine cible, - sur la complétude des essais avant mise en production.
Le coût du système résultant n'a que peu à voir avec un "PC de Bureau". Mais on commence à voir aujourd'hui des certifications sur des systèmes LINUX.
Mais ca reste de l'obligation de moyen et pas de résultats. Même avec tout ca on est encore très très loin de pouvoir affirmer que le système est exempt de bugs.
-- Emmanuel Dreyfus Le cahier de l'admin BSD 2eme ed. est dans toutes les bonnes librairies http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
jpeps <jpeps.NOspam.box@online.fr.invalid> wrote:
Il est possible de conclure des contrats où il existe de telles clauses.
La discussion ne porte alors pas sur la livraison des codes sources, qui
est une évidence, mais
- sur la précision de définition du matériel,
- sur l'intensité de l'audit du code, tant du coté client que fournisseur,
- sur l'évolution des versions, et les test de non régressions associés,
- sur la validation du logiciel et outils associés, tant que machine de
développement que sur machine cible,
- sur la complétude des essais avant mise en production.
Le coût du système résultant n'a que peu à voir avec un "PC de Bureau".
Mais on commence à voir aujourd'hui des certifications sur des systèmes
LINUX.
Mais ca reste de l'obligation de moyen et pas de résultats. Même avec
tout ca on est encore très très loin de pouvoir affirmer que le système
est exempt de bugs.
--
Emmanuel Dreyfus
Le cahier de l'admin BSD 2eme ed. est dans toutes les bonnes librairies
http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
manu@netbsd.org
Il est possible de conclure des contrats où il existe de telles clauses.
La discussion ne porte alors pas sur la livraison des codes sources, qui est une évidence, mais - sur la précision de définition du matériel, - sur l'intensité de l'audit du code, tant du coté client que fournisseur, - sur l'évolution des versions, et les test de non régressions associés, - sur la validation du logiciel et outils associés, tant que machine de développement que sur machine cible, - sur la complétude des essais avant mise en production.
Le coût du système résultant n'a que peu à voir avec un "PC de Bureau". Mais on commence à voir aujourd'hui des certifications sur des systèmes LINUX.
Mais ca reste de l'obligation de moyen et pas de résultats. Même avec tout ca on est encore très très loin de pouvoir affirmer que le système est exempt de bugs.
-- Emmanuel Dreyfus Le cahier de l'admin BSD 2eme ed. est dans toutes les bonnes librairies http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
manu
Joe wrote:
D'ailleurs, peut-être qu'il a été démontré mathématiquement qu'il est impossible de prouver qu'un logiciel est exempt de bugs, ie. le théorème d'incomplétude adapté à la programmation, ce qui expliquerait qu'on ne peut imposer aux développeurs un soft parfait?
On peut faire de la preuve de programme, et parfois on en fait. Il me semble que le logiciel de la ligne de métro 14 à Paris a été prouvé.
Mais faut voir sur quoi la preuve repose: par exemple, on suppose que l'OS et le matériel se comportent d'une certaine façon et à partir de ca on peut démontrer certaines proprietés dans le comportement du programme. Si l'OS ou le materiel n'ont pas le comportement prévu, la preuve ne démontre plus rien du tout.
Alors pour arriver à une certitude mathématique, il faut aller faire de la preuve du matériel. Et là on butte sur le fait que le monde réél n'est pas mathématique mais physique: le matériel ne se comporte pas forcement comme prévu, c'est un océan de probabilités très proches de 0 ou de 1, mais on est jamais mathématiquement sûr de rien.
Y'a un ammusant papier de types qui ont cassé le modèle de sécurité de la machine virtuelle Java: en chauffant la RAM ils arrivent à faire sortir le materiel de ses spécifications et ainsi faire dérailler le logiciel dans le sens qu'ils veulent: http://csdl.computer.org/comp/proceedings/sp/2003/1940/00/19400154abs.htm
Pour se proteger des errements du matériel, on peut prévoir des reprises sur erreur, pour detecter qu'on s'est ecarté du comportement normal et y revenir, mais bon on ne peut pas tout prévoir. Une autre technique consiste à multiplier les architectures, par exemple en faisant les mêmes calculs en C sur 80486 et en fortran sur 68030. Si ca diverge, c'est qu'il y a un problème. Dans le cas du chauffage de la RAM, la protection la plus simple est d'utiliser de la RAM ECC, qui est capable de detecter la plupart des alterations de la mémoire à cause de la chaleur.
Mais quelle que soit les mesures prises, on ne peut atteindre une certitude de 100% sur le comportement d'un système informatique, on se contente de se raprocher de la certitude.
-- Emmanuel Dreyfus http://hcpnet.free.fr/pubz
Joe <justaskme@if.you.want.to.contact.me> wrote:
D'ailleurs, peut-être qu'il a été démontré mathématiquement qu'il est
impossible de prouver qu'un logiciel est exempt de bugs, ie. le
théorème d'incomplétude adapté à la programmation, ce qui expliquerait
qu'on ne peut imposer aux développeurs un soft parfait?
On peut faire de la preuve de programme, et parfois on en fait. Il me semble
que le logiciel de la ligne de métro 14 à Paris a été prouvé.
Mais faut voir sur quoi la preuve repose: par exemple, on suppose que l'OS
et le matériel se comportent d'une certaine façon et à partir de ca on peut
démontrer certaines proprietés dans le comportement du programme. Si l'OS ou
le materiel n'ont pas le comportement prévu, la preuve ne démontre plus rien
du tout.
Alors pour arriver à une certitude mathématique, il faut aller faire de la
preuve du matériel. Et là on butte sur le fait que le monde réél n'est pas
mathématique mais physique: le matériel ne se comporte pas forcement comme
prévu, c'est un océan de probabilités très proches de 0 ou de 1, mais on est
jamais mathématiquement sûr de rien.
Y'a un ammusant papier de types qui ont cassé le modèle de sécurité de la
machine virtuelle Java: en chauffant la RAM ils arrivent à faire sortir le
materiel de ses spécifications et ainsi faire dérailler le logiciel dans le
sens qu'ils veulent:
http://csdl.computer.org/comp/proceedings/sp/2003/1940/00/19400154abs.htm
Pour se proteger des errements du matériel, on peut prévoir des reprises sur
erreur, pour detecter qu'on s'est ecarté du comportement normal et y
revenir, mais bon on ne peut pas tout prévoir. Une autre technique consiste
à multiplier les architectures, par exemple en faisant les mêmes calculs en
C sur 80486 et en fortran sur 68030. Si ca diverge, c'est qu'il y a un
problème. Dans le cas du chauffage de la RAM, la protection la plus simple
est d'utiliser de la RAM ECC, qui est capable de detecter la plupart des
alterations de la mémoire à cause de la chaleur.
Mais quelle que soit les mesures prises, on ne peut atteindre une certitude
de 100% sur le comportement d'un système informatique, on se contente de se
raprocher de la certitude.
D'ailleurs, peut-être qu'il a été démontré mathématiquement qu'il est impossible de prouver qu'un logiciel est exempt de bugs, ie. le théorème d'incomplétude adapté à la programmation, ce qui expliquerait qu'on ne peut imposer aux développeurs un soft parfait?
On peut faire de la preuve de programme, et parfois on en fait. Il me semble que le logiciel de la ligne de métro 14 à Paris a été prouvé.
Mais faut voir sur quoi la preuve repose: par exemple, on suppose que l'OS et le matériel se comportent d'une certaine façon et à partir de ca on peut démontrer certaines proprietés dans le comportement du programme. Si l'OS ou le materiel n'ont pas le comportement prévu, la preuve ne démontre plus rien du tout.
Alors pour arriver à une certitude mathématique, il faut aller faire de la preuve du matériel. Et là on butte sur le fait que le monde réél n'est pas mathématique mais physique: le matériel ne se comporte pas forcement comme prévu, c'est un océan de probabilités très proches de 0 ou de 1, mais on est jamais mathématiquement sûr de rien.
Y'a un ammusant papier de types qui ont cassé le modèle de sécurité de la machine virtuelle Java: en chauffant la RAM ils arrivent à faire sortir le materiel de ses spécifications et ainsi faire dérailler le logiciel dans le sens qu'ils veulent: http://csdl.computer.org/comp/proceedings/sp/2003/1940/00/19400154abs.htm
Pour se proteger des errements du matériel, on peut prévoir des reprises sur erreur, pour detecter qu'on s'est ecarté du comportement normal et y revenir, mais bon on ne peut pas tout prévoir. Une autre technique consiste à multiplier les architectures, par exemple en faisant les mêmes calculs en C sur 80486 et en fortran sur 68030. Si ca diverge, c'est qu'il y a un problème. Dans le cas du chauffage de la RAM, la protection la plus simple est d'utiliser de la RAM ECC, qui est capable de detecter la plupart des alterations de la mémoire à cause de la chaleur.
Mais quelle que soit les mesures prises, on ne peut atteindre une certitude de 100% sur le comportement d'un système informatique, on se contente de se raprocher de la certitude.
-- Emmanuel Dreyfus http://hcpnet.free.fr/pubz
jpeps
Emmanuel Dreyfus a écrit :
jpeps wrote:
Il est possible de conclure des contrats où il existe de telles clauses.
La discussion ne porte alors pas sur la livraison des codes sources, qui est une évidence, mais - sur la précision de définition du matériel, - sur l'intensité de l'audit du code, tant du coté client que fournisseur, - sur l'évolution des versions, et les test de non régressions associés, - sur la validation du logiciel et outils associés, tant que machine de développement que sur machine cible, - sur la complétude des essais avant mise en production.
Le coût du système résultant n'a que peu à voir avec un "PC de Bureau". Mais on commence à voir aujourd'hui des certifications sur des systèmes LINUX.
Mais ca reste de l'obligation de moyen et pas de résultats. Même avec tout ca on est encore très très loin de pouvoir affirmer que le système est exempt de bugs.
Bonjour.
Je parle bien d'obligation de résultat.
Avec de tels moyens, un client impliqué sur les résultats, l'emploi de métriques judicieuses et d'outils de contrôle de complétude lors des test, on obtient de très bonnes garanties (par exemple, pour 12 logiciels travaillant en collaboration, après 12 ans d'exploitation, on en est à 2 bugs - 1 non respect de spécification et 1 erreur d'implémentation - soit, selon toute vraisemblance 10 logiciels sans bug). Il y a en plus lieu de noter que le point central de la démonstration ne concernait pas l'absence de bug mais le comportement en présence de défaut matériel ou logiciel.
On est très loin de l'exemple cité dans mon autre post.
Salutations
JPP
-- Enlevez le NO du spam et .invalid pour me répondre
"Dans les champs de l'observation, le hasard ne favorise que les esprits préparés." Louis Pasteur
Emmanuel Dreyfus a écrit :
jpeps <jpeps.NOspam.box@online.fr.invalid> wrote:
Il est possible de conclure des contrats où il existe de telles clauses.
La discussion ne porte alors pas sur la livraison des codes sources, qui
est une évidence, mais
- sur la précision de définition du matériel,
- sur l'intensité de l'audit du code, tant du coté client que fournisseur,
- sur l'évolution des versions, et les test de non régressions associés,
- sur la validation du logiciel et outils associés, tant que machine de
développement que sur machine cible,
- sur la complétude des essais avant mise en production.
Le coût du système résultant n'a que peu à voir avec un "PC de Bureau".
Mais on commence à voir aujourd'hui des certifications sur des systèmes
LINUX.
Mais ca reste de l'obligation de moyen et pas de résultats. Même avec
tout ca on est encore très très loin de pouvoir affirmer que le système
est exempt de bugs.
Bonjour.
Je parle bien d'obligation de résultat.
Avec de tels moyens, un client impliqué sur les résultats, l'emploi de
métriques judicieuses et d'outils de contrôle de complétude lors des test,
on obtient de très bonnes garanties (par exemple, pour 12 logiciels
travaillant en collaboration, après 12 ans d'exploitation, on en est à 2
bugs - 1 non respect de spécification et 1 erreur d'implémentation - soit,
selon toute vraisemblance 10 logiciels sans bug). Il y a en plus lieu de
noter que le point central de la démonstration ne concernait pas l'absence
de bug mais le comportement en présence de défaut matériel ou logiciel.
On est très loin de l'exemple cité dans mon autre post.
Salutations
JPP
--
Enlevez le NO du spam et .invalid pour me répondre
"Dans les champs de l'observation, le hasard ne favorise que les esprits
préparés." Louis Pasteur
Il est possible de conclure des contrats où il existe de telles clauses.
La discussion ne porte alors pas sur la livraison des codes sources, qui est une évidence, mais - sur la précision de définition du matériel, - sur l'intensité de l'audit du code, tant du coté client que fournisseur, - sur l'évolution des versions, et les test de non régressions associés, - sur la validation du logiciel et outils associés, tant que machine de développement que sur machine cible, - sur la complétude des essais avant mise en production.
Le coût du système résultant n'a que peu à voir avec un "PC de Bureau". Mais on commence à voir aujourd'hui des certifications sur des systèmes LINUX.
Mais ca reste de l'obligation de moyen et pas de résultats. Même avec tout ca on est encore très très loin de pouvoir affirmer que le système est exempt de bugs.
Bonjour.
Je parle bien d'obligation de résultat.
Avec de tels moyens, un client impliqué sur les résultats, l'emploi de métriques judicieuses et d'outils de contrôle de complétude lors des test, on obtient de très bonnes garanties (par exemple, pour 12 logiciels travaillant en collaboration, après 12 ans d'exploitation, on en est à 2 bugs - 1 non respect de spécification et 1 erreur d'implémentation - soit, selon toute vraisemblance 10 logiciels sans bug). Il y a en plus lieu de noter que le point central de la démonstration ne concernait pas l'absence de bug mais le comportement en présence de défaut matériel ou logiciel.
On est très loin de l'exemple cité dans mon autre post.
Salutations
JPP
-- Enlevez le NO du spam et .invalid pour me répondre
"Dans les champs de l'observation, le hasard ne favorise que les esprits préparés." Louis Pasteur
manu
Joe wrote:
... ce qui explique que les éditeurs de logiciels ne sont pas poursuivis pour des bugs, vu la difficulté même dans des conditions idéales de pondre un soft avec zéro bugs.
Oui, enfin on peut quand même se batte sur l'obligation de moyens. Je suis d'accord avec Patrick qu'il est assez inadmissible de voir des logiciels remplis d'erreurs triviales dont la nature et les consequences sont connus de longue date.
-- Emmanuel Dreyfus Le cahier de l'admin BSD 2eme ed. est dans toutes les bonnes librairies http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
Joe <justaskme@if.you.want.to.contact.me> wrote:
... ce qui explique que les éditeurs de logiciels ne sont pas
poursuivis pour des bugs, vu la difficulté même dans des conditions
idéales de pondre un soft avec zéro bugs.
Oui, enfin on peut quand même se batte sur l'obligation de moyens. Je
suis d'accord avec Patrick qu'il est assez inadmissible de voir des
logiciels remplis d'erreurs triviales dont la nature et les consequences
sont connus de longue date.
--
Emmanuel Dreyfus
Le cahier de l'admin BSD 2eme ed. est dans toutes les bonnes librairies
http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
manu@netbsd.org
... ce qui explique que les éditeurs de logiciels ne sont pas poursuivis pour des bugs, vu la difficulté même dans des conditions idéales de pondre un soft avec zéro bugs.
Oui, enfin on peut quand même se batte sur l'obligation de moyens. Je suis d'accord avec Patrick qu'il est assez inadmissible de voir des logiciels remplis d'erreurs triviales dont la nature et les consequences sont connus de longue date.
-- Emmanuel Dreyfus Le cahier de l'admin BSD 2eme ed. est dans toutes les bonnes librairies http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
manu
jpeps wrote:
Je parle bien d'obligation de résultat.
Avec de tels moyens, un client impliqué sur les résultats, l'emploi de métriques judicieuses et d'outils de contrôle de complétude lors des test, on obtient de très bonnes garanties (par exemple, pour 12 logiciels travaillant en collaboration, après 12 ans d'exploitation, on en est à 2 bugs - 1 non respect de spécification et 1 erreur d'implémentation - soit, selon toute vraisemblance 10 logiciels sans bug). Il y a en plus lieu de noter que le point central de la démonstration ne concernait pas l'absence de bug mais le comportement en présence de défaut matériel ou logiciel.
Ben justement ton exemple est bien la preuve qu'on ne peut exgiger l'obligation de résultat pour du logiciel: même en mettant tous les atouts de ton coté, il te reste deux bugs découverts en 12 ans.
C'est un excellent résultat, et l'obligation de moyen a été sans aucun doute remplie, par contre si on avait ecrit obligation de zéro bugs au départ tu n'aurais pas rempli l'obligation de résultat.
-- Emmanuel Dreyfus Un bouquin en français sur BSD: http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
jpeps <jpeps.NOspam.box@online.fr.invalid> wrote:
Je parle bien d'obligation de résultat.
Avec de tels moyens, un client impliqué sur les résultats, l'emploi de
métriques judicieuses et d'outils de contrôle de complétude lors des test,
on obtient de très bonnes garanties (par exemple, pour 12 logiciels
travaillant en collaboration, après 12 ans d'exploitation, on en est à 2
bugs - 1 non respect de spécification et 1 erreur d'implémentation - soit,
selon toute vraisemblance 10 logiciels sans bug). Il y a en plus lieu de
noter que le point central de la démonstration ne concernait pas l'absence
de bug mais le comportement en présence de défaut matériel ou logiciel.
Ben justement ton exemple est bien la preuve qu'on ne peut exgiger
l'obligation de résultat pour du logiciel: même en mettant tous les
atouts de ton coté, il te reste deux bugs découverts en 12 ans.
C'est un excellent résultat, et l'obligation de moyen a été sans aucun
doute remplie, par contre si on avait ecrit obligation de zéro bugs au
départ tu n'aurais pas rempli l'obligation de résultat.
--
Emmanuel Dreyfus
Un bouquin en français sur BSD:
http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
manu@netbsd.org
Avec de tels moyens, un client impliqué sur les résultats, l'emploi de métriques judicieuses et d'outils de contrôle de complétude lors des test, on obtient de très bonnes garanties (par exemple, pour 12 logiciels travaillant en collaboration, après 12 ans d'exploitation, on en est à 2 bugs - 1 non respect de spécification et 1 erreur d'implémentation - soit, selon toute vraisemblance 10 logiciels sans bug). Il y a en plus lieu de noter que le point central de la démonstration ne concernait pas l'absence de bug mais le comportement en présence de défaut matériel ou logiciel.
Ben justement ton exemple est bien la preuve qu'on ne peut exgiger l'obligation de résultat pour du logiciel: même en mettant tous les atouts de ton coté, il te reste deux bugs découverts en 12 ans.
C'est un excellent résultat, et l'obligation de moyen a été sans aucun doute remplie, par contre si on avait ecrit obligation de zéro bugs au départ tu n'aurais pas rempli l'obligation de résultat.
-- Emmanuel Dreyfus Un bouquin en français sur BSD: http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
