Discussion :

[Amine Horseman]

Logiciel fiable, réalité ou utopie ?
Malgré la prolifération d’outils et méthodes pour éviter les bugs, pourquoi sont-ils toujours si présents ?

Avec la hausse du taux de machines infectées par des programmes malveillants à travers le monde et les fréquentes attaques cybercriminelles, qui ne cessent de se multiplier ces dernières années, il arrive un moment où on se demande ce qui ne va pas réellement avec la façon actuelle de procéder.

Le piratage informatique donne accès à des données sensibles et privées, c'est une manière de gagner de l'argent rapidement, de récupérer des données cachées, de montrer sa supériorité ou tout simplement de se faire une réputation dans le monde des hackers. Cependant, le piratage est aussi parfois une façon d'attirer l'attention sur la vulnérabilité de tel ou tel système qu'on croyait sécurisé.

Mais dans tous les cas, le piratage, qu'il soit bon ou mauvais, n'aurait pas pu atteindre une telle ampleur sans l'existence de failles de sécurité. Ces failles sont partout, que ce soit des bugs, des défauts, des erreurs ou tout type de faiblesse que les hackers pourraient utiliser pour pénétrer dans des systèmes auxquels ils n'ont pas accès normalement.

Les failles de sécurité sont tellement fréquentes, qu'il existe des outils pour les traquer ou les répertorier. Des budgets et des efforts colossaux sont mis en œuvre pour les détecter et les corriger rapidement. Toutefois, est-il possible de les prévoir à l'avance ?

La plupart des techniques utilisées aujourd'hui se basent soit sur des simulations de pénétration après avoir fini le développement du logiciel, soit sur des techniques de tests variées pendant la phase d'implémentation. Mais, est-il possible de les éviter avant même d'avoir commencé le codage ? Et pourquoi les méthodes actuelles de création de logiciels donnent naissance à des produits si peu fiables ?

[JayGr]

Hello,

Très bon sujet.
On ne peux pas fournir un système 100% fiable.
Que ce soit en développement ou en réseau, jamais un SI ne peut être complètement opaque.

Mais on peut prévenir et éviter un maximum de failles en sensibilisant et en formant les développeurs et les projets !!!
Soyons honnête, nombre de chefs de projet ou développeurs préfèrent éviter d'avoir à faire à la sécurité ("Ils vont encore nous péter le budget !!"). Alors sensibilisons ces gens pour qu'ils viennent d'eux mêmes se renseigner.

C'est pour moi la première étape d'un long travail... Après nous verrons ce qu'il faut changer dans le développement même. Commençons par une prise de conscience collective.

@+

[Max Lothaire]

En même temps; quand je vois/entends dire que, au niveau des tests unitaire, on peut se satisfaire d'une couverture de 80% du code; je m'étonne peu du nombre de bogues/failles que l'on peut trouver dans les logiciels

[spyserver]

Pour moi si on part d'un constat simple : les failles ne sont que des entrées/sorties indésirées au sein d'une application, d'un OS ou d'un réseau, on peut "en théorie" en connaissant parfaitement les entrées/sorties de l'appli que l'on code "maîtriser" la sécurité, sauf que le nombre d'I/O explose au sein des systèmes modernes à cause du nombre grandissant d'interfaces, de plateformes et de canaux de communications par lesquelles les applis sont accessibles. Par logique, on se retrouve donc avec une probabilité supérieure d'avoir des failles au sein d'une appli. Je pense qu'il y a des I/O explicites (champ,code JS,formulaire,port ouvert,etc) et implicites (NFC, interception de paquets, etc.), le tout étant de bien les identifier avant de concevoir le système. Comme dit plus haut, c'est davantage par pur soucis économique que l'aspect sécurité est sans cesse négliger au sein de l'IT, je pense que certains systèmes dits très sensibles peuvent tout à fait être correctement sécurisés, encore faut-il le vouloir ...

[transgohan]

En même temps; quand je vois/entends dire que, au niveau des tests unitaire, on peut se satisfaire d'une couverture de 80% du code; je m'étonne peu du nombre de bogues/failles que l'on peut trouver dans les logiciels

