IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Sécurité Discussion :

Logiciel fiable, réalité ou utopie ?


Sujet :

Sécurité

  1. #21
    Expert éminent sénior

    Homme Profil pro
    Directeur des systèmes d'information
    Inscrit en
    Avril 2002
    Messages
    2 789
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 63
    Localisation : Luxembourg

    Informations professionnelles :
    Activité : Directeur des systèmes d'information
    Secteur : Finance

    Informations forums :
    Inscription : Avril 2002
    Messages : 2 789
    Points : 18 930
    Points
    18 930
    Par défaut
    Citation Envoyé par coolspot Voir le message
    Car comme dit le dicton : "wHEN YOU PAY PEANUTS, YOU GET MONKEY"
    C'est ça

    En fait déjà que même en payant bien, souvent on te livre de la M..., alors en payant mal on peu tout imaginer.
    Les bons développeurs sont rares et chers, qu'on se le dise...
    Ne prenez pas la vie au sérieux, vous n'en sortirez pas vivant ...

  2. #22
    Expert confirmé Avatar de DonQuiche
    Inscrit en
    Septembre 2010
    Messages
    2 741
    Détails du profil
    Informations forums :
    Inscription : Septembre 2010
    Messages : 2 741
    Points : 5 485
    Points
    5 485
    Par défaut
    Si on parle de bogues en général, les prévenir est très difficile et coûteux, sans solution bien arrêtée. Au mieux on dispose de nombreuses bonnes pratiques et d'outils mais à moins d'y mettre vraiment le prix ça reste limité. Et même en y mettant le prix on ne fait pas de miracles.

    Si on revanche on parle de failles de sécurité alors on peut déjà en supprimer 90% rien qu'en abandonnant des langages bas-niveau comme le C++ (la vérification des bornes des tableaux, c'est le bien). Et je soupçonne qu'on pourrait encore diviser par dix en collant sur chaque moniteur un post-it "entrées utilisateurs == danger".

  3. #23
    Membre confirmé Avatar de Max Lothaire
    Homme Profil pro
    Étudiant
    Inscrit en
    Mai 2014
    Messages
    155
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : France, Moselle (Lorraine)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Mai 2014
    Messages : 155
    Points : 578
    Points
    578
    Par défaut
    Citation Envoyé par DonQuiche Voir le message
    Si on revanche on parle de failles de sécurité alors on peut déjà en supprimer 90% rien qu'en abandonnant des langages bas-niveau comme le C++ (la vérification des bornes des tableaux, c'est le bien).
    J'aimerais bien voir un OS ou une SGBD programmé en JAVA.
    Ça serait rigolo.

    Plus sérieusement, l'abandon d'un tel langage semble peu envisageable.

  4. #24
    En attente de confirmation mail
    Femme Profil pro
    pape n'aimant pas les censeurs
    Inscrit en
    Janvier 2010
    Messages
    803
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : Vatican

    Informations professionnelles :
    Activité : pape n'aimant pas les censeurs

    Informations forums :
    Inscription : Janvier 2010
    Messages : 803
    Points : 1 407
    Points
    1 407
    Par défaut
    Citation Envoyé par Pierre Louis Chevalier Voir le message
    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é.
    Nous sommes bien d'accord.

    Mais vous faites une erreur en surestimant le décideur, il y a plus de "gogo" dans les entreprises que vous ne semblez croire

    Et tout spécialement avec l'informatique en générale, un domaine dont le décideur ne connait bien souvent qu'une chose: C'est un centre de coùts trop élevé à diminuer par n'importe quel moyen.

    D'autre part, les "spammeurs escroc" ont fait leur temps, il y a maintenant du démarchage réel dans les entreprises pour proposer du service "low low low cost"

  5. #25
    Expert éminent sénior

    Homme Profil pro
    Directeur des systèmes d'information
    Inscrit en
    Avril 2002
    Messages
    2 789
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 63
    Localisation : Luxembourg

    Informations professionnelles :
    Activité : Directeur des systèmes d'information
    Secteur : Finance

    Informations forums :
    Inscription : Avril 2002
    Messages : 2 789
    Points : 18 930
    Points
    18 930
    Par défaut
    Citation Envoyé par NSKis Voir le message
    Nous sommes bien d'accord.
    Mais vous faites une erreur en surestimant le décideur, il y a plus de "gogo" dans les entreprises que vous ne semblez croire
    "
    Oui je suis au courant, au départ quelqu'un peu se faire avoir, mais après soit il trouve une solution pour réussir à faire développer ses applis ou gérer son informatique, soit il saute, parce que lui même doit rendre des comptes à son Directeur/Patron/Gérant/PDG/Board of directors/ Client/Propriétaire/actionnaire/investigateurs/ etc.
    Après vu le nombre colossal de dépôts de bilan tous les ans et bien oui tous le monde y arrive pas, il y à un processus de "sélection"...
    Ne prenez pas la vie au sérieux, vous n'en sortirez pas vivant ...

  6. #26
    Rédacteur
    Avatar de pcaboche
    Homme Profil pro
    Inscrit en
    Octobre 2005
    Messages
    2 785
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : Singapour

    Informations forums :
    Inscription : Octobre 2005
    Messages : 2 785
    Points : 9 716
    Points
    9 716
    Par défaut
    Citation Envoyé par DonQuiche Voir le message
    Si on revanche on parle de failles de sécurité alors on peut déjà en supprimer 90% rien qu'en abandonnant des langages bas-niveau comme le C++
    Citation Envoyé par Max Lothaire Voir le message
    J'aimerais bien voir un OS ou une SGBD programmé en JAVA.
    Faux et faux.

    La plupart des gros problèmes logiciels (ceux qui sont durs à détecter) sont liés à des effets de bord en tous genres :
    - accès mémoire (ex : heartbleed, dépassements de capacité)
    - problèmes de synchro entre processus concurrents (souvent très durs à reproduire et à résoudre)
    - overflow
    - etc.

    Bref C++, Java ou autre, même combat : plus il y a d'effets de bord possibles, plus il y a risque de bugs (c'est juste que plus c'est bas niveau, plus il y a de risques d'effets de bords, mais Java n'en est pas exempt).


    Pour pallier à ce problème, la réponse généralement acceptée en entreprise, c'est : "on n'a qu'à faire plus de tests" (je connais des gens qui ont quasiment fait carrière juste avec cette phrase).

    Cependant, il y a de nombreux problèmes avec les tests :
    - on n'est jamais sûr de leur couverture
    (pour pouvoir tester quelque chose, il faut déjà pouvoir envisager le scénario, comme dans le cas de Heartbleed par exemple)

    - c'est parfois difficile à reproduire
    (ex: ordonancement d'instructions en cas d'exécution concurrente, comme dans le cas du multi-threading)

    - plus le code est long/complexe, plus il y a de cas à tester.
    Le nombre de cas à tester peut potentiellement augmenter de manière quadratique, voire exponentielle (un peu comme la notation grand O pour mesurer la complexité d'un algorithme, mais appliquée au nombre de cas de tests en fonction du nombre de branches d'instructions. J'appelle ça "la notation grand T")


    Certains tentent de résoudre le problème de qualité avec des outils plus poussés (outils d'analyse statique de code, preuves formelles...) mais bon, tant qu'on restera avec des langages qui, par nature, introduisent autant d'effets de bord (en gros, la grande famille des langages impératifs) c'est plus ou moins peine perdue.

    Malheureusement, on n'a pas encore inventé de langage déclaratif à la fois performant et suffisamment puissant pour faire de l'introspection sur la qualité du code (et même si c'était le cas, les gens s'en détourneraient parce que "oh, c'est trop compliqué, ça ressemble pas à un langage que je connais déjà" ) donc on continue sur notre lancée, avec des problèmes de plus en plus difficile à résoudre, et vu que "ça coûte cher" (tout est relatif, il y a pas mal de "décideurs"qui sont loins d'apporter la même valeur ajoutée) alors on outsource dans des pays à bas coûts où on produit de la m**** en très grande quantité.

    Citation Envoyé par DonQuiche Voir le message
    Et pourquoi les méthodes actuelles de création de logiciels donnent naissance à des produits si peu fiables ?
    Relire tout ce que je vient de dire.
    "On en a vu poser les armes avant de se tirer une balle dans le pied..."
    -- pydévelop

    Derniers articles:

    (SQL Server) Introduction à la gestion des droits
    (UML) Souplesse et modularité grâce aux Design Patterns
    (UML) Le Pattern Etat
    Autres articles...

  7. #27
    Expert éminent

    Avatar de deusyss
    Homme Profil pro
    Expert Python
    Inscrit en
    Mars 2010
    Messages
    1 659
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : Expert Python
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mars 2010
    Messages : 1 659
    Points : 8 442
    Points
    8 442
    Par défaut
    Citation Envoyé par coolspot Voir le message
    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.
    Tu ne crois pas si bien dire. J'ai travaillé pour un gros groupe industriel. Dans sa mentalité (et dans beaucoup d'autres boites malheureusement), la direction considérait l'informatique comme un centre de cout. Et pourtant si leur informatique s'arrêtait, tout plantait.

    Leur matos? Un serveur "survivant" de 1979 avec 2GO de HDD et un soft maison de 25 ans avec des langages maisons, codés par des responsables d'usines. C'est cousus de bugs, ça plantent toutes les 5 mn. Bref, le contre exemple de la fiabilité, mais la direction considère que ça tourne comme ça depuis longtemps donc faut pas y toucher.

    Il serait temps que les directions dans cette mentalité se sortent un peu la tête et regarde la réalité. Dans le monde d'aujourd'hui, sans informatique, qui plus est fiable, aucune société ne peux plus avancer.
    "La connaissance appartient à tout le monde" (Film Antitrust)

    Tout le nécessaire pour Python:
    *News/Accueil *Cours/tutoriels *FAQ
    *Forums *Outils dédiés *Mon espace personnel avec mes Articles, Cours et Tutoriels

  8. #28
    Membre chevronné
    Avatar de free07
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Mars 2005
    Messages
    930
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Ardèche (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mars 2005
    Messages : 930
    Points : 1 959
    Points
    1 959
    Par défaut
    Citation Envoyé par Pierre Louis Chevalier Voir le message
    Ç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.
    Je confirme, 800 Eu / mois c'est vraiment un minimum, de ce que j'ai vu dernièrement, le cout d'un developpeur offshore est entre 10 $US et 30 $US de l'heure selon l'experience et les compétences recherchés.

  9. #29
    Membre actif
    Inscrit en
    Mai 2006
    Messages
    140
    Détails du profil
    Informations forums :
    Inscription : Mai 2006
    Messages : 140
    Points : 233
    Points
    233
    Par défaut
    Je suis vraiment surpris de lire dans ce sujet des personnes qui travaillent dans des sociétés où on leur demande de ne pas tout couvrir en TU.

    Je m'efforce toujours de tout couvrir dans l'ensemble des cas, même si cela implique en conséquence de passer plus de temps à faire des tests unitaires qu'à coder le programme à proprement parler. J'arrive quand même à développer confortablement en dessous de la matrice de la société cliente et de ne pas avoir rencontré de plantage en production lors de mes livraisons. Intervenant en tant que TMA pour une banque, je commence à comprendre pourquoi je récupère de temps en temps des projets en prod qui ne semblent pas terminés.

  10. #30
    Membre extrêmement actif
    Avatar de Aurelien Plazzotta
    Homme Profil pro
    .
    Inscrit en
    Juillet 2006
    Messages
    312
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : .

    Informations forums :
    Inscription : Juillet 2006
    Messages : 312
    Points : 934
    Points
    934
    Par défaut
    Hello,

    Ce débat est très lié au système de rémunération des chefs de projets, proposé il y a quelques mois. Je subodore que les primes versées à ces memes chefs de projets les pousse à accepter tout et n'importe quoi auprès des clients. Les équipes de dév accumulent des dettes techniques incluant les tests, la sécurisation, la refactorisation et l'optimisation qui ne sont pas facturées et donc jugées inutiles ou du moins optionnelles à traiter.

    Comme dit plus haut, la qualité du soft diminue et entraine une augmentation des surfaces d'attaques.
    Cela peut paraitre anodin et déconnecté du sujet mais selon moi, c'est bel et bien la part de rémunération variable des décideurs de projets informatiques qui les encourage à dire "Amen" aux clients à tout bout de champ, même quand les délais de livraison sont intenables.
    Je porte l'épée brisée, et sépare les vrais rois des tyrans. Qui suis-je ?

  11. #31
    En attente de confirmation mail
    Femme Profil pro
    pape n'aimant pas les censeurs
    Inscrit en
    Janvier 2010
    Messages
    803
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : Vatican

    Informations professionnelles :
    Activité : pape n'aimant pas les censeurs

    Informations forums :
    Inscription : Janvier 2010
    Messages : 803
    Points : 1 407
    Points
    1 407
    Par défaut
    Citation Envoyé par free07 Voir le message
    ... le cout d'un developpeur offshore est entre 10 $US et 30 $US de l'heure selon l'experience et les compétences recherchés.
    Vous oubliez dans votre estimation le coût nécessaire en local pour au final avoir un système qui fonctionne vraiment

    Histoire classique constatée sur le terrain:

    1. Une société "bien de chez nous" avec un staff de 10 développeurs les licencient pour les remplacer par une équipe outsourcée au ... Vietnam

    2. Après moins de 1 an, tous les développeurs vietnamiens avaient changé (ben oui, ils ne sont pas plus bêtes que d'autres, ils ont changé de job pour gagner plus!)

    3. La société "bien de chez nous" se rend compte qu'elle doit gérer ses "vietnamiens" de manière plus serrées en créant de "petits projets" faciles à réaliser avant que le développeur ne prenne les ailes

    4. Au final, la société "bien de chez nous" se retrouve avec un staff de 10 personnes en Europe pour coordonner le job des développeurs outsourcés

    Bingo!!!!!!!!!

  12. #32
    Membre chevronné
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Juillet 2007
    Messages
    884
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : Juillet 2007
    Messages : 884
    Points : 2 018
    Points
    2 018
    Par défaut
    Surtout on oublie de dire que les logiciels sont beaucoup plus sur qu'il y a 10,20 ou 30 ans car ils ont été sans cesse renforcés, car on utilise des solutions éprouvé (Open-source ou en place depuis très longtemps) . Mais le problème c'est que l'on est dans une course : une course pour améliorer le SI pour le rendre toujours plus performant, plus intelligent et une course contre les hacker.
    Aujourd'hui le premier point faible est avant tout l'utilisateurs final. Pour prendre une image, imaginez une voiture dont le moteur lâche parce que le propriétaire a rajouté un turbo. Tout le travail des hackers aujourd'hui est de convaincre un utilisateur au moins d'ajouter un turbo. Et effectivement la plupart des attaques de hacker utilisent soit des logiciels de type "cheval de troie", soit du spam... autrement dit du social engineering.

    Seul les agences gouvernemental ont les moyens de faire du vrai hacking (découverte de failles 0-day, création de virus...) alors que dans les années 70 n'importe qu'elle bidouilleur intelligent y arrivait.

    Un hacker isolé ne peut qu'acheter au marché noir un réseau de PC zombi pour faire une attaque DDOS... de moins en moins efficace. S'il veut après acheter une faille 0-day et bien d'autres choses il lui faudra un budget en millions d'euros pour faire une attaque complète...
    Tout ce que j'écris est libre de droits (Licence CC0) et je vous incite à faire de même.

  13. #33
    Membre à l'essai
    Homme Profil pro
    Étudiant
    Inscrit en
    Juillet 2009
    Messages
    9
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Juillet 2009
    Messages : 9
    Points : 15
    Points
    15
    Par défaut
    Mon petit grain de sable dans cette discussion ...

    Je pense qu'il faut faire attention à ne pas confondre sûreté et sécurité, i.e. bugs et failles de sécurité.
    Les logiciels fiables (en terme de sûreté) existent, ils sont développés à l'aide des méthodes formelles et peuvent garantir une absence totale de bugs et une correction totale par rapport à la spécification. Comme exemple : Méthode B, model-checking, preuve de programme, ou analyse statique en générale ..

    Le problème : ça demande beaucoup de ressource et de compétence, et donc ça coûte cher ... (mais c'est un sujet passionnant !)

    Sinon, pour augmenter très fortement la fiabilité sans forcément utiliser des méthodes formelles, il existe d'autre truc. Par exemple, développer avec des langages à typage statique et fort (langages fonctionnels comme OCaml ou Haskell entre autres).

    Par contre pour la sécurité des SI contre des attaques extérieurs, c'est un autre sujet. Et là, l'erreur est plus souvent humaine que logiciel ...

    see you

  14. #34
    Membre confirmé Avatar de KsassPeuk
    Homme Profil pro
    Ingénieur Chercheur
    Inscrit en
    Juillet 2013
    Messages
    138
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur Chercheur
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Juillet 2013
    Messages : 138
    Points : 635
    Points
    635
    Par défaut
    Lu'!
    Citation Envoyé par JayGr Voir le message
    On ne peux pas fournir un système 100% fiable.
    Je vais d'abord revenir sur ce point.
    Non, on ne peut pas avoir une certitude à 100%. En revanche, pour le critique on sait assurer du 99.9% de certitude ... Par rapport à une spécification donnée.
    On appelle ça les méthodes formelles. Et on sait déjà les appliquer sur des projets de taille raisonnable (CompCert, seL4, ...).

    Le(s) problème(s) après, c'est
    • est qu'on est capable d'écrire la spécification ?
    • est ce que ça vaut le coût ?
    • est ce que les couches sur lesquelles on se base assurent au moins aussi bien ?


    Pour la première question, c'est déjà pas évident. Pour faire de la vérification formelle, on a besoin de specs ... formelles. Cela veut dire apprendre un formalisme aux personnes qui conçoivent. Or ces formalismes ne sont pas simples à prendre en main, encore moins à maîtriser. Et ça, sans compter le fait qu'on peut se gourrer dans la spécification et laisser un joli trou dedans. On peut aussi faire des spécifications trop fortes et (de fait) ne pas réussir à prouver que l'implémentation est valide parce qu'on n'autorise pas assez de cas. Bref, c'est pas simple.

    Pour la deuxième question, encore une fois, ça va dépendre des décideurs. Vérifier qu'un micro-noyau à destination d'un hyperviseur pour la Cloud est valide, ça vaut le coût parce qu'il va avoir une tâche très critique. Vérifier formellement que dans l'interface graphique web l'utilisateur verra bien un logo bleu, clairement non. Vérifier formellement le distributed file-system ? Aaaaaah, ça commence à être un peu différent : vérifier formellement que l'utilisateur n'aura accès qu'à ses fichiers, ça peut être cohérent ; vérifier formellement qu'on fait suffisamment de réplications ? ça induit de la probabilité, ça veut dire quoi suffisamment ? Etc. Et même là, tout le monde ne peut pas se permettre ce genre de travaux, pour exemple seL4 et ses 10000 lignes de code c'est de l'ordre de 700$ par ligne de code.

    Pour la troisième question, je dirais que c'est la plus cruciale. On ne peut pas imaginer créer un FileSystem parfaitement sûr par dessus un micro-noyau tout pourri de bugs. Plus encore, on ne peut pas assurer qu'un système va tenir ses engagements si un autre système avec plus de droits que lui est susceptible d'aller taper comme un malpropre dans ses données.

    Les projets qui se mesurent en millions de lignes de code, c'est de plus en plus répandu. Une erreur assez communes est de ne pas assez les modulariser, cela dit, ce n'est pas toujours facile : un logiciel commence petit, puis gonfle progressivement, jusqu'à un point où l'on se dit "merde, ç'aurait été pas mal de faire un module pour ça et ça", sauf que trop tard, parce que le faire maintenant nécessiterait trop de travail. Un code avec des modules clairement définis est plus facile à spécifier et vérifier.

    Finalement un exemple pour illustrer la difficulté. Si on se place dans une optique deuxième question + troisième question et dans le cas des OS, ben force est de constater qu'actuellement c'est peine perdu. Typiquement Linux : on a pleins de modules qui sont définis (très bien). Problème : c'est des millions de ligne de code donc on peut difficilement tout vérifier. Ok, soyons sélectifs, ne vérifions que le plus critique. Problème : tout ce beau monde s'exécute en espace privilégié, donc tout le monde a le pouvoir de tuer tout le monde. On se retrouve avec deux optiques : tout vérifier (20 millions de lignes de code, bon courage) ou reprendre la conception pour avoir la possibilité de vérifier les éléments de manière séparée (approche des micro-noyaux).

    Bref, on peut donner des assurances extrêmement fortes qu'un code ne contient pas de bugs par rapport à une spécification donnée. Mais, c'est cher et ça demande des personnes avec des compétences élevées et rares.

  15. #35
    Membre chevronné
    Avatar de free07
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Mars 2005
    Messages
    930
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Ardèche (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mars 2005
    Messages : 930
    Points : 1 959
    Points
    1 959
    Par défaut
    Citation Envoyé par NSKis Voir le message
    Vous oubliez dans votre estimation le coût nécessaire en local pour au final avoir un système qui fonctionne vraiment

    Histoire classique constatée sur le terrain:

    1. Une société "bien de chez nous" avec un staff de 10 développeurs les licencient pour les remplacer par une équipe outsourcée au ... Vietnam

    2. Après moins de 1 an, l'ensemble des développeurs vietnamiens avaient changés (ben oui, ils ne sont pas plus bêtes que d'autres, ils ont changé de job pour gagner plus!)

    3. La société "bien de chez nous" se rend compte qu'elle doit gérer ses "vietnamiens" de manière plus serrées en créant de "petits projets" faciles à réaliser avant que le développeur prennent les ailes

    4. Au final, la société "bien de chez nous" se retrouvent avec un staff de 10 personnes en Europe pour coordonner le job des développeurs outsourcé

    Bingo!!!!!!!!!
    Bien sûr, je ne parlais que du coût offshore, il est certain que cela ne reflête pas le cout global d'un projet.

  16. #36
    Expert confirmé Avatar de DonQuiche
    Inscrit en
    Septembre 2010
    Messages
    2 741
    Détails du profil
    Informations forums :
    Inscription : Septembre 2010
    Messages : 2 741
    Points : 5 485
    Points
    5 485
    Par défaut
    Citation Envoyé par pcaboche Voir le message
    Faux et faux.

    La plupart des gros problèmes logiciels (ceux qui sont durs à détecter) sont liés à des effets de bord en tous genres :
    - accès mémoire (ex : heartbleed, dépassements de capacité)
    - problèmes de synchro entre processus concurrents (souvent très durs à reproduire et à résoudre)
    - overflow
    - etc.
    Je n'ai pas parlé des problèmes logiciels en général, j'ai expressément restreint mon propos aux failles de sécurité. Et les buffer overflows sur des tableaux (le cas typique) sont bel et bien impossibles avec des langages de plus haut niveau.

    Citation Envoyé par Max Lothaire Voir le message
    J'aimerais bien voir un OS ou une SGBD programmé en JAVA. Ça serait rigolo.
    Il n'y a pas que Java ou C# dans la vie : Swift, Go ou M#, entre autres, sont justement conçus pour écrire du code système ; ils sont de moins haut niveau que Java ou C# (pas de GC) mais vérifient les limites des tableaux sur chaque accès, promeuvent la séparation stricte des pages de code et de données, interdisent l'arithmétique de pointeurs et certains exposent des mécanismes de concurrence dont le compilateur peut prouver qu'ils ne causeront pas de deadlock. L'impact sur les performances n'est certes pas nul mais il est faible : le surpoids peut souvent être éliminé le compilateur après preuve d'inoffensivité et les conditions introduites sont supposées toujours réussir - sauf bogue du programme - donc pas de rollback du pipeline.

    Certains tentent de résoudre le problème de qualité avec des outils plus poussés (outils d'analyse statique de code, preuves formelles...) mais bon, tant qu'on restera avec des langages qui, par nature, introduisent autant d'effets de bord (en gros, la grande famille des langages impératifs) c'est plus ou moins peine perdue.
    J'aimerais voir une preuve que les effets de bord rendent infaisable l'analyse. Ce qui à ma connaissance rend infaisable l'analyse ce sont des choses comme l'arithmétique de pointeur, les assignations par introspection (reflection), la génération dynamique de code, etc. Pour le reste je veux bien croire que la multiplication des assignations augmentent la taille du problème et donc le temps de calcul mais je doute qu'en 2014 ce soit infaisable, d'autant que le problème est faisable sur GPU (EigenCFA).

    Citation Envoyé par AoCannaille Voir le message
    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.
    Ca ne résoudrait pas le problème : un bogue découle d'erreurs inattention, d'incompréhensions du problème, de défaut de prédiction, etc. Ces erreurs apparaîtraient simplement dans tes contraintes plutôt que dans ton code. Ce serait quand même un progrès : des contraintes déclaratives claires sont plus lisibles et sans doute moins sujette à des bogues que nos langages impératifs.

    Cela dit l'idée même de Coq, des tests unitaires, des pré- et post-conditions, etc, c'est la redondance. Tu écris un code pouvant contenir ddes erreurs, tu écris une vérification (tests, invariants, etc) pouvant contenir des erreurs, et tu vois si les deux sont d'accord.

  17. #37
    Membre confirmé Avatar de KsassPeuk
    Homme Profil pro
    Ingénieur Chercheur
    Inscrit en
    Juillet 2013
    Messages
    138
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur Chercheur
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Juillet 2013
    Messages : 138
    Points : 635
    Points
    635
    Par défaut
    Citation Envoyé par DonQuiche Voir le message
    J'aimerais voir une preuve que les effets de bord rendent impossible l'analyse. Ce qui à ma connaissance rend impossible l'analyse ce sont des choses comme l'arithmétique de pointeur, les assignations par introspection (reflection), la génération dynamique de code, etc.
    Il me semble que la preuve d'indécidabilité du problème c'est la présence d'alias [Check : W.Landi : Undecidability of Static Analysis]. Mais ça veut tout et rien dire, ce n'est pas parce que généralement c'est le merdier qu'on ne peut rien en faire.

  18. #38
    Membre à l'essai
    Homme Profil pro
    Développeur Web
    Inscrit en
    Juillet 2014
    Messages
    23
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Haut Rhin (Alsace)

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Juillet 2014
    Messages : 23
    Points : 15
    Points
    15
    Par défaut
    Il y a de plus en plus d'outil ... le reponse est dans la question. Puis a force d'ajouter des couches ont ne peux que ajouter des bug non ?

  19. #39
    Rédacteur
    Avatar de pcaboche
    Homme Profil pro
    Inscrit en
    Octobre 2005
    Messages
    2 785
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : Singapour

    Informations forums :
    Inscription : Octobre 2005
    Messages : 2 785
    Points : 9 716
    Points
    9 716
    Par défaut
    Citation Envoyé par DonQuiche Voir le message
    ... j'ai expressément restreint mon propos aux failles de sécurité. Et les buffer overflows sur des tableaux (le cas typique) sont bel et bien impossibles avec des langages de plus haut niveau.
    Je n'ai pas précisé, mais je pensais en particuler à l'arithmetic overflow.

    À cause de ça, à un moment il y avait une faille dans MySQL qui faisait qu'on avait une chance sur 256 d'obtenir les droits d'accès root (à cause d'un cast vers char je crois). Un simple brute force suffisait.

    Pareil dans le cas de la fusée Arianne 5, qui a explosé en vol à cause d'un dépassement de capacité sur un entier codé sur 8 bits...
    "On en a vu poser les armes avant de se tirer une balle dans le pied..."
    -- pydévelop

    Derniers articles:

    (SQL Server) Introduction à la gestion des droits
    (UML) Souplesse et modularité grâce aux Design Patterns
    (UML) Le Pattern Etat
    Autres articles...

  20. #40
    Expert confirmé Avatar de DonQuiche
    Inscrit en
    Septembre 2010
    Messages
    2 741
    Détails du profil
    Informations forums :
    Inscription : Septembre 2010
    Messages : 2 741
    Points : 5 485
    Points
    5 485
    Par défaut
    Citation Envoyé par KsassPeuk Voir le message
    Il me semble que la preuve d'indécidabilité du problème c'est la présence d'alias [Check : W.Landi : Undecidability of Static Analysis]. Mais ça veut tout et rien dire, ce n'est pas parce que généralement c'est le merdier qu'on ne peut rien en faire.
    Merci pour la source. Et, oui, je suis d'accord, difficile de dire quelles conclusions on peut vraiment en tirer : bien sûr qu'on peut écrire des programmes tels qu'en prouver certaines propriétés (comme la preuve de l'arrêt) équivaut à exécuter le programme. Pourtant pour tous les "programmes réels de la vraie vie" les êtres humains sont capables de prouver les propriétés que l'on voudrait que l'ordinateur prouve (sauf programme trop large et erreurs humaines), c'est donc bien que c'est faisable.

    Bon en revanche la construction des ensembles may-alias et must-alias est NP-hard. C'est noté et je ne suis pas surpris. Mais là aussi l'être humain y arrive "dans la vraie vie" en raisonnant de façon séquentielle (mais en s'appuyant sur une sacrée indexation mentale préalable).

    Citation Envoyé par pcaboche Voir le message
    Je n'ai pas précisé, mais je pensais en particuler à l'arithmetic overflow.

    À cause de ça, à un moment il y avait une faille dans MySQL qui faisait qu'on avait une chance sur 256 d'obtenir les droits d'accès root (à cause d'un cast vers char je crois). Un simple brute force suffisait.

    Pareil dans le cas de la fusée Arianne 5, qui a explosé en vol à cause d'un dépassement de capacité sur un entier codé sur 8 bits...
    Ok, cela dit tu reconnaîtras que les buffer overflows sont des failles de sécurité bien plus fréquentes que ce genre d'erreur.
    Pour Ariane 5 en revanche c'est un problème de sûreté, pas une faille de sécurité, cf. un commentaire précédent de PierreLeFake.

Discussions similaires

  1. Réponses: 89
    Dernier message: 01/01/2017, 21h08
  2. Les étudiants sont-ils bien formés à la réalité des métiers du développement logiciel?
    Par mattj dans le forum Débats sur le développement - Le Best Of
    Réponses: 88
    Dernier message: 04/09/2012, 01h40
  3. Conception : réalité ou utopie
    Par grunk dans le forum ALM
    Réponses: 3
    Dernier message: 24/03/2011, 22h13
  4. [Fondements] Preuve de programme: utopie ou réalité ?
    Par DrTopos dans le forum Débats sur le développement - Le Best Of
    Réponses: 115
    Dernier message: 05/10/2007, 17h12
  5. Réponses: 13
    Dernier message: 09/08/2006, 23h25

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo