La méthodologie de test logiciel repose-t-elle sur des données erronées?

C'est un fait bien connu en génie logiciel que le coût de la correction d'un bogue augmente de façon exponentielle à la découverte ultérieure du bogue. Ceci est corroboré par les données publiées dans Code Complete et adaptées dans de nombreuses autres publications.

Cependant, il s'avère que ces données n'ont jamais existé . Les données citées par Code Complete ne montrent apparemment pas une telle corrélation coût / temps de développement, et des tableaux publiés similaires ne montraient que la corrélation dans certains cas particuliers et une courbe plate dans d’autres (c’est-à-dire aucune augmentation de coût).

Existe-t-il des données indépendantes pour corroborer ou réfuter cela?

Et s’il est vrai (c’est-à-dire s’il n’existe tout simplement pas de données permettant de prendre en charge ce coût exponentiellement plus élevé pour les bogues récemment découverts), quel en est l’impact sur la méthodologie de développement logiciel?

La méthodologie de test logiciel repose-t-elle sur des données erronées?

Oui, manifestement. L'examen de la courbe du coût de changement agile montre qu'une partie du travail de Kent Beck sur XP (je ne sais pas si cela faisait partie de sa motivation ou de sa justification) consistait à "aplanir la courbe" des coûts des défauts, sur la base de la connaissance du " exponentielle "qui se trouve derrière la table Code Complete. Alors oui, travailler sur au moins une méthodologie - celle qui a le plus contribué à vulgariser le développement test-first - repose au moins en partie sur des données erronées.

Existe-t-il des données indépendantes pour corroborer ou réfuter cela?

Oui, vous pouvez certainement consulter d'autres données. La plus grande étude que je connaisse est l'analyse des défauts effectuée par Hughes Aircraft dans le cadre de son programme d'évaluation CMM . Le rapport de là montre comment les coûts de défaut dépendu avec la phase pour eux : si les données contenues dans ce rapport ne comprennent pas les écarts afin que vous devez se méfier de tirer trop de « cette chose coûte plus de cette chose » conclusions. Vous devriez également noter que, indépendamment de la méthodologie, il y a eu des changements dans les outils et les techniques entre les années 1980 et aujourd'hui qui remettent en question la pertinence de ces données.

Donc, en supposant que nous ayons toujours un problème pour justifier ces chiffres:

Quel impact cela at-il sur la méthodologie de développement logiciel?

Le fait que nous nous appuyions sur des chiffres non vérifiables n'a pas empêché les gens de progresser sur la base d'anecdotes et d'expérience: de la même manière que de nombreux métiers de maître-apprenti sont appris. Je ne pense pas qu'il y avait un Journal of Evidence-Based Maonry au Moyen Âge, mais tout un tas d'immeubles de grande taille, impressionnants et durables ont néanmoins été construits avec un certain succès. Cela signifie que nous basons principalement notre pratique sur "ce qui a fonctionné pour moi ou pour les personnes que j'ai rencontrées"; Ce n'est pas une mauvaise chose, mais ce n'est peut-être pas le moyen le plus efficace d'améliorer un groupe de millions de personnes qui constituent la pierre angulaire de l'ère technologique actuelle.

Je trouve décevant que, dans une prétendue discipline d'ingénierie, l'empirisme ne soit pas mieux fondé, et je soupçonne (bien que cela ne puisse clairement pas prouver) que nous serions en mesure de progresser plus clairement et plus clairement dans l'amélioration de nos techniques et méthodologies. cette fondation en place - tout comme la médecine clinique semble avoir été transformée par la pratique fondée sur des preuves. Ceci est basé sur quelques grandes hypothèses cependant:

