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. #1
    Expert éminent sénior

    Homme Profil pro
    Développeur informatique
    Inscrit en
    Septembre 2014
    Messages
    194
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Algérie

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : Septembre 2014
    Messages : 194
    Points : 12 291
    Points
    12 291
    Par défaut Logiciel fiable, réalité ou utopie ?
    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 ?

  2. #2
    Membre actif
    Homme Profil pro
    Expertise sécurité
    Inscrit en
    Avril 2013
    Messages
    185
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Expertise sécurité

    Informations forums :
    Inscription : Avril 2013
    Messages : 185
    Points : 268
    Points
    268
    Par défaut
    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.

    @+

  3. #3
    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
    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

  4. #4
    Membre confirmé
    Homme Profil pro
    Inscrit en
    Décembre 2011
    Messages
    268
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Décembre 2011
    Messages : 268
    Points : 556
    Points
    556
    Par défaut
    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 ...

  5. #5
    Expert éminent
    Avatar de transgohan
    Homme Profil pro
    Développeur Temps réel Embarqué
    Inscrit en
    Janvier 2011
    Messages
    3 146
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Maine et Loire (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur Temps réel Embarqué

    Informations forums :
    Inscription : Janvier 2011
    Messages : 3 146
    Points : 9 386
    Points
    9 386
    Par défaut
    Citation Envoyé par Max Lothaire Voir le message
    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.

    « Toujours se souvenir que la majorité des ennuis viennent de l'espace occupé entre la chaise et l'écran de l'ordinateur. »
    « Le watchdog aboie, les tests passent »

  6. #6
    Membre averti
    Profil pro
    Inscrit en
    Juin 2006
    Messages
    187
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2006
    Messages : 187
    Points : 434
    Points
    434
    Par défaut
    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".

  7. #7
    Membre expérimenté
    Homme Profil pro
    Développeur Web
    Inscrit en
    Juillet 2009
    Messages
    420
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Juillet 2009
    Messages : 420
    Points : 1 471
    Points
    1 471
    Par défaut
    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.

  8. #8
    MikeRowSoft
    Invité(e)
    Par défaut
    Après tous il existe plusieurs sorte de bogues et plusieurs raisons à ces bogues.
    Dernière modification par MikeRowSoft ; 05/11/2014 à 17h41.

  9. #9
    Membre à l'essai
    Homme Profil pro
    Inscrit en
    Décembre 2012
    Messages
    13
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Côtes d'Armor (Bretagne)

    Informations forums :
    Inscription : Décembre 2012
    Messages : 13
    Points : 21
    Points
    21
    Par défaut
    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.

  10. #10
    Membre éprouvé

    Profil pro
    Inscrit en
    Novembre 2009
    Messages
    506
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : Novembre 2009
    Messages : 506
    Points : 1 289
    Points
    1 289
    Par défaut Bah c'est tout simple
    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.

  11. #11
    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 frfancha Voir le message
    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

  12. #12
    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
    Ç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.
    Ne prenez pas la vie au sérieux, vous n'en sortirez pas vivant ...

  13. #13
    Expert éminent sénior
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Septembre 2012
    Messages
    3 020
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Finistère (Bretagne)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Septembre 2012
    Messages : 3 020
    Points : 16 093
    Points
    16 093
    Par défaut
    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.

  14. #14
    Membre averti
    Profil pro
    Inscrit en
    Janvier 2006
    Messages
    80
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Janvier 2006
    Messages : 80
    Points : 370
    Points
    370
    Par défaut
    Citation Envoyé par frfancha Voir le message
    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.

  15. #15
    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
    Ç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...

  16. #16
    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
    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é.
    Ne prenez pas la vie au sérieux, vous n'en sortirez pas vivant ...

  17. #17
    Membre expérimenté
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Juin 2004
    Messages
    374
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : Juin 2004
    Messages : 374
    Points : 1 399
    Points
    1 399
    Par défaut
    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 ...

  18. #18
    Modérateur

    Profil pro
    Inscrit en
    Septembre 2004
    Messages
    12 547
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2004
    Messages : 12 547
    Points : 21 602
    Points
    21 602
    Par défaut
    Citation Envoyé par Shepard Voir le message
    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

    Citation Envoyé par XKCD
    - Du code écrit en Haskell est garanti sans effet de bord.
    - ... Parce que personne n'essaiera jamais de le lancer ?
    N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  19. #19
    Expert confirmé Avatar de AoCannaille
    Inscrit en
    Juin 2009
    Messages
    1 412
    Détails du profil
    Informations forums :
    Inscription : Juin 2009
    Messages : 1 412
    Points : 4 729
    Points
    4 729
    Par défaut
    Citation Envoyé par Shepard Voir le message
    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.

  20. #20
    Membre éprouvé
    Profil pro
    Inscrit en
    Mars 2012
    Messages
    371
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2012
    Messages : 371
    Points : 1 002
    Points
    1 002
    Par défaut
    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"

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