• Aucun résultat trouvé

Besoins d’outils pour l’analyse statistique

Une fois en possession d’un tel tableau, il faut mener ce que l’on appelle l’analyse

Figure 3.1 – Les données de quantification relative peuvent être structurées en un

ensemble de trois tableaux : le tableau central contient les valeurs d’abondance de chaque entité chimique E pour chaque réplicat (ou échantillon) R. Le tableau du haut contient des métadonnées associées aux échantillons (par exemple, afin d’indiquer quel échantillon appartient à quelle condition biologique à comparer aux autres, ou les niveaux de réplication des échantillons). Enfin, le tableau de droite fourni les métadonnées associées aux entités chimiques (par exemple, pour un peptide, la ou les protéines d’appartenance).

protéines que l’on pense significativement différentiellement abondantes entre les conditions comparées, et d’associer à cette liste un certain nombre de garde-fous statistiques garantissant sa qualité. Naturellement, un telle analyse quantitative ne correspond ni aux missions, ni aux compétences d’un protéomicien. Il y a donc deux possibilités : la première consiste à dédier ce travail à un chargé d’études en statistiques ou en biostatistiques. Cette stratégie peut bien fonctionner mais risque de correspondre à un travail très répétitif et à faible valeur ajoutée pour le chargé d’étude, tout en rendant difficile la planification de son travail sur le très grand nombre de projets où il sera impliqué. La seconde possibilité est de faire porter les efforts sur le développement d’un outil qui permettra ensuite aux protéomiciens de conduire l’analyse quantitative par eux-mêmes, pour peu qu’ils aient suivi une formation minimale. Le risque de cette approche serait de finalement dépenser plus de temps en développement d’outils que le temps qu’aurait pris le traitement direct

des données. Finalement, nous avons pris le parti de développer des outils statistiques pour le pipeline le plus utilisé (la protéomique quantitative relative label-free), et de fournir une expertise de type “chargé d’études” pour les projets plus atypiques.

Le cahier des charges d’un outil permettant de mener une analyse quantitative exprime plusieurs des besoins utilisateurs : celui d’outils, d’interfaces graphiques et de scénarios d’usage, l’ensemble étant par ailleurs gouverné par des contraintes temporelles fortes :

Une collection d’outils statistiques : par ordre chronologique, c’est la

pre-mière demande qui apparaît : beaucoup d’outils correspondant à tout ce qui a déjà été utilisé dans la littérature protéomique, afin de pouvoir tout tester, et choisir ce qui semble le mieux. À l’inverse, la nouveauté ou l’originalité méthodologique n’est pas demandée (que ce soit par pragmatisme, ou par crainte). Il est donc avant tout attendu une ré-implémentation de l’existant. Face à cette demande, les packages R sont une bénédiction : la collection demandée est là ; et elle est pléthorique.

Des interfaces graphiques : le second besoin apparaît au moment de prendre

les algorithmes en main. Il n’est ni dans les compétences, ni dans les intérêts des pro-téomiciens de coder correctement un script R. Il faut donc développer des interfaces simplifiées leur permettant de travailler (des fonctions simplifiées, un interfaçage avec un tableur, ou des interfaces graphiques). En fonction du choix du type d’in-terface, le travail d’ingénierie demandé sera plus ou moins lourd, et permettra de plus ou moins autonomiser les utilisateurs.

Des scénarios d’utilisation : très rapidement, l’utilisateur se rend compte

qu’il peut-être potentiellement noyé sous le choix des algorithmes à appliquer ; et qu’appliquer une succession d’essais/erreurs sur les données issues d’un projet de recherche (et non d’un benchmark) jusqu’à trouver la protéine espérée est dange-reux. Dès lors, le chercheur en data science peut entamer un travail méthodologique réellement intéressant, visant à : (i) avoir un regard critique sur chaque algorithme afin d’en déterminer les cas d’usages adaptés ou la paramétrisation optimale ; (ii) la définition de pipelines d’analyse robustes et génériques à un grand nombre de situations (quels algorithmes ? appliqués dans quel ordre ?), ainsi que la justification des choix que cela induit ; (iii) le rappel de certaines bonnes pratiques statistiques qui peuvent être oubliées avec le temps. Concrètement, tout ce travail peut être valorisé par des publications de types “review”, “viewpoint”, “tutorial”, “technical

brief ”, voire “guidelines” et constitue, au-delà du travail de recherche, un élément

que je pense être déterminant pour le bon fonctionnement d’une communauté inter-disciplinaire. C’est notamment ainsi que j’ai pu faire valoriser les travaux du groupe KDPD sur différents sujets (qui seront détaillés dans la section suivante) :

– Réflexions sur l’imputation des valeurs manquantes [J’1] (review)

– Analyse critique d’un test statistique régulièrement mal utilisé en protéo-mique [J’2] (viewpoint)

– Réflexions sur le contrôle des fausses découvertes [J’3] (technical brief ) Par ailleurs, au-delà de leurs valorisations, ces réflexions ont permis d’améliorer la qualité des pipelines de traitement des données utilisés au laboratoire, et donc de participer à l’amélioration de la qualité des publications “de découvertes” associées.

Un processus de développement rapide : comme cela a déjà été évoqué (cf.

p.40), les protéomiciens abordent simultanément un grand nombre de problèmes et de difficultés, de sorte qu’il est légitime pour eux de ne les prendre en compte que

quand ils se présentent effectivement. Ainsi, les besoins statistiques ne sont expri-més qu’une fois les données produites, ne laissant que peu de temps à la réflexion méthodologique. Cette difficulté est connue de tous les porteurs de projets interdisci-plinaires, où finalement, les différents work packages ne peuvent être que faiblement intégrés, afin d’éviter les interblocages. Cela est d’autant plus vrai quand le versant applicatif est porté par une plateforme fournissant un service à la communauté, plu-tôt que par une équipe de recherche pouvant se contenter de prototypes. La plupart des choix technologiques (décrits dans le paragraphe suivant) ont donc été réalisés afin de permettre une réactivité maximale.