• que le caractère exclusif de la plupart des pratiques de génie logiciel n'empêche pas la collecte de suffisamment de données utiles et pertinentes;
• que les conclusions tirées de ces données sont généralement applicables (du fait que le génie logiciel est une profession qualifiée, des différences personnelles d'expérience, de capacité et de goût pourraient affecter cette applicabilité);
• que les ingénieurs en logiciel "sur le terrain" soient capables et motivés pour utiliser les résultats ainsi obtenus; et
• que nous savons réellement quelles questions nous sommes censés poser en premier lieu. C’est évidemment le point le plus important: lorsque nous parlons d’ amélioration du génie logiciel, que voulons-nous améliorer? Quelle est la mesure? Améliorer cette mesure améliore-t-il réellement le résultat ou joue-t-il au système? A titre d'exemple, supposons que la direction de ma société ait décidé que nous allions réduire le rapport entre le coût réel du projet et le coût prévu du projet. Je pourrais simplement commencer à multiplier toutes mes estimations de coûts par un facteur de fudge et je réaliserais cet "objectif". Devrait-il alors devenir une pratique courante de l’industrie de falsifier toutes les estimations?

Pour ma part, la réponse à "comment cela affecte-t-il la méthodologie de développement logiciel" est "pas grand chose".

Qu'il soit capturé par le développeur ou par l'utilisateur final, que cela prenne plus d'argent après avoir été capturé par l'utilisateur ou non, le fait demeure qu'un bogue a été trouvé dans le système. Si attrapé par le développeur, espérons que c'est une solution rapide. Le même espoir est valable pour les bugs détectés par l'utilisateur.

Indépendamment du coût réel en heures-développeur pour la résolution d'un bogue détecté par un utilisateur final, il existe un coût intangible lié au maintien du stéréotype que les codeurs craignent pour ce qu'ils font. Lorsqu'un utilisateur trouve un bogue, c'est la faute du développeur. Par conséquent, chaque bogue détecté par l'utilisateur final réduit sa confiance dans le système. C'est comme visiter une maison que vous voulez acheter et voir une tache d'eau apparaître à travers le plafond dans un coin de la maison. Cela, en soi, est une solution facile, mais vous vous demandez quelle en est la cause et quelles autres conséquences cette cause fondamentale peut avoir affectée. Que vaut votre tranquillité d'esprit? Vous devrez peut-être abattre les murs et recouvrir les murs et tout inspecter pour vous assurer que la tache provient d'un incident isolé qui a été corrigé. Savoir que cela pourrait être une possibilité ne vous rend pas très confiant à la maison. De même,

Ces coûts intangibles sont évités plus vite que le bogue est détecté, ce qui est l'objectif déclaré des méthodologies de type TDD. Un bogue détecté lors de la frappe par le développeur ou le partenaire d’une paire, un détecté au moment de la compilation ou un test détecté par unité / intégration (couche ajoutée par TDD), est un bogue que l’utilisateur ne doit jamais connaître, que votre Le chef de projet n'a jamais à s'excuser et à ce que vous n'ayez pas à vous soucier de ce que vous faites maintenant pour passer à la vitesse supérieure en mode de réparation des défauts sur une partie du système que vous pensiez avoir laissée derrière vous depuis.

Je vais commencer par dire que la plupart de ce que je trouve provient des années 70 et du début des années 80. Pendant ce temps, les modèles de processus séquentiels étaient beaucoup plus courants que les approches itératives et / ou incrémentales (le modèle Spiral ou les méthodes agiles). Une grande partie de ce travail est construit sur ces modèles séquentiels. Cependant, je ne pense pas que cela détruise la relation, mais l'un des avantages des approches itératives / incrémentielles est de libérer rapidement les fonctionnalités (toute une tranche verticale d'une application) et de corriger les problèmes avant que les dépendances ne soient injectées et la complexité de chaque phase. est haut.

Je viens tout juste de sortir mon exemplaire de Software Engineering Economics et de trouver une référence aux données sous-jacentes à ce graphique au chapitre 4. Il cite "Contrôles de conception et de code pour réduire les erreurs de développement de programmes" par ME Fagan ( IEEE , PDF de UMD ), EB "Management of Software Engineering" de Daly, "Une analyse des ressources utilisées dans le développement de logiciels système de sauvegarde" ( ACM ) de WE Stephenson et "Plusieurs projets TRW".

... le coût relatif de la correction des erreurs de logiciel (ou de toute autre modification de logiciel) en fonction de la phase de correction ou de modification. Si une erreur d'exigences logicielles est détectée et corrigée pendant la phase de planification et d'exigences, sa correction est une opération relativement simple de mise à jour de la spécification des exigences. Si la même erreur n'est pas corrigée avant la phase de maintenance, la correction implique un inventaire beaucoup plus important de spécifications, de codes, de manuels d'utilisation et de maintenance, ainsi que de matériel de formation.

En outre, les corrections tardives impliquent un processus d'approbation et de contrôle des modifications beaucoup plus formel, ainsi qu'une activité beaucoup plus étendue pour revalider la correction. Ces facteurs se combinent pour rendre l'erreur 100 fois plus coûteuse à corriger lors de la phase de maintenance sur les grands projets que lors de la phase des exigences.

Bohem a également examiné deux projets plus petits et moins formels et a constaté une augmentation des coûts, mais beaucoup moins significative que les 100 fois identifiées dans les projets plus importants. Compte tenu de la carte, les différences semblent être 4 fois plus importantes pour corriger un défaut d’exigences une fois le système opérationnel que lors de la phase d’exigences. Il a attribué cela à la réduction du nombre d'articles composant le projet et à la réduction des formalités, ce qui a permis de mettre en œuvre plus rapidement les solutions simplifiées.

Basé sur Boehm dans Software Engineering Economics, le tableau dans Code Complete est plutôt bouffi (le bas des fourchettes est souvent trop élevé). Le coût de toute modification au sein de la phase est en effet 1. Extrapolant à partir de la figure 4-2 de la rubrique Ingénierie du logiciel, un changement des exigences doit être de 1,5 à 2,5 fois dans l’architecture, de 2,5 à 10 pour le codage, de 4 à 20 pour les tests et de 4 à 4. 100 en maintenance. Le montant dépend de la taille et de la complexité du projet ainsi que de la formalité du processus utilisé.

Dans l'annexe E de Barry Boehm et Richard Turner, Équilibrage de l'agilité et de la discipline, contient une petite section sur les conclusions empiriques concernant le coût du changement.

Les premiers paragraphes citent Extreme Programming Explained de Kent Beck, citant Beck. Il dit que si le coût des changements augmentait lentement avec le temps, les décisions seraient prises le plus tard possible et seul le nécessaire serait mis en œuvre. C'est ce qu'on appelle la "courbe plate" et c'est ce qui motive la programmation extrême. Cependant, ce que la littérature précédente avait découvert était la "courbe raide", avec de petits systèmes (<5 KSLOC) présentant un changement de 5: 1 et des grands systèmes ayant un changement de 100: 1.

La section cite le Centre d'ingénierie logicielle empirique de l'Université du Maryland (parrainé par la National Science Foundation). Ils ont effectué une recherche dans la littérature disponible et ont constaté que les résultats avaient tendance à confirmer un rapport de 100: 1, certains résultats indiquant une plage allant de 70: 1 à 125: 1. Malheureusement, il s’agissait généralement de projets de «grande conception initiale» gérés de manière séquentielle.

Il existe des exemples de "petits projets Java commerciaux" exécutés à l'aide de la programmation extrême. Pour chaque histoire, les efforts consacrés à la correction des erreurs, à la nouvelle conception et à la refactorisation ont été suivis. Les données montrent que, à mesure que le système se développe (plus de user stories sont implémentées), l'effort moyen tend à augmenter de manière non triviale. Les efforts de refactorisation augmentent d’environ 5% et les efforts de correction d’efforts d’environ 4%.

Ce que j'apprends, c'est que la complexité du système joue un rôle important dans la quantité d'effort nécessaire. En créant des coupes verticales dans le système, vous ralentissez le rythme de la courbe en ajoutant lentement de la complexité au lieu de l’ajouter en piles. Plutôt que de traiter de la complexité des exigences suivie d'une architecture extrêmement complexe, suivie d'une implémentation extrêmement complexe, etc., vous commencez très simplement et vous ajoutez des éléments.

Quel impact cela at-il sur le coût à réparer? En fin de compte, peut-être pas beaucoup. Cependant, il présente l'avantage de permettre un contrôle accru de la complexité (grâce à la gestion de la dette technique). En outre, les livrables fréquents souvent associés à l'agilité signifient que le projet peut s'achever plus tôt. Au lieu de livrer "le système", les éléments sont livrés jusqu'à ce que les besoins de l'entreprise soient satisfaits ou aient radicalement changé: un nouveau système (et donc un nouveau projet). est nécessaire.

Métriques et modèles en ingénierie de la qualité logicielle de Stephen Kan comprend une section au chapitre 6 sur le rapport coût-efficacité de la suppression des défauts de phase.