C'est parce que 80% c'est déjà énorme par rapport à la réalité...
Certains projets couvrent à peine 20% en TU.
(après faut bien comprendre que tout couvrir n'est pas forcement utile, mais de là à dire que seul 20% sont utiles il y a un cap)

Pour ma part cet article m'a fait penser à une phrase sortie un jour comme conclusion de comment améliorer la qualité : "Les développeurs ont qu'à développer sans introduire de bug."
Je vous fait pas le dessin des personnes réunis dans la salle, tous les développeurs ont failli perdre leurs yeux tandis que tous les managers approuvaient bêtement cette si sainte idée.

[Washmid]

J'ai mieux : 0% de test unitaire chez nous.

La dernière fois qu'on a essayé d'introduire cette notion on s'est fait rembarrer... Alors 20% de tests ce serait le rêve

Puis bon, pour écrire un test, il faut documenter ce qu'on teste, et certains collègues en sont encore à paraphraser le nom des méthodes, et on s'en fout des arguments "ça sert à rien de les décrire".

[tontonnux]

Le problème c'est que beaucoup de "failles" viennent de comportements (au sens large) qui n'avaient pas été envisagés.

Du coup, la question devient: "Peut-on envisager ce qu'on n'a pas envisagé ?".
Réponse: "Bah... non."

On peut envisager qu'il y aura des problèmes et mettre en place des process forts de détection et de gestion de ces problèmes.
Vouloir éviter les problème n'a donc aucun sens. En revanche, on peut toujours essayer de mieux les gérer.

[MikeRowSoft]

Après tous il existe plusieurs sorte de bogues et plusieurs raisons à ces bogues.

[lrinaldi]

Les failles de sécurité sont tellement fréquentes, qu'il existe des outils pour les traquer ou les répertorier. Des budgets et des efforts colossaux sont mis en œuvre pour les détecter et les corriger rapidement. Toutefois, est-il possible de les prévoir à l'avance ?

Dans les petites entreprises, en général il n'y a pas de temps ni de budget pour la sécurité.

La plupart des techniques utilisées aujourd'hui se basent soi sur des simulations de pénétration après avoir fini le développement du logiciel, soit sur des techniques de tests variées pendant la phase d'implémentation. Mais, est-il possible de les éviter avant même d'avoir commencé le codage ? Et pourquoi les méthodes actuelles de création de logiciels donnent naissance à des produits si peu fiables ?

Pour moi le problème réside dans l'utilisation à outrance des "solutions clé en main" de type CMS/ERP/... où le développeur ne voit pas ce qu'il se passe sur le système car soit il n'a pas accès aux sources parce que le système est fermé, soit il n'a pas de temps pour ça.
Sans compter les fois où le système une fois livré et déployé chez un client ne sera plus jamais mis à jour.

[frfancha]

C'est un choix global de société: un trux qui marche à 90 % à 1000 EUR est préféré à un truc qui marche à 100% à 1.000.000 EUR, c'est tout.
Et c'est sans doute le choix qui a le plus de sens dans certains cas.

[NSKis]

C'est un choix global de société: un trux qui marche à 90 % à 1000 EUR est préféré à un truc qui marche à 100% à 1.000.000 EUR, c'est tout.
Et c'est sans doute le choix qui a le plus de sens dans certains cas.

Je connais un client (une banque que l'on ne nommera pas ) qui a entièrement outsourcé son équipes de développement dans un pays à bas coûts ("outsourcé", c'est le petit mot qui signifie "on vire tous le monde et on fait faire le job par une boite externe qui paye ses développeurs 200 euro/mois")

Et qu'est-il arrivé? Une baisse de la qualité du logiciel

Ben m... alors, on aurait pu espérer qu'avec le genre de coût salarial, ils auraient les moyens de mettre des ressources pour tester leur code

[Pierre Louis Chevalier]

Ça existe pas des développeurs à 200 Eu / mois, même au Bangladesh.

Généralement un développeur offshore valable c'est au moins 800 Eu / mois.

[Carhiboux]

La triste réalité, c'est que très très peu de projets ont un véritable suivi de la qualité.

Et par qualité, j'entends pas mal de choses :

Des normes de codages, pour que Jacques et Michel écrivent un code qui se ressemble, qui respecte les mêmes standards.

Un cahier des charges fonctionnel figé et détaillé au moment de la rédaction des spécifications techniques.

Un cahier des charges technique qui prévoit tous les cas. C'est bête dit comme ça, mais de ce que j'ai pu voir, c'est pas si évident que cela pour tout le monde.

Définir les jeux de tests AVANT le développement. Selon moi, on devrait les écrire au moment où l'on rédige la spec technique. Le risque des les écrire après, c'est qu'on va écrire les tests en fonction de ce qu'on a codé, et non en fonction du besoin.

Du budget.

Des ressources compétentes. Les écoles préparent assez peu à la qualité. Autre que le blabla administratif et le collage de post-it, pas forcément inutile, mais qui en soit, ne garanti pas un code sur et propre.

Bref, comme toujours, on en revient à la nature de notre métier, et c'est encore plus vrai en SS2I : les développeurs sont là pour faire du gain, pas de la qualité. J'ai entendu des managers reprocher à leurs équipes de faire de la surqualité! C'est presque surréaliste.

Le jour où les décideurs voudront des logiciels de qualité, les choses changeront. Mais tant qu'ils veulent des produits pas cher... ils auront des produits pas cher. On en a toujours pour son argent. Jamais plus.

[Alcore]

C'est un choix global de société: un trux qui marche à 90 % à 1000 EUR est préféré à un truc qui marche à 100% à 1.000.000 EUR, c'est tout.
Et c'est sans doute le choix qui a le plus de sens dans certains cas.

Celà dépend du contexte. Pour une application d'envoi de mass mailling un truc qui marche à 90% sera sans doute suffisant.
Une de mes conaissance travaille pour Siemens et ils fabriquent des scanners IRM (machines qui coutent plusieurs dizaines de millions d'€ l'unité...).
Dans ce cas, c'est la vie de personnes qui est en jeu et donc ils ne travaillent que avec des sociétés certifiées CMMI niveau 5 pour la gestion du risque, la gestion de la qualité du code, etc... Un truc qui marche à 99,999% des cas est pour eux une nécessité.

Il est cependant faux de s'immaginer que celà coute forcément cher de faire de la qualité.
Quelques bonnes pratiques, la mise en places de bonnes couvertures de tests et éventuellement de tests d'intégration sont déjà un pas.

Dans le monde Java, des outils comme Sonar et Jenkins sont très abordables.
Si dans votre projet la mise en place d'une couverture de tests à 100% est trop compliquée, identifiez les fonctionnalités principales (celles qui géreront la majorité de vos cas d'utilisation) et blindez celles-ci.

