Les erreurs de logiciels, le plus cher feu d'artifice de tous les temps, par Klaus Lambertz

Bonjour,

D'après l'auteur de cet article, Klaus Lambertz,

Citation:

---

En Europe, grâce aux logiciels de tests nous pourrions économiser plus de 100 milliards d'euros par an.

---

Revenant sur quelques cas grandeur nature de pertes colossales induites par des erreurs logicielles, l'auteur insiste sur l'intérêt des tests et en présente brièvement les différentes variantes.

Avez-vous en tête d'autres faits marquants pour lesquelles une erreur logicielle a coûté énormément d'argent à une ou plusieurs société, voire a mis en faillite l'une d'elle ?
Cet article vous convainc-t-il qu'il existe un Retour sur investissement à appliquer une stratégie qualité passant par les tests ?

J'ai vécu une situation semblable. Mais, tout le monde était un peu responsable. Quand il y a des bugs dans le logiciel, c'est un prétexte pour le client de ne pas payer, pour les salariés que "c'est la faute à l'informatique", pour les informaticiens que "les utilisateurs ne savent pas ce qu'ils veulent", pour les responsables que "les informaticiens ne sont pas bon ou que les commerciaux leur ont conseillé un mauvais outils, blablabla". La politique de la patate chaude qui est envoyée de l'un à l'autre. Et quand ça marche trop bien, alors on vire du personnel, ça s'appelle de la gestion !

Ensuite, il faut voir quel secteur est touché. Pour avoir un peu regardé les articles sur ariane 5 entre autre, il faut relativiser. Dans un monde où le profit est la priorité des priorités, il ne faut pas non plus s'étonner. En plus l'erreur est humaine, personne n'est parfait.
Avoir des outils de test, c'est bien beau, encore faut-il savoir quoi tester, autrement dit anticiper les erreurs.

Et puis c'est comme Tchernobyl, tant qu'il n'y a pas de catastrophes les humains ne comprennent pas, pire ils récidivent quelques temps après.

Les gens réagissent quand il y a des vrais responsables, mais tant qu'ils pourront se renvoyer la balle les uns les autres, ce seront toujours ceux qui seront au bas de l'échelle qui sauteront en premier. De temps en temps on fait sauter celui qui est tout en haut histoire de donner l'exemple, mais ça ne résout pas le problème à la base.

Les répercutions sont les mêmes dans tous les domaines, mais que l'informatique.

Une faiblesse dans le process d'un abattoir peut intoxiquer toute une région.
Une faiblesse mécanique dans une voiture peut avoir les mêmes conséquences qu'une imperfection électronique.
Une installation électrique foireuse peu foutre le feu à une habitation.
Etc.

Donc je pense que ce n'est pas spécifique à l'informatique, et que les conséquences ne sont pas nouvelles.

Je pense aussi que le plus gros coût du manque de qualité se situe dans la réputation de l'entreprise qu'elle engendre.

Cet article ressemble de mon point de vue à une plaquette publicitaire, et ne presente pas beaucoup d'interet, à la fois dans les faits décrits et dans les chiffres présentés.

Il y a deux choses à savoir :
* un logiciel (ou toute démarche d'ailleurs, informatique ou pas) ne sera jamais 100% sécurisé : le monde change, on ne connait pas tout...
* la qualité se paye : les appels d'offres permettent de faire descendre les prix mais il faut savoir que cette baisse des prix n'est pas magique

Les mêmes problèmes existent dans la construction, où l'on retrouve également MOA, MOE et appels d'offres.

Bonsoir

Citation:

---

Envoyé par TabrisLeFol

Cet article ressemble de mon point de vue à une plaquette publicitaire, et ne presente pas beaucoup d'interet, à la fois dans les faits décrits et dans les chiffres présentés.

---

C'est une plaquette publicitaire, mais utile !

Dans un coin de notre esprit on le savait déjà, mais un rappel de temps en temps est loin d'être inutile, il y a des faits importants qui méritent d'être rappelé sans cesse.

Citation:

---

Envoyé par TabrisLeFol

Il y a deux choses à savoir :
* un logiciel (ou toute démarche d'ailleurs, informatique ou pas) ne sera jamais 100% sécurisé : le monde change, on ne connait pas tout...

L

---

Oui nous savons très bien qu'un logiciel ne sera pas parfait à 100%, mais ce n'est pas pour cette raison que nous devons pas essayer.

Bon, pour atténuer ce que j'ai dit au départ en commentaire, à propos du vrai sujet du thread :

Citation:

---

Envoyé par Ricky81

Cet article vous convainc-t-il qu'il existe un Retour sur investissement à appliquer une stratégie qualité passant par les tests ?

---

La réponse est : bien entendu, il faut avoir une stratégie qualité passant par des tests. Les tests sont extrêmement importants..

C'était déjà le cas dans le WaterFall..


La seule chose à modiifier, de mon point de vue, c'est que les tests dits "unitaires" sont dans l'écrasante majorité des cas non appropriés et une perte de temps (surtout dans une approche entièrement documentée), mais que par contre les tests dits "fonctionnels" ou "de système" sont vitaux, et ce durant toute la phase de développement..

C'est ce que j'entend toujours par "approche agile" ou "user-centered".. Les tests doivent être permanents (plusieurs fois par jour) par les développeurs, et souvent (au minimum une fois par semaine) par les utilisateurs.. (pas des "testeurs" techniques, des vrais utilisateurs).


Les tests "fonctionnels" doivent être au fur et à mesure du développement de la fonctionalité, AVEC un/des utilisateur(s).

Les tests "systèmes" doivent être au fur et à mesure de l'inclusion des fonctionalités, AVEC un/des utilisateur(s).


Les tests "unitaires" sont plus à mon avis couverts par un processus (possiblement automatique, mais pas obligatoirement) sur des données de tests fournies par les utilisateurs , en leur faisant cracher les cas extrêmes...

Et la plupart sont visibles lors des tests "fonctionnels".



C'est un peu ce que je veux dire par rapport aux "méthodologies" : la formalisation de tests unitaires systématiques est un poids gigantesque, et du coup une possibilité plus que non négligeable d'introduction d'erreurs : pas par le fait que telle ou telle fonction remplisse le test, mais simplement par le nombre... et le travail répétitif requis..

Etablir des documents et des procèdures normées pour établir qu'une fonction de 3 lignes qui fait "A+B" correspond à son schéma de test est absurde et contre-productif..

Le simple nombre de telles choses provoque chez les développeurs un "automatisme" qui dilue l'attention, et donc diminue l'acuité lors de fonctions plus complexes..



Le temps perdu à ça pourrait être consacré avec beaucoup plus de retombées aux tests fonctionnels , qui feraient par là-même ressortir également les erreurs relevées dans les "unitaires"...

Et à mon avis cela améliorerait grandement la robustesse...



Bon, en ce qui concerne le bouquin, ce n'est jamais mauvais de rappeler ceci, mais bon, ça m'a effectivement plus l'air d'être de la pub qu'autre chose..