Il commence par citer l'article de Fagan de 1976 (également cité dans la publication Software Engineering Economics) selon lequel les retouches effectuées dans une conception de haut niveau (architecture système), une conception de bas niveau (conception détaillée) et une implémentation peuvent être entre 10 et 100 fois moins chères. que le travail effectué pendant les tests au niveau des composants et du système.

Il cite également deux publications de Freedman et Weinberg (1982 et 1984) qui traitent des grands systèmes. Le premier est "Manuel des procédures pas à pas, inspections et examens techniques" et le second est "Avis, procédures pas à pas et inspections". L'application des examens au début du cycle de développement peut réduire le nombre d'erreurs atteignant les phases de test d'un facteur 10. Cette réduction du nombre de défauts entraîne une réduction des coûts de test de 50% à 80%. Je devrais lire les études plus en détail, mais il apparaît que le coût comprend également la recherche et la correction des défauts.

Une étude réalisée en 1983 par Remus, intitulée "Validation logicielle intégrée dans la perspective des inspections / examens", a étudié le coût de la suppression des défauts dans différentes phases, en particulier les inspections de conception / code, les tests et la maintenance, à l'aide de données provenant du laboratoire IBM Santa Teresa en Californie. Les résultats cités indiquent un ratio de coûts de 1:20:82. C'est-à-dire qu'un défaut constaté lors des inspections de conception ou de code a un coût de changement de 1. Si le même défaut s'échappe lors des tests, il coûtera 20 fois plus cher. S'il parvient à échapper à un utilisateur, il corrigera jusqu'à 82 fois le coût pour corriger. Kan, utilisant des exemples de données provenant de l'installation d'IBM à Rochester, Minnessota, a constaté que le coût de suppression des défauts pour le projet AS / 400 était similaire. à 1:13:92. Cependant, il souligne que l'augmentation des coûts pourrait être due à la difficulté accrue de trouver un défaut.

Les publications de Gilb en 1993 ( "Inspection de logiciel" ) et 1999 ("Optimisation des processus de contrôle technique et de contrôle de la qualité d'ingénierie logicielle") sont citées pour corroborer les autres études.

Des informations supplémentaires peuvent être trouvées dans la page de Construx sur Augmentation du coût des défauts , qui fournit un certain nombre de références sur l'augmentation du coût de réparation des défauts. Il convient de noter que Steve McConnell, auteur de Code Complete, a fondé et travaille pour Construx.

J'ai récemment écouté une conférence intitulée Real Software Engineering donnée par Glenn Vanderburg à la conférence Lone Star Ruby en 2010. Il a donné la même conférence à la conférence Scottish Ruby et à Erubycon en 2011, à la conférence QCon San Francisco en 2012 et à la conférence sur l'architecture O'Reilly Software. en 2015 . Je n'ai écouté que la conférence Lone Star Ruby, mais le discours a évolué au fil du temps, à mesure que ses idées se précisaient.

Venderburg suggère que l'ensemble de ces données historiques indique en réalité le coût de la réparation des défauts au fil du temps, pas nécessairement à mesure du déroulement du projet. Un grand nombre des projets examinés dans les documents et ouvrages susmentionnés étaient des projets séquentiels de "cascade", où la phase et le temps allaient de pair. Cependant, un schéma similaire se dégagerait dans les projets itératifs et incrémentaux: si un défaut était injecté en une itération, il serait relativement peu coûteux de réparer cette itération. Cependant, au fur et à mesure que les itérations progressent, il se passe beaucoup de choses: le logiciel devient de plus en plus complexe, les utilisateurs oublient certains détails mineurs relatifs au travail dans des modules particuliers ou des parties du code, les exigences changent. Tout cela augmentera le coût de la réparation du défaut.

Je pense que cela est probablement plus proche de la réalité. Dans un projet en cascade, le coût augmente en raison de la quantité d'artefacts à corriger en raison d'un problème en amont. Dans les projets itératifs et incrémentaux, le coût augmente en raison de la complexité accrue du logiciel.

C'est juste une simple logique.

Erreur détectée dans la spéc.

Case : Error found while reviewing UseCase/Function spec.
Actions:
        Rewrite paragraph in error.

Case : Error found during unit test.
Actions:
        Fix code.
        (Possibly) rewrite paragraph in spec.
        rerun unit test.

Case : Error found in integration test.
        Fix code.
        (possibly) rewrite paragraph in spec.
        rerun unit test.
        build new release.
        rerun integration test for whole system.