[NSKis]

Ça existe pas des développeurs à 200 Eu / mois, même au Bangladesh.

Généralement un développeur offshore valable c'est au moins 800 Eu / mois.

Et bien, il va simplement falloir mettre à jour vos informations ainsi que vos tarifs

Lorsque l'on sort des chantiers battus, les prix sont très compétitifs!!! Et vous savez pas la meilleure? Même pas besoin de chercher, les offres vous arrivent sur le bureau sans avoir besoin de demander.

Et franchement parler d'un "développeur offshore valable"... VALABLE??? Vous croyez vraiment que c'est un argument pris en compte par un gars qui gère les coûts de l'entreprise à l'aide d'un tableau Excel?

Sachez, cher Monsieur, que lorsque l'on est un décideur, on commence par outsourcer avec des guignols à 200 euro/mois... C'est plusieurs mois après que l'on se rend compte de la différence entre un développeur valable et un non-valable...

[Pierre Louis Chevalier]

Je suis à jour, et j'ai bien précisé 'Valable" ce qui est une précision d'importance.
200 Eu / mois c'est pas un tarif c'est une escroquerie, pour ce prix rien d'utile ne sera développé, et le gogo "client" va payer pour rien
L'escroquerie la plus courante c'est de tricher sur le nombre d'heures réelles, faute de contrôle efficace, donc si le prestataire escroc déclare 4 fois plus que le nombre d'heure réelles on arrive bien à 200 * 4 = 800 Eu.
Si tu reçois un spam pour une offre de travail à domicile pour sois disant 10 000 Eu par mois, est ce que pour autant tu en conclu que toutes les secrétaires à domicile gagnent 10 000 EU par mois ?
Il ne faut pas confondre email de spammeurs escroc et vrai tarif du marché.

