Je dois faire une confession. Je dois admettre que le fait d'être un fournisseur de logiciels et de services SEND me pousse à avoir un fort parti pris sur la manière dont je pense que la norme SEND devrait être définie et mise en œuvre.
Dans les deux derniers messages, nous avons discuté de la flexibilité ou de la "subjectivité" de la norme SEND. Vous avez peut-être remarqué, d'après mon ton, que j'ai une aversion particulière pour cette flexibilité. J'ai essayé de le cacher, mais malheureusement mes propres préjugés transparaissent.
Pour expliquer en quoi le fait d'être un vendeur favorise ce parti pris, j'ai pensé qu'il serait bon d'examiner rapidement quelques-uns des avantages et des inconvénients d'une norme aussi souple.
Pour
La flexibilité avait pour but de faciliter l'adoption de la norme SEND. En raison des grandes différences dans la manière dont certaines données sont collectées et rapportées, la norme SEND ne pouvait pas être trop prescriptive dans ce qu'elle attendait des données. Il devait être suffisamment souple pour que, si l'étude comportait un élément particulier de données ou de métadonnées associé à un résultat, il y ait une place pour cet élément, mais s'il n'était pas saisi, cela ne posait pas de problème non plus.
Cela présente l'avantage de permettre à toutes les organisations d'adopter l'ENVOI, qu'elles saisissent ou non cet élément d'information particulier. Le même principe s'applique aux variables temporelles. Si l'on examine les données de l'étude, si l'on ne dispose que de dates calendaires, c'est parfait. S'il y a des dates et des heures, c'est également très bien. Toutefois, s'il n'y a que des numéros de jours d'étude, c'est tout aussi acceptable. Il suffit de renseigner les informations temporelles disponibles et de ne pas s'inquiéter de ce qui manque.
En adoptant cette approche, nous disposons d'une norme beaucoup plus large qui devrait permettre un plus grand nombre d'études et de méthodes de collecte.
Ça a l'air génial, non ? Mais quel est le problème ?
Cons
Pour de nombreuses organisations qui utilisent des ensembles de données SEND, le manque de cohérence d'une étude à l'autre pose plusieurs problèmes. Le plus évident d'entre eux est l'entrave à l'analyse croisée des études. Comment comparer deux études similaires lorsque les données sont restituées de manière si différente ? Il s'agit là d'un problème commun à tous ceux qui tentent de développer de tels outils. C'est difficile lorsque nous ne pouvons pas compter sur le fait que les variables sont renseignées de manière cohérente. À titre d'exemple, la semaine dernière, nous avons débattu de l'étiquette Nominal, car il s'agit d'une variable qui, en plus de pouvoir contenir un numéro de jour ou de semaine, peut ou non inclure des informations sur le point temporel, des informations catégorielles ou des informations sur la programmation. Toutes ces utilisations sont acceptables, mais qu'est-ce que cela signifie pour l'outil qui consomme les données ?
Une autre difficulté réside dans le fait que chaque organisation a développé sa propre interprétation de la norme. Cela complique la tâche de l'humble vendeur qui doit produire des outils permettant de créer et d'utiliser SEND de différentes manières afin de répondre aux besoins des diverses organisations. Il est donc évident que mon parti pris transparaît fortement ici, car je préférerais de loin que nous puissions tous utiliser SEND de la même manière. Pas d'options, pas de flexibilité.
J'ai commencé ce billet en avouant qu'en tant que vendeur, j'ai un parti pris mal dissimulé contre la flexibilité de SEND, et à la fin, ce billet expose ce parti pris à la vue de tous. En plus de faciliter la tâche des développeurs d'outils, je pense que l'ensemble de l'industrie bénéficierait d'un SEND plus restrictif. Que vous soyez d'accord ou non, j'aimerais connaître votre opinion. Envoyez vos courriels à l'adresse habituelle instem
Jusqu'à la prochaine fois
Marc
