Discussion :

[_vince_]

En partant du principe que d'autres programmeurs, par définition maladroits et peu précautionneux (c'est pas une insulte, j'applique vos principes ), vont toucher à mon code, je suppose que je dois appliquer ces vérifications même pour ce qui est des méthodes privées (bien que pour le moment je sois le seul à les utiliser) ?

En fait, tu dois prendre des precautions meme avec ton propre code pour te proteger de tes propres erreurs. Meme en etant rigoureux, tu introduiras quand meme des bugs dans ton code. C'est humain d'inserer des bugs dans du code. Personne n'en est a l'abri! C'est donc contre toi meme qu'il faut te proteger

[TheCaribouX]

ça m'apprendra à "critiquer" les autres programmeurs.

[Franck SORIANO]

- Si tu ecris une fonction avec plusieurs arguments. Il faut s'assurer que les valeurs fournies en entree sont correctes. Si l'argument est un pourcentage, tu verifies que la valeur est bien entre 0 et 100. Si c'est un code postal, tu peux verifier que le code postal est valide. Plus generalement, on parle de programmation par contrat.

Heu non, la programmation par contrat c'est le contraire. Ce que tu décris c'est la programmation blindée (ou défensive comme dit précédemment).

La programmation par contrat, c'est exactement le contraire. Tu définis un contrat avec l'utilisateur de la fonction, qui dit que la fonction doit être appelée uniquement dans tel context, avec tel paramètres. Ensuite tu pars du principe que le contrat est respecté et justement tu ne fais aucune vérification sur le contrat.

Programmation défensive et par contrat, ce sont deux styles de programmation opposés à utiliser en fonction de la situation où on se trouve.

La programmation défensive n'est pas la solution miracle. Au contraire elle peut même facilement provoquer l'effet inverse du but recherché :

Si l'argument est un pourcentage, tu verifies que la valeur est bien entre 0 et 100.

Ok, c'est un pourcentage. Donc tu contrôles. Le pourcentage dépasse 100% tu déclenches une erreur.... sauf que depuis quand est-ce qu'un pourcentage de 110% est une anomalie ? Tu as voulu trop blindé, pas de bol la valeur était normale.
Du coup c'est le test qui devais t'éviter des problèmes qui au contraire en crée...

Autre problème de la programme défensive : Si tu structures bien ton code, tu va très vite avoir beaucoup de petites méthodes qui s'appellent les unes les autres. Si chaque méthode commence par vérifer la cohérence de tous les paramètres à chaque fois, très vite le code "utile" de la méthode est noyé sous les vérifications et tout devient illisible... Les exceptions ont d'ailleurs été inventées pour améliorer ce problème.

Alors quand utiliser la programmation défensive et quand utiliser la programmation par contrat ?
Je dirais que pour un débutant, il faut commencer par la programmation défensive. Pour détecter un maximum d'erreurs au plus tôt. Et puis s'interroger sur toutes les erreurs possibles ça aide à réfléchir.

Ensuite, avec l'expérience, tu continues à contrôler systématiquement toutes les saisis des utilisateurs (ça c'est indispensable). Mais pour le reste, c'est au feeling en fonction de ce que tu fais.

[_vince_]

Ok, c'est un pourcentage. Donc tu contrôles. Le pourcentage dépasse 100% tu déclenches une erreur.... sauf que depuis quand est-ce qu'un pourcentage de 110% est une anomalie ?

C'est un exemple simpliste mais utile. C'est justement au premier programmeur a dire si c'est une anomalie ou non. Car si ce n'est pas "écrit" dans le code, celui qui va maintenir le programme des années plus tard n'en aura pas la moindre idée. Si le programmeur met une assertion pour dire que la valeur doit être inférieure à 100, celui qui passe après ne se posera pas la question.

Autre problème de la programme défensive : Si tu structures bien ton code, tu va très vite avoir beaucoup de petites méthodes qui s'appellent les unes les autres. Si chaque méthode commence par vérifier la cohérence de tous les paramètres à chaque fois, très vite le code "utile" de la méthode est noyé sous les vérifications et tout devient illisible... Les exceptions ont d'ailleurs été inventées pour améliorer ce problème.

Je suis d'accord qu'il ne faut pas trop en faire pour ne pas que ça devienne illisible au point d'avoir plus de code de gestion d'erreur que de code qui gère le cas nominal. Pour les erreurs de logique, je suis plus partisan de quelques assertions bien placées qui permettent de détecter les bugs plus tôt. Plus les mailles du filet sont serrés, plus on attrape de poissons.