[Shepard]

Vous connaissez Coq ? :p

C'est un langage de programmation qui permet de vérifier des théorèmes sur des fonctions, et les fonctions en question peuvent être exportées en OCaml/Haskell.

On est sûr à 100% que les théorèmes prouvés sur ces fonctions sont vérifiés dans les codes OCaml/Haskell correspondants (autrement dit, pas de bug)

Le problème consiste à savoir ce qu'il faut prouver, le fait que faire les preuves est long et fastidieux, d'ailleurs je ne suis pas sûr que ce soit toujours possible ...

L'idée c'est que peut-être que dans quelques années, on trouvera peut-être des compilateurs qui vérifient des propriétés essentielles des programmes grâce à ce genre de langages, et que l'on pourra assurer la fiabilité des programmes de manière simple et automatisée ( d'accord, je suis utopiste :-) )

My 2 cents, comme dirait l'autre ...

[thelvin]

On est sûr à 100% que les théorèmes prouvés sur ces fonctions sont vérifiés dans les codes OCaml/Haskell correspondants (autrement dit, pas de bug)

En même temps... Référence XKCD obligatoire

- Du code écrit en Haskell est garanti sans effet de bord.
- ... Parce que personne n'essaiera jamais de le lancer ?

[AoCannaille]

Vous connaissez Coq ? :p

C'est un langage de programmation qui permet de vérifier des théorèmes sur des fonctions, et les fonctions en question peuvent être exportées en OCaml/Haskell.

On est sûr à 100% que les théorèmes prouvés sur ces fonctions sont vérifiés dans les codes OCaml/Haskell correspondants (autrement dit, pas de bug)

Le problème consiste à savoir ce qu'il faut prouver, le fait que faire les preuves est long et fastidieux, d'ailleurs je ne suis pas sûr que ce soit toujours possible ...

L'idée c'est que peut-être que dans quelques années, on trouvera peut-être des compilateurs qui vérifient des propriétés essentielles des programmes grâce à ce genre de langages, et que l'on pourra assurer la fiabilité des programmes de manière simple et automatisée ( d'accord, je suis utopiste :-) )

My 2 cents, comme dirait l'autre ...

AH cool!merci de l'info!

En cours on nous a fait l'apologie de l'OCL (Object Constraint Language) qui est un sous ensemble de l'UML et qui décrit donc une sorte de langage Coq : on décrit des préconditions et post conditions et on vérifie si la fonction testée les respecte.
Tu dit que faire les preuves est long et fastidieux, imagine sur papier à coup d'inéquations... je me suis toujours dit que si l'OCL se compilait ça permettrait d'automatiser de façon propre et à l'étape de la conception les tests.

Mais bon, ça ne réglera pas le problème du budget des tests, ça "normalise" plutôt entre les boites les techniques de tests, un peu comme l'a fait JUnit en Java, mais pour potentiellement tous les langages.

[coolspot]

Outre le fait qu'un logiciel sans bug ca n'existe pas. Il y a en amont un problème politique qui fait que pour les "décideurs" de l'entreprise. L'informatique est un cout trop important pour l'entreprise et par conséquent tout ce qui concerne l'informatique doit être le moins cher possible.
Rajouter à ca que les developpeurs sont considérés comme des autiste handicapé qu'il faut payer au salaire des indiens n'aide pas à produire de la qualité ce qui est tout à fait normal je vois pas en quoi on devrait produire des logiciel de qualité si on est pas payé en conséquence.

Bref il veulent du pas cher et c'est ce qu'ils ont. Mais faut pas venir pleurer que ca bug de partout après. Donner plus de temps et augmenter les salaires des développeurs si vous voulez des logiciels de qualités avec le moins de bug possible.

Car comme dit le dicton : "wHEN YOU PAY PEANUTS, YOU GET MONKEY"