Pour ceux qui continuent, je vois deux éléments à prendre en compte dans cette discussion. Le premier est la possibilité d'exprimer un problème (une fonctionnalité du logiciel) de façon objective, le second concerne la vérité de cet expression .

Pour préciser le premier point, l'énoncé d'un fait peut se faire de façon subjective ou bien objective. L'énoncé sera subjectif lorsqu'il fait intervenir le "sujet" , c'est-à-dire l'interprétation, et il sera objectif lorsqu'il se rapporte uniquement à "l'objet" considéré.

Cela peut paraître évident, il n'est pourtant pas toujours facile de faire intuitivement la différence.
D'abord parce qu'un énoncé passant toujours par un humain (à l'écrit ou à l'oral) il est toujours soumis à un suspicion de subjectivité. Ensuite parce que par nature on est très friand de subjectivité et on a plutôt tendance à l'accueillir qu'a la rejeter.
Par exemple si je constate les faits suivants :

- les marchés sont à la baisse,
- une annonce politique vient d'être faite


Je peux énoncer de façon subjective : "le marché est influencé à la baisse par les orientations politiques actuelles" .
De façon objective, je dirais que "le marché est en chute depuis l'annonce des nouvelles orientations politiques".

La distinction entre les 2 formules n'est pas forcément évidente si l'on n'y prend pas garde. La seconde formulation pourtant ne relate que les faits (même si la formulation pourrait laisser penser à un lien de cause à effet) et permettra d'ouvrir la discussion y compris sur la pertinence de déduire une influence possible entre les événements.

Une formulation objective semble donc à priori plus forte et moins sujette à l'erreur qu'une formulation subjective.

Il est une série d'énoncés qui sont objectifs par nature, les énoncés mathématique. Si je dis "quand j'ajoute cinq et sept, j'obtiens douze" ça ne prête pas à interprétation.
Les mathématiques en tant que tels ne sont cependant pas des objets naturels, ils ont issus de la pensée. C'est une particularité humaine que d'être capable d'élaborer des théories de façon à constituer un panel de connaissances objectives.
K. Popper prêche même pour l'existence d'un "monde 3"qui serait celui de la connaissance objective, capable d'être persistant même en dehors des individus (le "monde 1" étant physique et le" monde 2" celui du vivant et de la subjectivité) . On n'est pas obligé de croire à cette interprétation mais je la trouve commode pour éclairer certaines choses.

Dans les projets informatiques on cherche à formuler les besoins de façon objective. On peut discuter de cette pertinence et je crois que c'est ce que font les méthodes Agiles, mais regardons d'abord l'approche historique des problèmes:
Dans les méthodes traditionnelles, on a cherché à graver les énoncés du projet en passant par des théories et des modèles pseudo-mathématique dont est certain de l'objectivité. Il est vrai qu'une relation "1,n" entre un client et des commandes coupe court à toute interprétation.
Pour poser cette relation objective, il aura souvent fallu venir à bout des hésitations du métier… Mais c'est la règle. Et le fer de lance du projet informatique depuis des décennies à été de mettre au point méthodes et théories de façon à garantir une information objective.
Finalement, le premier objectif du projet mené en mode classique est de faire passer la demande utilisateur du "monde 2" vers le" monde 3". Et avec les méthodes traditionnelles le projet reste en orbite dans le" monde 3" pendant longtemps…

Mais une information n'est pas vraie simplement parce qu'elle est objective. Je peux objectivement énoncer que l'eau de la méditerranée est bleue, tout le monde peut-être d'accord la dessus mais ce n'en est pas moins faux pour autant (il suffit de prendre un seau d'eau et de vérifier sa couleur pour le constater).
Dans le cadre d'un projet vouloir objectiver toute les informations en les "théorisant" n'est donc pas la meilleure solution pour réduire les erreurs.

L'approche Agile prend un autre parti, celui qui consiste à réduire l'erreur (et l'effort !) en utilisant les ressources naturelles de chacun des "mondes".

Le "monde 1", physique, est objectif par nature , c'est le monde des objets. Utilisons cet espace pour l'information sur l'avancement du projet: on voit, on touche, on déplace… Choisir de passer par là réduit automatiquement le champ de la subjectivité (kanban bien sur, mais aussi affichage de la "définition of done" par exemple).

Le problème est différent pour ce qui concerne les fonctionnalités, objet du développement, cible du projet. La subjectivité est en grande partie nécessaire, elle est créatrice de valeur. Utilisons au mieux le "monde 2", donnons des espaces d'expression et favorisons les échanges fréquents.

La réalisation quant à elle utilise en grande partie les ressources du "monde 3". Elle passe par la conceptualisation et par la maîtrise de beaucoup de théories. La compétence dans ce domaine, c'est la valeur ajoutée de l'équipe.
Mais comme la seule façon de s'assurer que la théorie fournit le résulta attendu c'est la confrontation aux "mondes inférieurs", il faut livrer souvent et se soumettre à la critique subjective des utilisateurs.

Je vous avais prévenu, tout ça ne répond quand même pas clairement à la question du BDD. Mais ça me donne quelques idées... que je creuserai plus tard. ...