[davcha]

Un bon projet, c'est un projet qui se termine rapidement et qui se vend cher.

Un très bon projet, c'est un projet qui se termine vite, qui se vend cher et qui donne de nouvelles idées d'améliorations à tes clients régulièrement.

Un projet génial c'est un très bon projet qui répond à une demande énorme.

[Garulfo]

[HS1 version Les Inconnus]
Un mauvais projet c'est un projet plein de code et puis qui une fois qu'il est terminé donne un programme. Un bon projet par contre, c'est un projet plein de code et qui, lui, une fois terminé, il te donne un programme... mais c'est un bon projet[/HS1]

[HS2 version E.Baer]
Il n'y a pas de bon ou de mauvais projet. Il y a la vie qui porte le projet; la vie qui vit en ton projet; et la vie qui porte le coeur du projet dans la vie elle-même qui en remercie le projet... etc.[/HS2]

[TheCaribouX]

[HS2 version E.Baer]
Il n'y a pas de bon ou de mauvais projet. Il y a la vie qui porte le projet; la vie qui vit en ton projet; et la vie qui porte le coeur du projet dans la vie elle-même qui en remercie le projet... etc.[/HS2]

Voilà qui est très instructif

Plus sérieusement, après avoir lu le tuto sur "comment bien commenter un code en c#" et les remarques de vince et F.Soriano, il semble clair que meme un code d'une centaine de lignes à la base va finalement en faire le quadruple si l'on commente bien le code et l'on programme de manière défensive, et donc au final on obtient un code surchargé et plus difficilement réutilisable (ce qui est quand meme un des buts d'un programme). Les exceptions permettent-elles vraiment de réduire le nombre de lignes? (intuitivement, j'aurais tendance à dire que la différence doit se compter sur les doigts de la main)

[Franck SORIANO]

...il semble clair que meme un code d'une centaine de lignes à la base va finalement en faire le quadruple si l'on commente bien le code et l'on programme de manière défensive, et donc au final on obtient un code surchargé et plus difficilement réutilisable (ce qui est quand meme un des buts d'un programme).