Case : Error found in UAT
        Fix code.
        (possibly) rewrite paragraph in spec.
        rerun unit test.
        build new release.
        rerun integration test for whole system.
        deploy release to UAT.
        rerun UAT tests.


Case : Error found in production
        Fix code.
        (possibly) rewrite paragraph in spec.
        rerun unit test.
        Build release.
        rerun integration test for whole system.
        deploy release to UAT.
        rerun UAT tests.
        deploy release to production.

Comme vous pouvez le voir, plus l'erreur est détectée tardivement, plus le nombre de personnes impliquées est important, plus le travail doit être refait. Dans n'importe quel environnement "normal", la paperasserie et la bureaucratie augmentent de manière exponentielle une fois que vous avez touché UAT.

Tout cela sans inclure les coûts qu'une entreprise pourrait encourir en raison d'une erreur dans un logiciel de production (pertes de ventes, dépassement des commandes, piratage de clients, etc.).

Je ne pense pas que quiconque ait jamais réussi à écrire un système non trivial qui n'ait jamais eu de bugs en production, mais tout ce que vous pouvez faire pour attraper les bugs tôt vous fera économiser du temps et des efforts à long terme. Les revues de spécifications, les revues de code, les tests unitaires approfondis, l'utilisation de différents codeurs pour écrire les tests, etc. sont toutes des méthodes éprouvées pour détecter les bogues tôt.

Je pense que cela concerne, et a toujours été, la gestion des risques et l’économie. Quel est le coût de la réduction du nombre de défauts par rapport à la valeur actuelle de l’impact des défauts futurs? La trajectoire de l’oiseau jaune légèrement en retrait dans Angry Birds n’équivaut pas à celle d’un missile de croisière Tomahawk. Les développeurs de logiciels dans les deux projets ne peuvent pas prendre de décisions en fonction de cette table. À cet égard, rien ne change.

À mon avis, cela a tendance à se faire par le biais du retour d’information. En raison des bogues coûteuses sur le terrain, les entreprises resserrent leurs processus qualité alors qu’aucune plainte de la part du secteur ne l’assouplit. Ainsi, avec le temps, les sociétés de développement de logiciels auront tendance à converger ou à osciller autour de quelque chose qui leur convient (+/-). Code Complete peut influer sur certaines valeurs initiales ou peut entraîner les entreprises légèrement d'une manière ou d'une autre. Une entreprise qui consacre trop d’efforts à éliminer les défauts que personne ne remarquerait risque probablement de perdre des clients au profit d’un concurrent doté d’une approche plus optimisée. D'autre part, une entreprise qui commercialise des produits buggy va également fermer ses portes.

Quelques articles pertinents à partir d'une recherche rapide (lisez les articles complets, faites plus de recherches et formez votre propre opinion):

Analyse systématique de la littérature sur la recherche en coût de la qualité des logiciels (2011)

"Alors que la communauté a ainsi développé une solide compréhension de la structure du domaine de recherche, la validation empirique fait souvent défaut. Seul environ un tiers des articles analysés présente une étude de cas ou des résultats empiriques plus détaillés. Cela semble insuffisant pour la recherche du coût de la qualité logicielle. , qui repose fortement sur des données quantitatives pour générer de nouvelles découvertes. Il est donc nécessaire d’adopter de nouvelles approches pour collecter des données sur les coûts de qualité, ainsi que de renforcer la coopération entre l’industrie et la recherche afin de rendre ces données disponibles. "

Évaluation du coût de la qualité du logiciel (1998)

"Enfin, nous avons constaté qu'il était important de surveiller les coûts de conformité et de non-conformité des logiciels afin que les stratégies de conformité puissent être ajustées afin de réduire les coûts totaux de la qualité des logiciels."

Le comportement des coûts des défauts logiciels (2004)

Résumé ... "Les recherches en cours tentent de mettre à jour nos connaissances sur la manière dont les défauts et leur coût de correction (ou de les laisser non corrigés) influence le coût final du logiciel" ... "les défauts non corrigés deviennent exponentiellement plus coûteux à chaque phase dans laquelle ils ne sont pas résolus "

Couverture des tests et défauts après vérification: une étude de cas multiple (2009)