Le code va vite grossir en nombre de lignes c'est sûr. Mais il n'y a pas de raisons pour que ça nuise à la réutilisabilité du code. Les commentaires ne vont pas t'empêcher de réutiliser le code.
Les vérifications de la programmation défensive peuvent être un obstacles si tu vas trop loin (cf exemple du pourcentage, peut-être que dans le context initiale, la valeur devait effectivement être dans [0..100], mais peut-être que dans un autre context, une valeur >100 est normale...
Mais normalement, tu fais la vérification des paramètres par rapport à ce que la méthode a besoin. Les règles tels que 0..100 seront placés dans du code métier qui lui sera de toute façon plus difficilement réutilisable dans une autre application.

Les exceptions permettent-elles vraiment de réduire le nombre de lignes? (intuitivement, j'aurais tendance à dire que la différence doit se compter sur les doigts de la main)

Oui, et surtout ça change la façon de traiter les erreurs.

Sans exception :
- Tu appelles une méthode, cette dernière renvoie un code de retour pour signaler une erreur.
- Tu ne testes pas le code de retour.
- Ca plante beaucoup plus loin sans que tu ne saches pourquoi.
Bon ça c'est la pratique. Normalement ça serait plutôt :

- Tu appelles une méthode : 1 ligne de code "utile".
- Tu testes le code de retour.
- Si c'est une erreur, tu gères l'erreur (tu affiches un message dans la plupart des cas) et tu arrêtes le traitement en cours (tu sors de la méthode).
Donc tu as au minimum : 3-4 lignes de code supplémentaires de tests pour chaque ligne "utile".

Au final, les lignes "utiles" sont disséminées au milieu de la gestion des erreurs. Tu as une ligne sur quatre qui fait quelque chose, le reste ne sert qu'à la gestion des erreurs.
Regarde les exemples de codes C++ de la MSDN, c'est un très bon exemple en la matière (en général, c'est 10 lignes de code minimum pour appeler une fonction de l'API Windows...).

Avec les exceptions :
- Tu appelles la méthode sans te poser de question : 1 Ligne utile.
- Tu continues ton traitement, comme si tout c'était bien passé. Donc tu enchaîne avec une autre ligne utile, qui suit ton algorithme.
- Si une erreur se produit sur un des appels : Une exception est déclenchée qui stoppe automatiquement tout traitement en cours. L'execution saute au premier catch trouvé pour traiter l'erreur.
Comme la plupart du temps, on ce contente d'afficher un message d'erreur, le même gestionnaire d'erreur peut traiter tous les appels...

Ainsi au final, tu as le code "utile" au début de la méthode. Et a la fin, tu as le block catch pour traiter les erreurs. Tu diminues le nombre de lignes, mais surtout c'est beaucoup plus claire. Et tu ne risque pas que le développeur ne teste pas les codes de retour.
A la place, il fera partout :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
  try
  {
  ...
  }
  catch
  {
    // chut !!!
  }

[hed62]

Les exceptions permettent-elles vraiment de réduire le nombre de lignes?

Tout dépend de comment elles sont gérées.
Le but n'est pas de limiter le nombre de lignes, mais de faciliter la lecture.
Attention avec le "tout-exception" (certains ne mettent aucun if/else, et traitent tout via exception) : le système de catch est assez lourd (bien plus que les if/else. Les exceptions sont à utiliser, mais dans des cas adaptés. Notamment, elles permmettent de récupérer des erreurs correctements identifiées, car les exceptions sont typees (NullException, ArgumentException, MonExceptionAMoi, etc...)

Il ne faut pas vérifier l'intégralité des choses, mais le minimum pour que la fonction ne se crashe pas. (notamment, toujours tester si une collection n'est pas nulle avant de faire un foreach dessus... ce n'est qu'un exemple.)

J'aime assez la programmation par contrat, cela allège grandement le code, et l'optimise. Toutefois, il ne faut pas en abuser non plus, et il faut que tous les intervenants soient très rigoureux, pour tester les contrats.

Les tests unitaires verifient que le code fonctionne comme prevu.

Non pas, surtout dans une optique TDD. Les tests unitaires visent alors à couvrir 98% du code (car 100% est pour moi utopique ), et donc à parcourir tous les traitements d'erreurs. Et pour voir que les erreurs sont bien traitées, on les provoque volontairement. Ainsi, pour tester une fonction qui prend deux paramètres pour écrire dans un fichier, on écrira de nombreux cas de tests : un cas nominal (en premier, car c'est lui qui doit être satisfait d'abord en TDD), un avec des paramètres null, un avec des paramètres aberrants, un où le fichier n'existe pas, un ou le fichier existe, mais pas les droits, un ou le fichier existe, mais quelqu'un l'a en ecriture, etc...

[TheCaribouX]

Je considérerai désormais les exceptions sous un angle différent!

...pour tester une fonction qui prend deux paramètres pour écrire dans un fichier, on écrira de nombreux cas de tests : un cas nominal (en premier, car c'est lui qui doit être satisfait d'abord en TDD), un avec des paramètres null, un avec des paramètres aberrants, un où le fichier n'existe pas, un ou le fichier existe, mais pas les droits, un ou le fichier existe, mais quelqu'un l'a en ecriture, etc...

C'est vraiment très intéressant! Est-ce que seule l'expérience permet de définir tous les tests à appliquer suivant la situation ou alors existe t'il une sorte de "répertoire" de ceux-ci?

[Franck SORIANO]

C'est vraiment très intéressant! Est-ce que seule l'expérience permet de définir tous les tests à appliquer suivant la situation ou alors existe t'il une sorte de "répertoire" de ceux-ci?

L'expérience joue beaucoup. Mais disons qu'il faut avant tout avoir le bon état d'esprit.
Ce qui est important, c'est qu'on ne teste pas pour vérifier que le programme marche, mais au contraire, on teste pour prouver qu'il est plein de bugs.
L'idéal, c'est de tester le code écrit par quelqu'un d'autre, en essayant de faire tous les tests possibles et imaginables pour faire planter son truc.

Ce n'est qu'une fois que tu auras échoué à montrer que ça ne marche pas, qu'en désespoire de cause, tu conclus : "Bon, ça ne marche certainement pas, mais puisque je n'arrive pas à le montrer, on va faire comme si c'était bon".
Et tu peux être sûr, que les utilisateurs finaux, eux parviendront et te montrer qu'effectivement, ça ne marchait toujours pas.

Après, le problème c'est de savoir quand s'arrêter et rester raisonnable. Il n'est pas nécessairement utile de tester le comportement de l'appli lorsque la machine est frappée par un rayon cosmique...

[gorgonite]

L'expérience joue beaucoup. Mais disons qu'il faut avant tout avoir le bon état d'esprit.
Ce qui est important, c'est qu'on ne teste pas pour vérifier que le programme marche, mais au contraire, on teste pour prouver qu'il est plein de bugs.
L'idéal, c'est de tester le code écrit par quelqu'un d'autre, en essayant de faire tous les tests possibles et imaginables pour faire planter son truc.

Ce n'est qu'une fois que tu auras échoué à montrer que ça ne marche pas, qu'en désespoire de cause, tu conclus : "Bon, ça ne marche certainement pas, mais puisque je n'arrive pas à le montrer, on va faire comme si c'était bon".

tu as du louper la case "analyse statique" et certification de code

[_vince_]

Je considérerai désormais les exceptions sous un angle différent!


C'est vraiment très intéressant! Est-ce que seule l'expérience permet de définir tous les tests à appliquer suivant la situation ou alors existe t'il une sorte de "répertoire" de ceux-ci?

Voici un catalogue de bugs de sites d'e-commerce provenant d'exemples reels:
http://www.testingeducation.org/a/tecrf.pdf

Le metier de testeur est un metier different de celui de programmeur. C'est une autre facette du developpement logiciel. Les tests unitaires ne verifient pas que le logiciel correspond aux besoins des utilisateurs, c'est le role des des tests d'acceptation/validation. Mais le sujet meriterait un post a lui tout seul. Pour faire simple et comme ca ete dit plus haut, il y a les developpeurs qui codent. Et les testeurs qui testent. Ces personnes doivent etre differentes. Sachant qu'on ne peut pas tout tester, il faut commencer par tester les fonctionnalites les plus importantes. Et ce n'est pas parce que tu n'arrives pas a trouver de bugs qu'il n'y en a pas ! Il y a toujours un bug qui se cache quelque part.

Concernant la gestion des erreurs et des exceptions, c'est plutot une question de style de programmation. Certains preferent les codes de retour d'erreur, d'autres les exceptions. A mon avis, l'important est que le style de programmation soit uniforme a travers le projet. Par exemple, en entrant dans une fonction, est-ce qu'on gere les cas exceptionnels en premier, ensuite les cas non-nominaux, et pour finir par les cas nominaux ? Ou alors, on peut terminer par les cas non-nominaux. Il n'y a pas de "meilleur" choix. L'important est que le style soit applique partout pour simplifier la vie des mainteneurs qui passent apres...

[davcha]

Il n'est pas nécessairement utile de tester le comportement de l'appli lorsque la machine est frappée par un rayon cosmique...

Quoique.... Ca me rappelle un truc ça, quand même...

[_vince_]

Après, le problème c'est de savoir quand s'arrêter et rester raisonnable. Il n'est pas nécessairement utile de tester le comportement de l'appli lorsque la machine est frappée par un rayon cosmique...

Sur des grands systemes operationnels, tu peux imaginer un site distant dit "de secours" qui est une copie du premier site si celui-ci tombe en panne. Et la on lance le sujet de la redondance chaude...

[Franck SORIANO]

tu as du louper la case "analyse statique" et certification de code

Ha bon, tu peux développer ?

Pour moi, l'analyse statique c'est un ensemble de techniques qui consistent à examiner le code pour tanter de prévoir les causes possibles d'erreur. Ce n'est qu'un outil pour t'aider à trouver des cas de tests pour prouver que l'appli plante. Ca ne change rien à la démarche général du test. J'aurais même tendance à dire que ça va plutôt dans le même sens : J'essaie de tout faire pour montrer que l'appli plante, et je m'appuie pour celà sur des tests boite blanche. Je regarde le code, tiens c'est codé comme ça, donc si je fais ça, ça va planter... chouette, il faut vite que j'essaie...

Quant à la certification de code qu'est-ce que c'est ? Pour moi, c'est rien d'autre qu'un audit effectué sur le code par un outil (ou quelqu'un) pour vérifier que le codage a bien été fait en respectant une norme ou un ensemble de règles définies à l'avance.
Ca ne te garanti en rien que l'appli fonctionnera correctement une fois compilée...

[gorgonite]

Pour moi, l'analyse statique c'est un ensemble de techniques qui consistent à examiner le code pour tanter de prévoir les causes possibles d'erreur.

c'est assez réducteur comme point de vue... disons que les possibilités de l'analyse statique sont liés à l'expressivité du code à analyser

• si tu veux analyser un langage complet ne respectant aucune convention, on se place effectivement dans le cas d'un outil repérant un maximum de bugs possibles de manière indépendante du contexte d'exécutions (et donc qui peut trouver des bugs qui n'arriveront jamais avec les données d'entrées normales du programme )... très pratique, mais aux résultats limités
• si tu acceptes de restreindre l'expressivité de tes programmes, tu peux arriver à des cas où certaines méthodes d'analyse statique peuvent de trouver tous les bugs

au passage, le cas le plus "évident" où l'on peut tout trouver est celui où tu disposes d'un domaine fini concret... par exemple, ça marche pas mal pour l'analyse de protocole réseaux

Quant à la certification de code qu'est-ce que c'est ? Pour moi, c'est rien d'autre qu'un audit effectué sur le code par un outil (ou quelqu'un) pour vérifier que le codage a bien été fait en respectant une norme ou un ensemble de règles définies à l'avance.

c'est plus complet que cela
1) y a des personnes qui surveillent que tu respectes certaines règles... (utiles pour assurer que tu es dans le cadre où les outils d'analyses te signalent tous les bugs)
2) ils peuvent faire des analyses intéressantes et posées des assertions qui aideront les programmes d'analyse statique

Ca ne te garanti en rien que l'appli fonctionnera correctement une fois compilée...

grossière erreur... qui te dit qu'on analyse seulement le code avant compilation ?

[Franck SORIANO]

c'est assez réducteur comme point de vue... disons que les possibilités de l'analyse statique sont liés à l'expressivité du code à analyser

• si tu veux analyser un langage complet ne respectant aucune convention, on se place effectivement dans le cas d'un outil repérant un maximum de bugs possibles de manière indépendante du contexte d'exécutions (et donc qui peut trouver des bugs qui n'arriveront jamais avec les données d'entrées normales du programme )... très pratique, mais aux résultats limités
• si tu acceptes de restreindre l'expressivité de tes programmes, tu peux arriver à des cas où certaines méthodes d'analyse statique peuvent de trouver tous les bugs

au passage, le cas le plus "évident" où l'on peut tout trouver est celui où tu disposes d'un domaine fini concret... par exemple, ça marche pas mal pour l'analyse de protocole réseaux