"Nous constatons également que l'effort de test augmente de manière exponentielle avec la couverture de test, mais que la réduction des problèmes sur le terrain augmente de manière linéaire avec la couverture de test. Cela suggère que pour la plupart des projets, les niveaux de couverture optimaux seront probablement bien inférieurs à 100%".

Combler le fossé entre le processus de test du logiciel et la valeur commerciale: étude de cas (2009)

Je ne peux pas répondre à votre première partie de la question, car je n’ai tout simplement pas vérifié. Mais je peux formuler une réponse à votre deuxième question et peut-être une allusion à une réponse possible à la première.

Il va sans dire que certains des facteurs les plus importants dans le coût de la correction d'un bogue, à l'exception des outils de développement intrinsèquement difficiles à utiliser, sont la complexité intrinsèque du produit et la capacité de l'utilisateur à comprendre ce produit.

En me concentrant un instant sur le code, en partant du principe que le code est généralement écrit et géré par des développeurs capables de gérer les complexités intrinsèques de leur code (ce qui peut ne pas être tout à fait vrai et mériter son propre débat), j'oserais suggérer que L’importance cruciale dans la maintenance, et donc dans la correction des bugs, est la capacité des mainteneurs à comprendre ledit code.

La capacité à comprendre le code est grandement améliorée par l’utilisation d’outils d’ingénierie logicielle éprouvés qui, malheureusement, sont pour la plupart sous-utilisés ou mal utilisés. Utiliser le bon niveau d'abstraction, la modularité, l'amélioration de la cohésion des modules et la réduction du couplage des modules sont des outils essentiels pour faire face à la complexité et nécessitant une utilisation appropriée. Le codage aux interfaces ou, dans la programmation orientée objet, en évitant l'utilisation excessive de l'héritage par rapport à la composition, emballage par fonctionnalité, sont certaines des techniques qui font souvent l'objet d'une attention insuffisante dans le codage.

Je pense que les réalités de la concurrence dans le secteur exercent une influence négative sur l’utilisation de méthodes d’amélioration de la qualité pour le développement de logiciels, tout en limitant la qualité intrinsèque des logiciels en tant que mesure du succès actuel.

Par conséquent, je pense que, dans l’industrie, les logiciels ont tendance à souffrir davantage des coûts de correction des bogues à mesure qu’ils grandissent. Avec de tels produits, les bugs deviennent de plus en plus difficiles à résoudre, car le système devient plus difficile à comprendre au fur et à mesure de sa croissance. Les préoccupations introduites par chaque fonctionnalité sont trop associées à d'autres préoccupations, ce qui complique la compréhension. Ou bien, le bon niveau d'abstraction n'a pas été utilisé, ce qui a empêché le responsable de la maintenance de formuler un modèle correct du système et de raisonner à son sujet. Le manque de documentation n'aide certainement pas.

Il y a des exceptions. Je suis sûr que Google ne fonctionne pas à son rythme sans de solides pratiques soutenues par des développeurs stellaires. Et d'autres sont probablement dans la même situation. Mais pour la majorité du logiciel, je ne serais pas surpris si les données ne confirment en effet la demande en code complet .

Une autre réponse! Cette fois, pour répondre à la question du titre "Le logiciel morhtodoligy repose-t-il sur des données erronées".

La vraie réponse est "il n'y a pas de données". Comme il n’existe pas de masse de données fiable sur les projets logiciels, il présente des défauts, des succès de mise sur le marché, etc.

Toutes les tentatives de collecte de ces données ont été sous-financées, statistiquement imparfaites ou si spécifiques à un projet particulier qu'il est impossible d'en tirer des conclusions générales.

De plus, je ne pense pas qu'il y en aura jamais, le processus de développement logiciel est trop subjectif et glissant pour une mesure stricte. Les organisations les mieux placées pour collecter ce type de données (les grands éditeurs de logiciels et les intégrateurs de systèmes) savent pertinemment que toute donnée recueillie à partir de leurs performances serait profondément embarrassante.

Les seuls organismes qui publient des chiffres sur le coût et le succès des projets de logiciels
sont les ministères, et alors seulement parce qu'ils doivent le faire, et oui, ces chiffres sont profondément embarrassants, quel que soit le résultat.

En conclusion, toutes les études de logiciels sont donc nécessairement purement subjectives, car il n’existe aucune donnée réelle sur laquelle fonder une conclusion objective.