Tu veux dire que si j'écris :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
int Somme(int a, int b)
{
    return a-b;
}

L'analyse statique va me dire que ma fonction calcule la différence a-b au lieu de la somme, et va trouver le bug toute seul sans avoir besoin de faire d'autres tests ?

au passage, le cas le plus "évident" où l'on peut tout trouver est celui où tu disposes d'un domaine fini concret... par exemple, ça marche pas mal pour l'analyse de protocole réseaux

Là je suis d'accord avec toi, le seul cas où on peut effectivement espérer faire des tests exhaustifs et que l'appli est sans bug, c'est si tu as un nombre d'entrées finis et que tu peux énumérer. Car dans ce cas, tu peux faire le test sur toutes les entrées pour vérifier que les résultats sont tous conformes aux attentes.

c'est plus complet que cela
1) y a des personnes qui surveillent que tu respectes certaines règles... (utiles pour assurer que tu es dans le cadre où les outils d'analyses te signalent tous les bugs)
2) ils peuvent faire des analyses intéressantes et posées des assertions qui aideront les programmes d'analyse statique

Je ne vois pas ce que ça change.

grossière erreur... qui te dit qu'on analyse seulement le code avant compilation ?

Ben en fait, c'est ce que je te demandes de nous expliquer. Mais pour moi, ta réponse est déjà un aveu pour dire que ça ne suffit pas, et que ça ne te dispense pas d'effectuer les tests à l'exécution.
Donc on en revient à : ce ne sont que des techniques pour t'aider à trouver les bons cas de tests. Techniques qui soit dit en passant doivent être très lourdes et couteuses à mettre en oeuvre et totalement déraisonnables dans beaucoups de cas.

Enfin dernière remarque, tu sembles penser qu'il est effectivement possible de trouver tous les bugs existants dans une application. Pourtant, tout le monde sait qu'en informatique, le 0 défaut n'existe pas. S'il existait une méthode miracle qui t'assure qu'un programme ne contient aucun bug, tout le monde s'en servirait et le mot "bug" n'existerait que dans son sens premier...

[souviron34]

je rejoindrais assez Franck sur le sujet des tests..

Je citerais un exemple..

Il y a longtemps, je travaillais sur une machine medicale d'imagerie (IRM), chez le fabricant.

J'etais responsable de l'IHM.

Pour acceptation a la Secu, nous devions passer devant un ingenieur biomedical, qui etait en charge du controle de la machine.

Cet ingenieur a passer 1 jour complet a cliquer a l'ecran et taper sur le clavier partout SANS regarder l'ecran ni le clavier.

Apres 3 crashs, il m'a dit "Si vous passez cette etape-la, vous avez 80%. La fonctionalite, ca se regle. Pas la solidite...".

Et, apres avoir corrige les crashs et repasse les tests d'acceptance, alors que mon IHM prenait possession de l'ecran et du clavier (impossible de faire quoi que ce soit d'imprevu, d'atteindre la console , etc etc..), nous avons quand meme ete appelle pour le SAV parce qu'un infirmier avait reussi (je ne sais toujours pas comment) a changer la configuration des touches de fonctions....

[gorgonite]

Tu veux dire que si j'écris :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
int Somme(int a, int b)
{
    return a-b;
}

L'analyse statique va me dire que ma fonction calcule la différence a-b au lieu de la somme, et va trouver le bug toute seul sans avoir besoin de faire d'autres tests ?

tout dépend du sens que tu as attribué à Somme... mais effectivement, il pourrait le détecter par une simple exécution symbolique
(tu peux aussi regarder les méthodes de Karr si tu veux quelque chose de plus formel )

Là je suis d'accord avec toi, le seul cas où on peut effectivement espérer faire des tests exhaustifs et que l'appli est sans bug, c'est si tu as un nombre d'entrées finis et que tu peux énumérer. Car dans ce cas, tu peux faire le test sur toutes les entrées pour vérifier que les résultats sont tous conformes aux attentes.

ben il y aussi le cas où l'on peut se rapporter à un modèle abstrait fini et où l'on a une propriété de sûreté de l'abstraction

Je ne vois pas ce que ça change.

si l'expert guide bien l'analyse statique, ça peut réduire les fausses alertes, et permettre aux développeurs de se consacrer sur les vraies erreurs

Ben en fait, c'est ce que je te demandes de nous expliquer. Mais pour moi, ta réponse est déjà un aveu pour dire que ça ne suffit pas, et que ça ne te dispense pas d'effectuer les tests à l'exécution.

disons qu'à l'heure actuelle dans tous les cas "non critiques", les langages utilisés et la façon de programmer font que l'anlyse statique n'est qu'un outil de débogage comme un autre

les limitations de l'analyse statiques viennent surtout de

• l'explosion combinatoire du nombre d'états à vérifier ;
• l'indécidabilité

et si l'on tient compte de :

• récentes avancées de la recherche sur des techniques pour contenir l'explosion combinatoire (rien que dans mon labo, on a soumis 3 papiers sur le sujet depuis le début de l'année... et on est 4 dans l'équipe ^^)
• la théorie de l'anti-fondation qui permet de contourner l'indécidabilité

Donc on en revient à : ce ne sont que des techniques pour t'aider à trouver les bons cas de tests. Techniques qui soit dit en passant doivent être très lourdes et couteuses à mettre en oeuvre et totalement déraisonnables dans beaucoups de cas.

à l'heure actuelle, l'industrie est sur une approche "design and debug"... et il est clair que les coûts peuvent devenir pharaoniques

on n'a pas la même approche dans mon labo... mais cela nécessite de fortes compétences pour les concepteurs

Enfin dernière remarque, tu sembles penser qu'il est effectivement possible de trouver tous les bugs existants dans une application. Pourtant, tout le monde sait qu'en informatique, le 0 défaut n'existe pas. S'il existait une méthode miracle qui t'assure qu'un programme ne contient aucun bug, tout le monde s'en servirait et le mot "bug" n'existerait que dans son sens premier...

à l'époque de Pasteur, tout le monde savait que la génération spontanée était une évidence, à celle de Copernic que le Soleil tournait autour de la Terre... on a même tué ou failli tuer ces hommes pour avoir dit le contraire. Pourtant, force est de constater que notre conception de ces problématiques a bien changé depuis