Modélisation et score de complexes protéine-ARN - Thèse Informatique

Modélisation et score de complexes protéine-ARN - thèse Informatique - Revenir à l'accueil

 

Autres thèses en informatique :

[TXT]

 APISENSE-a-distribut..> 05-Jan-2015 08:09  5.7M  

[TXT]

 APISENSE-terminaux-i..> 04-Jan-2015 21:53  5.4M  

[TXT]

 Addition-formulae-on..> 04-Jan-2015 21:26  3.0M  

[TXT]

 Architecture-de-comm..> 05-Jan-2015 08:04  4.4M  

[TXT]

 Catalogage-de-petits..> 05-Jan-2015 08:06  3.8M  

[TXT]

 Classification-et-ca..> 04-Jan-2015 11:58  1.3M  

[TXT]

 Collaboration-de-tec..> 04-Jan-2015 21:27  2.4M  

[TXT]

 Completion-combinato..> 05-Jan-2015 08:11  2.6M  

[TXT]

 Contributions-a-la-v..> 04-Jan-2015 21:51  5.4M  

[TXT]

 Cryptographie-sur-le..> 05-Jan-2015 08:01  3.4M  

[TXT]

 Detection-de-rails-m..> 05-Jan-2015 08:04  5.1M  

[TXT]

 Environnements-urbai..> 05-Jan-2015 08:03  6.3M  

[TXT]

 Equilibrage-de-charg..> 04-Jan-2015 21:25  3.2M  

[TXT]

 Evaluation-analytiqu..> 05-Jan-2015 08:07  3.5M  

[TXT]

 Faciliter-le-develop..> 04-Jan-2015 21:56  4.4M  

[TXT]

 Factorisation-matric..> 04-Jan-2015 11:59  2.7M  

[TXT]

 Generation-automatiq..> 03-Jan-2015 22:04  2.6M  

[TXT]

 Gestion-de-la-variab..> 04-Jan-2015 21:55  4.8M  

[TXT]

 Idéalisation-d-asse..> 04-Jan-2015 11:57  2.1M  

[TXT]

 Inference-d-invarian..> 04-Jan-2015 11:58  1.5M  

[TXT]

 Integration-de l-inf..> 04-Jan-2015 21:25  3.4M  

[TXT]

 Intelligence-en-essa..> 05-Jan-2015 08:03  5.6M  

[TXT]

 Interrogation-de-gra..> 03-Jan-2015 22:04  2.9M  

[TXT]

 La-gestion-du-trafic..> 03-Jan-2015 22:01  4.1M  

[TXT]

 Langage-de-mashup-Th..> 04-Jan-2015 21:24  4.1M  

[TXT]

 Les-logiciels-de-ges..> 03-Jan-2015 22:03  3.1M  

[TXT]

 Lh-rs-p2p-une-nouvel..> 04-Jan-2015 11:59  2.7M  

[TXT]

 Mesure-de-la-fragili..> 04-Jan-2015 21:24  3.8M  

[TXT]

 Meta-modelisation-du..> 04-Jan-2015 21:56  4.1M  

[TXT]

 Methode-de-classific..> 04-Jan-2015 11:58  1.3M  

[TXT]

 Methode-de-game-desi..> 05-Jan-2015 08:10  4.2M  

[TXT]

 Methodes-sequentiell..> 04-Jan-2015 21:27  2.2M  

[TXT]

 Mise-en-oeuvre-appli..> 04-Jan-2015 21:54  4.4M  

[TXT]

 Modele-et-experience..> 05-Jan-2015 08:01  3.8M  

[TXT]

 Modelisation-d-une-a..> 04-Jan-2015 21:53  5.0M  

[TXT]

 Modelisation-et-dete..> 04-Jan-2015 11:57  1.6M  

[TXT]

 Normalisation-et-App..> 03-Jan-2015 22:01  4.1M  

[TXT]

 Nouvelles-approches-..> 05-Jan-2015 08:09  2.3M  

[TXT]

 Planification-d-une-..> 05-Jan-2015 08:06  4.1M  

[TXT]

 Prise-en-compte-de-l..> 03-Jan-2015 22:04  2.8M  

[TXT]

 Qualification-system..> 04-Jan-2015 21:26  2.8M  

[TXT]

 Reconnaissance-de-co..> 03-Jan-2015 22:03  3.6M  

[TXT]

 Segmentation-supervi..> 04-Jan-2015 11:58  1.3M  

[TXT]

 Services-de-repartit..> 03-Jan-2015 21:59  4.7M  

[TXT]

 Techniques-visuelles..> 04-Jan-2015 21:27  2.7M  

[TXT]

 The-Emergence-of-Mul..> 03-Jan-2015 22:05  2.5M  

[TXT]

 Trigraphes-de-Berge-..> 03-Jan-2015 22:02  3.9M  

[TXT]

 Un-ilot-formel-pour-..> 05-Jan-2015 08:07  3.1M  

[TXT]

 Vers-une-capitalisat..> 03-Jan-2015 22:00  4.6M
Congrès d'informatique :

[TXT]

 Application-Agnostic..> 03-Jan-2015 21:16  2.1M  

[TXT]

 Continuity-Editing-f..> 03-Jan-2015 17:35  4.0M  

[TXT]

 Double-WP-Vers-une-p..> 03-Jan-2015 17:36  4.0M  

[TXT]

 Effective-Reproducib..> 03-Jan-2015 21:18  2.0M  

[TXT]

 Enforcing-reuse-and-..> 03-Jan-2015 21:17  2.0M  

[TXT]

 Extracting-Bounded-s..> 03-Jan-2015 21:19  4.0M  

[TXT]

 Fingerprint-Quality-..> 03-Jan-2015 21:16  2.1M  

[TXT]

 GPU-Load-Balance-Gui..> 03-Jan-2015 21:18  4.0M  

[TXT]

 Minkowski-sum-of-pol..> 03-Jan-2015 21:17  2.0M  

[TXT]

 Quality-Assessment-o..> 03-Jan-2015 21:16  2.1M  

[TXT]

 Rester-statique-pour..> 03-Jan-2015 17:35  4.0M  

[TXT]

 The-Power-of-Polynom..> 03-Jan-2015 21:16  2.1M  
Cours d'informatique :

[TXT]

 Analyse-numerique-Co..> 03-Jan-2015 17:33  3.0M  

[TXT]

 Approches-m-k-firm-p..> 03-Jan-2015 17:27  3.7M  

[TXT]

 COURS-LA-CULTURE-INF..> 03-Jan-2015 17:25  3.8M  

[TXT]

 CRYPTANALYSE-DE-RSA-..> 03-Jan-2015 17:33  3.0M  

[TXT]

 Cours-Interconnexion..> 03-Jan-2015 17:34  3.0M  

[TXT]

 Cours-d-Analyse-et-C..> 03-Jan-2015 17:22  3.9M  

[TXT]

 Efficient-C++finite-..> 03-Jan-2015 17:30  3.5M  

[TXT]

 Efficient-C++finite-..> 03-Jan-2015 17:31  3.2M  

[TXT]

 Fondements-de-l-Info..> 03-Jan-2015 17:22  4.0M  

[TXT]

 INTRODUCTION-A-L-INF..> 03-Jan-2015 17:24  3.8M  

[TXT]

 Informatique-et-Ling..> 03-Jan-2015 17:24  3.8M  

[TXT]

 Initiation-a-l-infor..> 03-Jan-2015 17:26  3.8M  

[TXT]

 Intelligence-Artific..> 03-Jan-2015 15:16  2.5M  

[TXT]

 Introduction-a-l-ana..> 03-Jan-2015 17:27  3.7M  

[TXT]

 Introduction-a-la-ge..> 03-Jan-2015 17:26  3.8M  

[TXT]

 Le-routage-externe-B..> 03-Jan-2015 17:32  3.1M  

[TXT]

 Le-systeme-d-informa..> 03-Jan-2015 17:32  3.1M  

[TXT]

 Lecture1_Linear_SVM_..> 03-Jan-2015 14:57  2.4M  

[TXT]

 Lecture2_Linear_SVM_..> 03-Jan-2015 14:56  2.4M  

[TXT]

 Lecture3_Linear_SVM_..> 03-Jan-2015 14:56  2.4M  

[TXT]

 Lecture4_Kenrels_Fun..> 03-Jan-2015 14:55  2.4M  

[TXT]

 Lecture5_Kernel_SVM...> 03-Jan-2015 14:55  2.4M  

[TXT]

 Lecture6_SVDD.pdf.htm   03-Jan-2015 14:54  2.4M  

[TXT]

 Lecture7_Cross_Valid..> 03-Jan-2015 14:54  2.4M  

[TXT]

 Lecture8_Multi_Class..> 03-Jan-2015 14:57  2.4M  

[TXT]

 Lecture9_Multi_Kerne..> 03-Jan-2015 14:53  2.5M  

[TXT]

 Lecture10_Outilier_L..> 03-Jan-2015 14:53  2.5M  

[TXT]

 Les-reseaux-sans-fil..> 03-Jan-2015 15:17  2.5M  

[TXT]

 NooJ-pour-l-Intellig..> 03-Jan-2015 17:30  3.2M  

[TXT]

 Outils-Logiques-pour..> 03-Jan-2015 15:15  2.8M  

[TXT]

 Presentation-de-la-r..> 03-Jan-2015 17:33  3.0M  

[TXT]

 Projet-IP-SIG-Signal..> 03-Jan-2015 15:16  2.5M  

[TXT]

 Robotique-Mobile-PDF..> 03-Jan-2015 15:16  2.6M  

[TXT]

 Systeme-informatique..> 03-Jan-2015 15:17  2.5M  

[TXT]

 Systemes-Multi-Agent..> 03-Jan-2015 17:28  3.5M  

[TXT]

 Tutoriel-Android-TP-..> 03-Jan-2015 14:57  2.3M  

[TXT]

 Understanding-SVM-th..> 03-Jan-2015 14:57  2.4M  

[TXT]

 Une-histoire-de-la-m..> 03-Jan-2015 17:28  3.5M  

[TXT]

 Une-introduction-aux..> 03-Jan-2015 17:31  3.1M  

[TXT]

 Vers-une-signalisati..> 03-Jan-2015 17:25  3.8M 
Mod´elisation et score de complexes prot´eine-ARN Adrien Guilhot-Gaudeffroy To cite this version: Adrien Guilhot-Gaudeffroy. Mod´elisation et score de complexes prot´eine-ARN. Bioinformatics. Universit´e Paris Sud - Paris XI, 2014. French. . HAL Id: tel-01081605 https://tel.archives-ouvertes.fr/tel-01081605 Submitted on 10 Nov 2014 HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers. L’archive ouverte pluridisciplinaire HAL, est destin´ee au d´epˆot et `a la diffusion de documents scientifiques de niveau recherche, publi´es ou non, ´emanant des ´etablissements d’enseignement et de recherche fran¸cais ou ´etrangers, des laboratoires publics ou priv´es.UNIVERSITE´ PARIS-SUD E´ COLE DOCTORALE 427 : INFORMATIQUE PARIS-SUD LABORATOIRE : LABORATOIRE DE RECHERCHE EN INFORMATIQUE THESE ` INFORMATIQUE par Adrien GUILHOT-GAUDEFFROY Modelisation et score de ´ complexes proteine-ARN ´ Date de soutenance : 29 / 09 / 2014 Composition du jury : Directeurs de these : ` M. Jer´ ome Az ˆ e Professeur (LIRMM, Universit ´ e de Montpellier 2) ´ Mme Julie Bernauer Chargee de recherche (Inria, LIX, ´ Ecole Polytechnique) ´ Mme Christine Froidevaux Professeure (LRI, Universite Paris-Sud, invit ´ ee) ´ Rapporteurs : Mme Anne Poupon Directrice de Recherche CNRS (BIOS, INRA Tours) Mme Celine Rouveirol Professeure (LIPN, Universit ´ e Paris-Nord) ´ Examinateurs : M. Philippe Dague Professeur (LRI, Universite Paris-Sud) ´ Mme Beatrice Duval Ma ´ ˆıtre de conferences HDR (LERIA, Universit ´ e d’Angers) ´iiSommaire Sommaire iii Table des figures ix Liste des tableaux xi Introduction xv 1 Contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv 2 Structure des proteines et des ARN . . . . . . . . . . . . . . . . . . . . ´ xvi 2.1 Les acides amines . . . . . . . . . . . . . . . . . . . . . . . . . . ´ xviii 2.2 Les acides nucleiques . . . . . . . . . . . . . . . . . . . . . . . . ´ xx 2.3 La structure primaire ou sequence . . . . . . . . . . . . . . . . . ´ xxi 2.3.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . ´ xxi 2.3.2 Determination . . . . . . . . . . . . . . . . . . . . . . . ´ xxiii 2.4 La structure secondaire . . . . . . . . . . . . . . . . . . . . . . . xxiii 2.4.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . ´ xxiii 2.4.2 Determination ´ a partir d’une solution . . . . . . . . . . . ` xxvi 2.4.3 Determination ´ a partir des coordonn ` ees atomiques . . ´ xxvii 2.4.4 Prediction . . . . . . . . . . . . . . . . . . . . . . . . . . ´ xxvii 2.5 La structure tertiaire . . . . . . . . . . . . . . . . . . . . . . . . . xxvii 2.5.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . ´ xxvii 2.5.2 Determination . . . . . . . . . . . . . . . . . . . . . . . ´ xxviii 2.5.3 Prediction . . . . . . . . . . . . . . . . . . . . . . . . . . ´ xxix Modelisation par homologie . . . . . . . . . . . . . . . . . ´ xxix Les methodes d’enfilage . . . . . . . . . . . . . . . . . . . ´ xxix La modelisation ´ ab initio . . . . . . . . . . . . . . . . . . . xxix Evaluation des pr ´ edictions : l’exp ´ erience C ´ ASP . . . . . . xxix iiiSommaire 2.6 La structure quaternaire . . . . . . . . . . . . . . . . . . . . . . . xxx 2.6.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . ´ xxx 2.6.2 Determination . . . . . . . . . . . . . . . . . . . . . . . ´ xxxi 2.6.3 Prediction . . . . . . . . . . . . . . . . . . . . . . . . . . ´ xxxi 3 Les complexes proteine-prot ´ eine et prot ´ eine-ARN . . . . . . . . . . . . ´ xxxii 3.1 Fonctions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxii 3.2 Detection exp ´ erimentale biochimique prot ´ eine-prot ´ eine . . . . . ´ xxxii 3.2.1 Le double-hybride sur la levure . . . . . . . . . . . . . . xxxii 3.2.2 Utilisation de marqueurs (TAP-tag et FLAP-tag) . . . . xxxii 3.3 Les methodes d’amarrage . . . . . . . . . . . . . . . . . . . . . . ´ xxxiv 3.3.1 Le probleme . . . . . . . . . . . . . . . . . . . . . . . . ` xxxiv 3.3.2 Les algorithmes . . . . . . . . . . . . . . . . . . . . . . xxxv 3.3.3 La transformation de Fourier . . . . . . . . . . . . . . . xxxvi 3.3.4 Algorithmes d’amarrage et partitionnement du probleme ` xxxvi 4 La tessellation de Vorono¨ı et ses deriv ´ ees pour l’amarrage . . . . . . . ´ xxxvii 4.1 Constructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxvii 4.2 Mesures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxix 5 Fonctions de score . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xl 6 Apprentissage automatise . . . . . . . . . . . . . . . . . . . . . . . . . . ´ xli 6.1 Paradigme de l’apprentissage supervise . . . . . . . . . . . . . . ´ xli 6.2 Criteres d’ ` evaluation . . . . . . . . . . . . . . . . . . . . . . . . . ´ xliii 6.2.1 Criteres d’ ` evaluation globaux . . . . . . . . . . . . . . . ´ xliii 6.2.2 Criteres d’ ` evaluation “locaux” . . . . . . . . . . . . . . . ´ xliv 1 Donnees 1 ´ 1.1 Jeux de donnees de complexes prot ´ eine-ARN . . . . . . . . . . . . . . ´ 1 1.1.1 Jeu de ref ´ erence des complexes prot ´ eine-ARN connus . . . . . ´ 1 1.1.2 Jeux d’evaluation des proc ´ edures d’amarrage : ´ Benchmarks . . 2 1.2 Nettoyage des donnees . . . . . . . . . . . . . . . . . . . . . . . . . . . ´ 2 1.3 Utilisation des donnees . . . . . . . . . . . . . . . . . . . . . . . . . . . ´ 3 1.3.1 Contexte biologique : definitions . . . . . . . . . . . . . . . . . . ´ 4 1.3.2 Ensemble des perturbations pour l’apprentissage . . . . . . . . . 4 1.3.3 Mesure de similarite : le RMSD . . . . . . . . . . . . . . . . . . . ´ 5 1.3.4 Etiquetage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ´ 6 1.3.5 Constitution des jeux d’apprentissage et de test . . . . . . . . . 7 iv1.4 Mesures d’evaluation locales . . . . . . . . . . . . . . . . . . . . . . . . ´ 8 2 Approche Rosetta et adaptation 11 2.1 Presentation de RosettaDock . . . . . . . . . . . . . . . . . . . . . . . . ´ 11 2.1.1 Amarrage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.1.1.1 Gen´ eration des candidats . . . . . . . . . . . . . . . . . ´ 11 2.1.1.2 Tri des candidats . . . . . . . . . . . . . . . . . . . . . . 14 2.1.1.3 Amarrages gros-grain ou atomique . . . . . . . . . . . 15 2.1.2 Autres strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . ´ 16 2.1.2.1 Fonctions de score atomique : termes physico-chimiques 16 2.1.2.2 Termes physico-chimiques a l’ ` echelle gros-grain . . . . ´ 20 2.2 Evaluation de la fonction de score non optimis ´ ee . . . . . . . . . . . . . ´ 21 2.2.1 Mesures d’evaluation globales . . . . . . . . . . . . . . . . . . . ´ 21 2.2.2 Mesures d’evaluation locales . . . . . . . . . . . . . . . . . . . . ´ 23 2.3 Optimisation de la fonction de score . . . . . . . . . . . . . . . . . . . . 25 2.3.1 Estimation des poids par regression logistique . . . . . . . . . . ´ 26 2.3.2 Algorithmes evolutionnaires . . . . . . . . . . . . . . . . . . . . . ´ 27 2.3.3 Methodologie d’optimisation de la fonction de score atomique . . ´ 28 2.4 Evaluation de la fonction de score optimis ´ ee . . . . . . . . . . . . . . . . ´ 30 2.4.1 Pouvoir predictif en fonction des contraintes . . . . . . . . . . . . ´ 31 2.4.2 Fonction de score dedi ´ ee pour chaque type d’ARN . . . . . . . . ´ 32 2.4.3 Combinaison lineaire ´ a poids positifs . . . . . . . . . . . . . . . . ` 32 2.4.3.1 Pouvoir predictif de la fonction de score . . . . . . . . . ´ 33 2.4.3.2 Enrichissement du tri des candidats . . . . . . . . . . . 35 2.4.3.3 Detection d’entonnoir . . . . . . . . . . . . . . . . . . . ´ 35 2.4.3.4 Repartition des coefficients des termes de score . . . . ´ 38 2.4.4 Filtrage a priori des candidats du modele atomique . . . . . . . . ` 39 2.5 Conclusions sur la fonction de score atomique . . . . . . . . . . . . . . 41 3 Approche a posteriori 43 3.1 Modeles ` a posteriori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 3.1.1 Combinaison lineaire . . . . . . . . . . . . . . . . . . . . . . . . . ´ 44 3.1.2 Approches dites ”explicatives” : arbres et regles de d ` ecision . . . ´ 44 3.1.3 Approches dites non explicatives . . . . . . . . . . . . . . . . . . 47 3.1.4 Boˆıte a outils utilis ` ee pour apprendre les mod ´ eles . . . . . . . . ` 49 vSommaire 3.1.5 Methodologie d’optimisation des fonctions de score ´ a posteriori . 50 3.2 Evaluation des fonctions de score ´ a posteriori . . . . . . . . . . . . . . . 50 3.2.1 Repartition des candidats par terme de score . . . . . . . . . . . ´ 51 3.2.2 Weka . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 3.2.3 ROGER non lineaire . . . . . . . . . . . . . . . . . . . . . . . . . ´ 53 3.3 Conclusions sur la fonction de score a posteriori . . . . . . . . . . . . . 55 4 Approche multi-echelle 57 ´ 4.1 Principe de l’approche multi-echelle . . . . . . . . . . . . . . . . . . . . ´ 57 4.1.1 Representation g ´ eom ´ etrique gros-grain des acides amin ´ es et ´ des acides nucleiques . . . . . . . . . . . . . . . . . . . . . . . . ´ 57 4.1.2 Mesure des termes geom ´ etriques ´ a l’ ` echelle gros-grain . . . . . ´ 60 4.1.3 Termes geom ´ etriques ´ a l’ ` echelle gros-grain . . . . . . . . . . . . ´ 64 4.1.4 Donnees et fonctions de score ´ a l’ ` echelle gros-grain . . . . . . . ´ 65 4.2 Optimisation de la fonction de score gros-grain . . . . . . . . . . . . . . 66 4.2.1 Methodologie d’optimisation de la fonction de score gros-grain . ´ 66 4.3 Evaluation de l’interaction ´ a l’ ` echelle gros-grain . . . . . . . . . . . . . . ´ 67 4.3.1 Etude des valeurs des mesures g ´ eom ´ etriques . . . . . . . . . . ´ 68 4.3.2 Evaluation de la fonction de score gros-grain . . . . . . . . . . . ´ 73 4.3.2.1 Poids . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 4.3.2.2 Evaluation de la fonction de score gros-grain . . . . . . ´ 76 4.3.2.3 Comparaison avec contrainte a poids positifs . . . . . . ` 78 4.3.2.4 Comparaison avec valeurs de centrage . . . . . . . . . 79 4.4 Conclusions sur la fonction de score gros-grain . . . . . . . . . . . . . . 80 5 Discussion biologique 83 5.1 Limites inherentes ´ a la construction de fonctions de score obtenues par ` apprentissage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 5.1.1 Une source de donnees exp ´ erimentales en constante ´ evolution . ´ 83 5.1.2 Influence du nettoyage des donnees . . . . . . . . . . . . . . . . ´ 84 5.1.2.1 Valeurs manquantes . . . . . . . . . . . . . . . . . . . . 84 5.1.2.2 Acides amines et nucl ´ eiques non standards . . . . . . ´ 84 5.1.2.3 Solvant et ions . . . . . . . . . . . . . . . . . . . . . . . 86 5.1.3 Influence du choix de la methode d’ ´ evaluation . . . . . . . . . . ´ 88 5.2 Flexibilite´ a l’interaction . . . . . . . . . . . . . . . . . . . . . . . . . . . ` 90 vi5.3 Limites du protocole de gen´ eration des candidats . . . . . . . . . . . . . ´ 91 6 Conclusion et perspectives 95 6.1 Integration de connaissances ´ a priori de contextes proches . . . . . . . 95 6.2 Extraction des donnees et complexit ´ es des mod ´ eles . . . . . . . . . . . ` 96 6.3 Predictions multi- ´ echelle . . . . . . . . . . . . . . . . . . . . . . . . . . . ´ 97 Bibliographie 103 Annexes 121 viiSommaire viiiTable des figures 1 Du gene ` a la prot ` eine . . . . . . . . . . . . . . . . . . . . . . . . . . . . ´ xvii 2 Les differents niveaux de structure . . . . . . . . . . . . . . . . . . . . . ´ xix 3 Formes D et L d’un acide amine . . . . . . . . . . . . . . . . . . . . . . ´ xix 4 Les 20 acides amines usuels . . . . . . . . . . . . . . . . . . . . . . . . ´ xx 5 Les nucleotides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ´ xxi 6 Geom ´ etrie de la liaison peptidique . . . . . . . . . . . . . . . . . . . . . ´ xxii 7 Appariement des nucleotides et h ´ elice d’ADN . . . . . . . . . . . . . . . ´ xxii 8 Helice ´ α . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiv 9 Brins β . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxv 10 Motifs de structure secondaire d’ARN . . . . . . . . . . . . . . . . . . . xxvi 11 Predictions issues d’une session de C ´ ASP . . . . . . . . . . . . . . . . . xxx 12 Schema de principe de d ´ etection des interactions prot ´ eine-prot ´ eine par ´ double-hybride chez la levure . . . . . . . . . . . . . . . . . . . . . . . . xxxiii 13 Le probleme de l’amarrage . . . . . . . . . . . . . . . . . . . . . . . . . ` xxxiv 14 Tessellation de Vorono¨ı et constructions deriv ´ ees . . . . . . . . . . . . . ´ xxxviii 15 Exemples de courbe ROC et explications . . . . . . . . . . . . . . . . . xlv 1.1 Diagramme de Venn du nombre de complexes par jeu de donnees externe ´ 3 1.2 Representation sch ´ ematique du calcul de l’alignement pour le L ´ RMSD et le IRMSD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.3 Exemple de diagramme d’EvsRMS . . . . . . . . . . . . . . . . . . . . . 9 1.4 Illustration du score d’enrichissement sur une courbe EvsRMS . . . . . 10 2.1 Espace de recherche des candidats d’une interaction entre 2 molecules ´ 12 2.2 Coordonnees torsionnelles pour la manipulation des structures 3D . . . ´ 14 2.3 Presentation g ´ en´ erale des scores physico-chimiques . . . . . . . . . . . ´ 18 2.4 Presentation de l’ ´ energie de Van der Waals . . . . . . . . . . . . . . . . ´ 19 2.5 Exemples de diagrammes d’EvsRMS pour ROS . . . . . . . . . . . . . 24 2.6 Meilleurs exemples de diagrammes d’EvsRMS pour ROS . . . . . . . . 24 2.7 Illustration de l’algorithme gen´ eral de R ´ OGER . . . . . . . . . . . . . . . 29 2.8 Methodologie d’optimisation de la fonction de score atomique . . . . . . ´ 30 2.9 Repartition de la valeur des coefficients par poids et contrainte . . . . . ´ 33 2.10 Repartition de la valeur des coefficients par poids . . . . . . . . . . . . . ´ 34 2.11 Courbes ROC de ROS et POS sur la PRIDB et les Benchmarks . . . . . 36 2.12 Courbes ROC de POS sur la PRIDB . . . . . . . . . . . . . . . . . . . . 37 ixTable des figures 2.13 Diagrammes d’EvsRMS d’interactions differentes propos ´ ees par POS . ´ 38 2.14 Diagrammes d’EvsRMS d’interactions alternatives proposees par POS . ´ 38 3.1 Exemple d’arbre de decision . . . . . . . . . . . . . . . . . . . . . . . . ´ 45 3.2 Arbre de decision appris avec J48 sur la P ´ RIDB . . . . . . . . . . . . . . 54 4.1 Modele gros-grain : exemple de l’uracile . . . . . . . . . . . . . . . . . . ` 58 4.2 Illustration de la construction intuitive d’un diagramme de Vorono¨ı . . . . 61 4.3 Exemple de triangulation de Delaunay, dual du diagramme de Vorono¨ı . 61 4.4 Construction d’une triangulation de Delaunay . . . . . . . . . . . . . . . 62 4.5 L’interface d’une tessellation de Vorono¨ı . . . . . . . . . . . . . . . . . . 63 4.6 Le solvant a l’interface d’une tessellation de Vorono ` ¨ı . . . . . . . . . . . 63 4.7 Mesure des parametres gros-grain ` a partir du diagramme de Vorono ` ¨ı . 64 4.8 Diagrammes d’EvsRMS pour POS avec entonnoirs . . . . . . . . . . . . 67 4.9 Interaction avec le solvant explicite du modele gros-grain . . . . . . . . ` 68 4.10 Courbes de densite des termes de score P1 et P2 . . . . . . . . . . . . ´ 70 4.11 Courbes de densite des termes de score P3 d’acides amin ´ es . . . . . . ´ 71 4.12 Courbes de densite des termes de score P3 des acides nucl ´ eiques . . . ´ 73 4.13 Coefficients de P1 et P3 : la surface d’interaction et le nombre d’acides amines et nucl ´ eiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ´ 74 4.14 Coefficients de P3 : les proportions d’acides amines et nucl ´ eiques . . . ´ 75 4.15 Coefficients de P4 : les volumes medians . . . . . . . . . . . . . . . . . ´ 76 4.16 Exemple de fonction avec valeurs de centrage . . . . . . . . . . . . . . 80 5.1 Structure 3D de 3 complexes proteine-ARN : ´ etude de cas des partenaires ´ 86 5.2 Diagramme EvsRMS des 3 complexes de l’etude de cas des partenaires ´ 87 5.3 Structure 3D de 3 complexes proteine-ARN : ´ etude de cas du solvant et ´ des ions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 5.4 Diagramme EvsRMS des 3 complexes de l’etude de cas du solvant et ´ des ions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 5.5 Diagramme EvsRMS de 3 complexes avec faible score d’enrichissement 90 5.6 Diagramme EvsRMS de 3 complexes . . . . . . . . . . . . . . . . . . . 92 5.7 Structure 3D d’une interaction de type clef-serrure . . . . . . . . . . . . 93 S1 Diagrammes par complexe de l’energie en fonction du I ´ RMSD (EvsRMS) 123 S2 Diagrammes EvsRMS pour les Benchmarks I et II . . . . . . . . . . . . 137 S3 Diagrammes EvsRMS des complexes avec proteine non li ´ ee . . . . . . ´ 142 xListe des tableaux 1 Matrice de confusion a deux classes . . . . . . . . . . . . . . . . . . . . ` xliii 1.1 Structures 3D, provenance et utilisation pour chaque jeu de donnees . . ´ 7 2.1 Evaluation globale de ROS sur la P ´ RIDB, au seuil du meilleur Fscore . . 22 2.2 Evaluation globale de ROS sur la P ´ RIDB, au seuil du top10 . . . . . . . 23 2.3 Evaluation des contraintes sur les poids compar ´ es´ a la fonction de score ` par defaut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ´ 32 2.4 Evaluation du mod ´ ele de pr ` ediction d ´ edi ´ e par cat ´ egorie de complexes . ´ 35 2.5 Exemples types de coefficients des termes de score hbond elev ´ es . . . ´ 39 2.6 Les complexes les plus difficiles a pr ` edire pour POS, avec filtre . . . . . ´ 40 3.1 Repartition des valeurs de chaque terme de score . . . . . . . . . . . . ´ 52 3.2 Evaluation des classifieurs Weka compar ´ es´ a R` OGER lineaire . . . . . . ´ 53 3.3 Evaluation des classifieurs R ´ OGER non lineaire compar ´ es´ a R ` OGER lineaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ´ 55 4.1 Repartition de termes g ´ eom ´ etriques sur les structures natives de la P ´ RIDB 69 4.2 Resultats gros-grain VOR pour la P ´ RIDB : 12 exemples . . . . . . . . . . 77 4.3 Resultats gros-grain VOR pour la P ´ RIDB : 6 exemples . . . . . . . . . . 78 4.4 Resultats gros-grain positifs pour la P ´ RIDB : 6 exemples . . . . . . . . . 79 4.5 Resultats gros-grain avec valeurs de centrage pour la P ´ RIDB : 6 exemples 81 S1 Resultats globaux des complexes de la P ´ RIDB, seuil du Fscore . . . . . 145 S2 Resultats globaux des complexes de la P ´ RIDB, seuil du top10 . . . . . . 148 S3 Resultats globaux des ´ Benchmarks I et II . . . . . . . . . . . . . . . . . 149 S4 Resultats globaux des complexes avec prot ´ eine non li ´ ee . . . . . . . . . ´ 150 S5 Resultats pour les complexes des ´ Benchmarks I et II . . . . . . . . . . . 151 S6 Resultats pour les complexes avec prot ´ eine non li ´ ee des ´ Benchmarks . 152 S7 Resultats gros-grain pour les complexes de la P ´ RIDB . . . . . . . . . . . 155 S8 Resultats gros-grain positifs pour les complexes de la P ´ RIDB . . . . . . 158 S9 Resultats gros-grain non lin ´ eaire pour les complexes de la P ´ RIDB . . . . 161 S10 Details sur les complexes prot ´ eine-ARN issus de la P ´ RIDB . . . . . . . . 165 S11 Details sur les complexes prot ´ eine-ARN issus des ´ benchmarks I et II . . 167 S12 Resultats atomiques pour les complexes de la P ´ RIDB . . . . . . . . . . 171 xiListe des tableaux xiiRemerciements Ce manuscrit doit son existence a l’interaction entre une multitude de personnes ` evoluant pour une grande part au sein de l’ ´ equipe-projet Inria AMIB (Algorithmes et ´ Modeles pour la Biologie Int ` egrative), qui comprend l’ ´ equipe bioinformatique du LRI ´ (Laboratoire de Recherche en Informatique) de l’Universite Paris-Sud et l’ ´ equipe bioin- ´ formatique du LIX (Laboratoire d’Informatique de Polytechnique) de l’Ecole Polytech- ´ nique. Je souhaite ici dresser un panorama de ces personnes, panorama qui ne se veut ni exhaustif, ni trie par score ou m ´ erite. ´ J’aimerais tout d’abord remercier mes directeurs de these dans leur ensemble pour ` nos discussions scientifiques et pour leur implication au rythme de nos nombreuses reunions. Et plus sp ´ ecifiquement : Julie Bernauer, pour sa minutie et ses mises en ´ perspective ; Jer´ ome Az ˆ e, pour son ´ ecoute et ses propos rassurants ; Christine Froide- ´ vaux, pour sa rigueur et sa supervision tout au long des differentes ´ etapes de la th ´ ese. ` Ce sont mes encadrants qui ont contribue´ a me former sur ce qu’aucun manuel n’a su ` me transmettre. Je tiens aussi a remercier l’ ` equipe bioinfo AMIB au complet pour cette ambiance ´ de travail a la fois studieuse et agr ` eable. Je remercie aussi plus particuli ´ erement les ` doctorants de l’equipe bioinfo AMIB pour leur soutien en cas de besoin et leurs sujets ´ de discussion passionnants sans cesse renouveles. ´ Merci aussi a Sid Chaudhury et Jeff Grey pour leurs conseils avis ` es en mati ´ ere de ` prediction structurale. ´ Je remercie Philippe Dague et Beatrice Duval pour avoir accept ´ e de faire partie de ´ mon jury de these, ainsi qu’Anne Poupon et C ` eline Rouveirol pour avoir aussi accept ´ e´ d’etre les rapporteurs de ce manuscrit. ˆ Un grand merci aux equipes techniques du LRI et du LIX pour leur efficacit ´ e et leur ´ aide au jour le jour sur le support informatique, ainsi que les equipes administratives ´ du LRI comme du LIX et le secretariat de l’ ´ Ecole doctorale pour leur patience. ´ Je remercie l’equipe de communication d’Inria pour leur sympathie et les journ ´ ees ´ de vulgarisation tres instructives. Merci aussi au SIP (Service d’Insertion Profession- ` nelle) pour ses formations sur l’ecriture de textes scientifiques et la prise de parole. Et ´ merci a Mich ` ele Sebag pour ses cours d’apprentissage automatis ` e.´ Je souhaiterais egalement remercier Anne Fourier, pour sa compr ´ ehension, ainsi ´ que son soutien inconditionnel durant les nuits blanches – ou presque – improvisees ´ et les reveils difficiles associ ´ es. ´ Je tiens aussi a signaler qu’une grande partie des calculs n ` ecessaires aux r ´ esultats ´ evalu ´ es au cours de cette th ´ ese n’auraient pas vu le jour en moins de trois ans sans ` la participation de certaines ressources de calcul. Parmi ces ressources se trouvent le cluster de l’equipe bioinfo AMIB, celui du LRI, ainsi que les ressources de CHP (Cal- ´ cul Haute Performance) du TGCC (Tres Grand Centre de calcul du CEA), l’allocation ` t2013077065 attribuee par Genci (Grand ´ Equipement National de Calcul Intensif). ´ Enfin, je remercie le Ministere de l’Enseignement Sup ` erieur et de la Recherche ´ ainsi que toutes les personnes qui ont contribue´ a me fournir la bourse doctorale, sans ` laquelle cette these n’aurait pas d ` ebut ´ e.´ xiiixivIntroduction 1 Contexte Les complexes proteine-ARN jouent un r ´ ole majeur dans la cellule. Ils sont im- ˆ pliques dans de nombreux processus cellulaires tels que la r ´ eplication et la transcrip- ´ tion des ARN messagers. Leur regulation est souvent clef dans les m ´ ecanismes qui ´ mettent en jeu de larges machineries moleculaires (comme le R ´ ISC, RNA-Induced Silencing Complex) impliquees dans les cancers. Les interactions prot ´ eine-ARN pr ´ e-´ sentent donc un grand inter´ et pour les ˆ etudes ´ a vis ` ee th ´ erapeutique [60]. Les prot ´ eines ´ etant capables d’interagir avec l’ARN sont nombreuses et vari ´ ees : leur structure met ´ en œuvre de nombreux domaines structuraux. Entre autres, les domaines RRM et dsRDB montrent tous une activite de liaison ´ a l’ARN et sont tr ` es` etudi ´ es [49]. Ces ´ dernieres ann ` ees, les techniques exp ´ erimentales de r ´ esolution ont mis en ´ evidence de ´ nouvelles structures d’ARN et de complexes proteines-ARN. Gr ´ ace ˆ a la cristallogra- ` phie [133] et a la r ` esonance magn ´ etique nucl ´ eaire (RMN) [227, 239], nous disposons ´ aujourd’hui de structures a haute r ` esolution qui permettent de mieux comprendre les ´ fonctions des ARN et leurs modes d’association [44, 78]. D’autres methodes exp ´ eri- ´ mentales permettent quant a elles d’ ` etudier ´ a basse r ` esolution des structures beau- ´ coup plus grandes [138, 166, 179]. Les experiences sur les mol ´ ecules uniques four- ´ nissent meme des donn ˆ ees ´ a haute r ` esolution [270] et la conception de mol ´ ecules ´ d’ARN est desormais accessible [45]. Malgr ´ e ces avanc ´ ees majeures en biologie ´ structurale pour les ARN et les complexes proteine-ARN, le nombre de structures ´ disponibles dans la Protein Data Bank, base de donnees exp ´ erimentale de r ´ ef´ erence, ´ reste faible : de l’ordre d’un ou deux milliers. La modelisation et la pr ´ ediction de ces ´ complexes sont donc necessaires, bien que difficiles [203]. ´ La modelisation des assemblages mol ´ eculaires est un probl ´ eme complexe et pour ` lequel de nombreuses methodes de pr ´ ediction et d’ ´ evaluation des r ´ esultats ont ´ et´ e´ developp ´ ees [173, 181, 249]. Le challenge international C ´ APRI (Critical Assessment of PRediction of Interactions) 1 [121], qui evalue les pr ´ edictions faites ´ a l’aveugle, a ` montre que, malgr ´ e de grands progr ´ es, les m ` ethodes actuelles d’amarrage ont besoin ´ d’une grande quantite et d’une grande vari ´ et´ e de donn ´ ees exp ´ erimentales [67]. Bien ´ que les techniques recentes soient capables de mieux pr ´ edire et prendre en compte ´ les ions et molecules d’eau qui interviennent dans les interactions [146], la flexibilit ´ e´ des molecules reste un frein majeur. M ´ eme s’il n’est pas aujourd’hui possible de pr ˆ edire ´ 1. http://capri.ebi.ac.uk xvIntroduction les affinites de liaison entre mol ´ ecules, l’originalit ´ e et la qualit ´ e des premiers r ´ esultats ´ obtenus sont encourageantes [146]. Les interactions entre proteines et ARN sont difficiles ´ a pr ` edire, principalement pour ´ deux raisons : la flexibilite des mol ´ ecules d’ARN d’une part et les forces ´ electrostatiques ´ qui guident l’interaction des molecules d’ARN charg ´ ees n ´ egativement d’autre part. Les ´ progres r ` ecents des techniques de pr ´ ediction de structure d’ARN et de repliement ´ [65, 66, 142, 195, 217] permettent de prendre en compte la flexibilite de l’ARN, mais ´ le plus souvent a l’ ` echelle atomique uniquement [85] et ne permettent pas ais ´ ement ´ l’integration dans une proc ´ edure d’amarrage. Cela ne pourra ´ etre fait qu’en disposant ˆ de fonctions de score assez performantes pour selectionner les bonnes conformations. ´ Les adaptations gros-grain qui permettent de reduire notoirement les phases initiales ´ de recherche sont interessantes [153, 229] et les champs de forces statistiques d ´ edi ´ es´ [43, 113, 205, 247, 269] sont prometteurs. Toutefois, ces optimisations sont souvent basees sur de simples mesures et font peu usage des jeux de donn ´ ees ´ a valeur ajout ` ee´ disponibles dans la communaute. La ´ Protein-RNA Interface DataBase (PRIDB) [152] fournit des jeux de donnees nettoy ´ es de qualit ´ e. Disponibles ´ a diff ` erents niveaux de ´ redondance, ils permettent des mesures atomiques precises. Les trois jeux d’essais ´ conc¸us pour l’amarrage protein-ARN et disponibles dans la litterature [9, 112, 204] ´ permettent d’evaluer les pr ´ edictions. ´ Pour l’amarrage, la disponibilite de donn ´ ees structurales est fondamentale pour ´ les methodes d’apprentissage. Plusieurs m ´ ethodes issues de l’apprentissage ont ´ et´ e´ developp ´ ees pour les complexes prot ´ eine-prot ´ eine [6, 18, 15, 22, 27]. Ces m ´ ethodes ´ se sont aver´ ees efficaces pour la r ´ e´evaluation ´ a posteriori (rescoring) et l’optimisation d’experiences d’amarrage ´ in silico, comme l’ont montre les derni ´ eres ` editions de C ´ APRI [251, 272]. Les techniques d’apprentissage sont donc de plus en plus etudi ´ ees et se ´ sont developp ´ ees au sein de la communaut ´ e C´ APRI [148]. Dans ce travail, je me suis interess ´ e au d ´ eveloppement de nouvelles m ´ ethodes ´ d’apprentissage pour les complexes proteine-ARN. Dans cette introduction, apr ´ es avoir ` present ´ e la structure des diff ´ erentes mol ´ ecules mises en jeu ainsi que leurs sp ´ ecificit ´ es´ structurales, je detaillerai les diff ´ erents mod ´ eles de repr ` esentation disponibles. Ensuite, ´ je decrirai le principe des m ´ ethodes d’amarrage et de score. Et j’aborderai enfin les ´ principes et methodes d’apprentissage en lien avec le probl ´ eme de l’amarrage. ` 2 Structure des proteines et des ARN ´ Une proteine est une macromol ´ ecule biologique constitu ´ ee d’un encha ´ ˆınement lineaire d’acides amin ´ es reli ´ es par une liaison peptidique. La prot ´ eine est le r ´ esultat de ´ l’expression d’un gene, port ` e par l’acide d ´ esoxyribonucl ´ eique (ADN), qui est d’abord ´ transcrit en acide ribonucleique (ARN) messager, lui-m ´ eme traduit en prot ˆ eine par ´ le ribosome (voir fig. 1). Les ARN sont formes d’un encha ´ ˆınement lineaire d’acides ´ nucleiques. De nombreux ARN ne codent pas pour des prot ´ eines et ont une structure ´ et une fonction propre. On distingue par exemple les ARN de tranfert (ARNt). Leur fonction est de permettre l’ajout d’un acide amine´ a la cha ` ˆıne d’acides amines d’une ´ xvi2. Structure des proteines et des ARN ´ proteine en cours de synth ´ ese. Les ARNt ont une structure tr ` es particuli ` ere, dite en ` trefle du fait de leur forme en repr ` esentation 2D. ´ E H A D W Y M V S N Noyau ADN ARN polymérase ARN messager ARN de transfert Acide aminé Ribosome Protéine TRANSCRIPTION TRADUCTION E C FIGURE 1 – Du gene ` a la prot ` eine. ´ Le gene (en bleu clair), appartenant ` a une mol ` ecule ´ d’ADN, est transcrit en ARN messager (en beige) par un enzyme : l’ARN polymerase. ´ Puis l’ARN messager est traduit en proteine dans le ribosome. ´ A cette traduction par- ` ticipent notamment les ARN de transfert. Image de J. Bernauer. Dans les conditions physiologiques, la proteine se replie, adoptant par ce biais une ´ conformation compacte specifique. Ce repliement peut ´ etre spontan ˆ e – par l’interaction ´ de la proteine avec le solvant – ou bien se faire gr ´ ace ˆ a des prot ` eines sp ´ ecialis ´ ees, ´ appelees les chaperonnes. Dans certains cas, une maturation peut se produire par ´ l’ajout de glucides ou bien par le clivage de certaines parties de la proteine. Ensuite, ´ la proteine, mature et repli ´ ee, est soit lib ´ er´ ee dans le cytoplasme, soit dirig ´ ee vers une ´ membrane, soit encore excret ´ ee dans le milieu ext ´ erieur. ´ Tout changement, qu’il soit dans les conditions du milieu (temperature, pH, force ´ ionique, presence d’agents chimiques) ou dans l’encha ´ ˆınement des acides amines (par ´ mutagenese ou par modification chimique), peut modifier le repliement de la prot ` eine ´ ou ses interactions et moduler son activite.´ Le repliement des proteines est impos ´ e d’une part par les interactions entre les ´ differents acides amin ´ es qui les composent et, d’autre part, entre ces acides amin ´ es´ et le solvant. Cependant, toutes les interactions ne sont pas parfaitement connues xviiIntroduction et la complexite de ce ph ´ enom ´ ene est telle que, ` a l’heure actuelle, son d ` eroulement ´ est impossible a d ` ecrire. La structure adopt ´ ee par une prot ´ eine de m ´ eme que ses ˆ interactions avec differents partenaires peuvent ´ etre d ˆ etermin ´ ees exp ´ erimentalement ´ mais cette determination peut ´ etre longue et difficile, m ˆ eme avec l’essor des projets de ˆ genomique structurale qui ont mis en place des strat ´ egies de r ´ esolution de structure ´ a haut d ` ebit. ´ Etant donn ´ e le nombre actuellement connu de s ´ equences prot ´ eiques ´ et d’interactions potentielles, la determination exp ´ erimentale de toutes les structures ´ correspondantes n’est pas envisageable. Il faut donc se tourner vers la modelisation, ´ qui tente de prevoir non seulement le repliement des prot ´ eines en partant de leurs ´ sequences, mais aussi la conformation du complexe ´ a partir de la structure de chacun ` de ses partenaires determin ´ ee s ´ epar ´ ement. ´ De la meme fac¸on, le repliement des ARN est d ˆ uˆ a l’interaction entre les nucl ` eotides ´ qui le composent, le solvant et – les molecules d’ARN ´ etant charg ´ ees – les ions. ´ Comme pour les proteines, les interactions mises en jeu lors du repliement sont mal ´ connues. La connaissance de ces interactions est rendue encore plus difficile par les aspects electrostatiques et les liaisons hydrog ´ ene tr ` es nombreuses. Les mol ` ecules ´ d’ARN sont a la fois beaucoup plus flexibles et moins stables que les prot ` eines, ce qui ´ rend a la fois leur r ` esolution exp ´ erimentale et leur mod ´ elisation plus difficiles. ´ On definit plusieurs niveaux d’organisation de la structure des prot ´ eines et des ´ acides nucleiques (voir fig. 2) : ´ – la structure primaire, ou sequence, est l’encha ´ ˆınement des acides amines ou des ´ nucleotides ; ´ – la structure secondaire resulte d’interactions ´ a courte distance (essentiellement ` des liaisons hydrogene entre atomes). Pour les prot ` eines, elles ne d ´ ependent ´ qu’en partie de la nature des chaˆınes laterales des acides amin ´ es impliqu ´ es : ´ certains segments de la proteine adoptent ainsi une conformation p ´ eriodique ´ d’angles diedres successifs. Pour les ARN, ces interactions sont li ` ees ´ a la nature ` des nucleotides et au type d’appariement que ceux-ci peuvent former ; ´ – la structure tertiaire est la forme fonctionnelle repliee d’une cha ´ ˆıne proteique ´ ou nucleique. Elle r ´ esulte de l’assemblage selon une topologie d ´ etermin ´ ee des ´ structures secondaires ; – la structure quaternaire, qui comprend les complexes, est l’association de plusieurs chaˆınes d’acides amines ou d’acides nucl ´ eiques (de cha ´ ˆınes identiques ou non). 2.1 Les acides amines´ Un acide amine est une mol ´ ecule constitu ´ ee d’un carbone asym ´ etrique (appel ´ e´ carbone α ou Cα) lie´ a un groupement carboxyle COOH, un groupement amin ` e NH ´ 2 , un hydrogene H et un radical R, aussi appel ` e la cha ´ ˆıne laterale. ´ Selon la conformation du carbone α, on parle d’acide amine D ou L (voir fig. 3). ´ Les appellations D et L ont et ´ e donn ´ ees ´ a l’origine pour d ` esigner les compos ´ es´ dextrogyres et levogyres. Cependant, la conformation D ou L ne permet pas de pr ´ evoir ´ les propriet ´ es optiques d’un acide amin ´ e. Chaque acide amin ´ e doit son nom ´ a la nature ` de son radical. Les acides amines naturels les plus courants sont au nombre de 20, ´ xviii2. Structure des proteines et des ARN ´ FIGURE 2 – Les differents niveaux de structure : (A) prot ´ eines, (B) ARN. La fonction des ´ assemblages formes est d ´ ependante des diff ´ erents niveaux. Image de J. Bernauer. ´ R Cα - H OOC +H3N R Cα H COONH3 + L-acide aminé D-acide aminé FIGURE 3 – Formes D et L d’un acide amine. Ces formes, non superposables, sont ´ l’image l’une de l’autre dans un miroir. Image de J. Bernauer. xixIntroduction tous de configuration L (voir fig. 4). Certaines proteines contiennent un petit nombre ´ d’acides amines modifi ´ es tels que l’hydroxyproline ou la s ´ el ´ enocyst ´ eine. ´ H2N CH C CH3 OH O H2N CH C CH OH O CH3 CH3 H2N CH C CH2 OH O CH CH3 CH3 H2N CH C CH OH O CH3 CH2 CH3 H2N CH C CH2 OH O H2N CH C CH2 OH O CH2 S CH3 H2N CH C CH2 OH O HN HN C OH O Alanine (Ala,A) Valine (Val,V) Leucine (Leu,L) Isoleucine (Ile,I) Phénylalanine (Phe, F) Méthionine (Met, M) Tryptophane (Trp, W) Proline (Pro, P) Acides aminés non polaires Acides aminés polaires non chargés H2N CH C H OH O H2N CH C CH2 OH O C NH2 O H2N CH C CH2 OH O CH2 C NH2 O H2N CH C CH2 OH O SH H2N CH C CH2 OH O OH H2N CH C CH OH O OH CH3 H2N CH C CH2 OH O OH Glycine (Gly, G) Asparagine (Asn, N) Glutamine (Gln,Q) Cystéine (Cys, C) Sérine (Ser, S) Thréonine (Thr, T) Tyrosine (Tyr, Y) Acides aminés basiques Acides aminés acides H2N CH C CH2 OH O CH2 CH2 CH2 NH3 + H2N CH C CH2 OH O CH2 CH2 NH C NH2 NH2 + H2N CH C CH2 OH O +HN NH H2N CH C CH2 OH O CH2 C O- O H2N CH C CH2 OH O C O- O Lysine (Lys, K) Arginine (Arg, R) Histidine (His, H) Acide glutamique (Glu, E) Acide aspartique (Asp, D) FIGURE 4 – Les 20 acides amines usuels. Image de J. Bernauer. ´ La nature du radical R (aussi appele cha ´ ˆıne laterale) conf ´ ere ` a chaque acide amin ` e´ des propriet ´ es physico-chimiques particuli ´ eres (encombrement st ` erique, hydrophobie, ´ polarite, acidit ´ e, flexibilit ´ e, ´ etc.). Ces propriet ´ es permettent le repliement de la prot ´ eine, ´ garantissent ainsi sa stabilite, et permettent son activit ´ e biochimique. ´ 2.2 Les acides nucleiques ´ Un acide nucleique, comme l’ARN ou l’ADN, est form ´ e de sous-unit ´ es appel ´ ees des ´ nucleotides. Les nucl ´ eotides sont form ´ es d’une base azot ´ ee appel ´ ee une base, d’un ´ cycle a cinq atomes de carbone appel ` e un sucre (ribose pour l’ARN et d ´ esoxyribose ´ pour l’ADN) et d’un groupement phosphate (voir fig. 5). Comme pour les acides amines, ´ pour les nucleotides, les parties correspondant au squelette – ´ a savoir le sucre et le ` groupement phosphate – sont identiques pour tous les nucleotides. Ceux-ci ne diff ´ erent ` donc que par leurs bases. xx2. Structure des proteines et des ARN ´ FIGURE 5 – Les nucleotides. Image de Wikipedia. ´ On distingue principalement cinq types de bases : l’adenine (A), la guanine (G), ´ la cytosine (C), l’uracile (U) et la thymine (T). Elles appartiennent a deux familles ` differentes : les purines, qui sont form ´ ees de deux cycles aromatiques (l’un ´ a cinq ` et l’autre a six atomes), et les pyrimidines qui sont form ` ees d’un cycle aromatique ´ a` six atomes. L’ARN contient principalement les quatre bases A,U,G et C. Il existe aussi d’autres nucleotides parfois en interaction dans un complexe prot ´ eine-ARN : ce sont les ´ nucleotides non standards. Ces nucl ´ eotides non standards sont g ´ en´ eralement obtenus ´ par l’ajout ou le retrait d’un groupement chimique a la base azot ` ee. ´ 2.3 La structure primaire ou sequence ´ 2.3.1 Definition ´ La structure primaire d’une proteine, ´ egalement appel ´ ee cha ´ ˆıne polypeptidique, est l’enchaˆınement de ses acides amines. Lors de la traduction, le groupement acide d’un ´ acide amine est li ´ e au groupement amin ´ e de l’acide amin ´ e suivant ; cette liaison est ´ appelee liaison peptidique. La nature de cette liaison impose certaines contraintes ´ spatiales : en particulier, le C et le O du groupement carboxyle du premier acide amine,´ ainsi que le N et le Cα de l’acide amine suivant sont coplanaires (voir fig. 6). ´ Les liaisons covalentes etablies lors de la traduction ne sont g ´ en´ eralement pas ´ modifiees. Les exceptions peuvent ´ etre la coupure de certaines parties de la cha ˆ ˆıne proteique, l’ ´ etablissement de ponts disulfure entre deux cyst ´ eines ou encore la liaison ´ avec des glucides lors de la maturation. Une proteine comprend entre 30 et 30 000 ´ acides amines, la moyenne se situant autour de 330 [268]. On appelle squelette de la ´ proteine, la cha ´ ˆıne des N, Cα, C, et O de tous les acides amines qui la constituent. ´ La structure primaire d’un ARN est la succession de ses nucleotides. Les bases ´ etant form ´ ees de cycles aromatiques, elles sont planes. Les bases s’apparient de la ´ fac¸on suivante : l’adenine forme deux liaisons hydrog ´ ene avec l’uracile et la guanine ` forme trois liaisons hydrogene avec la cytosine (voir fig. 7). Cette derni ` ere paire est ` donc plus stable. xxiIntroduction FIGURE 6 – Geom ´ etrie de la liaison peptidique telle que d ´ ecrite par Linus Pauling [197], ´ figure 1. FIGURE 7 – Appariement des nucleotides et h ´ elice d’ADN. Image adapt ´ ee de ´ Wikipedia. xxii2. Structure des proteines et des ARN ´ 2.3.2 Determination ´ La determination de la s ´ equence d’une prot ´ eine est une ´ etape indispensable de son ´ etude. En effet, la s ´ equence donne non seulement des informations sur le repliement ´ de la proteine (surtout s’il est possible de d ´ etecter des similitudes avec des prot ´ eines ´ dont la structure est connue), mais egalement sur sa fonction et sur sa localisation ´ cellulaire. Cette determination se fait g ´ en´ eralement de mani ´ ere indirecte, par traduction de ` la sequence du g ´ ene. De nombreuses techniques peuvent ` etre utilis ˆ ees ´ a des fins de ` sequenc¸age ´ a grande ` echelle [111]. ´ Cette methode ne permet cependant pas de conna ´ ˆıtre d’elements tels que les ´ ev´ enements post-traductionnels, en particulier les substitutions, les glycosylations ou ´ les del ´ etions d’une partie de la cha ´ ˆıne. Pour connaˆıtre directement la structure primaire d’une proteine de petite taille (moins de 150 acides amin ´ es), il est possible d’utiliser la ´ spectroscopie de masse [237]. Mais la sequence peut ´ egalement ´ etre d ˆ ecoup ´ ee – par ´ digestion enzymatique ou chimique – en tronc¸ons d’une longueur inferieure ´ a 30 acides ` amines. La s ´ equence de l’ensemble de ces tronc¸ons peut ensuite ´ etre d ˆ etermin ´ ee par ´ micro-sequenc¸age. ´ La determination d’une s ´ equence d’ARN se fait par s ´ equenc¸age, soit directement, ´ soit par conversion en ADN complementaire (ADNc) ´ a l’aide d’une transcriptase in- ` verse. 2.4 La structure secondaire 2.4.1 Definition ´ On appelle structure secondaire reguli ´ ere une partie de la cha ` ˆıne adoptant une conformation periodique. Ces structures sont stabilis ´ ees par des r ´ eseaux de liaisons ´ hydrogene entre les acides amin ` es non voisins dans la cha ´ ˆıne polypeptidique. Les premieres structures secondaires ont ` et´ e d ´ efinies par Linus Pauling en 1951 ´ [196, 197] : l’helice ´ α et le brin β. Ce sont deux structures secondaires tres largement ` majoritaires dans les proteines. Ces organisations mol ´ eculaires d’une part minimisent ´ les genes st ˆ eriques et les r ´ epulsions ´ electrostatiques entre les cha ´ ˆınes laterales et ´ maximisent le nombre de liaisons hydrogene : elles sont donc tr ` es largement favoris ` ees ´ [128]. Dans une proteine, en moyenne, la moiti ´ e des acides amin ´ es est impliqu ´ ee dans ´ des structures secondaires reguli ´ eres. L’autre moiti ` e des r ´ esidus se trouve impliqu ´ ee´ dans des boucles reliant entre elles les structures secondaires reguli ´ eres. En moyenne, ` la longueur d’un brin β est de cinq acides amines, celle d’une h ´ elice ´ α est de six acides amines, tandis que celle d’une boucle est de douze acides amin ´ es [51]. ´ L’helice ´ α est stabilisee par des liaisons hydrog ´ ene entre des acides amin ` es de la ´ meme h ˆ elice – des acides amin ´ es distants de seulement 3, 5 r ´ esidus en moyenne dans ´ la chaˆıne polypeptidique (voir fig. 8). Meme isol ˆ ee, l’h ´ elice ´ α est stable. Au contraire, le brin β n’est stable qu’associe´ a au moins un autre brin ` β, formant ainsi un feuillet (voir fig. 9). Les brins d’un feuillet peuvent etre tous dans le m ˆ eme sens ˆ xxiiiIntroduction FIGURE 8 – Helice ´ α telle que represent ´ ee dans l’article original de Linus Pauling [197], ´ figure 2. xxiv2. Structure des proteines et des ARN ´ – on parle alors de brins paralleles – ou bien ` etre positionn ˆ es alternativement dans un ´ sens et dans l’autre – on parle alors de brins antiparalleles. Les liaisons hydrog ` ene ` FIGURE 9 – Brins β tels que represent ´ es dans l’article original de Linus Pauling [196]. ´ assurant la cohesion des acides amin ´ es entre eux s’ ´ etablissent entre acides amin ´ es´ distants dans la sequence. ´ La quantite et l’agencement des structures secondaires r ´ eguli ´ eres conduisent ` a` classer les proteines en cinq cat ´ egories : tout- ´ α, tout-β, α/β (alternance d’helices ´ α et de brins β), α+β (structures contenant des helices ´ α et des brins β sans alternance), et ”autres” [185, 191]. La structure secondaire des ARN correspond aux motifs cre´es par les diff ´ erents ´ appariements des nucleotides. Alors que l’ADN existe principalement sous forme de ´ doubles helices compl ´ etement appari ` ees, l’ARN est souvent simple brin et forme de ´ nombreux motifs varies. L’ARN est en effet plus flexible et peut former des structures ´ plus complexes, du fait des liaisons hydrogene possibles avec le groupement hydroxyle ` du sucre. On distingue plusieurs motifs de structures secondaires pour l’ARN : les helices et ´ differents types de boucles. Les encha ´ ˆınements possibles de ces el ´ ements sont parfois ´ classes en familles de structures secondaires : les tetraloops, les pseudonœuds, les ´ tiges-boucles, etc. Bien qu’etant un motif de structure tertiaire, pour les acides nucl ´ eiques, l’h ´ elice ´ depend de la structure secondaire : en effet, elle correspond ´ a une r ` egion de structure ´ secondaire formee de paires de bases cons ´ ecutives. ´ La tige-boucle est un motif qui correspond a une h ` elice termin ´ ee par une courte ´ boucle de nucleotides non appari ´ es (voir fig. 10). C’est un motif extr ´ emement courant ˆ et qu’on retrouve dans des motifs plus grands tels que le trefle ` a quatre feuilles qui ` caracterise les ARN de transfert. Les boucles internes, s ´ erie de bases non appari ´ ees ´ au sein d’une helice, et les renflements, r ´ egions dans lesquelles un brin est compos ´ e´ de bases inser´ ees ”en plus” non appari ´ ees sont aussi fr ´ equentes. Ces r ´ egions sont ´ aussi parfois appelees jonctions. ´ Les pseudonœuds correspondent a une structure secondaire disposant de deux ` xxvIntroduction FIGURE 10 – Exemple de motifs de structure secondaire d’ARN : A) la tige boucle B) le pseudonœud. Image adaptee de Wikipedia. ´ tiges-boucles et dans laquelle la moitie d’une tige est intercal ´ ee entre les deux moiti ´ es´ de l’autre tige (voir fig. 10). Les pseudonœuds se replient en 3D en forme de nœuds mais ne sont pas des nœuds au sens topologique. De multiples processus biologiques reposent sur la formation de pseudonœuds (l’ARN de la telom ´ erase humaine par ex- ´ emple). Bien que l’ADN puisse former des pseudonœuds, ceux-ci ne sont trouves´ naturellement que chez les ARN. 2.4.2 Determination ´ a partir d’une solution ` A partir d’une solution de prot ` eine purifi ´ ee, il est possible d’estimer la composition ´ globale en structures secondaires reguli ´ eres (nombre d’acides amin ` es participant ´ a` des brins β ou a des h ` elices ´ α) par des methodes spectroscopiques : ´ – dichro¨ısme circulaire vibrationnel ou ultra-violet [194] ; – spectroscopie infrarouge [202] ; – spectroscopie Raman [4] ; – analyse des deplacements chimiques en RMN (r ´ esonance magn ´ etique nucl ´ eaire) ´ [258]. Cependant, pour les proteines, l’unique moyen de d ´ eterminer avec pr ´ ecision la position ´ dans la structure tertiaire de ces structures secondaires reguli ´ eres reste de d ` eterminer ´ completement la structure tertiaire. Pour l’ARN, la structure secondaire est en plus ` accessible grace ˆ a la structure tertiaire, mais celle-ci est bien plus difficile ` a r ` esoudre ´ experimentalement. Il est toutefois possible d’obtenir la structure secondaire de fac¸on ´ experimentale : soit par s ´ equenc¸age, soit ´ a l’aide de m ` ethodes de sondage. On peut ´ citer les sondages par modification chimique utilisant : – les radicaux hydroxyles, qui attaquent les cycles des sucres exposes [129, 246] ; ´ – le DMS (dimethyl sulfate), qui modifie certaines bases en les methylant, et les ´ sites qui ne peuvent plus ensuite s’apparier sont detect ´ es par RT-PCR [241] ; ´ – le CMCT (1-Cyclohexyl-3-(2-Morpholinoethyl)Carbodiimide metho-p-Toluene sulfonate), qui modifie les uridines et les guanines exposees (suivi aussi d’une ´ detection par RT-PCR) [88] ; ´ – le kethoxal (1,1-Dihydroxy-3-ethoxy-2-butanone), qui modifie aussi les guanines exposees [97] ; ´ – et la methode de sondage S ´ HAPE (Selective 2’-Hydroxyl Acylation analyzed by xxvi2. Structure des proteines et des ARN ´ Primer Extension), qui comprend des reactifs ayant une pr ´ ef´ erence pour les ´ zones flexibles du squelette de l’ARN [176]. Il existe aussi des methodes de sondage sans traitement chimique ´ (In-line probing) qui permettent de voir les changements structuraux dus aux interactions [97] ou de cartographie par interference utilisant des analogues de nucl ´ eotides ´ (NAIM) [219]. 2.4.3 Determination ´ a partir des coordonn ` ees atomiques ´ Meme lorsqu’on dispose des coordonn ˆ ees atomiques d’une prot ´ eine, il n’est pas ´ evident d’identifier les structures secondaires r ´ eguli ´ eres. Bien ` evidemment, il ne s’agit ´ plus ici de determiner le nombre et la nature des structures secondaires r ´ eguli ´ eres, ` mais plutot de d ˆ eterminer la position exacte de leurs extr ´ emit ´ es dans la s ´ equence. ´ Il existe de nombreux programmes permettant de realiser l’attribution des structures ´ secondaires des proteines, ´ a savoir : dire ` a quel type de structure secondaire participe ` chaque acide amine. La comparaison de ces programmes montre que les r ´ esultats ´ obtenus par les differentes m ´ ethodes peuvent ´ etre assez diff ˆ erents au niveau des lim- ´ ites de chaque structure secondaire. Pour les ARN, la determination des structures secondaires est bien plus simple. ´ L’attribution d’une structure secondaire aux acides nucleiques des extr ´ emit ´ es peut ´ etre ˆ delicate, mais de nombreux programmes proposent cette d ´ etermination. ´ 2.4.4 Prediction ´ La prediction des structures secondaires est une ´ etape int ´ eressante de l’ ´ etude ´ d’une proteine. En effet, elle permet d’ ´ emettre des hypoth ´ eses sur la nature du repliement, ` aide a localiser des r ` esidus du site actif, ou encore ´ a donner une hypoth ` ese quant ` a` la localisation de la proteine dans la cellule (en particulier pour les prot ´ eines mem- ´ branaires). Il existe un certain nombre de logiciels de prediction de structure secondaire, fond ´ es´ sur des methodes diff ´ erentes [87, 216]. D ´ esormais, les pr ´ edictions obtenues sont ex- ´ actes a plus de 75 %, comme le montrent les r ` esultats de l’exp ´ erience C ´ ASP. De la meme fac¸on, la pr ˆ ediction des structures secondaires est un champ de ´ recherche tres actif. De nombreuses techniques ont ` et´ e d ´ evelopp ´ ees [110, 171, 210, ´ 230, 274]. Une des difficultes majeures est ensuite de savoir dans quelle mesure les ´ structures locales des bases affectent la structure tertiaire des ARN. 2.5 La structure tertiaire 2.5.1 Definition ´ La structure tertiaire d’une proteine est la description du repliement d’une cha ´ ˆıne polypeptidique en sa forme fonctionnelle, ainsi que des liaisons covalentes apparues apres la traduction (essentiellement les ponts disulfure), la pr ` esence ´ eventuelle d’ions ´ ou de cofacteurs plus complexes (heme, flavine ad ` enine dinucl ´ eotide ou FAD...). Les ´ structures tertiaires sont tres vari ` ees et tr ´ es complexes. ` xxviiIntroduction Les chaˆınes polypeptidiques de grande taille (plus de 200 acides amines) se replient ´ souvent en plusieurs regions fonctionnelles. On parle de domaine si ces unit ´ es fonc- ´ tionnelles adoptent un repliement stable lorsqu’elles sont isolees. ´ Quand deux sequences prot ´ eiques pr ´ esentent plus de 30 % d’identit ´ e de s ´ equence, ´ elles adoptent le meme repliement [47, 221]. En dessous de ce seuil, il est difficile ˆ de prevoir, par les m ´ ethodes classiques d’alignement de s ´ equence, si deux prot ´ eines ´ vont adopter la meme structure tertiaire. De plus, certaines prot ˆ eines adoptent des ´ repliements similaires sans presenter d’identit ´ e de s ´ equence d ´ etectable ; c’est le cas ´ notamment de la superfamille des immunoglobulines [102]. Le repliement repose principalement sur des interactions a courte distance. Ces ` interactions ont lieu, d’une part, entre les acides amines enfouis dans la prot ´ eine, et, ´ d’autre part, entre les acides amines de la surface et les mol ´ ecules du solvant [215]. ´ Ces interactions sont des liaisons hydrogene, des ponts salins ou des liaisons de type ` Van der Waals. La structure tertiaire des ARN est, de la meme fac¸on, la description du repliement ˆ de la chaˆıne polynucleotidique en sa forme 3D fonctionnelle. Celle-ci repose princi- ´ palement sur les appariements Watson-Crick (GC et AU) qui forment les helices. Dans ´ les acides nucleiques, les h ´ elices sont des polym ´ eres en forme de spirale, en g ` en´ eral ´ droite, contenant deux brins de nucleotides appari ´ es. Un tour d’h ´ elice est constitu ´ e´ d’environ 10 nucleotides et contient un grand et un petit sillon. ´ Etant donn ´ e la diff ´ erence ´ de largeur entre le petit et le grand sillon, de nombreuses proteines se lient par le grand ´ sillon. De nombreux types d’helices sont possibles : pour l’ARN, on rencontre princi- ´ palement des helices A. ´ 2.5.2 Determination ´ La premiere structure de prot ` eine r ´ esolue a ´ et´ e celle de la myoglobine [134] par ´ cristallographie aux rayons X. A l’heure actuelle, la ` Protein Data Bank (PDB) [13, 14], banque de donnees des structures tridimensionnelles des prot ´ eines, contient plus ´ de 33 000 fichiers, dont environ 28 000 correspondent a des structures r ` esolues par ´ cristallographie et 5 000 a des structures r ` esolues par RMN (dans sa version ´ PDB 2004 archives release #1). D’autres methodes de r ´ esolution de structure peuvent aussi ´ etre ˆ utilisees, mais elles restent pour l’instant moins efficaces. ´ Ces methodes, m ´ eme si leurs performances se sont beaucoup am ˆ elior ´ ees, en ´ particulier avec l’apparition des projets de genomique structurale, restent tributaires ´ de conditions experimentales restrictives. La cristallographie n ´ ecessite l’obtention de ´ cristaux diffractants, ce qui demande beaucoup de materiel et de travail. Quant ´ a la ` RMN, meme si la contrainte du cristal est supprim ˆ ee, elle ne peut s’appliquer que sur ´ des proteines relativement petites (moins de 300 r ´ esidus) et il faut obtenir une quan- ´ tite importante de solution de prot ´ eine pure ´ a plus de 95 %. ` Etant donn ´ e le nombre ´ de sequences connues ´ a l’heure actuelle, il n’est donc pas envisageable de r ` esoudre ´ toutes les structures correspondantes. Par exemple pour la cristallographie X, selon la proteine et la qualit ´ e du cristal, ´ on connaˆıt la structure avec une resolution plus ou moins bonne. ´ A basse r ` esolution ´ (superieure ´ a 3 ` A), on conna ˚ ˆıt le squelette de la proteine et les structures secondaires. ´ xxviii2. Structure des proteines et des ARN ´ A moyenne r ` esolution, on peut observer les interactions entre acides amin ´ es, en par- ´ ticulier les liaisons hydrogene et les interactions de type Van der Waals. ` A haute ` resolution (moins de 1.5 ´ A), on peut d ˚ eterminer avec pr ´ ecision longueurs et angles des ´ liaisons, l’hydratation, et les mouvements atomiques autour des positions d’equilibre. ´ Ces methodes sont aussi utilis ´ ees pour les ARN, mais ceux-ci sont plus flexibles ´ et beaucoup moins stables, ce qui rend leur resolution beaucoup plus complexe. Alors ´ que la Protein Data Bank contient aujourd’hui plus de 100 000 structures, quelques milliers d’entre elles seulement correspondent a des structures d’ARN. ` 2.5.3 Prediction ´ Modelisation par homologie ´ Lorsqu’on peut etablir une similitude entre la s ´ equence ´ dont on cherche la structure et une sequence dont la structure tridimensionnelle est ´ connue (support), il est possible de construire un modele de la structure recherch ` ee. ´ Un modele obtenu de la sorte est d’autant plus pr ` ecis que l’identit ´ e de s ´ equence en- ´ tre le support et la sequence ´ a mod ` eliser est forte. Pour de faibles taux d’identit ´ e, on ne ´ connaˆıt avec precision, dans le mod ´ ele, que les acides amin ` es strictement conserv ´ es, ´ et les parties ne comportant pas de longues insertions/del ´ etions. Le mod ´ ele obtenu ` n’est donc pas l’equivalent d’une structure d ´ etermin ´ ee par des m ´ ethodes physiques. ´ Cependant, il rend souvent compte du comportement du site actif ou encore des parties de la proteine n ´ ecessaires ´ a son repliement ou ` a son interaction avec des parte- ` naires. Les methodes d’enfilage ´ Les methodes d’enfilage, ou ´ threading, permettent de tester la compatibilite d’une s ´ equence avec un repliement [240]. Dans ce cas, pour ´ une sequence donn ´ ee, on cherche parmi les structures connues, celle qui est la plus ´ compatible avec la sequence dont on dispose. ´ La modelisation ´ ab initio La finalite des techniques de mod ´ elisation ´ ab initio est de predire la structure d’une prot ´ eine ´ a partir de sa seule s ` equence. De nombreux ´ modeles de calculs sont utilis ` es, faisant appel par exemple ´ a la dynamique mol ` eculaire. ´ Mais, meme si les progr ˆ es sont cons ` equents, les r ´ esultats sont tr ´ es variables, comme ` l’atteste l’experience ´ CASP [25] ou l’etat du projet ´ folding@home 2 . Evaluation des pr ´ edictions : l’exp ´ erience C ´ ASP 3 L’experience C ´ ASP (Critical Assessment of Methods of Protein Structure Prediction) est une competition qui a lieu ´ tous les deux ans depuis 1994 et a pour objectif de tester les methodes de pr ´ ediction ´ de structure. Des proteines, dont la structure vient d’ ´ etre r ˆ esolue mais pas encore ´ publiee, sont propos ´ ees aux pr ´ edicteurs. Ceux-ci doivent tenter de pr ´ edire, selon la ´ categorie, la structure ´ ab initio, la structure par homologie ou la structure secondaire. 2. http://folding.stanford.edu/ 3. http://predictioncenter.org/ xxixIntroduction Les evaluations des pr ´ edictions [62, 141, 182] montrent d’importants progr ´ es dans la ` prediction de structure ´ ab initio (voir fig. 11). FIGURE 11 – Predictions issues d’une session de C ´ ASP. Predictions de structures ´ obtenues a l’aide du logiciel Rosetta [29] pour ` CASP6. Image originale en couverture du journal PROTEINS : Structure, Function, and Bioinformatics, volume 61 du 26 septembre 2005. Ces techniques s’appliquent aux proteines et aux ARN, avec plus de succ ´ es pour ` les proteines. ´ 2.6 La structure quaternaire 2.6.1 Definition ´ La structure quaternaire est la geom ´ etrie de l’association de plusieurs sous-unit ´ es´ proteiques ou nucl ´ eiques. Certaines prot ´ eines ne sont fonctionnelles que sous forme ´ d’oligomeres. Il existe des oligom ` eres form ` es de sous-unit ´ es identiques, comme par ´ exemple le tetram ´ ere de la thymidylate synthase X, et des oligom ` eres r ` eunissant des ´ sous-unites diff ´ erentes, comme les histones. On parlera alors de complexes. Enfin, cer- ´ taines proteines forment des polym ´ eres, constitu ` es d’un tr ´ es grand nombre de sous- ` unites, comme les polym ´ eres actine/myosine dans les muscles. ` L’association de ces sous-unites est stabilis ´ ee par des interactions ´ a courte dis- ` tance, similaires a celles qui assurent la stabilit ` e de la structure tertiaire (essentielle- ´ xxx2. Structure des proteines et des ARN ´ ment des liaisons hydrogene, des ponts salins et des interactions hydrophobes) [48, ` 125]. 2.6.2 Determination ´ L’existence d’oligomeres de cha ` ˆınes proteiques ou nucl ´ eiques, qu’elles soient ou ´ non identiques, peut etre d ˆ etermin ´ ee par filtration sur gel ou centrifugation analytique ´ par exemple. Mais leur existence peut aussi etre d ˆ etermin ´ ee par des m ´ ethodes de ´ biochimie et de biologie moleculaire plus pouss ´ ees et qui peuvent ´ etre utilis ˆ ees de ´ maniere syst ` ematique, telles que, pour les prot ´ eines, l’analyse double-hybride [116], ´ l’analyse par TAP-tag (ou FLAP-tag) couplee´ a la spectrom ` etrie de masse [92, 109]. ´ La geom ´ etrie de l’association peut ´ etre d ˆ etermin ´ ee´ a basse r ` esolution par diffusion ´ des rayons X ou des neutrons aux petits angles, chromatographie sur gel ou encore par microscopie electronique ´ a la fois pour les prot ` eines ou les ARN. ´ La connaissance de l’interaction au niveau des acides amines peut se faire, soit ´ directement par la determination de la structure par cristallographie aux rayons X, soit ´ par l’etude des interactions par RMN, ou encore indirectement, par mutagen ´ ese dirig ` ee´ ou modification chimique selective des cha ´ ˆınes laterales de certains acides amin ´ es. ´ Mais, en plus des contraintes associees aux deux m ´ ethodes vues pr ´ ec´ edemment, s’a- ´ joutent les contraintes inherentes aux complexes, telles que la taille, mais aussi, et ´ surtout, leur instabilite. En effet, pour pouvoir ´ etre ˆ etudi ´ e d’un point de vue structural, ´ un complexe doit etre stable dans les conditions requises. Or, de tr ˆ es nombreux com- ` plexes sont transitoires. Ainsi, meme s’il est d ˆ esormais possible d’obtenir la structure ´ de nombreuses proteines isol ´ ees de plus en plus rapidement, la r ´ esolution des struc- ´ tures de complexes reste difficile. 2.6.3 Prediction ´ Le premier modele de complexe prot ` eine-prot ´ eine (trypsine/inhibiteur) a ´ et´ e r ´ ealis ´ e´ en 1972 [20]. C’est en 1978 qu’est apparu le premier algorithme d’amarrage [259]. Les procedures d’amarrage utilisent les coordonn ´ ees atomiques des deux macromol ´ ecules ´ partenaires, gen´ erent un grand nombre de conformations et leur attribuent un score ` [260]. Cette modelisation est en g ´ en´ eral assimil ´ ee´ a la recherche de modes d’asso- ` ciation complementaires entre deux mol ´ ecules de forme pr ´ ed´ efinie. Un certain degr ´ e´ de flexibilite peut parfois ´ etre pris en compte, mais en g ˆ en´ eral, l’amarrage prot ´ eine- ´ proteine et prot ´ eine-ARN est principalement envisag ´ e dans une approche d’associa- ´ tion de corps rigides. Ces methodes s’appliquent ´ a des prot ` eines et acides nucl ´ eiques diff ´ erents, mais ´ peuvent aussi etre envisag ˆ ees pour d ´ eterminer l’ ´ etat d’oligom ´ erisation d’une prot ´ eine ´ ou d’un ARN. Elles peuvent prendre en compte les symetries connues comme pour ´ les proteines virales [12, 52, 199, 224], mais aussi utiliser des ´ etudes plus fines des ´ interfaces [19, 7, 200, 271]. xxxiIntroduction 3 Les complexes proteine-prot ´ eine et prot ´ eine-ARN ´ 3.1 Fonctions Au niveau moleculaire, la fonction d’une prot ´ eine ou d’un ARN est souvent subor- ´ donnee´ a l’interaction avec un certain nombre de partenaires. Les complexes inter- ` viennent a de nombreux niveaux et la compr ` ehension de leur m ´ ecanisme de forma- ´ tion/association permet de mieux comprendre de nombreux processus. Pour se rendre compte de leur importance, on peut citer des assemblages tels que le ribosome, les anticorps/antigenes, les capsides virales ou encore les microtubules. Ainsi, la fonction ` d’une proteine ou d’un ARN ne peut ´ etre envisag ˆ ee sans tenir compte des interactions. ´ 3.2 Detection exp ´ erimentale biochimique prot ´ eine-prot ´ eine ´ Les interactions proteine-prot ´ eine sont pr ´ esentes partout et en grand nombre. C’est ´ la raison pour laquelle de nouvelles methodes exp ´ erimentales d’analyse syst ´ ematique ´ sont developp ´ ees [123]. Deux types sont pr ´ esent ´ es dans la suite, les m ´ ethodes d’anal- ´ yse par double-hybride et celles utilisant des marqueurs. 3.2.1 Le double-hybride sur la levure La premiere m ` ethode utilis ´ ee pour ´ etudier dans la levure les interactions prot ´ eine- ´ proteine ´ a grande ` echelle a ´ et ´ e l’analyse par double hybride. Cette technique, mise ´ au point en 1989, permet la detection indirecte de l’interaction, car celle-ci induit la ´ formation d’un complexe moleculaire activant un g ´ ene rapporteur [81] (voir fig. 12). ` Cependant, dans cette detection, le nombre de faux positifs (les interactions d ´ etect ´ ees ´ mais non presentes) et de faux n ´ egatifs (les interactions pr ´ esentes non d ´ etect ´ ees) est ´ tres important. C’est donc une m ` ethode relativement peu fiable, ´ a moins de refaire un ` grand nombre de fois ces experiences, en plus d’exp ´ eriences compl ´ ementaires, ce qui ´ est relativement couteux et long dans une approche g ˆ enomique. ´ De plus, cette methode ne peut d ´ etecter dans sa forme originelle que des com- ´ plexes binaires. Or, la detection et la caract ´ erisation de complexes multiprot ´ eiques sont ´ tres importantes. ` Deux etudes sur la levure utilisent le double-hybride pour la d ´ etection syst ´ ematique ´ [116, 248]. Il est toutefois tres difficile de comparer ces ` etudes entre elles, en raison ´ principalement des problemes de fiabilit ` e dus aux contraintes exp ´ erimentales. ´ 3.2.2 Utilisation de marqueurs (TAP-tag et FLAP-tag) Deux autres etudes ont ´ et ´ e men ´ ees sur la levure ´ S. cerevisiae [92, 109] pour identifier et comprendre le role de complexes cellulaires dans la cellule eucaryote. Des ˆ centaines de sequences codantes de levure ont ´ et´ e fusionn ´ ees ´ a des cassettes d’ADN ` codant pour des marqueurs de purification. Puis, les souches de levure ont et´ e cul- ´ tivees, chacune exprimant une prot ´ eine cible marqu ´ ee, et soumises ´ a une proc ` edure ´ xxxii3. Les complexes proteine-prot ´ eine et prot ´ eine-ARN ´ Gal4 BD X Gal4 AD Y Gal4 BD X Gal4 AD Y Gal4 BD X Gal4 AD Y ARN Polymerase LacZ Interaction protéine-protéine Identification des colonies bleues X GalBD Y GalAD Vecteur appât Vecteur cible FIGURE 12 – Schema de principe de d ´ etection des interactions prot ´ eine-prot ´ eine par ´ double-hybride chez la levure. La proteine Gal4 est l’activateur naturel des diff ´ erents ´ genes intervenant dans le m ` etabolisme du galactose. Elle agit en se fixant sur des ´ sequences appel ´ ees UASG ´ (Upstream Activating Sequence GAL) qui regulent la tran- ´ scription. Les proteines ´ etudi ´ ees (X et Y), partenaires potentiels d’interaction, sont ´ fusionnees, l’une au domaine de fixation de Gal4 sur l’ADN (domaine DBD ou ´ DNA Binding Domain), et l’autre au domaine de Gal4 activant la transcription (domaine AC ou Activation Domain). C’est ce qui donne a ce syst ` eme le nom de double-hybride. ` Quand il y a interaction entre X et Y, les domaines DBD (DNA-Binding Domain) et AD (Activation Domain) sont associes et forment un activateur de transcription DBD- ´ X/Y-AD. C’est cet activateur hybride qui va se lier a l’ADN au niveau des s ` equences ´ qui controlent le g ˆ ene rapporteur (les s ` equences UASG), permettant la transcription du ´ gene par l’ARN polym ` erase II. Il suffit ensuite d’observer le produit du g ´ ene rapporteur, ` pour voir si un complexe s’est forme entre les prot ´ eines X et Y. Souvent, le g ´ ene LacZ ` est inser´ e dans l’ADN de la levure juste apr ´ es le promoteur Gal4, de fac¸on ` a ce que, ` si l’interaction a lieu, le gene LacZ, qui code pour la ` β-galactosidase, soit produit. Sur un substrat approprie, la ´ β-galactosidase devient bleue, ce qui permet de determiner ´ simplement si l’interaction a lieu. Image de J. Bernauer. xxxiiiIntroduction dans laquelle les complexes entiers, contenant la proteine marqu ´ ee, ont ´ et´ e purifi ´ es. ´ Ensuite, les complexes ont et ´ e fractionn ´ es par ´ electrophor ´ ese sur gel et leurs com- ` posants identifies par spectrom ´ etrie de masse. ´ Il est tres difficile de comparer les r ` esultats obtenus par ces ´ etudes car les jeux ´ utilises ne sont pas identiques et le prot ´ eome complet de la levure n’a pas pu ´ etre ˆ analyse. Globalement, ces ´ etudes donnent des r ´ esultats en accord avec celles r ´ ealis ´ ees ´ prec´ edemment, mais dans le d ´ etail, les r ´ esultats et la compl ´ etude des donn ´ ees ne per- ´ mettent pas de conclure. De plus, il est aussi difficile, pour les memes raisons, de comparer les ˆ etudes util- ´ isant des marqueurs et les etudes de double-hybride pr ´ esent ´ ees pr ´ ec´ edemment. ´ L’ensemble de ces etudes exp ´ erimentales permet de pr ´ edire environ 15 000 com- ´ plexes proteine-prot ´ eine potentiels pour le g ´ enome de la levure. Parmi ces 15 000 ´ complexes, beaucoup s’avereront ` etre des faux positifs et il est certain qu’il existe ˆ egalement un grand nombre de faux n ´ egatifs. ´ 3.3 Les methodes d’amarrage ´ 3.3.1 Le probleme ` Le but des methodes d’amarrage est de pr ´ edire la structure d’un complexe ´ a partir ` des structures ou modeles des partenaires isol ` es (voir fig. 13). Le probl ´ eme se divise ` + ? A B AB FIGURE 13 – Le probleme de l’amarrage. Comment associer la prot ` eine A et la prot ´ eine ´ B ? Des configurations AB obtenues, laquelle est susceptible d’exister in vivo ? Image de J. Bernauer. xxxiv3. Les complexes proteine-prot ´ eine et prot ´ eine-ARN ´ en deux etapes : d’abord, on explore l’espace pour obtenir toutes les conformations ´ possibles et ensuite, on trie ces conformations en esperant classer en premier la con- ´ formation native observee exp ´ erimentalement. ´ Avec une approximation de corps rigides, si on considere chaque partenaire comme ` une sphere de 15 ` A de rayon ˚ a la surface de laquelle les propri ` et´ es atomiques sont ´ decrites sur une grille de 1 ´ A, une recherche syst ˚ ematique pr ´ esente 10 ´ 9 modes distincts d’association [57]. La question est ensuite de determiner, parmi ces modes d’as- ´ sociation, lequel est le mode natif. Pour pouvoir acceder aux changements de conformation et aux mouvements des ´ chaˆınes laterales et des bases, le mod ´ ele doit ` etre de type ”soft”, c’est- ˆ a-dire que ` les molecules doivent pouvoir l ´ eg´ erement s’interp ` en´ etrer et on doit consid ´ erer les ´ molecules comme des ensembles de sph ´ eres articul ` ees. Ainsi, il est possible de traiter ´ aussi bien les molecules issues de r ´ esolution de structures de prot ´ eines seules, c’est- ´ a-dire non-li ` ees ´ (unbound), ou complexees, c’est- ´ a-dire li ` ees ´ (bound). 3.3.2 Les algorithmes Le premier algorithme, invente par Shoshana Wodak et Jo ´ el Janin [124, 259] ¨ a` partir des travaux de Cyrus Levinthal [149] realise une recherche de l’espace sur six ´ degres de libert ´ e (cinq rotations et une translation) pour amener les deux mol ´ ecules ´ en contact une fois leur orientation fixee, et attribue un score simple en fonction de la ´ surface de contact. Pour gagner du temps sur le calcul de la surface, une approximation a partir du mod ` ele de Levitt [150] est r ` ealis ´ ee. Cet algorithme a ´ et´ e am ´ elior ´ e en 1991 ´ a l’aide d’une minimisation d’ ` energie [46]. ´ D’autres types d’algorithmes, utilisant la complementarit ´ e de surface, ont ´ et´ e mis ´ en œuvre a partir d’une description en points critiques d ` efinis comme des ”trous et ´ bosses” (knobs and holes) [57, 145, 264]. Les solutions donnees correspondent ´ a une ` concordance de groupes de quatre points critiques, laquelle est identifiee gr ´ ace ˆ a une ` triangulation de surface comme definie par M. Connolly en 1985 [56]. Cette m ´ ethode ´ a et ´ e beaucoup am ´ elior ´ ee en 1991 par H. Wang, avec la mod ´ elisation de la surface ´ a` l’aide d’une grille [255]. En 1992, un programme utilisant ces grilles pour les petites molecules a ´ et´ e modifi ´ e´ par I. Kuntz et ses collaborateurs, pour s’appliquer aux complexes proteine-prot ´ eine et ´ a permis d’obtenir de bons resultats [175, 232] tout en g ´ en´ erant de nombreux faux- ´ positifs. Des algorithmes de vision par ordinateur (computer vision) a partir de hachage ` geom ´ etrique ont ensuite ´ etendu la m ´ ethode des ”trous et bosses”. En 1993 a ´ et´ e´ developp ´ e un algorithme qui fait correspondre des propri ´ et´ es de surface ´ a partir de ` triplets de points critiques qui sont stockes dans des tables de hachage [84, 163]. Cette ´ methode, tr ´ es efficace pour les mol ` ecules de type li ´ e, est tr ´ es sensible aux faibles vari- ` ations de surface, ce qui la rend rapidement inefficace pour les molecules de type ´ non-lie. ´ xxxvIntroduction 3.3.3 La transformation de Fourier Parmi toutes les methodes de compl ´ ementarit ´ e de surface, celle utilisant la trans- ´ formation de Fourier rapide (Fast Fourier Transform ou FFT), apparue des 1991 [126], ` est l’une des plus simples et des plus utilisees [10, 35, 40, 41, 132, 143, 180, 235, 257]. ´ Une grille cubique est tracee, et, ´ a chaque point, on attribue un poids qui est n ` egatif et ´ important si le point est situe´ a l’int ` erieur de la prot ´ eine A, nul s’il est ´ a l’ext ` erieur et 1 ´ s’il est proche de la surface ; on fait de meme pour la prot ˆ eine B. ´ Le produit est donc important et positif (donc defavorable) si les deux volumes ´ moleculaires s’interp ´ en´ etrent, et n ` egatif (donc favorable) pour les points qui apparti- ´ ennent a la surface d’une mol ` ecule et au volume de l’autre. Lorsque la mol ´ ecule A ´ est translatee par rapport ´ a la mol ` ecule B, le score peut ´ etre rapidement calcul ˆ e par ´ transformation de Fourier rapide (FFT), si la grille de A est identique a la grille de B. La ` grille doit donc etre red ˆ efinie ´ a chaque nouvelle orientation pour que la recherche soit ` complete. ` Cette approche presente de nombreux avantages : les poids peuvent contenir des ´ informations sur les propriet ´ es physico-chimiques de la surface, et la r ´ esolution peut ´ etre ajust ˆ ee en limitant le nombre de termes de Fourier calcul ´ es dans la somme. ´ Les resultats obtenus par cette m ´ ethode sont relativement bons dans une approche ´ corps rigide [11, 39, 170], mais le temps de calcul associe est trop important pour une ´ approche a grande ` echelle. ´ 3.3.4 Algorithmes d’amarrage et partitionnement du probleme ` Ces quinze dernieres ann ` ees, en particulier gr ´ ace ˆ a l’exp ` erience d’amarrage C ´ APRI (Critical Assessment of PRediction of Interactions) [118, 119, 120, 122, 261], plusieurs nouvelles methodes ont vu le jour [234]. Cette exp ´ erience est un test ´ a l’aveugle des ` algorithmes de docking de macromolecules qui doivent pr ´ edire le mode d’association ´ de deux proteines ´ a partir de leur structure tridimensionnelle. La structure du complexe, ` resolue exp ´ erimentalement, n’est d ´ evoil ´ ee aux participants et publi ´ ee qu’ ´ a l’issue des ` soumissions. Les nouvelles methodes d’amarrage utilisent des techniques tr ´ es vari ` ees telles que ´ le hachage geom ´ etrique [83, 115, 188, 189, 190, 220, 225, 262], les algorithmes ´ gen´ etiques [91], les harmoniques sph ´ eriques [213], la dynamique mol ´ eculaire [32, ´ 137, 238], la minimisation Monte-Carlo [100, 226], ou encore des methodes de min- ´ imisation d’energie ou de d ´ etection d’interfaces dirig ´ ees par des donn ´ ees biologiques ´ [69, 178, 250] (voir section 2.1.1 page 11). Le domaine de recherche a beaucoup progresse et l’une des conclusions de cette ´ experience est que l’on dispose d’algorithmes de recherche de compl ´ ementarit ´ e de ´ surfaces performants [174]. Cependant, la deuxieme ` etape du processus d’amarrage, ´ a savoir le tri des configurations putatives obtenues par une fonction de score, reste ` a am ` eliorer, car la seule m ´ ethode r ´ eellement performante ´ a l’heure actuelle est l’- ` expertise humaine. Les fonctions energ ´ etiques classiquement utilis ´ ees ayant montr ´ e´ leurs limites [42, 53, 77, 79, 104, 108, 154], de nouvelles fonctions de score statistiques sont apparues. Essentiellement basees sur les propri ´ et´ es physico-chimiques ´ xxxvi4. La tessellation de Vorono¨ı et ses deriv ´ ees pour l’amarrage ´ des atomes, elles ont tout d’abord et´ e utilis ´ ees pour le repliement et l’amarrage de ´ petites molecules, puis adapt ´ ees ´ a l’amarrage prot ` eine-prot ´ eine [64, 265, 266, 267]. ´ 4 La tessellation de Vorono¨ı et ses deriv ´ ees pour l’a- ´ marrage La premiere utilisation connue de la tessellation de Vorono ` ¨ı est la modelisation de la ´ repartition de l’ ´ epid ´ emie de chol ´ era de Londres par John Snow en 1854, dans laque- ´ lle est demontr ´ ee que la fontaine au centre de l’ ´ epid ´ emie est celle de Broad Street, ´ en plein coeur du quartier de Soho. Depuis lors, les applications utilisant cette construction sont nombreuses : en met´ eorologie d’abord, par A.H. Thiessen, en cristallo- ´ graphie par F. Seitz et E. Wigner, qui ont aussi donne leur nom ´ a cette construction ; ` mais aussi en physiologie (analyse de la repartition des capillaires dans les muscles), ´ metallurgie (mod ´ elisation de la croissance des grains dans les films m ´ etalliques), robo- ´ tique (recherche de chemin en presence d’obstacles) et bien d’autres. ´ La tessellation de Vorono¨ı, ainsi que les autres tessellations qui en ont et´ e d´ eriv ´ ees ´ (voir fig. 14), sont aussi beaucoup utilisees en biologie, o ´ u elles permettent de nom- ` breuses representations des structures des prot ´ eines [201]. ´ Etant donn ´ e un ensemble de points appel ´ es centro ´ ¨ıdes, la tessellation de Vorono¨ı divise l’espace au maximum en autant de regions qu’il y a de points (voir paragraphe ´ 4.1.2 page 60). Chaque region, appel ´ ee cellule de Vorono ´ ¨ı, est un polyedre qui peut ` etre consid ˆ er´ e comme la zone d’influence du point autour duquel est trac ´ ee la cellule. ´ 4.1 Constructions Dans le cadre de l’analyse structurale des proteines, la tessellation de Vorono ´ ¨ı a et ´ e utilis ´ ee pour la premi ´ ere fois par Richards en 1974 [211] pour ` evaluer, dans une ´ proteine globulaire, les volumes des atomes, d ´ efinis par les volumes de leurs poly ´ edres ` de Vorono¨ı. Dans cette etude, Richards est le premier ´ a proposer une solution ` a deux ` problemes que l’on retrouve dans toutes les ` etudes qui utilisent cette construction. ´ Tout d’abord, les atomes exposes au solvant ayant peu de voisins, leurs cellules de ´ Vorono¨ı sont grandes et ont un volume tres grand, peu repr ` esentatif de leurs propri ´ et ´ es. ´ Ensuite, cette construction considere tous les atomes comme ` equivalents, sans tenir ´ compte de leur nature chimique. Pour resoudre le premier probl ´ eme, Richards a plac ` e des mol ´ ecules d’eau sur un ´ reseau cubique entourant la prot ´ eine et a relax ´ e leurs positions. Cette m ´ ethode a ´ et´ e´ ensuite affinee par Gerstein et ses collaborateurs [94, 95, 243, 244, 245]. D’autres ´ methodes ont ´ et ´ e propos ´ ees telles que : ´ – prendre en consideration uniquement les atomes ayant une cellule de Vorono ´ ¨ı de volume  raisonnable  [206] ; – placer les molecules d’eau en utilisant la dynamique mol ´ eculaire [31, 37] ; ´ – utiliser une representation d’union de sph ´ eres [172] ; ` xxxviiIntroduction(a) (b) (c) (d) (e) (f) (g) (h) Diagramme de Voronoï Triangulation de Delaunay Méthode B de Richards zone non attribuée Décomposition en polyèdres de Laguerre Union de sphères α-Complexe Diagramme de Voronoï pondéré FIGURE 14 – Tessellation de Vorono¨ı et constructions deriv ´ ees ´ (a) Construction d’une cellule de Vorono¨ı : on trace la mediatrice entre un point donn ´ e et chacun des autres ´ points et ensuite, on considere le plus petit poly ` edre d ` efini par ces m ´ ediatrices ; c’est ´ la cellule de Vorono¨ı de ce meme point. (b) On obtient le diagramme de Vorono ˆ ¨ı (en violet) en rep´ etant l’op ´ eration pour tous les points de l’ensemble. (c) La triangulation ´ de Delaunay contient les aretes roses et les triangles ainsi d ˆ efinis. C’est le dual du ´ diagramme de Vorono¨ı. (d) Dans la methode de Richards, on ne consid ´ ere pas la ` mediatrice, mais on d ´ efinit une droite perpendiculaire au segment qui coupe celui-ci en ´ fonction des poids attribues´ a chacun des atomes. Cela laisse une zone non attribu ` ee. ´ (e) Si on remplace les droites prec´ edentes par les plans radicaux des sph ´ eres, on ` obtient a nouveau un pavage de l’espace : le diagramme de puissance ou tessellation ` de Laguerre. (f) L’intersection du diagramme de Laguerre et des spheres donne ce ` qu’on appelle l’union des spheres. (g) On d ` efinit une r ´ egion restreinte comme une ´ boule restreinte a sa r ` egion de Vorono ´ ¨ı. L’α-complexe correspond alors aux aretes ˆ et aux triangles definis par l’intersection de deux ou trois r ´ egions restreintes. L’ ´ α- shape est le domaine de l’α-complexe. (h) La surface de division d’un diagramme de Vorono¨ı ponder´ e est d ´ efinie par l’ensemble des points dont la distance aux deux points ´ de ref´ erence est ´ egale au rayon de la sph ´ ere correspondante plus une constante. Cette ` surface n’est pas plane, mais le diagramme correspondant est un pavage de l’espace. Image de A. Poupon. xxxviii4. La tessellation de Vorono¨ı et ses deriv ´ ees pour l’amarrage ´ – utiliser un melange entre la repr ´ esentation en diagramme de puissance et la ´ representation en union de sph ´ eres (voir fig. 14). ` Pour resoudre le probl ´ eme des poids des atomes, Richards a propos ` e d’introduire des ´ poids lors du placement des plans dans la construction de Vorono¨ı. Cette methode, ap- ´ pelee´ methode B de Richards ´ , a et ´ e tr ´ es utilis ` ee. Elle manque de rigueur math ´ ematique ´ car on trouve des volumes non attribues entre les cellules, l’intersection des plans ´ n’etant plus r ´ eduite ´ a un point. Cependant, Richards a montr ` e que ce volume mort, ´ bien que non nul, est petit en comparaison des volumes des atomes. Cette methode a ´ et ´ e de nombreuses fois am ´ elior ´ ee [82, 212], jusqu’ ´ a utiliser le diagramme de Laguerre ` [93] ou le diagramme de Vorono¨ı dit ponder´ e [58, 96], dans lequel les faces des cellules ´ ne sont plus planes (voir fig. 14). Une analyse formelle de toutes ces applications a et´ e r ´ ealis ´ ee par Edelsbrunner ´ et ses collaborateurs [72, 73, 74, 158, 159]. En plus des utilisations des tessellations de Vorono¨ı/Delaunay/Laguerre, ils mettent en place la notion d’α-shape pour les proteines : c’est un sous-ensemble des segments issus de la tessellation de Delaunay ´ qui sont contenus dans le volume de la proteine (voir fig. 14). Cela permet de mod ´ eliser ´ l’interieur de la prot ´ eine et de d ´ etecter les vides et les cavit ´ es [160]. ´ 4.2 Mesures Toutes ces constructions ont permis de montrer que la tessellation de Vorono¨ı est un bon modele math ` ematique de la structure des prot ´ eines. Elle permet en particulier ´ de montrer que les proteines sont des objets compacts, c’est- ´ a-dire que la densit ` e´ d’atomes a l’int ` erieur d’une prot ´ eine est comparable ´ a celle observ ` ee dans les cristaux ´ de petites molecules [95, 107]. De m ´ eme, une analyse o ˆ u les centro ` ¨ıdes sont les centres geom ´ etriques des acides amin ´ es a permis de montrer que les prot ´ eines sont aussi ´ des objets compacts au sens des modeles classiques des mati ` eres condens ` ees en ´ physique [3, 236]. Elle a egalement servi ´ a l’analyse des cavit ` es dans les structures [8, 72, 157, 198], ´ a l’ ` etude de propri ´ et ´ es m ´ ecaniques des prot ´ eines [136, 192, 222], ´ a la mise en place ` de potentiels empiriques pour l’affinement de modeles structuraux [23, 34, 90, 140, ` 156, 161, 183, 256, 273], ou encore a la d ` etection des h ´ elices transmembranaires [1]. ´ De telles methodes ont aussi ´ et´ e utilis ´ ees pour d ´ etecter les cavit ´ es des prot ´ eines ´ susceptibles d’interagir, mais aussi pour ajuster les ligands dans les poches ou encore etudier les interactions prot ´ eine-ADN [24, 28, 63, 186, 187]. Des ´ etudes util- ´ isant le modele B de Richards ou la construction de Laguerre ont montr ` e qu’ ´ a l’inter- ` face proteine-ADN et prot ´ eine-prot ´ eine, la densit ´ e de l’empilement est la m ´ eme qu’ ˆ a` l’interieur de la prot ´ eine pour la grande majorit ´ e des complexes [59]. ´ Plus recemment, la tessellation de Vorono ´ ¨ı a et´ e employ ´ ee pour la pr ´ ediction des ´ complexes proteine-prot ´ eine, en particulier afin d’obtenir des descripteurs gros-grains ´ pour la discrimination entre complexes cristallographiques et biologiques et pour les fonctions de score d’amarrage [27, 18, 17, 16, 15]. Ce type de methode est d ´ etaill ´ e au ´ chapitre 4. xxxixIntroduction 5 Fonctions de score Traditionnellement, les fonctions de score pour la prediction de la structure de ´ macromolecules biologiques ont pour objectif de repr ´ esenter l’ ´ energie libre de la struc- ´ ture. Pour quantifier l’energie libre d’une structure, les fonctions de score adoptent ´ differentes m ´ ethodes. Parmi celles-ci, on compte des m ´ ethodes empiriques, inspir ´ ees ´ des lois de la physique ou provenant de l’expertise des simulations de dynamique moleculaire. On compte aussi des m ´ ethodes bas ´ ees sur la connaissance, ´ i.e. issues de mesures sur des structures biologiques resolues exp ´ erimentalement. ´ De recents protocoles de pr ´ ediction des interactions prot ´ eine-prot ´ eine font ´ etat ´ de l’usage de ces methodes [18, 15, 22, 6, 27, 98]. RosettaDock [98] emploie un ´ melange de m ´ ethodes empiriques et de mod ´ elisation de lois physiques. Par exem- ´ ple, deux partenaires en interaction ont au moins un certain nombre d’atomes en interaction : cette simple observation est modelis ´ ee par une simple fonction continue ´ decroissante du nombre d’atomes en interaction. D’autres types de repr ´ esentation des ´ interactions locales, comme par exemple l’hydrophobicite,´ i.e. l’absence d’affinite entre ´ les molecules de solvant et les groupements hydrophobes n ´ ecessitent des fonctions ´ plus elabor ´ ees. Les fonctions de score d ´ evelopp ´ ees pour et utilis ´ ees par RosettaDock ´ [98] sont plus amplement detaill ´ ees dans la partie consacr ´ ee´ a l’ ` evaluation des confor- ´ mations par RosettaDock (voir section 2.1.1.2). Des fonctions de score s’appuyant sur une modelisation simplifi ´ ee de la structure, ´ dite gros-grain, ont dej ´ a permis d’orienter les pr ` edictions [18]. Ces fonctions de score ´ sont gen´ eralement plus simples, moins co ´ uteuses ˆ a calculer, ` a utiliser en amont d’une ` prediction plus sp ´ ecifique. ´ Pour predire l’interaction, il est possible d’utiliser certaines donn ´ ees externes, ´ i.e. ne provenant pas de la structure putative des molecules en interaction. On peut ainsi ´ voir des fonctions de score utiliser la conservation de sequences entre deux prot ´ eines ´ a travers l’ ` evolution pour inf ´ erer le comportement ´ a l’interaction d’une prot ` eine par ´ rapport a l’autre [22]. En effet, si une s ` equence est fortement conserv ´ ee entre deux ´ proteines, il y a de grandes chances pour que cette s ´ equence joue un r ´ ole dans au ˆ moins l’une des fonctions de chacune des deux proteines. Cependant, ces donn ´ ees ´ externes ne sont pas forcement toujours accessibles, ce qui limite leur utilisation dans ´ le cadre d’une prediction d’interactions ´ a grande ` echelle. Leur mauvaise interpr ´ etation ´ peut aussi parfois etre source d’erreur. La cible num ˆ ero 6 de C ´ APRI par exemple, bien que mettant en jeu des anticorps, traite d’une interaction n’impliquant pas le CDR (Complementarity determining regions) ou a lieu l’interaction avec l’antig ` ene. Il peut ` en outre s’averer compliqu ´ e de comparer la qualit ´ e de pr ´ edictions effectu ´ ees par une ´ methode de pr ´ ediction incluant des donn ´ ees externes de fac¸on optionnelle. ´ Mais aussi, des mesures plus complexes, comme un calcul de la complementarit ´ e´ de forme entre les deux partenaires, ont permis de mieux resoudre des interactions de ´ type clef-serrure. Il s’agit ici de l’utilisation de mesures faisant intervenir de fac¸on plus importante la geom ´ etrie de la structure, sans forc ´ ement tenir compte de param ´ etres ` davantage d’ordre biophysique. La construction du diagramme de Vorono¨ı a permis d’obtenir d’autres types de mesures geom ´ etriques sur la structure [15, 27]. De telles ´ xl6. Apprentissage automatise´ mesures geom ´ etriques ont montr ´ e qu’il ´ etait possible de mieux ´ evaluer l’empilement ´ sterique des prot ´ eines ´ a l’interaction, avec pour contrepartie de devoir construire le ` diagramme de Vorono¨ı. De maniere plus g ` en´ erale, les fonctions de score jouent un r ´ ole important en ap- ˆ prentissage automatise dans la traduction d’un ensemble d’attributs caract ´ erisant un ´ exemple donne en une sortie num ´ erique. Si cette sortie num ´ erique peut parfaitement ´ constituer l’estimation d’une observable, d’autres methodes pr ´ ef´ erent l’utiliser pour ` trier, voire pour classer les exemples. 6 Apprentissage automatise´ Un panorama relativement exhaustif de l’etat de l’art en apprentissage est disponible ´ en ref ´ erence [61]. Il propose une r ´ epartition des applications relevant du domaine de ´ l’apprentissage artificiel selon deux grands axes : (i) reconnaissance des formes et (ii) extraction de connaissances a partir des donn ` ees. Mais il est ´ egalement possible ´ de partitionner l’apprentissage automatique en fonction de la nature des donnees qui ´ sont etudi ´ ees : ´ apprentissage supervise´, ou les donn ` ees sont partiellement labellis ´ ees ´ (etiquet ´ ees), ´ vs apprentissage non supervise´ (donnees sans labels). ´ Dans le cadre de l’analyse des proteines (pr ´ ediction d’interactions prot ´ eine-prot ´ eine ´ et amarrage proteine-prot ´ eine), nous nous sommes focalis ´ es sur des m ´ ethodologies ´ relevant du domaine de l’apprentissage supervise : apprentissage d’un ´ modele pr ` edictif ´ a partir des donn ` ees connues. ´ 6.1 Paradigme de l’apprentissage supervise´ Le paradigme de l’apprentissage supervise peut se r ´ esumer de la fac¸on suivante : ´ etant donn ´ e un ensemble d’exemples ´ etiquet ´ es, apprendre un mod ´ ele capable de ` predire au mieux les ´ etiquettes de nouveaux exemples ´ . Soient X l’ensemble des exemples (ou donnees) et ´ Y l’ensemble des etiquettes ´ (notees aussi ´ classes) pouvant etre associ ˆ ees aux exemples. Dans le cadre des ´ travaux present ´ es dans ce manuscrit, seules des ´ etiquettes binaires ont ´ et´ e con- ´ sider´ ees : ´ Y = {+1, −1} (notees ´ egalement ´ {+, −} ou encore presque-natifs (+) et leurres (-) dans la suite du document). Les donnees peuvent se r ´ epartir en deux cat ´ egories : ´ – les donnees d ´ ej ´ a` etiquet ´ ees, en g ´ en´ eral pr ´ esentes en faible quantit ´ e car il est ´ souvent tres co ` uteux d’obtenir l’ ˆ etiquette associ ´ ee´ a une donn ` ee (par exemple, ´ obtenir la structure d’un complexe proteine-ARN par une exp ´ erience de cristallo- ´ graphie). Ces donnees seront utilis ´ ees pour apprendre un mod ´ ele permettant de ` predire les ´ etiquettes de nouveaux exemples. ´ – les donnees non ´ etiquet ´ ees, qu’il est en g ´ en´ eral ais ´ e d’obtenir. Dans notre cas, ´ nous pouvons utiliser un algorithme de gen´ eration de conformations pour obtenir ´ un large ensemble de conformations proteine-ARN non ´ etiquet ´ ees. ´ xliIntroduction L’ensemble des donnees d ´ ej ´ a` etiquet ´ ees est partitionn ´ e en un ´ ensemble d’apprentissage et ensemble de validation. Nous designerons l’ensemble d’apprentissage par ´ A = {(x1, y1), (x2, y2), . . . , (xn, yn)} avec xi ∈ R d et yi ∈ Y, ∀i ∈ {1, . . . , n}. xi est un vecteur de dimension d ou chaque dimension repr ` esente l’une des caract ´ eristiques de ´ l’exemple xi . L’apprentissage se deroule classiquement en trois phases, pour lesquelles on forme ´ a partir de l’ensemble d’apprentissage un ` jeu d’apprentissage : 1. l’apprentissage sur le jeu d’apprentissage d’un modele permettant de pr ` edire au ´ mieux les donnees d’apprentissage ; ´ 2. l’evaluation ´ de ce modele sur des jeux de donn ` ees extraits de l’ensemble d’ap- ´ prentissage (par exemple grace ˆ a une proc ` edure de validation-crois ´ ee ou de ´ leave-one-out) ; 3. le test du modele obtenu sur un jeu de donn ` ees ´ etiquet ´ e, qui est disjoint de ´ l’ensemble d’apprentissage, l’ensemble de validation. Le processus d’evaluation des performances d’un mod ´ ele appris n ` ecessite d’utiliser ´ des donnees non utilis ´ ees pour l’apprentissage afin de ne pas biaiser les ´ evaluations ´ de performances. Pour ce faire, l’evaluation s’effectue sur un mod ´ ele d’ ` evaluation, ´ specifiquement appris pour la phase d’ ´ evaluation. Ce mod ´ ele d’ ` evaluation est appris ´ de la meme mani ˆ ere que lors de la phase d’apprentissage, mais avec une partition de ` l’ensemble d’apprentissage : une partie des exemples est utilisee pour apprendre le ´ modele d’ ` evaluation tandis que l’autre est utilis ´ ee pour l’ ´ evaluation proprement dite du ´ modele. Deux processus sont classiquement utilis ` es pour l’ ´ evaluation : la ´ validationcroisee´ et le leave-one-out. L’evaluation du mod ´ ele appris par ` validation-croisee´ consiste a partitionner les ` donnees de l’ensemble d’apprentissage en ´ k parties disjointes, d’apprendre sur l’union de k − 1 parties et d’evaluer ses performances sur la partie non utilis ´ ee. Ce processus ´ est iter´ e´ k fois, ainsi tous les exemples de A auront et´ e utilis ´ es une fois en test et ´ k −1 fois en apprentissage. Le choix de la valeur de k depend de la taille des donn ´ ees. Les ´ valeurs classiquement utilisees sont ´ k = 3 ou k = 10. L’evaluation par ´ leave-one-out est une gen´ eralisation de la validation-crois ´ ee avec ´ k = n. Ainsi, pour chaque exemple, un modele est appris ` a partir de l’int ` egralit ´ e´ des donnees sauf l’exemple de test. Ce protocole d’ ´ evaluation est utilis ´ e lorsque les ´ donnees sont peu nombreuses et que le recours ´ a la validation-crois ` ee conduirait ´ a se ` priver d’une trop grande partie des donnees pour l’apprentissage. D ´ es que les donn ` ees ´ sont trop volumineuses, le recours a cette m ` ethode n’est plus viable car le co ´ ut de cal- ˆ cul devient rapidement prohibitif (apprentissage de n modeles). ` Ces deux processus d’evaluation supposent une ind ´ ependance des exemples en- ´ tre eux. Or, dans le cadre de l’amarrage proteine-ARN (ou prot ´ eine-prot ´ eine), les ex- ´ emples ne sont pas independants. En effet, comme nous l’avons vu pr ´ ec´ edemment, ´ nous disposons des structures de la proteine et de l’ARN, et ´ a partir de ces deux ` structures, nous gen´ erons, via un algorithme d’amarrage, des candidats. Ces can- ´ didats vont representer notre ensemble d’apprentissage. Un sous- ´ echantillon de ces ´ donnees sera ´ etiquet ´ e positif : la conformation dite native et les presques-natifs, si ´ l’algorithme d’amarrage a reussi ´ a en g ` en´ erer. Il existe donc un lien entre toutes les ´ xlii6. Apprentissage automatise´ conformations issues d’un couple proteine-ARN. Nous avons propos ´ e une adaptation ´ du processus leave-one-out pour prendre en consideration ce lien. Il s’agit du procesus ´ leave-”one-pdb”-out qui consiste a retirer non pas uniquement une conformation lors ` du processus d’apprentissage et d’evaluation, mais ´ a retirer toutes les conformations ` associees ´ a un couple prot ` eine-ARN. ´ Les criteres d’ ` evaluation permettant de mesurer les performances des mod ´ eles ` appris sont essentiels dans tout processus d’apprentissage. De nombreux criteres ` d’evaluation ont ´ et ´ e propos ´ es dans la litt ´ erature et nous pr ´ esentons ci-apr ´ es les crit ` eres ` les plus frequemment utilis ´ es et notamment ceux que nous manipulerons dans la suite ´ de ce document. 6.2 Criteres d’ ` evaluation ´ Tout d’abord, lorsqu’un modele pr ` edictif est appliqu ´ e sur un jeu de donn ´ ees, nous ´ pouvons mesurer, pour chaque etiquette, le nombre d’exemples correctement associ ´ es´ a cette ` etiquette, ainsi que le nombre d’exemples qui lui sont incorrectement associ ´ es. ´ Ces informations sont rassemblees dans une matrice nomm ´ ee la ´ matrice de confusion. Dans le cadre d’un modele` a deux classes, la matrice de confusion se repr ` esente ´ classiquement sous la forme d’un tableau (voir tableau 1). Reel ´ + - Pr´edit + VP FP - FN VN TABLE 1 – Matrice de confusion, ou VP repr ` esente le nombre de Vrais Positifs, FP le ´ nombre de Faux Positifs, FN le nombre de Faux Negatifs et VN le nombre de Vrais ´ Negatifs. Cette matrice de confusion restreinte ´ a un probl ` eme ` a deux classes peut ` etre ˆ etendue ´ a un probl ` eme ` a` n classes. La notion de Faux Positifs ou Faux Negatifs doit ´ alors egalement ´ etre ˆ etendue. ´ 6.2.1 Criteres d’ ` evaluation globaux ´ A partir de cette matrice de confusion, de nombreux crit ` eres d’ ` evaluation peuvent ´ etre calcul ˆ es. Parmi les plus utilis ´ es, nous pouvons citer : ´ – la precision ´ P = VP VP+FP , qui represente le pourcentage de pr ´ edictions correctes ´ associees ´ a la classe positive (la m ` eme mesure peut ˆ etre d ˆ efinie pour la classe ´ negative) ; ´ – le rappel R = VP VP+F N qui represente le pourcentage d’exemples positifs ´ etant ´ correctement predits positifs (de la m ´ eme mani ˆ ere que pour la pr ` ecision, il est ´ possible de definir cette m ´ etrique pour la classe n ´ egative) ; ´ – le Fscor e(β) = (β 2+1)×P×R β2×P+R qui permet d’agreger en une seule m ´ etrique la pr ´ ecision ´ et le rappel ; Le parametre ` β permet de ponderer la pr ´ ecision ´ vs le rappel. Si β < 1, le poids de la precision devient plus important, inversement, lorque ´ β > 1, xliiiIntroduction le poids de la precision diminue. Lorsque ´ β = 1 la precision et le rappel ont la ´ meme importance. La valeur de ˆ β est tres fr ` equemment fix ´ ee´ a 1 ; ` – l’accuracy Acc = VP+V N VP+V N+FP+F N qui permet d’evaluer la performance “globale” ´ d’un modele. Cette mesure repr ` esente le pourcentage de pr ´ edictions correctes ´ toutes classes confondues ; – la sensibilite´ Se = VP VP+F N qui est egale au rappel de la classe positive. Cette ´ mesure est issue du domaine du traitement du signal et est largement utilisee´ dans le domaine medical ; ´ – la specificit ´ e´ Sp = V N FP+V N qui correspond au rappel des negatifs. Cette mesure ´ est egalement issue du domaine du traitement du signal. Son utilisation dans le ´ domaine medical est toujours associ ´ ee´ a la sensibilit ` e. Ces deux mesures per- ´ mettent d’evaluer l’efficacit ´ e d’un nouveau test m ´ edical en indiquant sa capacit ´ e´ a effectuer ` a la fois des pr ` edictions correctes pour les positifs (sensibilit ´ e), tout ´ en couvrant peu de negatifs (capacit ´ e´ evalu ´ ee par 1 ´ − Sp). Toutes ces metriques fournissent une vision d’ensemble des performances d’un ´ modele en r ` esumant en une unique valeur le comportement du mod ´ ele pr ` edictif sur ´ l’ensemble des donnees. D’autres m ´ etriques ou crit ´ eres d’ ` evaluation ont ´ et´ e propos ´ es´ pour permettre d’obtenir une vision plus fine des performances d’un modele. Des ` modeles donnant plus d’information qu’une variable binaire peuvent profiter de crit ` eres ` d’evaluation adapt ´ es aux objectifs fix ´ es. Nous parlerons par la suite de classifieurs ´ pouvant soit donner une etiquette binaire aux exemples pr ´ edits soit leur attribuer un ´ score permettant ainsi d’ordonner les exemples. Nous les appellerons par extension des classifieurs. 6.2.2 Criteres d’ ` evaluation “locaux” ´ Il est notamment devenu evident, depuis les ann ´ ees 2000, qu’il ´ etait insuffisant ´ d’evaluer les performances d’un classifieur uniquement avec la pr ´ ecision et le rappel. ´ De nouvelles metriques se sont rapidement impos ´ ees dans la communaut ´ e [165, 89], ´ notamment des metriques permettent d’ ´ evaluer les classifieurs associant un score ´ a` chacune de leurs predictions. Ce score, qui peut ´ etre assimil ˆ e´ a un degr ` e de confiance ´ dans la prediction effectu ´ ee, permet alors d’ordonner les pr ´ edictions et ainsi d’obtenir ´ plus d’informations qu’une etiquette. ´ La courbe ROC (Receiver Operating Characteristic) [252, 177] permet de visualiser le compromis entre la sensibilite et la sp ´ ecificit ´ e. La courbe ROC associ ´ ee´ a` un classifieur ideal est constitu ´ ee de deux segments : un premier segment reliant le ´ point (0,0) au point (0,1) correspondant aux exemples positifs parfaitement ordonnes´ puis un second segment reliant le point (0,1) au point (1,1) correspondant aux exemples negatifs ayant tous des scores inf ´ erieurs aux scores des exemples positifs. Cette ´ courbe represente un classifieur ayant la capacit ´ e de s ´ eparer parfaitement les positifs ´ des negatifs (voir fig. 15). ´ Les courbes ROC permettent de visualiser rapidement les performances d’un ou plusieurs classifieurs. Afin de pouvoir comparer des classifieurs, notamment dans un cadre de recherche du meilleur classifieur (selon un ou plusieurs criteres d’ ` evaluation), ´ xliv6. Apprentissage automatise´ A B AUC = 0.5 % faux positifs % vrais positifs (0,0) (0,1) (1,1) (1,0) FIGURE 15 – Les courbes ROC associees aux classifieurs A et B permettent de visu- ´ aliser la superiorit ´ e du classifieur A par rapport au classifieur B. ´ il est tres utile de pouvoir comparer num ` eriquement les performances de ces classi- ´ fieurs. L’aire sous la courbe ROC – que nous appellerons par la suite ROC-AUC – est tres largement utilis ` ee pour comparer les performances de plusieurs classifieurs. [165, ´ 164] ont montre que l’aire sous la courbe ROC (AUC, ´ Area Under the Curve) est une metrique plus fiable que l’ ´ accuracy pour comparer deux classifieurs. De nombreux classifieurs “classiques” ont et´ e adapt ´ es pour pouvoir int ´ egrer l’opti- ´ misation de la ROC-AUC dans leur critere d’apprentissage comme les SVM [208] ou ` les arbres de decision [80]. ´ Sachant que, pour la problematique de l’amarrage prot ´ eine-ARN, seul un sous- ´ ensemble tres restreint de conformations candidates peuvent ` etre propos ˆ ees aux ex- ´ perts pour une validation experimentale, il est n ´ ecessaire de se focaliser sur des ´ metriques permettant d’identifier un sous-ensemble de conformations int ´ eressantes. ´ L’ensemble des criteres d’ ` evaluation locaux utilis ´ es sera pr ´ esent ´ e en d ´ etails dans ´ la section 1.4. xlvIntroduction xlviChapitre 1 Donnees ´ 1.1 Jeux de donnees de complexes prot ´ eine-ARN ´ Dans cette etude, quatre jeux de donn ´ ees provenant de la litt ´ erature sont utilis ´ es : la ´ Protein-RNA Interface DataBase (PRIDB) comprenant deux versions RB1179 et RB199 [152, 254], le Benchmark I proteine-ARN [9] et le ´ Benchmark II proteine-ARN [204] ´ (voir tableau 1.1). 1.1.1 Jeu de ref´ erence des complexes prot ´ eine-ARN connus ´ La Protein-RNA Interface DataBase (PRIDB) 4 se decline en deux versions : la ´ PRIDB redondante denomm ´ ee RB1179 [152] et la P ´ RIDB non redondante RB199 [254]. Elle est disponible en tel ´ echargement sur le site de la ´ Iowa State University 4 . Ce jeu de donnees regroupe l’ensemble des fichiers des complexes prot ´ eine-ARN de la ´ Protein Data Bank (PDB) extraits de fac¸on semi-automatique contenant au moins une surface d’interaction entre une proteine et un ARN. Sa version redondante (RB1179) contient ´ 1 170 complexes proteine-ARN. Sa version non redondante (RB199) tire son nom des ´ 199 chaˆınes d’acides amines qu’elle contient extraites de la PDB en mai 2010. ´ L’extraction des donnees de la P ´ RIDB non redondante est faite en respectant les criteres suivants : ` – s’assurer de la qualite des donn ´ ees, en extrayant uniquement les structures ´ resolues par cristallographie et ayant une r ´ esolution d’au plus 3.5 ´ A ; ˚ – les structures extraites doivent contenir une chaˆıne d’au moins 40 acides amines, ´ dont au moins 5 en interaction avec un ARN d’au moins 5 acides nucleiques ; ´ – un acide amine est consid ´ er´ e en interaction avec un ARN si l’un de ses atomes ´ est a au plus 5 ` A d’un atome de l’un des acides nucl ˚ eiques ; ´ – pour s’assurer de la non redondance entre les donnees, l’identit ´ e de s ´ equence ´ maximale entre chacune de ses chaˆınes d’acides amines est d’au plus 30 %. ´ La PRIDB non redondante RB199 contient 133 complexes. Or, plusieurs de ses complexes mettent en jeu plus de 2 partenaires. Nous n’utilisons donc que 120 des complexes de la PRIDB (voir section 1.2). 4. http ://pridb.gdcb.iastate.edu/download.php 1Chapitre 1. Donnees ´ 1.1.2 Jeux d’evaluation des proc ´ edures d’amarrage : ´ Benchmarks Le Benchmark I [9] proteine-ARN contient 45 complexes prot ´ eine-ARN tandis que ´ le Benchmark II proteine-ARN contient 106 complexes. ´ Tous les complexes du Benchmark I ont une version liee et non li ´ ee de la prot ´ eine ´ (voir section 2.1.1). 11 complexes ont une version liee et non-li ´ ee (ou mod ´ elis ´ ee) de ´ l’ARN. Par la suite, on utilise l’ensemble des 45 complexes de ce jeu. Parmi ces 45 complexes, seuls 11 complexes ne sont pas dans les 120 complexes de la PRIDB non redondante. Sur les 106 complexes du Benchmark II, 76 complexes ont une version non liee´ de la proteine. Par la suite, on utilise aussi ces 76 complexes pour l’ ´ evaluation. Parmi ´ ces 76 complexes, 36 complexes proteine-ARN ne sont pas dans la P ´ RIDB non redondante. Toutefois, il y a un complexe du Benchmark II (1eiy) qui met en jeu les deux memes partenaires qu’un complexe pr ˆ esent dans la P ´ RIDB (2iy5). Seuls 35 complexes du Benchmark sont donc utilises, 1eiy ´ etant ´ ecart ´ e et 2iy5 ´ etant utilis ´ e dans la P ´ RIDB. Il y a 5 complexes identiques entre les 45 complexes du Benchmark I et les 36 complexes du Benchmark II absents de la PRIDB non redondante (voir fig. 1.1). Il y a aussi 1 complexe du Benchmark I (2drb) mettant en jeu les deux memes partenaires qu’un ˆ complexe du Benchmark II (2dra), meme si le code pdb du complexe est diff ˆ erent. ´ C’est 2dra qui est utilise. ´ Dans l’ensemble des Benchmarks, nous avons donc un total de 40 complexes (5 du Benchmark I et 29 du Benchmark II et 6 de leur union) differents des complexes ´ dej ´ a pr ` esents dans la P ´ RIDB non redondante. Pour eviter la redondance, ce sont ces ´ 40 complexes que nous utilisons concernant les Benchmarks. 1.2 Nettoyage des donnees ´ Comme le protocole d’amarrage utilise prend en entr ´ ee deux partenaires et que ´ nous cherchons tout d’abord a mettre en place une proc ` edure de pr ´ ediction pour les ´ complexes binaires (le comportement des assemblages multiples etant bien plus diffi- ´ cile a d ` ecrire), nous n’utilisons que des complexes avec deux partenaires en interac- ´ tion. Les complexes de RB199 avec plus de deux partenaires en interaction (1a34 et 2q66) sont donc retires. Pour des raisons de complexit ´ e de calcul et des interactions ´ en presence, les complexes de RB199 mettant en jeu le ribosome complet ´ 5 sont aussi retires. Apr ´ es ces filtres, le jeu de donn ` ees issu de RB199 contient 120 complexes (voir ´ tableau S10). Les atomes d’hydrogene ne sont souvent pas pr ` esents dans les structures 3D con- ´ tenues dans la PDB. Aussi, les parametres des fonctions de score ne sont d ` efinis ´ que pour les atomes lourds des acides amines (resp. acides nucl ´ eiques) standards. ´ C’est pourquoi, pour l’ensemble des complexes utilises, les hydrog ´ enes sont retir ` es´ et les acides amines (resp. acides nucl ´ eiques) non standards transform ´ es en acides ´ amines (resp. acides nucl ´ eiques) standards. Ce remplacement des acides amin ´ es´ 5. Liste des complexes de RB199 mettant en jeu le ribosome complet : 1hr0, 1vqo, 2j01, 2qbe, 2vqe, 2zjr, 3f1e, 3huw, 3i1m, 3i1n, 3kiq 21.3. Utilisation des donnees ´ 5 6 29 7 27 14 72 Benchmark I (45 complexes) Benchmark II (76 complexes) RB199 (120 complexes) FIGURE 1.1 – Diagramme de Venn du nombre de complexes proteine-ARN utilis ´ es´ par jeu de donnees externe, extrait de la PDB : la P ´ RIDB non redondante munie de 120 complexes, le Benchmark I avec 45 complexes et le Benchmark II comportant 76 complexes avec une version non liee de la prot ´ eine. ´ (resp. acides nucleiques) non standards se fait en utilisant la correspondance de la ´ PDBeChem 6 , qui recense les denominations chimiques de la PDB. Ainsi pour chaque ´ acide amine (resp. acide nucl ´ eique) non standard, on peut obtenir l’acide amin ´ e (resp. ´ acide nucleique) standard le plus proche pouvant le substituer. Cependant, une telle ´ substitution peut avoir un impact sur le resultat biologique et ainsi rendre la structure ´ consider´ ee comme native peu fiable. ´ 1.3 Utilisation des donnees ´ Les donnees doivent ´ etre utilis ˆ ees pour d ´ efinir et ´ etiqueter les exemples. Il faut de ´ plus regrouper les exemples en jeux d’apprentissage et de test pour la modelisation de ´ la fonction de score comme pour l’evaluation du mod ´ ele. Mais le choix des ` etiquettes ´ depend du contexte biologique et n ´ ecessite donc de s’y attarder. C’est ce que nous ´ verrons en section 1.3.1. Nous verrons ensuite comment obtenir les exemples en section 1.3.2, leur etiquetage en section 1.3.4 et leur regroupement en diff ´ erents jeux en ´ section 1.3.5. 6. http ://www.ebi.ac.uk/pdbe-srv/pdbechem/ 3Chapitre 1. Donnees ´ 1.3.1 Contexte biologique : definitions ´ Dans une experience de pr ´ ediction de structure de complexe par ´ docking in silico, nous obtenons un grand nombre de structures potentiellement proches de la structure biologique qui n’est pas connue (voir section 2.1.1). Dans la suite, nous souhaitons extraire des structures de complexes biologiques vraisemblables dans un ensemble de structures issues d’une experience d’amarrage ´ (docking). Dans cet objectif, nous mettons en œuvre une approche d’apprentissage supervise : il nous faut donc ´ etiqueter ´ les donnees en fonction de leur int ´ er´ et biologique sur des exemples pour lesquels on ˆ connait dej ´ a la solution. ` Ainsi : – les complexes de la PDB sont les structures obtenues experimentalement ap- ´ pelees ´ natifs ou dites natives ; – les complexes candidats sont ceux pour lesquels on cherche a d ` eterminer s’ils ´ sont biologiquement natifs ; – les complexes leurres sont les complexes non-natifs, i.e. ceux qui ne sont vraisemblablement jamais formes dans la cellule ; ´ – les complexes proches de la solution native (selon un seuil a d ` eterminer en fonc- ´ tion du but recherche) sont les ´ presque-natifs. Les jeux de donnees de r ´ ef ´ erence sont constitu ´ es de structures 3D repr ´ esentant la ´ solution biologique de l’interaction. Ce sont donc des natives. La PRIDB en contient 120, les Benchmarks 40 (11 issus du Benchmark I et 29 issus du Benchmark II). Les 120 structures natives sont utilisees pour g ´ en´ erer un ´ ensemble de perturbations. Cet ensemble de perturbations contient l’ensemble des exemples utilises pour ´ l’apprentissage et l’evaluation. Il correspond donc ´ a l’ensemble d’apprentissage (voir ` section 0.6.1). Comme vu dans le chapitre prec´ edent, pour correctement valider le mod ´ ele de ` prediction, il est n ´ ecessaire d’utiliser des donn ´ ees diff ´ erentes des donn ´ ees utilis ´ ees ´ pour l’apprentissage. Une validation du modele est donc effectu ` ee gr ´ ace ˆ a un ` jeu de validation gen´ er´ e de la m ´ eme mani ˆ ere mais ` a partir des 40 structures des ` Benchmarks. Ce jeu de validation est utilise pour ´ evaluer la fonction de score g ´ en´ er´ ee´ a` partir de l’ensemble de perturbations. 1.3.2 Ensemble des perturbations pour l’apprentissage Comme cela a et ´ e fait dans la litt ´ erature pour l’amarrage prot ´ eine-prot ´ eine [98], ´ des exemples positifs et negatifs sont g ´ en´ er´ es par perturbation des structures na- ´ tives. La perturbation des structures natives est un proced´ e g ´ en´ erant un ´ echantillon ´ gaussien des candidats autour de la structure native. Pour chaque complexe, 10 000 candidats sont gen´ er´ es par perturbation des coordonn ´ ees des atomes de l’ARN par ´ rapport aux coordonnees des atomes de la prot ´ eine. L’op ´ eration de perturbation con- ´ siste en 1 translation et 3 rotations pour modifier les coordonnees des atomes de ´ l’ARN. Les amplitudes de la translation et des rotations sont chacune choisies selon une loi gaussienne de variance 1 et de moyenne variable. La moyenne des amplitudes de la translation et des rotations est adaptee en fonction du complexe. La moyenne ´ 41.3. Utilisation des donnees ´ est determin ´ ee de telle sorte que, pour un complexe donn ´ e, il existe au moins 30 ´ candidats suffisamment proches de la structure native et 30 candidats suffisamment eloign ´ es de la structure native (voir section 1.3.3). Pour satisfaire ces deux conditions ´ sur les candidats obtenus, 3 jeux distincts sont utilises : ´ – la perturbation standard a un jeu de moyennes de valeurs 3 A pour la translation ˚ et 8 ° pour les rotations ; – la perturbation restreinte a un jeu de moyennes de valeurs 1 A et 4 ° ; ˚ – la perturbation etendue a un jeu de moyennes de valeurs 9 ´ A et 27 °. ˚ 1.3.3 Mesure de similarite : le RMSD ´ Le RMSD (Root-Mean-Square Deviation) est une mesure utilisee pour ´ evaluer ´ la dissimilarite entre deux structures repr ´ esentant des conformations diff ´ erentes d’un ´ meme complexe. Dans une telle comparaison, les deux jeux d’atomes sont identiques ˆ ou comparables, mais avec des coordonnees spatiales diff ´ erentes. Le RMSD utilise ´ la distance entre chaque atome dans les deux structures, une fois que les structures sont alignees. Le RMSD est calcul ´ e comme la distance moyenne entre les atomes de ´ ces deux structures. Considerons deux structures ´ s1 et s2 d’un meme complexe de ˆ N atomes, soit di la distance entre l’atome i de s1 et l’atome i de s2 (voir eq. 1.1) : ´ RMSD(s1, s2) = vuut 1 N X N i=1 d 2 i (1.1) Le RMSD est couramment utilise sous diverses versions pour ´ evaluer la dissim- ´ ilarite entre une structure native et un candidat. Parmi ces versions du RMSD, il y ´ a le LRMSD et le IRMSD utilises par C ´ APRI, calcules sur une restriction des atomes : ´ uniquement sur le ligand pour le LRMSD, uniquement sur l’interface pour le IRMSD [147] (voir fig. 1.2). L’alignement differe selon le RMSD calcul ` e. Pour le L ´ RMSD, l’alignement s’effectue uniquement sur les atomes du squelette des acides amines de la prot ´ eine. ´ Pour le IRMSD, ce sont les atomes a l’interface qui sont align ` es. Le RMSD peut aussi ´ etre calcul ˆ e soit sur l’ensemble des atomes de chacun des acides amin ´ es et acides ´ nucleiques consid ´ er´ es, soit uniquement ´ a partir d’un atome de r ` ef´ erence par acide ´ amine ou acide nucl ´ eique. C’est ici le carbone ´ α qui est utilise comme atome de ´ ref ´ erence de l’acide amin ´ e. Pour l’acide nucl ´ eique, c’est l’atome de phosphore qui est ´ utilise comme atome de r ´ ef ´ erence. ´ Cette mesure de similarite est utilis ´ ee dans la g ´ en´ eration des candidats. Les deux ´ conditions fixees sur le nombre minimum de candidats ´ a g ` en´ erer sont : ´ – un IRMSD ≤ 5A pour les 30 candidats devant ˚ etre suffisamment proches de la ˆ structure native ; – un IRMSD > 8A pour les 30 candidats devant ˚ etre suffisamment ˆ eloign ´ es de la ´ structure native. Ces deux conditions ont pour objectif de conserver une distribution relativement homogene de chaque nuage de candidats. Il reste ensuite ` a comparer les candidats ` gen´ er´ es entre eux pour les ´ etiqueter. ´ 5Chapitre 1. Donnees ´ L R L , FIGURE 1.2 – Representation sch ´ ematique en gris des acides amin ´ es et acides ´ nucleiques s ´ electionn ´ es pour le calcul du L ´ RMSD et du IRMSD. La proteine (ou ´ recepteur) est d ´ enomm ´ ee R. L’ARN (ou ligand) est appel ´ e L et L’ correspond ´ a la ` position de L dans une seconde structure de l’interaction entre R et L. Le LRMSD est calcule sur les atomes du ligand L, les atomes du r ´ ecepteur R ´ etant align ´ es, ´ a partir ` des distances en vert et en bleu (seules quelques distances sont affichees). Le I ´ RMSD est calcule sur les atomes des acides amin ´ es et acides nucl ´ eiques ´ a l’interface, en noir, ` a partir des distances en vert, les atomes ` a l’interface ` etant align ´ es. ´ 1.3.4 Etiquetage ´ Une fois les jeux de donnees g ´ en´ er´ es, il faut choisir la version de RMSD utilis ´ ee et ´ le seuil en RMSD en-dessous duquel un candidat est consider´ e comme un presque- ´ natif. La version de RMSD impacte les possibilites de comparaison des structures ´ candidates de differents complexes. Une version de RMSD tr ´ es sensible ` a la taille ` des partenaires (en nombre d’acides amines et d’acides nucl ´ eiques) donne une sig- ´ nification tres diff ` erente au seuil fixe pour des complexes de tailles diff ´ erentes. Un ´ complexe de petite taille doit etre bien plus ˆ eloign ´ e de la structure native qu’un com- ´ plexe de grande taille pour arriver au seuil fixe. Comme nous choisissons un seuil ´ fixe, independant de la taille des complexes, il est pr ´ ef´ erable d’avoir une version de ´ RMSD peu sensible a la taille des complexes. Nous choisissons le I ` RMSD qui, malgre´ sa dependance ´ a la taille de l’interface, reste la version CAPRI de RMSD le moins ` sensible a la taille de chacun des deux partenaires. ` Le seuil de IRMSD a un impact sur la tolerance que le mod ´ ele de pr ` ediction a ´ sur la divergence entre un candidat consider´ e presque-natif et la structure native. Un ´ seuil elev ´ e accepte comme presque-natif des structures candidates tr ´ es` eloign ´ ees de ´ la structure native, donnant une prediction avec peu de signification. Certes, un tel ´ modele peut plus facilement pr ` edire si un candidat est presque-natif, mais un candi- ´ 61.3. Utilisation des donnees ´ dat predit presque-natif par ce biais peut ´ etre tr ˆ es proche comme tr ` es` eloign ´ e de la ´ structure native. Un seuil bas gen´ ere trop peu de presque-natifs, ce qui limite d’au- ` tant le nombre de candidats disponibles pour l’apprentissage. Pire, un seuil trop bas ne permettrait pas d’obtenir un modele de fonction de score utilisable pour affiner une ` structure 3D. Nous choisissons un seuil en IRMSD de 5A : ˚ – les candidats de IRMSD ≤ 5A sont consid ˚ er´ es comme des ´ presque-natifs ; – les candidats de IRMSD > 5A sont consid ˚ er´ es comme des ´ leurres. Le seuil en IRMSD de 5 A n’est pas choisi au hasard. Pour un complexe prot ˚ eine- ´ proteine, le crit ´ ere C ` APRI pour une solution acceptable est d’avoir un IRMSD < 4A. ˚ Comme nous evaluons des complexes prot ´ eine-ARN, o ´ u l’ARN est une mol ` ecule plus ´ flexible, nous admettons une marge d’erreur leg´ erement sup ` erieure, pour un seuil en ´ IRMSD de 5A. ˚ Jeu de donnees ´ Nb. de structures Provenance Utilisation PRIDB redondante RB1179 1 170 PDB Mesures PRIDB non redondante RB199 120 PDB Gen´ eration ´ Ensemble de perturbations 1 200 000 Gen´ er´ e´ Apprentissage Benchmark proteine-ARN I ´ 45 (11) PDB Gen´ eration ´ Benchmark proteine-ARN II ´ 76 (29) PDB Gen´ eration ´ Jeu de validation 400 000 Gen´ er´ e´ Validation TABLE 1.1 – Nombre de structures 3D presentes, provenance et utilisation pour chaque ´ jeu de donnees. Pour les ´ Benchmarks I et II, le nombre de structures 3D entre parentheses correspond au nombre de structures 3D n’ ` etant pas d ´ ej ´ a pr ` esentes dans la ´ PRIDB non redondante RB199. Il s’agit aussi du nombre de structures 3D effectivement utilisees dans la g ´ en´ eration de candidats. Chaque jeu de donn ´ ees g ´ en´ er´ e est ´ issu des jeux de donnees extraits de la PDB dans la m ´ eme section, qui sont indiqu ˆ es´ comme utilises pour la g ´ en´ eration de candidats. Les mesures effectu ´ ees sur la P ´ RIDB redondante sont des mesures statistiques. 1.3.5 Constitution des jeux d’apprentissage et de test Les jeux d’apprentissage sont constitues par ´ echantillonnage sans remise des can- ´ didats des deux classes pour chaque structure native : – 30 presque-natifs ; – 30 leurres de IRMSD > 8A. ˚ Pour que cet echantillonnage soit possible, pour chaque structure native, l’ ´ etape de ´ gen´ eration des candidats a assur ´ e qu’au moins 30 presque-natifs et 30 leurres de ´ IRMSD > 8A soient g ˚ en´ er´ es. Le seuil en I ´ RMSD de 8 A permet de s’assurer qu’il existe ˚ au moins 30 leurres suffisamment eloign ´ es des presque-natifs. ´ Les jeux de test contiennent l’ensemble des candidats gen´ er´ es. Le jeu de test de la ´ fonction de score finale est le jeu de validation, constitue des candidats g ´ en´ er´ es gr ´ ace ˆ 7Chapitre 1. Donnees ´ aux 40 complexes issus des Benchmarks I et II. Le faible nombre d’interactions non redondantes disponibles incite a utiliser au maximum les donn ` ees disponibles. ´ Pour effectuer une premiere ` evaluation avant de g ´ en´ erer la fonction de score ´ a partir ` des candidats issus des 120 structures natives, une strategie adapt ´ ee du ´ leave-one-out est employee : le ´ leave-”one-pdb”-out (present ´ e au chapitre pr ´ ec´ edent, section 0.6.1). ´ Avec le leave-”one-pdb”-out, pour chaque structure native, une fonction de score est apprise, avec : – en jeu de test, les 10 000 candidats de la structure native ; – en jeu d’apprentissage, les 30 presque-natifs et 30 leurres des 119 autres structures natives. Cet ensemble de differents jeux de donn ´ ees nous permet, tout en utilisant au max- ´ imum la quantite relativement faible de donn ´ ees disponibles, de valider le protocole ´ d’apprentissage a chaque ` etape. ´ 1.4 Mesures d’evaluation locales ´ Les donnees issues de l’ ´ evaluation des diff ´ erents jeux de donn ´ ees n ´ ecessitent l’util- ´ isation de mesures d’evaluation adapt ´ ees pour comparer les m ´ ethodes et leurs mises ´ en œuvre sur chaque jeu de donnees. Les mesures d’ ´ evaluation globales ont d ´ ej ´ a` et´ e´ detaill ´ ees pr ´ ec´ edemment (voir section 0.6.2). ´ Les mesures d’evaluation locales sont plus sp ´ ecifiques ´ a l’objectif qui nous int ` eresse ´ de discriminer les presque-natifs des leurres dans une prediction d’interactions prot ´ eine- ´ ARN. Parmi celles-ci, le nombre de presque-natifs dans le top10 est sans doute le plus important, puisqu’il s’agit de compter le nombre de presque-natifs contenus dans les 10 premiers candidats lorsque les candidats sont tries selon le score. Or, le nombre ´ de candidats que CAPRI accepte de recevoir comme solutions envisagees par une ´ fonction de score est justement de 10. Evidemment, ce nombre va de 0 ´ a 10 et, plus ` ce nombre est elev ´ e, meilleure est la pr ´ ediction. Pour qu’une fonction de score soit ´ consider´ ee comme ayant r ´ eussi ´ a mod ` eliser l’interaction, elle doit avoir au moins 1 ´ presque-natif dans le top10. Les diagrammes d’energie en fonction du RMSD ´ permettent d’identifier les entonnoirs (funnels) de la prediction. Sur le diagramme d’ ´ energie en fonction du RMSD, il ´ s’agit d’identifier une forme en entonnoir des points. Cet entonnoir se situe idealement ´ la pointe en bas a gauche du graphique, sa partie ` evas ´ ee partant en diagonale ´ a droite ` (voir fig. 1.3). Un entonnoir implique que la fonction de score indique, pour des candidats de RMSD donnee, une plage de valeurs de score inf ´ erieure pour des candidats ´ de RMSD superieure. La d ´ ecouverte d’un entonnoir est le signe que la fonction de ´ score evalu ´ ee est utilisable pour affiner la structure 3D de l’interaction recherch ´ ee. ´ Les candidats se trouvant dans le coin superieur gauche sont des presque-natifs mal ´ predits. De la m ´ eme mani ˆ ere, les candidats se trouvant dans le coin inf ` erieur droit sont ´ des leurres mal predits. Les candidats se trouvant dans le coin inf ´ erieur gauche sont ´ les presque-natifs correctement predits et ceux dans le coin sup ´ erieur droit des leurres ´ correctement predits. Les candidats du top10 sont les 10 premiers en partant du bas ´ 81.4. Mesures d’evaluation locales ´ du diagramme. C’est le diagramme de l’energie en fonction du I ´ RMSD qui est utilise´ comme critere d’ ` evaluation (not ´ e´ EvsRMS). EvsRMS −193 −177 −162 0 5 10 15 20 25 Irmsd Score FIGURE 1.3 – Exemples de diagramme d’EvsRMS : le diagramme d’energie en fonction ´ du IRMSD permet la detection d’entonnoir. Voici un exemple d’entonnoir, avec la ma- ´ jorite des candidats suivant un entonnoir partant du coin inf ´ erieur gauche pour s’ ´ evaser ´ dans le coin superieur droit. Une telle courbe permet de montrer que la fonction de ´ score proposee est utilisable pour de l’affinement de structure, une fois l’ ´ epitope de ´ l’interaction identifie. ´ Soit C un ensemble de candidats gen´ er´ e´ a partir d’un m ` eme complexe ˆ c, trie en ´ energie selon une fonction de score. Le ´ score d’enrichissement ES (C) mesure la performance d’une fonction de score pour maximiser la proportion des 10 % premiers candidats tries en I ´ RMSD parmi les 10 % premiers candidats tries en ´ energie. Ainsi, ´ le score d’enrichissement est le nombre de candidats de C dans les 10 % premiers candidats a la fois en ` energie et en I ´ RMSD, divise par le nombre total de candidats de ´ C multiplie par 100 (voir ´ eq. 1.2). En reprenant l’exemple du diagramme d’EvsRMS, ´ les candidats a la fois dans les 10 % premiers candidats en score et les 10 % premiers ` candidats en IRMSD correspondent aux candidats dans le coin inferieur gauche du ´ graphique, si l’on separe le graphique verticalement et horizontalement ´ a 10% des ` candidats en IRMSD et 10% des candidats en energie (voir fig. 1.4). ´ Plus le score d’enrichissement est elev ´ e, plus le tri est enrichi, c’est- ´ a-dire plus la ` proportion de presque-natifs est importante dans les 10 % premiers candidats du tri. Le score d’enrichissement va de 0 a 10. Dans le cas d’un tri parfait, le score d’en- ` richissement vaut 10. Quand il y a independance entre tri en ´ energie et tri en I ´ RMSD, le score s’enrichissement vaut 1. Un score d’enrichissement inferieur ´ a 1 indique qu’au- ` cun enrichissement n’est observe, correspondant ´ a une mauvaise fonction de tri. ` ES (C) = 100# (top10%IRMSD (C) ∩ top10%ENERGY (C)) # (C) (1.2) 9Chapitre 1. Donnees ´ EvsRMS −193 −177 −162 0 5 10 15 20 25 Irmsd Score FIGURE 1.4 – Illustration du score d’enrichissement sur une courbe EvsRMS : un trait horizontal (resp. vertical) divise le graphique en deux parties de telle sorte que 10 % des candidats soient toujours en-dessous (resp. a gauche) de la s ` eparation. Les can- ´ didats dans le cadran inferieur gauche sont les presque-natifs bien pr ´ edits, contraire- ´ ment aux candidats dans le cadran superieur gauche et le cadran inf ´ erieur droit. Les ´ leurres correctement predits se trouvent dans le cadran sup ´ erieur droit. Le score d’en- ´ richissement equivaut ´ a la proportion de candidats dans le cadran inf ` erieur gauche ´ parmi l’union des candidats en-dessous de la ligne de separation horizontale et des ´ candidats a gauche de la ligne de s ` eparation verticale. ´ 10Chapitre 2 Approche Rosetta et adaptation 2.1 Presentation de RosettaDock ´ RosettaDock est un outil de prediction d’interactions entre macromol ´ ecules bi- ´ ologiques. La prediction d’interactions de RosettaDock est conc¸ue et optimis ´ ee pour ´ modeliser les interactions entre prot ´ eines. RosettaDock s’appuie sur un protocole ´ appele´ amarrage (docking). D’autres protocoles en lien avec l’amarrage sont aussi disponibles via RosettaDock. Nous traiterons d’abord de l’amarrage avant de continuer sur les autres protocoles. 2.1.1 Amarrage L’amarrage consiste a pr ` edire la structure 3D repr ´ esentant l’interaction de deux ´ partenaires donnes pour chacun desquels la structure native est connue. Classique- ´ ment, la prediction de la structure 3D de l’interaction est r ´ ealis ´ ee en deux grandes ´ etapes : ´ 1. la gen´ eration d’un large ensemble de candidats (de conformation plausible pour ´ l’interaction des deux partenaires) ; 2. puis le tri de l’ensemble des candidats selon differents crit ´ eres permettant de ` rendre compte de la qualite des candidats pour repr ´ esenter l’interaction (taille de ´ l’interface, nombre de residus en contact ´ etc.). Dans les deux prochaines sections, nous allons sequentiellement d ´ etailler chacune ´ de ces deux etapes. ´ 2.1.1.1 Gen´ eration des candidats ´ L’etape de g ´ en´ eration des candidats consiste ´ a construire plusieurs amarrages 3D ` possibles des deux partenaires etudi ´ es. Un candidat g ´ en´ er´ e est d ´ efini par les coor- ´ donnees spatiales des atomes de ses partenaires. Afin de r ´ eduire le temps de calcul ´ de la gen´ eration, seules les coordonn ´ ees d’un des deux partenaires sont modifi ´ ees, ´ pour deplacer ce partenaire autour de l’autre partenaire, qui reste immobile. En r ´ egle ` 11Chapitre 2. Approche Rosetta et adaptation gen´ erale, le partenaire de plus petite taille est consid ´ er´ e comme mobile, alors que le ´ plus volumineux (en nombre d’acides amines ou d’acides nucl ´ eiques) est fixe. Dans ´ notre cadre d’etude, le partenaire mobile est l’ARN et le partenaire fixe est la prot ´ eine, ´ independamment de leurs tailles respectives. ´ L’espace des candidats possibles d’une interaction a 6 degres de libert ´ e (voir fig. ´ 2.1) : – la translation ρ suivant l’axe X ; – la rotation χ suivant l’axe X ; – la rotation φ1 suivant l’axe Y1 ; – la rotation θ1 suivant l’axe Z1 ; – la rotation φ2 suivant l’axe Y2 ; – la rotation θ2 suivant l’axe Z2. θ2 θ1 φ2 φ1 ρ χ O1 Y1 X1 Z1 Y2 X2 O2 Z2 FIGURE 2.1 – L’espace de recherche des candidats d’une interaction entre deux macromolecules biologiques a 6 degr ´ es de libert ´ e : ´ ρ, χ, φ1, θ1, φ2 et θ2. Image J.Bernauer, adaptee de [46]. ´ L’exploration quasi-exhaustive de l’espace de recherche n’est pas envisageable dans des temps de calcul raisonnables. Comme le montre Connolly [54, 55, 56], la quantite de candidats ´ a envisager pour tester toutes les combinaisons entre la surface ` de la proteine et celle de l’ARN est bien trop importante. Sur les 6 degr ´ es de libert ´ e,´ le nombre de candidats a envisager d ` epend essentiellement du pas en rotation et en ´ translation, mais aussi de la surface de Connolly de chacun des deux partenaires. La surface de Connolly depend de la taille d’un partenaire et de sa forme, puisqu’elle ´ reflete la surface accessible au solvant et donc la surface ` a explorer pour envisager les ` differentes interactions possibles avec un partenaire. Les diff ´ erentes interactions possi- ´ 122.1. Presentation de RosettaDock ´ bles avec un partenaire correspondent au nombre de candidats dont la construction est a envisager pour une exploration quasi-exhaustive de l’espace de recherche. Ce nom- ` bre de candidats peut depasser le million pour des partenaires de taille raisonnable ´ (environ 400 acides amines ou 40 acides nucl ´ eiques selon les moyennes constat ´ ees ´ sur la PRIDB). La gen´ eration des candidats ne s’int ´ eresse donc qu’ ´ a un sous-ensemble ` de candidats. Pour un nombre fixe de candidats ´ a g ` en´ erer, l’objectif est de maximiser ´ les chances d’obtenir des candidats presque-natifs parmi les candidats gen´ er´ es. ´ En utilisant une methode de Monte-Carlo, il est possible d’orienter la g ´ en´ eration des ´ candidats : plus un candidat a une energie faible et plus il aura de chances d’ ´ etre con- ˆ serve. L’exploration de l’espace des candidats donne alors plus probablement des can- ´ didats dans des sous-espaces contenant des candidats de faible energie. En r ´ eit ´ erant ´ un grand nombre de fois la methode de Monte-Carlo, la g ´ en´ eration des candidats per- ´ met de maximiser les chances d’obtenir des candidats de faible energie parmi les ´ candidats gen´ er´ es. En pratique, la r ´ eit ´ eration de la m ´ ethode de Monte-Carlo permet ´ de gen´ erer des candidats correspondant ´ a diff ` erents minima locaux, potentiellement ´ separ ´ es par des barri ´ eres d’ ` energie importantes. Ces barri ´ eres d’ ` energie, o ´ u les candi- ` dats ont une energie tr ´ es forte, emp ` echeraient d’appliquer une minimisation d’ ˆ energie ´ pour arriver a un candidat presque-natif ` a partir d’un puits d’ ` energie diff ´ erent. ´ Dans un modele o ` u les partenaires sont flexibles, il faut, apr ` es d ` eplacement d’un ´ partenaire par rapport a l’autre, prendre en compte la d ` eformation des partenaires. ´ Cette deformation s’effectue lorsque l’environnement proche des atomes des parte- ´ naires est modifie. La modification de l’environnement proche correspond ´ a la prox- ` imite avec des atomes de l’autre partenaire. La proximit ´ e entre atomes des deux parte- ´ naires definit une interface. Une fois une position d ´ etermin ´ ee pour le partenaire mobile, ´ la structure 3D des chaˆınes laterales est donc optimis ´ ee en fonction de son environ- ´ nement proche pour minimiser l’energie. ´ Pour minimiser les temps de calcul dans la modification des coordonnees de chaque ´ atome, on utilise les coordonnees internes (voir fig. 2.2) pour chaque acide amin ´ e et ´ chaque acide nucleique. Un arbre des coordonn ´ ees des atomes est construit pour ´ chaque acide amine et chaque acide nucl ´ eique : ´ – chaque atome a 3 atomes parents dans l’arbre ; – la distance r est la distance au premier parent ; – l’angle θ donne l’angle forme entre les deux premiers parents et le premier parent ´ avec l’atome, dans le plan forme par les droites des deux premiers et des deux ´ derniers parents ; – l’angle φ est l’angle entre les deux derniers parents et le premier parent avec l’atome, dans le plan perpendiculaire a la droite form ` ee par les deux premiers ´ parents. Ainsi, modifier les coordonnees de tout un acide amin ´ e ou acide nucl ´ eique ne ´ necessite pas de modifier les coordonn ´ ees de l’ensemble de ses atomes. Par ailleurs, ´ les angles θ et φ definis chacun pour 2 des rotations d’un partenaire par rapport ´ a` l’autre correspondent aux rotations θ et φ dans des coordonnees torsionnelles. ´ 13Chapitre 2. Approche Rosetta et adaptation CG1 C CG1 C Cβ Cα r y x φ θ Cα FIGURE 2.2 – La manipulation des coordonnees des structures 3D se fait ´ a l’aide ` des coordonnees internes : chaque acide amin ´ e et chaque acide nucl ´ eique sont ´ represent ´ es sous la forme d’un arbre passant par les liaisons covalentes entre les ´ atomes (les cycles sont coupes). Chaque atome a 3 atomes parents, ´ a l’exception des ` 3 premiers atomes qui sont definis les uns par rapport aux autres. La position d’un ´ atome est definie par la distance ´ r a son premier atome parent et par les angles ` θ et φ. Le ref ´ erentiel de coordonn ´ ees cart ´ esien est donn ´ e´ a titre indicatif. Les atomes donn ` es´ en exemple sont C, Cα, Cβ et l’atome gros-grain CG1. 2.1.1.2 Tri des candidats L’etape de g ´ en´ eration des candidats n’explore pas de mani ´ ere exhaustive l’espace ` des conformations possibles entre les deux partenaires etudi ´ es. Toutefois, il est impor- ´ tant de noter que, en regle g ` en´ erale, le nombre de candidats devant ´ etre g ˆ en´ er´ es pour ´ esperer obtenir des candidats presque-natifs est ´ elev ´ e, de l’ordre de 10 000. Certaines ´ fonctions d’evaluation ne sont pas diff ´ erentiables, ce qui ne permet pas de mettre en ´ place des approches efficaces de minimisation. C’est notamment le cas de la fonction de score gros-grain de RosettaDock, qui somme un terme de score defini par une ´ fonction discrete avec d’autres termes de score (voir section 2.1.2.2). ` Sur ce grand nombre de candidats, seul un petit nombre d’entre eux ont une chance d’etre des presque-natifs. La proportion est g ˆ en´ eralement consid ´ er´ ee de l’ordre de ´ 1 pour 1 000 pour la grande majorite des complexes, mais il est attendu d’un bon ´ algorithme d’amarrage de depasser cet ordre de grandeur [114]. ´ Il existe deux types d’erreurs pouvant apparaˆıtre suite au tri des candidats. Ils ont des couts tr ˆ es diff ` erents : ´ – ne pas reussir ´ a mettre un presque-natif en avant face aux leurres oblige ` a` gen´ erer plus de candidats pour obtenir un presque-natif dans les premiers can- ´ didats du tri ; 142.1. Presentation de RosettaDock ´ – mettre un leurre en avant par rapport aux presque-natifs donne l’illusion d’avoir trouve un presque-natif, sur lequel peuvent ensuite se baser des exp ´ eriences qui ´ coutent cher (par exemple, de cristallographie). ˆ Il est donc imperatif de mettre en place d’autres crit ´ eres d’ ` evaluation les plus efficaces ´ possibles pour eviter ces deux types d’erreurs et identifier les presque-natifs parmi ´ l’ensemble des candidats. Nous appelons fonctions de score les differents crit ´ eres d’ ` evaluation que nous al- ´ lons etudier. Selon les besoins, plusieurs fonctions de score peuvent ´ etre d ˆ efinies et ´ appliquees. Une premi ´ ere fonction de score agit comme un filtre permettant de sup- ` primer les leurres les plus evidents. Ce filtre est ´ evalu ´ e sur l’ensemble des configura- ´ tions testees pour la g ´ en´ eration d’un candidat. Le filtre doit donc ´ etre rapide ˆ a calculer. ` Le filtre prend en consideration les crit ´ eres suivants : ` – chevauchements des structures ; – nombre d’atomes impliques dans l’interaction. ´ Pour chaque candidat, si les chevauchements sont trop importants ou si le nombre d’atomes impliques dans l’interaction est trop faible, alors la probabilit ´ e qu’il s’agisse ´ d’un leurre est elev ´ ee. Le filtre associe alors un score ´ elev ´ e au candidat consid ´ er´ e. Si ´ le candidat consider´ e a un score trop ´ elev ´ e, il ne fera pas partie des candidats g ´ en´ er´ es. ´ Une seconde fonction de score est definie pour ´ evaluer et optimiser la structure 3D des ´ chaˆınes laterales ´ a l’interaction. Une telle fonction de score a pour but de donner une ` structure 3D plus fidele` a la r ` ealit ´ e biologique. Gr ´ ace ˆ a la minimisation des cha ` ˆınes laterales, les atomes des cha ´ ˆınes laterales voient leurs coordonn ´ ees adapt ´ ees ´ a l’in- ` teraction avec les atomes du partenaire. Un score final est enfin attribue´ a chaque ` candidat, pour evaluer sa structure 3D dans son ensemble et trier les candidats en ´ fonction de leur probabilite de repr ´ esenter correctement l’interaction. Pour calculer ce ´ score, l’ensemble des termes de score est agreg´ e pour chaque candidat. La fonction ´ d’agregation est une somme pond ´ er´ ee. ´ Selon l’objectif du score, ce dernier utilise pref´ erentiellement des param ´ etres issus ` de differents mod ´ eles g ` eom ´ etriques. Un score permettant d’affiner une structure 3D ´ doit pouvoir correctement evaluer l’ ´ energie issue d’interactions avec le solvant, d’o ´ u le ` calcul de l’influence de la solvatation a l’ ` echelle atomique. ´ A l’inverse, un score utilis ` e´ comme filtre a besoin d’etre calcul ˆ e rapidement et se focalise pr ´ ef´ erentiellement sur ´ des parametres calcul ` es´ a l’ ` echelle gros-grain. ´ 2.1.1.3 Amarrages gros-grain ou atomique L’echelle ´ a laquelle s’effectue l’amarrage convient ` a des probl ` ematiques sp ´ ecifiques. ´ Pour chaque problematique standard d’amarrage, il existe un protocole d’amarrage. ´ L’amarrage gros-grain a pour but de decouvrir l’ ´ epitope ´ (ou zone d’interaction), c’esta-dire identifier les acides nucl ` eiques et acides amin ´ es impliqu ´ es dans l’interaction. ´ L’amarrage atomique a pour but de determiner la structure 3D de l’interaction ´ a l’ ` echelle ´ de l’Angstrom voire en-dessous. Il peut arriver qu’un amarrage atomique soit utilis ¨ e´ lorsque l’on connaˆıt dej ´ a l’ ` epitope, pour affiner la structure 3D identifi ´ ee. ´ Pour reduire les temps de calcul, un amarrage atomique dont on ne conna ´ ˆıt pas l’epitope est g ´ en´ eralement pr ´ ec´ ed´ e d’un amarrage gros-grain. Dans un contexte de ´ 15Chapitre 2. Approche Rosetta et adaptation prediction ´ a l’aveugle comme CAPRI, o ` u on ne connait pas la solution, on proc ` ede ` en gen´ eral ´ a un amarrage atomique ` a partir des structures candidates g ` en´ er´ ees par ´ l’amarrage gros-grain. 2.1.2 Autres strategies ´ Selon le contexte, d’autres strategies pour affiner l’amarrage local peuvent ´ etre ˆ envisagees : ´ – minimisation d’une structure ; – gen´ eration par perturbation d’un nuage de candidats autour d’une structure 3D ; ´ – evaluation du score d’une structure sans modification de la structure 3D. ´ La minimisation correspond le plus souvent a une descente de gradient pour obtenir ` un minimum local proche de la structure 3D donnee en entr ´ ee. Une strat ´ egie de min- ´ imisation du score permet de comparer les candidats gen´ er´ es par diff ´ erents outils de ´ gen´ eration de candidats, chaque outil ayant une fonction de score diff ´ erente avec des ´ minima qui ne correspondent pas necessairement d’un outil ´ a l’autre. Tous les outils de ` gen´ eration de candidats n’ont pas non plus le m ´ eme seuil ˆ a partir duquel deux atomes ` sont consider´ es en interaction. La minimisation permet, pour une I ´ RMSD tres petite ` (normalement de moins de 1A), de potentiellement diminuer drastiquement l’ ˚ energie. ´ Ceci est du au fait que des contraintes ˆ a faible distance peuvent donner de tr ` es fortes ` penalit ´ es aux structures 3D. ´ La gen´ eration par perturbation de candidats autour d’une structure 3D est utilis ´ ee, ´ lorsque l’on connaˆıt dej ´ a l’interaction, pour g ` en´ erer des candidats presque-natifs et ´ leurres. Cette strategie correspond ´ a un amarrage atomique, mais en g ` en´ erant les can- ´ didats selon une operation de rotation-translation al ´ eatoire du partenaire mobile, sans ´ utilisation de l’algorithme de Monte-Carlo. De plus, cette strategie part de la structure ´ native directement, i.e. de la solution, plutot que de partir de la structure 3D de chacun ˆ des deux partenaires. Cette strategie est davantage d ´ etaill ´ ee dans la section traitant ´ de la gen´ eration de candidats par perturbation (voir section 1.3.2). La g ´ en´ eration par ´ perturbation de candidats a dej ´ a` et ´ e utilis ´ ee pour mettre en place et ´ evaluer la fonction ´ de score proteine-prot ´ eine de RosettaDock [98]. ´ Evaluer le score d’une structure 3D sans g ´ en´ eration de candidats est g ´ en´ eralement ´ d’inter´ et lorsque l’on compare diff ˆ erentes fonctions de score ou pour ´ evaluer l’ ´ energie ´ d’une structure native. La comparaison des fonctions de score peut avoir lieu a des ` fins d’evaluation de la structure ou des fonctions de score, comme dans ce manuscrit. ´ L’evaluation de l’ ´ energie d’une structure native permet de v ´ erifier la coh ´ erence d’une ´ fonction de score avec les structures natives disponibles. En effet, une fonction de score correctement modelis ´ ee doit id ´ ealement attribuer une ´ energie plus faible ´ a la ` structure native qu’aux structures des candidats. 2.1.2.1 Fonctions de score atomique : termes physico-chimiques Les termes physico-chimiques sont calcules en utilisant des connaissances issues ´ des propriet ´ es physico-chimiques des interactions entre atomes. ´ A l’ ` echelle atomique, ´ 162.1. Presentation de RosettaDock ´ RosettaDock utilise 10 types de termes de score repartis en 6 groupes (voir fig. 2.3). ´ Sur l’ensemble des equations, les m ´ emes notations sont utilis ˆ ees pour d ´ esigner les ´ memes entit ˆ es, o ´ u : ` – E est le terme de score, modelisant une ´ energie physico-chimique ; ´ – w est le poids donne au terme de score ; ´ – N est le nombre d’atomes ; – Naa est le nombre d’atomes gros-grain des acides amines ; ´ – Nna est le nombre d’atomes gros-grain des acides nucleiques ; ´ – M est le nombre d’acides amines ; ´ – L est le nombre d’acides nucleiques ; ´ – d est la distance entre deux atomes ; – P est une probabilite estim ´ ee ; ´ – σ est la distance minimale d’approche entre deux atomes, somme de leurs rayons de Van der Waals [21] ; – q est une charge positive ou negative ; ´ – ∆Gf r ee est l’energie de Gibbs [162] ; ´ – V est le volume atomique [21] ; – λ est la longueur de correlation d’un atome [144] ; ´ – φ est l’angle diedre d’un rotam ` ere form ` e par le quadruplet d’atomes successifs ´ CO0 − NH1 − Cα1 − CO1 [209] ; – ψ est l’angle diedre d’un rotam ` ere form ` e par le quadruplet d’atomes successifs ´ NH1 − Cα1 − CO1 − NH2 [209] ; – ξ est l’environnement d’un atome. Les deux termes de score attractif (fa atr) et repulsif ´ (fa rep) de Van der Waals representent respectivement l’attraction et la r ´ epulsion universelle entre atomes. In- ´ dependamment du type d’atome, deux atomes se repoussent s’ils sont trop proches ´ l’un de l’autre. Alternativement, deux atomes s’attirent lorsqu’ils sont suffisamment loin l’un de l’autre, jusqu’a une attraction asymptotiquement nulle au fur et ` a mesure que ` la distance croˆıt. Les equations de Lennard-Jones 12-6 pr ´ esent ´ ees ici (voir ´ eq. 2.1 et ´ 2.2) sont une simplification de l’energie de Van der Waals, o ´ u` εij est la profondeur du puits d’energie pour ´ i et j. L’energie de Van der Waals est uniquement calcul ´ ee pour ´ les atomes a moins de 8 ` A de distance. Au-del ˚ a de 8 ` A, l’ ˚ energie de Van der Waals est ´ donc consider´ ee par le mod ´ ele comme nulle. Cette approximation permet de minimiser ` les temps de calcul alloues au calcul de ces deux termes de score. La partie attractive ´ est utilisee pour 0.89 ´ σij A˚ < dij < 8A alors que la partie r ˚ epulsive est utilis ´ ee pour ´ 0.6σij A˚ < dij ≤ 0.89σij A. ˚ Efa at r = wfa at r X N i=1 X N j>i εij  σij dij 12 − 2  σij dij 6 ! (2.1) Efa r ep = wfa r epX N i=1 X N j>i εij    σij 0.6σij 12 − 2  σij 0.6σij 6 − 0.6σij − dij  −12σ 12 ij (0.6σij) 13 + 12σ 6 ij (0.6σij) 7    (2.2) 17Chapitre 2. Approche Rosetta et adaptation FIGURE 2.3 – L’energie potentielle d’une structure 3D de macromol ´ ecules biologiques, ´ souvent assimilee´ a un score, est g ` en´ eralement calcul ´ ee selon une somme de ter- ´ mes modelisant des ph ´ enom ´ enes physico-chimiques sp ` ecifiques. Les termes peuvent ´ porter sur les interactions covalentes (liens, angles, torsions) ou non covalentes (attraction et repulsion universelles, forces ´ electrostatiques, liaisons hydrog ´ ene, ` etc.). Image adaptee de Scientific American / Adv Drug Del Rev. ´ Dans la cellule, le complexe proteine-ARN est plong ´ e dans un solvant. Il est donc ´ necessaire que le mod ´ ele` in silico prenne cette caracteristique en compte. Le terme de ´ solvatation (fa sol) est modelis ´ e dans cet objectif. Le terme de solvatation favorise l’ac- ´ cessibilite des parties hydrophiles solvant et l’inaccessibilit ´ e des parties hydrophobes ´ au solvant (voir eq. 2.3). Ce terme de score demande le calcul de l’accessibilit ´ e au ´ solvant, qui coute cher en temps de calcul [144]. ˆ Efa sol = wfa sol X N i=1 X N j>i   2∆Gf r ee i exp  −d 2 ij  4π √ πλiσ 2 ij Vj + 2∆Gf r ee j exp  −d 2 ij  4π p πλjσ 2 ij Vi   (2.3) 182.1. Presentation de RosettaDock ´ FIGURE 2.4 – Presentation de l’ ´ energie de Van der Waals, o ´ u` ε correspond a la pro- ` fondeur du puits d’energie. L’ ´ energie de Van der Waals poss ´ ede une part r ` epulsive de ´ 0 A jusqu’ ˚ a 0.89 ` σij A et une part attractive au-del ˚ a.` Meme sans aller jusqu’ ˆ a` etre charg ˆ e positivement ou n ´ egativement, un atome peut ´ avoir une charge partielle. Cette charge partielle attire pref´ erentiellement l’atome en ´ question vers les atomes ayant une charge partielle opposee. De plus, certains atomes ´ sont plus frequemment observ ´ es´ a proximit ` e l’un de l’autre qu’avec d’autres atomes. ´ Le terme d’affinite entre paires d’atomes ´ (fa pair) donne un score plus favorable aux atomes ayant une forte affinite entre eux (voir ´ eq. 2.4). Seuls les atomes interagissant ´ entre eux ont une valeur calculee pour fa ´ pair (int dans l’equation). Le terme d’affinit ´ e´ entre paires d’atomes classe chaque atome en quatre environnements, selon sa proximite avec un atome de l’autre partenaire et son accessibilit ´ e au solvant. Pour chaque ´ environnement, chaque paire de type d’atomes obtient un score different. Les quatre ´ environnements possibles sont : – l’atome est dans l’interaction et accessible au solvant ; – l’atome est dans l’interaction et inaccessible au solvant ; – l’atome est hors de l’interaction et accessible au solvant ; – l’atome est hors de l’interaction et inaccessible au solvant. Efa pai r = wfa pai r Y M m=1 Y L l=1 P (m, l|int, ξm, ξl) P (m|int, ξm)P (l|int, ξl) (2.4) Outre les affinites qu’il peut y avoir entre des atomes partiellement charg ´ es, les ´ charges, lorsqu’elles sont presentes, ont aussi un impact sur les interactions entre ´ atomes. Le modele de Coulomb d ` ecrit pour cela l’interaction entre atomes charg ´ es´ en fonction de la valence de leur charge et de la distance qui les separe. Le terme ´ electrostatique ´ (hack elec) utilise le modele de Coulomb (voir ` eq. 2.5). ´ Ehack elec = whack elec X N i=1 X N j>1 332qiqj min dij, 32 (2.5) 19Chapitre 2. Approche Rosetta et adaptation Un phenom ´ ene plus sp ` ecifique de charge partielle intervient dans la cr ´ eation et le ´ maintien d’interactions entre molecules et ´ a l’int ` erieur d’une m ´ eme mol ˆ ecule. Il s’agit ´ de la formation de liaisons hydrogene. Les liaisons hydrog ` ene se forment entre un ` hydrogene de charge partielle positive et un autre atome de charge partielle n ` egative ´ (gen´ eralement un oxyg ´ ene ou un azote). Ces liaisons sont des liaisons non covalentes, ` mais qui participent aux interactions de par leur multiplicite. Les quatre termes de li- ´ aisons hydrogene ` (hbond sc, hbond bb sc, hbond lr bb, hbond sr bb) favorisent l’existence de liaisons hydrogene (voir ` eq. 2.6). Le score donn ´ e aux liaisons hydrog ´ ene ` depend de la distance d’interaction, ´ a courte port ` ee ou ´ a longue port ` ee, et de la local- ´ isation des atomes d’hydrogene, dans le squelette ou dans la cha ` ˆıne laterale. ´ Ehbond ∗ = whbond ∗ X N i=1 X N j>i 5  σij dij 12 − 6  σij dij 10! F (q) (2.6) Les chaˆınes laterales des acides amin ´ es sont flexibles et peuvent adopter plusieurs ´ conformations. Ces conformations sont categoris ´ ees par probabilit ´ e d’apparition dans ´ le diagramme de Ramachandran. La base de donnees de rotam ´ eres de Dunbrack ` [70] a et ´ e conc¸ue sur le m ´ eme principe pour d ˆ eterminer, selon la conformation de ´ la chaˆıne laterale, la probabilit ´ e d’apparition correspondante. Le terme de rotam ´ eres ` de Dunbrack (fa dun) donne un score plus favorable aux rotameres les plus pr ` esents ´ dans les complexes proteine-prot ´ eine connus (voir ´ eq. 2.7). Le terme de rotam ´ eres de ` Dunbrack n’est, pour le moment, utilise que pour les acides amin ´ es. ´ Efa dun = wfa dunX M m=1 − ln Ptype(m) (φmψm)  (2.7) 2.1.2.2 Termes physico-chimiques a l’ ` echelle gros-grain ´ A l’ ` echelle gros-grain, RosettaDock calcule quatre types de termes de score. Les ´ atomes consider´ es sont alors des atomes gros-grain. Dans cette section, on note ´ N le nombre d’atomes gros-grain. Le terme de contact (interchain contact) est une version simplifiee du terme d’at- ´ traction de Van der Waals. Le score donne au terme de contact est une fonction ´ discrete d ` ependant du nombre ´ nInt d’atomes gros-grain a l’interface. Cette fonction ` discrete est d ` efinie par une droite avec une valeur extr ´ eme et deux points particuliers. ˆ S’il n’y a aucun atome gros-grain en interaction, le terme de contact vaut 12. S’il y a 2 atomes gros-grain en interaction, il vaut 9.5. Entre 3 et 19 atomes gros-grain, il vaut 10 − 0.5 ∗ nInt . Au-dela de 19 atomes gros-grain, il est ` egal ´ a sa valeur extr ` eme : ˆ −10. Le terme de repulsion de Van der Waals gros-grain ´ (interchain vdw) est aussi une version simplifiee du terme de r ´ epulsion de Van der Waals atomique. Le terme de ´ repulsion de Van der Waals gros-grain vaut entre 0 et 1. Il utilise un param ´ etre ` dα,β determin ´ e au moyen d’une mesure statistique sur un jeu de donn ´ ees de complexes, o ´ u` α est le type de l’atome i et β le type de l’atome j (voir eq. 2.8). Nous avons notamment ´ 202.2. Evaluation de la fonction de score non optimis ´ ee´ determin ´ e les valeurs de ce param ´ etre pour chaque paire ( ` α, β) de type d’atomes grosgrain. Einter chain vdw = winter chain vdw X Naa i=1 X Nna j=1  d 2 α,β − d 2 ij  d 2 α,β (2.8) Le terme d’affinite par paire d’atomes gros-grain ´ (interchain pair) fonctionne de la meme mani ˆ ere que le terme d’affinit ` e par paire d’atomes. ´ Le terme d’environnement (interchain env) reprend le principe d’environnement des termes d’affinite par paire d’atomes. Le terme d’environnement donne un score favor- ´ able aux atomes gros-grain se trouvant dans les environnements ou ils ont le plus de ` chances d’etre trouv ˆ es. Le terme d’environnement prend aussi en compte une version ´ simplifiee du terme de solvatation. ´ 2.2 Evaluation de la fonction de score non optimis ´ ee´ La fonction de score non optimisee pour les complexes prot ´ eine-ARN est la fonc- ´ tion de score par defaut dans RosettaDock. Cette fonction de score est directement ´ issue de l’amarrage proteine-prot ´ eine : elle est optimis ´ ee pour l’amarrage prot ´ eine- ´ proteine. Nous appellerons cette fonction de score ´ ROS. Nous allons d’abord observer les mesures d’evaluation globales avant de traiter les mesures d’ ´ evaluation locales. ´ 2.2.1 Mesures d’evaluation globales ´ Les mesures d’evaluation globales peuvent s’appliquer lorsque l’on dispose de la ´ matrice de confusion. Calculer la matrice de confusion necessite de d ´ eterminer un ´ seuil a partir duquel la fonction de score s ` epare en presque-natifs et en leurres les ´ candidats predits. Nous utilisons deux seuils diff ´ erents. Le premier seuil est le seuil ´ permettant d’obtenir, pour chaque complexe, le meilleur Fscore (voir section 0.6.2). Ce seuil permet de savoir a quel point la fonction de score peut trouver un compromis ` entre deux types d’erreurs : predire presque-natif un leurre (Faux Positif) et ne pas ´ predire presque-natif un presque-natif (Faux N ´ egatif). ´ Avec ce seuil, le nombre de candidats predits presque-natifs est tr ´ es` elev ´ e (voir ´ tableau 2.1). Le rappel est tres` elev ´ e, mais on peut remarquer avec la pr ´ ecision que ´ la moitie des candidats pr ´ edits sont des presque-natifs. En moyenne, chaque candidat ´ predit presque-natif a donc une chance sur deux d’ ´ etre un presque-natif. Et le rappel ˆ montre que la quasi-totalite des presque-natifs sont pr ´ edits presque-natifs. De plus, ´ la specificit ´ e continue de montrer que la fonction de score ROS n’est pas adapt ´ ee´ a` la prediction d’interactions prot ´ eine-ARN. Pour plus de la moiti ´ e des complexes, les ´ leurres predits par la fonction de score ROS repr ´ esentent moins de 1 % des v ´ eritables ´ leurres. Dit autrement, plus de 99 % des leurres sont predits comme ´ etant des presque- ´ natifs. 21Chapitre 2. Approche Rosetta et adaptation Aggregat ´ Precision ´ Rappel Fscore Accuracy Specificit ´ e´ Seuil Moyenne 49.52% 98.68% 65.94% 50.75% 2.27% 9 874 Mediane pr ´ ecision ´ 47.44% 99.99% 64.35% 47.45% 0.06% 9 998 Mediane Fscore ´ 46.51% 99.99% 63.49% 46.53% 0.06% 9 997 TABLE 2.1 – Evaluation globale de la fonction de score ROS sur la P ´ RIDB, sous le seuil du meilleur Fscore pour chaque complexe, avec la moyenne et la mediane sur les ´ 120 complexes de la PRIDB. La derniere colonne correspond au nombre de candidats ` predits presque-natifs au seuil du meilleur Fscore et permet de comparer ces r ´ esultats ´ a ceux du top10. Pour le calcul des mesures des lignes concernant la m ` ediane, ce sont ´ les exemples correspondant a la m ` ediane de la pr ´ ecision, d’une part, et du Fscore, ´ d’autre part, qui sont utilises. ´ L’evaluation de la fonction de score par des mesures globales avec un seuil d ´ efini ´ par le Fscore donne des resultats apparemment satisfaisants. Mais le seuil est alors ´ different pour chaque complexe et n ´ ecessite de conna ´ ˆıtre a l’avance le r ` esultat. On ´ ne peut donc pas choisir ce seuil, qui est gen´ eralement tr ´ es` elev ´ e, avec la plupart ´ des valeurs au-dela de 9 990 candidats pr ` edits presque-natifs. Le seuil d ´ efini par le ´ meilleur Fscore est uniquement etudi ´ e pour mesurer un compromis de performance ´ de la fonction de score. De plus, meme si l’on pouvait trouver ce seuil de compro- ˆ mis entre precision et rappel, la pr ´ ecision n’est que de moiti ´ e. Cela signifie que, en ´ prenant au hasard un candidat parmi les candidats predits, il y a en moyenne 50 % de ´ chances que le candidat predit ne soit pas un presque-natif. Or, l’objectif est justement ´ de nous assurer de pouvoir trouver au moins un presque-natif, avec comme marge de manœuvre le fait de pouvoir en selectionner 10. ´ Le second seuil est fixe´ a 10 candidats, ce qu’on appelle le top10. Ainsi, seuls les ` 10 meilleurs candidats au sens du tri oper´ e par la fonction de score sont consid ´ er´ es´ comme des presque-natifs. Tous les autres candidats sont predits comme ´ etant des ´ leurres. Avec un seuil au top10, on ne s’attend pas a avoir un fort rappel (ou sensibilit ` e)´ lorsque le nombre de presque-natifs est grand dans l’ensemble des exemples testes. ´ Rappelons que le nombre de presque-natifs est d’au moins 30 pour chaque complexe de la PRIDB. Et le rappel est effectivement tres bas (voir tableau 2.2). Mais surtout, ` la precision est aussi tr ´ es basse, avec 59 des 120 complexes - soit pr ` es de la moiti ` e´ d’entre eux - n’ayant aucun presque-natif dans le top10 (voir tableau S2). On voit donc que les mesures d’evaluation globales affichent parfois des r ´ esultats ´ tres satisfaisants, avec un rappel ou une sp ` ecificit ´ e tr ´ es forte. Mais les r ` esultats ne ´ correspondent en realit ´ e pas aux objectifs fix ´ es, ce que peut montrer notamment la ´ precision. C’est pourquoi il est utile de passer ´ a des mesures d’ ` evaluation locales. ´ 222.2. Evaluation de la fonction de score non optimis ´ ee´ Aggregat ´ Precision ´ Rappel Fscore Accuracy Specificit ´ e´ Moyenne 29.25% 0.05% 0.09% 68.17% 99.83% Mediane pr ´ ecision ´ 10.00% 0.06% 0.12% 81.13% 99.89% Mediane Fscore ´ 15.00% 0.02% 0.04% 26.26% 99.28% TABLE 2.2 – Evaluation globale de la fonction de score ROS sur la P ´ RIDB, sous le seuil de 10 candidats (top10), avec la moyenne et la mediane sur les 120 complexes ´ de la PRIDB. Pour la mediane, ce sont les complexes correspondant ´ a la m ` ediane de ´ la precision, d’une part, et du Fscore, d’autre part, qui sont utilis ´ es pour calculer les ´ differentes mesures, dont les lignes sont intitul ´ ees pr ´ ecision et Fscore. ´ 2.2.2 Mesures d’evaluation locales ´ Les mesures d’evaluation locales sont au moins pour certaines plus sp ´ ecifiques au ´ probleme ` etudi ´ e et plus adapt ´ ees aux objectifs fix ´ es pour la pr ´ ediction d’interactions ´ proteine-ARN. Les mesures d’ ´ evaluation locales se d ´ eclinent en deux axes : ´ – d’une part, des mesures sur les performances de la fonction de score, comme l’aire sous la courbe ROC ; – d’autre part, des mesures davantage focalisees sur les objectifs biologiques de ´ la prediction, comme le nombre de presque-natifs dans le top10 des candidats, ´ le score d’enrichissement et le diagramme d’energie en fonction du I ´ RMSD. Les aires sous la courbe ROC sont en moyenne de 0.37, avec une variance de 0.02. On pourrait penser qu’inverser la prediction donn ´ ee par la fonction de score ROS ´ donnerait de meilleurs resultats. Inverser la pr ´ ediction correspond par exemple ´ a at- ` tribuer a chaque candidat le n ` egatif de son score, ce qui inverse l’ordre dans lequel ´ les candidats se situent dans un tri selon le score. Pour l’aire sous la courbe ROC, cela aurait pour consequence d’obtenir le miroir par rapport ´ a 0.5 de la valeur de l’aire ` sous la courbe de ROC (ici, 0.63, puisque 0.5 − 0.37 = 0.13 et 0.5 + 0.13 = 0.63). Cependant, c’est sans compter sur le fait que la proportion de presque-natifs dans un ensemble de candidats est bien plus faible pour une prediction ´ a l’aveugle (de l’ordre ` de 1 a 10 pour 10 000 avec un bon protocole de g ` en´ eration de candidats). Inverser la ´ prediction reviendrait certainement ´ a donner une ` energie ´ elev ´ ee´ a une grande partie ` des presque-natifs de faible energie. ´ De la meme mani ˆ ere, avec 59 complexes sur 120, pr ` es de la moiti ` e des complexes ´ n’ont aucun presque-natif dans le top10 des meilleurs candidats en energie. Formul ´ e´ autrement, en prenant un complexe au hasard de la PRIDB, il y a une chance sur deux que la prediction ne propose aucun candidat satisfaisant. La fonction de score ROS ne ´ permet pas la prediction des interactions prot ´ eine-ARN. ´ Les diagrammes d’energie en fonction du I ´ RMSD permettent de constater que la fonction de score ROS n’est pas adaptee´ a un raffinement d’une structure de haute ` resolution prot ´ eine-ARN. En effet, aucun des complexes ne montre un entonnoir sur la ´ totalite de ses candidats : il existe toujours de nombreux candidats de faible ´ energie et ´ ayant un IRMSD elev ´ e (voir 2.5). On peut aussi constater plus clairement qu’inverser la ´ fonction de score ROS amenerait ` a n’avoir qu’une tr ` es faible quantit ` e de candidats de ´ 23Chapitre 2. Approche Rosetta et adaptation faible energie, souvent avec un I ´ RMSD superieur ´ a 5 ` A. ˚ Irmsd (Å) Score 0 20 −200 3350 Irmsd (Å) Score 0 20 −530 3400 Irmsd (Å) Score 0 20 −90 4940 FIGURE 2.5 – Exemples de diagrammes d’energie en fonction du I ´ RMSD pour la fonction de score ROS sur 3 complexes. On remarque l’absence d’entonnoir. De nombreux complexes montrent des diagrammes semblables pour la fonction de score ROS, qui n’est pas adaptee. ´ On note toutefois que certains complexes peuvent etre consid ˆ er´ es comme ayant ´ un entonnoir, jusqu’a une faible valeur de I ` RMSD (voir 2.6). Au-dela de cette valeur en ` IRMSD, de l’ordre de 2 ou 3A et propre ˚ a chacun de ces complexes, la fonction de ` score ROS donne une energie comparable entre des candidats ayant un I ´ RMSD faible comme elev ´ e. ´ Irmsd (Å) Score 0 20 −210 2980 Irmsd (Å) Score 0 20 −1190 4730 Irmsd (Å) Score 0 20 −930 5030 FIGURE 2.6 – Meilleurs exemples de diagrammes d’energie en fonction du I ´ RMSD pour la fonction de score ROS sur 3 complexes. On remarque un entonnoir s’arretant rapide- ˆ ment. Rares sont les complexes montrant des diagrammes semblables pour la fonction de score ROS. Si la fonction de score non optimisee ROS n’est pas adapt ´ ee´ a la pr ` ediction d’in- ´ teractions proteine-ARN, il est possible d’optimiser une fonction de score similaire. ´ Nous verrons lors de l’optimisation de la fonction de score, avec le filtrage a priori, que ROS est initialement apprise pour predire des candidats dont certains leurres sont ´ 242.3. Optimisation de la fonction de score dej ´ a filtr ` es. Il s’agit notamment des candidats avec trop d’interp ´ en´ etrations, aussi ap- ´ pelees ´ clashes, notion modelis ´ ee par le terme de score fa ´ rep. Ce constat, couple au ´ fait que ROS n’a pas et ´ e construite pour pr ´ edire d’interactions prot ´ eine-ARN, explique ´ son echec sur la pr ´ ediction d’interactions prot ´ eine-ARN. Mais nous verrons aussi et ´ surtout d’autres approches d’optimisation. 2.3 Optimisation de la fonction de score La combinaison lineaire de termes physico-chimiques est la seule forme de fonc- ´ tion de score que RosettaDock peut nativement utiliser. Nous mettons donc en œuvre l’apprentissage d’une fonction de score etant la combinaison lin ´ eaire des 10 attributs ´ physico-chimiques atomiques disponibles pour chaque candidat. L’equation 2.9 montre ´ pour un candidat c la combinaison lineaire ´ E(c) des |A| attributs physico-chimiques ai . wai representent les poids de la fonction de score et ´ Eai (c) la valeur de l’attribut ai pour le candidat c. E(c) = X |A| i=1 waiEai (c) (2.9) Une autre formulation envisageable est celle present ´ ee dans l’ ´ equation 2.10 avec ´ des notations plus classiquement utilisees en apprentissage. On retrouve ´ X qui designe ´ le candidat c, xi qui represente la valeur de l’attribut ´ Eai pour le candidat c (Eai (c)) et wi le poids du i eme attribut. E(X) = X |A| i=1 wixi (2.10) Par souci de simplicite et pour ´ eviter d’introduire un formalisme trop distant des ´ conventions usuelles en apprentissage automatique, nous utiliserons les notations present ´ ees dans l’ ´ equation 2.10. ´ Les poids wi doivent etre d ˆ efinis soit ´ a partir de connaissances physico-chimiques, ` soit a partir de donn ` ees d ´ ej ´ a connues, c’est- ` a-dire des complexes prot ` eine-ARN pour ´ lesquels un ensemble de presque-natifs et un ensemble de leurres sont connus. Pour conserver la semantique biologique de la fonction de score qui repr ´ esente une ´ energie, ´ les presque-natifs doivent avoir des scores de valeurs inferieures ´ a ceux des leurres. ` Si nous arrivons a construire une telle fonction de score, nous pourrons l’utiliser ` a des fins pr ` edictives. C’est- ´ a-dire que seules les candidats (ou exemples) ayant les ` valeurs les plus faibles pour ce score seront retenus. Du point de vue de l’apprentissage, cela implique qu’il existe une correlation entre ´ la probabilite d’ ´ etre un candidat presque-natif et la valeur du score. Nous pouvons ˆ donc estimer la probabilite conditionnelle ´ P(Pr esque −natif|E(X)) et de maniere plus ` gen´ erale ´ P(Pr esque − natif|X). Dans notre cadre de travail, nous disposons de deux classes : presque-natif et leurre. Nous noterons 1 la classe presque-natif et 0 la classe leurre. 25Chapitre 2. Approche Rosetta et adaptation Notre objectif se reformule donc comme l’estimation de la probabilite condition- ´ nelle : P(y = 1|X). Compte tenu du cadre impose par RosettaDock, nous cherchons ´ a estimer ` P(y = 1|X) ∼ E(X) = P|A| i=1 wixi . Nous devons donc determiner les poids ´ wi tels que E(X) represente bien la probabilit ´ e pour ´ X d’etre un presque-natif. Pour ˆ etre tout ˆ a fait ` rigoureux, sachant que E(X) represente (d’un point de vue biologique) l’ ´ energie du ´ candidat X, plus cette energie est faible alors plus la probabilit ´ e que le candidat ´ X soit un presque-natif est elev ´ ee. ´ Nous cherchons donc a d ` eterminer les poids ´ wi tels que P(y = 1|X) = 1 − E(X) = 1 − P|A| i=1 wixi aient une valeur maximale pour X presque-natif. Plusieurs approches peuvent etre mises en œuvre pour estimer les poids ˆ wi . Nous presentons dans les sous-sections 2.3.1 et 2.3.2 deux approches permettant ´ de determiner ces poids. ´ 2.3.1 Estimation des poids par regression logistique ´ Nous allons montrer dans cette section le bien fonde de la mod ´ elisation de ´ P(y = 1|X) par une combinaison lineaire des attributs de ´ X Sachant que notre objectif est de pouvoir identifier les presques-natifs, nous pouvons redefinir notre objectif principal : ´ estimer au mieux le ratio P(y = 1|X)/P(y = 0|X). Si le ratio est superieur ou ´ egal ´ a 1 alors le candidat sera pr ` edit comme ´ etant un ´ presque-natif, sinon, il sera predit comme ´ etant un leurre. ´ Par un simple jeu de re´ecriture des probabilit ´ es conditionnelles, nous pouvons re- ´ formuler le rapport P(y = 1|X)/P(y = 0|X) comme indique dans l’ ´ equation 2.11. ´ P(y = 1|X) P(y = 0|X) = P(y = 1) P(y = 0) ∗ P(X|y = 1) P(X|y = 0) (2.11) Classiquement la fraction P(y=1) P(y=0) est estimee´ a partir du rapport des contingences ob- ` servees sur le jeu d’apprentissage : ´ P(y=1) P(y=0) = nb(y=1) nb(y=0) ou` nb(y = 1) (resp. = 0) represente ´ le nombre de candidats presque-natifs (resp. leurres) dans le jeu d’apprentissage. L’estimation du rapport des probabilites conditionnelles exprim ´ e dans l’ ´ equation ´ 2.11 repose donc sur l’estimation du rapport defini dans l’ ´ equation 2.12. ´ P(X|y = 1) P(X|y = 0) (2.12) Pour estimer le rapport 2.12, la regression logistique pose l’hypoth ´ ese fondamen- ` tale que le logarithme nep´ erien du rapport des probabilit ´ es conditionnelles peut s’ex- ´ primer comme une combinaison lineaire des attributs d ´ ecrivant ´ X (voir equation 2.13). ´ ln  P(X|y = 1) P(X|y = 0) = a0 + X |A| i=1 aixi (2.13) Sachant que nous cherchons a estimer la probabilit ` e d’un candidat d’ ´ etre un presque- ˆ natif, nous devons estimer P(y = 1|X). 262.3. Optimisation de la fonction de score Nous pouvons obtenir une estimation de P(y = 1|X) grace ˆ a l’ ` equation 2.14 avec ´ w0 = ln P(y=1) P(y=0) + a0 et wi = ai . LOGIT(P(y = 1|E)) = ln P(y = 1|X) 1 − P(y = 1|X) = w0 + X |A| i=1 wiEi (2.14) L’estimation de P(y = 1|X) est fournie par l’equation 2.15. ´ P(y = 1|X) = e w0+ P|A| i=1 wi xi 1 − e w0+ P|A| i=1 wi xi (2.15) Rappelons que notre objectif est de determiner les poids ´ wi permettant d’estimer au mieux P(y = 1|X). Plusieurs methodes peuvent ´ etre utilis ˆ ees pour d ´ eterminer ces ´ poids. Classiquement en regression logistique, ces poids sont estim ´ es par maximum ´ de vraisemblance a partir d’un ` echantillon de donn ´ ees consid ´ er´ e comme repr ´ esentatif. ´ Nous ne detaillerons pas les calculs n ´ ecessaires pour l’estimation par maximum ´ de vraisemblance. Le lecteur interess ´ e par le maximum de vraisemblance appliqu ´ e au ´ raffinement de structures 3D pourra se ref´ erer ´ a [184]. ` D’autres approches peuvent etre utilis ˆ ees pour estimer les valeurs des poids, par ´ exemple des approches d’optimisation stochastiques telles que les algorithmes de type evolutionnaire. ´ 2.3.2 Algorithmes evolutionnaires ´ Les algorithmes evolutionnaires appartiennent ´ a la famille des m ` ethodes d’optimi- ´ sation stochastiques. Ces algorithmes permettent d’obtenir une solution approchee´ a` un probleme. ` Dans notre cadre de travail, notre objectif est de pouvoir determiner, ´ a partir d’un ` ensemble d’attributs associes´ a un candidat, si celui-ci est un presque-natif ou non. Si ` nous nous replac¸ons dans le cadre de RosettaDock, nous cherchons a d ` eterminer les ´ poids wi tels que E(X) = P|A| i=1 wixi soit minimal si X est un presque-natif. Pour determiner les poids ´ wi , nous avons vu que nous pouvons estimer ces poids par maximum de vraisemblance, mais nous pouvons aussi determiner ces poids par ´ rapport a une fonction objectif et un jeu de donn ` ees ´ etiquet ´ ees. Et comme indiqu ´ e´ prec´ edemment, notre objectif est de d ´ eterminer les poids ´ wi tels que les presque-natifs obtiennent des valeurs faibles pour E et les leurres des valeurs elev ´ ees. ´ Nous avons choisi de mettre en œuvre l’approche ROGER (ROC-based Evolutionary learneR) [228]. Il s’agit d’une implementation en C d’un algorithme g ´ en´ etique cher- ´ chant a optimiser un vecteur de valeurs selon une fonction objectif. R ` OGER a pour fonction objectif l’aire sous la courbe Receiver Operating Characteristic (ROC-AUC), a` maximiser. En pratique, ROGER minimise la somme des rangs des exemples positifs, qui est un equivalent de la maximisation de l’aire sous la courbe ROC. ´ Le principe de ROGER (principe gen´ eral des algorithmes ´ evolutionnaires) est illustr ´ e´ dans la figure 2.7. 27Chapitre 2. Approche Rosetta et adaptation Le principe consiste a manipuler des individus g ` en´ etiques qui vont ´ evoluer dans ´ l’espace de recherche au moyen de mutations et de croisements de leur patrimoine gen´ etique. ´ Plusieurs espaces de recherche peuvent etre d ˆ efinis. Dans notre cadre de travail, ´ l’espace de recherche est R |A| car les |A| attributs caracterisant un candidat sont ´ a` valeur reelle. ´ Un individu gen´ etique est d ´ efini comme l’ensemble des ´ |A| poids wi que nous cherchons a d ` efinir. ´ Etant donn ´ e un individu g ´ en´ etique, tous les candidats du jeu d’appren- ´ tissage sont evalu ´ es et le score obtenu pour chaque individu permet d’ordonner tous ´ les candidats par valeur croissante de ce score (E tel que defini dans l’ ´ equation 2.10). ´ La qualite d’un individu g ´ en´ etique ´ f est evalu ´ ee´ a partir de ce tri. Cette qualit ` e se ´ definit simplement par la somme des rangs des exemples presque-natifs. ´ Le principe gen´ eral de R ´ OGER comporte globalement les cinq etapes suivantes ´ (voir fig. 2.7) : 1. gen´ eration al ´ eatoire de la population initiale des individus g ´ en´ etiques ( ´ µ parents), puis evaluation de cette population ; ´ 2. verification de la qualit ´ e de la population. Fin de l’algorithme si au moins l’un des ´ criteres d’arr ` et est atteint ; ˆ 3. evolution de cette population pour obtenir un ensemble d’enfants de cardinalit ´ e´ λ ; La gen´ eration de ces ´ λ enfants est realis ´ ee par mutation et croisement ´ a partir ` des µ parents de la population courante ; 4. evaluation de l’ensemble des ´ λ nouveaux enfants ; 5. selection de la nouvelle population, ne conservant que les ´ µ meilleurs individus gen´ etiques ´ a partir de l’ensemble des individus de la population courante, ` i.e. les µ parents + λ enfants. Nous avons teste diff ´ erents couples de valeurs pour ´ µ et λ. Compte tenu des performances obtenues et des temps de calculs, le meilleur couple de valeurs est (µ, λ) = (10, 80). Nous avons defini trois crit ´ eres d’arr ` et pour l’algorithme : ˆ – le nombre maximum d’iterations est atteint (100 000 it ´ erations) ; ´ – le nombre maximum d’iterations sans am ´ elioration de la fonction objectif est at- ´ teint (20 000 iterations) ; ´ – l’optimum de la fonction objectif est atteint, c’est-a-dire que l’aire sous la courbe ` ROC est egale ´ a 1. ` ROGER peut apprendre differents types de fonctions parmis lesquels nous retrou- ´ vons des fonctions lineaires, polynomiales, logistiques, ´ etc. 2.3.3 Methodologie d’optimisation de la fonction de score atom- ´ ique La methodologie g ´ en´ erale d’optimisation de la fonction de score atomique de Roset- ´ taDock peut se decomposer en 3 parties : ´ 282.3. Optimisation de la fonction de score Initialisation Enfants (λ vecteurs) Mutations et brassages Fonction objectif Évaluation Critère d'arrêt (AUC, itérations... ) Parents (μ vecteurs) Remplacement Meilleurs parmi μ + λ Évaluation FIGURE 2.7 – Illustration de l’algorithme gen´ eral de R ´ OGER. Les parents et enfants que ROGER manipule sont des vecteurs de valeurs. En encadres verts se trouvent ´ les vecteurs. Les etapes du processus sont encadr ´ ees en bleu et l’entr ´ ee et la sortie ´ sont en encadres noirs. R ´ OGER commence par choisir au hasard µ parents et les evaluer. Puis, il g ´ en´ ere ` λ enfants par mutation et recombinaison a partir des ` µ parents. ROGER evalue et s ´ electionne ensuite selon la fonction objectif les ´ µ meilleurs vecteurs parmi les µ parents et λ enfants. Ces µ meilleurs vecteurs deviennent les µ parents de l’iteration suivante, jusqu’ ´ a atteindre un crit ` ere d’arr ` et. ˆ – la constitution des jeux de donnees, d ´ ej ´ a pr ` esent ´ ee au chapitre 1 ; ´ – l’apprentissage de la fonction de score sur l’ensemble des 120 complexes et l’apprentissage des 120 fonctions de score en leave-”one-pdb”-out, present ´ es´ prec´ edemment dans cette m ´ eme section ; ˆ – l’evaluation des 120 fonctions de score en ´ leave-”one-pdb”-out sur les candidats de leur jeu d’evaluation et celle de la fonction de score sur les 40 000 candidats ´ de l’ensemble de validation. Sur le diagramme 2.8, la premiere partie est d ` elimit ´ ee par les points ´ a, b et c. Ces points a, b et c correspondent respectivement a la g ` en´ eration des candidats ´ par perturbation, a leur ` etiquetage en presque-natifs, leurres et leurres du test et ´ a` l’echantillonnage sans remise des candidats des classes presque-natifs et leurres pour ´ constituer le jeu d’apprentissage. La seconde partie intervient aux points d et e dans la construction des fonctions de score, qu’il s’agisse des 120 fonctions de score apprises en leave-”one-pdb”-out – point d – ou de la fonction de score apprise sur l’ensemble des 120 complexes – point e. La derniere partie est repr ` esent ´ ee par le point ´ f, avec le calcul et l’observation des differentes mesures d’ ´ evaluation sur les exemples ´ de validation. 29Chapitre 2. Approche Rosetta et adaptation PRIDBnr 133 pdb Génération de candidats par perturbation 10 000 structures par pdb Filtre : pdb avec seulement 2 partenaires en interaction 133 pdb oui 120 * 10 000 candidats 3 600 presque-natifs 3 600 leurres 120 pdb 354 344 leurres a b c Sépare les candidats Irmsd(presque-natifs) ≤ 5 Å Irmsd(leurres) > 8 Å leurres de test sinon Jeu d'apprent. 7 200 candidats Pour tout pdb : #cand.(Irmsd ≤ 5 Å) ≥ 30 et #cand.(Irmsd > 8 Å) ≥ 30 ? non 590 707 presquenatifs 120 * 10 000 candidats 254 949 leurres de test Échantillonnage sans remise : candidats avec #presque-natifs=#leurres=30 Ensemble d'apprent. 1 200 000 candidats Apprentissage + évaluation Leave-"one-pdb"-out Critères globaux Inspection visuelle Courbe ROC + ROC-AUC #presque-natifs(top10) #cand.(sous énergie native) Score d'enrichment d Apprentissage 1 fonction de score ROGER Logistique e Modèle de fonction de score 1 modèle f 120 modèles FIGURE 2.8 – Illustration de la methodologie d’optimisation de la fonction de score ´ atomique. 2.4 Evaluation de la fonction de score optimis ´ ee´ Le modele utilis ` e pour l’apprentissage et pr ´ esent ´ e pr ´ ec´ edemment peut faire l’objet ´ de variantes pour ameliorer le pouvoir pr ´ edictif tel qu’il est refl ´ et´ e par les diff ´ erentes ´ mesures d’evaluation. ´ Les choix sur les variantes dependent des connaissances ´ a priori sur le contexte de la prediction prot ´ eine-ARN. D’une part, nous choisissons de tester les m ´ ethodologies ´ mises en œuvre dans la prediction d’interactions prot ´ eine-prot ´ eine. D’autre part, nous ´ prenons en compte les caracteristiques propres des ARN par rapport aux prot ´ eines, ´ notamment sa plus grande flexibilite. Parmi ces choix, nous pouvons identifier : ´ – la definition de l’intervalle de valeurs des poids des termes de score ; ´ – le filtrage a priori des candidats pour chaque complexe ; – la categorisation des complexes en fonction de crit ´ eres sur leurs partenaires ` 302.4. Evaluation de la fonction de score optimis ´ ee´ combinee´ a la mod ` elisation d’une fonction de score par cat ´ egorie de complexes. ´ 2.4.1 Pouvoir predictif en fonction des contraintes ´ L’intervalle de valeurs dans lequel les poids des termes de score sont recherches´ influence les performances de la fonction de score obtenue pour maximiser la fonction objectif. Une contrainte imposee sur cet intervalle de valeurs permet de simplifier la ´ recherche du maximum global en diminuant la taille de l’espace de recherche. Mais contraindre l’intervalle de valeurs des poids peut aussi empecher de trouver les poids ˆ permettant d’obtenir le maximum global. Il convient donc d’utiliser une contrainte astucieusement choisie pour eviter les minima locaux tout en conservant dans l’intervalle ´ de valeurs les poids permettant d’obtenir le maximum global. Quelles que soient les contraintes appliquees ´ a l’apprentissage dans R ` OGER, les fonctions de score optimisees pour l’amarrage prot ´ eine-ARN surpassent les perfor- ´ mances de la fonction de score optimisee pour l’amarrage prot ´ eine-prot ´ eine qui est, ´ rappelons-le, la fonction par defaut de RosettaDock (voir tableau 2.3). La fonction de ´ score optimisee pour l’amarrage prot ´ eine-prot ´ eine a une AUC moyenne inf ´ erieure ´ a 0.4 ` et n’a que la moitie des complexes avec un nombre de presque-natifs non nul parmi le ´ top10 des candidats tries en ´ energie. De plus, seuls 15 des complexes ont une AUC ´ superieure ´ a 0.5. ` La contrainte a poids positifs, issue de la connaissance experte de l’amarrage ` proteine-prot ´ eine, donne de meilleurs r ´ esultats que la contrainte ´ a poids n ` egatifs ou ´ meme que l’absence de contrainte [101]. Les fonctions de score ˆ a poids positifs ont ` une ROC-AUC moyenne superieure de plus de 0.1 ´ a la ROC-AUC moyenne des autres ` fonctions de score. De plus, les fonctions de score a poids positifs ont une dizaine ` de complexes de plus avec une ROC-AUC superieure ´ a 0.5 et avec un nombre de ` presque-natifs non nul dans le top10 des candidats tries en ´ energie. ´ La contrainte a poids n ` egatifs donne des r ´ esultats quasi-identiques ´ a l’absence ` de contrainte. Ces deux manieres d’apprendre les fonctions de score donnent une ` ROC-AUC moyenne de 0.64, 105 complexes avec une ROC-AUC superieure ´ a 0.5 et ` 109 complexes avec au moins 1 presque-natif dans le top10 des candidats tries en ´ energie. En l’absence de contrainte, les poids sont pi ´ eg´ es dans des minima locaux. Ce ´ sont justement ces minima locaux qui sont evit ´ es en appliquant la contrainte des poids ´ positifs. Etant donn ´ ee la similarit ´ e de r ´ esultats entre la contrainte n ´ egative et l’absence ´ de contrainte, la question est de savoir si les poids sont aussi similaires. Il se trouve que les minima locaux des fonctions de score sans contrainte appliquee´ sur leurs poids sont pour certains negatifs ou nuls (voir fig. 2.9). Les poids en question ´ des fonctions de score sans contrainte sont donc effectivement pieg´ es dans l’intervalle ´ de valeurs negatif. ´ Les poids finalement acceptes ont surtout des valeurs non nulles pour quatre ter- ´ mes de score (voir fig. 2.10). Parmi ces quatre termes de score, trois d’entre eux correspondent a des types de liaisons hydrog ` ene et ont une valeur proche de 1 pour quasi- ` ment tous les complexes. Ceci montre a quel point la formation des liaisons hydrog ` ene ` dans une interaction proteine-ARN est importante dans les structures biologiquement ´ 31Chapitre 2. Approche Rosetta et adaptation Classifieur ROC-AUC ROC-AUC > 0.5 #(top10E(Candidats))> 0 ROS 0.363±0.016 15 61 NEG 0.640±0.016 105 109 ALL 0.643±0.016 105 109 POS 0.798±0.018 119 117 TABLE 2.3 – Pour chaque intervalle de valeurs utilise comme contrainte d’apprentis- ´ sage des poids par ROGER lineaire sont indiqu ´ es : la moyenne et la variance de la ´ ROC-AUC, le nombre de complexes pour lesquels la ROC-AUC est superieure ´ a 0.5 et ` le nombre de complexes avec un #presque-natifs (top10E(Candidats)) non nul. ROGER lineaire positif (POS) a pour contrainte l’intervalle de valeurs positif [0 ; 1], R ´ OGER lineaire (ALL) l’intervalle de valeurs sans contrainte [ ´ −1 ; 1] et ROGER lineaire n ´ egatif ´ (NEG) l’intervalle de valeurs negatif [ ´ −1 ; 0]. La fonction de score par defaut est celle ´ implement ´ ee dans RosettaDock et optimis ´ ee pour l’amarrage prot ´ eine-prot ´ eine. ´ actives. Le seul type de liaison hydrogene qui n’est pas privil ` egi ´ e correspond aux li- ´ aisons hydrogene entre les atomes de la cha ` ˆıne laterale de l’un des partenaires et les ´ atomes du squelette de l’autre partenaire. Le dernier terme de score a une valeur qui avoisine les 0.2 et correspond a l’affinit ` e entre paires d’atomes. ´ 2.4.2 Fonction de score dedi ´ ee pour chaque type d’ARN ´ Une des hypotheses de travail est de consid ` erer que l’interaction entre la prot ´ eine et ´ l’ARN depend de la forme des partenaires. Dans cette optique, nous avons cat ´ egoris ´ e´ les complexes en trois types, en fonction de la forme gen´ erale de l’ARN : simple brin ´ (ss), double brin (ds) et ARN de transfert mature (tRNA). Puis, nous avons modelis ´ e´ une fonction de score pour chaque categorie de complexes. Pour chaque fonction ´ de score ainsi modelis ´ ee, nous avons proc ´ ed´ e, en amont de l’apprentissage et de ´ l’evaluation, ´ a un filtre des complexes pour ne garder que les complexes de la cat ` egorie ´ correspondant a la fonction. ` Les resultats de l’ ´ evaluation indiquent que les complexes mettant en jeu un tRNA ´ mature sont un peu mieux modelis ´ es avec une fonction de score d ´ edi ´ ee (voir tableau ´ 2.4). Les deux autres fonctions de score dedi ´ ees ne montrent pas d’am ´ elioration par ´ rapport a la fonction de score R ` OGER a poids positifs. ` 2.4.3 Combinaison lineaire ´ a poids positifs ` Apres apprentissage de la fonction de score ` a combinaison lin ` eaire par R ´ OGER avec des coefficients des termes de score contraints aux valeurs dans [0 ; 1], la fonction de score est evalu ´ ee. Pour chaque mesure d’ ´ evaluation, nous allons ´ evaluer les ´ 120 fonctions de score gen´ er´ ees par ´ leave-”one-pdb”-out et la fonction de score globale sur le jeu de donnees issu des ´ Benchmarks I et II. 322.4. Evaluation de la fonction de score optimis ´ ee´ ● ● ● ● ● ● ●● ● ● ● ● ● ● −1.0 −0.5 0.0 0.5 1.0 Poids ● ●● ● ● ● ● ●● ● ● ● ● ●●● ● ●● ● ● ●● ● ● ● ● ● ● ● ●● ● ●● ● ● ● ● ● ● ● ● ●● ● −1.0 −0.5 0.0 0.5 1.0 fa_atr fa_rep fa_dun fa_sol fa_pair hbond_lr_bb hbond_sr_bb hbond_bb_sc hbond_sc hack_elec FIGURE 2.9 – Repartition de la valeur des coefficients par poids et contrainte d’inter- ´ valle de valeurs, pour les 120 fonctions de score gen´ er´ ees par le ´ leave-”one-pdb”-out mis en œuvre sur la PRIDB. Les points en losange jaune correspondent aux valeurs des coefficients des poids de la fonction de score par defaut de RosettaDock, ROS. ´ Les boˆıtes a moustache repr ` esentent les valeurs des coefficients des termes de score ´ pour un intervalle de definition n ´ egatif (en bleu) ou sans contrainte (en noir). ´ 2.4.3.1 Pouvoir predictif de la fonction de score ´ La ROC-AUC est superieure ´ a 0.7 pour 89 des 120 complexes, montrant un pouvoir ` predictif important (voir tableau S12). Globalement, les presque-natifs sont donc bien ´ separ ´ es des leurres. La ROC-AUC est en moyenne de 0.8 et sa variance de 0.02. ´ Lges courbes ROC ont une pente a l’origine ` elev ´ ee, comme on peut le voir pour les ´ 33Chapitre 2. Approche Rosetta et adaptation FIGURE 2.10 – Repartition de la valeur des coefficients par poids, pour les 120 fonc- ´ tions de score gen´ er´ ees par le ´ leave-”one-pdb”-out mis en œuvre sur la PRIDB. Les points en losange correspondent aux valeurs des coefficients des poids de la fonction de score par defaut de RosettaDock, ROS. ´ complexes etant ´ a la m ` ediane, au premier quartile et au troisi ´ eme quartile en ROC- ` AUC (voir fig. 2.11). Sur l’ensemble des complexes, seuls 8 des 120 ont une pente a` l’origine insatisfaisante (voir fig. 2.12). Dans le jeu de donnees issu des ´ Benchmarks I et II, les resultats des fonctions de ´ score ROGER sont similaires a ceux pour le jeu de donn ` ees de perturbations issu de ´ la PRIDB (voir fig 2.11). 342.4. Evaluation de la fonction de score optimis ´ ee´ Categorie ´ Mediane(ROC-AUC) ´ ROC-AUC > 0.7 ROC-AUC > 0.6 Complexes POS 0.82 0.73 0.88 120 POS ds 0.81 0.69 0.87 55 POS ss 0.80 0.76 0.88 33 POS tRNA 0.87 0.84 0.97 32 TABLE 2.4 – Evaluation du mod ´ ele de pr ` ediction d ´ edi ´ e par cat ´ egorie de complexes. Les ´ categories double brin (POS ds), simple brin (POS ss) et ARN de transfert (POS tRNA) ´ sont comparees ´ a la fonction de score sans cat ` egorisation des complexes (POS). La ´ mediane de la ROC-AUC, et la proportion des complexes v ´ erifiant une condition sur la ´ ROC-AUC parmi les complexes de la categorie sont compar ´ ees. La derni ´ ere colonne ` correspond au nombre de complexes dans la categorie. On peut remarquer que la ´ fonction de score dedi ´ ee aux complexes avec un ARNt mature donne de meilleures ´ performances que la fonction de score traitant indifferemment les complexes. Les deux ´ autres fonctions de score dedi ´ ees donnent des r ´ esultats similaires ´ a la fonction de ` score non dedi ´ ee. ´ 2.4.3.2 Enrichissement du tri des candidats Le score d’enrichissement defini au chapitre 1 montre un enrichissement du tri pour ´ 27 des 120 complexes : ces 27 complexes ont un score d’enrichissement superieur ´ a 6. Sur les 120 complexes, 6 complexes ont un enrichissement inf ` erieur ´ a 1. ` A la ` lumiere de ces r ` esultats, il faut rappeler que la fonction de score apprend ´ a s ` eparer ´ deux classes - presque-natifs et leurres - qui sont distinguees l’une de l’autre par un ´ seuil fixe de 5A en I ˚ RMSD. Or, le score d’enrichissement considere les 10 % premiers ` candidats en IRMSD comme des presque-natifs et regarde parmi eux la proportion des 10 % premiers candidats en energie. Dans un ensemble de candidats g ´ en´ er´ es par ´ faible perturbation, il arrive frequemment qu’un seuil d ´ efini ´ a 10 % des candidats en ` IRMSD soit tres inf ` erieur ´ a 5 ` A (de l’ordre de 1 ˚ a 2 ` A). De mani ˚ ere g ` en´ erale, le score ´ d’enrichissement est donc d’autant moins bon que le seuil a 10 % des candidats en ` IRMSD s’ecarte de 5 ´ A. Le r ˚ esultat obtenu est plus coh ´ erent avec les autres mesures ´ d’evaluation pour un score d’enrichissement ´ a` X % ou` X est la proportion de candidats necessaires pour avoir un seuil en I ´ RMSD de 5A. Pour R ˚ OGER, le score d’enrichissement ainsi calcule est sup ´ erieur ´ a 6 pour 94 des 120 complexes, contre seulement ` 42 complexes pour ROS. Et aucun complexe n’a un score inferieur ´ a 2 pour le score ` ROGER, contre 41 complexes pour ROS. 2.4.3.3 Detection d’entonnoir ´ Les courbes d’EvsIrms permettent de detecter un entonnoir pour 94 des 120 com- ´ plexes (voir fig. S1). Ceci suggere que la fonction de score est utilisable en amarrage ` atomique pour affiner une structure 3D dont on a detect ´ e l’ ´ epitope. ´ On pourrait penser que la separation des candidats en presque-natifs et leurres ´ selon un seuil fixe a un impact sur la signification de la prediction. Si la fonction de ´ 35Chapitre 2. Approche Rosetta et adaptation FIGURE 2.11 – Courbes ROC pour trois complexes de la PRIDB avec la fonction de score POS (a) et ROS (b), avec les courbes ROC pour trois complexes du Benchmark I (c) et du Benchmark II (d). Les trois complexes utilises´ a chaque fois sont choisis ` parce qu’ils sont les plus proches de la mediane (en trait plein), le 1 ´ er quartile et le 3e quartile (en pointilles) en ROC-AUC. La ROC-AUC de la m ´ ediane est ´ a chaque fois ` indiquee. ´ score apprend correctement a s ` eparer les classes, les candidats pr ´ edits presque-natifs ´ ont une forte chance d’avoir un IRMSD ≤ 5A. Mais la pr ˚ ediction pourrait ne pas don- ´ ner d’information plus forte sur la divergence entre le presque-natif et la structure native. Pourtant, on constate avec la detection d’entonnoir que les caract ´ eristiques de ´ l’interaction ont correctement et ´ e mod ´ elis ´ ees par la fonction de score pour approxima- ´ tivement 100 des 120 complexes. En effet, les candidats de meilleure energie tendent ´ 362.4. Evaluation de la fonction de score optimis ´ ee´ 0.0 0.2 0.4 0.6 0.8 1.0 0.0 0.2 0.4 0.6 0.8 1.0 Irmsd Score FIGURE 2.12 – Courbes ROC pour 8 complexes de la PRIDB avec la fonction de score POS. Ces 8 complexes ont et ´ e choisis pour la faible valeur de leur pente ´ a l’origine. ` aussi a` etre ceux qui ont le meilleur I ˆ RMSD et non n’importe quel IRMSD entre 0 et 5A. Cette information a ˚ et ´ e retrouv ´ ee par le mod ´ ele de fonction de score alors qu’elle ` n’etait pas fournie en entr ´ ee de l’apprentissage. ´ Il reste neanmoins des cas o ´ u un entonnoir n’est tout simplement pas d ` etect ´ e.´ Pour ces complexes pour lesquels l’interaction n’est pas capturee, une structure 3D ´ alternative est quelque fois proposee par la fonction de score, d’ ´ energie plus ´ elev ´ ee´ que l’interaction recherchee. Il s’agit ici de 1jbs et 1t0k, pour lesquels plusieurs leurres ´ de meme I ˆ RMSD sont proposes par la fonction de score. ´ Mais il y a aussi des cas ou la fonction de score privil ` egie de fac¸on consistante des ´ structures plus eloign ´ ees de la native, sans pour autant qu’il s’agisse de leurres. C’est ´ 37Chapitre 2. Approche Rosetta et adaptation 1jbs (ES = 0.79) Irmsd (Å) Score 0 20 −22 −12 0 20 1t0k (ES = 1.34) Irmsd (Å) Score 0 20 21 34 0 20 FIGURE 2.13 – Diagrammes d’energie en fonction du I ´ RMSD pour deux complexes de la PRIDB avec la fonction POS. On constate que la fonction de score propose une interaction differente de celle de la structure native, alors qu’elle d ´ etecte tr ´ es bien un ` entonnoir pour 94 des 120 complexes. notamment le cas pour 1feu, 1j1u ou 1pgl, ainsi que, dans une moindre mesure, pour 1asy, 1av6 ou 1b23. Pour certains de ces complexes, les candidats mis en avant par la prediction ´ evitent davantage l’interp ´ en´ etration des partenaires que la structure native. ´ Pour d’autres, un entonnoir est meme visible en plus du premier entonnoir et laisse ˆ suspecter une potentielle interaction de plus haute energie. Les complexes 2bx2, 2d6f ´ et, surtout, 3egz montrent en effet qu’une seconde interaction est compatible avec le modele de fonction de score (voir fig. 2.14). ` 2bx2 (ES = 2.08) Irmsd (Å) Score 0 20 2 12 0 20 2d6f (ES = 2.75) Irmsd (Å) Score 0 20 6 17 0 20 3egz (ES = 3.05) Irmsd (Å) Score 0 20 −17 −6 0 20 FIGURE 2.14 – Diagrammes d’energie en fonction du I ´ RMSD pour trois complexes de la PRIDB avec la fonction POS. On constate que la fonction de score propose, en plus de presque-natifs proches de la structure native, une interaction alternative a celle de ` la structure native. 2.4.3.4 Repartition des coefficients des termes de score ´ Les coefficients des termes de score nous permettent de mieux comprendre les forces en jeu influenc¸ant le plus les interactions entre proteines et ARN. On peut re- ´ marquer plusieurs types de comportements parmi tous les complexes. Notamment, le 382.4. Evaluation de la fonction de score optimis ´ ee´ comportement le plus remarque est celui o ´ u les termes de score hbond, repr ` esentant ´ la stabilite provenant des liaisons hydrog ´ ene, ont des coefficients ` elev ´ es. Mais sur ´ les quatre types de termes de score hbond, seuls trois d’entre eux ont des valeurs elev ´ ees : le coefficient reste tr ´ es faible pour le score hbond ` bb sc, qui represente les ´ liaisons hydrogene entre le squelette d’un partenaire et les cha ` ˆınes laterales de l’autre ´ partenaire. Ceci indique que les complexes proteine-ARN ont tendance ´ a former des ` liaisons entre les atomes de leurs squelettes a courte et moyenne port ` ee, mais aussi ´ entre les atomes des chaˆınes laterales. ´ Code PDB fa atr fa rep fa dun fa sol fa pair 1h3e 0.000496 0.000793 0.000009 0.000944 0.22261 1j2b 0.000653 0.000337 0.000023 0.000474 0.175237 3ex7 0.00058 0.000314 0.000009 0.000511 0.166342 Code PDB hbond lr bb hbond sr bb hbond bb sc hbond sc hack elec 1h3e 0.999557 0.999906 0.000132 0.999968 0.000726 1j2b 0.999245 0.999941 0.000627 0.99933 0.000559 3ex7 0.999739 0.999963 0.000301 0.999195 0.000479 TABLE 2.5 – Trois exemples types de coefficients des termes de score hbond elev ´ es. ´ Les valeurs des coefficients tournent toujours autour de valeurs tres faibles ( ` < 10−3 ) ou tres hautes ( ` > 1−10−3 ). Le seul terme de score faisant exception a la r ` egle est le terme ` de score fa pair, modelisant l’affinit ´ e entre atomes en fonction de leur environnement. ´ 2.4.4 Filtrage a priori des candidats du modele atomique ` Avec le filtrage a priori des candidats pour chaque complexe, le modele rejette ` d’emblee de la pr ´ ediction une partie des candidats, principalement pour deux raisons. ´ D’une part, les candidats peuvent etre rejet ˆ es parce qu’ils sont des leurres ´ evidents. ´ D’autre part, pour certains candidats, il peut etre trop difficile de discriminer entre ˆ presque-natif et leurre. Il devient alors acceptable de rejeter ces candidats si la proportion de presque-natifs parmi eux est suffisamment faible et si les retirer du jeu d’apprentissage permet d’ameliorer la pr ´ ediction. ´ Nous avons proced´ e´ a un filtre en fonction du score donn ` e par le terme de score ´ fa rep, qui donne une quantification du chevauchement entre les deux partenaires. Nous ne conservons que les candidats en-dessous de la mediane du terme de score ´ de fa rep, ce qui signifie que nous choisissons systematiquement de ne conserver que ´ les 5 000 meilleurs candidats en fa rep. En realit ´ e, il ne s’agit pas exactement des 5 000 ´ meilleurs candidats en fa rep. Le nombre exact de candidats retenu peut etre sup ˆ erieur ´ a 5 000, puisque la valeur en fa ` rep peut etre identique entre candidats autour du seuil ˆ des 5 000 meilleurs candidats en fa rep. Sur les 120 complexes de la PRIDB, 54 n’ont que des complexes presque-natifs apres utilisation du filtre. Ceci montre l’importance du terme de score fa ` rep dans la 39Chapitre 2. Approche Rosetta et adaptation determination des structures repr ´ esentant le mieux l’interaction, mais aussi que ce ´ terme de score ne suffit pas a pr ` edire l’interaction. ´ Sur les 66 complexes restants, qui disposent encore de leurres, on constate une diminution drastique des performances en ROC-AUC. Sur ces complexes, 28 ont une diminution de plus de 0.05 du ROC-AUC pour POS. Le filtre a permis d’ecarter des ´ candidats qui etaient des leurres tr ´ es faciles ` a discerner des presque-natifs pour les ` fonctions de score employees. ´ Cependant, nous observons aussi une augmentation du nombre de presque-natifs dans le top10. Les 3 complexes pour lesquels il est le plus difficile pour POS de predire ´ des presque-natifs dans le top10 ont, apres filtre, tous au moins un presque-natif dans ` le top10 (voir tableau 2.6). De plus, le nombre de complexes pour lesquels il n’y a aucun presque-natif dans le top10 passe de 59 a 22 pour la fonction de score ROS. ` pdb Enrichissement Top10 Top100 Presque-natifs Seuil ROC-AUC ROS POS ROS POS ROS POS ROS POS 1jbs 0.38 0.40 0 1 35 32 2528 5003 0.49 0.55 1t0k 0.61 1.03 9 8 79 76 3725 5002 0.51 0.56 2anr 0.38 1.04 8 6 43 75 2927 5000 0.43 0.56 TABLE 2.6 – Les trois complexes les plus difficiles a pr ` edire pour la fonction de score ´ POS ont tous au moins 1 candidat presque-natif dans le top10 apres utilisation du filtre ` de la mediane en fa ´ rep, alors qu’ils etaient les seuls ´ a avoir un nombre de presque- ` natif dans le top10 a 0 sans usage du filtre. Pourtant, le ROC-AUC reste faible (0.55 ` environ). Nous pourrions etre tent ˆ es de conserver le filtrage par la m ´ ediane en fa ´ rep dans la suite de ces travaux. En effet, ce filtre a priori permet d’ameliorer les r ´ esultats quant ´ a l’objectif fix ` e de maximiser le nombre de presque-natifs dans le top10. Cependant, ´ il faut se rappeler que les candidats rejetes par ce filtre ´ a priori sont rejetes parce ´ qu’ils presentent une interp ´ en´ etration trop importante. Or, de tels candidats ne sont ´ pas attendus apres une g ` en´ eration de candidats ayant incorpor ´ e l’utilisation d’un filtre ´ adapte pour rejeter les candidats pr ´ esentant des caract ´ eristiques trop ´ eloign ´ ees des ´ attentes biologiques (interpen´ etration trop importante, distance trop importante entre ´ les atomes des partenaires, etc.). Il est ainsi conseille d’employer le filtrage par la m ´ ediane en fa ´ rep en l’absence de tout autre filtre ou de tout amarrage pouvant garantir que les candidats gen´ er´ es ne ´ presentent pas d’interp ´ en´ etration n’ayant aucun sens biologique. Mais l’objectif dans ´ les chapitres suivants est justement d’arriver a un protocole de pr ` ediction d’interactions ´ proteine-ARN o ´ u les candidats soumis ` a la pr ` ediction atomique ont un sens biologique. ´ 402.5. Conclusions sur la fonction de score atomique 2.5 Conclusions sur la fonction de score atomique Nous avons pu voir dans ce chapitre la fonction de score atomique implement ´ ee´ par defaut dans RosettaDock, ROS. Vu que ROS n’est pas optimis ´ e pour la pr ´ ediction ´ d’interactions proteine-ARN, ses performances ne permettent pas la pr ´ ediction d’in- ´ teractions entre proteine et ARN, encore moins le raffinement de structures 3D. Nous ´ avons constate que les mesures d’ ´ evaluation globales ne permettent pas d’obtenir d’in- ´ formations sur l’objectif fixe, qui est de maximiser le nombre de presque-natifs dans ´ le top10 des candidats. Dans cette optique, les mesures d’evaluation locales se sont ´ aver´ ees plus utiles. L’optimisation de la fonction de score atomique, en conservant ´ les contraintes de RosettaDock, a permis d’obtenir des performances bien meilleures. Ce gain de performance a et ´ e conditionn ´ e´ a un apprentissage contraint ` a l’intervalle ` de definition positif, [0 ; 1], raison pour laquelle la fonction de score apprise s’appelle ´ POS. Nous avons confronte POS ´ a deux autres fonctions de score, ALL et NEG, re- ` spectivement sur l’intervalle de definition [ ´ −1 ; 1] pour ALL et [−1 ; 0] pour NEG. Cette confrontation a permis de montrer l’efficacite de POS, dont l’intervalle de d ´ efinition ´ est tire de la connaissance ´ a priori de l’amarrage proteine-prot ´ eine. Un filtre ´ a priori permet d’ameliorer la pr ´ ediction donn ´ ee par ROS, mais les r ´ esultats sont encore peu ´ stables, marquant des ecarts de performance importantes entre les diff ´ erents com- ´ plexes. Ce filtre consiste a ne conserver pour la pr ` ediction que les candidats dont la ´ valeur du terme de score fa rep est inferieure ´ a celle de la m ` ediane de fa ´ rep sur les 10 000 candidats gen´ er´ es. ´ Nous avons donc obtenu une fonction de score POS non seulement capable de predire l’interaction prot ´ eine-ARN, mais aussi d’ ´ etre efficace dans le raffinement de ˆ structures 3D proteine-ARN. Il reste maintenant ´ a concevoir une fonction de score ` s’affranchissant des contraintes de RosettaDock, pour esperer mieux mod ´ eliser encore ´ l’interaction. La finalite est d’obtenir un protocole d’amarrage de pr ´ ediction d’interaction ´ proteine-ARN multi- ´ echelle, ce qui implique la mod ´ elisation d’une fonction de score ´ a` une autre echelle. Cette fonction de score sur une autre ´ echelle peut servir de filtre ´ a priori pour diminuer les temps de calcul et ecarter les leurres les plus simples. C’est ´ pourquoi, dans un second temps, nous nous focaliserons sur une echelle gros-grain. ´ 41Chapitre 2. Approche Rosetta et adaptation 42Chapitre 3 Approche a posteriori Nous avons vu, dans le chapitre prec´ edent, l’approche classique mise en œuvre ´ dans RosettaDock pour la gen´ eration et l’ ´ evaluation de candidats. Le choix de Roset- ´ taDock impose de se restreindre a une fonction d’ ` evaluation qui est une combinaison ´ lineaire des attributs associ ´ es´ a chaque candidat. ` Comme nous le verrons par la suite, RosettaDock peut gen´ erer des candidats ´ presque-natifs qui, d’apres la fonction d’ ` evaluation utilis ´ ee, ne sont pas class ´ es parmi ´ les meilleurs candidats. Il n’est donc pas toujours possible, en utilisant seulement une fonction de type combinaison lineaire, de mettre en avant les meilleurs candi- ´ dats gen´ er´ es par RosettaDock. Nous nous sommes donc focalis ´ e sur d’autres familles ´ de fonctions afin de pouvoir ordonner plus efficacement les candidats gen´ er´ es par ´ RosettaDock. Sachant que ces fonctions ne pourront etre appliqu ˆ ees qu’en post- ´ traitement de RosettaDock, c’est-a-dire sans interaction directe avec RosettaDock, ` nous appelerons les approches mises en œuvre pour obtenir ces nouvelles fonctions de tri : modeles ` a posteriori. 3.1 Modeles ` a posteriori Les modeles de fonction de score ` a posteriori ne sont pas utilises directement par ´ RosettaDock et peuvent ainsi s’affranchir de la contrainte de la combinaison lineaire. ´ Les candidats sont initialement gen´ er´ es par RosettaDock puis tri ´ es par une fonction de ´ score appliquee en post traitement. Notons qu’un tri ´ a posteriori ne permet pas d’orienter la gen´ eration des candidats durant l’ ´ etape de g ´ en´ eration. Sachant qu’il est possible ´ de fournir a RosettaDock un ensemble de candidats ` a priori peu divergeant des solutions recherchees, nous pouvons parfaitement envisager de coupler des phases de ´ gen´ eration de candidats suivies de s ´ election des meilleurs candidats en appliquant les ´ fonctions de tri que nous presenterons par la suite. Les meilleurs candidats pourront ´ alors etre utilis ˆ es comme conformations initiales pour l’it ´ eration suivante de Rosetta- ´ Dock. De nombreuses approches peuvent etre mises en œuvre pour apprendre des fonc- ˆ tions de score a partir des attributs disponibles pour chaque candidat. Nous avons ` etudi ´ e diff ´ erentes approches reposant sur l’apprentissage de mod ´ eles : fonctions de ` 43Chapitre 3. Approche a posteriori score de type combinaison lineaire ´ etendue, arbres ou r ´ egles de d ` ecision, mod ´ ele` bayesien na ´ ¨ıf, etc. 3.1.1 Combinaison lineaire ´ La combinaison lineaire de termes physico-chimiques est la seule forme de fonc- ´ tion de score que RosettaDock peut nativement utiliser. L’equation 3.1 montre pour le ´ candidat X la combinaison lineaire ´ f(X) des attributs xi ou` wi representent les poids ´ qui doivent etre appris pour chaque attribut. ˆ f(X) = X |A| i=1 wixi (3.1) Cette modelisation peut ´ etre ˆ etendue en int ´ egrant la notion de ´ valeur de centrage associee´ a chaque attribut. ` Les valeurs de centrage doivent etre apprises pour chaque attribut. Ces valeurs ˆ vont permettre de determiner si la contribution au score de chaque attribut est lin ´ eaire ´ ou non. La nouvelle fonction de score obtenue, fc, est definie par l’ ´ equation 3.2, o ´ u` X represente le candidat, ´ xi la valeur du i e attribut, wi son poids et ci sa valeur de centrage. Ainsi, la prise en consideration des valeurs de centrage, permet d’obtenir, pour ´ chaque attribut, un comportement lineaire par partie : croissant (resp. d ´ ecroissant) ´ jusqu’a un seuil ` ci puis decroissante (resp. croissant) apr ´ es le seuil. Notons que la ` contribution de xi est nulle au point ci . fc(X) = X |A| i=1 wi |xi − ci | (3.2) A l’image des diff ` erents noyaux utilis ´ es pour les SVM, d’autres types de fonctions ´ peuvent etre prises en consid ˆ eration : polynomiales, quadratiques, gaussiennes, ´ etc. Notre principal objectif n’etant pas d’apprendre une fonction d’ordonnancement des ´ candidats, mais plutot de pouvoir identifier efficacement les candidats presque-natifs, ˆ nous nous sommes focalises sur des approches permettant d’apprendre des mod ´ eles ` predicitifs. ´ 3.1.2 Approches dites ”explicatives” : arbres et regles de d ` ecision ´ Les arbres et les regles de d ` ecision appartienent ´ a la famille des mod ` eles ”expli- ` catifs” ou ”comprehensibles”. En effet, lorsqu’un arbre de d ´ ecision est appris sur des ´ donnees, il est ais ´ e de proposer ´ a l’expert une repr ` esentation graphique des donn ´ ees. ´ L’expert peut alors tres facilement comprendre le mod ` ele obtenu et se l’approprier. ` L’une des limitations de ces approches (arbres ou regles de d ` ecision) est la taille de ´ l’arbre obtenu (ou la quantite de r ´ egles). ` 443.1. Modeles a posteriori ` Pour illustration, voici un exemple simple d’arbre de decision (voir fig. 3.1). Sur trois ´ attributs fa dun, fa pair et fa rep, 50 exemples fictifs sont utilises pour la pr ´ ediction : ´ 25 presque-natifs et 25 leurres. La valeur de chacun des attributs est dans l’intervalle [0 ; 1] pour les 50 exemples. Voici le resultat de l’apprentissage d’un arbre d ´ ecisionnel ´ sur ces 50 exemples fictifs : • fa dun≥ 0.43 • fa rep≤ 0.72 (presque-natifs) : 13 presque-natifs et 5 leurres • fa rep> 0.72 (leurres) : 16 leurres et 4 presque-natifs • fa dun< 0.43 • fa pair< 0.14 (presque-natifs) : 2 presque-natifs • fa pair≥ 0.14 • fa rep> 0.65 (leurres) : 3 leurres • fa rep≤ 0.65 (presque-natifs) : 6 presque-natifs et 1 leurre FIGURE 3.1 – Exemple d’arbre de decision sur 50 exemples fictifs r ´ epartis en 25 ´ presque-natifs et 25 leurres, avec 3 attributs : fa dun, fa pair et fa rep. Cet exemple fictif commence par separer en deux les 50 exemples selon fa ´ dun, avec un seuil de 0.43. Les exemples avec fa dun≥ 0.43 sont ensuite separ ´ es selon ´ fa rep, avec un seuil de 0.72, a la suite de quoi deux feuilles sont donc cr ` e´ees. La ´ premiere feuille correspond aux exemples avec fa ` dun≥ 0.43 et fa rep≤ 0.72 et est peuple de 13 presque-natifs et 5 leurres. En pr ´ ediction, comme cette feuille est ma- ´ joritairement peuplee de presque-natifs, un exemple dont la classe est ´ a pr ` edire et qui ´ serait attribue´ a cette feuille serait pr ` edit presque-natif. La seconde feuille correspond ´ aux exemples avec fa rep> 0.72 parmi les exemples de fa dun≥ 0.43. Cette feuille est peuplee de 16 leurres et 4 presque-natifs, et pr ´ edit comme un leurre tout exemple ´ correspondant a ses seuils. ` Pour les exemples avec fa dun< 0.43, une seconde separation est effectu ´ ee avec ´ un seuil de 0.14 sur fa pair. Nous tombons directement sur une feuille pour fa dun< 0.43 et fa pair< 0.14, peuplee de 2 presque-natifs. Pour fa ´ dun< 0.43 et fa pair≥ 0.14, une troisieme s ` eparation selon fa ´ rep est effectuee, avec un seuil de 0.65. Les ´ exemples avec fa dun< 0.43, fa pair≥ 0.14 et fa rep> 0.65 sont au nombre de 3 et sont tous des leurres. La derniere feuille a 7 exemples, dont 6 presque-natifs et ` 1 leurre, avec fa dun< 0.43, fa pair≥ 0.14 et fa rep≤ 0.65. Cette feuille predit les ´ exemples comme etant des presque-natifs. ´ Dans cet exemple fictif, on peut remarquer deux cas de figure : les feuilles ou les ` exemples sont de meme classe et les feuilles o ˆ u il y a des exemples des deux classes. ` Dans le cas ou les exemples sont de m ` eme classe, il para ˆ ˆıt evident que les exemples ´ a pr ` edire dont les valeurs d’attributs correspondent ´ a cette feuille sont pr ` edits comme ´ etant de la classe des exemples de la feuille. Dans le second cas, c’est la classe ´ majoritaire qui est consider´ ee comme ´ etant la classe de la feuille. ´ On peut aussi remarquer que les deux premieres feuilles sont peupl ` ees d’exemples ´ des deux classes, alors qu’il reste un dernier attribut selon lequel les exemples n’ont pas et ´ e s ´ epar ´ es. L’apprentissage de l’arbre a consid ´ er´ e que cette s ´ eparation en fa ´ pair n’apportait pas d’information supplementaire ´ a la pr ` ediction. ´ 45Chapitre 3. Approche a posteriori La taille de l’arbre est ici relativement petite, mais cette taille peut grandement augmenter avec le nombre d’attributs et d’exemples. Le principal inter´ et des arbres (ou r ˆ egles) de d ` ecision dans notre travail ne r ´ eside ´ pas dans leur pouvoir explicatif mais plutot dans la m ˆ ethode mise en œuvre pour ap- ´ prendre les modeles. ` L’apprentissage des arbres de decision repose sur le principe ´ diviser-pour-regner ´ . Le principe gen´ eral est de diviser it ´ erativement, chaque fois selon un attribut, l’ensem- ´ ble des exemples en sous-ensembles pour lesquels les exemples ont plus de probabilite d’ ´ etre d’une classe donn ˆ ee. La construction de l’arbre de d ´ ecision d ´ ebute l’ensem- ´ ble des exemples. L’objectif est de determiner le couple (attribut, valeur) permettant ´ d’obtenir une partition ”optimale” des donnees. Plusieurs mesures permettent d’ ´ evaluer ´ la qualite des partitions obtenues. Parmi les crit ´ eres classiquement utilis ` es, nous pou- ´ vons citer le gain de Gini, l’entropie de Shannon, etc. Sans rentrer dans les details techniques de l’algorithme que nous avons utilis ´ e,´ a` savoir C4.5 [207] (algorithme de ref ´ erence pour les arbres de d ´ ecision), nous pr ´ ecisons ´ tout de meme que le crit ˆ ere utilis ` e pour s ´ electionner les couples (attribut, valeur) per- ´ mettant de construire un arbre de decision est l’entropie de Shannon. ´ L’algorithme ne procede pas ` a une s ` eparation en nœuds fils s’il se trouve dans l’un ´ des cas suivants : – tous les exemples du nœud courant sont de la meme classe ˆ y, ce qui cree une ´ feuille etiquet ´ ee avec la classe ´ y ; – tous les attributs obtiennent un gain d’information normalise nul, ce qui cr ´ ee une ´ feuille etiquet ´ ee de la classe majoritaire ; ´ – la taille d’au moins une des partitions cre´e est inf ´ erieure ´ a un seuil pr ` ed´ efini. ´ Dans le premier cas, le classement est parfait suivant les exemples du jeu d’apprentissage. Dans le second cas, les attributs ne permettent pas d’ameliorer davantage le ´ gain d’information et toute inference suppl ´ ementaire de r ´ egles de d ` ecision est donc ´ inutile du point de vue des donnees disponibles en apprentissage. Le troisi ´ eme cas ` correspond a la situation o ` u, malgr ` e l’ensemble des tests d ´ ej ´ a effectu ` es, la partition ´ courant n’est toujours pas pure mais sa taille est telle qu’il n’est pas raisonnable de continuer a rafiner car cela impliquerait du surapprentissage. ` D’autres arbres de decision peuvent ´ etre obtenus, par exemple des arbres de ˆ decision partiels tels que l’algorithme P ´ ART permet d’en construire. L’algorithm PART gen´ ere des arbres de d ` ecision partiels sans optimisation globale des r ´ egles apprises. ` La meme strat ˆ egie d’apprentissage que celle pr ´ esent ´ ee pr ´ ec´ edemment pour les ar- ´ bres de decision, ´ a savoir diviser-pour-r ` egner, est utilis ´ ee dans P ´ ART. PART commence par creer un arbre de d ´ ecision ´ elagu ´ e, qui divise les candidats en sous-ensembles ´ dans les nœuds de l’arbre. Pour ce faire, PART divise en sous-ensembles les candidats d’un sous-ensemble n’etant pas encore divis ´ e selon un test sur la valeur d’un ´ attribut au hasard. PART rep´ ete ce processus r ` ecursivement jusqu’ ´ a ce que tous les ` sous-ensembles soient des feuilles contenant des candidats d’une seule classe. Pour l’elagage de l’arbre, P ´ ART annule la division de n’importe quel sous-ensemble en feuilles si l’erreur calculee sur les feuilles est sup ´ erieure ou ´ egale ´ a l’erreur calcul ` ee´ sur le sous-ensemble. Une fois un arbre de decision ´ elagu ´ e, P ´ ART infere une r ` egle de ` decision en ne choisissant que le chemin de la racine vers la feuille la plus peupl ´ ee´ 463.1. Modeles a posteriori ` de l’arbre. Un nouvel arbre de decision est ensuite construit en ne consid ´ erant que ´ les candidats qui ne sont pas couverts par une regle de d ` ecision. P ´ ART itere jusqu’ ` a` couvrir tous les candidats. Comme indique pr ´ ec´ edemment, parmi les approches dites ”explicatives”, nous trou- ´ vons des approches permettant d’apprendre des regles de d ` ecision. Parmi ces ap- ´ proches, nous avons retenu RIPPER qui est une amelioration de IREP ´ (Incremental Reduced Error Pruning) [50]. L’apprentissage des regles de d ` ecision avec R ´ IPPER repose sur deux etapes s’ex ´ ecutant s ´ equentiellement : 1) la construction avec croissance ´ et elagage et 2) l’optimisation des r ´ egles de d ` ecision. Pour chaque classe, de la moins ´ peuplee´ a la plus peupl ` ee, R ´ IPPER commence par iterer l’ ´ etape de construction sur ´ l’ensemble des attributs par series de croissance et d’ ´ elagage de r ´ egles. Une ` etape ´ de construction commence par une partition de l’ensemble d’apprentissage en un ensemble de croissance et un ensemble d’elagage. La construction des r ´ egles s’arr ` ete ˆ lorsque : – la longueur de description de la regle en construction a 64 bits de plus que celle ` de la regle de longueur de description la plus petite parmi les r ` egles trouv ` ees ; ´ – il n’y a plus d’exemple positif, auquel cas l’ensemble de regles est retourn ` e tel ´ quel ; – le taux d’erreur est superieur ou ´ egal ´ a 50 %, auquel cas l’ensemble de r ` egles ` retourne contient toutes les r ´ egles construites sauf la derni ` ere r ` egle. ` La croissance rajoute une a une les conditions permettant d’augmenter le plus ` vite le gain d’information (par approche gloutonne), jusqu’a obtenir une pr ` ecision de ´ 100%. La croissance teste toutes les valeurs possibles a chaque fois qu’elle ajoute ` une condition. L’elagage est incr ´ emental pour chaque r ´ egle : l’ ` elagage supprime la ´ condition dont l’effacement ameliore la mesure d’ ´ elagage. La mesure d’ ´ elagage utilis ´ ee´ dans JRip (implantation de RIPPER dans Weka) est egale ´ a ( ` p + 1)/(p + n + 2) avec p le nombre d’exemples positifs correctement predits et ´ n le nombre d’exemples negatifs ´ correctement predits parmi les exemples d’ ´ elagage. Lorsqu’une r ´ egle est construite, ` les exemples qu’elle couvre sont retires des exemples utilis ´ es pour la construction des ´ futures regles. ` L’etape d’optimisation consiste en la construction de deux variantes pour chaque ´ regle, en utilisant comme ensemble d’apprentissage un sous-ensemble al ` eatoire des ´ exemples de l’ensemble d’apprentissage. La premiere variante ajoute des conditions ` a une r ` egle vide. La seconde variante ajoute les conditions par approche gloutonne ` a` la regle initiale. Pour l’optimisation, le mesure d’ ` elagage est ( ´ p + n)/(P + N), avec P le nombre d’exemples positifs et N le nombre d’exemples negatifs parmi les exemples ´ d’elagage. Une fois les variantes construites, la variante de longueur de description la ´ plus petite est conservee. Enfin, les r ´ egles augmentant la longueur de description de ` l’ensemble de regles sont retir ` ees. ´ 3.1.3 Approches dites non explicatives Les forets al ˆ eatoires ´ se fondent sur l’apprentissage de B arbres decisionnels ´ d’une hauteur maximale h en utilisant a chaque fois ` k attributs au hasard. Pour chaque 47Chapitre 3. Approche a posteriori arbre decisionnel (ou arbre al ´ eatoire), un ´ echantillon al ´ eatoire du jeu de donn ´ ees d’ap- ´ prentissage est utilise pour l’apprentissage. De plus, pour chaque arbre d ´ ecisionnel, ´ seul un sous-ensemble de k attributs aleatoires est utilis ´ e pour l’apprentissage. Un ´ arbre decisionnel est l’arborescence d’une succession de tests conditionnels ´ a ef- ` fectuer sur les valeurs des attributs de l’exemple a pr ` edire. ´ A chaque nœud d’un arbre ` decisionnel correspond une test sur un attribut, menant ´ a l’un de ses nœuds fils en ` fonction de la valeur de l’attribut teste. Pour d ´ ecider de la classe d’un exemple en ´ utilisant un arbre decisionnel, il faut successivement tester, du noeud racine jusqu’ ´ a` une feuille, les nœuds vers lesquels dirigent le resultat de chaque decision. Un arbre ´ decisionnel est appris par mesure statistique sur les diff ´ erents attributs au sein des ex- ´ emples de chacune des classes. Cette mesure statistique se fonde sur une approche frequentiste. ´ Le classifieur bayesien na¨ıf ´ repose sur le theor ´ eme de Bayes. Le classifieur ` bayesien na ´ ¨ıf est appele na ´ ¨ıf en ce sens qu’il fait l’hypothese d’ind ` ependance des ´ differents attributs entre eux (voir ´ eq. 3.3). La probabilit ´ e qu’un exemple soit d’une cer- ´ taine classe y sachant la valeur de chacun de ses attributs est egale ´ a sa probabilit ` e´ a priori d’etre de la classe ˆ y multipliee par le produit des probabilit ´ es qu’un exemple ´ de cette classe ait la valeur de chacun de ses attributs. Les differents param ´ etres du ` modele sont estim ` es par calcul de fr ´ equences sur l’ensemble d’apprentissage. Il est ´ par ailleurs fait l’hypothese que les variables al ` eatoires sous-jacentes aux param ´ etres ` suivent une loi normale. P (y|X) = P (y) Y |A| i=1 P (xi |y) (3.3) Un autre classifieur est dit na¨ıf, le 1-plus-proche-voisin. Le 1-plus-proche-voisin est une instance du k-plus-proche-voisin pour k = 1. Le k-plus-proche-voisin predit ´ qu’un exemple est de la classe majoritaire parmi les k exemples appris les plus proches. Pour k pair, en cas d’egalit ´ e, il est possible de privil ´ egier une classe par rapport ´ a` l’autre ou de ponderer le vote de chaque voisin par l’inverse de sa distance ´ a l’exemple ` a pr ` edire Le choix de la distance employ ´ ee influence la pr ´ ediction. Traditionnellement, ´ la distance euclidienne est mesuree pour d ´ eterminer la distance entre deux exem- ´ ples. Mais d’autres distances – comme la distance de Manhattan ou la distance de Mahalanobis – sont plus adaptees ´ a certaines probl ` ematiques. Les coordonn ´ ees des ´ exemples sont les valeurs de leurs attributs. Plus k est grand et moins la methode est ´ sensible aux erreurs presentes dans les jeux de donn ´ ees, mais aussi plus la limite ´ entre les classes est floue. Le 1-plus-proche-voisin fait l’hypothese que les exemples ` se comportent localement de la meme mani ˆ ere : leur classe est la m ` eme si les valeurs ˆ de leurs attributs sont proches. De plus, tous les attributs sont comparables dans le poids qui leur est donne pour le calcul de la distance. ´ Tous ces classifieurs sont plus adaptes´ a certaines probl ` ematiques qu’ ´ a d’autres. ` Mais il existe des classifieurs dont la particularite est de tirer partir de la combinaison ´ de classifieurs d’approches tres diff ` erentes : il s’agit des ´ metaclassifieurs ´ . Si plusieurs classifieurs peuvent chacun capturer des informations differentes sur la pr ´ ediction, le ´ metaclassifieur a plus de chances de donner une meilleure pr ´ ediction que chacun ´ 483.1. Modeles a posteriori ` des classifieurs dont il depend. Les m ´ etaclassifieurs offrent le plus de flexibilit ´ e en ´ combinant les scores de plusieurs modeles de fonction de score. ` AdaBoost est un metaclassifieur reposant sur l’apprentissage successif de classi- ´ fieurs faibles. Chaque iteration d’AdaBoost apprend un nouveau classifieur faible. Pour ´ le premier classifieur appris, tous les exemples ont un poids identique. Chaque autre classifieur faible appris rec¸oit en entree de son apprentissage, pour chaque candidat, ´ un poids augmentant avec les erreurs commises par les classifieurs faibles prec´ edents ´ sur ce candidat. Cette ponderation donne plus d’importance aux exemples n’ayant pas ´ et ´ e captur ´ es par les classifieurs faibles pr ´ ec´ edemment construits. Au fur et ´ a mesure ` des iterations, les exemples les plus difficiles ´ a classer rec¸oivent un poids ` elev ´ e, jusqu’ ´ a` ce que l’un des classifieurs les classe correctement. Vote attribue pour chaque exemple a pr ` edire une classe selon un principe de vote. ´ Le principe de vote peut utiliser la moyenne, la mediane, le minimum ou m ´ eme le ˆ maximum. Les machines a vecteurs de support ` (SVM, Support Vector Machines) ont pour principe gen´ eral d’apprendre une fonction de s ´ eparation qui maximise la marge en- ´ tre les exemples et leur separation. Maximiser la marge de s ´ eparation a pour objec- ´ tif de minimiser l’erreur de gen´ eralisation. Les SVM mettent en jeu des noyaux pour ´ determiner cette s ´ eparation. Avec les SVM, le mod ´ ele est param ` etr ´ e par l’hyperplan ´ utilise pour s ´ eparer les exemples pr ´ edits positifs des exemples pr ´ edits n ´ egatifs. De ´ plus, il est possible d’utiliser une fonction noyau pour transformer les exemples et gen´ erer un mod ´ ele implicitement non-lin ` eaire. Selon la probl ´ ematique, les diff ´ erents ´ noyaux sont plus ou moins adaptes. Les SVM ne tiennent cependant pas compte de ´ la difference de distribution des exemples en fonction de leur classe. En effet, les SVM ´ ont pour objectif de maximiser la marge de separation, ´ i.e. la distance minimale entre la fonction de separation apprise et les exemples de chaque classe. Or, les exemples ´ peuvent se distribuer differemment selon la classe ´ a laquelle ils appartiennent. Les ex- ` emples d’une classe peuvent etre tr ˆ es proches les uns des autres alors que les exem- ` ples d’une autre classe peuvent etre comparativement plus ˆ etendus. Dans un tel cas ´ de figure, il serait plus judicieux, pour minimiser l’erreur de gen´ eralisation, de donner ´ un poids plus important a la distance aux exemples de la classe la plus ` etendue qu’aux ´ autres exemples. La fonction de separation serait alors plus proches des exemples de ´ la classe dont la distribution est la moins etendue. ´ 3.1.4 Boˆıte a outils utilis ` ee pour apprendre les mod ´ eles ` Weka [103] est une boˆıte a outils impl ` ement ´ ee en Java d’algorithmes de fouille de ´ donnees. Weka prend en donn ´ ees d’entr ´ ee des exemples munis de descripteurs et ´ peut visualiser la correlation entre ces descripteurs au sein des donn ´ ees. Weka peut ´ filtrer les donnees d’entr ´ ee et utiliser des m ´ ethodes de clustering ou de s ´ election de de- ´ scripteurs. Weka peut aussi apprendre des modeles de pr ` ediction sur ces donn ´ ees, les ´ tester et sortir les modeles et leurs ` evaluations. Les classifieurs disponibles dans Weka ´ sont ranges par cat ´ egories : les classifieurs bay ´ esiens, les fonctions, les classifieurs ´ na¨ıfs, les metaclassifieurs, les r ´ egles de d ` ecision, les arbres de d ´ ecision, les classi- ´ 49Chapitre 3. Approche a posteriori fieurs multi-instances et les classifieurs n’ayant pas pu etre rang ˆ es dans les autres ´ categories. Les classifieurs sont appris avec la version 3.6 de Weka. Les classifieurs ´ presents dans Weka et utilis ´ es ici sont : ´ – J48 (implementation de C4.5 [207]) ; ´ – JRip (implementation de R ´ IPPER, Repeated Incremental Pruning to Produce Error Reduction [50]) ; – PART (variante de C4.5 et de RIPPER reposant sur des arbres de decision partiels ´ [86]) ; – RandomForest (implementation des for ´ ets al ˆ eatoires [30]) ; ´ – NaiveBayes (implementation du classifieur bay ´ esien na ´ ¨ıf [127]) ; – IB1 (implementation du 1-plus-proche-voisin [2]) ; ´ – AdaBoostM1 (implementation d’AdaBoost [223]) ; ´ – Vote [135] ; – Machines a vecteurs de support (SVM [38]). ` 3.1.5 Methodologie d’optimisation des fonctions de score ´ a posteriori La methodologie g ´ en´ erale d’optimisation des fonctions de score ´ a posteriori se decompose en quatre phases : ´ – reprendre les jeux de donnees pr ´ epar ´ es et pr ´ esent ´ es au chapitre 1 ; ´ – l’apprentissage des fonctions de score par les differents classifieurs sur l’ensem- ´ ble des 120 complexes et le meme apprentissage, mais effectu ˆ e en ´ leave-”onepdb”-out ; – l’apprentissage par ROGER des metascores avec comme attributs les termes de ´ score physico-chimiques et les scores des differents classifieurs ; ´ – l’evaluation des diff ´ erentes fonctions de score des classifieurs ainsi que des ´ metascores. ´ 3.2 Evaluation des fonctions de score ´ a posteriori A posteriori, il est possible d’utiliser une fonction de score plus complexe qu’une combinaison lineaire de termes d’ ´ energie. L’utilit ´ e de ce proc ´ ed´ e est de pouvoir re- ´ trier un ensemble de candidats gen´ er´ es par RosettaDock, pour pouvoir r ´ einjecter les ´ meilleurs candidats dans un amarrage atomique, pour affiner les structures obtenues. Cela necessite que la fonction de score ´ a posteriori permette de mieux identifier les presque-natifs qu’une fonction de score etant une combinaison lin ´ eaire de termes ´ d’energie. Les r ´ esultats suivants ´ evaluent plusieurs mod ´ eles de fonctions de score ` a posteriori. Pour que chaque terme de score puisse participer dans la meme mesure ˆ a la fonc- ` tion de score, il est necessaire que l’intervalle de valeurs de chaque terme de score ´ soit reduit ´ a l’intervalle unit ` e. Les termes de score ´ a valeurs positives sont ramen ` es´ a l’intervalle [0 ; 1] alors que les termes de score ` a valeurs n ` egatives sont ramen ´ es´ a` 503.2. Evaluation des fonctions de score a posteriori ´ l’intervalle [−1 ; 0]. La repartition des candidats pour chaque terme de score est donc ´ etudi ´ ee pour mieux comprendre l’influence de chaque terme. ´ 3.2.1 Repartition des candidats par terme de score ´ Pour etudier au mieux le comportement des termes de score pour l’ensemble des ´ candidats presque-natifs et leurres, les valeurs reduites ´ a l’intervalle unit ` e sont in- ´ diquees entre parenth ´ eses, sauf pour les scores issus des classifieurs, qui donnent ` dej ´ a des valeurs dans l’intervalle unit ` e. L’ ´ etude se fait sur l’ensemble des 1 200 000 ´ candidats et sur les termes de score physico-chimiques comme sur ceux issus des classifieurs (voir tableau 3.1). On peut notamment remarquer que la valeur du terme de score fa dun est plus elev ´ ee pour les presque-natifs que pour les leurres : la m ´ ediane est de 683 (0.10) ´ pour les presque-natifs contre 549 (0.08) pour les leurres. La terme de score fa dun correspond a la p ` enalit ´ e donn ´ ee par la base de donn ´ ees Dunbrack pour les rotam ´ eres ` presents dans la structure ´ evalu ´ ee. Pour les deux classes d’exemples, les valeurs ´ se distribuent densement autour de la m ´ ediane et d ´ epassent largement la valeur ´ moyenne, respectivement a 848 (0.12) et 682 (0.10). Cette r ` epartition montre que seul ´ un petit nombre d’acides amines est, pour chaque complexe, assimil ´ e´ a une p ` enalit ´ e´ elev ´ ee, mais aussi que ce nombre est plus ´ elev ´ e pour les presque-natifs que pour les ´ leurres. On peut en conclure que les chaˆınes laterales des acides amin ´ es se compor- ´ tent differemment de ce qui est attendu par la base de donn ´ ees Dunbrack lorsqu’elles ´ sont en interaction avec un ARN. Les termes de score fa rep et fa pair sont quant a eux plus faibles pour les presque- ` natifs que pour les leurres. Pour fa rep, les presque-natifs ont une mediane de 352 ´ (0.27), alors que les leurres ont une mediane de 406 (0.32). Pour fa ´ pair, la mediane ´ est a 37 (0.17), contre 51 (0.23) pour les leurres. Ils ont effectivement pour but de ` donner une penalit ´ e aux candidats mettant en jeu des atomes trop proches les uns ´ des autres (fa rep) ou rarement rencontres ensemble (fa ´ pair). Le terme de score fa sol a un comportement different dans les valeurs n ´ egatives, ´ puisqu’il a des valeurs plus faibles en valeur absolue pour les presque-natifs que pour les leurres. La mediane de fa ´ sol est de −9 (−0.22) pour les presque-natifs et de −11 (−0.27) pour les leurres. Le score le plus remarquable issu des classifieurs est le score donne par le 1- ´ plus-proche-voisin : sa moyenne est de 0.62 pour les presque-natifs et 0.55 pour les leurres. Les autres scores appris a l’aide des classifieurs ne permettent pas de discriminer ` les presque-natifs des leurres. Mais nous allons tout de meme ˆ evaluer l’ensemble des ´ classifieurs a l’aide des diff ` erentes mesures d’ ´ evaluation. ´ 3.2.2 Weka Les fonctions de score gen´ er´ ees avec les diff ´ erentes strat ´ egies d’apprentissage ´ selectionn ´ ees dans Weka montrent des performances hasardeuses (voir tableau 3.2). ´ 51Chapitre 3. Approche a posteriori Exemples Score 1 er quartile Mediane ´ Moyenne 3 e quartile +1 fa dun 366 (0.05) 683 (0.10) 848 (0.12) 1165 (0.16) +1 fa pair 19 (0.08) 37 (0.17) 50 (0.22) 70 (0.31) +1 fa rep 228 (0.18) 352 (0.27) 425 (0.33) 607 (0.47) +1 fa sol -3 (-0.08) -9 (-0.22) -11 (-0.27) -17 (-0.40) +1 hack elec -8 (-0.09) -17 (-0.21) -18 (-0.23) -25 (-0.31) +1 hbond bb sc -13 (-0.07) -29 (-0.16) -37 (-0.21) -55 (-0.31) +1 NearestNeighbor 0.00 1.00 0.62 1.00 +1 NaiveBayes 0.34 0.42 0.50 0.60 +1 JRip 0.44 0.54 0.51 0.57 +1 J48 0.44 0.52 0.53 0.74 +1 PART 0.45 0.52 0.55 0.68 +1 RandomForest 0.40 0.60 0.56 0.70 -1 fa dun 282 (0.04) 549 (0.08) 682 (0.10) 927 (0.13) -1 fa pair 25 (0.11) 51 (0.23) 60 (0.27) 82 (0.37) -1 fa rep 267 (0.21) 406 (0.32) 487 (0.38) 671 (0.52) -1 fa sol -6 (-0.13) -11 (-0.27) -14 (-0.32) -20 (-0.48) -1 hack elec -9 (-0.11) -18 (-0.22) -20 (-0.25) -26 (-0.33) -1 hbond bb sc -17 (-0.10) -40 (-0.23) -46 (-0.26) -60 (-0.34) -1 NearestNeighbor 0.00 1.00 0.55 1.00 -1 NaiveBayes 0.34 0.41 0.47 0.54 -1 JRip 0.43 0.53 0.49 0.57 -1 J48 0.43 0.47 0.51 0.64 -1 PART 0.44 0.48 0.51 0.58 -1 RandomForest 0.40 0.50 0.53 0.70 TABLE 3.1 – Pour chaque terme de score sont indiques la valeur du premier quartile, de ´ la mediane, de la moyenne et du troisi ´ eme quartile, sur les presque-natifs (exemples ` +1) et les leurres (exemples -1). Entre parentheses se trouvent les valeurs des scores ` ramenees ´ a l’intervalle unit ` e quand ce n’est pas d ´ ej ´ a le cas. NearestNeighbor corre- ` spond au score donne par la fonction de score apprise au moyen du 1-plus-proche- ´ voisin, NaiveBayes au classifieur bayesien na ´ ¨ıf, JRip a l’impl ` ementation de R ´ IPPER, J48 a l’impl ` ementation de C4.5, P ´ ART est une variante de C4.5 et RandomForest a` l’apprentissage de forets al ˆ eatoires. ´ De maniere g ` en´ erale, moins de la moiti ´ e des complexes ont une ROC-AUC sup ´ erieure ´ a 0.5. Les performances de Vote ne sont pas indiqu ` ees car la fonction de score ap- ´ prise par Vote classe systematiquement les candidats comme presque-natifs. Seul le ´ classifieur bayesien na ´ ¨ıf donne des resultats satisfaisants, avec 108 des 120 com- ´ plexes ayant une ROC-AUC superieure ´ a 0.5 et 81 complexes avec un #presque- ` natifs (top10E(Candidats)) non nul. Malgre les performances, il est tout de m ´ eme int ˆ eressant d’observer par exemple ´ les premiers termes de score utilises par les arbres de d ´ ecision (voir fig. 3.2). Ce ´ 523.2. Evaluation des fonctions de score a posteriori ´ Classifieur ROC-AUC ROC-AUC > 0.5 #(top10E(Candidats))> 0 ROGER lineaire ´ 0.798±0.018 119 117 JRip 0.314±0.164 36 8 IB1 0.449±0.122 53 3 PART 0.472±0.039 49 18 J48 0.493±0.020 60 16 RandomForest 0.498±0.022 60 56 NaiveBayes 0.649±0.015 108 81 TABLE 3.2 – Pour chaque classifieur Weka selectionn ´ e sont indiqu ´ es : la moyenne ´ et la variance de la ROC-AUC, le nombre de complexes pour lesquels la ROCAUC est superieure ´ a 0.5 et le nombre de complexes avec un #presque- ` natifs (top10E(Candidats)) non nul. sont les termes de score fa dun – qui correspond au terme de score des rotameres ` Dunbrack – hack elec (terme de score electrostatique), fa ´ sol (terme de solvatation), fa pair (terme d’affinite entre pairs d’atomes), fa ´ rep (terme de repulsion universelle) ´ et les termes de score hbond qui sont mis en avant. Nous avons vu dans l’etude de la ´ repartition des valeurs des termes de score entre presque-natifs et leurres que fa ´ dun donnait pour les presque-natifs des valeurs plus elev ´ ees que pour les leurres. Et en ´ effet, une petite partie des presque-natifs correspond a un pic de valeurs extr ` emes en ˆ fa dun, avec de nombreuses chaˆınes laterales dans des conformations ordinairement ´ peu probables dans une proteine. Ceci nous conforte dans l’id ´ ee que la distribution des ´ conformations des chaˆınes laterales des acides amin ´ es d’une prot ´ eine peut changer ´ a l’interaction avec un ARN. Les termes de score ` electrostatique, d’affinit ´ e entre pairs ´ d’atomes et des liaisons hydrogene ont d ` ej ´ a` et´ e vus dans la section 2.4.3.4 comme ´ etant des facteurs importants de l’interaction prot ´ eine-ARN. Le terme de score fa ´ rep a aussi et ´ e vu dans le filtre par la m ´ ediane en fa ´ rep comme etant important pour ´ ecarter ´ les leurres comportant trop d’interpen´ etration (voir section 2.4.4). Seul le terme de ´ solvatation n’avait jusqu’a lors pas ` et´ e vu dans le chapitre pr ´ ec´ edent comme important ´ pour l’interaction proteine-ARN. ´ 3.2.3 ROGER non lineaire ´ Lever la contrainte de linearit ´ e de la fonction de score permet d’explorer des solu- ´ tions plus complexes, pouvant prendre en compte des informations qu’une combinaison lineaire des termes de score n’atteint pas. L’apprentissage de fonctions de score ´ non lineaires avec R ´ OGER a cet objectif. Deux types de fonctions de score sont apprises : l’une apprise uniquement sur les termes de score physico-chimiques, l’autre apprise aussi sur les scores des classifieurs selectionn ´ es dans Weka. ´ Meme si les classifieurs s ˆ electionn ´ es dans Weka ne donnent pas de r ´ esultats satis- ´ faisants, ils ont des performances de classifieur faible pour plusieurs dizaines de complexes chacun. S’ils capturent chacun des informations differentes sur les candidats, il ´ 53Chapitre 3. Approche a posteriori • fa dun ≤ 866.949 • fa dun ≤ 231.186 • fa sol ≤ −23.739 • fa atr ≤ −2023.861 (presque-natifs) • fa atr > −2023.861 (leurres) • fa sol > −23.739 • hbond sc ≤ −12.138 (leurres) • hbond sc > −12.138 (presque-natifs) • fa dun > 231.186 • fa sol ≤ −35.702 • hbond bb sc ≤ −93.066 (leurres) • hbond bb sc > −93.066 (presque-natifs) • fa sol > −35.702 • fa rep ≤ 1042.462 (leurres) • fa rep > 1042.462 (presque-natifs) • fa dun > 866.949 • fa dun ≤ 1499.729 • hbond bb sc ≤ −148.009 • fa rep ≤ 1063.695 (leurres) • fa rep > 1063.695 (presque-natifs) • hbond bb sc > −148.009 • hack elec ≤ −2.433 (leurres) • hack elec > −2.433 (presque-natifs) • fa dun > 1499.729 • fa pair ≤ 65.641 • fa rep ≤ 556.425 (leurres) • fa rep > 556.425 (presque-natifs) • fa pair > 65.641 • hbond sr bb ≤ −8.178 (presque-natifs) • hbond sr bb > −8.178 (leurres) FIGURE 3.2 – Arbre de decision appris avec J48 sur les 120 complexes de la P ´ RIDB. Seuls les nœuds apres au plus 4 bifurcations sont affich ` es, pour donner un aperc¸u des ´ premiers attributs mis en jeu dans l’arbre. peut etre int ˆ eressant de combiner les forces de chacun de ces classifieurs. L’apprentis- ´ sage d’un metascore avec R ´ OGER non lineaire permet de tester cette hypoth ´ ese. Les ` scores des classifieurs selectionn ´ es dans Weka deviennent des termes de score, au ´ meme titre que les termes physico-chimiques. ˆ Dans l’ensemble, les fonctions de score apprises avec ROGER non lineaire don- ´ nent des resultats moins satisfaisants que celles obtenues avec R ´ OGER lineaire (voir ´ tableau 3.3). Sans metascore, les r ´ esultats sont quasiment identiques concernant le ´ nombre de complexes avec une ROC-AUC superieure ´ a 0.5, mais moins satisfaisants ` du point de vue des autres mesures d’evaluation. L’emploi des scores des classifieurs ´ de Weka dans les metascores d ´ egradent les performances. Les m ´ etascores donnent ´ 543.3. Conclusions sur la fonction de score a posteriori tout de meme 114 complexes pour lesquels il y a au moins un presque-natif dans le ˆ top10 des candidats tries en ´ energie, contre 106 pour R ´ OGER non lineaire sans ap- ´ prentissage d’un metascore. ´ Classifieur ROC-AUC ROC-AUC > 0.5 top10> 0 ROGER lineaire ´ 0.798±0.018 119 117 Metascore R ´ OGER non lineaire ´ 0.648±0.015 107 114 ROGER non lineaire ´ 0.649±0.015 115 106 TABLE 3.3 – Pour chaque classifieur ROGER selectionn ´ e sont indiqu ´ es : la ´ moyenne et la variance de la ROC-AUC, le nombre de complexes pour lesquels la ROC-AUC est superieure ´ a 0.5 et le nombre de complexes avec un #presque- ` natifs (top10E(Candidats)) non nul. 3.3 Conclusions sur la fonction de score a posteriori Nous avons commence par observer la r ´ epartition des termes de score en com- ´ parant les presque-natifs avec les leurres. Nous avons formule plusieurs constata- ´ tions, notamment que la base de donnees de rotam ´ eres Dunbrack n’est peut- ` etre ˆ pas adaptee´ a la pr ` ediction d’interaction prot ´ eine-ARN. En plus d’utiliser une base ´ de donnees de rotam ´ eres pour les ARN, il peut ` etre n ˆ ecessaire d’utiliser une base ´ de donnees sp ´ ecifique aux interactions prot ´ eine-ARN pour obtenir les probabilit ´ es as- ´ sociees ´ a chaque rotam ` ere en interaction avec un ARN. Nous avons ` evalu ´ e des fonc- ´ tions de score modelis ´ ees pour ´ etre utilis ˆ ees ´ a posteriori de la gen´ eration de candidats ´ par RosettaDock. Nous avons modelis ´ e des fonctions de score directement apprises ´ grace ˆ a des classifieurs usuels, notamment des arbres et r ` egles de d ` ecision, mais ´ aussi des metascores prenant pour attributs les scores donn ´ es par ces classifieurs ´ en plus des termes de score physico-chimiques. Il s’avere que les fonctions de score ` testees n’ont pas de performances plus int ´ eressantes que celles de la fonction de ´ score atomique POS. C’est la raison pour laquelle nous nous tournons maintenant vers l’usage de termes de score non pas physico-chimiques, mais geom ´ etriques. Nous souhaitons ´ etendre le ´ protocole de prediction des interactions prot ´ eine-ARN en testant la fonction de score ´ atomique POS sur des candidats issus d’une prediction aveugle. Or, POS n’a ´ et´ e´ testee que pour des candidats ´ a au plus une quinzaine d’Angstr ` oms de la structure ¨ native. Nous souhaitons donc concevoir une fonction de score a une ` echelle plus gros- ´ grain avec pour objectif de trouver des candidats utilisables par POS. 55Chapitre 3. Approche a posteriori 56Chapitre 4 Approche multi-echelle ´ 4.1 Principe de l’approche multi-echelle ´ Pour predire l’interaction avec un maximum d’efficacit ´ e – temps de calcul le plus ´ faible possible et qualite des pr ´ edictions – plusieurs approches peuvent ´ etre com- ˆ binees. Nous avons vu l’utilisation de filtres ´ a posteriori, pour reordonner les r ´ esultats ´ du tri apres une g ` en´ eration de candidats qui contiennent au moins quelques presque- ´ natifs. Nous pouvons aussi intervenir en amont de la gen´ eration des candidats ´ a` l’echelle atomique, en g ´ en´ erant des candidats ´ a l’ ` echelle gros-grain. Cette g ´ en´ eration ´ a l’ ` echelle gros-grain a l’int ´ er´ et de possiblement donner un aperc¸u du score qu’aurait ˆ le meme candidat ˆ a l’ ` echelle atomique, mais avec un temps de calcul r ´ eduit. ´ 4.1.1 Representation g ´ eom ´ etrique gros-grain des acides amin ´ es´ et des acides nucleiques ´ Le prix Nobel de Chimie 2013 7 a montre l’importance dans le domaine de la bi- ´ ologie structurale computationnelle des representations multi- ´ echelle combin ´ ees aux ´ modeles physiques simples. Ce mod ` ele correspond en effet au d ` eveloppement des ´ premiers potentiels energ ´ etiques des ann ´ ees 70. La premi ´ ere apparition correspond ` au modele de Levitt [151] dans lequel chaque r ` esidu d’une prot ´ eine ´ etait repr ´ esent ´ e´ par trois points encore appeles ”atomes gros-grains” : deux pour la cha ´ ˆıne principale (squelette) et un pour la chaˆıne laterale. ´ Depuis ce modele initial, de nombreux autres mod ` eles ont ` et´ e d ´ evelopp ´ es [155, ´ 231, 242]. Par exemple, Voth et Izvekoc [117] ont developp ´ e un potentiel multi- ´ echelle ´ gros-grain ou les param ` etres du champ de force sont extraits de simulations de dy- ` namique moleculaire en utilisant un proc ´ ed´ e d’adaptation des forces. Souvent, les ´ parametres obtenus sont tabul ` es de fac¸on ´ a ne pas ` etre restreints ˆ a la forme analytique ` d’un potentiel. Plus recemment, d’autres potentiels du m ´ eme type ont ˆ et´ e d ´ evelopp ´ es´ [105], permettant de simuler le repliement de proteines de petite taille [106]. ´ Les modelisations gros-grain rendent les calculs plus rapides. Par exemple, pour ´ 7. http://www.nobelprize.org/nobel_prizes/chemistry/laureates/2013/ 57Chapitre 4. Approche multi-echelle ´ le passage d’un modele tout atome ` a un mod ` ele r ` eduit avec un point par r ´ esidu/acide ´ nucleique, le nombre d’atomes (pseudo-atomes) est environ divis ´ e par dix, ce qui peux ´ rendre les calculs jusqu’a 100 fois plus rapide. Le m ` eme ordre de grandeur peut ˆ etre ˆ observe lors du passage d’un mod ´ ele r ` eduit avec un point par r ´ esidu ´ a un point par ` el ´ ement de structure secondaire. ´ Toutefois, le degre de pr ´ ecision n ´ ecessaire ´ a la repr ` esentation fine des processus ´ biologiques est souvent atomique. Il est donc difficile de deriver une repr ´ esentation ´ gros-grain gen´ erique pour un ensemble de syst ´ emes et de simulations rendant la ` modelisation peu co ´ uteuse en temps de calcul et pr ˆ ecise quant ´ a la repr ` esentation ´ fine d’un phenom ´ ene biologique. Pour cette raison, de nombreux groupes ont combin ` e´ des approches a gros grains et grains fins dans des simulations mixtes [5]. Une revue ` des differentes approches est disponible [85]. ´ Dans cette etude, je pr ´ esenterai ´ a nouveau rapidement le mod ` ele utilis ` e par le ´ logiciel RosettaDock puis, de fac¸on plus detaill ´ ee, le mod ´ ele de Vorono ` ¨ı utilise pour ´ l’amarrage. Dans le cadre de l’utilisation de RosettaDock, comme indique dans la section ´ 2.1.1.3 du chapitre 2, la representation gros-grain des prot ´ eines comprend l’ensem- ´ ble des atomes du squelette et un a trois atomes pour la cha ` ˆıne laterale appel ´ es´ centro¨ıdes [99]. Dans cette etude, nous nous sommes limit ´ es´ a l’utilisation du mod ` ele` a un centro ` ¨ıde que nous avons etendu ´ a l’ARN et ` a l’ADN. Les coordonn ` ees spatiales ´ des atomes gros-grain des acides nucleiques sont calcul ´ ees ´ a partir des coordonn ` ees ´ atomiques des acides nucleiques. L’ARN et l’ADN sont donc pourvus des coordonn ´ ees ´ spatiales de leurs atomes gros-grain (voir fig. 4.1). a) Representation g ´ eom ´ etrique gros-grain b) Repr ´ esentation g ´ eom ´ etrique atomique ´ FIGURE 4.1 – Modele gros-grain et mod ` ele atomique : exemple de l’uracile. Le groupe- ` ment phosphate et les atomes lourds du sucre sont represent ´ es en gris. a) Le mod ´ ele` gros grain avec le centro¨ıde en rouge b) Le modele atomique avec les atomes de la ` base en bleu. Le centro¨ıde est le centre geom ´ etrique des atomes lourds. ´ Pour l’adenine, par exemple, nous passons d’un mod ´ ele avec 33 atomes ` a un ` modele avec 13 atomes gros-grains. Le m ` eme facteur 3 est observ ˆ e pour les autres ´ acides nucleiques. ´ La taille des centro¨ıdes des acides nucleiques ainsi remplac ´ es est importante, car ´ elle conditionne la distance a partir de laquelle on peut consid ` erer une interp ´ en´ etration ´ des structures. Cette taille doit permettre aux centro¨ıdes d’occuper l’espace des atomes 584.1. Principe de l’approche multi-echelle ´ que chacun d’entre eux represente, pour leur permettre de se comporter de fac¸on ´ semblable. La taille des centro¨ıdes est donc fixee´ a la valeur donn ` ee pour leur version ´ atomique, a savoir 8 ` A. ˚ Pour les proteines, dans le cadre du mod ´ ele de Vorono ` ¨ı, nous avons choisi de travailler avec un seul point par residu, le centre g ´ eom ´ etrique de la cha ´ ˆıne laterale et du ´ Cα. Ce choix permet tout d’abord de travailler sur un nombre reduit de points, mais ´ aussi de s’affranchir des mouvements des chaˆınes laterales. En effet, m ´ eme lorsque ˆ la chaˆıne laterale bouge, ce qui est fr ´ equent ´ a la surface de la prot ` eine, le centre ´ geom ´ etrique n’est souvent pas trop affect ´ e. Pour la suite, la cellule de Vorono ´ ¨ı correspondante est donc presque identique. La triangulation de Delaunay pour les proteines a ´ et´ e le plus souvent effectu ´ ee´ a` partir des carbones α [71, 183, 233, 253]. Nous avons choisi de construire les diagrammes de Vorono¨ı a partir des centres g ` eom ´ etriques des acides amin ´ es, ceux-ci ´ ayant permis d’obtenir de bons resultats dans le cadre de l’amarrage prot ´ eine-prot ´ eine ´ [18, 15, 26, 27]. Ceux-ci ont et ´ e d ´ efinis comme centres de gravit ´ e des atomes de la cha ´ ˆıne laterale ´ et du carbone α, les atomes d’hydrogene n’ ` etant pas pris en compte. Le centre g ´ eo- ´ metrique ainsi obtenu est donc tr ´ es proche du centre de masse de l’acide amin ` e.´ Ce choix est a rapprocher d’une ` etude r ´ ealis ´ ee par S. Karlin d ´ ebut ´ ee en 1994 [131, ´ 130] dans laquelle trois types de distances sont etudi ´ ees : ´ – entre carbones α ; – entre centres de gravite des acides amin ´ es sans prendre en compte les carbones ´ α ; – entre centres de gravite de tous les atomes du r ´ esidu (cha ´ ˆıne laterale et squelette). ´ Ces trois types de distances sont utilises pour mesurer la distance entre deux r ´ esidus ´ dans un ensemble de structures tridimensionnelles de proteines connues. Cette ´ etude ´ statistique montre que les distances entre centres de gravite des cha ´ ˆınes laterales ´ sont tres sensibles aux interactions ` electrostatiques et hydrophobes, mais tr ´ es peu ` aux contraintes steriques, contrairement aux distances entre les centres de gravit ´ e de ´ tous les atomes de chaque residu. Le fait de prendre en compte le carbone ´ α dans le calcul du point qui va representer chaque acide amin ´ e, permet donc d’obtenir des ´ propriet ´ es interm ´ ediaires. S. Karlin et ses collaborateurs montrent ´ egalement que les ´ distances entre carbones α sont largement decorr ´ el ´ ees, ´ a la fois des interactions et ` des contraintes steriques. ´ Le meme mod ˆ ele a ` et ´ e utilis ´ e pour l’ARN o ´ u nous avons aussi un atome gros-grain ` par acide nucleique, situ ´ e au centre g ´ eom ´ etrique des atomes lourds de la base. En ´ effet, le groupement phosphate et les atomes du sucre sont consider´ es comme faisant ´ partie du squelette, tandis que les atomes lourds de la base sont consider´ es comme ´ etant la cha ´ ˆıne laterale. ´ Contrairement aux proteines, qui n’ont que quatre atomes lourds dans leur squelette, ´ les ARN ont douze atomes lourds et donc un squelette de taille importante. Ceci a pour consequence de placer le centro ´ ¨ıde tres loin du squelette et donc de donner ` une grande importance a l’orientation de la base. Cette approche permet ainsi de ` representer g ´ eom ´ etriquement la flexibilit ´ e de l’ARN pour mieux en tenir compte dans ´ les mesures geom ´ etriques, plut ´ ot que de placer un atome gros-grain au centre de ˆ 59Chapitre 4. Approche multi-echelle ´ l’ensemble des atomes lourds de chaque nucleotide. ´ 4.1.2 Mesure des termes geom ´ etriques ´ a l’ ` echelle gros-grain ´ Les termes geom ´ etriques sont uniquement utilis ´ es ici pour les fonctions de score ´ a l’ ` echelle gros-grain. Seuls les acides amin ´ es et les acides nucl ´ eiques ´ a l’interface ` sont consider´ es pour calculer les termes g ´ eom ´ etriques. Ces termes ont d ´ ej ´ a fait leurs ` preuves pour l’amarrage proteine-prot ´ eine [15]. Ils sont calcul ´ es´ a partir du diagramme ` de Vorono¨ı. Le diagramme de Vorono¨ı est un pavage unique de l’espace en cellules de Vorono¨ı a` partir d’un ensemble de sites. Dans le cas qui nous interesse, les sites sont les r ´ esidus ´ ou pseudo-atomes. Le pavage est defini de telle sorte que n’importe quel point de l’es- ´ pace plus proche d’un site que de tout autre appartient a la cellule de Vorono ` ¨ı de ce site. Formellement, soit l’ensemble des n sites {pj}1≤j≤n, l’ensemble des positions spatiales V(pi) qui sont plus proches du site pi que de tout autre site constitue la cellule de Vorono¨ı du site pi (voir eq. 4.1). ´ V(pi) = {x ∈ R d : kx − pik ≤ kx − pjk; ∀j ∈ N, 1 ≤ j ≤ n} (4.1) Les jointures entre les cellules de Vorono¨ı s’appellent des facettes de Vorono¨ı. En 3 dimensions, une cellule de Vorono¨ı est un volume et une facette de Vorono¨ı est une surface. Les facettes de Vorono¨ı representent la surface d’interaction entre les ´ differents sites. Plus les sites sont proches et peu encombr ´ es par les sites environ- ´ nants, plus elles sont grandes. La cellule de Vorono¨ı represente la zone o ´ u le site a le ` plus d’influence par rapport aux autres sites. Intuitivement, la construction du diagramme de Vorono¨ı utilise entre les differents ´ sites le trace des m ´ ediatrices. Pour plus de clart ´ e, l’exemple illustr ´ e montre la construc- ´ tion manuelle d’un diagramme de Vorono¨ı dans un espace en 2 dimensions (voir fig. 4.2). La Computational Geometry Algorithms Library (CGAL [36]) permet la construction du diagramme de Vorono¨ı. CGAL est une librairie implement ´ ee en C++ de g ´ eom ´ etrie ´ computationnelle algorithmiquement efficace. En pratique, pour une plus grande rapidite de calcul, C ´ GAL obtient le diagramme de Vorono¨ı en construisant son dual, la triangulation de Delaunay (voir fig. 4.3). La triangulation de Delaunay est une triangulation uniquement constituee de trian- ´ gles de Delaunay [167]. Un triangle est un triangle de Delaunay si son cercle circonscrit ne contient aucun autre site que les trois sommets du triangle. Dans une triangulation de Delaunay, tous les sites sont relies par des segments de droites formant des tri- ´ angles. L’algorithme construisant la triangulation de Delaunay en 3 dimensions est un algorithme incremental probabiliste de complexit ´ e´ O(n d 3 2 e ). 604.1. Principe de l’approche multi-echelle ´ a) b) c) FIGURE 4.2 – Illustration de la construction intuitive d’un diagramme de Vorono¨ı en 2 dimensions : a) tracer les mediatrices entre chaque paire de sites (repr ´ esent ´ es par des ´ croix), b) puis limiter les segments de droite a leur jointure et c) it ` erer jusqu’ ´ a obtenir ` toutes les cellules de Vorono¨ı. a) b) c) FIGURE 4.3 – Exemple de triangulation de Delaunay (en 2 dimensions), le dual du diagramme de Vorono¨ı. a) Les droites secantes entre les diff ´ erents sites forment des ´ triangles. b) Pour qu’une triangulation soit une triangulation de Delaunay, le cercle circonscrit de chaque triangle ne doit contenir aucun autre site. c) Pour un meme en- ˆ semble de sites, en gris sont represent ´ es les triangles de la triangulation de Delaunay ´ et en noir les facettes de Vorono¨ı. La construction d’une triangulation de Delaunay commence par la selection al ´ eatoire ´ de 3 sites, qui sont toujours une triangulation de Delaunay. Puis, on teste l’insertion aleatoire d’un nouveau site dans la triangulation en formant de nouveaux triangles ´ avec ce site. Si le nouveau site inser´ e forme un triangle dont le cercle circonscrit con- ´ tient un autre site, alors on teste la formation d’autres triangles avec le meme site. ˆ Sinon, on accepte le nouveau site. On itere jusqu’ ` a ce que tous les sites soient ins ` er´ es´ 61Chapitre 4. Approche multi-echelle ´ (voir fig. 4.4). a) b) c) FIGURE 4.4 – Construction d’une triangulation de Delaunay. Cas initial : 3 sites trac¸ant un triangle constituent toujours une triangulation de Delaunay. Etape d’insertion d’un ´ nouveau site : a) inserer al ´ eatoirement un nouveau site, et donc un nouveau trian- ´ gle (l’insertion est valide si aucun autre site que les sommets du triangle n’est dans son cercle circonscrit) ; b) si un autre site appartient au cercle circonscrit, on refuse l’insertion du triangle et c) on teste alors la construction d’un autre triangle. CGAL est couple´ a la ` Easy Structural Biology Templated Library (ESBTL [168]) pour determiner l’interface et obtenir les mesures statistiques. ESBTL est une li- ´ brairie implement ´ ee en C++, munie de ´ templates pour modeliser et manipuler effi- ´ cacement les entites biologiques. Il est notamment possible de s ´ electionner des entit ´ es´ biologiques telles que des chaˆınes d’acides amines ou d’acides nucl ´ eiques, des acides ´ amines, des acides nucl ´ eiques, des atomes. Des filtres peuvent ´ etre utilis ˆ es pour ne ´ selectionner qu’un sous-ensemble d’entit ´ es biologiques en fonction de son type. Nous ´ avons etendu ESBTL pour : ´ – definir des acides nucl ´ eiques ; ´ – construire automatiquement des atomes gros-grain a partir d’atomes de l’ ` echelle ´ atomique ; – calculer l’aire d’une facette de Vorono¨ı et le volume d’une cellule de Vorono¨ı en 3D. L’interface peut etre d ˆ efinie gr ´ ace au diagramme de Vorono ˆ ¨ı. L’usage d’une structure geom ´ etrique telle que le diagramme de Vorono ´ ¨ı permet en effet de s’affranchir des seuils arbitraires de distance utilises pour d ´ efinir si deux atomes sont en inter- ´ action. Ainsi, au sens du diagramme de Vorono¨ı, pour que deux atomes gros-grain soient en interaction, ils doivent partager une facette de Vorono¨ı. L’interface est de cette maniere repr ` esent ´ ee par l’ensemble des atomes gros-grain partageant une facette de ´ 624.1. Principe de l’approche multi-echelle ´ Vorono¨ı avec au moins un atome gros-grain de l’autre partenaire (voir fig. 4.5). C’est cette definition de l’interface qui est utilis ´ ee pour la fonction de score g ´ eom ´ etrique. ´ FIGURE 4.5 – L’interface d’une tessellation de Vorono¨ı appliquee´ a une interaction ` proteine-ARN. Les atomes gros-grain de la prot ´ eine (en bleu) et de l’ARN (en orange) ´ forment a leur interaction une interface (en vert). ` Le solvant est ajoute explicitement aux structures 3D notamment ´ a l’aide de ESBTL. ` Le solvant explicite a pour fonction de delimiter les surfaces ext ´ erieures des cellules ´ de Vorono¨ı qui ne sont pas enfouies dans la structure. L’ajout du solvant se traduit par l’insertion de sites supplementaires, avant la construction du diagramme de Vorono ´ ¨ı. Ces sites supplementaires sont ins ´ er´ es sous la forme d’un treillis o ´ u tout site est distant ` de tous ses voisins de 5A. Comme l’ajout du solvant explicite a pour cons ˚ equence une ´ forte augmentation du temps de calcul du diagramme de Vorono¨ı, les atomes grosgrain de solvant inutiles sont retires. Sont inutiles tous les atomes gros-grain de solvant ´ qui sont trop loin des atomes gros-grain de chacun des deux partenaires pour interagir avec eux. Comme l’ajout du solvant explicite peut induire un biais dans les resultats, ´ les atomes gros-grain en interaction avec le solvant ne sont pas consider´ es comme ´ faisant partie de l’interface. FIGURE 4.6 – Le solvant a l’interface d’une tessellation de Vorono ` ¨ı construite sur les atomes gros-grain d’une interaction proteine-ARN. Les atomes gros-grain du solvant ´ explicite (en rouge) reduisent l’interface (en vert) : tout atome gros-grain interagissant ´ avec un atome gros-grain du solvant est consider´ e en dehors de l’interface. ´ 63Chapitre 4. Approche multi-echelle ´ 4.1.3 Termes geom ´ etriques ´ a l’ ` echelle gros-grain ´ Il y a 210 termes de score geom ´ etriques r ´ epartis en 6 types de termes de score ´ geom ´ etriques (voir fig. 4.7) : ´ – P1 (1 terme), le nombre de centro¨ıdes a l’interface ; ` – P2 (1 terme), l’aire totale d’interaction, definie par la somme des aires des facettes ´ de Vorono¨ı a l’interface ; ` – P3 (24 termes), la proportion des cellules de Vorono¨ı des centro¨ıdes a l’interface ` sur le nombre total de cellules de Vorono¨ı a l’interface, pour chaque type d’acide ` amine (20) ou d’acide nucl ´ eique (4) ; ´ – P4 (24 termes), la volume median des centro ´ ¨ıdes a l’interface, pour chaque type ` d’acide amine (20) ou d’acide nucl ´ eique (4) ; ´ – P5 (80 termes), la proportion des facettes de Vorono¨ı a l’interface sur le nombre ` total de facettes de Vorono¨ı a l’interface, pour chaque paire de types d’acides ` amines (20) et d’acides nucl ´ eiques (4) ; ´ – P6 (80 termes), la distance mediane entre les centro ´ ¨ıdes a l’interface de cha- ` cun des deux partenaires, pour chaque paire de types d’acides amines (20) et ´ d’acides nucleiques (4). ´ FIGURE 4.7 – Mesure des parametres gros-grain ` a partir du diagramme de Vorono ` ¨ı entre une proteine (en bleu) et un ARN (en orange). a) Facette de Vorono ´ ¨ı (surface grise) entre un acide amine et un acide nucl ´ eique en interaction. Le param ´ etre P2 correspond ` a la somme des aires des facettes de Vorono ` ¨ı constituant l’interface. b) Cellule de Vorono¨ı (en gris et ici decoup ´ ee pour faire appara ´ ˆıtre l’ARN en son centre) d’un acide amine. Le param ´ etre P4 d’un type d’atome gros-grain correpond ` a la valeur m ` ediane ´ de ce volume sur tous les atomes gros-grain du type donne. c) Distance entre deux ´ atomes gros-grain (en jaune). Le parametre P6 de deux types donn ` es d’atomes gros- ´ grain correspond a la valeur m ` ediane de cette distance sur toutes les paires d’atomes ´ gros-grain de ces deux types donnes. ´ On peut dej ´ a remarquer que le nombre de termes de score est ` elev ´ e, avec 210 ´ termes. D’autres parametres auraient pu ` etre utilis ˆ es, comme le nombre de facettes ´ de Vorono¨ı ou la distance mediane entre tous les centro ´ ¨ıdes a l’interface. Mais ces ` 644.1. Principe de l’approche multi-echelle ´ termes de score auraient pu augmenter la redondance des informations contenues dans les differents termes de score. ´ Les deux premiers termes de score P1 et P2 sont attendus plus grands pour les presque-natifs que pour les leurres. Cependant, il est tout a fait possible que leurs ` valeurs oscillent autour d’une valeur moyenne pour les presque-natifs et que des candidats puissent avoir des valeurs encore plus elev ´ ees sans pour autant correspondre ´ a des presque-natifs. Le terme de score P1 correspond ` a une version issue du dia- ` gramme de Vorono¨ı du terme de score gros-grain interchain contact. Les termes de score P3 et P5 ont pour objectif de mesurer l’impact de la presence ´ de chacun des types d’acide amine ou d’acide nucl ´ eique ´ a l’interface (P3), mais aussi ` leurs interactions pref ´ erentielles (P5). En effet, si un terme de score P3 est sensi- ´ blement plus elev ´ e au sein des presque-natifs qu’au sein des leurres, cela peut sig- ´ nifier que le type d’acide amine ou d’acide nucl ´ eique auquel il correspond se trouve ´ pref ´ erentiellement ´ a l’interface. De la m ` eme mani ˆ ere pour un terme de score P5, cela ` signifierait que le type d’acide amine et le type d’acide nucl ´ eique qui lui correspondent ´ sont plus souvent que les autres en interaction dans les complexes proteine-ARN. Les ´ termes de score P3 et P5 correspondent respectivement a une version g ` eom ´ etrique ´ des termes de score interchain env et interchain pair, mais dedi ´ es´ a l’interface. ` Le terme de score P4 evalue sp ´ ecifiquement l’empilement st ´ erique. Les acides ´ amines et nucl ´ eiques au contact les uns des autres forment ce qui est appel ´ e un em- ´ pilement sterique. Si les atomes gros-grain sont trop proches les uns des autres, le ´ volume median sera petit. Or, certains acides nucl ´ eiques et acides amin ´ es occupent ´ plus d’espace que d’autres. On attend donc des atomes gros-grain des acides amines´ et acides nucleiques dont la cha ´ ˆıne laterale est petite d’avoir un petit volume m ´ edian ´ chez les presque-natifs, et inversement. Le terme de score P6 a plusieurs usages. D’une part, la distance mediane permet ´ de reperer les structures pour lesquelles une interaction anormalement longue inter- ´ vient, presageant d’un cas pathologique de leurre (mauvais empilement et donc pos- ´ siblement un probleme lors de la g ` en´ eration des leurres). D’autre part, P6 permet de ´ retrouver l’orientation des acides amines et acides nucl ´ eiques et d’ ´ evaluer si l’orienta- ´ tion de l’interaction se fait telle qu’attendue dans un presque-natif. En effet, les atomes gros-grain representent la cha ´ ˆıne laterale et, selon l’orientation des acides amin ´ es et ´ acides nucleiques ´ a l’interaction, la distance entre eux n’est pas la m ` eme. ˆ 4.1.4 Donnees et fonctions de score ´ a l’ ` echelle gros-grain ´ Le jeu de donnees atomique de candidats est g ´ en´ er´ e autour et ´ a proximit ` e de la ´ solution. Or, la fonction de score gros-grain a besoin de discriminer des candidats meme tr ˆ es` eloign ´ es de la solution des candidats mod ´ elisant l’ ´ epitope de l’interaction. ´ Ce jeu de donnees de candidats g ´ en´ er´ es n’est donc pas utilisable pour l’optimisation ´ de la fonction de score gros-grain. Un jeu de donnees de candidats est donc g ´ en´ er´ e´ a l’identique du jeu de donn ` ees ´ atomique, aux parametres de la perturbation pr ` es. Plut ` ot que de d ˆ efinir un nuage de ´ perturbation gaussienne, les coordonnees de l’ARN sont d ´ efinies al ´ eatoirement au- ´ 65Chapitre 4. Approche multi-echelle ´ tour de la proteine. Ceci assure que la structure native n’affecte pas le r ´ esultat et que ´ n’importe quel candidat puisse etre g ˆ en´ er´ e et utilis ´ e pour l’apprentissage comme pour ´ l’evaluation. ´ Les candidats gen´ er´ es sont ensuite ´ etiquet ´ es par un seuil diff ´ erent en I ´ RMSD de celui utilise pour le jeu de donn ´ ees atomique, pour refl ´ eter la diff ´ erence d’objectif. L’ob- ´ jectif de la fonction de score gros-grain est en effet de trouver l’epitope, pas d’op ´ erer ´ un raffinement de la structure. Le seuil de IRMSD choisi est de 12 A, seuil en-dessous ˚ duquel un candidat est appele´ presque-natif, par analogie avec l’echelle atomique. ´ 4.2 Optimisation de la fonction de score gros-grain Comme pour l’echelle atomique, une fonction de score gros-grain impl ´ ement ´ ee di- ´ rectement dans RosettaDock necessite d’ ´ etre mod ˆ elis ´ ee sous la forme d’une combi- ´ naison lineaire des param ´ etres. Il est cependant possible de s’affranchir d’une telle ` contrainte et de n’utiliser la fonction de score gros-grain qu’en post-traitement de la gen´ eration. Une telle utilisation implique d’avoir d ´ ej ´ a g ` en´ er´ e les candidats. Deux ap- ´ proches sont donc envisageables : l’utilisation d’une combinaison lineaire ou la mise ´ en place d’une fonction de score a posteriori. ROGER, etant donn ´ ees ses performances pour l’adaptation de la fonction de score ´ atomique de RosettaDock a la pr ` ediction d’interactions prot ´ eine-ARN, est utilis ´ e pour ´ l’apprentissage d’une fonction logistique pour modeliser une fonction de score gros- ´ grain. La fonction de score ainsi apprise est appelee´ VOR. Nous allons maintenant detailler comment cette fonction de score est apprise au moyen de R ´ OGER. 4.2.1 Methodologie d’optimisation de la fonction de score gros- ´ grain La methodologie g ´ en´ erale d’optimisation de la fonction de score gros-grain se ´ decline en cinq phases : ´ – la gen´ eration de candidats issus des complexes de la P ´ RIDB par perturbation, mais avec des candidats divergeant davantage de la structure native ; – la construction d’un diagramme de Vorono¨ı sur chacun des candidats gen´ er´ es ; ´ – la mesure des valeurs des termes de score geom ´ etriques gros-grain sur les dia- ´ grammes de Vorono¨ı construits ; – l’apprentissage de la fonction de score sur l’ensemble des 120 complexes de la PRIDB ; – l’evaluation des 120 fonctions de score apprises en ´ leave-”one-pdb”-out et eva- ´ luees sur les 10 000 candidats de leurs jeux d’ ´ evaluation. ´ La gen´ eration de candidats pour l’amarrage gros-grain doit donner des candi- ´ dats divergeant davantage de la solution. De plus, cette gen´ eration ne doit pas tenir ´ compte de la structure du natif. C’est pourquoi la gen´ eration des candidats de l’a- ´ marrage gros-grain se fait en aveugle : les coordonnees spatiales de l’ARN sont ´ determin ´ ees al ´ eatoirement. Une telle g ´ en´ eration sur 10 000 candidats nous emp ´ eche ˆ 664.3. Evaluation de l’interaction ´ a l’ ` echelle gros-grain ´ par consequent d’imposer la m ´ eme contrainte du nombre minimum de presque-natifs ˆ et de leurres gen´ er´ es par complexe. Si le nombre de leurres est rapidement important, ´ le nombre de presque-natifs gen´ er´ es reste tr ´ es faible. Cependant, nous voulons que ` la fonction de score gros-grain nous permette seulement de predire les structures suff- ´ isamment proches de la solution pour etre affin ˆ ees par la fonction de score atomique. ´ Nous pouvons donc considerer ´ a l’ ` echelle gros-grain et pour des raisons d’appren- ´ tissage que le seuil de presque-natifs est cette fois-ci de 10A. Nous pouvons v ˚ erifier ´ que des candidats a moins de 10 ` A de la structure native en I ˚ RMSD permettent bien d’affiner la structure par protocole d’amarrage grace aux entonnoirs d ˆ etect ´ es pour la ´ fonction de score atomique (voir fig. 4.8). 2i82 (ES = 7.14) Irmsd (Å) Score 0 20 −44 −26 0 20 3fht (ES = 3.66) Irmsd (Å) Score 0 20 −24 −17 0 20 3iev (ES = 5.64) Irmsd (Å) Score 0 20 −27 −19 0 20 FIGURE 4.8 – Exemples de diagrammes d’energie en fonction du I ´ RMSD pour la fonction de score POS sur 3 complexes. On remarque des entonnoirs permettant un affinement de structures candidates trouvees ´ a moins de 10 ` A de la structure native. ˚ Contrairement aux termes de score physico-chimiques, ici, tous les termes de score geom ´ etriques ont des valeurs positives ou nulles. Nous ne contraignons donc pas l’ap- ´ prentissage a rechercher les poids sur l’intervalle de valeurs positif avec cette fonction ` de score gros-grain. Nous etudions toutefois les diff ´ erences entre un apprentissage ´ a poids positifs et un apprentissage sans contrainte sur l’intervalle de d ` efinition des ´ poids. 4.3 Evaluation de l’interaction ´ a l’ ` echelle gros-grain ´ La fonction de score gros-grain est modelis ´ ee au moyen de termes g ´ eom ´ etriques ´ issus de la construction d’un diagramme de Vorono¨ı avec pour sites de construction du diagramme les atomes gros-grain de la structure 3D. En plus d’etablir un protocole ´ permettant la prediction des interactions prot ´ eine-ARN, il s’agit de mieux comprendre ´ les mecanismes donnant lieu ´ a une interaction entre prot ` eine et ARN. C’est pourquoi ´ nous etudions non seulement la fonction de score mod ´ elis ´ ee, mais aussi les valeurs ´ des parametres selon le type de structure rencontr ` ee : native ou candidate. ´ 67Chapitre 4. Approche multi-echelle ´ 4.3.1 Etude des valeurs des mesures g ´ eom ´ etriques ´ Les valeurs des mesures geom ´ etriques des structures natives et des candidats per- ´ mettent d’en apprendre plus sur le comportement des mesures geom ´ etriques lorsqu’il ´ y a interaction entre proteine et ARN. Toutes les valeurs des mesures g ´ eom ´ etriques ´ sont ici analysees avant traitement des valeurs non renseign ´ ees : ces derni ´ eres ne ` sont tout simplement pas prises en compte pour cette analyse. Les mesures les plus eloquentes sont certainement le nombre de cellules de Vorono ´ ¨ı en interaction et l’aire de la surface totale d’interaction pour une meme structure 3D. Pour ces deux mesures, ˆ les valeurs sont reparties tr ´ es diff ` eremment entre les structures natives et les candi- ´ dats. En effet, les structures natives ont une surface d’interaction minimale de 10A˚ 2 , contre 0 pour des candidats ou les partenaires sont suffisamment ` eloign ´ es l’un de l’autre ´ (voir tableau 4.1). Rappelons qu’il est possible pour des candidats d’avoir une surface d’interaction nulle car tout atome gros-grain en interaction avec le solvant est retire de ´ l’interface. La mediane de la surface d’interaction des structures natives est de 756 ´ A˚ 2 , contre 336A˚ 2 pour les candidats. La methode de g ´ en´ eration des candidats n’impose ´ pas de contrainte sur les partenaires. Comme ceux-ci sont rigides, les perturbations engendrent de nombreux candidats qui presentent un mauvais emboitement et une ´ interface faible (voir fig. 4.9). FIGURE 4.9 – Interaction de la proteine (en bleu) et de l’ARN (en orange) avec le ´ solvant explicite (en rouge) du modele gros-grain, avec le mod ` ele atomique des deux ` partenaires affiche pour information (en gris). Il peut arriver comme ici que le nombre ´ d’acides amines et de r ´ esidus ´ a l’interface soit r ` eduit ´ a 0 par la pr ` esence d’atomes ´ gros-grain de solvant autour d’une petite interface composee de trois ou quatre acides ´ amines et nucl ´ eiques. ´ Pour le nombre de cellules de Vorono¨ı a l’interface, c’est d’autant plus flagrant, ` puisque la mediane du nombre de cellules de Vorono ´ ¨ı a l’interface est de 44 pour ` les structures natives, contre 28 pour les candidats. Il y a au minimum 3 cellules de Vorono¨ı a l’interface dans les structures natives, contre 27 220 candidats qui n’en ont ` aucune. Ces 27 220 candidats sont repartis sur 26 complexes et ont des partenaires ´ trop eloign ´ es pour avoir une interface, le solvant se logeant trop pr ´ es des quelques ` 684.3. Evaluation de l’interaction ´ a l’ ` echelle gros-grain ´ atomes gros-grain interagissant. Cette absence d’interface est parfois aggravee par le ´ traitement des ions. Les ions a l’interface sont en effet retir ` es de la structure 3D et ´ sont par consequent remplac ´ es par des atomes de solvant s’ils laissent un vide trop ´ important. Or, tout atome gros-grain en interaction avec un atome gros-grain du solvant n’est pas consider´ e comme faisant partie de l’interface, pour ´ eviter que le solvant ne ´ biaise les resultats des surfaces d’interaction et des volumes des cellules de Vorono ´ ¨ı. Agregat ´ Aire de l’interface Nombre de cellules Maximum 3209 174 Moyenne 952 54 Mediane ´ 756 44 Minimum 10 3 TABLE 4.1 – Repartition de deux termes de score g ´ eom ´ etriques sur les structures ´ natives de la PRIDB. L’aire de l’interface (P1) est la surface totale de l’interaction en A˚ 2 , qui est indiquee avec le nombre de cellules de Vorono ´ ¨ı a l’interface. ` Les autres types de mesures sont repartis en fonction du type d’acide amin ´ e´ ou d’acide nucleique et sont donc plus nombreux, mais aussi parfois avec plus de ´ valeurs manquantes. On peut toutefois remarquer certaines propriet´ es int ´ eressantes ´ en comparaison avec les interactions proteine-prot ´ eine. Il a ´ et´ e vu pour les interac- ´ tions proteine-prot ´ eine que les acides amin ´ es hydrophobes ´ etaient les plus pr ´ esents ´ dans l’interface entre les partenaires [15]. Pour les interactions proteine-ARN, c’est le ´ phenom ´ ene inverse qui est observ ` e (voir fig. 4.11). ´ A part la leucine, ce sont les acides ` amines polaires – et notamment charg ´ es – qui sont ´ a l’interface : parmi les acides ` amines hydrophobes, seule la leucine fait partie des acides amin ´ es de proportion non ´ nulle a l’interface sur plus de la moiti ` e des structures natives. La leucine se partage ´ plus de la moitie des interfaces des structures natives avec l’arginine, l’aspartate, le ´ glutamate, la glycine, la lysine et la serine. Au total, parmi les acides amin ´ es charg ´ es, ´ seule l’histidine est absente de l’interface sur l’ensemble des structures natives alors que, au contraire, parmi les acides amines polaires non charg ´ es, ce sont la glycine et ´ la serine qui ont une proportion non nulle. Aucun acide amin ´ e n’est ´ a l’interface dans ` toutes les structures natives. De plus, seule la lysine est presente ´ a l’interface dans ` plus des trois quarts des structures natives. De fac¸on plus gen´ erale, on constate une ´ queue de distribution plus elev ´ ee pour les leurres que pour les presque-natifs et natifs. ´ De la meme mani ˆ ere, les uraciles repr ` esentent en moyenne 12 % des acides amin ´ es´ et nucleiques ´ a l’interface, bien au-del ` a de la guanine (8 %), la cyst ` eine (7 %) et ´ l’adenine (5 %). Et seul l’uracile est pr ´ esent ´ a l’interface dans plus des trois-quarts ` des structures natives (voir fig. 4.12). On peut donc en conclure que les acides amines´ dominent largement les acides nucleiques dans leur participation ´ a l’interaction. Il y ` a plus d’un acide amine pour un acide nucl ´ eique. Le rapport est plus proche de sept ´ acides amines pour trois acides nucl ´ eiques dans les structures natives, donc plus ´ de deux pour un. C’est un rapport important a garder en t ` ete lorsque l’on souhaite ˆ modeliser une interaction prot ´ eine-ARN. En effet, cela signifie que ce sont les atomes ´ 69Chapitre 4. Approche multi-echelle ´ 0 1000 2000 3000 0.0000 0.0010 0.0020 0.0030 P1 : aire de la surface d'interaction Densité de structures 0 50 100 150 200 0.00 0.02 0.04 P2 : nombre d'acides aminés et nucléiques Densité de structures FIGURE 4.10 – Courbes de densite des termes de score P1 (surface d’interaction) et P2 ´ (nombre d’acides amines et nucl ´ eiques ´ a l’interface) sur les 120 structures natives (en ` rouge), sur les 64 994 presque-natifs (en orange) et sur les 1 135 006 leurres (en gris). On peut remarquer que de nombreux candidats ne presentent pas d’interface, ce qui ´ est du au fait que tous les atomes gros-grain en interaction entre les deux partenaires ˆ sont aussi en interaction avec le solvant. gros-grain des acides amines qui ont le plus d’impact sur la valeur du score. ´ La forte proportion de candidats sans un ou plusieurs types d’acides nucleiques ´ a` l’interface est explique par deux ph ´ enom ´ enes : ` – les candidats sans interface ; 704.3. Evaluation de l’interaction ´ a l’ ` echelle gros-grain ´ 0.0 0.2 0.4 0.6 0 20 40 60 80 P3 : proportion de LEU Densité de structures 0.0 0.2 0.4 0.6 0 10 20 30 40 50 P3 : proportion de ARG Densité de structures 0.0 0.2 0.4 0.6 0 10 20 30 40 50 60 P3 : proportion de ASP Densité de structures FIGURE 4.11 – Courbes de densite des termes de score P3 pour quelques acides ´ amines sur les 120 structures natives (en rouge), sur les presque-natifs (en orange) et ´ sur les leurres (en gris). – les candidats avec de petits ARN ou des ARN ne presentant qu’un ou deux types ´ d’acides nucleiques. ´ Nous avons en effet vu que les candidats sans interface etaient nombreux et ont ´ necessairement les valeurs des quatre param ´ etres P3 des acides nucl ` eiques ´ a z ` ero. ´ Mais il existe aussi de petits ARN ou des ARN ne presentant pas un ou plusieurs types ´ d’acides nucleiques. C’est le cas des queues poly-A ou poly-U, qui ne poss ´ edent que ` des adenines ou des uraciles. Il existe aussi des complexes dont l’ARN ne contient ´ 71Chapitre 4. Approche multi-echelle ´ 0.0 0.2 0.4 0.6 0 5 10 20 30 P3 : proportion de GLU Densité de structures 0.0 0.2 0.4 0.6 0 10 30 50 70 P3 : proportion de GLY Densité de structures 0.0 0.2 0.4 0.6 0 5 10 20 30 P3 : proportion de LYS Densité de structures 0.0 0.2 0.4 0.6 0 20 40 60 80 P3 : proportion de SER Densité de structures FIGURE 4.11 (cont.) – Courbes de densite des termes de score P3 pour quelques ´ acides amines sur les 120 structures natives (en rouge), sur les presque-natifs (en ´ orange) et sur les leurres (en gris). qu’une rep´ etition du motif GC. Aucun de ces complexes ne poss ´ ede certains types ` d’acides nucleiques et ceci se retrouve dans les param ´ etres P3 des acides nucl ` eiques ´ sous la forme d’un pic a l’abscisse z ` ero (voir fig. 4.12). ´ 724.3. Evaluation de l’interaction ´ a l’ ` echelle gros-grain ´ 0.0 0.2 0.4 0.6 0 5 10 20 30 P3 : proportion de A Densité de structures 0.0 0.2 0.4 0.6 0.8 0 5 10 15 20 P3 : proportion de C Densité de structures 0.0 0.2 0.4 0.6 0.8 0 5 10 15 20 P3 : proportion de G Densité de structures 0.0 0.2 0.4 0.6 0.8 0 5 10 15 20 P3 : proportion de U Densité de structures FIGURE 4.12 – Courbes de densite des termes de score P3 pour les acides nucl ´ eiques ´ sur les 120 structures natives (en rouge), sur les presque-natifs (en orange) et sur les leurres (en gris). Ici, s’ajoutent aux candidats sans interface les candidats avec de tres` petits ARN, comme des queues poly-A, qui ne contiennent que des adenines et, par ´ consequent, ne poss ´ edent pas d’autre acide nucl ` eique ´ a l’interface que des ad ` enines. ´ 4.3.2 Evaluation de la fonction de score gros-grain ´ La fonction de score gros-grain a pour objectif de trier les candidats de telle sorte qu’au moins une structure modelisant l’ ´ epitope de l’interaction fasse partie des premi- ´ eres structures du tri. Une fois l’ ` epitope d ´ etect ´ e, c’est ´ a la fonction de score atomique ` 73Chapitre 4. Approche multi-echelle ´ d’affiner la structure et d’en modeliser l’interaction 3D. Nous allons d’abord ´ evaluer ´ les poids de la fonction de score gros-grain, puis ses performances, que nous comparerons ensuite a la m ` eme fonction de score dont les poids sont appris dans l’inter- ˆ valle de valeurs positif, ainsi qu’a une fonction de score non lin ` eaire utilisant une valeur ´ de centrage par terme de score (voir section 3.1.1 chapitre 3). 4.3.2.1 Poids Les poids des parametres P1 (l’aire totale de la surface d’interaction) et P2 (le nom- ` bre d’acides amines et nucl ´ eiques ´ a l’interface) sont sans surprise tr ` es n ` egatifs (voir ´ 4.13). Ces poids etaient attendus n ´ egatifs car ils sont cens ´ es favoriser l’interaction : il ´ faut qu’il y ait un nombre suffisant d’acides amines et nucl ´ eiques (pour P1), de m ´ eme ˆ qu’une surface d’interaction suffisante (pour P2) pour obtenir une interaction entre les deux partenaires. On constate tout de meme une distance d’interquartile (entre le pre- ˆ mier quartile et le troisieme) plus importante pour P2 que pour P1. Autrement dit, l’ap- ` prentissage sur chacun des plis du leave-”one-pdb”-out ne donne pas un consensus aussi clair pour l’utilite de P2 que pour celle de P1 pour pr ´ edire l’interaction prot ´ eine- ´ ARN. Ceci suggere que le nombre d’acides amin ` es et nucl ´ eiques en interaction a une ´ contribution plus discutable que la surface d’interaction. ● ● ●●● ● ● ● ● ● ● ● ● −1.0 −0.5 0.0 0.5 1.0 Termes de score P1 (surface d'interaction) et P2 (nombre d'acides aminés et nucléiques) Poids P1 P2 FIGURE 4.13 – Valeurs des coefficients des parametres P1 et P2 pour les 120 com- ` plexes : l’aire totale de la surface d’interaction (en A˚ 2 ) et le nombre d’acide amines et ´ nucleiques ´ a l’interface. P1 et P2 sont tr ` es n ` egatifs. ´ On peut aussi constater que tous les parametres P3 (proportion d’acides amin ` es´ a l’interaction) fluctuent autour d’une valeur de 0.5, avec peu de diff ` erences entre les ´ types d’acides amines ou nucl ´ eiques (voir fig. 4.14). Ces poids ont donc tendance ´ a` 744.3. Evaluation de l’interaction ´ a l’ ` echelle gros-grain ´ augmenter le score final, donc classer le candidat comme leurre. La fonction de score a pris en compte le fait qu’il existe des leurres pour lesquels la proportion d’acides amines de m ´ eme type ˆ a l’interaction est tr ` es importante. Cette proportion importante ` d’acides amines de m ´ eme type correspond ˆ a la queue de distribution de chacun des ` termes de score de P3 vue a la section pr ` ec´ edente. ´ ●● ● ● ● ● ● ● ●● ● ● ● ● ● ● ● ●● ● −1.0 −0.5 0.0 0.5 1.0 Termes de score P3 : proportion d'acides aminés ou nucléiques par type Poids ALA ARG ASN ASP CYS GLN GLU GLY HIS ILE LEU LYS MET PRO PHE SER THR TRP TYR VAL A C G U FIGURE 4.14 – Valeurs des coefficients des parametres P3 pour les 120 complexes : ` les proportions de chaque type d’acide amine et d’acide nucl ´ eique. P3 p ´ enalise les ´ structures qui privilegient ´ a leur interface la pr ` esence d’un type d’acide amin ´ e ou ´ nucleique plut ´ ot qu’un autre. ˆ Comparativement aux poids appris pour les interactions proteine-prot ´ eine, les poids ´ des parametres P4 – les volumes m ` edians – ne sont pas tous n ´ egatifs (voir 4.15). Au ´ contraire, plusieurs acides amines montrent des poids positifs de grande amplitude. En ´ realit ´ e, les poids P4 montrent que l’ordonnancement des acides amin ´ es selon leur taille ´ (ou encombrement sterique) a partiellement ´ et´ e retrouv ´ e´ a travers l’apprentissage. Ils ` sont positifs pour les acides amines de petite taille (alanine, glycine, aspartate, gluta- ´ mate, methionine, valine) et n ´ egatifs de grande amplitude pour les acides amin ´ es de ´ taille importante (arginine, tyrosine, tryptophane, phenylalanine, histidine). Les acides ´ amines polaires non charg ´ es (asparagine, glutamine) de composition proche de cer- ´ tains residus charg ´ es ont aussi des poids n ´ egatifs de plus grande amplitude que les ´ acides amines charg ´ es correspondants : l’aspartate et le glutamate d ´ ej ´ a cit ` es plus ´ haut. Globalement, les poids des parametres P4 sont n ` egatifs ou nuls m ´ eme pour ˆ des acides amines de taille moyenne (thr ´ eonine, leucine, isoleucine, lysine, s ´ erine, ´ cysteine, proline). Pour les acides nucl ´ eiques, les poids sont positifs et faibles, indi- ´ quant que la fonction de score favorise les candidats ayant un volume median rela- ´ tivement faible pour chaque acide nucleique, en comparaison des volumes m ´ edians ´ 75Chapitre 4. Approche multi-echelle ´ obtenus sur les candidats d’une gen´ eration de candidats par perturbation. Les poids ´ des pyrimidines (G et C) sont plus elev ´ es que ceux des purines, qui sont de taille ´ plus petite relativement aux pyrimidines. Le meme constat que pour les prot ˆ eines peut ´ donc etre fait pour les acides nucl ˆ eiques : l’ordonnancement des acides nucl ´ eiques ´ selon leur taille a et ´ e appris par la fonction de score. D’un point de vue g ´ eom ´ etrique, ´ les acides amines et nucl ´ eiques avec une taille importante ont tendance ´ a obtenir des ` cellules de Vorono¨ı plus volumineuses dans une structure native ou presque-native. Dans une structure gen´ er´ ee al ´ eatoirement et ´ eloign ´ ee de la solution native, la cellule ´ de Vorono¨ı peut avoir un volume plus elev ´ e ou plus faible. Cette diff ´ erence entre le ´ volume des cellules de Vorono¨ı pour les presque-natifs et pour les leurres lors de l’apprentissage a donc permis a l’algorithme d’apprentissage de retrouver les tailles des ` differents acides amin ´ es et nucl ´ eiques. ´ ● ● ● ● ● ● ● ● ●● ● ● ● ● ● ● ● −1.0 −0.5 0.0 0.5 1.0 Termes de score P4 : volume médian par acide aminé ou nucléique Poids ALA ARG ASN ASP CYS GLN GLU GLY HIS ILE LEU LYS MET PRO PHE SER THR TRP TYR VAL A C G U FIGURE 4.15 – Valeurs des coefficients des parametres P4 pour les 120 complexes : ` les volumes medians par type d’acide amin ´ e ou nucl ´ eique. Les poids montrent que ´ la fonction de score a retrouve l’information d’encombrement st ´ erique de chaque type ´ d’acide amine et nucl ´ eique. ´ 4.3.2.2 Evaluation de la fonction de score gros-grain ´ La fonction de score gros-grain VOR montre de moins bonnes performances que la fonction de score atomique POS : seuls 65 des complexes ont au moins un presquenatif parmi les 10 premiers candidats. Meme dans le top100 des candidats, seulement ˆ 99 des complexes ont au moins un presque-natif. Ceci est duˆ a plusieurs facteurs. ` Tout d’abord, on peut remarquer que le nombre de presque-natifs par complexe est drastiquement plus faible : moins de 150 presque-natifs sur les 10 000 structures, pour 764.3. Evaluation de l’interaction ´ a l’ ` echelle gros-grain ´ plus de la moitie des complexes. En comparaison, aucun complexe n’avait aussi peu ´ de presque-natifs a l’ ` echelle atomique, puisque leur minimum ´ etait ´ a 225 presque- ` natifs et ce nombre depassait le millier pour 116 des complexes. Ensuite, le nombre de ´ parametres complexifie l’apprentissage. Nous avons pu voir dans l’ ` etude des poids que ´ de nombreuses informations ont et´ e extraites par la fonction de score : l’encombrement ´ sterique des acides amin ´ es et nucl ´ eiques ainsi que la queue de distribution des propor- ´ tions d’acides amines et nucl ´ eiques ´ a l’interface, notamment. Mais les 210 param ` etres ` ne sont appris que sur moins de 2 500 candidats a chaque fois. De plus, la g ` en´ eration ´ de candidats par perturbation n’a pas permis d’obtenir 30 presque-natifs pour tous les complexes et ne permet qu’une gen´ eration in ´ egale du nombre de presque-natifs ´ par complexe. On peut notamment voir des illustrations de complexes pour lesquels la prediction a fonctionn ´ e et d’autres pour lesquels elle n’a pas fonctionn ´ e (voir table 4.2). ´ pdb ES TOP10 Attendus TOP100 Presque-natifs ROC-AUC 1gtf 1.55 10 6.307 99 6307 0.70 1knz 3.26 10 1.136 90 1136 0.73 1m8v 1.70 10 6.192 92 6192 0.61 2a8v 2.22 10 5.018 90 5018 0.67 2voo 4.88 10 3.261 97 3261 0.77 3d2s 1.63 10 5.557 93 5557 0.62 1asy 2.35 0 0.008 0 8 0.59 1b23 1.67 0 0.024 1 24 0.72 1c0a 1.89 0 0.001 0 1 0.77 1ddl 1.21 0 0.327 1 327 0.61 1di2 0.93 0 0.114 0 114 0.52 1e8o 1.43 0 0.743 10 743 0.60 TABLE 4.2 – Resultats de la fonction de score gros-grain VOR sans contrainte sur ´ l’apprentissage des poids pour 6 des meilleurs (en haut) et 6 des pires (en bas) complexes de la PRIDB (meilleurs ou pires au sens du nombre de presque-natifs dans le top10) : score d’enrichissement (ES), nombre de presque-natifs dans le top10, nombre de presque-natifs attendus en moyenne par un tri aleatoire, nombre de presque- ´ natifs dans le top100, nombre de presque-natifs sur les 10 000 structures et aire sous la courbe ROC sur 10 000 candidats par pdb evalu ´ e. On peut remarquer que ´ tous ces meilleurs complexes ont plus de 1 000 presque-natifs dans les 10 000 candidats gen´ er´ es, alors que tous ces pires complexes ont moins de 1 000 presque-natifs ´ gen´ er´ es, souvent m ´ eme bien moins. ˆ Il est aussi a noter qu’il n’est pas n ` ecessaire d’avoir un maximum de presque-natifs ´ dans le top10 des candidats : un seul presque-natif suffit. De plus, ici, l’objectif est davantage de minimiser la position du premier presque-natif – idealement pour qu’il ´ soit en premiere position dans le tri – que de le placer dans le top10. En effet, plus ce ` presque-natif sera place loin dans le tri et plus il faudra tester de candidats comme point ´ de depart d’un amarrage atomique avant de pouvoir effectuer un amarrage atomique ´ 77Chapitre 4. Approche multi-echelle ´ sur le bon candidat. Lorsque l’on regarde le top100 des candidats, on peut observer que plusieurs complexes avec moins de 10 presque-natifs en ont un ou plusieurs dans le top100 (voir table 4.3). Les aires sous la courbe ROC ont alors des valeurs tres` elev ´ ees. On peut ´ donc se rendre compte que, lorsque la gen´ eration de candidats par perturbation per- ´ met de rapidement gen´ erer de nombreux candidats de I ´ RMSD proche de la solution, le protocole d’amarrage gros-grain fonctionne tres bien. Mais d ` es que les deux parte- ` naires sont de taille suffisamment elev ´ ee, la g ´ en´ eration de 10 000 candidats est insuff- ´ isante pour avoir de bonnes chances de trouver l’epitope en une dizaine de tentatives ´ d’amarrage atomique. pdb ES TOP10 Attendus TOP100 Presque-natifs ROC-AUC 1ffy 2.30 0 0.008 2 8 0.88 1ser 1.95 0 0.008 1 8 0.88 1qtq 2.05 0 0.007 3 7 0.93 1f7u 2.56 0 0.007 1 7 0.86 1qf6 2.06 0 0.005 1 5 0.85 2bte 2.46 0 0.002 1 2 0.98 TABLE 4.3 – Resultats de la fonction de score gros-grain VOR sans contrainte sur ´ l’apprentissage des poids pour 6 autres des pires complexes de la PRIDB (pires au sens du nombre de presque-natifs dans le top10), mais avec au moins un presquenatif dans le top100 : score d’enrichissement (ES), nombre de presque-natifs dans le top10, nombre de presque-natifs attendus en moyenne par un tri aleatoire, nombre de ´ presque-natifs dans le top100, nombre de presque-natifs sur les 10 000 structures et aire sous la courbe ROC sur 10 000 candidats par pdb evalu ´ e. Malgr ´ e le faible nombre ´ de presque-natifs dans les 10 000 candidats de chaque complexe, il y a tout de meme ˆ un ou plusieurs presque-natifs dans le top100 des candidats, ce qui donne de tres` bonnes ROC-AUC. 4.3.2.3 Comparaison avec contrainte a poids positifs ` La fonction de score avec contrainte a poids positifs offre des performances encore ` moins bonnes. Seulement 8 complexes ont au moins un presque-natif dans le top10 des candidats (voir table 4.4). Et seulement 35 complexes ont au moins un presquenatif dans le top100 des candidats. Nous pouvons donc voir que la contrainte de l’intervalle de valeurs des poids a` apprendre depend enti ´ erement du contexte de l’apprentissage. Les descripteurs appris ` sont ici differents du cas de l’ ´ echelle atomique et donnent tous, quelle que soit leur ´ nature, une valeur positive ou nulle. La modelisation de la fonction de score doit alors ´ prendre en compte la contrainte selon laquelle tous les poids doivent etre positifs, alors ˆ que certains termes de score ne sont pas des termes de penalisation des structures, ´ mais au contraire penchent en faveur de l’interaction. 784.3. Evaluation de l’interaction ´ a l’ ` echelle gros-grain ´ pdb ES TOP10 Attendus TOP100 Presque-natifs ROC-AUC 1gtf 1.27 7 6.307 53 6307 0.48 2a8v 0.69 5 5.018 54 5018 0.46 3d2s 1.00 5 5.557 47 5557 0.49 1sds 0.69 4 2.190 15 2190 0.52 1dfu 0.31 1 0.743 2 743 0.31 2bu1 0.35 1 1.291 4 1291 0.38 TABLE 4.4 – Resultats de la fonction de score gros-grain ´ a poids positifs pour les ` 6 meilleurs complexes de la PRIDB (au sens du nombre de presque-natifs dans le top10) : score d’enrichissement (ES), nombre de presque-natifs dans le top10, nombre de presque-natifs attendus en moyenne par un tri aleatoire, nombre de presque-natifs ´ dans le top100, nombre de presque-natifs sur les 10 000 structures et aire sous la courbe ROC sur 10 000 candidats par pdb evalu ´ e. Comme on peut le voir, les r ´ esultats ´ ne sont pas satisfaisants pour notre protocole d’amarrage gros-grain. 4.3.2.4 Comparaison avec valeurs de centrage Etant donn ´ e le comportement des structures natives par rapport aux candidats ´ gen´ er´ es, Il est l ´ egitime de penser que les presque-natifs ont une plage de valeurs ´ ideales pour au moins certains param ´ etres, au-dessus et en-dessous de laquelle se ` trouve un espace majoritairement peuple de leurres. Nous pouvons tirer parti de cette ´ repartition en plage de valeurs id ´ eales. C’est un concept qui a d ´ ej ´ a fait ses preuves, ` notamment en fouille de donnees textuelles [214], mais aussi en amarrage prot ´ eine- ´ proteine [6]. Une fonction de score non lin ´ eaire est alors compar ´ ee´ a la fonction ` de score constituee d’une combinaison lin ´ eaire des termes de score g ´ eom ´ etriques. ´ Son comportement sur un seul parametre se mod ` elise par une fonction d ´ ecroissante ´ jusqu’en 0, suivie d’une fonction croissante (voir fig. 4.16). La valeur de centrage ci indique le centre estime par la fonction de score pour la plage de valeurs id ´ eales. Le ´ poids wi mesure la vitesse a laquelle s’ ` ecarter de cette valeur de centrage p ´ enalise ´ la structure. Au lieu d’un seul poids par terme de score i, cette fonction de score non lineaire apprend donc les deux poids ´ wi et ci , calculant le score ainsi, avec les valeurs des A descripteurs de l’exemple tels que X = (x1, x2, ...x|A|) (voir eq. 4.2). ´ f(X) = X |A| i=1 wi |xi − ci | (4.2) Ce modele de fonction de score a d ` ej ´ a` et´ e pr ´ esent ´ e au chapitre 3, en section 3.1.1. ´ Son avantage pour le cas qui nous interesse est de pouvoir discriminer, pour chaque ´ descripteur, d’une part une plage de valeurs correspondant aux presque-natifs, d’autre part des valeurs correspondant aux leurres et positionnees de part et d’autre de cette ´ plage de valeurs. Remarquons que l’apprentissage des poids doit ici se faire dans l’intervalle positif au moins pour les valeurs de centrage. Une valeur de ci negative n’a ´ en effet pas de sens puisque tous les termes de score sont a valeur dans l’intervalle ` 79Chapitre 4. Approche multi-echelle ´ positif. Valeur du terme de score xi Participation yi de xi au score 0 ci 0 wi * |ci| FIGURE 4.16 – Exemple de calcul de la participation yi a un score ` y par une fonction de score avec valeurs de centrage, utilisant les poids wi et ci . Le poids ci est aussi appele´ la valeur de centrage. On peut voir que l’ordonnee´ a l’origine est ` egale ´ a` wi∗|ci |. Ce type de fonction permet de modeliser des ph ´ enom ´ enes pour lesquels une plage de valeurs ` ideales est entour ´ ee de valeurs de plus en plus ´ eloign ´ ees du crit ´ ere caract ` erisant la ´ plage de valeurs ideales. ´ Les resultats de la fonction de score avec valeurs de centrage sont moins satis- ´ faisants (voir table 4.5). Il y a 28 complexes pour lesquels au moins un presque-natif est trouve dans le top10 des candidats, et 61 complexes avec au moins un presque- ´ natif dans le top100 des candidats. La fonction de score avec valeurs de centrage est tout de meme plus performante que la fonction de score form ˆ ee d’une combinaison ´ lineaire des param ´ etres dont les poids sont restreints ` a l’intervalle de valeurs positif. ` D’autre part, on n’observe plus aucun complexe pour lesquels il existe au moins un presque-natif dans le top100 pour les complexes avec dix presque-natifs ou moins sur l’ensemble des 10 000 candidats gen´ er´ es. Cette fonction de score est donc bien moins ´ adaptee´ a la pr ` ediction d’interactions prot ´ eine-ARN que la fonction de score VOR. ´ 4.4 Conclusions sur la fonction de score gros-grain Le protocole gros-grain part de candidats gen´ er´ es al ´ eatoirement dans l’espace des ´ candidats pour essayer de trouver un candidat suffisamment proche de l’epitope pour ´ etre exploitable par le protocole atomique. Malheureusement, les performances de la ˆ fonction de score gros-grain ne remplissent pas aussi bien les objectifs fixes que pour ´ 804.4. Conclusions sur la fonction de score gros-grain pdb ES TOP10 Attendus TOP100 Presque-natifs ROC-AUC 1gtf 1.12 8 6.307 65 6307 0.51 1m8v 1.07 5 6.192 57 6192 0.49 2f8k 1.06 5 3.820 43 3820 0.49 1wsu 1.02 4 2.288 29 2288 0.51 2gxb 0.96 4 3.404 39 3404 0.49 2a8v 0.77 3 5.018 43 5018 0.49 TABLE 4.5 – Resultats de la fonction de score gros-grain avec valeurs de centrage pour ´ les 6 meilleurs complexes de la PRIDB (au sens du nombre de presque-natifs dans le top10) : score d’enrichissement (ES), nombre de presque-natifs dans le top10, nombre de presque-natifs attendus en moyenne par un tri aleatoire, nombre de presque-natifs ´ dans le top100, nombre de presque-natifs sur les 10 000 structures et aire sous la courbe ROC sur 10 000 candidats par pdb evalu ´ e. Comme on peut le voir, les r ´ esultats ´ sont meilleurs que lorsque l’on contraint un apprentissage des poids dans un intervalle de valeurs positif, mais toujours insatisfaisants pour notre protocole d’amarrage grosgrain. la fonction de score atomique. Le manque de solutions acceptables a l’ ` echelle gros- ´ grain parmi celles obtenues avec la gen´ eration de candidats par perturbation participe ´ a ce constat. G ` en´ erer plus de 10 000 candidats pourrait permettre de mieux g ´ erer ce ´ phenom ´ ene. Le second probl ` eme est le nombre de param ` etres, qui s’ ` el ´ eve ` a 210, ` alors que la fonction de score utilise moins de 2 500 candidats dans l’apprentissage. Malgre cela, m ´ eme pour des complexes avec tr ˆ es peu de solutions, on constate des ` presque-natifs dans le top100 des candidats. Nous avons cependant pu constater a nouveau qu’il est important de savoir d ` efinir ´ avec precaution l’intervalle de valeurs des poids ´ a apprendre pour la fonction de score. ` Contrairement a l’amarrage atomique, ici, il convient de ne pas contraindre l’appren- ` tissage des poids a l’intervalle de valeurs positif, au risque d’obtenir une fonction de ` score moins performante. Nous avons aussi pu tester l’apprentissage d’une fonction de score avec valeurs de centrage, qui semblait bien adaptee au ph ´ enom ´ ene de plages ` de valeurs ideales observ ´ ees pour plusieurs param ´ etres. Cette fonction de score avec ` valeurs de centrage etait tout de m ´ eme moins performante que la fonction de score ˆ par combinaison lineaire des param ´ etres. ` Nous avons aussi pu montrer que les acides amines hydrophobes participent bien ´ moins a l’interaction que les acides amin ` es hydrophiles – surtout les acides amin ´ es´ charges – contrairement ´ a ce qui est observ ` e pour les interactions prot ´ eine-prot ´ eine. ´ Les poids associes aux param ´ etres issus des volumes m ` edians montrent que la taille ´ (encombrement sterique) des acides amin ´ es et des acides nucl ´ eiques est retrouv ´ ee et ´ prise en compte dans la fonction de score gros-grain. 81Chapitre 4. Approche multi-echelle ´ 82Chapitre 5 Discussion biologique 5.1 Limites inherentes ´ a la construction de fonctions ` de score obtenues par apprentissage Les modeles de fonction de score construits pour cette ` etude sont issus d’extrac- ´ tion de connaissances a partir de donn ` ees biologiques/biophysiques exp ´ erimentales et ´ simulees. Pour donner de bons r ´ esultats, ces mod ´ eles de fonction de score n ` ecessitent ´ donc des donnees de qualit ´ e et une mod ´ elisation fiable et pr ´ ecise des objets ´ etudi ´ es. ´ Or, si la quantite relativement faible de donn ´ ees disponibles (que nous verrons en sec- ´ tion 5.1.1) sur les interactions 3D proteine-ARN incite ´ a pr ` edire ces interactions, elle ´ limite aussi les modeles pouvant ` etre construits pour pr ˆ edire ces interactions. ´ Pour eviter une sur-repr ´ esentation de complexes tr ´ es` etudi ´ es dans la PDB, il est ´ necessaire de limiter la redondance dans les jeux de donn ´ ees. Mais cela a pour ´ consequence que les quantit ´ es de donn ´ ees disponibles sont faibles voire tr ´ es faibles. ` Le manque de donnees et la diversit ´ e des r ´ esidus et bases nucl ´ eiques imposent ´ des choix de methodes d’ ´ evaluation et de traitement des valeurs manquantes, des ´ valeurs non standards et du solvant. Chacun de ces choix a un impact sur les resultats. ´ Cette partie traite de cet impact, qu’il faut avoir a l’esprit pour correctement interpr ` eter ´ les resultats. ´ 5.1.1 Une source de donnees exp ´ erimentales en constante ´ evolution ´ Nous avons pu extraire et nettoyer 120 complexes proteines-ARN de la P ´ RIDB non redondante RB199. Nous avons ensuite utilise ces 120 solutions natives pour ´ gen´ erer 10 000 candidats chacune, d’une part pour l’ ´ echelle atomique, d’autre part ´ pour l’echelle gros-grain. Pour ces 120 complexes prot ´ eine-ARN, nous avons pu mon- ´ trer que l’objectif etait rempli pour plus de 90 % d’entre eux. ´ Un nouveau jeu de donnees non redondantes de r ´ ef´ erence – RB344 – est en cours ´ de construction 8 . Il contiendra comme son nom l’indique 344 chaˆınes d’acides amines´ et palliera en partie le manque de donnees. Qu’en serait-il si nous avions dispos ´ e´ 8. http://www.pridb.gdcb.iastate.edu/download.php 83Chapitre 5. Discussion biologique de ces complexes ? Avec davantage de donnees, il serait par exemple possible d’en- ´ visager une evaluation d’interactions non prises en compte dans le mod ´ ele pr ` esent ´ e,´ notamment les interactions avec le solvant explicite qui a et´ e trait ´ e lors du nettoyage ´ des donnees. ´ 5.1.2 Influence du nettoyage des donnees ´ 5.1.2.1 Valeurs manquantes Le traitement des valeurs manquantes a ici eu pour but de minimiser l’impact des parametres inconnus et de permettre d’utiliser des techniques pour lesquelles ` l’ensemble des descripteurs doivent etre renseign ˆ es. Dans les jeux de donn ´ ees de ´ ref ´ erence, certains acides nucl ´ eiques (resp. acides amin ´ es) sont peu pr ´ esents voire ´ inexistants en interaction avec des acides amines (resp. acides nucl ´ eiques). C’est no- ´ tamment le cas de la cysteine. Pour que le mod ´ ele de fonction de score soit complet, il ` necessite tout de m ´ eme un score associ ˆ e aux interactions rarement rencontr ´ ees. Pour ´ determiner cette valeur de score, nous utilisons une m ´ ethode statistique. Une premi ´ ere ` maniere de proc ` eder serait de prendre la valeur moyenne du score pour les autres ´ acides nucleiques ou acides amin ´ es. Ceci donnerait un poids identique ´ a chaque acide ` nucleique ou amin ´ e dans la valeur du score des interactions rares ou non rencontr ´ ees. ´ Or, plusieurs acides nucleiques ou amin ´ es diff ´ erent de mani ` ere importante des autres, ` que ce soit par leur taille ou par leur charge elev ´ ee. Nous avons donc choisi une sec- ´ onde methode : la valeur m ´ ediane. Pour minimiser l’impact de ces acides amin ´ es ou ´ nucleiques au comportement diff ´ erent, nous remplac¸ons la valeur de score des inter- ´ actions rarement rencontrees par la valeur m ´ ediane des acides nucl ´ eiques ou amin ´ es´ sur l’ensemble des structures natives. La mediane de chaque param ´ etre sur les struc- ` tures natives suffit pour attribuer une valeur a chacun des 210 param ` etres. Il s’ensuit ` que les interactions rares ou non rencontrees ont une estimation impr ´ ecise de la valeur ´ de leur score, mais qui correspond au comportement d’un acide amine ou nucl ´ eique ´ type dans une veritable interaction. ´ 5.1.2.2 Acides amines et nucl ´ eiques non standards ´ Le traitement des valeurs issues des bases et residus non standards a un impact ´ sur les predictions issues du mod ´ ele. Pour d ` efinir les param ´ etres de la fonction de ` score gros-grain, les methodes utilis ´ ees mettent en œuvre des mesures statistiques ´ sur les jeux de donnees. Le principe est de faire l’hypoth ´ ese que toute nouvelle inter- ` action a pr ` edire se comportera localement pour un acide amin ´ e ou un acide nucl ´ eique ´ comme les interactions dej ´ a connues : ` – si un type d’acide amine se trouve souvent ´ a l’interaction dans les jeux de ` donnees de r ´ ef ´ erence, on aura tendance ´ a penser qu’il devrait g ` en´ eralement ´ etre ˆ a l’interaction ; ` – si un type d’atome ne se trouve quasiment jamais a moins d’une certaine dis- ` tance d’un autre type d’atome, on aura tendance a penser qu’il ne devrait pas se ` trouver plus pres d’un atome que cette distance. ` 845.1. Limites inherentes ´ a la construction de fonctions de score obtenues par apprentissage ` De plus, il arrive que les proteines et ARN en interaction contiennent des acides ´ amines ou acides nucl ´ eiques non standards, g ´ en´ erant des param ´ etres qui leur sont ` specifiques. Or, ces acides nucl ´ eiques ou amin ´ es non standards sont rencontr ´ es trop ´ rarement pour modeliser correctement leur influence sur la fonction de score. Il faut ´ alors simplifier le modele et remplacer les acides amin ` es et acides nucl ´ eiques non ´ standards par la structure chimique standard leur etant la plus proche. ´ Cette simplification du modele a peu d’incidence sur la plupart des complexes ` proteine-ARN. Il existe cependant des cas o ´ u les acides amin ` es ou nucl ´ eiques non ´ standards jouent un role d ˆ eterminant dans l’interaction. C’est le cas de certains des ´ complexes mettant en jeu la reconnaissance specifique de ces acides amin ´ es ou ´ nucleiques non standards. Pour illustration, le complexe tRNA-pseudouridine avec la ´ tRNA-pseudouridine synthase necessite la reconnaissance sp ´ ecifique du codon de la ´ pseudouridine du tRNA par la tRNA synthase. Il existe plusieurs complexes de ce type, avec differentes variantes de tRNA-pseudouridine synthase et diff ´ erents tRNA avec ´ lesquels ils doivent interagir. Pour tous ces complexes, la pseudouridine se trouve clairement a l’interface. Mais la reconnaissance n’est pas garantie lorsque la pseu- ` douridine est remplacee par l’uridine. Commenc¸ons par un exemple o ´ u le mod ` ele de ` prediction admet la reconnaissance du tRNA par la tRNA-synthase m ´ eme lorsque la ˆ pseudouridine est remplacee par l’uridine. Le complexe de code 1r3e existe chez la ´ bacterie ´ Thermotoga maritima [193]. Il represente l’interaction entre la tRNA-pseudo- ´ uridine synthase B et la tRNA-pseudouridine (voir fig. 5.1). Ici, l’interaction est correctement predite par le mod ´ ele et l’on peut facilement observer un entonnoir dans le ` diagramme d’energie en fonction du I ´ RMSD (voir fig. 5.2). Mais il est un cas, illustre´ aussi par la PRIDB, ou l’interaction mettant en œuvre des acides nucl ` eiques non stan- ´ dards n’est pas correctement predite. Ce complexe, de code PDB 1asy, est pr ´ esent ´ chez Saccharomyces cerevisiae [218]. Il s’agit de la tRNA-aspartate synthase A en interaction avec le tRNA-aspartate. Le tRNA-aspartate reconnu contient trois acides nucleiques non standards en diff ´ erents points de l’interaction, dont la pseudouridine et ´ la methylguanosine. Notamment, la tRNA-aspartate synthase doit pouvoir diff ´ erencier ´ le tRNA-aspartate d’un autre tRNA (voir fig. 5.1). L’evaluation du mod ´ ele montre que ` des candidats avec une IRMSD > 5A sont pr ˚ esents dans le top10 des candidats en ´ energie (voir fig. 5.2). La d ´ etection d’entonnoir est aussi moins claire. ´ Etant donn ´ e´ le remplacement de la pseudouridine par l’uridine et de la methylguanosine par la ´ guanine, le modele propose donc des interactions diff ` erentes : la tRNA-aspartate syn- ´ thase ne doit pas etre en interaction avec un tRNA-aspartate dans lequel les acides ˆ nucleiques non standards sont remplac ´ es par leur acide nucl ´ eique standard. ´ Certaines molecules biologiques sont aussi consid ´ er´ ees comme des h ´ et´ eroatomes ´ et sont retirees de la structure 3D. C’est notamment le cas des ATP, GTP et autres lig- ´ ands se liant aux complexes lors de mecanismes qui les mettent en jeu. C’est aussi le ´ cas par exemple de l’aspartyl-adenosine-monophosphate (AMP-ASP). Son implication ´ dans une interaction proteine-ARN est illustr ´ ee par le complexe de code 1c0a, pr ´ esent ´ dans Escherichia coli [75]. Ce complexe presente l’interaction de la tRNA-aspartate ´ synthase avec le tRNA-aspartate, mais avec la presence d’un AMP-ASP ´ a l’interaction ` (voir fig. 5.1). Le vide laisse par cet AMP-ASP n’emp ´ eche cependant pas la pr ˆ ediction ´ de l’interaction (voir fig. 5.2). 85Chapitre 5. Discussion biologique a) b) c) FIGURE 5.1 – Structure 3D de trois complexes proteine-ARN (la prot ´ eine en bleu ´ et l’ARN en orange), dans une etude de cas des acides amin ´ es et nucl ´ eiques non ´ standards, avec certains acides amines et nucl ´ eiques mis en ´ evidence (b ´ atonnets ˆ verts, rouges et blancs) : a) Le tRNA-aspartate en interaction avec la tRNA-aspartate synthase (code PDB 1c0a), ou l’interaction est mod ` elis ´ ee et pr ´ edite sans difficult ´ e.´ L’aspartyl-adenosine monophosphate est mise en ´ evidence ´ a l’interaction. b) Le tRNA- ` pseudouridine en interaction avec la tRNA-pseudouridine synthase (code PDB 1r3e), ou l’interaction est aussi correctement pr ` edite. La pseudouridine est mise en ´ evidence ´ a l’interaction. c) Le tRNA-aspartate en interaction avec la tRNA-aspartate synthase ` de la levure (de code PDB 1asy), avec plusieurs acides nucleiques non standards ´ (PSU – la pseudouridine – et 1MG – la 1N-methylguanosine) remplac ´ es par les acides ´ nucleiques standards correspondants (respectivement l’uracile et la guanine). Cette in- ´ teraction est correctement predite, malgr ´ e quelques leurres avec des scores tr ´ es bas. ` 5.1.2.3 Solvant et ions Dans les etapes de nettoyage pr ´ esent ´ ees dans ce manuscrit, le solvant et les ions ´ sont retires des structures natives. Ce traitement du solvant et des ions permet de sim- ´ plifier le modele en retirant le solvant explicite et les ions de la mod ` elisation atomique. ´ En amarrage proteine-prot ´ eine, la communaut ´ e C´ APRI a mene des ´ evaluations de ´ la prediction de la position des mol ´ ecules du solvant et certains algorithmes d’amar- ´ rage ont montre de bonnes performances dans l’affinement de la position des mol ´ ecu- ´ les d’eau [68]. Cet affinement des positions des molecules d’eau a m ´ eme permis de ˆ mieux modeliser l’interaction entre les deux partenaires. ´ Dans RosettaDock, les molecules d’eau ne sont pas prises en compte. Elles sont ´ 865.1. Limites inherentes ´ a la construction de fonctions de score obtenues par apprentissage ` 1c0a (ES = 5.89) Irmsd (Å) Score 0 20 −194 −162 0 20 1r3e (ES = 6.89) Irmsd (Å) Score 0 20 −18 3 0 20 0 1asy (ES = 3.69) Irmsd (Å) Score 0 20 176 223 0 20 FIGURE 5.2 – Diagramme d’energie en fonction du I ´ RMSD (EvsRMS) pour les trois complexes de la PRIDB utilises dans l’ ´ etude de cas des partenaires. Pour 1c0a et 1r3e, ´ la prediction de l’interaction est un succ ´ es. Pour 1asy, des am ` eliorations sont encore ´ possibles. tout simplement ignorees ´ a la lecture du fichier de structure, de m ` eme que les ions. ˆ Si l’on devait modeliser l’interaction avec le solvant, il faudrait d ´ eterminer les in- ´ teractions possibles entre chacun des partenaires et chaque molecule d’eau pouvant ´ potentiellement s’incorporer a l’interface. En effet, les mol ` ecules d’eau sont des dip ´ oles ˆ et peuvent avoir une interaction du cotˆ e des hydrog ´ enes comme du c ` otˆ e de l’oxyg ´ ene. ` D’une part, modeliser cette interaction revient ´ a traiter un cas plus complexe que le ` cas de l’interaction binaire. D’autre part, cette energie est d ´ ej ´ a partiellement prise en ` compte dans le terme de solvatation, qui calcule l’accessibilite au solvant : le solvant ´ est modelis ´ e implicitement [76, 144]. Mais la stabilit ´ e conf ´ er´ ee par l’interaction indi- ´ recte des deux partenaires par le biais de molecules d’eau n’est pas enti ´ erement prise ` en compte. C’est par exemple le cas du complexe impliquant la proteine ´ LA en interaction avec la queue 3’ terminale UUU de certains ARN lorsqu’ils sont nouvellement transcrits. C’est le complexe de code PDB 2voo pour la proteine humaine, avec pour ´ role la protection de la queue 3’terminale UUU avec laquelle la prot ˆ eine est en in- ´ teraction [139]. Dans ce complexe, l’interaction entre les deux partenaires implique de nombreuses molecules d’eau ´ a l’interface, par comparaison avec la taille de l’ARN (voir ` fig. 5.3). L’evaluation du mod ´ ele par l’EvsRMSD montre que la plupart des candidats ` de plus basse energie s’ ´ eloignent de 3 ´ a 4 ` A en I ˚ RMSD de la structure native (voir fig. 5.4. La difference est suffisante pour montrer qu’une mod ´ elisation plus fine de l’inter- ´ action avec les molecules d’eau est n ´ ecessaire, au moins pour les complexes dot ´ es´ d’un partenaire de petite taille. Un autre exemple de l’interaction avec le solvant peut etre observ ˆ e avec le com- ´ plexe de code PDB 2jlv du virus de la Dengue [169]. Dans ce complexe, la sousunite NS3 de la s ´ erine prot ´ ease du virus de la Dengue est en interaction avec un petit ´ ARN simple brin. De nombreuses molecules de solvant peuvent ´ etre observ ˆ ees en- ´ tre la sous-unite NS3 et l’ARN, allant jusqu’ ´ a quasiment entourer l’ARN (voir fig. 5.3). ` Comme on peut le voir dans le diagramme EvsRMS, l’interaction de 2jlv n’est pas 87Chapitre 5. Discussion biologique predite correctement par la fonction de score (voir fig. 5.4). ´ Le cas des ions est illustre par le complexe de code PDB 1jbs d’ ´ Aspergillus restrictus [263]. La restrictocine d’Aspergillus restrictus est en interaction avec un ARN analogue de la boucle du domaine sarcine-ricine de l’ARN 28S. Des ions potassium se trouvent en interaction avec l’ARN et l’un d’entre separe m ´ eme l’ARN de la prot ˆ eine ´ (voir fig. 5.3). La fonction de score a du mal a pr ` edire avec exactitude l’interaction entre ´ la restrictocine et cet analogue de la boucle du domaine sarcine-ricine (voir fig. 5.4). a) b) c) FIGURE 5.3 – Structure 3D de trois complexes proteine-ARN (la prot ´ eine en bleu et ´ l’ARN en orange), dans une etude de cas du solvant (sph ´ eres rouge) et des ions ` (spheres violettes) : a) La prot ` eine ´ LA en interaction avec la queue 3’ terminale UUU d’un ARN nouvellement transcrit (code PDB 2voo), avec quatre molecules d’eau as- ´ surant l’interaction entre les deux partenaires. Cette interaction est tout de meme cor- ˆ rectement predite par la fonction de score. b) La sous-unit ´ e NS3 de la s ´ erine prot ´ ease ´ du virus de la dengue en interaction avec un petit ARN simple brin (code PDB 2jlv), ou` l’interaction n’est pas predite correctement. De nombreuses mol ´ ecules de solvant sont ´ mises en evidence ´ a l’interface entre les deux partenaires. c) La restrictocine en inter- ` action avec un ARN analogue de la boucle du domaine sarcine-ricine de l’ARN 28S (code PDB 1jbs), ou l’on peut voir un ion potassium log ` e entre la prot ´ eine et l’ARN. ´ Cette interaction n’est pas correctement predite par la fonction de score. ´ 5.1.3 Influence du choix de la methode d’ ´ evaluation ´ Le leave-”one-pdb”-out peut etre vu comme une ˆ k-validation croisee avec ´ k egal ´ au nombre de structures natives et ou les exemples sont r ` epartis en une strate par ´ 885.1. Limites inherentes ´ a la construction de fonctions de score obtenues par apprentissage ` 2voo (ES = 1.69) Irmsd (Å) Score 0 20 −9 −5 0 20 2jlv (ES = 0.74) Irmsd (Å) Score 0 20 −142 −108 0 20 1jbs (ES = 0.79) Irmsd (Å) Score 0 20 −22 −12 0 20 FIGURE 5.4 – Diagramme d’energie en fonction du I ´ RMSD (EvsRMS) pour les trois complexes de la PRIDB utilises dans l’ ´ etude de cas du solvant et des ions. Pour 2voo ´ et 2jlv, la prediction de l’interaction est un succ ´ es. Pour 1jbs, des am ` eliorations sont ´ encore possibles. structure native. Chaque strate contient alors les exemples issus de la gen´ eration de ´ candidats par perturbation a partir d’une structure native donn ` ee. ´ Le leave-”one-pdb”-out est une methode permettant de se mettre en situation d’- ´ exploitation avec des donnees d’apprentissage. Plut ´ ot que d’ ˆ etre dans le cas o ˆ u l’on ` connaˆıt 120 structures natives, on considere ne conna ` ˆıtre que 119 structures natives. On rencontre alors une structure native supplementaire et l’on ´ evalue la performance ´ de la fonction de score apprise sur cette structure native. Comme il faut apprendre une fonction de score par strate, les calculs pour l’evaluation ´ des donnees sont plus co ´ uteux. Ainsi, cette m ˆ ethode d’ ´ evaluation est non seulement ´ pref ´ erable pour utiliser un maximum de donn ´ ees en apprentissage, mais son co ´ utˆ evolue aussi en ´ n 2 ou` n est le nombre de complexes proteine-ARN du jeu de donn ´ ees. ´ Ces deux constats rendent le leave-”one-pdb”-out pref´ erable ´ a utiliser sur des jeux de ` donnees de petite taille. ´ Les analyses des resultats sont plus complexes, puisque l’on ne se retrouve plus ´ avec l’evaluation d’une seule fonction de score mais avec l’ ´ evaluation de 120 fonctions ´ de score. Il faut s’assurer que les fonctions de score sont toujours comparables et verifier ´ a quel point les diff ` erentes mesures peuvent se comparer entre elles. La ROC- ´ AUC est pour cela une bonne mesure de la performance d’une fonction de score. Pour illustration, le score d’enrichissement a 10 % ne donne pas de r ` esultats satisfaisants, ´ meme pour des complexes avec lesquels le diagramme d’EvsIrmsd permet de d ˆ etecter ´ un entonnoir. Il s’agit gen´ eralement de complexes pour lesquels il y a peu de leurres. ´ C’est notamment le cas pour 1av6, 1gtf et 1vfg (voir fig. 5.5). Toutefois, les fonctions de score apprennent a discerner avec un seul en I ` RMSD < 5A un exemple des autres ˚ exemples, alors que le score d’enrichissement a 10 % s ` epare les exemples selon un ´ seuil dependant de la distribution en I ´ RMSD des exemples. 89Chapitre 5. Discussion biologique 1av6 (ES = 1.53) Irmsd (Å) Score 0 20 −4 6 0 20 1gtf (ES = 1.61) Irmsd (Å) Score 0 20 −35 −20 0 20 1vfg (ES = 0.32) Irmsd (Å) Score 0 20 58 68 0 20 FIGURE 5.5 – Diagramme d’energie en fonction du I ´ RMSD (EvsRMS) pour trois complexes de la PRIDB pour lesquels on peut observer un faible score d’enrichissement, malgre la d ´ etection d’un entonnoir. Il y a peu de leurres pour ces trois complexes, ´ compares aux autres complexes. ´ 5.2 Flexibilite´ a l’interaction ` Les molecules biologiques adoptent ´ in vivo une conformation biologiquement active. C’est cette structure 3D qui est recherchee dans les exp ´ eriences de repliement ´ et qui est utilisee par l’amarrage pour pr ´ edire la structure de l’interaction. Mais il ar- ´ rive que les structures des proteines et des ARN se d ´ eforment ´ a l’interaction. On parle ` alors de flexibilite. ´ C’est un concept qui a necessit ´ e de diff ´ erencier l’amarrage partant des structures ´ liees de l’amarrage partant des structures non li ´ ees. En effet, la pr ´ ediction de l’inter- ´ action est plus difficile avec des structures non liees qu’avec des structures li ´ ees. La ´ prediction est d’autant plus difficile que la d ´ eformation de la structure de l’un ou l’autre ´ des deux partenaires est grande a l’interface. Certaines grandes d ` eformations sont ´ modelisables lorsqu’elles mettent en jeu, notamment pour les prot ´ eines, des acides ´ amines se situant dans des boucles. ´ Il arrive aussi qu’un ARN en interaction avec une proteine ne soit compos ´ e que ´ de quelques acides nucleiques. Dans ce genre de cas, la d ´ etermination du repliement ´ de l’ARN doit se faire a la vol ` ee, directement ´ a l’interface avec la prot ` eine. Si ces ´ calculs peuvent etre co ˆ uteux pour des ARN de plusieurs dizaines ou centaines d’acides ˆ nucleiques, ils sont n ´ ecessaires pour les plus petits ARN. ´ Pour les proteines dans RosettaDock, la flexibilit ´ e´ a l’interaction est mod ` elis ´ ee´ grace ˆ a deux m ` ecanismes : ´ – la reconstruction des chaˆınes laterales des acides amin ´ es en interaction avec ´ des acides amines du partenaire ; ´ – la reconstruction du squelette des boucles en interaction avec des acides amines´ du partenaire. Pour les chaˆınes laterales, un ´ echantillonnage des diff ´ erents rotam ´ eres possibles ` est teste en ´ evaluant le score que chaque rotam ´ ere test ` e obtiendrait s’il remplac¸ait la ´ 905.3. Limites du protocole de gen´ eration des candidats ´ chaˆıne laterale existante. Un algorithme de Monte-Carlo est utilis ´ e pour choisir quel ´ rotamere doit remplacer la cha ` ˆıne laterale existante. ´ Pour les boucles, un algorithme de reconstruction de boucle est utilise : ´ Cyclic Coordinate Descent (CCD, [33]). La boucle a reconstruire est d’abord rompue pour perme- ` ttre un mouvement plus libre de ses acides amines. Puis, le squelette de chaque acide ´ amine est repositionn ´ e sans prendre en consid ´ eration sa cha ´ ˆıne laterale. Les cha ´ ˆınes laterales sont enfin reposition ´ ees et, si elles sont en interaction avec des acides amin ´ es´ du partenaire, sont reconstruites par echantillonnage des rotam ´ eres possibles, comme ` decrit au paragraphe pr ´ ec´ edent. L’algorithme CCD est utilis ´ e pour refermer la boucle. ´ L’alliance de ces deux mecanismes de reconstruction de cha ´ ˆınes laterales et de ´ boucles permet de modeliser une part importante de la flexibilit ´ e des prot ´ eines. Ces ´ mecanismes ont toutefois un co ´ ut, qui est contr ˆ ol ˆ e en ne recherchant pas de mani ´ ere ` exhaustive les meilleurs rotameres et squelettes de boucle. En effet, pour l’un comme ` pour l’autre des mecanismes, le meilleur choix, qu’il s’agisse du rotam ´ ere ou du squelette, ` depend des autres choix ´ a effectuer pour les rotam ` eres ou squelettes. Une recherche ` exhaustive impliquerait un calcul combinatoire couteux. Une heuristique est donc utilis ˆ ee. ´ Evidemment, adapter ces deux m ´ ecanismes de reconstruction au cas de l’ARN sig- ´ nifie disposer de donnees cons ´ equentes sur la flexibilit ´ e des ARN. D’une part, nous de- ´ vons disposer d’une base de donnees de rotam ´ eres pour les ARN. Il se trouve qu’une ` base de donnees de rotam ´ eres d’ARN est disponible dans les fichiers de RosettaDock. ` Cependant, nous avons pu voir en section 3.2.1 du chapitre 3 que la base de donnees ´ de rotameres des prot ` eines n’ ´ etait peut- ´ etre pas adapt ˆ ee aux interactions prot ´ eine- ´ ARN. Il n’y a donc aucune raison pour que la base de donnees de rotam ´ eres ARN ` convienne a la pr ` ediction d’interactions prot ´ eine-ARN. Cela signifie qu’il faudrait aussi ´ adapter les rotameres ARN aux interactions prot ` eine-ARN. D’autre part, la reconstruc- ´ tion des boucles a et ´ e´ evalu ´ ee pour les acides amin ´ es. Elle n ´ ecessite une fonction de ´ score dedi ´ ee pour ´ evaluer le meilleur squelette de chaque acide amin ´ e. Il faudrait donc ´ aussi adapter cette fonction de score aux interactions proteine-ARN. ´ 5.3 Limites du protocole de gen´ eration des candidats ´ Le tri des candidats d’une interaction entre macromolecules biologiques implique ´ d’avoir au prealable un ensemble de candidats g ´ en´ er´ e. Cet ensemble de candidats ´ a un impact direct sur les performances du tri. Comme on a pu le voir en section 2.4.4 du chapitre 2, un ensemble de candidats judicieusement filtre permet d’accro ´ ˆıtre considerablement les performances d’une fonction de score. Ainsi, la g ´ en´ eration des ´ candidats doit suivre certains objectifs. Le premier objectif de la gen´ eration des candidats est d’offrir un panel suffisamment ´ large et representatif de candidats pouvant raisonnablement ´ etre consid ˆ er´ es comme ´ des candidats de l’interaction : les candidats avec deux partenaires trop eloign ´ es pour ´ interagir ou avec trop d’interpen´ etration pour repr ´ esenter une interaction biologique ´ sont des leurres evidents. Cet objectif a cependant des implications s’il est rempli. Nous ´ pouvons par exemple observer pour certains des 120 complexes de la PRIDB que les 91Chapitre 5. Discussion biologique candidats gen´ er´ es sont pour plus de 99.9 % d’entre eux r ´ epartis de part et d’autre d’un ´ intervalle de plus de 1A (voir fig. 5.6). Cet ˚ etat de fait a deux cons ´ equences. ´ 1n35 (ES = 7.27) Irmsd (Å) Score 0 20 −28 −20 0 20 1tfw (ES = 4.38) Irmsd (Å) Score 0 20 −63 −49 0 20 2nug (ES = 6.56) Irmsd (Å) Score 0 20 −67 −42 0 20 FIGURE 5.6 – Diagramme d’energie en fonction du I ´ RMSD (EvsRMS) pour trois complexes de la PRIDB pour lesquels on peut observer moins de 10 candidats sur un intervalle de plus de 1 A, avec le reste des candidats se r ˚ epartissant de part et d’autre ´ de cet intervalle. Ce manque de donnees est li ´ e´ a une barri ` ere ` energ ´ etique ´ elev ´ ee´ entre les conformations des presque-natifs et celles des leurres. Tout d’abord, la quasi-absence de candidats dans cet intervalle de IRMSD empeche ˆ d’affirmer que, pour ces complexes, il est possible d’affiner une structure proche du natif. Pour tous les autres complexes ou un entonnoir est d ` etect ´ e, nous pouvons ´ aisement confirmer que l’affinement de structure est possible. Mais pour ces com- ´ plexes, comme nous ne disposons pas des candidats dans cet intervalle de IRMSD, nous ne pouvons pas affirmer qu’il n’y aura pas dans cet intervalle un saut en energie ´ empechant la formation d’un entonnoir. D’ailleurs, il y a toutes les chances que des ˆ candidats gen´ er´ es dans cet intervalle de I ´ RMSD et qui ont et´ e rejet ´ es lors de la g ´ en´ eration ´ des candidats aient eu une energie ´ elev ´ ee, notamment due ´ a une tr ` es forte contribution ` du terme de score fa rep. Ensuite, il existe une barriere ` energ ´ etique plus importante pour ces trois complexes ´ que pour les autres entre les conformations des presque-natifs et celles des leurres. Cette barriere ` energ ´ etique est principalement due ´ a l’interp ` en´ etration trop importante ´ entre les deux partenaires, pour les candidats proches des presque-natifs gen´ er´ es. Il ´ s’agit d’ailleurs essentiellement de complexes pour lesquels l’agencement des partenaires en interaction clef-serrure est particulierement marqu ` ee (voir fig. 5.7). ´ Cette distribution est liee au protocole de g ´ en´ eration des candidats par perturbation ´ en corps rigides. Lorsque les molecules sont emboit ´ ees, il n’est pas possible d’obtenir ´ un continuum de structures proches et donc un saut apparaˆıt. La fonction de score obtenue pourrait donc avoir de mediocres performances lors de l’ ´ evaluation de ce type ´ d’interface par une approche semi-flexible. 925.3. Limites du protocole de gen´ eration des candidats ´ FIGURE 5.7 – Structure 3D d’une interaction de type clef-serrure. On peut voir que la proteine (en bleu) et l’ARN (en orange) s’embo ´ ˆıtent comme le feraient une clef et une serrure. 93Chapitre 5. Discussion biologique 94Chapitre 6 Conclusion et perspectives 6.1 Integration de connaissances ´ a priori de contextes proches L’amarrage proteine-prot ´ eine nous a appris de nombreuses connaissances tou- ´ jours valables en amarrage proteine-ARN : g ´ en´ eration de donn ´ ees ´ a partir d’un jeu de ` donnees de r ´ ef ´ erence, termes de score physico-chimiques, contraintes appliqu ´ ees sur ´ les intervalles de valeurs des poids a apprendre, ` etc. Tout d’abord, nous avons montre´ que les termes de score physico-chimiques, qui ont fait leur preuve en amarrage proteine-prot ´ eine, permettent de capturer des informations d ´ ecisives dans la pr ´ ediction ´ des interactions proteine-ARN. Nous avons montr ´ e comment l’apprentissage d’une ´ fonction de score formee d’une combinaison lin ´ eaire des param ´ etres physico-chimiques ` et apprise grace ˆ a des donn ` ees de r ´ ef´ erence nettoy ´ ees permet d’atteindre l’objectif ´ fixe. Cet objectif est d ´ efini d’apr ´ es les attentes de la communaut ` e internationale de ´ l’amarrage de macromolecules biologiques, ´ a savoir pr ` edire correctement au moins ´ une structure candidate parmi les 10 meilleures proposees pour chaque interaction. ´ Nous avons pu atteindre cet objectif pour 117 des 120 complexes utilises pour l’ap- ´ prentissage de la fonction de score atomique avec ROGER. De plus, pour plus de 90 % des complexes, cette fonction de score montre des capacites´ a affiner une structure ` candidate suffisamment proche de la solution, meme ˆ a 8 ` A en I ˚ RMSD de la solution. Nous avons aussi montre que cet objectif n’aurait pas ´ et´ e atteint sans l’aide de con- ´ traintes appliquees sur les intervalles de valeurs des poids ´ a apprendre pour la fonction ` de score. Mais il reste des interactions proteine-ARN pour lesquelles les termes de ´ score physico-chimiques sont encore inefficaces, notamment pour ce qui est d’affiner une structure candidate. D’autre part, l’utilisation de ce protocole atomique necessite ´ d’avoir une idee de l’ ´ epitope pour ne pas avoir ´ a g ` en´ erer des millions de candidats. ´ Nous avons egalement ´ evalu ´ e l’utilisation de donn ´ ees telles que des informations ´ supplementaires sur le type d’ARN de chacun des complexes prot ´ eine-ARN dont l’in- ´ teraction est a pr ` edire. Nous avons propos ´ e l’apprentissage d’une fonction de score ´ dedi ´ ee´ a chaque cat ` egorie d’ARN parmi trois (ARN simple brin, ARN double brin et ´ ARN de tranfert). Les trois fonctions de score gen´ er´ ees ne montrent cependant pas ´ d’amelioration des performances. Il reste encore ´ a tester l’utilisation d’informations ` 95Chapitre 6. Conclusion et perspectives supplementaires sur les cat ´ egories de prot ´ eines. ´ 6.2 Extraction des donnees et complexit ´ es des mod ´ eles ` La modelisation de fonctions de score plus complexes qu’une combinaison lin ´ eaire ´ des termes de score physico-chimiques n’a pas permis d’obtenir davantage d’informations sur la prediction d’interactions prot ´ eine-ARN. De nombreux mod ´ eles classiques ` ont et ´ e´ etudi ´ es et il est probable qu’une ´ etude plus approfondie soit n ´ ecessaire pour ´ tirer davantage parti des informations obtenues grace aux termes de score physico- ˆ chimiques : apprentissage d’un modele bas ` e uniquement sur un sous-ensemble des ´ parametres, apprentissage d’une variable estim ` ee comme l’I ´ RMSD plutot qu’une clas- ˆ sification binaire, etc. Des modeles non lin ` eaires tels que des fonctions de score ´ avec valeurs de centrage ou l’utilisation de metaclassifieurs n’a pas non plus ap- ´ porte de gain de performance. Cependant, il reste possible que les termes de score ´ physico-chimiques aient dej ´ a fourni tout ce qu’on peut en extraire sur l’interaction. ` Pour ameliorer la pr ´ ediction, il faudrait alors repenser la mod ´ elisation de certains des ´ termes de score physico-chimiques en fonction des differents facteurs d’interaction, ´ pour les adapter aux interactions proteine-ARN. Il n’y a par exemple aucune certi- ´ tude quant au fait que les criteres de d ` ecision soient les m ´ emes pour les interactions ˆ proteine-prot ´ eine et prot ´ eine-ARN entre absence d’interaction (quand les partenaires ´ sont trop eloign ´ es), pr ´ esence d’interaction (quand les partenaires sont juste ´ a port ` ee) ´ et interpen´ etration (quand les partenaires sont trop proches l’un de l’autre). L’une des ´ ameliorations des termes de score physico-chimiques pourrait donc consister ´ a recali- ` brer les parametres propres ` a la d ` efinition de l’interaction et de l’interp ´ en´ etration pour ´ les interactions proteine-ARN. ´ Il est cependant concevable d’utiliser des fonctions de score a posteriori sur un ensemble plus restreint de candidats, notamment le top10 ou le top100 des candidats du protocole atomique. En ne triant que les meilleurs candidats, il devient possible pour les fonctions de score a posteriori de se focaliser sur la discrimination des presquenatifs au sein des candidats les plus proches d’une interaction biologique. On pourrait par exemple attendre des fonctions de score a posteriori qu’elles assurent que les presque-natifs du top10 d’un complexe aient plus de chances de se trouver parmi les premiers candidats du top10. Il serait aussi envisageable d’explorer l’hypothese ` selon laquelle ces ces fonctions de score tenteraient de retrouver les presque-natifs du top100 et absents du top10 pour les ramener dans le top10. L’etude ´ a posteriori, en n’ameliorant pas la pr ´ ediction apport ´ ee par la combinai- ´ son lineaire, nous montre l’importance d’une m ´ ethode d’apprentissage adapt ´ ee´ a la ` problematique pos ´ ee. De plus, nous avons d ´ efini comme objectif pour l’apprentis- ´ sage par ROGER la maximisation de l’aire sous la courbe ROC. Or, notre objectif veritable n’est pas de maximiser l’aire sous la courbe ROC, mais de maximiser le ´ nombre de presque-natifs dans les 10 premiers candidats du tri. Et pourtant, malgre´ cette difference entre l’objectif appris et l’objectif v ´ eritable ´ a atteindre, cet objectif ` veritable est rempli. En effet, ne pas utiliser l’objectif r ´ eel comme objectif appris est ´ un choix permettant de verifier si l’apprentissage a su retrouver les informations es- ´ 966.3. Predictions multi- ´ echelle ´ sentielles pour caracteriser les interactions. Plus que cela, les candidats de l’appren- ´ tissage etaient seulement ´ etiquet ´ es presque-natifs et leurres, ramenant l’information ´ numerique prodigu ´ ee par le I ´ RMSD a une valeur binaire. Rien n’attestait qu’un appren- ` tissage reussi permettrait d’obtenir une fonction quasi-croissante du score en fonction ´ du IRMSD. Ceci montre bien que le modele de fonction de score form ` e d’une com- ´ binaison lineaire des param ´ etres physico-chimiques a v ` eritablement pu retrouver les ´ informations determinantes pour pr ´ edire l’interaction prot ´ eine-ARN. ´ Nous avons vu par ailleurs que l’apprentissage de fonctions de score a posteriori a confirme l’importance de certains termes de score dans la description des interac- ´ tions proteine-ARN et en a r ´ ev´ el ´ e de nouveaux. En comparaison avec les interactions ´ proteine-prot ´ eine, le facteur le plus important est sans doute le terme de score des ´ forces electrostatiques. Avec une telle importance de ce facteur, une mod ´ elisation plus ´ fine des interactions electrostatiques devrait permettre de mieux mod ´ eliser l’interac- ´ tion. 6.3 Predictions multi- ´ echelle ´ Nous avons pu montrer qu’une adaptation judicieuse des recentes m ´ ethodes d’a- ´ marrage proteine-prot ´ eine permet de correctement pr ´ edire les interactions prot ´ eine- ´ ARN. La mise a contribution de termes de score g ` eom ´ etriques montre que d’autres ´ voies que celles sugger´ ees par les connaissances issues des scores physico-chimiques ´ peuvent mener a la pr ` ediction des interactions prot ´ eine-ARN. Cette vision de l’interac- ´ tion permet notamment de s’abstraire des seuils de distance utilises pour d ´ efinir si deux ´ atomes sont en interaction. Nous avons aussi pu voir que c’est une modelisation qui ´ prend mieux en compte, directement dans la representation g ´ eom ´ etrique, la flexibilit ´ e´ de l’ARN, plus accentuee que celle des prot ´ eines. ´ L’apprentissage de la fonction de score gros-grain a necessit ´ e, pour am ´ eliorer ´ les performances, de ne pas contraindre l’intervalle de valeurs des poids a appren- ` dre. Simplement contraindre l’apprentissage a l’intervalle de valeurs positif a en effet ` montre des performances d ´ egrad ´ ees. Cependant, apr ´ es une analyse d ` etaill ´ ee des ´ valeurs des parametres sur les structures natives, il peut para ` ˆıtre opportun d’imposer des intervalles de valeurs differents pour chacun des poids, en fonction de leur nature. ´ Exactement comme pour les termes de score physico-chimiques, qui ont des valeurs negatives lorsqu’elles favorisent l’interaction et positives lorsqu’elles la p ´ enalisent, ´ nous pourrions donner un poids negatif aux termes de score privil ´ egiant l’interaction et ´ positif aux termes de score la defavorisant. Cette modification du mod ´ ele de fonction ` de score gros-grain VOR pourrait certainement donner lieu a une am ` elioration de ses ´ performances. La modelisation et l’ ´ evaluation du protocole gros-grain nous a permis de mettre ´ en lumiere des connaissances nouvelles sur les interactions prot ` eine-ARN. Contraire- ´ ment aux interactions proteine-prot ´ eine, qui favorisent les acides amin ´ es hydrophobes ´ a l’interaction, ce sont les acides amin ` es hydrophiles qui sont pr ´ ef´ erentiellement en ´ interaction avec les acides amines. Nous avons aussi pu voir que, des quatre acides ´ nucleiques, c’est l’uracile qui est majoritairement pr ´ esent ´ a l’interaction. Le volume ` 97Chapitre 6. Conclusion et perspectives median des cellules de Vorono ´ ¨ı des acides amines et nucl ´ eiques a aussi permis de ´ retrouver un ordonnancement des acides amines, d’une part, et des acides nucl ´ eiques, ´ d’autre part, en fonction de leur taille (leur encombrement sterique). Les param ´ etres ` associes au volume m ´ edian permettent de mesurer l’empilement st ´ erique. ´ Nous avons enfin pu voir que l’apprentissage multi-echelle repose essentiellement ´ sur le changement de point de vue sur l’objet a apprendre et sur le changement ` d’objectif. Du point de vue de l’apprentissage, changer de point de vue correspond a changer les attributs utilis ` es, ici des termes de score. S’aider d’attributs de natures ´ differentes pour la pr ´ ediction – ici physico-chimiques et g ´ eom ´ etriques – permet de cap- ´ turer des informations sinon difficilement accessibles, potentiellement plus adaptees ´ au probleme pos ` e pour chacune des ´ echelles. Changer d’objectif pourrait revenir ´ a` changer la fonction objectif de l’apprentissage, qui a et´ e l’aire sour la courbe ROC ´ chaque fois que nous avons appris une fonction de score a l’aide de R ` OGER. Se pose alors la question de savoir si changer la fonction objectif utilisee pour l’apprentissage ´ permettrait d’ameliorer les performances de la fonction de score gros-grain. En effet, il ´ suffit qu’un seul presque-natif soit de rang le plus petit pour que la fonction de score gros-grain . Toutefois, il reste encore des voies a explorer. Le protocole propos ` e et ´ evalu ´ e dans ´ ce manuscrit est decompos ´ e en deux ´ etapes : amarrage gros-grain, puis amarrage ´ atomique. Il est toujours possible d’etudier des protocoles plus sophistiqu ´ es d’amar- ´ rage, qui permettront de traquer des epitopes potentiels, ´ a une ` echelle gros-grain, de ´ les explorer a une ` echelle atomique et de revenir ´ a l’ ` echelle gros-grain si les candidats ´ gen´ er´ es ne sont pas satisfaisants. Cet aller-retour entre amarrage gros-grain et amar- ´ rage atomique tire parti des deux perspectives et necessite d’ ´ etudier le meilleur moyen ´ de les faire communiquer dans trois buts : – minimiser le nombre d’amarrages atomiques explores ; ´ – maximiser les chances de reperer l’ ´ epitope ; ´ – maximiser les chances de trouver un presque-natif une fois l’epitope rep ´ er´ e.´ Si l’on parametre les amarrages gros-grain et atomiques pour qu’ils prennent cha- ` cun approximativement le meme temps d’ex ˆ ecution, chaque erreur de l’amarrage ´ gros-grain conduisant a un amarrage atomique inutile augmente consid ` erablement ´ les temps de calcul necessaires avant de trouver la solution. D’un autre c ´ otˆ e, si l’amar- ´ rage gros-grain ou l’amarrage atomique manquent l’interaction a son ` echelle, c’est tout ´ le protocole d’amarrage qui est compromis. Un tel protocole pourrait ben´ eficier d’une ´ fonction de score permettant de definir s’il y a ou non interaction. Jusqu’ ´ a maintenant, ` les fonctions de score definies ici se contentent de trier les candidats et de proposer les ´ meilleurs d’entre eux pour representer l’interaction, m ´ eme si l’ensemble des candidats ˆ utilises dans le tri sont des leurres ´ evidents. Or, pour juger que les candidats propos ´ es´ par un amarrage atomique sont insatisfaisants et ainsi remettre en cause une solution proposee par l’amarrage gros-grain, il est n ´ ecessaire de pouvoir rejeter un candidat ´ juge trop ´ eloign ´ e de ce que devrait ´ etre une interaction prot ˆ eine-ARN. Cela fait appel ´ a` une notion de seuil allant au-dela de l’approche par tri adopt ` ee dans ce manuscrit. La ´ fonction de tri, associee au seuil du top10 des candidats, ne fait que s ´ electionner 10 ´ candidats parmi les 10 000 gen´ er´ es et les propose dans un certain ordre. Cette fonc- ´ tion de tri n’a actuellement aucun moyen de reperer que l’un des candidats propos ´ es´ 986.3. Predictions multi- ´ echelle ´ ne devrait pas faire partie de la liste de 10 candidats. C’est donc une autre approche a mettre en œuvre, pouvant par exemple ` evaluer le nombre de leurres en queue de ´ distribution d’un tri pour s’assurer de pouvoir rejeter les candidats etant des leurres. ´ Mais ce n’est pas suffisant. Pour obtenir un seuil fixe et universel pour l’ensemble des complexes proteine-ARN, il faudrait mod ´ eliser une fonction de score dont l’amplitude ´ du score ne depend pas de la taille du complexe (en nombre d’atomes). En effet, le ´ score obtenu avec les fonctions de score present ´ ees dans ce manuscrit, utilis ´ ees dans ´ RosettaDock et dans plusieurs autres algorithmes d’amarrage, est calcule en faisant ´ une somme sur l’ensemble des atomes ou acides amines et nucl ´ eiques. Un complexe ´ de tres petite taille aura donc de grandes chances d’avoir un score de faible amplitude ` alors qu’un complexe de grande taille aura de grandes chances d’avoir un score de forte amplitude. Avec de tels ecarts entre les scores, il est impossible de fixer un seuil ´ pour l’ensemble des complexes proteine-ARN qui permette de d ´ eterminer ´ a partir de ` quand un candidat dote de ce score est n ´ ecessairement un presque-natif ou un leurre. ´ Il est donc necessaire, pour traiter du probl ´ eme de variabilit ` e du seuil, de traiter du ´ probleme de la variabilit ` e de taille des objets ´ etudi ´ es et de son impact sur le score. La ´ fonction de score gros-grain resoud en partie ce probl ´ eme, en proposant quatre types ` de parametres ind ` ependants de la taille du complexe (proportions et volumes m ´ edians ´ des acides amines et nucl ´ eiques ´ a l’interface, proportions et distances m ` edianes des ´ paires d’acides amines et nucl ´ eiques ´ a l’interface) et deux types de param ` etres qui en ` dependent (nombre d’acides amin ´ es et nucl ´ eiques ´ a l’interface). Pour cette fonction de ` score, il serait possible de se soustraire totalement de la taille du complexe en modifiant ces deux derniers types de parametres en mesurant par exemple ` a la place le ` pourcentage d’acides amines et nucl ´ eiques ´ a l’interface et la surface m ` ediane d’une ´ facette de l’interface. Il est aussi envisageable d’etudier, en fonction de la taille des ´ complexes proteine-ARN, l’ ´ evolution du nombre d’acides amin ´ es et nucl ´ eiques ´ a l’in- ` terface, pour se faire une idee de leur courbe d’ ´ evolution l’un par rapport ´ a l’autre. Cette ` courbe n’est pas necessairement lin ´ eaire et pourrait conduire ´ a dresser des cat ` egories ´ de complexes en fonction de leur taille. Plus qu’un protocole multi-echelle de pr ´ ediction d’interactions prot ´ eine-ARN, c’est ´ une approche que nous avons conc¸ue de sorte qu’elle est adaptable : d’autres protocoles d’amarrage peuvent voir le jour en adaptant cette approche a d’autres algo- ` rithmes de gen´ eration de candidats et d’autres termes de score. Et plus g ´ en´ eralement, ´ la mise au point d’une methodologie telle que le ´ leave-”one-pdb”-out peut parfaitement etre r ˆ eutilis ´ ee dans d’autes contextes informatiques. Le cadre le plus adapt ´ e au ´ leave-”one-pdb”-out est certainement la faible quantite d’instances positives connues, ´ couteuses ou rares ˆ a obtenir, pour lesquelles on souhaite apprendre, ` etant donn ´ e un ´ ensemble de parametres connus sur ces instances positives, ` a les retrouver. Il peut ` s’agir d’apprendre a les mod ` eliser pour les reproduire (commande souhait ´ ee accom- ´ plie pour la manipulation d’une interface neuronale) ou pour les eviter (accident en ´ vol pour un avion ou un drone). Cette methodologie n ´ ecessite une mani ´ ere, ` a partir ` de ces instances positives, de gen´ erer des exemples proches de ces instances pos- ´ itives et des exemples plus eloign ´ es. Elle implique aussi de disposer d’une mesure ´ de distance ou tout au moins de divergeance entre les exemples et l’instance positive dont ils sont issus. Il reste ensuite a apprendre la donn ` ee recherch ´ ee en fonction des ´ 99Chapitre 6. Conclusion et perspectives parametres connus, en veillant ` a chaque fois ` a garder pour l’ ` evaluation les exemples ´ issus d’une meme instance positive. ˆ Au-dela des protocoles d’amarrage se pose la question du filtrage collaboratif. ` Jusqu’ici, nous n’avons emis l’hypoth ´ ese d’un filtrage collaboratif que pour les ter- ` mes de score physico-chimiques et les scores issus des predictions des mod ´ eles ` a posteriori. Cependant, nous pouvons toujours etudier les filtrages collaboratifs dans le ´ cadre de l’echelle gros-grain, potentiellement en conjonction avec les termes de score ´ physico-chimiques de l’echelle gros-grain. ´ Nous avions envisage dans la section pr ´ ec´ edente une autre fac¸on de traiter l’ ´ etude ´ a posteriori, en lui donnant un but different de la pr ´ ediction par combinaison lin ´ eaire. ´ Puisqu’il s’agit d’un tri a posteriori, le tri par combinaison lineaire est d ´ ej ´ a effectu ` e´ lorsque le tri a posteriori est applique. Dans ce cas de figure, il est tout ´ a fait possible ` de n’appliquer le tri a posteriori que sur un sous-ensemble dej ´ a tri ` e des pr ´ edictions. ´ Comme le tri par combinaison lineaire remplit les objectifs fix ´ es pour presque tous les ´ complexes, il est pensable de durcir les objectifs en integrant le tri ´ a posteriori pour ne trier que les 10 ou 100 premiers candidats. De la sorte, le tri a posteriori ne traite que des candidats dej ´ a jug ` es satisfaisants et pourrait ´ etre en mesure de donner au moins ˆ un presque-natif dans les trois, quatre ou cinq premiers candidats. Si un tel objectif peut etre atteint, cela signifie qu’il est possible, toujours en proposant 10 candidats ˆ potentiels de l’interaction, de choisir des candidats representant le mieux l’interaction ´ telle qu’elle est vue par differents amarrages atomiques. Chacun de ces amarrages ´ atomiques serait initie par un candidat gros-grain diff ´ erent et ferait l’hypoth ´ ese d’un ` epitope distinct. ´ L’amarrage gros-grain tel qu’il est modelis ´ e dans ce manuscrit met en œuvre 210 ´ parametres dans sa fonction de score. De plus, 104 de ces param ` etres ont, pour la ` plupart des candidats, une valeur non attribuee et remplac ´ ee par la valeur m ´ ediane du ´ parametre sur l’ensemble des structures natives. Le premier facteur ` a l’origine de ces ` deux constatations est que nous differencions les vingt types d’acides amin ´ es et les ´ quatre types d’acides nucleiques. En effet, 208 des param ´ etres sont d ` efinis par le nom- ´ bre de types d’acides amines et d’acides nucl ´ eiques pris en compte : le nombre de cer- ´ tains de ces parametres est issu d’une addition du nombre de types d’acides amin ` es´ et du nombre de types d’acides nucleiques ; pour d’autres de ces param ´ etres, il s’agit ` d’une multiplication. Or, nous avons vu que des resultats satisfaisants en amarrage ´ proteine-prot ´ eine ont ´ et ´ e observ ´ es en regroupant les acides amin ´ es en six cat ´ egories ´ [15]. Une maniere de diminuer la complexit ` e du mod ´ ele serait donc de reprendre ces ` six categories, ramenant d’une part le nombre de param ´ etres ` a 64 et diminuant d’autre ` part le nombre de valeurs non attribuees pour chaque candidat. Confronter ce mod ´ ele` au modele` a vingt types d’acides amin ` es permettrait de savoir, dans le cas o ´ u certaines ` informations echappent au mod ´ ele` a six cat ` egories d’acides amin ´ es, si les cat ´ egories ´ d’acides amines d ´ efinies pour l’amarrage prot ´ eine-prot ´ eine peuvent ´ etre remani ˆ ees ´ pour l’amarrage proteine-ARN. Il a toutefois fallu d ´ ej ´ a disposer du protocole tel que ` nous l’avons defini jusqu’ ´ a maintenant pour pouvoir confronter ce nouveau mod ` ele de ` fonction de score a celui que nous avons ` evalu ´ e.´ Les differentes approches ´ evalu ´ ees ont donc montr ´ e que, rien qu’ ´ a partir de la ` structure 3D de chacun des deux partenaires d’un complexe et sans aucune autre 1006.3. Predictions multi- ´ echelle ´ forme de donnees, il est possible de retrouver l’interaction de ces deux partenaires. Il ´ faudra certes encore prendre en compte la flexibilite des partenaires pour v ´ eritablement ´ passer de la structure 3D de partenaires non lies – dont la structure est d ´ etermin ´ ee´ en dehors de toute interaction – a la pr ` ediction de leur interaction. Mais la rapidit ´ e´ de calculs permet desormais de se pencher sur la question de l’amarrage haut d ´ ebit. ´ La prise en compte de la flexibilite et l’accession ´ a l’amarrage haut-d ` ebit constituent ´ certainement la suite logique de ces travaux. La prediction d’interactions prot ´ eine-ARN est un domaine en plein essor, pour ´ lequel de plus en plus de defis sont relev ´ es. Cela a commenc ´ e par la pr ´ ediction d’inter- ´ actions de petites molecules, puis de mol ´ ecules de plus grandes tailles. La pr ´ ediction ´ d’interactions dans le cas ou la prot ` eine est non li ´ ee est en passe d’ ´ etre r ˆ esolue. ´ Nous devrions voir bientot des travaux traitant de la flexibilit ˆ e de l’ARN sur le point de ´ resoudre les interactions avec les deux partenaires non li ´ es. Mais ceci n ´ ecessitera pour ´ les petits ARN de savoir reconstruire l’ARN a la vol ` ee, en prenant en compte la prox- ´ imite de la prot ´ eine. Plus g ´ en´ eralement dans le domaine des interactions de macro- ´ molecules biologiques, C ´ APRI a recemment montr ´ e sa volont ´ e d’ ´ evaluer la pr ´ ediction ´ de caracteristiques sp ´ ecifiques de l’interaction, telles que la position des mol ´ ecules de ´ solvant ou l’affinite de l’interaction [68]. Avec des fonctions de score mieux adapt ´ ees ´ a l’estimation de la valeur d’une ` energie ou de l’affinit ´ e d’une interaction, il devien- ´ dra possible de passer le cap de la classification binaire. Mais de tels defis n ´ ecessitent ´ des donnees biologiques rarement disponibles en grandes quantit ´ es, et m ´ eme souvent ˆ disponibles en bien moindres quantites que les structures 3D des interactions. Il fau- ´ dra encore quelques annees avant que l’on puisse utiliser des m ´ ethodes bas ´ ees sur la ´ connaissance pour predire l’affinit ´ e de l’interaction, et encore plus pour les complexes ´ proteine-ARN. ´ 101Chapitre 6. Conclusion et perspectives 102Bibliographie [1] L. Adamian, R. Jackups, Jr, T. A. Binkowski, and J. Liang. Higher-order interhelical spatial interactions in membrane proteins. J Mol Biol, 327(1) :251–72, 2003. [2] D. W. Aha, D. Kibler, and M. K. Albert. Instance-based learning algorithms. In Machine Learning, pages 37–66, 1991. [3] B. Angelov, J. F. Sadoc, R. Jullien, A. Soyer, J. P. Mornon, and J. Chomilier. Nonatomic solvent-driven Voronoi tessellation of proteins : an open tool to analyze protein folds. Proteins, 49(4) :446–56, 2002. [4] J. C. Austin, K. R. Rodgers, and T. G. Spiro. Protein structure from ultraviolet resonance Raman spectroscopy. Methods Enzymol, 226 :374–96, 1993. [5] G. S. Ayton, W. G. Noid, and G. A. Voth. Multiscale modeling of biomolecular systems : in serial and in parallel. Curr Opin Struct Biol, 17(2) :192–198, Apr 2007. [6] J. Aze, T. Bourquard, S. Hamel, A. Poupon, and D. Ritchie. ´ Using Kendall-tau Meta-Bagging to Improve Protein-Protein Docking Predictions, volume 7036 of Lecture Notes in Computer Science, chapter 25, pages 284–295. Springer Berlin Heidelberg, 2011. [7] R. P. Bahadur, P. Chakrabarti, F. Rodier, and J. Janin. A dissection of specific and non-specific protein-protein interfaces. J Mol Biol, 336(4) :943–55, 2004. [8] D. Bakowies and W. F. Van Gunsteren. Water in protein cavities : a procedure to identify internal water and exchange pathways and application to fatty acidbinding protein. Proteins, 47(4) :534–45, 2002. [9] A. Barik, N. C., and R. P. Bahadur. A protein-RNA docking benchmark (I) : nonredundant cases. Proteins, 80(7) :1866–1871, Jul 2012. [10] E. Ben-Zeev, A. Berchanski, A. Heifetz, B. Shapira, and M. Eisenstein. Prediction of the unknown : inspiring experience with the CAPRI experiment. Proteins, 52(1) :41–6, 2003. [11] E. Ben-Zeev and M. Eisenstein. Weighted geometric docking : incorporating external information in the rotation-translation scan. Proteins, 52(1) :24–7, 2003. [12] A. Berchanski, D. Segal, and M. Eisenstein. Modeling oligomers with Cn or Dn symmetry : application to CAPRI target 10. Proteins, 60(2) :202–6, 2005. 103Bibliographie [13] H. M. Berman, T. N. Bhat, P. E. Bourne, Z. Feng, G. Gilliland, H. Weissig, and J. Westbrook. The Protein Data Bank and the challenge of structural genomics. Nat Struct Biol, 7 Suppl :957–9, 2000. [14] H. M. Berman, J. Westbrook, Z. Feng, G. Gilliland, T. N. Bhat, H. Weissig, I. N. Shindyalov, and P. E. Bourne. The Protein Data Bank. Nucleic Acids Research, 28 :235–242, 2000. [15] J. Bernauer, J. Aze, J. Janin, and A. Poupon. A new protein-protein docking scor- ´ ing function based on interface residue properties. Bioinformatics, 23(5) :555– 562, Mar 2007. [16] J. Bernauer, R. P. Bahadur, F. Rodier, J. Janin, and A. Poupon. DiMoVo : a Voronoi tessellation-based method for discriminating crystallographic and biological protein-protein interactions. Bioinformatics, 24(5) :652–658, Mar 2008. [17] J. Bernauer, X. Huang, A. Y. Sim, and M. Levitt. Fully differentiable coarsegrained and all-atom knowledge-based potentials for RNA structure evaluation. RNA, 17(6) :1066–75, 2011. [18] J. Bernauer, A. Poupon, J. Aze, and J. Janin. A docking analysis of the statistical ´ physics of protein-protein recognition. Phys Biol, 2(2) :S17–23, 2005. [19] T. A. Binkowski, L. Adamian, and J. Liang. Inferring functional relationships of proteins from local sequence and spatial surface patterns. J Mol Biol, 332(2) :505–26, 2003. [20] D. M. Blow, C. S. Wright, D. Kukla, A. Ruhlmann, W. Steigemann, and R. Huber. A model for the association of bovine pancreatic trypsin inhibitor with chymotrypsin and trypsin. J Mol Biol, 69(1) :137–44, 1972. [21] A. Bondi. Van der Waals volumes and radii. The Journal of physical chemistry, 68(3) :441–451, 1964. [22] A. J. Bordner and A. A. Gorin. Protein docking using surface matching and supervised machine learning. Proteins, 68(2) :488–502, 2007. [23] D. Bostick and I. I. Vaisman. A new topological method to measure protein structure similarity. Biochem Biophys Res Commun, 304(2) :320–5, 2003. [24] L. G. Boulu, G. M. Crippen, H. A. Barton, H. Kwon, and M. A. Marletta. Voronoi binding site model of a polycyclic aromatic hydrocarbon binding protein. J Med Chem, 33(2) :771–5, 1990. [25] P. E. Bourne. CASP and CAFASP experiments and their findings. Methods Biochem Anal, 44 :501–7, 2003. [26] T. Bourquard, J. Bernauer, J. Aze, and A. Poupon. Comparing voronoi and laguerre tessellations in the protein-protein docking context. In Voronoi Diagrams, 2009. ISVD ’09. Sixth International Symposium on, pages 225–232, 2009. [27] T. Bourquard, J. Bernauer, J. Aze, and A. Poupon. A collaborative filtering ap- ´ proach for protein-protein docking scoring functions. PLoS One, 6(4) :e18541, 2011. 104[28] M. P. Bradley and G. M. Crippen. Voronoi modeling : the binding of triazines and pyrimidines to L. casei dihydrofolate reductase. J Med Chem, 36(21) :3171–7, 1993. [29] P. Bradley, L. Malmstrom, B. Qian, J. Schonbrun, D. Chivian, D. E. Kim, J. Meiler, K. M. Misura, and D. Baker. Free modeling with Rosetta in CASP6. Proteins, 61 Suppl 7 :128–34, 2005. [30] L. Breiman. Random Forests. Eighteenth International Conference on Machine Learning, 45(1) :5–32, 2001. [31] N. Calimet, M. Schaefer, and T. Simonson. Protein molecular dynamics with the generalized Born/ACE solvent model. Proteins, 45(2) :144–58, 2001. [32] C. J. Camacho. Modeling side-chains using molecular dynamics improve recognition of binding region in CAPRI targets. Proteins, 60(2) :245–51, 2005. [33] A. A. Canutescu and R. L. Dunbrack. Cyclic coordinate descent : a robotics algorithm for protein loop closure. Protein science, 12(5) :963–972, 2003. [34] C. W. Carter, Jr, B. C. LeFebvre, S. A. Cammer, A. Tropsha, and M. H. Edgell. Four-body potentials reveal protein-specific correlations to stability changes caused by hydrophobic core mutations. J Mol Biol, 311(4) :625–38, 2001. [35] P. Carter, V. I. Lesk, S. A. Islam, and M. J. Sternberg. Protein-protein docking using 3D-Dock in rounds 3, 4, and 5 of CAPRI. Proteins, 60(2) :281–8, 2005. [36] Project CGAL. CGAL, Computational Geometry Algorithms Library, 1990. [37] S. Chakravarty, A. Bhinge, and R. Varadarajan. A procedure for detection and quantitation of cavity volumes proteins. Application to measure the strength of the hydrophobic driving force in protein folding. J Biol Chem, 277(35) :31345– 53, 2002. [38] C.-C. Chang and C.-J. Lin. LIBSVM : a library for support vector machines (version 2.31), 2001. [39] R. Chen, L. Li, and Z. Weng. ZDOCK : an initial-stage protein-docking algorithm. Proteins, 52(1) :80–7, 2003. [40] R. Chen, W. Tong, J. Mintseris, L. Li, and Z. Weng. ZDOCK predictions for the CAPRI challenge. Proteins, 52(1) :68–73, 2003. [41] R. Chen and Z. Weng. Docking unbound proteins using shape complementarity, desolvation, and electrostatics. Proteins, 47(3) :281–94, 2002. [42] R. Chen and Z. Weng. A novel shape complementarity scoring function for protein-protein docking. Proteins, 51(3) :397–408, 2003. [43] Y. Chen, T. Kortemme, T. Robertson, D. Baker, and G. Varani. A new hydrogenbonding potential for the design of protein-RNA interactions predicts specific contacts and discriminates decoys. Nucleic Acids Res, 32(17) :5147–62, 2004. [44] Y. Chen and G. Varani. Protein families and RNA recognition. FEBS J, 272(9) :2088–97, 2005. 105Bibliographie [45] Y. Chen and G. Varani. Engineering RNA-binding proteins for biology. FEBS J, 280(16) :3734–54, 2013. [46] J. Cherfils, S. Duquerroy, and J. Janin. Protein-protein recognition analyzed by docking simulation. Proteins, 11(4) :271–80, 1991. [47] C. Chothia and M. Gerstein. Protein evolution. How far can sequences diverge ? Nature, 385(6617) :579, 581, 1997. [48] C. Chothia and J. Janin. Principles of protein-protein recognition. Nature, 256(5520) :705–8, 1975. [49] A. Clery, M. Blatter, and F. H. Allain. RNA recognition motifs : boring ? Not quite. Curr Opin Struct Biol, 18(3) :290–8, 2008. [50] W. W. Cohen. Fast Effective Rule Induction. In Proceedings of the Twelfth International Conference on Machine Learning, pages 115–123. Morgan Kaufmann, 1995. [51] N. Colloc’h, C. Etchebest, E. Thoreau, B. Henrissat, and J.P. Mornon. Comparison of three algorithms for the assignment of secondary structure in proteins : the advantages of a consensus assignment. Protein Eng, 6(4) :377–82, 1993. [52] S. R. Comeau and C. J. Camacho. Predicting oligomeric assemblies : N-mers a primer. J Struct Biol, 150(3) :233–44, 2005. [53] S. R. Comeau, S. Vajda, and C. J. Camacho. Performance of the first protein docking server ClusPro in CAPRI rounds 3-5. Proteins, 60(2) :239–44, 2005. [54] M. L. Connolly. Analytical molecular surface calculation. Journal of Applied Crystallography, 16(5) :548–558, 1983. [55] M. L. Connolly. Solvent-accessible surfaces of proteins and nucleic acids. Science, 221(4612) :709–713, Aug 1983. [56] M. L. Connolly. Molecular surface triangulation. Journal of Applied Crystallography, 18(6) :499–505, 1985. [57] M. L. Connolly. Shape complementarity at the hemoglobin alpha 1 beta 1 subunit interface. Biopolymers, 25(7) :1229–47, 1986. [58] M. L. Connolly. Molecular interstitial skeleton. Computers & Chemistry, 15(1) :37–45, 1991. [59] L. L. Conte, C. Chothia, and J. Janin. The atomic structure of protein-protein recognition sites. J Mol Biol, 285(5) :2177–98, 1999. [60] T. A. Cooper, L. Wan, and G. Dreyfuss. RNA and disease. Cell, 136(4) :777–93, 2009. [61] A. Cornuiejols and L. Miclet. ´ Apprentissage Artificiel - Concepts et algorithmes. Cepadues, 2002. ´ [62] D. Cozzetto, A. Di Matteo, and A. Tramontano. Ten years of predictions... and counting. FEBS J, 272(4) :881–2, 2005. [63] G. M. Crippen. Voronoi binding site models. NIDA Res Monogr, 112 :7–20, 1991. 106[64] M. D. Daily, D. Masica, A. Sivasubramanian, S. Somarouthu, and J. J. Gray. CAPRI rounds 3-5 reveal promising successes and future challenges for RosettaDock. Proteins, 60(2) :181–6, 2005. [65] R. Das and D. Baker. Automated de novo prediction of native-like RNA tertiary structures. Proc Natl Acad Sci U S A, 104(37) :14664–9, 2007. [66] R. Das, J. Karanicolas, and D. Baker. Atomic accuracy in predicting and designing noncanonical RNA structure. Nat Methods, 7(4) :291–4, 2010. [67] S. J. de Vries, A. S. Melquiond, P. L. Kastritis, E. Karaca, A. Bordogna, M. van Dijk, J. P. Rodrigues, and A. M. Bonvin. Strengths and weaknesses of datadriven docking in critical assessment of prediction of interactions. Proteins, 78(15) :3242–9, 2010. [68] S. J. De Vries, A. D. J. van Dijk, M. Krzeminski, M. van Dijk, A. Thureau, V. Hsu, T. Wassenaar, and A. M. J. J. Bonvin. HADDOCK versus HADDOCK : new features and performance of HADDOCK2. 0 on the CAPRI targets. Proteins : structure, function, and bioinformatics, 69(4) :726–733, 2007. [69] C. Dominguez, R. Boelens, and A. M. Bonvin. HADDOCK : a protein-protein docking approach based on biochemical or biophysical information. J Am Chem Soc, 125(7) :1731–7, 2003. [70] R. L. Dunbrack, Jr and F. E. Cohen. Bayesian statistical analysis of protein sidechain rotamer preferences. Protein Sci, 6 :1661–1681, 1997. [71] F. Dupuis, J.F. Sadoc, R. Jullien, B. Angelov, and J.P. Mornon. Voro3D : 3D Voronoi tessellations applied to protein structures. Bioinformatics, 21(8) :1715– 6, 2005. [72] H. Edelsbrunner, M. Facello, and J. Liang. On the definition and the construction of pockets in macromolecules. Pac Symp Biocomput, pages 272–87, 1996. [73] H. Edelsbrunner, M. Facello, and J. Liang. On the definition and the construction of pockets in macromolecules. Discr Appl Math, 88 :83–102, 1998. [74] H. Edelsbrunner and P. Koehl. The weighted-volume derivative of a space-filling diagram. Proc Natl Acad Sci U S A, 100(5) :2203–8, 2003. [75] S. Eiler, A.-C. Dock-Bregeon, L. Moulinier, J.-C. Thierry, and D. Moras. Synthesis of aspartyl-tRNAAsp in Escherichia coli—a snapshot of the second step. The EMBO journal, 18(22) :6532–6541, 1999. [76] D. Eisenberg and A. D. McLachlan. Solvation energy in protein folding and binding. Nature, 319(6050) :199–203, 1986. [77] M. Eisenstein. Introducing a 4th dimension to protein-protein docking. Structure (Camb), 12(12) :2095–6, 2004. [78] J. J. Ellis, M. Broom, and S. Jones. Protein-RNA interactions : structural analysis and functional classes. Proteins, 66(4) :903–11, 2007. [79] J. Fernandez-Recio, R. Abagyan, and M. Totrov. Improving CAPRI predictions : ´ optimized desolvation for rigid-body docking. Proteins, 60(2) :308–13, 2005. 107Bibliographie [80] C. Ferri, P. Flach, and J. Hernandez-Orallo. Learning decision trees using the ´ area under the ROC curve. Machine Learning-International Workshop Then Conference-, pages 139–146, 2002. [81] S. Fields and O. Song. A novel genetic system to detect protein-protein interactions. Nature, 340(6230) :245–6, 1989. [82] J. L. Finney. Volume occupation, environment and accessibility in proteins. The problem of the protein surface. J Mol Biol, 96(4) :721–32, 1975. [83] D. Fischer, S. L. Lin, H. L. Wolfson, and R. Nussinov. A geometry-based suite of molecular docking processes. J Mol Biol, 248(2) :459–77, 1995. [84] D. Fischer, R. Norel, H. Wolfson, and R. Nussinov. Surface motifs by a computer vision technique : searches, detection, and implications for protein-ligand recognition. Proteins, 16(3) :278–92, 1993. [85] S. C. Flores, J. Bernauer, S. Shin, R. Zhou, and X. Huang. Multiscale modeling of macromolecular biosystems. Brief Bioinform, 13(4) :395–405, 2012. [86] E. Frank and I. H. Witten. Generating accurate rule sets without global optimization. Fifteenth International Conference on Machine Learning, 45(1) :144–151, 1998. [87] D. Frishman and P. Argos. The future of protein secondary structure prediction accuracy. Fold Des, 2(3) :159–62, 1997. [88] J. J. Fritz, A. Lewin, W. Hauswirth, A. Agarwal, M. Grant, and L. Shaw. Development of hammerhead ribozymes to modulate endogenous gene expression for functional studies. Methods, 28(2) :276–285, Oct 2002. [89] J. Furnkranz and Flach. An analysis of rule evaluation metrics. ¨ Proceedings of the Twentieth International Conference on Machine Learning (ICML-2003), Jan 2003. [90] H. H. Gan, A. Tropsha, and T. Schlick. Lattice protein folding with two and fourbody statistical potentials. Proteins, 43(2) :161–74, 2001. [91] E. J. Gardiner, P. Willett, and P. J. Artymiuk. GAPDOCK : a Genetic Algorithm Approach to Protein Docking in CAPRI round 1. Proteins, 52(1) :10–4, 2003. [92] A. C. Gavin, M. Bosche, R. Krause, P. Grandi, M. Marzioch, A. Bauer, J. Schultz, J. M. Rick, A. M. Michon, C. M. Cruciat, M. Remor, C. Hofert, M. Schelder, M. Brajenovic, H. Ruffner, A. Merino, K. Klein, M. Hudak, D. Dickson, T. Rudi, V. Gnau, A. Bauch, S. Bastuck, B. Huhse, C. Leutwein, M. A. Heurtier, R. R. Copley, A. Edelmann, E. Querfurth, V. Rybin, G. Drewes, M. Raida, T. Bouwmeester, P. Bork, B. Seraphin, B. Kuster, G. Neubauer, and G. Superti-Furga. Functional organization of the yeast proteome by systematic analysis of protein complexes. Nature, 415(6868) :141–7, 2002. [93] B. J. Gellatly and J. L. Finney. Calculation of protein volumes : an alternative to the Voronoi procedure. J Mol Biol, 161(2) :305–22, 1982. [94] M. Gerstein and C. Chothia. Packing at the protein-water interface. Proc Natl Acad Sci U S A, 93(19) :10167–72, 1996. 108[95] M. Gerstein, J. Tsai, and M. Levitt. The volume of atoms on the protein surface : calculated from simulation, using Voronoi polyhedra. J Mol Biol, 249(5) :955–66, 1995. [96] A. Goede, R. Preissner, and C. Frommel. Voronoi cell : new method for allocation ¨ of space among atoms : elimination of avoidable errors in calculation of atomic volume and density. J Comp Chem, 18(9) :1113–1123, 1997. [97] S. C. B. Gopinath. Mapping of RNA-protein interactions. Anal Chim Acta, 636(2) :117–128, Mar 2009. [98] J. J. Gray, S. Moughon, C. Wang, O. Schueler-Furman, B. Kuhlman, C. A. Rohl, and D. Baker. Protein-protein docking with simultaneous optimization of rigidbody displacement and side-chain conformations. J Mol Biol, 331(1) :281–99, 2003. [99] J. J. Gray, S. Moughon, C. Wang, O. Schueler-Furman, B. Kuhlman, C. A. Rohl, and D. Baker. Protein-protein docking with simultaneous optimization of rigidbody displacement and side-chain conformations. J Mol Biol, 331(1) :281–99, 2003. [100] J. J. Gray, S. E. Moughon, T. Kortemme, O. Schueler-Furman, K. M. Misura, A. V. Morozov, and D. Baker. Protein-protein docking predictions for the CAPRI experiment. Proteins, 52(1) :118–22, 2003. [101] A. Guilhot-Gaudeffroy, J. Aze, J. Bernauer, and C. Froidevaux. Apprentissage ´ de fonctions de tri pour la prediction d’interactions prot ´ eine-ARN. In ´ Quatorzieme conf ` erence Francophone sur l’Extraction et la Gestion des Connais- ´ sances, pages 479–484, 2014. [102] D. M. Halaby and J. P. Mornon. The immunoglobulin superfamily : an insight on its tissular, species, and functional diversity. J Mol Evol, 46(4) :389–400, 1998. [103] M. Hall, E. Frank, G. Holmes, B. Pfahringer, P. Reutemann, and I. H. Witten. The WEKA data mining software : an update. SIGKDD Explorations, 11(1) :10–18, 2009. [104] I. Halperin, B. Ma, H. Wolfson, and R. Nussinov. Principles of docking : an overview of search algorithms and a guide to scoring functions. Proteins, 47(4) :409–43, 2002. [105] Wei Han, Cheuk-Kin Wan, Fan Jiang, and Yun-Dong Wu. Pace force field for protein simulations. 1. full parameterization of version 1 and verification. Journal of Chemical Theory and Computation, 6(11) :3373–3389, 2010. [106] Wei Han, Cheuk-Kin Wan, and Yun-Dong Wu. Pace force field for protein simulations. 2. folding simulations of peptides. Journal of Chemical Theory and Computation, 6(11) :3390–3402, 2010. [107] Y. Harpaz, M. Gerstein, and C. Chothia. Volume changes on protein folding. Structure, 2(7) :641–9, 1994. [108] A. Heifetz, E. Katchalski-Katzir, and M. Eisenstein. Electrostatics in proteinprotein docking. Protein Sci, 11(3) :571–87, 2002. 109Bibliographie [109] Y. Ho, A. Gruhler, A. Heilbut, G. D. Bader, L. Moore, S. L. Adams, A. Millar, P. Taylor, K. Bennett, K. Boutilier, L. Yang, C. Wolting, I. Donaldson, S. Schandorff, J. Shewnarane, M. Vo, J. Taggart, M. Goudreault, B. Muskat, C. Alfarano, D. Dewar, Z. Lin, K. Michalickova, A. R. Willems, H. Sassi, P. A. Nielsen, K. J. Rasmussen, J. R. Andersen, L. E. Johansen, L. H. Hansen, H. Jespersen, A. Podtelejnikov, E. Nielsen, J. Crawford, V. Poulsen, B. D. Sorensen, J. Matthiesen, R. C. Hendrickson, F. Gleeson, T. Pawson, M. F. Moran, D. Durocher, M. Mann, C. W. Hogue, D. Figeys, and M. Tyers. Systematic identifi- cation of protein complexes in Saccharomyces cerevisiae by mass spectrometry. Nature, 415(6868) :180–3, 2002. [110] I. L. Hofacker. RNA secondary structure analysis using the Vienna RNA package. Curr Protoc Bioinformatics, Chapter 12 :Unit 12.2, Feb 2004. [111] G. M. Huang. High-throughput DNA sequencing : a genomic data manufacturing process. DNA Seq, 10(3) :149–53, 1999. [112] S. Y. Huang and X. Zou. A nonredundant structure dataset for benchmarking protein-RNA computational docking. J Comput Chem, 34(4) :311–8, 2013. [113] S. Y. Huang and X. Zou. A knowledge-based scoring function for protein-RNA interactions derived from a statistical mechanics-based iterative method. Nucleic Acids Res, 2014. [114] Y. Huang, S. Liu, D. Guo, L. Li, and Y. Xiao. A novel protocol for three-dimensional structure prediction of RNA-protein complexes. Scientific reports, 3, 2013. [115] Y. Inbar, D. Schneidman-Duhovny, I. Halperin, A. Oron, R. Nussinov, and H. J. Wolfson. Approaching the CAPRI challenge with an efficient geometry-based docking. Proteins, 60(2) :217–23, 2005. [116] T. Ito, K. Tashiro, S. Muta, R. Ozawa, T. Chiba, M. Nishizawa, K. Yamamoto, S. Kuhara, and Y. Sakaki. Toward a protein-protein interaction map of the budding yeast : a comprehensive system to examine two-hybrid interactions in all possible combinations between the yeast proteins. Proc Natl Acad Sci U S A, 97(3) :1143–7, 2000. [117] S. Izvekov and G. A. Voth. A multiscale coarse-graining method for biomolecular systems. J Phys Chem B, 109(7) :2469–2473, Feb 2005. [118] J. Janin. Assessing predictions of protein-protein interaction : the CAPRI experiment. Protein Sci, 14(2) :278–83, 2005. [119] J. Janin. Sailing the route from Gaeta, Italy, to CAPRI. Proteins, 60(2) :149, 2005. [120] J. Janin. The targets of CAPRI rounds 3-5. Proteins, 60(2) :170–5, 2005. [121] J. Janin. Protein-protein docking tested in blind predictions : the CAPRI experiment. Mol Biosyst, 6(12) :2351–62, 2010. [122] J. Janin, K. Henrick, J. Moult, L. T. Eyck, M. J. Sternberg, S. Vajda, I. Vakser, and S. J. Wodak. CAPRI : a Critical Assessment of PRedicted Interactions. Proteins, 52(1) :2–9, 2003. 110[123] J. Janin and B. Seraphin. Genome-wide studies of protein-protein interaction. Curr Opin Struct Biol, 13(3) :383–8, 2003. [124] J. Janin and S. J. Wodak. Reaction pathway for the quaternary structure change in hemoglobin. Biopolymers, 24(3) :509–26, 1985. [125] J. Janin and S. J. Wodak. Protein modules and protein-protein interaction. Introduction. Adv Protein Chem, 61 :1–8, 2002. [126] F. Jiang and S. H. Kim. “Soft docking” : matching of molecular surface cubes. J Mol Biol, 219(1) :79–102, 1991. [127] G. H. John and P. Langley. Estimating continuous distributions in bayesian classifiers. In Proceedings of the Eleventh Conference on Uncertainty in Artificial Intelligence, UAI’95, pages 338–345, San Francisco, CA, USA, 1995. Morgan Kaufmann Publishers Inc. [128] W. Kabsch and C. Sander. Dictionary of protein secondary structure : pattern recognition of hydrogen-bonded and geometrical features. Biopolymers, 22(12) :2577–637, 1983. [129] R. Karaduman, P. Fabrizio, K. Hartmuth, H. Urlaub, and R. Luhrmann. RNA ¨ structure and RNA-protein interactions in purified yeast u6 snRNPs. J Mol Biol, 356(5) :1248–1262, Mar 2006. [130] S. Karlin, Z. Y. Zhu, and F. Baud. Atom density in protein structures. Proc Natl Acad Sci U S A, 96(22) :12500–5, 1999. [131] S. Karlin, M. Zuker, and L. Brocchieri. Measuring residue associations in protein structures. Possible implications fro protein folding. J. Mol. Biol., 264 :121–136, 1994. [132] E. Katchalski-Katzir, I. Shariv, M. Eisenstein, A. A. Friesem, C. Aflalo, and I. A. Vakser. Molecular surface recognition : determination of geometric fit between proteins and their ligands by correlation techniques. Proc Natl Acad Sci U S A, 89(6) :2195–9, 1992. [133] A. Ke and J. A. Doudna. Crystallization of RNA and RNA-protein complexes. Methods, 34(3) :408–14, 2004. [134] J. C. Kendrew, R. E. Dickerson, B. E. Standberg, R. G. Hart, D. R. Davies, and D. C. Phillips. Structure of myoglobin. A three dimensional Fourier synthesis at 2 A resolution. ˚ Nature, 185 :422–427, 1960. [135] J. Kittler, M. Hatef, R. Duin, and J. Matas. On combining classifiers. Pattern Analysis and Machine Intelligence, IEEE Transactions on, 20(3) :226–239, 1998. [136] N. Kobayashi, T. Yamato, and N. Go. Mechanical property of a TIM-barrel protein. Proteins, 28(1) :109–16, 1997. [137] K. Komatsu, Y. Kurihara, M. Iwadate, M. Takeda-Shitaka, and H. Umeyama. Evaluation of the third solvent clusters fitting procedure for the prediction of proteinprotein interactions based on the results at the CAPRI blind docking study. Proteins, 52(1) :15–8, 2003. 111Bibliographie [138] J. Konig, K. Zarnack, N. M. Luscombe, and J. Ule. Protein-RNA interactions : new genomic technologies and perspectives. Nat Rev Genet, 13(2) :77–83, 2011. [139] O. Kotik-Kogan, E. R. Valentine, D. Sanfelice, M. R. Conte, and S. Curry. Structural analysis reveals conformational plasticity in the recognition of RNA 3’ ends by the human La protein. Structure, 16(6) :852–862, Jun 2008. [140] B. Krishnamoorthy and A. Tropsha. Development of a four-body statistical pseudo-potential to discriminate native from non-native protein conformations. Bioinformatics, 19(12) :1540–8, 2003. [141] A. Kryshtafovych, C. Venclovas, K. Fidelis, and J. Moult. Progress over the first decade of CASP experiments. Proteins, 61 Suppl 7 :225–36, 2005. [142] C. Laing and T. Schlick. Computational approaches to 3D modeling of RNA. J Phys Condens Matter, 22(28) :283101, 2010. [143] D. S. Law, L. F. Ten Eyck, O. Katzenelson, I. Tsigelny, V. A. Roberts, M. E. Pique, and J. C. Mitchell. Finding needles in haystacks : Reranking DOT results by using shape complementarity, cluster analysis, and biological information. Proteins, 52(1) :33–40, 2003. [144] T. Lazaridis and M. Karplus. Effective energy function for proteins in solution. Proteins, 35(2) :133–152, May 1999. [145] R. H. Lee and G. D. Rose. Molecular recognition. I. Automatic identification of topographic surface features. Biopolymers, 24(8) :1613–27, 1985. [146] M. F. Lensink, I. H. Moal, P. A. Bates, P. L. Kastritis, A. S. Melquiond, E. Karaca, C. Schmitz, M. van Dijk, A. M. Bonvin, M. Eisenstein, B. Jimenez-Garcia, S. Grosdidier, A. Solernou, L. Perez-Cano, C. Pallara, J. Fern ´ andez-Recio, J. Xu, ´ P. Muthu, K. Praneeth Kilambi, J. J. Gray, S. Grudinin, G. Derevyanko, J. C. Mitchell, J. Wieting, E. Kanamori, Y. Tsuchiya, Y. Murakami, J. Sarmiento, D. M. Standley, M. Shirota, K. Kinoshita, H. Nakamura, M. Chavent, D. W. Ritchie, H. Park, J. Ko, H. Lee, C. Seok, Y. Shen, D. Kozakov, S. Vajda, P. J. Kundrotas, I. A. Vakser, B. G. Pierce, H. Hwang, T. Vreven, Z. Weng, I. Buch, E. Farkash, H. J. Wolfson, M. Zacharias, S. Qin, H. X. Zhou, S. Y. Huang, X. Zou, J. A. Wojdyla, C. Kleanthous, and S. J. Wodak. Blind prediction of interfacial water positions in CAPRI. Proteins, 2013. [147] M. F. Lensink, R. Mendez, and S. J. Wodak. Docking and scoring protein com- ´ plexes : CAPRI 3rd edition. Proteins, 69(4) :704–718, Dec 2007. [148] M. F. Lensink and S. J. Wodak. Docking, scoring, and affinity prediction in CAPRI. Proteins, 81(12) :2082–95, 2013. [149] C. Levinthal, S. J. Wodak, P. Kahn, and A. K. Dadivanian. Hemoglobin interaction in sickle cell fibers. I : theoretical approaches to the molecular contacts. Proc Natl Acad Sci U S A, 72(4) :1330–4, 1975. [150] M. Levitt. A simplified representation of protein conformations for rapid simulation of protein folding. J Mol Biol, 104(1) :59–107, 1976. 112[151] M. Levitt. A simplified representation of protein conformations for rapid simulation of protein folding. J Mol Biol, 104(1) :59–107, Jun 1976. [152] B. A. Lewis, R. R. Walia, M. Terribilini, J. Ferguson, C. Zheng, V. Honavar, and D. Dobbs. PRIDB : a protein-RNA interface database. Nucleic Acids Res, 39(Database issue) :D277–D282, Jan 2011. [153] C. H. Li, L. B. Cao, J. G. Su, Y. X. Yang, and C. X. Wang. A new residuenucleotide propensity potential with structural information considered for discriminating protein-RNA docking decoys. Proteins, 80(1) :14–24, 2012. [154] L. Li, R. Chen, and Z. Weng. RDOCK : refinement of rigid-body protein docking predictions. Proteins, 53(3) :693–707, 2003. [155] W. Li, H. Yoshii, N. Hori, T. Kameda, and S. Takada. Multiscale methods for protein folding simulations. Methods, 52(1) :106–114, Sep 2010. [156] X. Li, C. Hu, and J. Liang. Simplicial edge representation of protein structures and alpha contact potential with confidence measure. Proteins, 53(4) :792–805, 2003. [157] J. Liang and K. A. Dill. Are proteins well-packed ? Biophys J, 81(2) :751–66, 2001. [158] J. Liang, H. Edelsbrunner, P. Fu, P. V. Sudhakar, and S. Subramaniam. Analytical shape computation of macromolecules : I. Molecular area and volume through alpha shape. Proteins, 33(1) :1–17, 1998. [159] J. Liang, H. Edelsbrunner, P. Fu, P. V. Sudhakar, and S. Subramaniam. Analytical shape computation of macromolecules : II. Inaccessible cavities in proteins. Proteins, 33(1) :18–29, 1998. [160] J. Liang, H. Edelsbrunner, and C. Woodward. Anatomy of protein pockets and cavities : measurement of binding site geometry and implications for ligand design. Protein Sci, 7(9) :1884–97, 1998. [161] J. Liang and S. Subramaniam. Computation of molecular electrostatics with boundary element methods. Biophys J, 73(4) :1830–41, 1997. [162] D. R. Lide. CRC handbook of chemistry and physics. CRC press, 2004. [163] S. L. Lin, R. Nussinov, D. Fischer, and H. J. Wolfson. Molecular surface representations by sparse critical points. Proteins, 18(1) :94–101, 1994. [164] C. X. Ling, J. Huang, and H. Zhang. AUC : a better measure than accuracy in comparing learning algorithms. Advances in Artificial Intelligence, Jan 2003. [165] C. X. Ling, J. Huang, and H. Zhang. AUC : a statistically consistent and more discriminating measure than accuracy. International joint Conference on artificial intelligence, pages 519–524, Jan 2003. [166] J. Lipfert and S. Doniach. Small-angle X-ray scattering from RNA, proteins, and protein complexes. Annu Rev Biophys Biomol Struct, 36 :307–27, 2007. [167] Y. Liu and J. Snoeyink. A comparison of five implementations of 3D Delaunay tessellation. Combinatorial and Computational Geometry, 52 :439–458, 2005. 113Bibliographie [168] S. Loriot, F. Cazals, and J. Bernauer. ESBTL : efficient PDB parser and data structure for the structural and geometric analysis of biological macromolecules. Bioinformatics, 26(8) :1127–1128, Apr 2010. [169] D. Luo, T. Xu, R. P. Watson, D. Scherer-Becker, A. Sampath, W. Jahnke, S. S. Yeong, C. H. Wang, S. P. Lim, A. Strongin, et al. Insights into rna unwinding and atp hydrolysis by the flavivirus ns3 protein. The EMBO journal, 27(23) :3209– 3219, 2008. [170] J. G. Mandell, V. A. Roberts, M. E. Pique, V. Kotlovyi, J. C. Mitchell, E. Nelson, I. Tsigelny, and L. F. Ten Eyck. Protein docking using continuum electrostatics and geometric fit. Protein Eng, 14(2) :105–13, 2001. [171] D. H. Mathews. Revolutions in RNA secondary structure prediction. J Mol Biol, 359(3) :526–532, Jun 2006. [172] B. J. McConkey, V. Sobolev, and M. Edelman. Quantification of protein surfaces, volumes and atom-atom contacts using a constrained Voronoi procedure. Bioinformatics, 18(10) :1365–73, 2002. [173] R. Mendez, R. Leplae, L. De Maria, and S. J. Wodak. Assessment of blind predictions of protein-protein interactions : current status of docking methods. Proteins, 52(1) :51–67, 2003. [174] R. Mendez, R. Leplae, M. F. Lensink, and S. J. Wodak. Assessment of CAPRI predictions in rounds 3-5 shows progress in docking procedures. Proteins, 60(2) :150–69, 2005. [175] E. C. Meng, B. K. Shoichet, and I. D. Kuntz. Automated docking with grid-based energy evaluation. J Comp Chem, 13 :505–524, 1992. [176] E. J. Merino, K. A. Wilkinson, J. L. Coughlan, and K. M. Weeks. RNA structure analysis at single nucleotide resolution by selective 2’-hydroxyl acylation and primer extension (shape). J Am Chem Soc, 127(12) :4223–4231, Mar 2005. [177] C. E. Metz. Basic principles of ROC analysis. Seminars in nuclear medicine, VIII(4) :283–298, Jan 1978. [178] I. Mihalek, I. Res, and O. Lichtarge. A structure and evolution-guided Monte Carlo sequence selection strategy for multiple alignment-based analysis of proteins. Bioinformatics, 22(2) :149–56, 2006. [179] M. Milek, E. Wyler, and M. Landthaler. Transcriptome-wide analysis of proteinRNA interactions using high-throughput sequencing. Semin Cell Dev Biol, 23(2) :206–12, 2012. [180] J. C. Mitchell, R. Kerr, and L. F. Ten Eyck. Rapid atomic density methods for molecular shape characterization. J Mol Graph Model, 19(3-4) :325–30, 388– 90, 2001. [181] I. S. Moreira, P. A. Fernandes, and M. J. Ramos. Protein-protein docking dealing with the unknown. J Comput Chem, 31(2) :317–42, 2010. 114[182] J. Moult, K. Fidelis, B. Rost, T. Hubbard, and A. Tramontano. Critical assessment of methods of protein structure prediction (CASP)–round 6. Proteins, 61 Suppl 7 :3–7, 2005. [183] P. J. Munson and R. K. Singh. Statistical significance of hierarchical multi-body potentials based on Delaunay tessellation and their application in sequencestructure alignment. Protein Sci, 6(7) :1467–81, 1997. [184] G. N. Murshudov, A. A. Vagin, and E. J. Dodson. Refinement of macromolecular structures by the maximum-likelihood method. Acta Crystallographica Section D : Biological Crystallography, 53(3) :240–255, 1997. [185] A. G. Murzin, S. E. Brenner, T. Hubbard, and C. Chothia. SCOP : a structural classification of proteins database for the investigation of sequences and structures. J Mol Biol, 247(4) :536–40, 1995. [186] K. Nadassy, I. Tomas-Oliveira, I. Alberts, J. Janin, and S. J. Wodak. Standard atomic volumes in double-stranded DNA and packing in protein–DNA interfaces. Nucleic Acids Res, 29(16) :3362–76, 2001. [187] K. Nadassy, S. J. Wodak, and J. Janin. Structural features of protein-nucleic acid recognition sites. Biochemistry, 38(7) :1999–2017, 1999. [188] R. Norel, D. Fischer, H. J. Wolfson, and R. Nussinov. Molecular surface recognition by a computer vision-based technique. Protein Eng, 7(1) :39–46, 1994. [189] R. Norel, S. L. Lin, H. J. Wolfson, and R. Nussinov. Molecular surface complementarity at protein-protein interfaces : the critical role played by surface normals at well placed, sparse, points in docking. J Mol Biol, 252(2) :263–73, 1995. [190] R. Norel, D. Petrey, H. J. Wolfson, and R. Nussinov. Examination of shape complementarity in docking of unbound proteins. Proteins, 36(3) :307–17, 1999. [191] C. A. Orengo, A. D. Michie, S. Jones, D. T. Jones, M. B. Swindells, and J. M. Thornton. CATH–a hierarchic classification of protein domain structures. Structure, 5(8) :1093–108, 1997. [192] E. Paci and M. Marchi. Intrinsic compressibility and volume compression in solvated proteins by molecular dynamics simulation at high pressure. Proc Natl Acad Sci U S A, 93(21) :11609–14, 1996. [193] H. Pan, S. Agarwalla, D. T. Moustakas, J. Finer-Moore, and R. M. Stroud. Structure of tRNA pseudouridine synthase TruB and its RNA complex : RNA recognition through a combination of rigid docking and induced fit. Proc Natl Acad Sci U S A, 100(22) :12648–12653, Oct 2003. [194] P. Pancoska and T. A. Keiderling. Systematic comparison of statistical analyses of electronic and vibrational circular dichroism for secondary structure prediction of selected proteins. Biochemistry, 30(28) :6885–95, 1991. [195] M. Parisien and F. Major. The MC-Fold and MC-Sym pipeline infers RNA structure from sequence data. Nature, 452(7183) :51–5, 2008. [196] L. Pauling and R. B. Corey. The pleated sheet, a new layer configuration of polypeptide chains. Proc Natl Acad Sci U S A, 37(5) :251–6, 1951. 115Bibliographie [197] L. Pauling, R. B. Corey, and H. R. Branson. The structure of proteins ; two hydrogen-bonded helical configurations of the polypeptide chain. Proc Natl Acad Sci U S A, 37(4) :205–11, 1951. [198] K. P. Peters, J. Fauck, and C. Frommel. The automatic search for ligand binding sites in proteins of known three-dimensional structure using only geometric criteria. J Mol Biol, 256(1) :201–13, 1996. [199] B. Pierce, W. Tong, and Z. Weng. M-ZDOCK : a grid-based approach for Cn symmetric multimer docking. Bioinformatics, 21(8) :1472–8, 2005. [200] H. Ponstingl, K. Henrick, and J. M. Thornton. Discriminating between homodimeric and monomeric proteins in the crystalline state. Proteins, 41(1) :47–57, 2000. [201] A. Poupon. Voronoi and Voronoi-related tessellations in studies of protein structure and interaction. Curr Opin Struct Biol, 14(2) :233–41, 2004. [202] R. Pribic, I. H. van Stokkum, D. Chapman, P. I. Haris, and M. Bloemendal. Protein secondary structure from Fourier transform infrared and/or circular dichroism spectra. Anal Biochem, 214(2) :366–78, 1993. [203] T. Puton, L. Kozlowski, I. Tuszynska, K. Rother, and J. M. Bujnicki. Computational methods for prediction of protein-RNA interactions. J Struct Biol, 179(3) :261–8, 2012. [204] L. Perez-Cano, B. Jim ´ enez-Garc ´ ´ıa, and J. Fernandez-Recio. A protein-RNA ´ docking benchmark (II) : extended set from experimental and homology modeling data. Proteins, 80(7) :1872–1882, Jul 2012. [205] L. Perez-Cano, A. Solernou, C. Pons, and J. Fern ´ andez-Recio. Structural predic- ´ tion of protein-RNA interaction by computational docking with propensity-based statistical potentials. Pac Symp Biocomput, pages 293–301, 2010. [206] M. L. Quillin and B. W. Matthews. Accurate calculation of the density of proteins. Acta Crystallogr D Biol Crystallogr, 56 (Pt 7) :791–4, 2000. [207] J. R. Quinlan. C4.5 : Programs for Machine Learning. Morgan Kaufmann Publishers Inc., San Francisco, CA, USA, 1993. [208] A. Rakotomamonjy. Optimizing area under ROC curves with SVMs. ROCAI’04, Jan 2004. [209] G. N. Ramachandran. Conformation of polypeptides and proteins. Advances in protein chemistry, 23 :283, 1968. [210] J. Reeder, M. Hochsmann, M. Rehmsmeier, B. Voss, and R. Giegerich. Beyond ¨ Mfold : recent advances in RNA bioinformatics. J Biotechnol, 124(1) :41–55, Jun 2006. [211] F. M. Richards. The interpretation of protein structures : total volume, group volume distributions and packing density. J Mol Biol, 82(1) :1–14, 1974. [212] F. M. Richards. Calculation of molecular volumes and areas for structures of known geometry. Methods Enzymol, 115 :440–64, 1985. 116[213] D. W. Ritchie. Evaluation of protein docking predictions using Hex 3.1 in CAPRI rounds 1 and 2. Proteins, 52(1) :98–106, 2003. [214] M. Roche, J. Aze, Y. Kodratoff, and M. Sebag. Learning interestingness mea- ´ sures in terminology extraction. a ROC-based approach. In Jose Hern ´ andez- ´ Orallo, Cesar Ferri, Nicolas Lachiche, and Peter A. Flach, editors, ´ ROC Analysis in Artificial Intelligence, 1st International Workshop, ROCAI-2004, Valencia, Spain, August 22, 2004, ROCAI, pages 81–88, 2004. [215] G. D. Rose, A. R. Geselowitz, G. J. Lesser, R. H. Lee, and M. H. Zehfus. Hydrophobicity of amino acid residues in globular proteins. Science, 229(4716) :834–8, 1985. [216] B. Rost, C. Sander, and R. Schneider. Redefining the goals of protein secondary structure prediction. J Mol Biol, 235(1) :13–26, 1994. [217] K. Rother, M. Rother, M. Boniecki, T. Puton, and J. M. Bujnicki. RNA and protein 3D structure modeling : similarities and differences. J Mol Model, 17(9) :2325– 36, 2011. [218] M. Ruff, S. Krishnaswamy, M. Boeglin, A. Poterszman, A. Mitschler, A. Podjarny, B. Rees, J. C. Thierry, and D. Moras. Class II aminoacyl transfer RNA synthetases : crystal structure of yeast aspartyl-tRNA synthetase complexed with tRNA (asp). Science, 252(5013) :1682–1689, 1991. [219] S. P. Ryder and S. A. Strobel. Nucleotide analog interference mapping. Methods, 18(1) :38–50, May 1999. [220] B. Sandak, R. Nussinov, and H. J. Wolfson. A method for biomolecular structural recognition and docking allowing conformational flexibility. J Comput Biol, 5(4) :631–54, 1998. [221] C. Sander and R. Schneider. Database of homology-derived protein structures and the structural meaning of sequence alignment. Proteins, 9(1) :56–68, 1991. [222] M. Schaefer, C. Bartels, F. Leclerc, and M. Karplus. Effective atom volumes for implicit solvent models : comparison between Voronoi volumes and minimum fluctuation volumes. J Comput Chem, 22(15) :1857–1879, 2001. [223] R. E. Schapire, Y. Freund, P. Bartlett, and W. S. Lee. Boosting the margin : a new explanation for the effectiveness of voting methods. The Annals of Statistics, 26(5) :1651–1686, 10 1998. [224] D. Schneidman-Duhovny, Y. Inbar, R. Nussinov, and H. J. Wolfson. Geometrybased flexible and symmetric protein docking. Proteins, 60(2) :224–31, 2005. [225] D. Schneidman-Duhovny, Y. Inbar, V. Polak, M. Shatsky, I. Halperin, H. Benyamini, A. Barzilai, O. Dror, N. Haspel, R. Nussinov, and H.J. Wolfson. Taking geometry to its edge : fast unbound rigid (and hinge-bent) docking. Proteins, 52(1) :107–12, 2003. [226] O. Schueler-Furman, C. Wang, and D. Baker. Progress in protein-protein docking : atomic resolution predictions in the CAPRI experiment using RosettaDock with an improved treatment of side-chain flexibility. Proteins, 60(2) :187–94, 2005. 117Bibliographie [227] L. G. Scott and M. Hennig. RNA structure determination by NMR. Methods Mol Biol, 452 :29–61, 2008. [228] M. Sebag, J. Aze, and N. Lucas. Impact studies and sensitivity analysis in med- ´ ical data mining with ROC-based genetic learning. In Proceedings of the Third IEEE International Conference on Data Mining, ICDM 2003, pages 637–40, Nov 2003. [229] P. Setny and M. Zacharias. A coarse-grained force field for protein-RNA docking. Nucleic Acids Res, 39(21) :9118–29, 2011. [230] B. A. Shapiro, Y. G. Yingling, W. Kasprzak, and E. Bindewald. Bridging the gap in RNA structure prediction. Curr Opin Struct Biol, 17(2) :157–165, Apr 2007. [231] Paul Sherwood, Bernard R. Brooks, and Mark S P. Sansom. Multiscale methods for macromolecular simulations. Curr Opin Struct Biol, 18(5) :630–640, Oct 2008. [232] B. K. Shoichet, I. D. Kuntz, and D. L. Bodian. Molecular docking using shape descriptors. J Comp Chem, 13 :380–397, 1992. [233] R. K. Singh, A. Tropsha, and I. I. Vaisman. Delaunay tessellation of proteins : four body nearest-neighbor propensities of amino acid residues. J Comput Biol, 3(2) :213–21, 1996. [234] G. R. Smith and M. J. Sternberg. Prediction of protein-protein interactions by docking methods. Curr Opin Struct Biol, 12(1) :28–35, 2002. [235] G. R. Smith and M. J. Sternberg. Evaluation of the 3D-Dock protein docking suite in rounds 1 and 2 of the CAPRI blind trial. Proteins, 52(1) :74–9, 2003. [236] A. Soyer, J. Chomilier, J.P. Mornon, R. Jullien, and J.F. Sadoc. Voronoi tessellation reveals the condensed matter character of folded proteins. Phys Rev Lett, 85(16) :3532–5, 2000. [237] M. L. Stolowitz. Chemical protein sequencing and amino acid analysis. Curr Opin Biotechnol, 4(1) :9–13, 1993. [238] G. Terashi, M. Takeda-Shitaka, D. Takaya, K. Komatsu, and H. Umeyama. Searching for protein-protein interaction sites and docking by the methods of molecular dynamics, grid scoring, and the pairwise interaction potential of amino acid residues. Proteins, 60(2) :289–95, 2005. [239] C. A. Theimer, N. L. Smith, and M. Khanna. NMR studies of protein-RNA interactions. Methods Mol Biol, 831 :197–218, 2012. [240] R. Thiele, R. Zimmer, and T. Lengauer. Protein threading by recursive dynamic programming. J Mol Biol, 290(3) :757–79, 1999. [241] P. Tijerina, S. Mohr, and R. Russell. DMS footprinting of structured RNAs and RNA-protein complexes. Nat Protoc, 2(10) :2608–2623, 2007. [242] V. Tozzini. Coarse-grained models for proteins. Curr Opin Struct Biol, 15(2) :144– 150, Apr 2005. [243] J. Tsai and M. Gerstein. Calculations of protein volumes : sensitivity analysis and parameter database. Bioinformatics, 18(7) :985–95, 2002. 118[244] J. Tsai, R. Taylor, C. Chothia, and M. Gerstein. The packing density in proteins : standard radii and volumes. J Mol Biol, 290(1) :253–66, 1999. [245] J. Tsai, N. Voss, and M. Gerstein. Determining the minimum number of types necessary to represent the sizes of protein atoms. Bioinformatics, 17(10) :949– 56, 2001. [246] T. D. Tullius and B. A. Dombroski. Hydroxyl radical “footprinting” : high-resolution information about DNA-protein contacts and application to lambda repressor and Cro protein. Proc Natl Acad Sci U S A, 83(15) :5469–5473, Aug 1986. [247] I. Tuszynska and J. M. Bujnicki. DARS-RNP and QUASI-RNP : new statistical potentials for protein-RNA docking. BMC Bioinformatics, 12 :348, 2011. [248] P. Uetz, L. Giot, G. Cagney, T. A. Mansfield, R. S. Judson, J. R. Knight, D. Lockshon, V. Narayan, M. Srinivasan, P. Pochart, A. Qureshi-Emili, Y. Li, B. Godwin, D. Conover, T. Kalbfleisch, G. Vijayadamodar, M. Yang, M. Johnston, S. Fields, and J. M. Rothberg. A comprehensive analysis of protein-protein interactions in Saccharomyces cerevisiae. Nature, 403(6770) :623–7, 2000. [249] I. A. Vakser and P. Kundrotas. Predicting 3D structures of protein-protein complexes. Curr Pharm Biotechnol, 9(2) :57–66, 2008. [250] A. D. van Dijk, S. J. de Vries, C. Dominguez, H. Chen, H. X. Zhou, and A. M. Bonvin. Data-driven docking : HADDOCK’s adventures in CAPRI. Proteins, 60(2) :232–8, 2005. [251] S. Viswanath, D. V. Ravikant, and R. Elber. Improving ranking of models for protein complexes with side chain modeling and atomic potentials. Proteins, 81(4) :592–606, 2013. [252] M. Vuk and T. Curk. ROC curve, lift chart and calibration plot. Metodoloski zvezki, 3(1) :89–108, Jan 2006. [253] H. Wako and T. Yamato. Novel method to detect a motif of local structures in different protein conformations. Protein Eng, 11(11) :981–90, 1998. [254] R. R. Walia, C. Caragea, B. A. Lewis, F. Towfic, M. Terribilini, Y. El-Manzalawy, D. Dobbs, and V. Honavar. Protein-RNA interface residue prediction using machine learning : an assessment of the state of the art. BMC Bioinformatics, 13 :89, 2012. [255] H. Wang. Grid-search molecular accessible surface algorithm for solving the protein docking problem. J Comp Chem, 12 :746–750, 1991. [256] L. Wernisch, M. Hunting, and S. J. Wodak. Identification of structural domains in proteins by a graph heuristic. Proteins, 35(3) :338–52, 1999. [257] K. Wiehe, B. Pierce, J. Mintseris, W. W. Tong, R. Anderson, R. Chen, and Z. Weng. ZDOCK and RDOCK performance in CAPRI rounds 3, 4, and 5. Proteins, 60(2) :207–13, 2005. [258] D. S. Wishart, B. D. Sykes, and F. M. Richards. Relationship between nuclear magnetic resonance chemical shift and protein secondary structure. J Mol Biol, 222(2) :311–33, 1991. 119Bibliographie [259] S. J. Wodak and J. Janin. Computer analysis of protein-protein interaction. J Mol Biol, 124(2) :323–42, 1978. [260] S. J. Wodak and J. Janin. Structural basis of macromolecular recognition. Adv Protein Chem, 61 :9–73, 2002. [261] S. J. Wodak and R. Mendez. Prediction of protein-protein interactions : the CAPRI experiment, its evaluation and implications. Curr Opin Struct Biol, 14(2) :242–9, 2004. [262] H. J. Wolfson and R. Nussinov. Geometrical docking algorithms. A practical approach. Methods Mol Biol, 143 :377–97, 2000. [263] X. Yang, T. Gerczei, L. Glover, and C. C. Correll. Crystal structures of ´ restrictocin–inhibitor complexes with implications for RNA recognition and base flipping. Nature Structural & Molecular Biology, 8(11) :968–973, 2001. [264] K.-D. Zachmann, W. Heiden, M. Schlenkrich, and J. Brickmann. Topological analysis of complex molecular surfaces. J Comp Chem, 13 :76–84, 1992. [265] C. Zhang, S. Liu, and Y. Zhou. Accurate and efficient loop selections by the DFIRE-based all-atom statistical potential. Protein Sci, 13(2) :391–9, 2004. [266] C. Zhang, S. Liu, and Y. Zhou. Docking prediction using biological information, ZDOCK sampling technique, and clustering guided by the DFIRE statistical energy function. Proteins, 60(2) :314–8, 2005. [267] C. Zhang, S. Liu, Q. Zhu, and Y. Zhou. A knowledge-based energy function for protein-ligand, protein-protein, and protein-DNA complexes. J Med Chem, 48(7) :2325–35, 2005. [268] J. Zhang. Protein-length distributions for the three domains of life. Trends Genet, 16(3) :107–9, 2000. [269] S. Zheng, T. A. Robertson, and G. Varani. A knowledge-based potential function predicts the specificity and relative binding energy of RNA-binding proteins. FEBS J, 274(24) :6378–91, 2007. [270] Z. H. Zhou. Towards atomic resolution structural determination by single-particle cryo-electron microscopy. Curr Opin Struct Biol, 18(2) :218–28, 2008. [271] H. Zhu, F. S. Domingues, I. Sommer, and T. Lengauer. NOXclass : prediction of protein-protein interaction types. BMC Bioinformatics, 7(1) :27, 2006. [272] X. Zhu, S. S. Ericksen, O. N. Demerdash, and J. C. Mitchell. Data-driven models for protein interaction and design. Proteins, 81(12) :2221–8, 2013. [273] R. Zimmer, M. Wohler, and R. Thiele. New scoring schemes for protein fold recognition based on Voronoi contacts. Bioinformatics, 14(3) :295–308, 1998. [274] M. Zuker. Mfold web server for nucleic acid folding and hybridization prediction. Nucleic Acids Res, 31(13) :3406–3415, Jul 2003. 120Annexes 1 # P e rt u r b at i o n . 2 −docking : d o c k p e rt 3 8 # P e rt u r b a l i t t l e the second p a rt n e r (3A, 8d ) . 3 # P repacking . 4 −docking : dock ppk f al s e # No docking prepack mode . 5 # Output . 6 −out : pdb # Output pdb f i l e . 7 −out : o v e r w r it e t rue # O v e rw r it e o ut p ut f i l e s . 8 # Docking o pt i o n s . 9 −docking : d o c k i n g c e n t r o i d o u t e r c y c l e s 0 10 −docking : d o c k i n g c e n t r o i d i n n e r c y c l e s 0 11 −docking : n o f i l t e r s t rue 12 −docking : dock mcm f al s e 13 −docking : sc min f al s e 14 −docking : dock min f al s e Listing .1 – Fichier de flags pour gen´ erer des candidats par perturbation. ´ 1 # P e rt u r b at i o n . 2 −docking : d o c k p e rt 3 8 # P e rt u r b a l i t t l e the second p a rt n e r (3A, 8d ) . 3 −docking : randomize2 # Randomize the second p a rt n e r ( p a rt n e r B ) . 4 −docking : s p i n # Spin a l i t t l e the second p a rt n e r . 5 # P repacking . 6 −docking : dock ppk t rue # Docking prepack mode . 7 # Output . 8 −out : pdb # Output pdb f i l e . 9 −out : o v e r w r it e 10 # Docking o pt i o n s . 11 −docking : d o c k i n g l o c a l r e f i n e t rue Listing .2 – Fichier de flags pour gen´ erer des candidats par amarrage atomique. ´ 1211 # P e rt u r b at i o n . 2 −docking : d o c k p e rt 3 8 # P e rt u r b a l i t t l e the second p a rt n e r (3A, 8d ) . 3 −docking : randomize2 # Randomize the second p a rt n e r ( p a rt n e r B ) . 4 −docking : s p i n # Spin a l i t t l e the second p a rt n e r . 5 # P repacking . 6 −docking : dock ppk t rue # Docking prepack mode . 7 # Output . 8 −out : pdb # Output pdb f i l e . 9 −out : o v e r w r it e 10 # Docking o pt i o n s . 11 −docking : l o w r e s p r o t o c o l o n l y # Skip high re s docking . Listing .3 – Fichier de flags pour gen´ erer des candidats par amarrage gros-grain. ´ 1 # P e rt u r b at i o n . 2 −docking : d o c k p e rt 3 8 # P e rt u r b a l i t t l e the second p a rt n e r (3A, 8d ) . 3 −docking : randomize2 # Randomize the second p a rt n e r ( p a rt n e r B ) . 4 −docking : s p i n # Spin a l i t t l e the second p a rt n e r . 5 # P repacking . 6 −docking : dock ppk t rue # Docking prepack mode . 7 # Output . 8 −out : pdb # Output pdb f i l e . 9 −out : o v e r w r it e t rue # O v e rw r it e o ut p ut f i l e s . Listing .4 – Fichier de flags pour gen´ erer des candidats par amarrage en aveugle. ´ 1221asy (ES = 3.69) Irmsd (Å) Score 0 20 176 223 Irmsd (Å) Score 0 20 −680 3420 1av6 (ES = 1.53) Irmsd (Å) Score 0 20 −4 6 Irmsd (Å) Score 0 20 −310 4560 1b23 (ES = 2.87) Irmsd (Å) Score 0 20 −134 −90 Irmsd (Å) Score 0 20 −340 3220 1c0a (ES = 5.89) Irmsd (Å) Score 0 20 −194 −162 Irmsd (Å) Score 0 20 −620 3380 1ddl (ES = 2.64) Irmsd (Å) Score 0 20 26 44 Irmsd (Å) Score 0 20 −380 1860 1dfu (ES = 5.07) Irmsd (Å) Score 0 20 −22 −7 Irmsd (Å) Score 0 20 −120 3500 1di2 (ES = 4.05) Irmsd (Å) Score 0 20 −14 −2 Irmsd (Å) Score 0 20 −160 2800 1e8o (ES = 2.08) Irmsd (Å) Score 0 20 −11 −5 Irmsd (Å) Score 0 20 −140 3830 1f7u (ES = 4.46) Irmsd (Å) Score 0 20 −237 −191 Irmsd (Å) Score 0 20 −700 3960 FIGURE S1 – Diagramme par complexe de l’energie en fonction du I ´ RMSD (EvsRMS). Chaque candidat est positionne (par une croix) sur le diagramme selon son ´ energie ´ et son IRMSD. Les 10 premiers candidats en energie sont indiqu ´ es comme presque- ´ natifs (en bleu) ou leurres (en rouge). La fonction de score utilisee est celle apprise ´ par ROGER en leave-”one-pdb”-out pour les grands diagrammes et celle disponible par defaut dans RosettaDock dans les encarts en bas ´ a droite de chaque diagramme ` (candidats indiques en gris). ´ 1231feu (ES = 1.72) Irmsd (Å) Score 0 20 −78 −48 Irmsd (Å) Score 0 20 −200 3350 1ffy (ES = 7.09) Irmsd (Å) Score 0 20 −69 −47 Irmsd (Å) Score 0 20 −750 5130 1fxl (ES = 6.26) Irmsd (Å) Score 0 20 −7 2 Irmsd (Å) Score 0 20 −140 3330 1gtf (ES = 1.61) Irmsd (Å) Score 0 20 −35 −20 Irmsd (Å) Score 0 20 −140 5060 1h3e (ES = 5.02) Irmsd (Å) Score 0 20 −18 −5 Irmsd (Å) Score 0 20 −250 4130 1h4s (ES = 1.9) Irmsd (Å) Score 0 20 −326 −287 Irmsd (Å) Score 0 20 −1060 4100 1hq1 (ES = 2.42) Irmsd (Å) Score 0 20 −30 −17 Irmsd (Å) Score 0 20 −110 4770 1j1u (ES = 1.4) Irmsd (Å) Score 0 20 −35 −29 Irmsd (Å) Score 0 20 −370 3270 1j2b (ES = 6.25) Irmsd (Å) Score 0 20 91 110 Irmsd (Å) Score 0 20 −660 5460 FIGURE S1 (cont.) – Diagramme par complexe de l’energie en fonction du I ´ RMSD (EvsRMS). Chaque candidat est positionne (par une croix) sur le diagramme selon son ´ energie et son I ´ RMSD. Les 10 premiers candidats en energie sont indiqu ´ es comme ´ presque-natifs (en bleu) ou leurres (en rouge). La fonction de score utilisee est celle ´ apprise par ROGER en leave-”one-pdb”-out pour les grands diagrammes et celle disponible par defaut dans RosettaDock dans les encarts en bas ´ a droite de chaque ` diagramme (candidats indiques en gris). ´ 1241jbs (ES = 0.79) Irmsd (Å) Score 0 20 −22 −12 Irmsd (Å) Score 0 20 −150 5310 1jid (ES = 0.05) Irmsd (Å) Score 0 20 −14 −9 Irmsd (Å) Score 0 20 −150 4350 1k8w (ES = 7.73) Irmsd (Å) Score 0 20 −31 −20 Irmsd (Å) Score 0 20 −320 3300 1knz (ES = 5.68) Irmsd (Å) Score 0 20 −25 −17 Irmsd (Å) Score 0 20 −210 2980 1lng (ES = 3.91) Irmsd (Å) Score 0 20 −41 −26 Irmsd (Å) Score 0 20 −140 5170 1m8v (ES = 1.7) Irmsd (Å) Score 0 20 −2 5 Irmsd (Å) Score 0 20 −60 2610 1m8x (ES = 4.61) Irmsd (Å) Score 0 20 −10 2 Irmsd (Å) Score 0 20 −350 4470 1mzp (ES = 3.15) Irmsd (Å) Score 0 20 −107 −69 Irmsd (Å) Score 0 20 −240 5100 1n35 (ES = 7.27) Irmsd (Å) Score 0 20 −28 −20 Irmsd (Å) Score 0 20 −1190 4730 FIGURE S1 (cont.) – Diagramme par complexe de l’energie en fonction du I ´ RMSD (EvsRMS). Chaque candidat est positionne (par une croix) sur le diagramme selon son ´ energie et son I ´ RMSD. Les 10 premiers candidats en energie sont indiqu ´ es comme ´ presque-natifs (en bleu) ou leurres (en rouge). La fonction de score utilisee est celle ´ apprise par ROGER en leave-”one-pdb”-out pour les grands diagrammes et celle disponible par defaut dans RosettaDock dans les encarts en bas ´ a droite de chaque ` diagramme (candidats indiques en gris). ´ 1251n78 (ES = 3.67) Irmsd (Å) Score 0 20 −234 −191 Irmsd (Å) Score 0 20 −530 3400 1ooa (ES = 2.56) Irmsd (Å) Score 0 20 −8 4 Irmsd (Å) Score 0 20 −260 5530 1pgl (ES = 0) Irmsd (Å) Score 0 20 −48 −31 Irmsd (Å) Score 0 20 −470 2510 1q2r (ES = 6.33) Irmsd (Å) Score 0 20 −92 −80 Irmsd (Å) Score 0 20 −770 3560 1qf6 (ES = 7.3) Irmsd (Å) Score 0 20 −32 −17 Irmsd (Å) Score 0 20 −600 4320 1qtq (ES = 6.36) Irmsd (Å) Score 0 20 −29 −12 Irmsd (Å) Score 0 20 −550 4830 1r3e (ES = 6.89) Irmsd (Å) Score 0 20 −18 3 Irmsd (Å) Score 0 20 −260 4080 1r9f (ES = 3.19) Irmsd (Å) Score 0 20 −30 −18 Irmsd (Å) Score 0 20 −170 2790 1sds (ES = 1.51) Irmsd (Å) Score 0 20 −5 3 Irmsd (Å) Score 0 20 −120 4170 FIGURE S1 (cont.) – Diagramme par complexe de l’energie en fonction du I ´ RMSD (EvsRMS). Chaque candidat est positionne (par une croix) sur le diagramme selon son ´ energie et son I ´ RMSD. Les 10 premiers candidats en energie sont indiqu ´ es comme ´ presque-natifs (en bleu) ou leurres (en rouge). La fonction de score utilisee est celle ´ apprise par ROGER en leave-”one-pdb”-out pour les grands diagrammes et celle disponible par defaut dans RosettaDock dans les encarts en bas ´ a droite de chaque ` diagramme (candidats indiques en gris). ´ 1261ser (ES = 4.35) Irmsd (Å) Score 0 20 −65 −48 Irmsd (Å) Score 0 20 −760 3310 1si3 (ES = 4.66) Irmsd (Å) Score 0 20 1 11 Irmsd (Å) Score 0 20 −90 4940 1t0k (ES = 1.34) Irmsd (Å) Score 0 20 21 34 Irmsd (Å) Score 0 20 −410 5520 1tfw (ES = 4.38) Irmsd (Å) Score 0 20 −63 −49 Irmsd (Å) Score 0 20 −930 5030 1u0b (ES = 6.33) Irmsd (Å) Score 0 20 −219 −154 Irmsd (Å) Score 0 20 −490 4940 1un6 (ES = 2.93) Irmsd (Å) Score 0 20 −150 −87 Irmsd (Å) Score 0 20 −120 4350 1uvj (ES = 3.2) Irmsd (Å) Score 0 20 −44 −37 Irmsd (Å) Score 0 20 −670 2080 1vfg (ES = 0.32) Irmsd (Å) Score 0 20 58 68 Irmsd (Å) Score 0 20 −130 2740 1wpu (ES = 3.48) Irmsd (Å) Score 0 20 −8 −3 Irmsd (Å) Score 0 20 −150 3320 FIGURE S1 (cont.) – Diagramme par complexe de l’energie en fonction du I ´ RMSD (EvsRMS). Chaque candidat est positionne (par une croix) sur le diagramme selon son ´ energie et son I ´ RMSD. Les 10 premiers candidats en energie sont indiqu ´ es comme ´ presque-natifs (en bleu) ou leurres (en rouge). La fonction de score utilisee est celle ´ apprise par ROGER en leave-”one-pdb”-out pour les grands diagrammes et celle disponible par defaut dans RosettaDock dans les encarts en bas ´ a droite de chaque ` diagramme (candidats indiques en gris). ´ 1271wsu (ES = 1.72) Irmsd (Å) Score 0 20 −6 4 Irmsd (Å) Score 0 20 −150 3870 1wz2 (ES = 5.18) Irmsd (Å) Score 0 20 43 57 Irmsd (Å) Score 0 20 −380 5450 1yvp (ES = 2.69) Irmsd (Å) Score 0 20 −14 −5 Irmsd (Å) Score 0 20 −510 3730 1zbh (ES = 1.74) Irmsd (Å) Score 0 20 −26 −12 Irmsd (Å) Score 0 20 −220 4350 2a8v (ES = 2.2) Irmsd (Å) Score 0 20 −3 0 Irmsd (Å) Score 0 20 −100 1840 2anr (ES = 2.06) Irmsd (Å) Score 0 20 15 25 Irmsd (Å) Score 0 20 −140 2160 2asb (ES = 5.26) Irmsd (Å) Score 0 20 −33 −22 Irmsd (Å) Score 0 20 −160 3430 2az0 (ES = 4.33) Irmsd (Å) Score 0 20 −20 −7 Irmsd (Å) Score 0 20 −170 4540 2azx (ES = 2.29) Irmsd (Å) Score 0 20 −50 −43 Irmsd (Å) Score 0 20 −770 4220 FIGURE S1 (cont.) – Diagramme par complexe de l’energie en fonction du I ´ RMSD (EvsRMS). Chaque candidat est positionne (par une croix) sur le diagramme selon son ´ energie et son I ´ RMSD. Les 10 premiers candidats en energie sont indiqu ´ es comme ´ presque-natifs (en bleu) ou leurres (en rouge). La fonction de score utilisee est celle ´ apprise par ROGER en leave-”one-pdb”-out pour les grands diagrammes et celle disponible par defaut dans RosettaDock dans les encarts en bas ´ a droite de chaque ` diagramme (candidats indiques en gris). ´ 1282b3j (ES = 3.18) Irmsd (Å) Score 0 20 −171 −135 Irmsd (Å) Score 0 20 −330 3020 2bgg (ES = 4.89) Irmsd (Å) Score 0 20 −5 7 Irmsd (Å) Score 0 20 −400 2820 2bh2 (ES = 7.08) Irmsd (Å) Score 0 20 −20 −6 Irmsd (Å) Score 0 20 −390 3620 2bte (ES = 2.15) Irmsd (Å) Score 0 20 −164 −139 Irmsd (Å) Score 0 20 −810 2290 2bu1 (ES = 2.41) Irmsd (Å) Score 0 20 −9 0 Irmsd (Å) Score 0 20 −110 4340 2bx2 (ES = 2.08) Irmsd (Å) Score 0 20 2 12 Irmsd (Å) Score 0 20 −250 1840 2ct8 (ES = 3.09) Irmsd (Å) Score 0 20 −295 −235 Irmsd (Å) Score 0 20 −440 2770 2czj (ES = 3.51) Irmsd (Å) Score 0 20 0 9 Irmsd (Å) Score 0 20 −20 4190 2d6f (ES = 2.75) Irmsd (Å) Score 0 20 6 17 Irmsd (Å) Score 0 20 −290 3700 FIGURE S1 (cont.) – Diagramme par complexe de l’energie en fonction du I ´ RMSD (EvsRMS). Chaque candidat est positionne (par une croix) sur le diagramme selon son ´ energie et son I ´ RMSD. Les 10 premiers candidats en energie sont indiqu ´ es comme ´ presque-natifs (en bleu) ou leurres (en rouge). La fonction de score utilisee est celle ´ apprise par ROGER en leave-”one-pdb”-out pour les grands diagrammes et celle disponible par defaut dans RosettaDock dans les encarts en bas ´ a droite de chaque ` diagramme (candidats indiques en gris). ´ 1292der (ES = 4.52) Irmsd (Å) Score 0 20 −23 −13 Irmsd (Å) Score 0 20 −250 3190 2du3 (ES = 2.11) Irmsd (Å) Score 0 20 −52 −42 Irmsd (Å) Score 0 20 −850 4130 2e9t (ES = 7.7) Irmsd (Å) Score 0 20 −31 −15 Irmsd (Å) Score 0 20 −430 4360 2f8k (ES = 1.47) Irmsd (Å) Score 0 20 −7 −2 Irmsd (Å) Score 0 20 −110 4840 2f8s (ES = 2.19) Irmsd (Å) Score 0 20 −13 −5 Irmsd (Å) Score 0 20 −530 1560 2fk6 (ES = 2.93) Irmsd (Å) Score 0 20 −26 −16 Irmsd (Å) Score 0 20 −270 2750 2fmt (ES = 5.99) Irmsd (Å) Score 0 20 −12 2 Irmsd (Å) Score 0 20 −290 3400 2gic (ES = 3.06) Irmsd (Å) Score 0 20 7 12 Irmsd (Å) Score 0 20 −260 2830 2gje (ES = 2.6) Irmsd (Å) Score 0 20 −3 7 Irmsd (Å) Score 0 20 −150 5750 FIGURE S1 (cont.) – Diagramme par complexe de l’energie en fonction du I ´ RMSD (EvsRMS). Chaque candidat est positionne (par une croix) sur le diagramme selon son ´ energie et son I ´ RMSD. Les 10 premiers candidats en energie sont indiqu ´ es comme ´ presque-natifs (en bleu) ou leurres (en rouge). La fonction de score utilisee est celle ´ apprise par ROGER en leave-”one-pdb”-out pour les grands diagrammes et celle disponible par defaut dans RosettaDock dans les encarts en bas ´ a droite de chaque ` diagramme (candidats indiques en gris). ´ 1302gjw (ES = 4.25) Irmsd (Å) Score 0 20 −7 4 Irmsd (Å) Score 0 20 −470 5040 2gtt (ES = 3.38) Irmsd (Å) Score 0 20 19 26 Irmsd (Å) Score 0 20 −210 5000 2gxb (ES = 1.87) Irmsd (Å) Score 0 20 −60 −23 Irmsd (Å) Score 0 20 −70 3040 2hw8 (ES = 3.72) Irmsd (Å) Score 0 20 −45 −27 Irmsd (Å) Score 0 20 −240 4120 2i82 (ES = 7.14) Irmsd (Å) Score 0 20 −44 −26 Irmsd (Å) Score 0 20 −210 5770 2iy5 (ES = 6.69) Irmsd (Å) Score 0 20 22 35 Irmsd (Å) Score 0 20 −810 5720 2jlv (ES = 0.74) Irmsd (Å) Score 0 20 −142 −108 Irmsd (Å) Score 0 20 −210 5420 2nqp (ES = 3.02) Irmsd (Å) Score 0 20 −28 −15 Irmsd (Å) Score 0 20 −510 4170 2nug (ES = 6.56) Irmsd (Å) Score 0 20 −67 −42 Irmsd (Å) Score 0 20 −550 3410 FIGURE S1 (cont.) – Diagramme par complexe de l’energie en fonction du I ´ RMSD (EvsRMS). Chaque candidat est positionne (par une croix) sur le diagramme selon son ´ energie et son I ´ RMSD. Les 10 premiers candidats en energie sont indiqu ´ es comme ´ presque-natifs (en bleu) ou leurres (en rouge). La fonction de score utilisee est celle ´ apprise par ROGER en leave-”one-pdb”-out pour les grands diagrammes et celle disponible par defaut dans RosettaDock dans les encarts en bas ´ a droite de chaque ` diagramme (candidats indiques en gris). ´ 1312ozb (ES = 6.82) Irmsd (Å) Score 0 20 −4 12 Irmsd (Å) Score 0 20 −360 2950 2pjp (ES = 1.75) Irmsd (Å) Score 0 20 −16 −8 Irmsd (Å) Score 0 20 −140 4450 2po1 (ES = 1.35) Irmsd (Å) Score 0 20 −38 −28 Irmsd (Å) Score 0 20 −510 4400 2qux (ES = 3.18) Irmsd (Å) Score 0 20 −16 −7 Irmsd (Å) Score 0 20 −240 4040 2r7r (ES = 4.54) Irmsd (Å) Score 0 20 −15 −6 Irmsd (Å) Score 0 20 −900 2450 2r8s (ES = 1.96) Irmsd (Å) Score 0 20 −369 −332 Irmsd (Å) Score 0 20 −590 2480 2vnu (ES = 2.2) Irmsd (Å) Score 0 20 −63 −34 Irmsd (Å) Score 0 20 −650 6230 2voo (ES = 1.69) Irmsd (Å) Score 0 20 −9 −5 Irmsd (Å) Score 0 20 −180 2510 2w2h (ES = 3.96) Irmsd (Å) Score 0 20 101 109 Irmsd (Å) Score 0 20 300 6590 FIGURE S1 (cont.) – Diagramme par complexe de l’energie en fonction du I ´ RMSD (EvsRMS). Chaque candidat est positionne (par une croix) sur le diagramme selon son ´ energie et son I ´ RMSD. Les 10 premiers candidats en energie sont indiqu ´ es comme ´ presque-natifs (en bleu) ou leurres (en rouge). La fonction de score utilisee est celle ´ apprise par ROGER en leave-”one-pdb”-out pour les grands diagrammes et celle disponible par defaut dans RosettaDock dans les encarts en bas ´ a droite de chaque ` diagramme (candidats indiques en gris). ´ 1322wj8 (ES = 6.11) Irmsd (Å) Score 0 20 16 24 Irmsd (Å) Score 0 20 −340 2710 2z2q (ES = 2.64) Irmsd (Å) Score 0 20 49 56 Irmsd (Å) Score 0 20 −810 2550 2zi0 (ES = 0.48) Irmsd (Å) Score 0 20 −17 −7 Irmsd (Å) Score 0 20 −100 4820 2zko (ES = 4.04) Irmsd (Å) Score 0 20 −29 −14 Irmsd (Å) Score 0 20 −220 3780 2zni (ES = 6.44) Irmsd (Å) Score 0 20 41 57 Irmsd (Å) Score 0 20 −450 4090 2zue (ES = 4.53) Irmsd (Å) Score 0 20 −216 −171 Irmsd (Å) Score 0 20 −710 4050 2zzm (ES = 8.06) Irmsd (Å) Score 0 20 −18 1 Irmsd (Å) Score 0 20 −260 4930 3a6p (ES = 7.17) Irmsd (Å) Score 0 20 2 31 Irmsd (Å) Score 0 20 −1120 3810 3bso (ES = 5.84) Irmsd (Å) Score 0 20 −31 −15 Irmsd (Å) Score 0 20 −490 4210 FIGURE S1 (cont.) – Diagramme par complexe de l’energie en fonction du I ´ RMSD (EvsRMS). Chaque candidat est positionne (par une croix) sur le diagramme selon son ´ energie et son I ´ RMSD. Les 10 premiers candidats en energie sont indiqu ´ es comme ´ presque-natifs (en bleu) ou leurres (en rouge). La fonction de score utilisee est celle ´ apprise par ROGER en leave-”one-pdb”-out pour les grands diagrammes et celle disponible par defaut dans RosettaDock dans les encarts en bas ´ a droite de chaque ` diagramme (candidats indiques en gris). ´ 1333bt7 (ES = 4.98) Irmsd (Å) Score 0 20 −16 −7 Irmsd (Å) Score 0 20 −280 2520 3ciy (ES = 2.79) Irmsd (Å) Score 0 20 6 21 Irmsd (Å) Score 0 20 −440 4200 3d2s (ES = 0.79) Irmsd (Å) Score 0 20 −27 −14 Irmsd (Å) Score 0 20 −110 2750 3dd2 (ES = 2) Irmsd (Å) Score 0 20 −35 −23 Irmsd (Å) Score 0 20 −320 5130 3egz (ES = 3.05) Irmsd (Å) Score 0 20 −17 −6 Irmsd (Å) Score 0 20 −120 4940 3eph (ES = 8.81) Irmsd (Å) Score 0 20 −17 −4 Irmsd (Å) Score 0 20 −380 4410 3eqt (ES = 7.19) Irmsd (Å) Score 0 20 −16 −1 Irmsd (Å) Score 0 20 −250 3430 3ex7 (ES = 4.06) Irmsd (Å) Score 0 20 −40 −29 Irmsd (Å) Score 0 20 −610 2100 3fht (ES = 3.66) Irmsd (Å) Score 0 20 −24 −17 Irmsd (Å) Score 0 20 −370 1790 FIGURE S1 (cont.) – Diagramme par complexe de l’energie en fonction du I ´ RMSD (EvsRMS). Chaque candidat est positionne (par une croix) sur le diagramme selon son ´ energie et son I ´ RMSD. Les 10 premiers candidats en energie sont indiqu ´ es comme ´ presque-natifs (en bleu) ou leurres (en rouge). La fonction de score utilisee est celle ´ apprise par ROGER en leave-”one-pdb”-out pour les grands diagrammes et celle disponible par defaut dans RosettaDock dans les encarts en bas ´ a droite de chaque ` diagramme (candidats indiques en gris). ´ 1343foz (ES = 8) Irmsd (Å) Score 0 20 −28 −15 Irmsd (Å) Score 0 20 −360 4800 3gib (ES = 1.8) Irmsd (Å) Score 0 20 −3 1 Irmsd (Å) Score 0 20 −170 4470 3hax (ES = 6.51) Irmsd (Å) Score 0 20 −59 −37 Irmsd (Å) Score 0 20 −430 4460 3hl2 (ES = 3.66) Irmsd (Å) Score 0 20 −28 −20 Irmsd (Å) Score 0 20 −790 1710 3htx (ES = 8.04) Irmsd (Å) Score 0 20 15 30 Irmsd (Å) Score 0 20 −500 5330 3i5x (ES = 3.55) Irmsd (Å) Score 0 20 −29 −24 Irmsd (Å) Score 0 20 −550 2350 3iab (ES = 5.28) Irmsd (Å) Score 0 20 −18 −10 Irmsd (Å) Score 0 20 −250 5270 3icq (ES = 2.83) Irmsd (Å) Score 0 20 −197 −141 Irmsd (Å) Score 0 20 −360 4850 3iev (ES = 5.64) Irmsd (Å) Score 0 20 −27 −19 Irmsd (Å) Score 0 20 −290 2780 FIGURE S1 (cont.) – Diagramme par complexe de l’energie en fonction du I ´ RMSD (EvsRMS). Chaque candidat est positionne (par une croix) sur le diagramme selon son ´ energie et son I ´ RMSD. Les 10 premiers candidats en energie sont indiqu ´ es comme ´ presque-natifs (en bleu) ou leurres (en rouge). La fonction de score utilisee est celle ´ apprise par ROGER en leave-”one-pdb”-out pour les grands diagrammes et celle disponible par defaut dans RosettaDock dans les encarts en bas ´ a droite de chaque ` diagramme (candidats indiques en gris). ´ 1353k62 (ES = 3.4) Irmsd (Å) Score 0 20 −23 −13 Irmsd (Å) Score 0 20 −430 3960 3l25 (ES = 7.02) Irmsd (Å) Score 0 20 −174 −127 Irmsd (Å) Score 0 20 −530 3980 3snp (ES = 6.63) Irmsd (Å) Score 0 20 −54 −42 Irmsd (Å) Score 0 20 −810 2450 FIGURE S1 (cont.) – Diagramme par complexe de l’energie en fonction du I ´ RMSD (EvsRMS). Chaque candidat est positionne (par une croix) sur le diagramme selon son ´ energie et son I ´ RMSD. Les 10 premiers candidats en energie sont indiqu ´ es comme ´ presque-natifs (en bleu) ou leurres (en rouge). La fonction de score utilisee est celle ´ apprise par ROGER en leave-”one-pdb”-out pour les grands diagrammes et celle disponible par defaut dans RosettaDock dans les encarts en bas ´ a droite de chaque ` diagramme (candidats indiques en gris). ´ 1361b7f (ES = 5.15) Irmsd (Å) Score 0 20 −115 −98 Irmsd (Å) Score 0 20 −90 3490 1c9s (ES = 1.19) Irmsd (Å) Score 0 20 −50 −34 Irmsd (Å) Score 0 20 −60 3700 1dk1 (ES = 2.58) Irmsd (Å) Score 0 20 −145 −122 Irmsd (Å) Score 0 20 −90 3140 1e7k (ES = 1.33) Irmsd (Å) Score 0 20 −126 −97 Irmsd (Å) Score 0 20 −90 4790 1ec6 (ES = 0.88) Irmsd (Å) Score 0 20 −90 −73 Irmsd (Å) Score 0 20 −80 3420 1efw (ES = 2.9) Irmsd (Å) Score 0 20 −492 −468 Irmsd (Å) Score 0 20 −400 3340 1ekz (ES = 0.81) Irmsd (Å) Score 0 20 −98 −75 Irmsd (Å) Score 0 20 −60 3960 1g1x (ES = 0.54) Irmsd (Å) Score 0 20 −166 −148 Irmsd (Å) Score 0 20 −110 3170 1hc8 (ES = 3.63) Irmsd (Å) Score 0 20 −123 −105 Irmsd (Å) Score 0 20 −110 1860 FIGURE S2 – Diagramme par complexe des Benchmarks I et II de l’energie en fonction ´ du IRMSD (EvsRMS). Chaque candidat est positionne (par une croix) sur le diagramme ´ selon son energie et son I ´ RMSD. Les 10 premiers candidats en energie sont indiqu ´ es´ comme presque-natifs (en bleu) ou leurres (en rouge). La fonction de score utilisee est ´ celle apprise par ROGER en leave-”one-pdb”-out pour les grands diagrammes et celle disponible par defaut dans RosettaDock dans les encarts en bas ´ a droite de chaque ` diagramme (candidats indiques en gris). ´ 1371hvu (ES = 1.93) Irmsd (Å) Score 0 20 −667 −636 Irmsd (Å) Score 0 20 1210 6690 1jbr (ES = 0.02) Irmsd (Å) Score 0 20 −135 −112 Irmsd (Å) Score 0 20 −140 4470 1kog (ES = 1.14) Irmsd (Å) Score 0 20 −365 −338 Irmsd (Å) Score 0 20 −300 4420 1kq2 (ES = 5.4) Irmsd (Å) Score 0 20 −255 −236 Irmsd (Å) Score 0 20 −270 4150 1m5o (ES = 1.33) Irmsd (Å) Score 0 20 −191 −170 Irmsd (Å) Score 0 20 −200 3750 1m8w (ES = 1.27) Irmsd (Å) Score 0 20 −326 −307 Irmsd (Å) Score 0 20 −360 3870 1mfq (ES = 2.35) Irmsd (Å) Score 0 20 −231 −204 Irmsd (Å) Score 0 20 −180 4830 1mms (ES = 3.31) Irmsd (Å) Score 0 20 −169 −146 Irmsd (Å) Score 0 20 −130 2850 1msw (ES = 8.84) Irmsd (Å) Score 0 20 −692 −656 Irmsd (Å) Score 0 20 −500 5040 FIGURE S2 (cont.) – Diagramme par complexe des Benchmarks I et II de l’energie en ´ fonction du IRMSD (EvsRMS). Chaque candidat est positionne (par une croix) sur le ´ diagramme selon son energie et son I ´ RMSD. Les 10 premiers candidats en energie ´ sont indiques comme presque-natifs (en bleu) ou leurres (en rouge). La fonction de ´ score utilisee est celle apprise par R ´ OGER en leave-”one-pdb”-out pour les grands diagrammes et celle disponible par defaut dans RosettaDock dans les encarts en bas ´ a droite de chaque diagramme (candidats indiqu ` es en gris). ´ 1381ob2 (ES = 3.38) Irmsd (Å) Score 0 20 −320 −293 Irmsd (Å) Score 0 20 −270 3590 1u63 (ES = 1.13) Irmsd (Å) Score 0 20 −191 −162 Irmsd (Å) Score 0 20 −50 4650 1t4l (ES = 1.64) Irmsd (Å) Score 0 20 −27041 −25961 Irmsd (Å) Score 0 20 9803120 9970860 1ttt (ES = 3.25) Irmsd (Å) Score 0 20 −374 −348 Irmsd (Å) Score 0 20 −260 3610 1wne (ES = 4.41) Irmsd (Å) Score 0 20 −346 −324 Irmsd (Å) Score 0 20 −410 4170 1zbi (ES = 2.95) Irmsd (Å) Score 0 20 −150 −124 Irmsd (Å) Score 0 20 −130 3840 2ad9 (ES = 2.53) Irmsd (Å) Score 0 20 −64 −54 Irmsd (Å) Score 0 20 −70 2080 2adb (ES = 3.37) Irmsd (Å) Score 0 20 −86 −76 Irmsd (Å) Score 0 20 −100 2410 2adc (ES = 2.61) Irmsd (Å) Score 0 20 −148 −136 Irmsd (Å) Score 0 20 −180 2440 FIGURE S2 (cont.) – Diagramme par complexe des Benchmarks I et II de l’energie en ´ fonction du IRMSD (EvsRMS). Chaque candidat est positionne (par une croix) sur le ´ diagramme selon son energie et son I ´ RMSD. Les 10 premiers candidats en energie ´ sont indiques comme presque-natifs (en bleu) ou leurres (en rouge). La fonction de ´ score utilisee est celle apprise par R ´ OGER en leave-”one-pdb”-out pour les grands diagrammes et celle disponible par defaut dans RosettaDock dans les encarts en bas ´ a droite de chaque diagramme (candidats indiqu ` es en gris). ´ 1392b6g (ES = 0.02) Irmsd (Å) Score 0 20 −95 −74 Irmsd (Å) Score 0 20 −80 3630 2c0b (ES = 2.98) Irmsd (Å) Score 0 20 −327 −310 Irmsd (Å) Score 0 20 −50 3410 2dra (ES = 6.16) Irmsd (Å) Score 0 20 −392 −369 Irmsd (Å) Score 0 20 −440 4260 2err (ES = 2.48) Irmsd (Å) Score 0 20 −80 −62 Irmsd (Å) Score 0 20 −90 3730 2ez6 (ES = 2.92) Irmsd (Å) Score 0 20 −278 −251 Irmsd (Å) Score 0 20 −310 3850 2hgh (ES = 1.03) Irmsd (Å) Score 0 20 −138 −110 Irmsd (Å) Score 0 20 −130 6030 2i91 (ES = 7.35) Irmsd (Å) Score 0 20 −444 −421 Irmsd (Å) Score 0 20 −390 3710 2ix1 (ES = 2.14) Irmsd (Å) Score 0 20 −482 −451 Irmsd (Å) Score 0 20 −580 6730 2py9 (ES = 2.95) Irmsd (Å) Score 0 20 −110 −101 Irmsd (Å) Score 0 20 −110 1660 FIGURE S2 (cont.) – Diagramme par complexe des Benchmarks I et II de l’energie en ´ fonction du IRMSD (EvsRMS). Chaque candidat est positionne (par une croix) sur le ´ diagramme selon son energie et son I ´ RMSD. Les 10 premiers candidats en energie ´ sont indiques comme presque-natifs (en bleu) ou leurres (en rouge). La fonction de ´ score utilisee est celle apprise par R ´ OGER en leave-”one-pdb”-out pour les grands diagrammes et celle disponible par defaut dans RosettaDock dans les encarts en bas ´ a droite de chaque diagramme (candidats indiqu ` es en gris). ´ 1403bo2 (ES = 2.73) Irmsd (Å) Score 0 20 −295 −273 Irmsd (Å) Score 0 20 −140 4850 3bsb (ES = 1.55) Irmsd (Å) Score 0 20 −306 −283 Irmsd (Å) Score 0 20 −290 4870 3bsx (ES = 1.2) Irmsd (Å) Score 0 20 −315 −294 Irmsd (Å) Score 0 20 −340 4660 3bx2 (ES = 3.09) Irmsd (Å) Score 0 20 −315 −296 Irmsd (Å) Score 0 20 −310 4500 FIGURE S2 (cont.) – Diagramme par complexe des Benchmarks I et II de l’energie en ´ fonction du IRMSD (EvsRMS). Chaque candidat est positionne (par une croix) sur le ´ diagramme selon son energie et son I ´ RMSD. Les 10 premiers candidats en energie ´ sont indiques comme presque-natifs (en bleu) ou leurres (en rouge). La fonction de ´ score utilisee est celle apprise par R ´ OGER en leave-”one-pdb”-out pour les grands diagrammes et celle disponible par defaut dans RosettaDock dans les encarts en bas ´ a droite de chaque diagramme (candidats indiqu ` es en gris). ´ 1411m5o (ES = 4.75) Irmsd (Å) Score 0 20 −194 −174 Irmsd (Å) Score 0 20 −200 3830 1qtq (ES = 6.09) Irmsd (Å) Score 0 20 −437 −403 Irmsd (Å) Score 0 20 −380 5500 1wpu (ES = 3.15) Irmsd (Å) Score 0 20 −116 −103 Irmsd (Å) Score 0 20 −150 2460 1yvp (ES = 0.2) Irmsd (Å) Score 0 20 −484 −459 Irmsd (Å) Score 0 20 −540 3980 1zbh (ES = 0) Irmsd (Å) Score 0 20 −188 −165 Irmsd (Å) Score 0 20 −200 3840 2ad9 (ES = 6.06) Irmsd (Å) Score 0 20 −50 −42 Irmsd (Å) Score 0 20 −20 2170 FIGURE S3 – Diagramme par complexe des 6 complexes avec proteine non li ´ ee de ´ l’energie en fonction du I ´ RMSD (EvsRMS). Chaque candidat est positionne (par une ´ croix) sur le diagramme selon son energie et son I ´ RMSD. Les 10 premiers candidats en energie sont indiqu ´ es comme presque-natifs (en bleu) ou leurres (en rouge). La ´ fonction de score utilisee est celle apprise par R ´ OGER en leave-”one-pdb”-out pour les grands diagrammes et celle disponible par defaut dans RosettaDock dans les encarts ´ en bas a droite de chaque diagramme (candidats indiqu ` es en gris). ´ 142Precision ´ Rappel Fscore Accuracy Sensibilite´ Specificit ´ e´ pdb ROS POS ROS POS ROS POS ROS POS ROS POS ROS POS 1asy 0.72 0.75 1.00 0.99 0.84 0.86 0.72 0.76 1.00 0.99 0.00 0.16 1av6 0.88 0.88 1.00 1.00 0.94 0.94 0.88 0.88 1.00 1.00 0.00 0.01 1b23 0.50 0.66 1.00 0.90 0.67 0.76 0.50 0.72 1.00 0.90 0.00 0.54 1c0a 0.26 0.71 1.00 0.78 0.41 0.74 0.26 0.86 1.00 0.78 0.00 0.89 1ddl 0.28 0.34 1.00 0.81 0.44 0.48 0.28 0.51 1.00 0.81 0.00 0.39 1dfu 0.92 0.96 1.00 0.99 0.96 0.97 0.92 0.95 1.00 0.99 0.00 0.44 1di2 0.76 0.84 1.00 0.94 0.86 0.88 0.76 0.82 1.00 0.94 0.00 0.45 1e8o 0.34 0.35 1.00 0.95 0.50 0.51 0.34 0.38 1.00 0.95 0.00 0.09 1f7u 0.41 0.76 1.00 0.85 0.58 0.80 0.41 0.83 1.00 0.85 0.00 0.81 1feu 0.91 0.92 1.00 0.99 0.95 0.95 0.91 0.91 1.00 0.99 0.00 0.10 1ffy 0.32 0.58 0.98 0.77 0.48 0.66 0.33 0.76 0.98 0.77 0.04 0.75 1fxl 0.51 0.86 1.00 0.87 0.68 0.87 0.51 0.86 1.00 0.87 0.00 0.86 1gtf 0.96 0.96 1.00 1.00 0.98 0.98 0.96 0.96 1.00 1.00 0.00 0.02 1h3e 0.59 0.69 1.00 0.94 0.74 0.79 0.59 0.71 1.00 0.94 0.00 0.38 1h4s 0.12 0.19 1.00 0.52 0.21 0.27 0.12 0.67 1.00 0.52 0.00 0.69 1hq1 0.28 0.28 0.89 0.97 0.42 0.43 0.36 0.33 0.89 0.97 0.17 0.10 1j1u 0.83 0.83 1.00 1.00 0.91 0.91 0.83 0.83 1.00 1.00 0.00 0.00 1j2b 0.13 0.64 1.00 0.81 0.23 0.71 0.13 0.91 1.00 0.81 0.00 0.93 1jbs 0.25 0.31 1.00 0.79 0.40 0.45 0.25 0.50 1.00 0.79 0.00 0.40 1jid 0.94 0.94 1.00 1.00 0.97 0.97 0.94 0.94 1.00 1.00 0.00 0.08 1k8w 0.39 0.72 1.00 0.86 0.56 0.78 0.39 0.81 1.00 0.86 0.00 0.79 1knz 0.31 0.84 1.00 0.89 0.47 0.86 0.31 0.91 1.00 0.89 0.00 0.92 1lng 0.73 0.76 1.00 0.98 0.84 0.86 0.73 0.76 1.00 0.98 0.00 0.16 1m8v 0.70 0.70 1.00 1.00 0.82 0.83 0.70 0.70 1.00 1.00 0.00 0.01 1m8x 0.84 0.84 1.00 1.00 0.91 0.91 0.84 0.84 1.00 1.00 0.00 0.01 1mzp 0.16 0.32 1.00 0.52 0.27 0.39 0.16 0.75 1.00 0.52 0.00 0.79 1n35 0.07 0.57 1.00 0.83 0.14 0.68 0.08 0.94 1.00 0.83 0.00 0.95 1n78 0.44 0.83 1.00 0.88 0.61 0.85 0.44 0.87 1.00 0.88 0.00 0.86 1ooa 0.87 0.88 1.00 1.00 0.93 0.94 0.87 0.88 1.00 1.00 0.00 0.14 1pgl 0.93 0.94 1.00 1.00 0.97 0.97 0.93 0.94 1.00 1.00 0.00 0.10 1q2r 0.46 0.73 1.00 0.92 0.63 0.82 0.46 0.81 1.00 0.92 0.00 0.71 1qf6 0.12 0.67 1.00 0.80 0.21 0.73 0.12 0.93 1.00 0.80 0.00 0.95 1qtq 0.30 0.72 1.00 0.77 0.46 0.74 0.30 0.84 1.00 0.77 0.00 0.87 1r3e 0.34 0.60 1.00 0.74 0.50 0.66 0.34 0.75 1.00 0.74 0.00 0.76 1r9f 0.94 0.94 1.00 1.00 0.97 0.97 0.94 0.94 1.00 1.00 0.00 0.04 1sds 0.43 0.42 0.96 1.00 0.59 0.59 0.44 0.43 0.96 1.00 0.07 0.02 1ser 0.30 0.66 1.00 0.87 0.46 0.75 0.30 0.83 1.00 0.87 0.00 0.81 1si3 0.77 0.95 1.00 0.95 0.87 0.95 0.77 0.92 1.00 0.95 0.00 0.84 1t0k 0.38 0.37 0.98 1.00 0.54 0.54 0.39 0.37 0.98 1.00 0.03 0.00 1tfw 0.02 0.71 1.00 0.96 0.04 0.82 0.02 0.99 1.00 0.96 0.00 0.99 1u0b 0.26 0.58 1.00 0.77 0.41 0.66 0.26 0.79 1.00 0.77 0.00 0.80 1un6 0.40 0.67 1.00 0.73 0.57 0.70 0.40 0.75 1.00 0.73 0.00 0.76 1uvj 0.21 0.72 1.00 0.92 0.34 0.81 0.21 0.91 1.00 0.92 0.00 0.91 1vfg 0.93 0.93 1.00 1.00 0.96 0.96 0.93 0.93 1.00 1.00 0.00 0.00 1wpu 0.87 0.88 1.00 1.00 0.93 0.93 0.87 0.88 1.00 1.00 0.00 0.05 1wsu 0.48 0.51 1.00 0.95 0.65 0.67 0.48 0.54 1.00 0.95 0.00 0.15 1wz2 0.25 0.51 1.00 0.78 0.39 0.62 0.25 0.76 1.00 0.78 0.00 0.76 Resultats globaux des 120 complexes de la P ´ RIDB sous le seuil du meilleur Fscore : avec les mesures d’evaluation globales pour chacun des complexes pour la fonction ´ de score par defaut de RosettaDock (ROS) et la fonction de score atomique apprise ´ avec ROGER (POS). 143Precision ´ Rappel Fscore Accuracy Sensibilite´ Specificit ´ e´ pdb ROS POS ROS POS ROS POS ROS POS ROS POS ROS POS 1yvp 0.94 0.94 1.00 1.00 0.97 0.97 0.94 0.94 1.00 1.00 0.00 0.01 1zbh 0.38 0.47 1.00 0.90 0.55 0.61 0.38 0.57 1.00 0.90 0.00 0.37 2a8v 0.48 0.54 1.00 0.87 0.65 0.67 0.48 0.59 1.00 0.87 0.00 0.33 2anr 0.29 0.36 1.00 0.76 0.45 0.49 0.29 0.54 1.00 0.76 0.00 0.44 2asb 0.55 0.68 1.00 0.97 0.71 0.80 0.55 0.73 1.00 0.97 0.00 0.45 2az0 0.14 0.32 0.99 0.58 0.24 0.41 0.14 0.77 0.99 0.58 0.01 0.81 2azx 0.72 0.77 1.00 0.97 0.84 0.86 0.72 0.77 1.00 0.97 0.00 0.27 2b3j 0.72 0.88 1.00 0.94 0.84 0.91 0.72 0.87 1.00 0.94 0.00 0.68 2bgg 0.54 0.81 1.00 0.87 0.70 0.84 0.54 0.82 1.00 0.87 0.00 0.76 2bh2 0.23 0.76 1.00 0.70 0.38 0.73 0.23 0.88 1.00 0.70 0.00 0.93 2bte 0.73 0.80 1.00 0.93 0.84 0.86 0.73 0.78 1.00 0.93 0.00 0.39 2bu1 0.39 0.43 1.00 0.91 0.56 0.59 0.39 0.50 1.00 0.91 0.00 0.24 2bx2 0.35 0.51 0.99 0.89 0.51 0.65 0.35 0.67 0.99 0.89 0.01 0.56 2ct8 0.58 0.72 1.00 0.90 0.74 0.80 0.58 0.74 1.00 0.90 0.00 0.53 2czj 0.91 0.91 1.00 1.00 0.95 0.96 0.91 0.91 1.00 1.00 0.00 0.01 2d6f 0.85 0.85 1.00 1.00 0.92 0.92 0.85 0.85 1.00 1.00 0.01 0.00 2der 0.35 0.83 1.00 0.79 0.52 0.81 0.35 0.87 1.00 0.79 0.00 0.91 2du3 0.92 0.92 1.00 1.00 0.96 0.96 0.92 0.92 1.00 1.00 0.00 0.01 2e9t 0.17 0.93 1.00 0.98 0.29 0.95 0.17 0.98 1.00 0.98 0.00 0.99 2f8k 0.50 0.50 1.00 0.99 0.67 0.67 0.50 0.51 1.00 0.99 0.00 0.02 2f8s 0.68 0.69 1.00 0.99 0.81 0.82 0.68 0.69 1.00 0.99 0.00 0.05 2fk6 0.82 0.83 1.00 0.99 0.90 0.90 0.82 0.83 1.00 0.99 0.00 0.09 2fmt 0.27 0.53 1.00 0.88 0.42 0.66 0.27 0.76 1.00 0.88 0.00 0.71 2gic 0.40 0.69 1.00 0.90 0.57 0.78 0.40 0.80 1.00 0.90 0.00 0.74 2gje 0.72 0.78 1.00 0.95 0.84 0.85 0.72 0.76 1.00 0.95 0.00 0.28 2gjw 0.78 0.85 1.00 0.97 0.88 0.91 0.78 0.84 1.00 0.97 0.00 0.41 2gtt 0.24 0.51 0.98 0.87 0.39 0.64 0.26 0.76 0.98 0.87 0.03 0.73 2gxb 0.47 0.49 1.00 0.93 0.64 0.64 0.47 0.52 1.00 0.93 0.00 0.15 2hw8 0.73 0.81 1.00 0.97 0.84 0.88 0.73 0.81 1.00 0.97 0.00 0.38 2i82 0.69 0.78 1.00 0.95 0.82 0.85 0.69 0.78 1.00 0.95 0.00 0.39 2iy5 0.09 0.47 1.00 0.83 0.17 0.60 0.10 0.90 1.00 0.83 0.01 0.91 2jlv 0.46 0.71 0.99 0.94 0.63 0.81 0.47 0.80 0.99 0.94 0.04 0.68 2nqp 0.27 0.35 1.00 0.82 0.42 0.49 0.27 0.54 1.00 0.82 0.01 0.44 2nug 0.06 1.00 0.58 1.00 0.11 1.00 0.66 1.00 0.58 1.00 0.66 1.00 2ozb 0.37 0.66 1.00 0.76 0.54 0.71 0.37 0.77 1.00 0.76 0.00 0.77 2pjp 0.30 0.39 1.00 0.83 0.46 0.53 0.30 0.56 1.00 0.83 0.00 0.45 2po1 0.92 0.91 1.00 1.00 0.96 0.96 0.92 0.91 1.00 1.00 0.03 0.00 2qux 0.19 0.28 1.00 0.77 0.33 0.41 0.20 0.57 1.00 0.77 0.01 0.52 2r7r 0.42 0.83 1.00 0.94 0.59 0.88 0.42 0.89 1.00 0.94 0.00 0.86 2r8s 0.73 0.73 1.00 1.00 0.84 0.84 0.73 0.73 1.00 1.00 0.00 0.04 2vnu 0.25 0.69 1.00 0.96 0.40 0.80 0.25 0.88 1.00 0.96 0.00 0.86 2voo 0.76 0.76 1.00 1.00 0.86 0.86 0.76 0.76 1.00 1.00 0.00 0.00 2w2h 0.55 0.63 1.00 0.91 0.71 0.75 0.55 0.66 1.00 0.91 0.00 0.35 2wj8 0.24 0.82 1.00 0.93 0.39 0.88 0.24 0.94 1.00 0.93 0.00 0.94 2z2q 0.59 0.60 1.00 0.99 0.74 0.75 0.59 0.60 1.00 0.99 0.00 0.05 2zi0 0.79 0.89 1.00 0.98 0.88 0.93 0.79 0.89 1.00 0.98 0.00 0.55 2zko 0.17 0.24 0.52 0.62 0.26 0.34 0.61 0.68 0.52 0.62 0.62 0.69 Resultats globaux des 120 complexes de la P ´ RIDB sous le seuil du meilleur Fscore : avec les mesures d’evaluation globales pour chacun des complexes pour la fonction ´ de score par defaut de RosettaDock (ROS) et la fonction de score atomique apprise ´ avec ROGER (POS). 144Precision ´ Rappel Fscore Accuracy Sensibilite´ Specificit ´ e´ pdb ROS POS ROS POS ROS POS ROS POS ROS POS ROS POS 2zni 0.27 0.52 1.00 0.71 0.42 0.60 0.27 0.75 1.00 0.71 0.00 0.76 2zue 0.49 0.77 1.00 0.88 0.66 0.82 0.49 0.81 1.00 0.88 0.00 0.74 2zzm 0.13 0.76 1.00 0.79 0.22 0.78 0.13 0.94 1.00 0.79 0.00 0.96 3a6p 0.61 0.88 0.56 0.90 0.58 0.89 0.84 0.96 0.56 0.90 0.91 0.97 3bso 0.25 0.77 0.99 0.94 0.40 0.85 0.27 0.92 0.99 0.94 0.04 0.91 3bt7 0.54 0.67 1.00 0.87 0.70 0.76 0.54 0.70 1.00 0.87 0.00 0.50 3ciy 0.56 0.58 1.00 0.98 0.72 0.73 0.56 0.58 1.00 0.98 0.00 0.07 3d2s 0.89 0.90 1.00 1.00 0.94 0.94 0.89 0.89 1.00 1.00 0.00 0.02 3dd2 0.25 0.30 1.00 0.79 0.40 0.43 0.25 0.48 1.00 0.79 0.00 0.38 3egz 0.52 0.82 1.00 0.91 0.69 0.87 0.52 0.85 1.00 0.91 0.00 0.79 3eph 0.10 0.93 1.00 0.95 0.18 0.94 0.10 0.99 1.00 0.95 0.00 0.99 3eqt 0.52 0.85 1.00 0.76 0.68 0.80 0.52 0.80 1.00 0.76 0.00 0.85 3ex7 0.75 0.87 1.00 0.96 0.86 0.91 0.75 0.86 1.00 0.96 0.00 0.59 3fht 0.83 0.92 1.00 0.95 0.90 0.93 0.83 0.89 1.00 0.95 0.00 0.59 3foz 0.13 0.68 1.00 0.92 0.24 0.78 0.13 0.93 1.00 0.92 0.00 0.93 3gib 0.23 0.40 1.00 0.64 0.38 0.49 0.23 0.69 1.00 0.64 0.00 0.71 3hax 0.10 0.76 1.00 0.60 0.19 0.67 0.10 0.94 1.00 0.60 0.00 0.98 3hl2 0.91 0.95 1.00 0.99 0.95 0.97 0.91 0.94 1.00 0.99 0.00 0.48 3htx 0.10 0.63 1.00 0.76 0.19 0.69 0.10 0.93 1.00 0.76 0.00 0.95 3i5x 0.68 0.79 1.00 0.96 0.81 0.87 0.68 0.80 1.00 0.96 0.00 0.47 3iab 0.48 0.74 1.00 0.85 0.65 0.79 0.48 0.78 1.00 0.85 0.00 0.73 3icq 0.51 0.67 1.00 0.89 0.68 0.76 0.51 0.72 1.00 0.89 0.00 0.53 3iev 0.79 0.79 1.00 1.00 0.88 0.88 0.79 0.79 1.00 1.00 0.00 0.01 3k62 0.85 0.85 1.00 1.00 0.92 0.92 0.85 0.85 1.00 1.00 0.00 0.03 3l25 0.12 0.92 1.00 0.96 0.22 0.94 0.12 0.98 1.00 0.96 0.00 0.99 3snp 0.32 0.63 1.00 0.75 0.48 0.68 0.32 0.78 1.00 0.75 0.00 0.79 TABLE S1 – Resultats globaux des 120 complexes de la P ´ RIDB sous le seuil du meilleur Fscore : avec les mesures d’evaluation globales pour chacun des complexes pour la ´ fonction de score par defaut de RosettaDock (ROS) et la fonction de score atomique ´ apprise avec ROGER (POS). 145Precision ´ Rappel Fscore Accuracy Sensibilite´ Specificit ´ e´ pdb ROS POS ROS POS ROS POS ROS POS ROS POS ROS POS 1asy 0.70 0.90 0.00 0.00 0.00 0.00 0.28 0.28 0.00 0.00 1.00 1.00 1av6 0.50 1.00 0.00 0.00 0.00 0.00 0.12 0.12 0.00 0.00 1.00 1.00 1b23 0.40 1.00 0.00 0.00 0.00 0.00 0.50 0.50 0.00 0.00 1.00 1.00 1c0a 0.10 1.00 0.00 0.00 0.00 0.01 0.74 0.74 0.00 0.00 1.00 1.00 1ddl 0.20 0.40 0.00 0.00 0.00 0.00 0.72 0.72 0.00 0.00 1.00 1.00 1dfu 0.40 1.00 0.00 0.00 0.00 0.00 0.08 0.08 0.00 0.00 0.99 1.00 1di2 1.00 0.90 0.00 0.00 0.00 0.00 0.25 0.25 0.00 0.00 1.00 1.00 1e8o 0.60 0.40 0.00 0.00 0.00 0.00 0.66 0.66 0.00 0.00 1.00 1.00 1f7u 0.40 1.00 0.00 0.00 0.00 0.00 0.59 0.59 0.00 0.00 1.00 1.00 1feu 0.40 1.00 0.00 0.00 0.00 0.00 0.09 0.09 0.00 0.00 0.99 1.00 1ffy 0.00 0.80 0.00 0.00 0.00 0.01 0.69 0.69 0.00 0.00 1.00 1.00 1fxl 0.00 1.00 0.00 0.00 0.00 0.00 0.49 0.49 0.00 0.00 1.00 1.00 1gtf 1.00 1.00 0.00 0.00 0.00 0.00 0.04 0.04 0.00 0.00 1.00 1.00 1h3e 0.00 0.80 0.00 0.00 0.00 0.00 0.41 0.41 0.00 0.00 1.00 1.00 1h4s 0.10 0.50 0.00 0.00 0.00 0.01 0.88 0.88 0.00 0.00 1.00 1.00 1hq1 0.60 0.00 0.00 0.00 0.00 0.00 0.74 0.74 0.00 0.00 1.00 1.00 1j1u 1.00 1.00 0.00 0.00 0.00 0.00 0.17 0.17 0.00 0.00 1.00 1.00 1j2b 0.00 0.90 0.00 0.01 0.00 0.01 0.87 0.87 0.00 0.01 1.00 1.00 1jbs 0.00 0.20 0.00 0.00 0.00 0.00 0.75 0.75 0.00 0.00 1.00 1.00 1jid 0.20 1.00 0.00 0.00 0.00 0.00 0.06 0.07 0.00 0.00 0.99 1.00 1k8w 0.10 1.00 0.00 0.00 0.00 0.01 0.61 0.61 0.00 0.00 1.00 1.00 1knz 0.00 0.50 0.00 0.00 0.00 0.00 0.69 0.69 0.00 0.00 1.00 1.00 1lng 0.60 0.90 0.00 0.00 0.00 0.00 0.27 0.27 0.00 0.00 1.00 1.00 1m8v 1.00 0.90 0.00 0.00 0.00 0.00 0.30 0.30 0.00 0.00 1.00 1.00 1m8x 0.70 1.00 0.00 0.00 0.00 0.00 0.16 0.16 0.00 0.00 1.00 1.00 1mzp 0.00 0.60 0.00 0.00 0.00 0.01 0.84 0.84 0.00 0.00 1.00 1.00 1n35 0.00 0.00 0.00 0.00 0.00 0.00 0.93 0.93 0.00 0.00 1.00 1.00 1n78 0.00 1.00 0.00 0.00 0.00 0.00 0.56 0.56 0.00 0.00 1.00 1.00 1ooa 0.60 0.90 0.00 0.00 0.00 0.00 0.13 0.13 0.00 0.00 1.00 1.00 1pgl 1.00 1.00 0.00 0.00 0.00 0.00 0.07 0.07 0.00 0.00 1.00 1.00 1q2r 0.00 1.00 0.00 0.00 0.00 0.00 0.54 0.54 0.00 0.00 1.00 1.00 1qf6 0.00 1.00 0.00 0.01 0.00 0.02 0.88 0.89 0.00 0.01 1.00 1.00 1qtq 0.00 1.00 0.00 0.00 0.00 0.01 0.70 0.70 0.00 0.00 1.00 1.00 1r3e 0.00 0.90 0.00 0.00 0.00 0.01 0.66 0.67 0.00 0.00 1.00 1.00 1r9f 1.00 1.00 0.00 0.00 0.00 0.00 0.07 0.07 0.00 0.00 1.00 1.00 1sds 0.50 0.40 0.00 0.00 0.00 0.00 0.58 0.58 0.00 0.00 1.00 1.00 1ser 0.00 0.60 0.00 0.00 0.00 0.00 0.70 0.70 0.00 0.00 1.00 1.00 1si3 0.00 1.00 0.00 0.00 0.00 0.00 0.23 0.23 0.00 0.00 1.00 1.00 1t0k 0.80 0.00 0.00 0.00 0.00 0.00 0.63 0.63 0.00 0.00 1.00 1.00 1tfw 0.00 0.40 0.00 0.02 0.00 0.03 0.98 0.98 0.00 0.02 1.00 1.00 1u0b 0.00 1.00 0.00 0.00 0.00 0.01 0.74 0.74 0.00 0.00 1.00 1.00 1un6 0.00 0.90 0.00 0.00 0.00 0.00 0.60 0.61 0.00 0.00 1.00 1.00 1uvj 0.00 0.40 0.00 0.00 0.00 0.00 0.79 0.79 0.00 0.00 1.00 1.00 1vfg 0.90 0.90 0.00 0.00 0.00 0.00 0.07 0.07 0.00 0.00 1.00 1.00 1wpu 1.00 1.00 0.00 0.00 0.00 0.00 0.13 0.13 0.00 0.00 1.00 1.00 1wsu 0.00 0.60 0.00 0.00 0.00 0.00 0.52 0.52 0.00 0.00 1.00 1.00 1wz2 0.00 0.90 0.00 0.00 0.00 0.01 0.75 0.76 0.00 0.00 1.00 1.00 Resultats globaux des 120 complexes de la P ´ RIDB sous le seuil du top10 des candidats : avec les mesures d’evaluation globales pour chacun des complexes pour la ´ fonction de score par defaut de RosettaDock (ROS) et la fonction de score atomique ´ apprise avec ROGER (POS). 146Precision ´ Rappel Fscore Accuracy Sensibilite´ Specificit ´ e´ pdb ROS POS ROS POS ROS POS ROS POS ROS POS ROS POS 1yvp 0.80 1.00 0.00 0.00 0.00 0.00 0.06 0.06 0.00 0.00 1.00 1.00 1zbh 0.20 0.80 0.00 0.00 0.00 0.00 0.62 0.62 0.00 0.00 1.00 1.00 2a8v 0.20 0.50 0.00 0.00 0.00 0.00 0.52 0.52 0.00 0.00 1.00 1.00 2anr 0.70 0.10 0.00 0.00 0.00 0.00 0.71 0.71 0.00 0.00 1.00 1.00 2asb 0.20 1.00 0.00 0.00 0.00 0.00 0.45 0.45 0.00 0.00 1.00 1.00 2az0 0.00 0.40 0.00 0.00 0.00 0.01 0.86 0.86 0.00 0.00 1.00 1.00 2azx 0.00 0.90 0.00 0.00 0.00 0.00 0.28 0.28 0.00 0.00 1.00 1.00 2b3j 0.00 1.00 0.00 0.00 0.00 0.00 0.28 0.28 0.00 0.00 1.00 1.00 2bgg 0.00 1.00 0.00 0.00 0.00 0.00 0.46 0.46 0.00 0.00 1.00 1.00 2bh2 0.00 1.00 0.00 0.00 0.00 0.01 0.77 0.77 0.00 0.00 1.00 1.00 2bte 0.70 1.00 0.00 0.00 0.00 0.00 0.28 0.28 0.00 0.00 1.00 1.00 2bu1 0.50 0.30 0.00 0.00 0.00 0.00 0.61 0.61 0.00 0.00 1.00 1.00 2bx2 0.00 0.80 0.00 0.00 0.00 0.00 0.65 0.66 0.00 0.00 1.00 1.00 2ct8 0.30 1.00 0.00 0.00 0.00 0.00 0.42 0.42 0.00 0.00 1.00 1.00 2czj 1.00 1.00 0.00 0.00 0.00 0.00 0.09 0.09 0.00 0.00 1.00 1.00 2d6f 1.00 0.50 0.00 0.00 0.00 0.00 0.16 0.15 0.00 0.00 1.00 1.00 2der 0.00 0.90 0.00 0.00 0.00 0.01 0.65 0.65 0.00 0.00 1.00 1.00 2du3 0.90 1.00 0.00 0.00 0.00 0.00 0.08 0.09 0.00 0.00 1.00 1.00 2e9t 0.00 0.90 0.00 0.01 0.00 0.01 0.83 0.83 0.00 0.01 1.00 1.00 2f8k 0.90 0.50 0.00 0.00 0.00 0.00 0.50 0.50 0.00 0.00 1.00 1.00 2f8s 0.60 1.00 0.00 0.00 0.00 0.00 0.32 0.32 0.00 0.00 1.00 1.00 2fk6 1.00 0.90 0.00 0.00 0.00 0.00 0.18 0.18 0.00 0.00 1.00 1.00 2fmt 0.00 1.00 0.00 0.00 0.00 0.01 0.73 0.73 0.00 0.00 1.00 1.00 2gic 0.00 0.60 0.00 0.00 0.00 0.00 0.60 0.60 0.00 0.00 1.00 1.00 2gje 0.60 1.00 0.00 0.00 0.00 0.00 0.28 0.28 0.00 0.00 1.00 1.00 2gjw 0.80 1.00 0.00 0.00 0.00 0.00 0.22 0.22 0.00 0.00 1.00 1.00 2gtt 0.00 0.40 0.00 0.00 0.00 0.00 0.76 0.76 0.00 0.00 1.00 1.00 2gxb 0.00 0.40 0.00 0.00 0.00 0.00 0.53 0.53 0.00 0.00 1.00 1.00 2hw8 0.90 0.90 0.00 0.00 0.00 0.00 0.27 0.27 0.00 0.00 1.00 1.00 2i82 0.60 1.00 0.00 0.00 0.00 0.00 0.31 0.31 0.00 0.00 1.00 1.00 2iy5 0.00 0.00 0.00 0.00 0.00 0.00 0.91 0.91 0.00 0.00 1.00 1.00 2jlv 0.00 0.10 0.00 0.00 0.00 0.00 0.55 0.55 0.00 0.00 1.00 1.00 2nqp 0.00 0.20 0.00 0.00 0.00 0.00 0.73 0.74 0.00 0.00 1.00 1.00 2nug 0.00 1.00 0.00 0.03 0.00 0.05 0.96 0.96 0.00 0.03 1.00 1.00 2ozb 0.10 1.00 0.00 0.00 0.00 0.01 0.63 0.63 0.00 0.00 1.00 1.00 2pjp 0.10 0.60 0.00 0.00 0.00 0.00 0.70 0.70 0.00 0.00 1.00 1.00 2po1 1.00 0.30 0.00 0.00 0.00 0.00 0.09 0.09 0.00 0.00 1.00 0.99 2qux 0.10 0.00 0.00 0.00 0.00 0.00 0.81 0.81 0.00 0.00 1.00 1.00 2r7r 0.00 0.70 0.00 0.00 0.00 0.00 0.58 0.58 0.00 0.00 1.00 1.00 2r8s 0.80 0.90 0.00 0.00 0.00 0.00 0.27 0.27 0.00 0.00 1.00 1.00 2vnu 0.00 0.20 0.00 0.00 0.00 0.00 0.75 0.75 0.00 0.00 1.00 1.00 2voo 1.00 1.00 0.00 0.00 0.00 0.00 0.25 0.25 0.00 0.00 1.00 1.00 2w2h 0.20 1.00 0.00 0.00 0.00 0.00 0.45 0.45 0.00 0.00 1.00 1.00 2wj8 0.00 0.80 0.00 0.00 0.00 0.01 0.76 0.76 0.00 0.00 1.00 1.00 2z2q 0.30 0.60 0.00 0.00 0.00 0.00 0.41 0.41 0.00 0.00 1.00 1.00 2zi0 0.00 0.60 0.00 0.00 0.00 0.00 0.21 0.21 0.00 0.00 1.00 1.00 2zko 0.00 0.10 0.00 0.00 0.00 0.00 0.87 0.87 0.00 0.00 1.00 1.00 Resultats globaux des 120 complexes de la P ´ RIDB sous le seuil du top10 des candidats : avec les mesures d’evaluation globales pour chacun des complexes pour la ´ fonction de score par defaut de RosettaDock (ROS) et la fonction de score atomique ´ apprise avec ROGER (POS). 147Precision ´ Rappel Fscore Accuracy Sensibilite´ Specificit ´ e´ pdb ROS POS ROS POS ROS POS ROS POS ROS POS ROS POS 2zni 0.00 1.00 0.00 0.00 0.00 0.01 0.73 0.73 0.00 0.00 1.00 1.00 2zue 0.00 1.00 0.00 0.00 0.00 0.00 0.51 0.51 0.00 0.00 1.00 1.00 2zzm 0.00 1.00 0.00 0.01 0.00 0.02 0.87 0.88 0.00 0.01 1.00 1.00 3a6p 0.00 0.70 0.00 0.00 0.00 0.01 0.80 0.80 0.00 0.00 1.00 1.00 3bso 0.00 0.00 0.00 0.00 0.00 0.00 0.75 0.75 0.00 0.00 1.00 1.00 3bt7 0.10 1.00 0.00 0.00 0.00 0.00 0.46 0.46 0.00 0.00 1.00 1.00 3ciy 0.40 0.30 0.00 0.00 0.00 0.00 0.44 0.44 0.00 0.00 1.00 1.00 3d2s 0.60 1.00 0.00 0.00 0.00 0.00 0.11 0.11 0.00 0.00 1.00 1.00 3dd2 0.00 0.30 0.00 0.00 0.00 0.00 0.75 0.75 0.00 0.00 1.00 1.00 3egz 0.60 0.90 0.00 0.00 0.00 0.00 0.48 0.48 0.00 0.00 1.00 1.00 3eph 0.00 1.00 0.00 0.01 0.00 0.02 0.90 0.90 0.00 0.01 1.00 1.00 3eqt 0.20 1.00 0.00 0.00 0.00 0.00 0.48 0.48 0.00 0.00 1.00 1.00 3ex7 0.00 1.00 0.00 0.00 0.00 0.00 0.25 0.25 0.00 0.00 1.00 1.00 3fht 0.00 1.00 0.00 0.00 0.00 0.00 0.17 0.18 0.00 0.00 0.99 1.00 3foz 0.00 1.00 0.00 0.01 0.00 0.01 0.86 0.87 0.00 0.01 1.00 1.00 3gib 0.00 0.50 0.00 0.00 0.00 0.00 0.77 0.77 0.00 0.00 1.00 1.00 3hax 0.10 1.00 0.00 0.01 0.00 0.02 0.90 0.90 0.00 0.01 1.00 1.00 3hl2 0.00 1.00 0.00 0.00 0.00 0.00 0.09 0.09 0.00 0.00 0.99 1.00 3htx 0.00 0.90 0.00 0.01 0.00 0.02 0.89 0.90 0.00 0.01 1.00 1.00 3i5x 0.00 1.00 0.00 0.00 0.00 0.00 0.32 0.32 0.00 0.00 1.00 1.00 3iab 0.00 1.00 0.00 0.00 0.00 0.00 0.52 0.52 0.00 0.00 1.00 1.00 3icq 0.00 0.90 0.00 0.00 0.00 0.00 0.49 0.49 0.00 0.00 1.00 1.00 3iev 0.80 1.00 0.00 0.00 0.00 0.00 0.21 0.21 0.00 0.00 1.00 1.00 3k62 0.90 1.00 0.00 0.00 0.00 0.00 0.15 0.15 0.00 0.00 1.00 1.00 3l25 0.00 0.90 0.00 0.01 0.00 0.01 0.88 0.88 0.00 0.01 1.00 1.00 3snp 0.10 1.00 0.00 0.00 0.00 0.01 0.68 0.68 0.00 0.00 1.00 1.00 TABLE S2 – Resultats globaux des 120 complexes de la P ´ RIDB sous le seuil du top10 des candidats : avec les mesures d’evaluation globales pour chacun des complexes ´ pour la fonction de score par defaut de RosettaDock (ROS) et la fonction de score ´ atomique apprise avec ROGER (POS). 148Precision ´ Rappel Fscore Accuracy Sensibilite´ Specificit ´ e´ pdb ROS POS ROS POS ROS POS ROS POS ROS POS ROS POS 1b7f 0.36 0.75 1.00 0.73 0.53 0.74 0.36 0.82 1.00 0.73 0.00 0.87 1c9s 0.59 0.64 1.00 0.94 0.74 0.77 0.59 0.66 1.00 0.94 0.00 0.25 1dk1 0.77 0.81 1.00 0.97 0.87 0.88 0.77 0.80 1.00 0.97 0.00 0.25 1e7k 0.34 0.34 0.98 1.00 0.50 0.50 0.35 0.34 0.98 1.00 0.04 0.00 1ec6 0.18 0.22 0.99 0.81 0.30 0.34 0.20 0.46 0.99 0.81 0.03 0.39 1efw 0.64 0.73 1.00 0.91 0.78 0.81 0.64 0.73 1.00 0.91 0.00 0.41 1ekz 0.19 0.19 0.89 0.96 0.31 0.31 0.30 0.25 0.89 0.96 0.17 0.09 1g1x 0.88 0.88 1.00 1.00 0.93 0.93 0.88 0.88 1.00 1.00 0.00 0.00 1hc8 0.94 0.95 1.00 1.00 0.97 0.97 0.94 0.94 1.00 1.00 0.00 0.07 1hvu 0.44 0.50 0.99 0.90 0.61 0.65 0.45 0.57 0.99 0.90 0.03 0.32 1jbr 0.92 0.92 1.00 1.00 0.96 0.96 0.92 0.92 1.00 1.00 0.00 0.00 1kog 0.15 0.16 1.00 0.94 0.27 0.28 0.15 0.25 1.00 0.94 0.00 0.12 1kq2 0.26 0.42 1.00 0.65 0.41 0.51 0.26 0.67 1.00 0.65 0.00 0.68 1m5o 0.47 0.66 1.00 0.91 0.64 0.77 0.47 0.74 1.00 0.91 0.00 0.57 1m8w 0.83 0.84 1.00 1.00 0.91 0.91 0.83 0.84 1.00 1.00 0.00 0.02 1mfq 0.78 0.78 1.00 1.00 0.88 0.87 0.78 0.78 1.00 1.00 0.02 0.00 1mms 0.89 0.90 1.00 0.99 0.94 0.94 0.89 0.89 1.00 0.99 0.00 0.13 1msw 0.08 0.91 1.00 0.99 0.16 0.95 0.08 0.99 1.00 0.99 0.00 0.99 1ob2 0.46 0.67 1.00 0.83 0.63 0.74 0.46 0.73 1.00 0.83 0.00 0.65 1t4l 0.79 0.79 1.00 1.00 0.88 0.88 0.79 0.79 1.00 1.00 0.00 0.00 1ttt 0.47 0.59 1.00 0.89 0.64 0.71 0.47 0.65 1.00 0.89 0.00 0.44 1u63 0.83 0.86 1.00 0.97 0.91 0.91 0.83 0.84 1.00 0.97 0.00 0.22 1wne 0.22 0.92 1.00 0.99 0.36 0.95 0.22 0.98 1.00 0.99 0.00 0.98 1zbi 0.22 0.37 1.00 0.71 0.37 0.49 0.22 0.67 1.00 0.71 0.00 0.66 2ad9 0.92 0.92 1.00 1.00 0.96 0.96 0.92 0.92 1.00 1.00 0.00 0.01 2adb 0.92 0.95 1.00 0.97 0.96 0.96 0.92 0.93 1.00 0.97 0.00 0.48 2adc 0.69 0.85 1.00 0.85 0.82 0.85 0.69 0.79 1.00 0.85 0.00 0.67 2b6g 0.52 0.52 1.00 1.00 0.69 0.69 0.52 0.52 1.00 1.00 0.00 0.00 2c0b 0.39 0.67 1.00 0.82 0.57 0.73 0.39 0.77 1.00 0.82 0.00 0.73 2dra 0.14 0.63 1.00 0.67 0.25 0.65 0.14 0.90 1.00 0.67 0.00 0.93 2err 0.83 0.92 1.00 0.97 0.90 0.95 0.83 0.91 1.00 0.97 0.00 0.60 2ez6 0.52 0.53 1.00 0.98 0.69 0.69 0.53 0.54 1.00 0.98 0.01 0.06 2hgh 0.54 0.76 1.00 0.80 0.70 0.78 0.54 0.75 1.00 0.80 0.00 0.70 2i91 0.17 0.81 1.00 0.85 0.29 0.83 0.17 0.94 1.00 0.85 0.00 0.96 2ix1 0.18 0.66 1.00 0.91 0.30 0.76 0.18 0.90 1.00 0.91 0.00 0.89 2py9 0.80 0.88 1.00 0.98 0.89 0.92 0.80 0.87 1.00 0.98 0.00 0.44 3bo2 0.37 0.55 1.00 0.89 0.54 0.68 0.37 0.69 1.00 0.89 0.00 0.57 3bsb 0.83 0.84 1.00 1.00 0.91 0.91 0.83 0.84 1.00 1.00 0.00 0.02 3bsx 0.84 0.85 1.00 1.00 0.92 0.92 0.84 0.85 1.00 1.00 0.00 0.02 3bx2 0.86 0.87 1.00 0.99 0.92 0.93 0.86 0.86 1.00 0.99 0.00 0.07 TABLE S3 – Resultats globaux des ´ Benchmarks I et II : avec les mesures d’evaluation ´ globales pour chacun des complexes pour la fonction de score par defaut de Rosetta- ´ Dock (ROS) et la fonction de score atomique apprise avec ROGER (POS). 149Precision ´ Rappel Fscore Accuracy Sensibilite´ Specificit ´ e´ pdb ROS POS ROS POS ROS POS ROS POS ROS POS ROS POS 1m5o 0.48 0.66 1.00 0.81 0.65 0.73 0.48 0.71 1.00 0.81 0.00 0.62 1qtq 0.28 0.73 1.00 0.76 0.44 0.74 0.28 0.85 1.00 0.76 0.00 0.89 1wpu 0.87 0.88 1.00 1.00 0.93 0.93 0.87 0.88 1.00 1.00 0.00 0.05 1yvp 0.94 0.94 1.00 1.00 0.97 0.97 0.94 0.94 1.00 1.00 0.00 0.00 1zbh 0.98 0.99 1.00 1.00 0.99 0.99 0.98 0.99 1.00 1.00 0.00 0.21 2ad9 0.00 0.00 1.00 1.00 0.00 0.01 0.02 0.98 1.00 1.00 0.02 0.98 TABLE S4 – Resultats globaux des 6 complexes avec prot ´ eine non li ´ ee : avec les ´ mesures d’evaluation globales pour chacun des complexes pour la fonction de score ´ par defaut de RosettaDock (ROS) et la fonction de score atomique apprise avec ´ ROGER (POS). 150pdb ES Top10 Top100 # presque-natifs ROC-AUC ROS POS ROS POS Attendu ROS POS ROS POS 1b7f 0.47 5.15 1 10 3.58 1 100 3579 0.32 0.89 1c9s 0.90 1.19 6 7 5.91 25 81 5905 0.37 0.69 1dk1 2.32 2.58 9 8 7.66 89 97 7660 0.61 0.82 1e7k 0.67 1.33 2 1 3.36 11 16 3359 0.50 0.53 1ec6 0.31 0.88 1 0 1.73 3 14 1730 0.44 0.60 1efw 0.41 2.90 0 10 6.37 0 96 6366 0.33 0.79 1ekz 0.95 0.81 4 1 1.77 18 20 1768 0.52 0.52 1g1x 3.32 0.54 2 6 8.76 85 82 8764 0.59 0.51 1hc8 1.56 3.63 10 10 9.43 94 100 9433 0.49 0.79 1hvu 0.77 1.93 2 2 4.37 42 48 4366 0.50 0.70 1jbr 3.56 0.02 9 9 9.23 71 86 9229 0.45 0.65 1kog 0.95 1.14 3 1 1.53 11 23 1532 0.49 0.54 1kq2 0.09 5.40 0 9 2.60 0 89 2602 0.31 0.74 1m5o 1.06 1.33 6 5 4.75 6 78 4748 0.24 0.83 1m8w 1.79 1.27 4 10 8.34 80 97 8343 0.37 0.74 1mfq 1.36 2.35 10 3 7.76 91 52 7757 0.62 0.59 1mms 2.52 3.31 10 9 8.86 85 96 8859 0.50 0.86 1msw 0.00 8.84 0 10 0.84 0 98 841 0.08 1.00 1ob2 0.78 3.38 7 10 4.63 12 97 4625 0.41 0.83 1t4l 0.56 1.64 10 10 7.85 98 95 7852 0.52 0.61 1ttt 0.76 3.25 6 10 4.69 11 97 4691 0.39 0.78 1u63 3.14 1.13 7 10 8.34 72 100 8338 0.44 0.86 1wne 0.01 4.41 0 7 2.21 0 96 2213 0.17 0.99 1zbi 0.37 2.95 0 8 2.23 0 69 2231 0.34 0.75 2ad9 1.99 2.53 10 10 9.18 84 100 9179 0.31 0.90 2adb 1.03 3.37 10 10 9.18 75 100 9180 0.25 0.89 2adc 3.38 2.61 3 10 6.94 40 100 6940 0.44 0.86 2b6g 1.73 0.02 9 6 5.23 93 62 5228 0.58 0.42 2c0b 0.00 2.98 0 8 3.94 0 91 3937 0.26 0.86 2dra 0.03 6.16 0 8 1.42 0 88 1419 0.32 0.91 2err 1.27 2.48 8 10 8.26 20 100 8263 0.15 0.92 2ez6 1.42 2.92 10 9 5.24 87 67 5235 0.58 0.62 2hgh 0.74 1.03 0 4 5.39 0 69 5387 0.25 0.82 2i91 0.47 7.35 0 10 1.73 0 95 1726 0.28 0.98 2ix1 0.02 2.14 0 4 1.80 0 55 1795 0.17 0.94 2py9 4.28 2.95 9 10 8.01 89 98 8014 0.50 0.83 3bo2 0.66 2.73 4 6 3.66 4 82 3663 0.31 0.80 3bsb 1.60 1.55 7 10 8.35 81 100 8348 0.36 0.80 3bsx 1.60 1.20 3 10 8.45 83 100 8448 0.32 0.82 3bx2 1.83 3.09 8 10 8.60 75 100 8595 0.33 0.84 TABLE S5 – Resultats pour les 40 complexes utilis ´ es des ´ Benchmarks I et II : score d’enrichissement (ES), nombre de presque-natifs dans le top10, nombre de presquenatifs attendus en moyenne par un tri aleatoire, nombre de presque-natifs dans le ´ top100, nombre de presque-natifs sur les 10 000 structures et aire sous la courbe ROC (ROC-AUC) sur 10 000 candidats par pdb evalu ´ e.´ 151pdb ES Top10 Top100 # presque-natifs ROC-AUC ROS POS ROS POS Attendu ROS POS ROS POS 1m5o 0.43 4.75 0 4 4.79 3 66 4790 0.25 0.79 1qtq 0.00 6.09 0 10 2.80 0 98 2798 0.24 0.91 1wpu 1.60 3.15 9 10 8.72 71 100 8723 0.47 0.70 1yvp 0.93 0.20 6 10 9.36 61 100 9362 0.29 0.81 1zbh 0.88 0.00 5 10 9.83 82 100 9834 0.12 0.96 2ad9 0.00 6.06 0 0 0.00 0 0 1 0.02 0.98 TABLE S6 – Resultats pour les 6 complexes dans le cas de la prot ´ eine non li ´ ee des ´ Benchmarks I et II : score d’enrichissement (ES), nombre de presque-natifs dans le top10, nombre de presque-natifs attendus en moyenne par un tri aleatoire, nombre de ´ presque-natifs dans le top100, nombre de presque-natifs sur les 10 000 structures et aire sous la courbe ROC (ROC-AUC) sur 10 000 candidats par pdb evalu ´ e.´ 152pdb ES Top10 Attendu Top100 # presque-natifs ROC-AUC 1asy 2.35 0 0.008 0 8 0.59 1av6 2.43 5 0.654 19 654 0.71 1b23 1.67 0 0.024 1 24 0.72 1c0a 1.89 0 0.001 0 1 0.77 1ddl 1.21 0 0.327 1 327 0.61 1dfu 1.20 2 0.743 9 743 0.66 1di2 0.93 0 0.114 0 114 0.52 1e8o 1.43 0 0.743 10 743 0.60 1f7u 2.56 0 0.007 1 7 0.86 1feu 1.97 2 0.378 17 378 0.69 1ffy 2.30 0 0.008 2 8 0.88 1fxl 4.43 8 0.589 64 589 0.85 1gtf 1.55 10 6.307 99 6307 0.70 1h3e 1.98 0 0.024 1 24 0.75 1h4s 1.73 0 0.036 1 36 0.67 1hq1 1.27 0 0.684 9 684 0.60 1j1u 1.66 0 0.112 1 112 0.54 1j2b 2.15 0 0.001 0 1 0.72 1jbs 2.57 0 0.499 20 499 0.71 1jid 1.91 1 0.377 11 377 0.65 1k8w 3.16 2 0.151 16 151 0.84 1knz 3.26 10 1.136 90 1136 0.73 1lng 1.80 2 0.13 6 130 0.65 1m8v 1.70 10 6.192 92 6192 0.61 1m8x 1.91 4 0.899 25 899 0.67 1mzp 1.85 2 0.148 8 148 0.69 1n35 4.40 2 0.017 17 17 1.00 1n78 2.08 0 0.01 1 10 0.83 1ooa 2.92 0 0.497 21 497 0.76 1pgl 1.85 2 0.898 26 898 0.63 1q2r 1.62 0 0.043 0 43 0.51 1qf6 2.06 0 0.005 1 5 0.85 1qtq 2.05 0 0.007 3 7 0.93 1r3e 1.78 0 0.028 0 28 0.59 1r9f 1.77 0 0.2 2 200 0.71 1sds 1.47 2 2.19 36 2190 0.67 1ser 1.95 0 0.008 1 8 0.88 1si3 2.33 4 0.547 23 547 0.69 1t0k 1.08 0 0.382 1 382 0.56 1tfw 2.99 0 0.004 0 4 0.98 1u0b 2.24 1 0.014 3 14 0.83 1un6 3.44 1 0.129 20 129 0.85 1uvj 5.06 8 0.357 62 357 0.94 1vfg 2.02 1 0.248 7 248 0.68 1wpu 1.53 1 1.162 21 1162 0.65 1wsu 1.26 0 2.288 20 2288 0.59 1wz2 2.18 0 0 0 0 1.00 Resultats de la fonction de score gros-grain VOR pour les 120 complexes de la P ´ RIDB : score d’enrichissement (ES), nombre de presque-natifs dans le top10, nombre de presque-natifs attendus en moyenne par un tri aleatoire, nombre de presque-natifs ´ dans le top100, nombre de presque-natifs sur les 10 000 structures et aire sous la courbe ROC (ROC-AUC) sur 10 000 candidats par pdb evalu ´ e.´ 153pdb ES Top10 Attendu Top100 # presque-natifs ROC-AUC 1yvp 1.72 1 0.13 4 130 0.64 1zbh 2.07 4 0.967 30 967 0.62 2a8v 2.22 10 5.018 90 5018 0.67 2anr 1.52 3 0.929 22 929 0.59 2asb 2.80 3 0.186 9 186 0.80 2az0 2.83 1 0.2 3 200 0.69 2azx 2.00 0 0.011 0 11 0.70 2b3j 2.39 2 0.426 29 426 0.71 2bgg 2.13 2 0.131 8 131 0.63 2bh2 3.23 0 0.051 12 51 0.84 2bte 2.46 0 0.002 1 2 0.98 2bu1 1.88 2 1.291 22 1291 0.65 2bx2 1.74 3 0.31 9 310 0.62 2ct8 1.92 0 0.029 1 29 0.64 2czj 2.69 2 0.207 9 207 0.76 2d6f 1.58 0 0.087 2 87 0.55 2der 1.10 0 0.029 0 29 0.72 2du3 1.20 0 0.186 1 186 0.56 2e9t 2.75 1 0.06 16 60 0.80 2f8k 1.33 3 3.82 52 3820 0.53 2f8s 1.21 0 0.076 0 76 0.39 2fk6 2.18 0 0.092 5 92 0.70 2fmt 1.82 0 0.018 0 18 0.67 2gic 4.48 7 0.103 38 103 0.94 2gje 2.11 0 0.079 3 79 0.72 2gjw 1.98 0 0.078 3 78 0.70 2gtt 3.91 5 0.069 24 69 0.91 2gxb 1.99 7 3.404 65 3404 0.64 2hw8 2.10 1 0.149 13 149 0.75 2i82 2.80 2 0.159 19 159 0.83 2iy5 1.22 0 0.001 0 1 0.51 2jlv 4.63 8 0.416 59 416 0.90 2nqp 2.10 1 0.296 15 296 0.70 2nug 2.19 0 0.001 0 1 0.97 2ozb 2.20 2 0.078 4 78 0.74 2pjp 2.14 1 0.576 15 576 0.65 2po1 1.91 1 0.19 4 190 0.65 2qux 2.53 1 0.26 7 260 0.74 2r7r 3.19 3 0.074 25 74 0.95 2r8s 1.31 0 0.039 0 39 0.56 2vnu 5.79 8 0.123 38 123 0.98 2voo 4.88 10 3.261 97 3261 0.77 2w2h 1.30 0 0.018 0 18 0.46 2wj8 3.08 3 0.43 29 430 0.79 2z2q 1.73 3 0.863 20 863 0.57 2zi0 0.86 3 1.278 15 1278 0.49 2zko 3.61 1 0.181 11 181 0.80 Resultats de la fonction de score gros-grain VOR pour les 120 complexes de la P ´ RIDB : score d’enrichissement (ES), nombre de presque-natifs dans le top10, nombre de presque-natifs attendus en moyenne par un tri aleatoire, nombre de presque-natifs ´ dans le top100, nombre de presque-natifs sur les 10 000 structures et aire sous la courbe ROC (ROC-AUC) sur 10 000 candidats par pdb evalu ´ e.´ 154pdb ES Top10 Attendu Top100 # presque-natifs ROC-AUC 2zni 1.91 1 0.017 2 17 0.83 2zue 2.77 0 0.004 0 4 0.95 2zzm 3.59 2 0.009 4 9 0.93 3a6p 2.19 0 0.001 1 1 0.99 3bso 2.74 2 0.038 12 38 0.85 3bt7 3.59 6 0.192 36 192 0.87 3ciy 1.43 0 0.01 2 10 0.79 3d2s 1.63 10 5.557 93 5557 0.62 3dd2 1.95 1 0.232 6 232 0.74 3egz 1.41 0 0.235 5 235 0.57 3eph 2.01 0 0.001 0 1 0.99 3eqt 3.87 2 0.405 24 405 0.80 3ex7 2.03 1 0.239 12 239 0.71 3fht 2.05 2 0.513 8 513 0.65 3foz 1.81 0 0.019 4 19 0.89 3gib 1.67 1 0.641 13 641 0.63 3hax 2.07 0 0.008 0 8 0.62 3hl2 2.07 0 0.015 1 15 0.67 3htx 1.59 0 0.014 0 14 0.65 3i5x 2.48 0 0.175 3 175 0.74 3iab 3.35 0 0.03 3 30 0.82 3icq 2.64 0 0.002 0 2 0.91 3iev 1.90 1 0.227 8 227 0.68 3k62 2.34 4 0.486 19 486 0.69 3l25 7.94 3 0.247 26 247 0.97 3snp 2.68 0 0.041 8 41 0.85 TABLE S7 – Resultats de la fonction de score gros-grain VOR pour les 120 com- ´ plexes de la PRIDB : score d’enrichissement (ES), nombre de presque-natifs dans le top10, nombre de presque-natifs attendus en moyenne par un tri aleatoire, nombre de ´ presque-natifs dans le top100, nombre de presque-natifs sur les 10 000 structures et aire sous la courbe ROC (ROC-AUC) sur 10 000 candidats par pdb evalu ´ e.´ 155pdb ES Top10 Attendu Top100 # presque-natifs ROC-AUC 1asy 0.43 0 0.008 0 8 0.35 1av6 0.46 0 0.654 0 654 0.37 1b23 1.16 0 0.024 0 24 0.60 1c0a 0.79 0 0.001 0 1 0.04 1ddl 1.12 0 0.327 0 327 0.53 1dfu 0.31 1 0.743 2 743 0.31 1di2 0.82 0 0.114 1 114 0.39 1e8o 0.88 0 0.743 0 743 0.54 1f7u 0.38 0 0.007 0 7 0.16 1feu 0.23 0 0.378 1 378 0.38 1ffy 0.65 0 0.008 0 8 0.15 1fxl 0.46 0 0.589 2 589 0.38 1gtf 1.27 7 6.307 53 6307 0.48 1h3e 0.51 0 0.024 0 24 0.36 1h4s 0.73 0 0.036 0 36 0.34 1hq1 0.50 0 0.684 0 684 0.41 1j1u 0.65 0 0.112 0 112 0.43 1j2b 0.16 0 0.001 0 1 0.12 1jbs 0.92 0 0.499 2 499 0.56 1jid 0.38 0 0.377 0 377 0.32 1k8w 1.58 0 0.151 0 151 0.47 1knz 0.10 0 1.136 1 1136 0.26 1lng 0.32 0 0.13 0 130 0.34 1m8v 0.48 0 6.192 34 6192 0.44 1m8x 0.40 0 0.899 6 899 0.41 1mzp 0.60 0 0.148 0 148 0.40 1n35 0.12 0 0.017 0 17 0.01 1n78 0.46 0 0.01 0 10 0.13 1ooa 0.15 0 0.497 2 497 0.27 1pgl 0.35 0 0.898 0 898 0.30 1q2r 1.00 0 0.043 1 43 0.46 1qf6 0.81 0 0.005 0 5 0.18 1qtq 0.59 0 0.007 0 7 0.09 1r3e 0.73 0 0.028 0 28 0.39 1r9f 0.49 0 0.2 0 200 0.38 1sds 0.69 4 2.19 15 2190 0.52 1ser 0.33 0 0.008 0 8 0.12 1si3 0.18 0 0.547 0 547 0.25 1t0k 0.19 0 0.382 1 382 0.33 1tfw 0.27 0 0.004 0 4 0.13 1u0b 0.37 0 0.014 0 14 0.14 1un6 0.21 0 0.129 0 129 0.20 1uvj 0.02 0 0.357 0 357 0.09 1vfg 0.51 0 0.248 0 248 0.40 1wpu 0.62 0 1.162 5 1162 0.48 1wsu 0.71 0 2.288 7 2288 0.50 1wz2 0.29 0 0 0 0 1.00 Resultats de la fonction de score gros-grain avec poids positifs pour les 120 com- ´ plexes de la PRIDB : score d’enrichissement (ES), nombre de presque-natifs dans le top10, nombre de presque-natifs attendus en moyenne par un tri aleatoire, nombre de ´ presque-natifs dans le top100, nombre de presque-natifs sur les 10 000 structures et aire sous la courbe ROC (ROC-AUC) sur 10 000 candidats par pdb evalu ´ e.´ 156pdb ES Top10 Attendu Top100 # presque-natifs ROC-AUC 1yvp 0.89 0 0.13 1 130 0.33 1zbh 0.23 0 0.967 0 967 0.29 2a8v 0.69 5 5.018 54 5018 0.46 2anr 0.35 0 0.929 1 929 0.38 2asb 0.32 0 0.186 0 186 0.27 2az0 0.64 0 0.2 0 200 0.32 2azx 0.76 0 0.011 0 11 0.33 2b3j 0.34 0 0.426 0 426 0.28 2bgg 0.52 0 0.131 0 131 0.50 2bh2 0.84 0 0.051 0 51 0.40 2bte 0.33 0 0.002 0 2 0.02 2bu1 0.35 1 1.291 4 1291 0.38 2bx2 0.90 0 0.31 0 310 0.35 2ct8 0.84 0 0.029 0 29 0.39 2czj 0.63 0 0.207 0 207 0.34 2d6f 0.53 0 0.087 0 87 0.49 2der 1.27 0 0.029 0 29 0.45 2du3 0.78 0 0.186 2 186 0.44 2e9t 0.40 0 0.06 0 60 0.27 2f8k 0.66 0 3.82 14 3820 0.47 2f8s 0.87 0 0.076 3 76 0.62 2fk6 0.48 0 0.092 0 92 0.34 2fmt 0.15 0 0.018 0 18 0.25 2gic 0.18 0 0.103 0 103 0.07 2gje 0.26 0 0.079 0 79 0.28 2gjw 0.45 0 0.078 0 78 0.54 2gtt 0.01 0 0.069 0 69 0.07 2gxb 0.16 1 3.404 8 3404 0.32 2hw8 0.27 0 0.149 0 149 0.21 2i82 0.49 0 0.159 0 159 0.21 2iy5 0.47 0 0.001 0 1 0.51 2jlv 0.54 0 0.416 1 416 0.17 2nqp 0.27 0 0.296 0 296 0.34 2nug 0.34 0 0.001 0 1 0.28 2ozb 1.10 0 0.078 2 78 0.52 2pjp 0.70 0 0.576 1 576 0.40 2po1 0.16 0 0.19 0 190 0.35 2qux 0.06 0 0.26 0 260 0.20 2r7r 0.48 0 0.074 0 74 0.45 2r8s 0.62 0 0.039 0 39 0.50 2vnu 0.21 0 0.123 0 123 0.18 2voo 0.00 0 3.261 3 3261 0.34 2w2h 0.81 0 0.018 0 18 0.52 2wj8 0.01 0 0.43 0 430 0.17 2z2q 0.71 0 0.863 2 863 0.45 2zi0 1.07 1 1.278 14 1278 0.51 2zko 0.32 0 0.181 0 181 0.17 Resultats de la fonction de score gros-grain avec poids positifs pour les 120 com- ´ plexes de la PRIDB : score d’enrichissement (ES), nombre de presque-natifs dans le top10, nombre de presque-natifs attendus en moyenne par un tri aleatoire, nombre de ´ presque-natifs dans le top100, nombre de presque-natifs sur les 10 000 structures et aire sous la courbe ROC (ROC-AUC) sur 10 000 candidats par pdb evalu ´ e.´ 157pdb ES Top10 Attendu Top100 # presque-natifs ROC-AUC 2zni 0.45 0 0.017 0 17 0.16 2zue 0.18 0 0.004 0 4 0.15 2zzm 0.37 0 0.009 0 9 0.11 3a6p 0.34 0 0.001 0 1 0.31 3bso 0.57 0 0.038 0 38 0.22 3bt7 0.63 0 0.192 0 192 0.17 3ciy 0.89 0 0.01 0 10 0.23 3d2s 1.00 5 5.557 47 5557 0.49 3dd2 0.68 0 0.232 0 232 0.36 3egz 0.67 0 0.235 1 235 0.38 3eph 0.18 0 0.001 0 1 0.01 3eqt 0.21 0 0.405 0 405 0.22 3ex7 1.09 0 0.239 1 239 0.46 3fht 0.88 0 0.513 2 513 0.51 3foz 0.82 0 0.019 0 19 0.20 3gib 0.62 0 0.641 2 641 0.41 3hax 0.83 0 0.008 0 8 0.40 3hl2 0.48 0 0.015 0 15 0.42 3htx 0.77 0 0.014 0 14 0.36 3i5x 0.19 0 0.175 0 175 0.21 3iab 0.05 0 0.03 0 30 0.15 3icq 0.20 0 0.002 0 2 0.08 3iev 0.31 0 0.227 0 227 0.19 3k62 0.34 0 0.486 1 486 0.31 3l25 0.04 0 0.247 0 247 0.08 3snp 0.63 0 0.041 0 41 0.31 TABLE S8 – Resultats de la fonction de score gros-grain avec poids positifs pour les 120 ´ complexes de la PRIDB : score d’enrichissement (ES), nombre de presque-natifs dans le top10, nombre de presque-natifs attendus en moyenne par un tri aleatoire, nombre ´ de presque-natifs dans le top100, nombre de presque-natifs sur les 10 000 structures et aire sous la courbe ROC (ROC-AUC) sur 10 000 candidats par pdb evalu ´ e.´ 158pdb ES Top10 Attendu Top100 # presque-natifs ROC-AUC 1asy 0.69 0 0.008 0 8 0.46 1av6 0.93 0 0.654 2 654 0.48 1b23 0.77 0 0.024 0 24 0.48 1c0a 0.81 0 0.001 0 1 0.48 1ddl 1.04 0 0.327 1 327 0.48 1dfu 1.08 2 0.743 14 743 0.52 1di2 1.06 1 0.114 1 114 0.45 1e8o 0.80 0 0.743 5 743 0.49 1f7u 0.52 0 0.007 0 7 0.38 1feu 1.07 1 0.378 4 378 0.48 1ffy 0.65 0 0.008 0 8 0.46 1fxl 0.63 0 0.589 0 589 0.45 1gtf 1.12 8 6.307 65 6307 0.51 1h3e 0.80 0 0.024 0 24 0.39 1h4s 0.86 0 0.036 0 36 0.46 1hq1 0.96 1 0.684 7 684 0.50 1j1u 0.98 1 0.112 3 112 0.55 1j2b 0.73 0 0.001 0 1 0.51 1jbs 0.86 0 0.499 1 499 0.49 1jid 1.04 0 0.377 4 377 0.48 1k8w 0.71 0 0.151 0 151 0.47 1knz 0.81 1 1.136 11 1136 0.50 1lng 0.97 0 0.13 0 130 0.45 1m8v 1.07 5 6.192 57 6192 0.49 1m8x 1.04 1 0.899 7 899 0.51 1mzp 0.93 0 0.148 0 148 0.44 1n35 0.73 0 0.017 0 17 0.27 1n78 0.71 0 0.01 0 10 0.45 1ooa 0.74 1 0.497 3 497 0.46 1pgl 1.04 2 0.898 6 898 0.50 1q2r 1.07 0 0.043 0 43 0.53 1qf6 0.85 0 0.005 0 5 0.52 1qtq 0.69 0 0.007 0 7 0.34 1r3e 1.07 0 0.028 0 28 0.45 1r9f 0.98 0 0.2 2 200 0.43 1sds 1.04 1 2.19 16 2190 0.50 1ser 0.82 0 0.008 0 8 0.41 1si3 0.80 0 0.547 3 547 0.46 1t0k 0.88 0 0.382 3 382 0.50 1tfw 0.95 0 0.004 0 4 0.61 1u0b 0.71 0 0.014 1 14 0.55 1un6 0.34 0 0.129 0 129 0.36 1uvj 0.94 1 0.357 5 357 0.51 1vfg 0.81 0 0.248 1 248 0.44 1wpu 0.96 2 1.162 6 1162 0.49 1wsu 1.02 4 2.288 29 2288 0.51 1wz2 0.60 0 0 0 0 1.00 Resultats de la fonction de score gros-grain non lin ´ eaire avec valeurs de centrage ´ pour les 120 complexes de la PRIDB : score d’enrichissement (ES), nombre de presque-natifs dans le top10, nombre de presque-natifs attendus en moyenne par un tri aleatoire, nombre de presque-natifs dans le top100, nombre de presque-natifs sur ´ les 10 000 structures et aire sous la courbe ROC (ROC-AUC) sur 10 000 candidats par pdb evalu ´ e. ´ 159pdb ES Top10 Attendu Top100 # presque-natifs ROC-AUC 1yvp 0.99 0 0.13 3 130 0.48 1zbh 0.87 0 0.967 4 967 0.48 2a8v 0.77 3 5.018 43 5018 0.49 2anr 0.71 0 0.929 4 929 0.47 2asb 0.86 0 0.186 0 186 0.46 2az0 1.40 1 0.2 5 200 0.51 2azx 0.83 0 0.011 1 11 0.52 2b3j 0.66 0 0.426 1 426 0.49 2bgg 0.92 0 0.131 2 131 0.53 2bh2 0.65 0 0.051 1 51 0.39 2bte 0.55 0 0.002 0 2 0.17 2bu1 0.96 1 1.291 8 1291 0.49 2bx2 1.09 0 0.31 0 310 0.48 2ct8 0.75 0 0.029 0 29 0.39 2czj 0.75 0 0.207 1 207 0.49 2d6f 1.00 0 0.087 3 87 0.53 2der 0.94 0 0.029 0 29 0.48 2du3 0.91 0 0.186 3 186 0.47 2e9t 0.91 1 0.06 2 60 0.49 2f8k 1.06 5 3.82 43 3820 0.49 2f8s 1.04 0 0.076 2 76 0.53 2fk6 0.65 0 0.092 0 92 0.41 2fmt 0.89 0 0.018 0 18 0.41 2gic 0.40 0 0.103 0 103 0.42 2gje 0.69 0 0.079 0 79 0.49 2gjw 0.89 0 0.078 0 78 0.47 2gtt 0.40 0 0.069 0 69 0.34 2gxb 0.96 4 3.404 39 3404 0.49 2hw8 0.59 0 0.149 0 149 0.39 2i82 0.86 0 0.159 2 159 0.46 2iy5 0.87 0 0.001 0 1 0.02 2jlv 1.01 1 0.416 6 416 0.50 2nqp 0.84 0 0.296 1 296 0.51 2nug 1.09 0 0.001 0 1 0.42 2ozb 0.64 0 0.078 0 78 0.47 2pjp 0.86 0 0.576 1 576 0.49 2po1 0.86 0 0.19 1 190 0.48 2qux 0.79 0 0.26 1 260 0.46 2r7r 0.73 0 0.074 0 74 0.40 2r8s 0.85 0 0.039 0 39 0.52 2vnu 0.49 0 0.123 0 123 0.27 2voo 1.07 3 3.261 27 3261 0.49 2w2h 1.14 0 0.018 0 18 0.47 2wj8 0.74 0 0.43 2 430 0.47 2z2q 0.97 2 0.863 10 863 0.49 2zi0 1.09 1 1.278 13 1278 0.51 2zko 1.37 1 0.181 6 181 0.53 Resultats de la fonction de score gros-grain non lin ´ eaire avec valeurs de centrage ´ pour les 120 complexes de la PRIDB : score d’enrichissement (ES), nombre de presque-natifs dans le top10, nombre de presque-natifs attendus en moyenne par un tri aleatoire, nombre de presque-natifs dans le top100, nombre de presque-natifs sur ´ les 10 000 structures et aire sous la courbe ROC (ROC-AUC) sur 10 000 candidats par pdb evalu ´ e. ´ 160pdb ES Top10 Attendu Top100 # presque-natifs ROC-AUC 2zni 0.75 0 0.017 0 17 0.47 2zue 0.64 0 0.004 0 4 0.26 2zzm 0.67 0 0.009 0 9 0.36 3a6p 1.16 0 0.001 0 1 0.11 3bso 0.66 0 0.038 0 38 0.38 3bt7 0.47 0 0.192 0 192 0.45 3ciy 1.07 0 0.01 0 10 0.62 3d2s 0.91 3 5.557 49 5557 0.48 3dd2 0.87 1 0.232 6 232 0.50 3egz 0.98 0 0.235 0 235 0.47 3eph 0.83 0 0.001 0 1 0.59 3eqt 0.40 0 0.405 1 405 0.45 3ex7 0.85 0 0.239 1 239 0.47 3fht 0.99 0 0.513 3 513 0.49 3foz 0.72 0 0.019 0 19 0.30 3gib 0.84 0 0.641 3 641 0.49 3hax 0.86 0 0.008 0 8 0.39 3hl2 0.76 0 0.015 0 15 0.51 3htx 0.99 0 0.014 0 14 0.54 3i5x 0.90 0 0.175 1 175 0.52 3iab 0.67 0 0.03 0 30 0.52 3icq 0.71 0 0.002 0 2 0.46 3iev 0.82 0 0.227 0 227 0.45 3k62 0.87 0 0.486 3 486 0.48 3l25 0.35 0 0.247 0 247 0.42 3snp 0.70 0 0.041 0 41 0.50 TABLE S9 – Resultats de la fonction de score gros-grain non lin ´ eaire avec valeurs de ´ centrage pour les 120 complexes de la PRIDB : score d’enrichissement (ES), nombre de presque-natifs dans le top10, nombre de presque-natifs attendus en moyenne par un tri aleatoire, nombre de presque-natifs dans le top100, nombre de presque-natifs ´ sur les 10 000 structures et aire sous la courbe ROC (ROC-AUC) sur 10 000 candidats par pdb evalu ´ e. ´ 161pdb Description prot´eine Nombre d’acides amin´es Description ARN Nombre d’acides nucl´eiques Type 2zi0 Tomato aspermy virus protein 2b 60 siRNA 40 dsRNA 2gxb H. sapiens dsRNA-specific adenosine deaminase 62 dsRNA 5’-UCGCGCG-3’ and 5’-CGCGCG-3’ 13 dsRNA 1hq1 E. coli signal recognition particle protein 76 4.5S RNA domain IV 49 dsRNA 2f8k S. cerevisiae VTS1 protein SAM domain 84 5’-UAAUCUUUGACAGAUU-3’ 16 dsRNA 1lng M. jannaschii signal recognition particle 19 kDa protein 87 7S.S signal recognition particle RNA 97 dsRNA 3egz H. sapiens U1 small nuclear ribonucleoprotein A 91 Tetracyclin haptamer and artificial riboswitch 65 dsRNA 1dfu E. coli ribosomal protein L25 94 5S rRNA fragment 38 dsRNA 1jid H. sapiens signal recognition particle 19 kDa protein 114 signal recognition particle RNA helix 6 29 dsRNA 2pjp E. coli selenocysteine-specific elongation factor selB 121 SECIS RNA 23 dsRNA 1r9f Tomato bushy stunt virus core protein 19 121 siRNA 40 dsRNA 2czj T. thermophilus SsrA-binding protein 122 tmRNA tRNA domain 62 dsRNA 1wsu M. thermoacetica selenocystein-specific elongation factor 124 5’-GGCGUUGCCGGUCGGCAACGCC-3’ 22 dsRNA 2bu1 E. phage MS2 coat protein 129 5’-CAUGAGGAUUACCCAUG-3’ 17 dsRNA 1di2 X. laevis protein A dsRNA-binding domain 129 dsRNA 5’-GGCGCGCGCC-3’ tetramer 40 dsRNA 2zko Influenza A virus non-structural protein 1 (NS1) 140 dsRNA 42 dsRNA 2az0 Flock house virus B2 protein 141 dsRNA 5’-GCAUGGACGCGUCCAUGC-3’ dimer 36 dsRNA 1jbs A. restrictus restrictocin 142 29-mer sarcin/ricin domain RNA analog 29 dsRNA 1un6 X. laevis transcription factor IIIA 145 5S rRNA fragment 61 dsRNA 1e8o H. sapiens signal recognition particle 9 kDa and 14 kDa protein 149 7SL RNA 49 dsRNA 2anr H. sapiens neuro-oncological ventral antigen 1 (NOVA 1) 155 5’-CUCGCGGAUCAGUCACCCAAGCGAG-3’ 25 dsRNA 1feu T. thermophilus 50S ribosomal protein L25 185 5S rRNA fragment 40 dsRNA 2i82 E. coli ribosomal large subunit pseudouridine synthase A 217 5’-GAGGGGAAUGAAAAUCCCCUC-3’ 21 dsRNA 1mzp S. acidocaldarius 50S ribosomal protein L1P 217 23S rRNA fragment 55 dsRNA 1zbh H. sapiens 3’-5’ exonuclease ERI1 224 histone mRNA stem-loop 16 dsRNA 2hw8 T. thermophilus 50S ribosomal protein L1 228 mRNA 36 dsRNA 2qux P. phage coat protein 244 dsRNA 25 dsRNA 3iab S. cerevisiae ribonuclease P/MRP protein subunit POP6 255 Ribonuclease MRP RNA component P3 domain 46 dsRNA and POP7 3eqt H. sapiens ATP-dependent RNA helicase DHX58 269 5’-GCGCGCGC-3’ 8 dsRNA 3dd2 H. sapiens thrombine 288 dsRNA 26 dsRNA 2b3j S. aureus tRNA adenosine deaminase (tAdA) 302 tRNA-ARG2 anticodon stem-loop 15 dsRNA 1k8w E. coli tRNA-PseudoU synthase B 304 T stem-loop RNA 22 dsRNA Codes PDB des complexes prot´eine-ARN utilis´es dans la PRIDB non redondante RB199, avec une description de la prot´eine et de l’ARN, ainsi que le nombre d’acides amin´es #aa et d’acides nucl´eiques #an dans la structure 3D. Le type d’ARN est aussi indiqu´e entre simple brin (ssRNA), double brin (dsRNA) et ARN de transfert (tRNA). 162pdb Description prot´eine Nombre d’acides amin´es Description ARN Nombre d’acides nucl´eiques Type 1r3e T. maritima tRNA-PseudoU synthase B 305 tRNA-PseudoU T-arm 51 dsRNA 1ooa M. musculus nuclear factor NF-kappa-B p105 subunit 313 RNA aptamer 29 dsRNA 1vfg A. aeolicus tRNA nucleotidyltransferase 342 Primer tRNA 31 dsRNA 2ozb H. sapiens U4/U6 small nuclear ribonucleoprotein Prp31 365 U4snRNA 5’ stem-loop 33 dsRNA 3bt7 E. coli tRNA (uracile-5)-methyltransferase 369 19 nucleotide T-arm analogue 19 dsRNA 2bgg A. fulgidus piwi AF1318 protein 395 dsRNA 5’-UUCGACGC-3’ and 5’-GUCGAAUU-3’ 16 dsRNA 2r8s M. musculus synthetic FAB 433 P4-P6 RNA ribozyme domain 159 dsRNA 2nug A. aeolicus ribonuclease III 434 dsRNA 44 dsRNA 1t0k E. coli maltose-binding periplasmic-protein 462 mRNA 3’ consensus 5’-UGACC-3’ 27 dsRNA and S. cerevisiae 60S ribosomal protein L30 2e9t Foot-and-mouth disease virus RNA-dependent RNA polymerase 474 dsRNA 5’-UAGGGCCC-3’ and 5’-GGGCCCU-3’ 15 dsRNA 3bso Norwalk virus RNA-dependent RNA polymerase 479 primer-template RNA 16 dsRNA 3l25 Ebola virus polymerase cofactor VP35 492 dsRNA 5’-CGCAUGCG-3’ dimer 16 dsRNA 1yvp X. laevis 60 kDa SS-A Ro ribonucleoprotein 529 Both strands of the Y RNA sequence 20 dsRNA 2w2h Equine infectious anemia virus protein TAT 581 TAR RNA 44 dsRNA and E. caballus cyclin-T1 2gjw A. fulgidus tRNA-splicing endonuclease 612 dsRNA 37 dsRNA 3ciy M. musculus toll-like receptor 3 661 dsRNA 92 dsRNA 1q2r Z. mobilis queunine tRNA ribosyltransferase 748 dsRNA 5’-AGCACGGCUNUAAACCGUGC-3’ dimer 40 dsRNA 3htx A. thaliana RNA methyltransferase HEN1 780 dsRNA 44 dsRNA 3snp O. cuniculus cytoplasmic aconitate hydratase 850 Ferritin H IRE RNA 30 dsRNA 1tfw A. fulgidus tRNA nucleotidyltransferase 874 Immature tRNA 26 dsRNA 3icq S. cerevisiae GTP-binding nuclear protein GSP1/CNR1 1116 dsRNA 62 dsRNA and S. pombe exportin-T 3a6p H. sapiens exportin-5 1242 pre-miRNA 46 dsRNA 1n35 M. orthoreovirus minor core protein lambda 3 1264 dsRNA 5’-GGGGG-3’ and 5’-UAGCCCCC-3’ 13 dsRNA 2f8s A. aeolicus argonaute protein 1408 dsRNA 5’-AGACAGCAUAUAUGCUGUCUUU-3’ dimer 44 dsRNA 1m8v P. abyssi putative snRNP sm-like protein 72 5’-UUUUUU-3’ 6 ssRNA 1sds M. jannaschii 50S ribosomal protein L7Ae 112 Archeal box H/ACA sRNA K-turn 15 ssRNA 2a8v E. coli rho-dependent transcription termination 118 5’-CCC-3’ 3 ssRNA factor RNA-binding domain 1si3 H. sapiens eukaryotic translation initiation factor 2C 1 120 5’-CGUGACUCU-3’ 9 ssRNA Codes PDB des complexes prot´eine-ARN utilis´es dans la PRIDB non redondante RB199, avec une description de la prot´eine et de l’ARN, ainsi que le nombre d’acides amin´es #aa et d’acides nucl´eiques #an dans la structure 3D. Le type d’ARN est aussi indiqu´e entre simple brin (ssRNA), double brin (dsRNA) et ARN de transfert (tRNA). 163pdb Description prot´eine Nombre d’acides amin´es Description ARN Nombre d’acides nucl´eiques Type 3d2s H. sapiens musculeblind-like protein 1 (MBNL1) 135 5’-GCUGU-3’ 5 ssRNA 1gtf G. staerothermophilus TRP RNA-binding attenuation protein 142 5’-GAGU-3’ 4 ssRNA 1wpu B. subtilis hut operon positive regulatory protein 148 5’-UUGAGUU-3’ 7 ssRNA 1fxl P. encephalomyelitis antigen hud 167 5’-UUUUAUUUU-3’ 9 ssRNA 2voo H. sapiens lupus LA protein 179 5’-UUU-3’ 3 ssRNA 3gib E. coli protein Hfq 191 5’-AAAAAAAAA-3’ 9 ssRNA 2asb M. tuberculosis transcription elongation protein nusA 226 5’-GAACUCAAUAG-3’ 11 ssRNA 1av6 Vaccinia cap-specific mRNA methyltransferase VP39 290 M7G Capped RNA 5’-GAAAAA-3’ 7 ssRNA 1knz S. rotavirus nonstructural RNA-binding protein 34 292 mRNA 3’ consensus 5’-UGACC-3’ 5 ssRNA 2gje T. brucei mRNA-binding protein bBP 292 Guide-RNA fragment 18 ssRNA 3iev A. aeolicus GTP-binding protein ERA 302 16S rRNA 3’ end 11 ssRNA 1m8x H. sapiens pumilio 1 homology domain 341 5’-UUGUAUAU-3’ 8 ssRNA 2wj8 Human respiratory syncytial virus nucleoprotein 374 5’-CCCCCCC-3’ 7 ssRNA 3fht H. sapiens ATP-dependent RNA helicase DDX19B 392 5’-UUUUUU-3’ 6 ssRNA 3k62 C. elegans Fem-3 mRNA-binding factor 2 400 5’-UGUGUUAUC-3’ 9 ssRNA 2gtt Rabies virus nucleoprotein 401 ssRNA 17 ssRNA 2gic Vesicular stomatitis Indiana virus nucleocapsid protein 416 ssRNA fragment 15 ssRNA 2bh2 E. coli 23S ribosomal RNA (uracil-5)-methyltransferase RUMA 419 23S rRNA fragment 29 ssRNA 2jlv Dengue virus serine protease subunit NS3 451 5’-AGACUAA-3’ 7 ssRNA 2bx2 E. coli ribonuclease E 500 5’-UUUACAGUAUUUGU-3’ 14 ssRNA 2po1 P. abyssi probable exosome complex exonuclease 503 5’-AAAAAAA-3’ 7 ssRNA 3i5x S. cerevisiae ATP-dependent RNA helicase MSS116 509 5’-UUUUUUUUUU-3’ 10 ssRNA 1ddl Desmodium yellow mottle tymovirus 551 5’-UUUUUUU-3’ 7 ssRNA 1pgl Bean pod mottle virus 555 5’-AGUCUC-3’ 6 ssRNA 1uvj P. phage P2 protein 664 5’-UUCC-3’ 4 ssRNA 3ex7 H. sapiens CASC3 and mago nashi homolog 687 5’-UUUUUU-3’ 6 ssRNA and RNA-binding protein 8 and eukaryotic initiation factor 4A-III 2vnu S. cerevisiae exosome complex exonuclease RRP44 694 5’-AAAAAAAAA-3’ 9 ssRNA 2z2q Flock house viruse capsid protein 980 Flock house virus genomic RNA 12 ssRNA 2r7r Simian rotavirus RNA-dependent RNA polymerase 1073 5’-UGUGACC-3’ 7 ssRNA 1j1u M. jannaschii tRNA-TYR synthetase 300 tRNA-TYR 74 tRNA 3foz E. coli isopentenyl-tRNA transferase 303 tRNA-PHE 69 tRNA Codes PDB des complexes prot´eine-ARN utilis´es dans la PRIDB non redondante RB199, avec une description de la prot´eine et de l’ARN, ainsi que le nombre d’acides amin´es #aa et d’acides nucl´eiques #an dans la structure 3D. Le type d’ARN est aussi indiqu´e entre simple brin (ssRNA), double brin (dsRNA) et ARN de transfert (tRNA). 164pdb Description prot´eine Nombre d’acides amin´es Description ARN Nombre d’acides nucl´eiques Type 2fk6 B. subtilis ribonuclease Z 307 tRNA-THR 53 tRNA 2fmt E. coli tRNA-FMET formyltransferase 314 Formyl-methionyl-tRNA-FMET2 77 tRNA 2zzm M. jannaschii uncharacterized protein MJ0883 329 tRNA-LEU 84 tRNA 2der E. coli tRNA-specific 2-thiouridylase mnmA 348 tRNA-GLU 74 tRNA 3eph S. cerevisiae tRNA isopentenyltransferase 402 tRNA 69 tRNA 1b23 T. aquaticus elongation factor EF-TU 405 E. coli tRNA-CYS 74 tRNA 1h3e T. thermophilus tRNA-TYR synthetase 427 Wild type tRNA-TYR (GUA) 84 tRNA 1u0b E. coli tRNA-CYS 461 tRNA-CYS 74 tRNA 2ct8 A. aeolicus tRNA-MET synthetase 465 tRNA-MET 74 tRNA 1n78 T. thermophilus tRNA-GLU synthetase 468 tRNA-GLU 75 tRNA 2d6f M. thermautotrophicus tRNA-GLN amidotransferase 485 tRNA-GLN 72 tRNA 1asy Yeast tRNA-ASP synthetase 490 tRNA-ASP 75 tRNA 3hax P. furiosus probable tRNA-PseudoU synthase B 503 H/ACA RNA 74 tRNA and ribosome biogenesis protein Nop10 and 50S ribosomal protein L7Ae 2nqp E. coli tRNA-PseudoU synthase A 528 tRNA-LEU 71 tRNA 1qtq E. coli tRNA-GLN synthetase 529 tRNA-GLN II 74 tRNA 2zni D. hafniense tRNA-PYL synthetase 558 tRNA-PYL 72 tRNA 1c0a E. coli tRNA-ASP synthetase 585 tRNA-ASP 77 tRNA 1f7u S. cerevisiae tRNA-ARG synthetase 607 tRNA-ARG 76 tRNA 2zue P. horikoshii tRNA-ARG synthetase 628 tRNA-ARG 76 tRNA 1qf6 E. coli tRNA-THR synthetase 641 tRNA-THR 76 tRNA 2azx H. sapiens tRNA-TRP synthetase 778 tRNA-TRP 72 tRNA 1ser T. thermophilus tRNA-SER synthetase 793 tRNA-SER 65 tRNA 2bte T. thermophilus aminoacyl-tRNA synthetase 877 tRNA-LEU transcript with anticodon CAG 78 tRNA 3hl2 H. sapiens O-phosphoseryl-tRNA-SEC selenium transferase 886 tRNA-SEC 82 tRNA 1ffy S. aureus tRNA-ILE synthetase 917 tRNA-ILE 75 tRNA 1h4s T. thermophilus tRNA-PRO synthetase 946 tRNA-PRO (CGG) 67 tRNA 1wz2 P. horikoshii tRNA-LEU synthetase 948 tRNA-LEU 88 tRNA 2du3 A. fulgidus O-phosphoseryl-tRNA synthetase 1001 tRNA-CYS 71 tRNA 2iy5 T. thermophilus tRNA-PHE synthetase 1117 tRNA-PHE 76 tRNA 1j2b P. horikoshii archaeosine tRNA-GUA transglycosylase 1152 tRNA-VAL 77 tRNA TABLE S10 – Codes PDB des complexes prot´eine-ARN utilis´es dans la PRIDB non redondante RB199, avec une description de la prot´eine et de l’ARN, ainsi que le nombre d’acides amin´es et d’acides nucl´eiques dans la structure 3D. Le type d’ARN est aussi indiqu´e entre simple brin (ssRNA), double brin (dsRNA) et ARN de transfert (tRNA). 165D pdb pdb aa Description prot´eine Nombre d’acides amin´es pdb na Description ARN Nombre d’acides nucl´eiques Type R 2b6g 2d3d S. cerevisiae VTS1 protein SAM domain 81 2b7g 5’-GGAGGCUCUGGCAGCUUUC-3’ 19 dsRNA R 1ec6 1dtj H. sapiens neuro-oncological ventral antigen 2 (NOVA 2) 87 – dsRNA 20 dsRNA R 1t4l 1t4o S. cerevisiae ribonuclease III 90 – snRNA 47 precursor 5’ terminal hairpin 32 dsRNA R 1m5o 1nu4 H. sapiens U1 small nuclear ribonucleoprotein A 92 – RNA substrate and RNA hairpin ribozyme 113 dsRNA R 3bo2 1nu4 H. sapiens U1 small nuclear ribonucleoprotein A 95 – Group I intron P9 and mRNA 221 dsRNA R 1g1x 1ris T. thermophilus 30S ribosomal protein S6 98 – 16S rRNA fragment 84 dsRNA R 1zbi 1zbf B. halodurans Ribonuclease H-related protein 135 – RNA-DNA hydrid 24 dsRNA R 1jbr 1aqz A. restrictus restrictocin 149 – 31-mer SRD RNA analog 31 dsRNA R 1u63 1l2a M. jannaschii 50S ribosomal protein L1P 214 – mRNA 49 dsRNA R 2ez6 1jfz A. aeolicus ribonuclease III 218 – dsRNA 56 dsRNA R 1kog 1evl E. coli tRNA-THR synthetase 401 – tRNA-THR synthetase mRNA 37 dsRNA operator essential domain R 2dra 1r89 A. fulgidus CCA-adding enzyme 437 1vfg tRNA mini DCC 34 dsRNA R 1wne 1u09 Foot-and-mouth disease virus 476 – dsRNA 5’-CAUGGGCC-3’ 13 dsRNA RNA-dependent RNA polymerase and 5’-GGCCC-3’ dimer R 1c9s 1qaw G. staerothermopilus TRP RNA-binding attenuation protein 67 – 5’-GAUGAGA-3’ 7 ssRNA R 1m8w 1mz8 H. sapiens pumilio 1 homology domain 340 – 5’-UUGUAUAU-3’ 8 ssRNA R 3bsb 1m8z H. sapiens pumilio 1 homology domain 341 – 5’-UUUAAUGUU-3’ 9 ssRNA R 3bsx 1m8z H. sapiens pumilio 1 homology domain 341 – 5’-UUGUAAUAUU-3’ 10 ssRNA R 1kq2 1kq1 S. aureus host factor protein for Q beta 365 – 5’-AUUUUUG-3’ 7 ssRNA R 2i91 1yvr S. laevis 60 kDa SS-A Ro ribonucleoprotein 526 – misfolded RNA fragment 23 ssRNA Codes PDB des 40 complexes prot´eine-ARN utilis´es dans les benchmarks I et II, par difficult´e (D, avec R pour corps rigide, S pour semi-flexible et X pour flexible), avec une description de la prot´eine et de l’ARN, ainsi que le nombre d’acides amin´es #aa et d’acides nucl´eiques #an dans la structure 3D et le code PDB de la structure 3D de la prot´eine (pdb aa) et de l’ARN (pdb na) non li´es si disponibles. Le type d’ARN est aussi indiqu´e entre simple brin (ssRNA), double brin (dsRNA) et ARN de transfert (tRNA). 166D pdb pdb aa Description prot´eine Nombre d’acides amin´es pdb na Description ARN Nombre d’acides nucl´eiques Type R 2ix1 2id0 E. coli exoribonuclease II 643 – 5’-AAAAAAAAAAAAA-3’ 13 ssRNA R 1ttt 1eft T. aquaticus elongation factor EF-TU 405 4tna Yeast tRNA-PHE 76 tRNA R 1efw 1l0w T. thermophilus tRNA-ASP synthetase 580 1c0a tRNA-ASP 73 tRNA S 1hc8 1foy G. staerothermopilus ribosomal protein L11 74 – 23S rRNA fragment 57 dsRNA S 1dk1 2fkx T. thermophilus 30S ribosomal protein S15 86 – 30S rRNA fragment 57 dsRNA S 1mfq 1qb2 H. sapiens signal recognition particle 54 kDa protein 108 1l9a 7S RNA of Human signal recognition particle 128 dsRNA S 1e7k 2jnb H. sapiens 15.5 kDa RNA-binding protein 125 – 5’-GCCAAUGAGGCCGAGGC-3’ 17 dsRNA S 1mms 2k3f T. maritima ribosomal protein L11 133 – 23S rRNA fragment 58 dsRNA S 2err 2cq3 H. sapiens ataxin-2-binding protein 1 (Fox 1) 88 – 5’-UGCAUGU-3’ 7 ssRNA S 2ad9 1sjq H. sapiens polypyrimidine tract-binding protein RBD1 98 – 5’-CUCUCU-3’ 6 ssRNA S 2adb 1sjr H. sapiens polypyrimidine tract-binding protein RBD2 127 – 5’-CUCUCU-3’ 6 ssRNA S 2py9 2jzx H. sapiens poly(rC)-binding protein 2 141 – Human telomeric RNA 12 ssRNA S 2adc 2evz H. sapiens polypyrimidine tract-binding protein RBD3 and 4 208 – 5’-CUCUCU-3’ 6 ssRNA S 3bx2 1m8z H. sapiens pumilio 1 homology domain 328 – 5’-UGUAUAUUA-3’ 9 ssRNA X 1ekz 1stu D. melanogaster maternal effect protein 76 – RNA hairpin 30 dsRNA X 2hgh 2j7j S. laevis transcription factor IIIA 87 – 5S rRNA fragment 55 dsRNA X 1hvu 2vg5 Human immunodeficiency virus HIV1 reverse transcriptase 954 – RNA pseudoknot 30 dsRNA X 1b7f 3sxl D. melanogaster SXL-lethal protein 167 – 5’-GUUGUUUUUUUU-3’ 12 ssRNA X 2c0b 2vmk E. coli ribonuclease E 488 – 5’-UUUACAGUAUU-3’ 11 ssRNA X 1msw 1aro E. phage DNA-directed T7 RNA polymerase 863 – mRNA 47 ssRNA X 1ob2 1efc E. coli elongation factor EF-TU 393 1ehz tRNA-PHE 76 tRNA TABLE S11 – Codes PDB des 40 complexes prot´eine-ARN utilis´es dans les benchmarks I et II, par difficult´e (D, avec R pour corps rigide, S pour semi-flexible et X pour flexible), avec une description de la prot´eine et de l’ARN, ainsi que le nombre d’acides amin´es et d’acides nucl´eiques dans la structure 3D et le code PDB de la structure 3D de la prot´eine (pdb aa) et de l’ARN (pdb na) non li´es si disponibles. Le type d’ARN est aussi indiqu´e entre simple brin (ssRNA), double brin (dsRNA) et ARN de transfert (tRNA). 167ES TOP10 TOP100 ROC-AUC pdb ROS POS ALL NEG ROS POS ALL NEG Attendu ROS POS ALL NEG ROS POS ALL NEG 1asy 0.49 3.69 0.88 0.87 7 8 7 7 7.195 28 95 92 92 0.43 0.74 0.58 0.57 1av6 3.15 1.53 0.00 0.00 5 10 10 10 8.815 77 100 97 97 0.38 0.88 0.62 0.62 1b23 1.47 2.87 0.94 0.94 4 10 9 9 5.037 4 99 88 88 0.39 0.81 0.61 0.61 1c0a 0.46 5.89 2.82 2.76 1 10 9 9 2.568 11 99 75 75 0.30 0.91 0.70 0.70 1ddl 0.52 2.64 1.24 1.24 2 3 1 1 2.789 18 35 28 28 0.48 0.64 0.53 0.52 1dfu 2.11 5.07 0.22 0.22 4 10 10 10 9.24 47 100 99 99 0.28 0.93 0.74 0.73 1di2 0.59 4.05 0.92 0.92 10 10 8 8 7.553 99 98 90 89 0.41 0.91 0.60 0.60 1e8o 1.18 2.08 1.48 1.48 6 2 8 8 3.376 23 37 62 62 0.44 0.63 0.56 0.56 1f7u 0.17 4.46 2.58 2.55 4 10 10 10 4.105 4 94 75 75 0.21 0.89 0.80 0.80 1feu 1.16 1.72 0.11 0.11 4 10 9 9 9.081 65 99 96 96 0.34 0.81 0.67 0.67 1ffy 0.02 7.09 1.11 1.10 0 10 4 4 3.121 0 100 17 17 0.42 0.93 0.58 0.58 1fxl 0.08 6.26 0.26 0.24 0 10 10 10 5.104 0 100 98 98 0.18 0.79 0.83 0.82 1gtf 4.28 1.61 0.00 0.00 10 10 10 10 9.628 97 100 100 100 0.49 0.72 0.51 0.51 1h3e 0.41 5.02 0.96 0.95 0 10 4 4 5.918 11 100 65 65 0.35 0.77 0.65 0.65 1h4s 0.81 1.90 1.72 1.75 1 4 4 4 1.19 2 34 35 35 0.42 0.63 0.58 0.58 1hq1 1.43 2.42 0.68 0.67 6 3 0 0 2.624 31 40 6 6 0.57 0.67 0.43 0.43 1j1u 1.56 1.40 0.15 0.15 10 9 10 10 8.331 96 92 97 97 0.53 0.67 0.47 0.47 1j2b 0.02 6.25 4.17 4.14 0 10 9 9 1.317 0 100 75 75 0.13 0.87 0.87 0.87 1jbs 0.58 0.79 0.59 0.59 0 0 3 3 2.528 1 5 25 26 0.44 0.61 0.56 0.56 1jid 2.52 0.05 0.00 0.00 2 10 10 10 9.357 63 98 95 95 0.37 0.65 0.64 0.63 1k8w 0.59 7.73 2.78 2.70 1 10 10 10 3.916 5 100 86 86 0.35 0.94 0.67 0.65 1knz 0.00 5.68 0.19 0.19 0 10 3 3 3.11 0 100 62 63 0.15 0.93 0.86 0.85 1lng 2.74 3.91 0.77 0.77 6 10 5 5 7.299 70 95 58 58 0.61 0.65 0.39 0.39 1m8v 0.85 1.70 0.51 0.50 10 3 10 10 7.017 90 51 81 81 0.44 0.54 0.56 0.56 1m8x 1.68 4.61 0.26 0.26 7 10 9 9 8.413 86 100 90 90 0.43 0.75 0.58 0.58 1mzp 0.76 3.15 1.96 1.95 0 6 4 4 1.592 11 51 39 38 0.40 0.71 0.60 0.60 1n35 0.10 7.27 2.62 2.62 0 8 0 0 0.732 0 85 13 13 0.34 0.99 0.67 0.67 1n78 0.33 3.67 0.53 0.53 0 10 4 4 4.39 0 98 62 62 0.30 0.92 0.71 0.71 1ooa 3.45 2.56 0.00 0.00 6 10 10 10 8.662 75 100 95 95 0.44 0.91 0.57 0.57 1pgl 3.13 0.00 0.00 0.00 10 9 9 9 9.344 80 98 99 99 0.24 0.85 0.76 0.76 1q2r 0.00 6.33 1.13 1.11 0 10 9 9 4.585 0 100 93 93 0.24 0.82 0.77 0.77 1qf6 0.09 7.30 2.92 2.92 0 10 7 7 1.154 0 99 52 52 0.23 0.90 0.77 0.77 R´esultats des fonctions de score atomiqes de la fonction par d´efaut de RosettaDock (ROS), positive (POS), n´egative (NEG) et sans contrainte (ALL) pour les complexes de la PRIDB : score d’enrichissement, nombre de presque-natifs dans le top10, nombre de presque-natifs attendus en moyenne par un tri al´eatoire, nombre de presque-natifs dans le top100 et aire sous la courbe ROC (ROC-AUC) sur 10 000 candidats par pdb ´evalu´e. 168ES TOP10 TOP100 ROC-AUC pdb ROS POS ALL NEG ROS POS ALL NEG Attendu ROS POS ALL NEG ROS POS ALL NEG 1qtq 0.05 6.36 2.57 2.54 0 10 9 9 2.971 4 100 80 80 0.30 0.89 0.70 0.70 1r3e 0.66 6.89 2.65 2.65 0 10 6 6 3.356 10 100 75 75 0.41 0.90 0.60 0.60 1r9f 1.55 3.19 0.28 0.28 10 10 10 10 9.359 99 100 98 98 0.38 0.87 0.63 0.62 1sds 0.80 1.51 0.47 0.47 5 6 2 2 4.183 41 37 32 32 0.55 0.59 0.45 0.45 1ser 0.10 4.35 0.51 0.51 0 9 7 7 2.999 0 95 41 39 0.29 0.96 0.72 0.71 1si3 0.27 4.66 0.11 0.09 0 10 10 10 7.681 0 100 100 100 0.08 0.75 0.92 0.92 1t0k 1.53 1.34 0.73 0.73 8 0 4 4 3.725 59 14 27 27 0.55 0.51 0.45 0.45 1tfw 0.02 4.38 3.33 3.31 0 10 1 1 0.225 0 97 14 14 0.22 1.00 0.79 0.78 1u0b 0.02 6.33 3.44 3.41 0 10 7 7 2.616 0 97 69 69 0.21 0.87 0.79 0.79 1un6 0.66 2.93 1.29 1.30 0 9 7 7 3.952 1 93 87 86 0.30 0.83 0.71 0.71 1uvj 0.51 3.20 0.66 0.66 0 6 2 2 2.066 0 73 47 46 0.31 0.80 0.69 0.69 1vfg 2.96 0.32 0.11 0.11 9 10 10 10 9.313 87 99 98 98 0.42 0.74 0.59 0.59 1wpu 2.16 3.48 0.14 0.13 10 10 9 9 8.746 78 100 95 95 0.51 0.62 0.49 0.49 1wsu 0.50 1.72 1.50 1.48 0 2 6 6 4.816 14 32 72 72 0.36 0.52 0.64 0.64 1wz2 0.25 5.18 1.81 1.72 0 10 5 4 2.451 0 98 55 53 0.31 0.79 0.70 0.69 1yvp 2.26 2.69 0.00 0.00 8 10 10 10 9.384 84 100 99 99 0.37 0.84 0.63 0.63 1zbh 0.15 1.74 1.33 1.33 2 8 7 7 3.809 4 69 62 62 0.34 0.68 0.66 0.66 2a8v 0.14 2.20 1.81 1.83 2 8 6 6 4.775 14 84 64 65 0.34 0.53 0.66 0.66 2anr 0.55 2.06 2.14 2.15 7 0 3 3 2.927 23 18 48 48 0.38 0.57 0.62 0.62 2asb 1.18 5.26 0.13 0.13 2 10 6 6 5.475 3 100 60 60 0.46 0.92 0.55 0.55 2az0 0.22 4.33 1.36 1.34 0 10 1 1 1.351 1 77 12 12 0.40 0.84 0.61 0.61 2azx 0.13 2.29 1.85 1.81 0 9 9 9 7.22 10 90 90 89 0.29 0.63 0.72 0.71 2b3j 1.56 3.18 0.11 0.11 0 10 10 10 7.172 7 100 100 100 0.24 0.93 0.76 0.76 2bgg 0.30 4.89 2.25 2.21 0 10 10 10 5.42 4 100 98 97 0.28 0.88 0.73 0.73 2bh2 0.29 7.08 1.75 1.74 0 10 8 8 2.34 0 100 82 82 0.32 0.89 0.68 0.68 2bte 0.98 2.15 0.23 0.23 7 10 6 6 7.251 76 98 83 82 0.42 0.82 0.59 0.58 2bu1 0.18 2.41 1.75 1.73 5 3 2 2 3.909 17 54 43 43 0.38 0.60 0.62 0.62 2bx2 0.07 2.08 0.98 0.96 0 5 3 2 3.441 0 42 21 20 0.36 0.81 0.64 0.64 2ct8 0.68 3.09 0.87 0.87 3 10 4 4 5.817 37 87 69 69 0.35 0.79 0.65 0.65 2czj 3.12 3.51 0.06 0.05 10 10 10 10 9.135 94 100 97 97 0.51 0.78 0.49 0.49 2d6f 2.30 2.75 0.00 0.00 10 10 1 1 8.458 81 96 64 64 0.63 0.67 0.37 0.37 2der 0.88 4.52 0.88 0.87 0 10 5 5 3.535 0 100 84 84 0.26 0.96 0.75 0.74 R´esultats des fonctions de score atomiqes de la fonction par d´efaut de RosettaDock (ROS), positive (POS), n´egative (NEG) et sans contrainte (ALL) pour les complexes de la PRIDB : score d’enrichissement, nombre de presque-natifs dans le top10, nombre de presque-natifs attendus en moyenne par un tri al´eatoire, nombre de presque-natifs dans le top100 et aire sous la courbe ROC (ROC-AUC) sur 10 000 candidats par pdb ´evalu´e. 169ES TOP10 TOP100 ROC-AUC pdb ROS POS ALL NEG ROS POS ALL NEG Attendu ROS POS ALL NEG ROS POS ALL NEG 2du3 2.14 2.11 0.05 0.05 9 6 10 10 9.16 65 84 95 95 0.48 0.52 0.52 0.52 2e9t 0.00 7.70 1.83 1.80 0 10 4 4 1.688 0 100 75 73 0.19 1.00 0.83 0.82 2f8k 1.37 1.47 0.92 0.92 9 1 4 4 4.993 78 32 63 62 0.51 0.57 0.49 0.49 2f8s 1.27 2.19 0.62 0.62 6 10 10 10 6.802 53 100 93 93 0.40 0.67 0.60 0.60 2fk6 0.84 2.93 0.61 0.61 10 10 9 9 8.17 78 98 94 94 0.46 0.86 0.54 0.54 2fmt 0.59 5.99 1.07 1.06 0 10 7 7 2.675 10 100 44 43 0.40 0.90 0.61 0.61 2gic 1.11 3.06 0.13 0.13 0 8 3 3 3.956 0 87 36 35 0.38 0.92 0.63 0.63 2gje 1.11 2.60 0.27 0.26 6 9 10 10 7.233 74 95 93 93 0.30 0.83 0.70 0.70 2gjw 0.11 4.25 0.18 0.18 8 10 10 10 7.806 28 100 100 100 0.22 0.89 0.79 0.79 2gtt 1.03 3.38 0.41 0.38 0 9 0 0 2.419 0 88 12 12 0.43 0.88 0.57 0.57 2gxb 0.54 1.87 0.98 0.95 0 3 3 3 4.715 16 45 37 37 0.49 0.59 0.51 0.51 2hw8 1.89 3.72 0.14 0.14 9 10 9 9 7.302 23 99 91 90 0.52 0.93 0.49 0.48 2i82 3.45 7.14 0.05 0.05 6 10 10 10 6.908 60 100 96 96 0.41 0.84 0.60 0.60 2iy5 0.07 6.69 2.12 2.10 0 4 0 0 0.92 0 79 3 3 0.31 0.96 0.70 0.70 2jlv 0.53 0.74 0.00 0.00 0 1 0 0 4.519 0 13 7 7 0.33 0.81 0.67 0.67 2nqp 0.74 3.02 0.77 0.77 0 5 1 1 2.642 5 58 25 25 0.43 0.74 0.57 0.57 2nug 0.29 6.56 5.83 5.82 0 10 0 0 0.365 0 100 1 1 0.66 1.00 0.40 0.37 2ozb 1.10 6.82 2.24 2.23 1 10 10 10 3.716 3 100 95 95 0.37 0.84 0.63 0.63 2pjp 0.01 1.75 2.16 2.17 1 1 6 6 2.983 1 33 53 53 0.31 0.60 0.69 0.69 2po1 1.98 1.35 0.00 0.00 10 10 1 1 9.139 97 100 55 55 0.45 0.75 0.56 0.56 2qux 0.16 3.18 1.63 1.61 1 4 0 0 1.94 1 56 16 17 0.40 0.70 0.60 0.60 2r7r 0.03 4.54 0.16 0.16 0 10 6 6 4.231 0 98 74 73 0.18 0.91 0.83 0.83 2r8s 1.35 1.96 0.28 0.28 8 10 9 9 7.263 42 90 83 82 0.46 0.59 0.54 0.54 2vnu 0.09 2.20 1.13 1.13 0 2 0 0 2.481 0 58 30 30 0.24 0.93 0.76 0.76 2voo 0.08 1.69 0.13 0.13 10 10 10 10 7.556 96 100 97 97 0.43 0.85 0.58 0.57 2w2h 0.50 3.96 2.71 2.70 2 10 10 10 5.472 20 99 97 97 0.36 0.81 0.64 0.64 2wj8 0.06 6.11 0.66 0.65 0 10 5 5 2.429 0 99 52 52 0.22 0.91 0.79 0.79 2z2q 0.49 2.64 1.36 1.36 3 9 5 5 5.908 26 89 76 76 0.41 0.60 0.59 0.59 2zi0 3.01 0.48 0.01 0.01 0 9 4 4 7.917 10 88 58 58 0.27 0.80 0.74 0.74 2zko 1.15 4.04 0.99 1.00 0 7 0 0 1.338 9 83 9 9 0.57 0.83 0.44 0.43 2zni 0.30 6.44 1.70 1.64 0 10 9 9 2.671 0 100 48 46 0.40 0.76 0.61 0.61 2zue 0.30 4.53 1.50 1.49 0 10 9 9 4.929 0 99 82 82 0.22 0.89 0.79 0.78 R´esultats des fonctions de score atomiqes de la fonction par d´efaut de RosettaDock (ROS), positive (POS), n´egative (NEG) et sans contrainte (ALL) pour les complexes de la PRIDB : score d’enrichissement, nombre de presque-natifs dans le top10, nombre de presque-natifs attendus en moyenne par un tri al´eatoire, nombre de presque-natifs dans le top100 et aire sous la courbe ROC (ROC-AUC) sur 10 000 candidats par pdb ´evalu´e. 170ES TOP10 TOP100 ROC-AUC pdb ROS POS ALL NEG ROS POS ALL NEG Attendu ROS POS ALL NEG ROS POS ALL NEG 2zzm 0.11 8.06 3.62 3.57 0 10 6 6 1.256 0 100 67 67 0.18 0.93 0.83 0.83 3a6p 6.30 7.17 0.00 0.00 0 7 0 0 1.972 54 96 0 0 0.80 0.99 0.21 0.20 3bso 0.94 5.84 0.08 0.08 0 10 0 0 2.472 1 100 0 0 0.43 0.99 0.58 0.58 3bt7 0.57 4.98 0.75 0.72 1 10 10 10 5.376 20 100 90 90 0.33 0.79 0.68 0.68 3ciy 1.71 2.79 0.19 0.18 4 10 2 2 5.629 44 82 54 53 0.59 0.69 0.41 0.41 3d2s 0.04 0.79 0.56 0.56 6 10 9 9 8.929 62 97 97 97 0.32 0.71 0.69 0.69 3dd2 0.74 2.00 1.21 1.21 0 3 2 2 2.468 4 43 34 35 0.44 0.66 0.56 0.56 3egz 1.05 3.05 0.41 0.39 6 10 7 7 5.223 6 97 91 90 0.16 0.79 0.84 0.84 3eph 0.19 8.81 5.65 5.61 0 10 10 10 1.002 0 100 90 90 0.13 0.99 0.88 0.87 3eqt 0.40 7.19 0.50 0.48 2 10 8 8 5.188 54 100 85 85 0.38 0.94 0.62 0.62 3ex7 0.05 4.06 0.55 0.53 0 10 10 10 7.516 0 96 99 99 0.18 0.75 0.83 0.82 3fht 2.19 3.66 0.01 0.01 0 10 10 10 8.25 0 100 100 100 0.18 0.84 0.83 0.83 3foz 0.48 8.00 2.67 2.66 0 10 8 8 1.341 0 100 48 48 0.21 0.98 0.80 0.79 3gib 0.37 1.80 1.78 1.78 0 6 6 6 2.324 0 48 56 57 0.31 0.49 0.69 0.69 3hax 0.04 6.51 4.73 4.71 1 10 9 9 1.027 1 100 81 80 0.19 0.88 0.81 0.81 3hl2 2.67 3.66 0.00 0.00 0 10 10 10 9.062 56 100 100 100 0.48 0.99 0.54 0.53 3htx 0.02 8.04 3.70 3.69 0 10 6 6 1.045 0 100 52 51 0.22 0.96 0.79 0.78 3i5x 0.31 3.55 1.20 1.19 0 10 8 8 6.791 4 100 80 79 0.35 0.80 0.65 0.65 3iab 0.59 5.28 1.17 1.13 0 10 10 10 4.77 7 92 100 100 0.24 0.73 0.77 0.77 3icq 0.14 2.83 1.12 1.12 0 10 7 8 5.14 10 88 80 80 0.35 0.81 0.65 0.65 3iev 1.30 5.64 0.94 0.92 8 10 10 10 7.914 67 100 99 99 0.61 0.65 0.40 0.40 3k62 2.51 3.40 0.15 0.15 9 10 9 9 8.482 86 100 96 96 0.35 0.78 0.65 0.65 3l25 0.35 7.02 1.09 1.07 0 7 2 2 1.205 0 79 35 33 0.38 0.99 0.64 0.62 3snp 0.02 6.63 2.80 2.77 1 10 10 10 3.201 1 100 86 86 0.25 0.84 0.75 0.75 TABLE S12 – R´esultats des fonctions de score atomiqes de la fonction par d´efaut de RosettaDock (ROS), positive (POS), n ´egative (NEG) et sans contrainte (ALL) pour les complexes de la PRIDB : score d’enrichissement, nombre de presquenatifs dans le top10, nombre de presque-natifs attendus en moyenne par un tri al´eatoire, nombre de presque-natifs dans le top100 et aire sous la courbe ROC (ROC-AUC) sur 10 000 candidats par pdb ´evalu´e. 171 https://hal.archives-ouvertes.fr/tel-01081605/document Une approche agile, fiable et minimale pour le maintien de la qualit´e de service lors de l’´evolution d’applications `a base de processus m´etiers Alexandre Feugas To cite this version: Alexandre Feugas. Une approche agile, fiable et minimale pour le maintien de la qualit´e de service lors de l’´evolution d’applications `a base de processus m´etiers. Software Engineering. Universit´e des Sciences et Technologie de Lille - Lille I, 2014. French. HAL Id: tel-01073193 https://tel.archives-ouvertes.fr/tel-01073193 Submitted on 9 Oct 2014 HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers. L’archive ouverte pluridisciplinaire HAL, est destin´ee au d´epˆot et `a la diffusion de documents scientifiques de niveau recherche, publi´es ou non, ´emanant des ´etablissements d’enseignement et de recherche fran¸cais ou ´etrangers, des laboratoires publics ou priv´es.Universit´e Lille 1 Sciences et Technologies D´epartement de formation doctorale en informatique Ecole doctorale SPI Lille ´ UFR IEEA Une Approche Agile, Fiable et Minimale pour le Maintien de la Qualit´e de Service lors de l’Evolution ´ d’Applications `a Base de Processus M´etiers THESE ` pr´esent´ee et soutenue publiquement le 8 octobre 2014 pour l’obtention du Doctorat de l’Universit´e Lille 1 Sciences et Technologies Sp´ecialit´e Informatique par Alexandre Feugas Composition du jury Rapporteurs : Marie-Pierre Gervais, Universit´e Paris Ouest Nanterre La D´efense Jean-Michel Bruel, Universit´e de Toulouse Directeur de th`ese : Laurence Duchien, Universit´e Lille 1 Examinateurs : Jean-Luc Dekeyser, Universit´e Lille 1 S´ebastien Mosser, Universit´e Nice - Sophia Antipolis Laboratoire d’Informatique Fondamentale de Lille — UMR CNRS 8022 INRIA Lille - Nord EuropeUne Approche Agile, Fiable et Minimale pour le Maintien de la Qualité de Service lors de l’Évolution d’Applications à Base de Processus Métiers Les logiciels actuels adoptent une méthodologie de développement dite "agile" pour mieux prendre en compte la nécessité de s’adapter constamment aux nouveaux besoins des utilisateurs. Les concepteurs et développeurs se rapprochent alors des futurs utilisateurs du logiciel en proposant des cycles courts d’itération, où le futur utilisateur fait un retour rapide sur l’incrément apporté au logiciel, et fait part de nouveaux besoins à prendre en compte dans les incréments à venir. Ces itérations peuvent être vues comme des évolutions, faisant suite à la définition d’un nouveau besoin de l’utilisateur, à un changement de l’environnement d’exécution, ou encore à une remise en question de l’architecture du logiciel. Dans l’écosystème des architectures orientées services, la conception d’applications passe par la chorégraphie ou l’orchestration de services par des processus métiers. Concevoir ces applications consiste alors à mettre en relation les flots de contrôle et de données de ces services. La phase d’évolution devient une phase complexe, où une simple modification localisée à une sous-partie d’un processus métier peut avoir des conséquences sur l’ensemble du système logiciel, causant par exemple son ralentissement lors de l’exécution. Du point de vue de la qualité de service (QoS), la maîtrise de la fiabilité du processus d’évolution pour maintenir la qualité de service d’un logiciel est alors critique. Il est donc nécessaire de pouvoir proposer des mécanismes d’évolution agiles et fiables permettant le maintien de la QoS lors de l’évolution d’applications à base de processus métiers. En d’autres termes, il s’agit de s’assurer qu’une évolution ne viole pas les contrats de QoS définis initialement. Cette garantie doit être établie en fonction du contrat soit lors de la conception soit lors de l’exécution. Dans ce dernier cas, le processus de vérification doit être minimal et localisé, afin de ne pas dégrader les performances du système logiciel. Pour cela, nous proposons de mettre en œuvre un cycle de développement agile, centré sur le maintien de la QoS lors de l’évolution. Il s’agit de prendre l’aspect évolutif du système, ceci dès l’étape de conception initiale, en identifiant les informations requises pour déterminer si la QoS est correcte et si elle est non violée par une évolution. Ces informations étant détenues par plusieurs intervenants, il est également nécessaire d’établir les points d’interaction au cours du cycle de développement, au cours desquels les informations seront partagées de façon à ce que le logiciel qui en est issu reste syntaxiquement et sémantiquement cohérent et que les contrats de QoS soient (re)vérifiés a minima. Les contributions de cette thèse sont donc mises en œuvre dans Blink, un cycle de développement pour l’évolution, et Smile, un canevas de développement pour le maintien de la qualité de service lors de l’évolution d’applications orientées service définies à base de processus métiers. Tandis que le cycle de développement Blink vise à identifier les différents rôles présents dans l’équipe de développement et à expliciter leurs interactions, le canevas Smile propose la réalisation d’une boucle d’évolution. Cette boucle permet de concevoir, d’analyser et d’appliquer une évolution, en détectant les potentielles violations de contrat de QoS. Pour cela, l’analyse de l’évolution détermine son effet sur la QoS du logiciel, en établissant des relations de causalité entre les différentes variables, opérations, services et autres parties du système. Ainsi, en identifiant les éléments causalement affectés par l’évolution et en écartant ceux qui ne le sont pas, notre approche permet de limiter le nombre d’éléments à (re)vérifier, garantissant ainsi une étape d’évolution fiable, avec une étape de (re)vérification minimale. Nous montrons sur un cas concret de système de gestion de crises, constitué de onze processus métiers et de dix scénarios, que l’utilisation conjointe de Blink et de Smile permet d’identifier, pour chaque évolution, quel sera son effet sur le reste du système, et si la qualité de service sera maintenue ou non.An Agile, Reliable and Minimalist Approach to Preserve the QoS of Business-Processes Based Applications during their Evolutions Current softwares are built using "agile" development methods, to better consider the need to adapt to new user requirements. Developers and designers are getting closer to future software users by making short iterative cycles, where the future user gives a fast feedback on the increment made to the software and emits new user requirement to be fulfilled in future increments. These iterations can be seen as evolutions, as an answer to the definition of a new user requirement, or due to a change in the execution environment or in the architecture of the software. In the Service-Oriented Architecture (SOA) world, the design of software is composed of service choreography, or service orchestration using business processes. The design of these applications is equivalent to connecting the services control flow and data flow. As a result, the evolution step becomes a complex step, where a simple modification on a sub-part of a business process can have consequences on the entire system, causing for example its slowing down at runtime. From the Quality of Service (QoS) point of view, ensuring the fiability of the evolution process to maintain software QoS is critical. As a result, it is necessary to propose agile, reliable evolution mecanisms ensuring QoS preservation during the evolution of software made of business processes. In other words, we need to control that an evolution does not violate any QoS contract initially set up. Depending of the contract, this garanty must be established either at design time or at runtime. In the latter case, the verification process must be minimal and local, in order to not degrade the software performance. To achieve this goal, we propose to realise an agile development cycle, centered on the QoS preservation during the evolution. It is necessary to care about the evolutive concern of a system from the initial design step, by identifying required information to determine if the QoS continues to be correct and not violated by an evolution. Considering that this information is known by many stakeholders, it is also necessary to set up interaction points during the development cycle, during which information is shared in order to keep building a syntactically and semantically coherent software and to minimally (re)check QoS contracts. The contributions of this thesis are applied in Blink, a development cycle for evolution, and Smile, a framework to maintain QoS during the evolution of a service-oriented software made of business processes. While Blink is intended to identify the different actors and to make their interactions explicit, Smile proposes the realisation of an evolution loop. This loop enables the design, analysis and application of an evolution, by detecting the potential QoS contract violation. The evolution analysis determines its effect on the software QoS, by defining causal relations among variables, operations, services and other parts of the system. In this way, by identifying elements that are causally affected by the evolution, and by avoiding the elements that are not, our approach enables the limitation of the number of elements to (re)check in order to assure a reliable evolution step, with a minimal (re)check step. We show on the concrete case of a crisis management system, composed of eleven business processes and ten scenarios, that the combined use of Blink and Smile enables for each evolution the identification of its effect on the system, and the QoS preservation of the system.Remerciements La thèse est une aventure, une expérience humaine qui vous marque profondément tant elle change vos habitudes,votre façon de penser. J’ai vécu au cours de ces quatre dernières années quelque chose de beau, d’intense, de douloureux et de décourageant aussi. Mais c’est avant tout l’ensemble des rencontres faites durant ce laps de temps qui ont fait de cette thèse un moment fort à mes yeux. Dans cette page, je n’aurai pas la prétention d’être exhaustif, j’oublierai sûrement quelques personnes qui, je l’espère, ne m’en voudront pas. Mais sachez juste que, qui que vous soyez, que je vous ai croisé de près ou de loin, merci à vous d’avoir joué un rôle dans mon aventure doctorante. Je voudrais remercier en premier lieu mes encadrants, Laurence et Seb, qui ont dû avoir quelques cheveux blancs à cause de moi. Merci de vous être impliqué dans ces travaux, d’avoir su garder patience avec moi. J’espère que vous ne m’en voulez pas trop de vous avoir mené la vie dure. A titre postume, j’ai également une pensée profonde pour AnneFrançoise, qui a su croire en moi ; qui m’a encouragé et qui a été derrière moi à mes débuts. Merci à toi. J’aurais aimé que tu sois présente, auprès de nous. Plus généralement, je voudrais remercier l’équipe Adam/Spirals, qui a été ma deuxième famille. Merci aux permanents, avec leurs remarques, leurs discussions passionnantes, ou leurs reculs. Merci enfin aux doctorants et ingénieurs de l’équipe, qui ont partagé avec moi le stress des différentes présentations et autres deadlines d’articles. On ne le dit jamais assez, une thèse, c’est pas une sinécure... Et puis merci à tous les collègues embarqués dans la même galère : bravo, merci et courage au 4 autres compagnons ayant démarré cette folle aventure avec moi : Adel, Nico, Rémi et Rémi. Bonne continuation à vous, en espérant que vous garderez le même souvenir d’Inria que moi. Un clin d’œil pour Clément, frère de thèse, qui a su m’accueillir à Lille malgré son accent sudiste, qui m’a fait découvrir de nombreux endroits sympathiques. J’ai beaucoup apprécié nos longues conversations, autant scientifiques que footballistiques. J’espère que tu mèneras une longue et brillante carrière académique, en démarrant par Milan. Obrigado également à Antonio, mon frère de bière, compagnon de nuit et de braderie, qui m’a fait découvrir sa culture, son pays, et bien plus encore. J’ai été heureux de faire ta connaissance, en espérant te re-croiser un jour, ou dans une vie future. Je ne pourrai pas écrire ces remerciements sans penser à mes camarades de l’association des doctorants, Tilda. Tout particulièrement, je voudrais saluer Fabien et sa bonne humeur, avec qui j’ai eu le plaisir de travailler. Enfin, un immense merci à Julie, voisine de thèse, compagnon de pause café et motivatrice intarissable. Merci de m’avoir épaulé autant dans ma thèse que dans ma vie perso. Enfin, merci à ma famille, qui m’a soutenu tout au long de ces quatre dernières années, dans les bons et les mauvais moments. Merci d’avoir été auprès de moi, d’avoir cru en moi, lorsque moi-même je n’y croyais plus. Encore une fois, merci à vous. Merci également à tous mes amis sudistes, qui ont sû rester en contact avec moi, malgré la grande distance séparant mon sud natal de cette terre d’accueil qu’a été le Nord. Je ne citerai personne de peur d’oublier quelqu’un, exception faite bien sûr de Laetitia, qui a été mon accroche immuable tout au long du doctorat. Tu as su rester auprès de moi malgré la distance, l’eau qui coulait sur les ponts, et nos chemins qui tendaient à bifurquer. Tu as été présente au bout du téléphone lorsque j’allais bien, lorsque j’allais mal, quand j’avais envie de parler politique, ou simplement de la pluie et du beau temps pour oublier les difficultés de la journée passée. Plus encore, c’est sans nul doute grâce à toi si aujourd’hui, je suis docteur... (le 13ème ?) C’est toi qui, au moment où j’avais envie de baisser les bras, là où je ne voyais plus aucun espoir ni réconfort, a réussi non seulement à me donner la force de terminer ma thèse, mais qui m’a en plus redonné l’envie de sourire, et qui m’a donné un but en m’attendant patiemment dans notre nouvelle contrée toulousaine. Merci, merci infiniment. iiiTable des matières Table des matières 1 Introduction 1 1.1 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.2 Défis pour maintenir la qualité de service lors de l’évolution . . . . . . . . . 2 1.3 Proposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.4 Organisation du document . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.5 Liste des publications liées à cette thèse . . . . . . . . . . . . . . . . . . . . 5 I Contexte et Motivations 7 2 Contexte 9 2.1 Les architectures orientées services . . . . . . . . . . . . . . . . . . . . . . . 9 2.1.1 Définitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.1.2 Organisation des architectures orientées services . . . . . . . . . . . 10 2.2 La Qualité de Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.2.1 Qualité du logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.2.2 Méthodes de détermination de la qualité de service . . . . . . . . . . 14 2.2.3 Contrats de Qualité de Service . . . . . . . . . . . . . . . . . . . . . 17 2.3 Évolution des systèmes logiciels . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.3.1 Définition de l’évolution . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.3.2 Caractéristiques d’une évolution . . . . . . . . . . . . . . . . . . . . 18 2.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 3 État de l’art 25 3.1 Processus de développement . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.1.1 Les processus de développement généralistes . . . . . . . . . . . . . . 26 3.1.2 Les processus de développement spécialisés SOA . . . . . . . . . . . 27 3.1.3 Prise en compte de la Qualité de Service . . . . . . . . . . . . . . . . 28 3.1.4 Prise en compte de l’évolution . . . . . . . . . . . . . . . . . . . . . 28 3.1.5 Comparatif et limitations . . . . . . . . . . . . . . . . . . . . . . . . 29 3.2 Analyse d’impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.2.1 Fondements de la causalité . . . . . . . . . . . . . . . . . . . . . . . 29 3.2.2 Application de la causalité : les analyses d’impact . . . . . . . . . . 30 3.2.3 Analyse d’impact pour la qualité de service . . . . . . . . . . . . . . 32 3.2.4 Comparatif et limitations . . . . . . . . . . . . . . . . . . . . . . . . 32 3.3 Conclusion de l’état de l’art . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 4 Présentation du cas d’étude 37 4.1 Séduite, un système de diffusion d’informations à base de processus métiers 37 4.2 PicWeb, un processus métier de recherche d’images . . . . . . . . . . . . . 39 4.2.1 Description de PicWeb . . . . . . . . . . . . . . . . . . . . . . . . . 39 4.2.2 Évolution de PicWeb . . . . . . . . . . . . . . . . . . . . . . . . . . 40Table des matières II Contributions 41 5 Un processus de développement pour le maintien de la qualité de service 43 5.1 Motivations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 5.2 Définition des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 5.3 Description du processus de développement . . . . . . . . . . . . . . . . . . 44 5.4 Coopération entre acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 5.5 Conclusion du chapitre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 6 Modélisation d’un système à base de processus métiers 51 6.1 Défis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 6.2 Modélisation du système . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 6.2.1 Univers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 6.2.2 Variables et types . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 6.2.3 Messages et Opérations . . . . . . . . . . . . . . . . . . . . . . . . . 53 6.2.4 Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 6.2.5 Activités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 6.2.6 Relations d’ordre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 6.2.7 Processus métier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 6.2.8 Système . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 6.3 Causalité de l’exécution d’un système . . . . . . . . . . . . . . . . . . . . . 58 6.3.1 Mise en œuvre de la causalité . . . . . . . . . . . . . . . . . . . . . . 59 6.3.2 Relations causales fonctionnelles . . . . . . . . . . . . . . . . . . . . 59 6.3.3 Exemple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 6.4 Déduction des relations causales d’un système . . . . . . . . . . . . . . . . . 61 6.4.1 Méthodologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 6.4.2 Expression des règles causales . . . . . . . . . . . . . . . . . . . . . . 62 6.5 Conclusion du chapitre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 7 Modélisation de la qualité de service pour l’évolution 65 7.1 Motivations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 7.2 Modélisation de la qualité de service d’un système . . . . . . . . . . . . . . 66 7.2.1 Propriété, unité et critère de comparaison . . . . . . . . . . . . . . . 67 7.2.2 Domaine d’application . . . . . . . . . . . . . . . . . . . . . . . . . . 67 7.2.3 Valeur de propriété . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 7.2.4 Influence et ressource . . . . . . . . . . . . . . . . . . . . . . . . . . 68 7.2.5 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 7.3 Définition des relations causales de propriété . . . . . . . . . . . . . . . . . 69 7.3.1 Relations d’environnement . . . . . . . . . . . . . . . . . . . . . . . . 71 7.3.2 Relations de dérivation de propriétés . . . . . . . . . . . . . . . . . . 71 7.3.3 Relations d’agrégation de valeurs . . . . . . . . . . . . . . . . . . . . 73 7.3.4 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 7.4 QoS4Evol, un langage de description de la qualité de service . . . . . . . . . 74 7.4.1 Présentation de QoS4Evol . . . . . . . . . . . . . . . . . . . . . . . . 75 7.4.2 Définition du langage . . . . . . . . . . . . . . . . . . . . . . . . . . 75 7.4.3 Caractéristiques du langage . . . . . . . . . . . . . . . . . . . . . . . 76 7.5 Déduction des règles causales d’une propriété . . . . . . . . . . . . . . . . . 77 7.5.1 Principe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 7.5.2 Obtention des relations causales d’environnement . . . . . . . . . . . 78 7.5.3 Obtention des relations causales de dérivation . . . . . . . . . . . . . 79 viTable des matières 7.5.4 Obtention des relations causales d’agrégation . . . . . . . . . . . . . 79 7.5.5 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 7.6 Conclusion du chapitre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 8 Analyse de l’évolution du logiciel orientée QoS 83 8.1 Présentation générale du processus d’évolution . . . . . . . . . . . . . . . . 84 8.1.1 Enjeux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 8.1.2 Spécification du processus d’évolution . . . . . . . . . . . . . . . . . 84 8.1.3 Hypothèses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 8.2 Un langage pour l’évolution des processus métier . . . . . . . . . . . . . . . 86 8.3 Spécification de l’analyse de l’évolution . . . . . . . . . . . . . . . . . . . . . 87 8.3.1 Aperçu des différentes étapes . . . . . . . . . . . . . . . . . . . . . . 88 8.3.2 Étape 1 : mise à jour du modèle causal . . . . . . . . . . . . . . . . . 89 8.3.3 Étape 2 : analyse causale . . . . . . . . . . . . . . . . . . . . . . . . 92 8.3.4 Étape 3 : re-vérification . . . . . . . . . . . . . . . . . . . . . . . . . 93 8.3.5 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 8.4 Résultat de l’analyse et prise de décision . . . . . . . . . . . . . . . . . . . . 96 8.4.1 Enjeux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 8.4.2 Vérification des contrats . . . . . . . . . . . . . . . . . . . . . . . . . 97 8.4.3 Détermination des causes racines . . . . . . . . . . . . . . . . . . . . 98 8.4.4 Déploiement et retour en arrière (roll-back) . . . . . . . . . . . . . . 99 8.4.5 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 8.5 Conclusion du chapitre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 III Validation 103 9 Mise en œuvre et utilisation de Smile 105 9.1 Réalisation de Smile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 9.1.1 Présentation du canevas . . . . . . . . . . . . . . . . . . . . . . . . . 106 9.1.2 Besoins des utilisateurs de Smile . . . . . . . . . . . . . . . . . . . . 106 9.1.3 Architecture de Smile . . . . . . . . . . . . . . . . . . . . . . . . . . 106 9.2 Smile pour la description du système . . . . . . . . . . . . . . . . . . . . . 109 9.2.1 Import de système . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 9.2.2 Description des règles causales . . . . . . . . . . . . . . . . . . . . . 111 9.3 Smile pour la qualité de service . . . . . . . . . . . . . . . . . . . . . . . . 113 9.3.1 Principe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 9.3.2 Description d’une propriété . . . . . . . . . . . . . . . . . . . . . . . 113 9.3.3 Gestion des règles causales de propriété . . . . . . . . . . . . . . . . 114 9.3.4 Collecte des données . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 9.3.5 Description d’un contrat . . . . . . . . . . . . . . . . . . . . . . . . . 116 9.4 Smile pour l’évolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 9.4.1 Description d’une évolution . . . . . . . . . . . . . . . . . . . . . . . 117 9.4.2 Analyse causale de l’évolution . . . . . . . . . . . . . . . . . . . . . . 118 9.4.3 Contrôle à l’exécution . . . . . . . . . . . . . . . . . . . . . . . . . . 119 9.5 Limites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 9.6 Conclusion du chapitre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 viiTable des matières 10 Evaluation 121 10.1 Défis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 10.2 Cas d’étude : le Système de gestion de crises . . . . . . . . . . . . . . . . . . 122 10.2.1 Contexte du cas d’étude . . . . . . . . . . . . . . . . . . . . . . . . . 122 10.2.2 Description du scénario . . . . . . . . . . . . . . . . . . . . . . . . . 123 10.2.3 Cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 10.3 Implémentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 10.4 Évolutions du scénario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 10.4.1 Évolutions pour la construction du système . . . . . . . . . . . . . . 128 10.4.2 Évolutions du processus Gestion de la Mission . . . . . . . . . . . . 129 10.5 Évaluation quantitative des contributions . . . . . . . . . . . . . . . . . . . 132 10.5.1 Comparaison des éléments à re-vérifier . . . . . . . . . . . . . . . . . 132 10.6 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 10.7 Conclusion du chapitre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 IV Conclusion 137 11 Conclusion et Travaux Futurs 139 11.1 Résumé des contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 11.2 Perspectives à court terme . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 11.3 Perspectives à long terme . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 Bibliographie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 viiiTable des figures Table des figures 2.1 Exemple de détermination par dérivation. . . . . . . . . . . . . . . . . . . . 16 2.2 Exemple de détermination par agrégation. . . . . . . . . . . . . . . . . . . . 16 4.1 Utilisation de Séduite au cours de la nuit de l’info. . . . . . . . . . . . . . . 38 4.2 Architecture de Séduite. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 4.3 Évolutions de PicWeb. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 5.1 Schéma du processus de développement Blink. . . . . . . . . . . . . . . . . 46 6.1 Extrait du méta-modèle de Smile : variables et types. . . . . . . . . . . . . 53 6.2 modélisation du service Helper. . . . . . . . . . . . . . . . . . . . . . . . . . 54 6.3 Extrait du méta-modèle de Smile : services, opérations et messages. . . . . 55 6.4 Extrait du méta-modèle de Smile : activités. . . . . . . . . . . . . . . . . . 55 6.5 Extrait du modèle de PicWeb : activité receive. . . . . . . . . . . . . . . . 55 6.6 Extrait du modèle de PicWeb : relations d’ordre. . . . . . . . . . . . . . . 57 6.7 Extrait du méta-modèle : relations d’ordre. . . . . . . . . . . . . . . . . . . 57 6.8 Extrait du méta-modèle : processus métier. . . . . . . . . . . . . . . . . . . 58 6.9 Modèle causal fonctionnel de PicWeb. . . . . . . . . . . . . . . . . . . . . . 60 6.10 Procédé de déduction des relations causales. . . . . . . . . . . . . . . . . . . 62 7.1 Modèle et méta-modèle d’une propriété. . . . . . . . . . . . . . . . . . . . . 67 7.2 Modèle et méta-modèle du domaine d’application. . . . . . . . . . . . . . . 68 7.3 Méta-Modèle de propriété : Valeurs de propriété. . . . . . . . . . . . . . . . 69 7.4 Modèle du temps de réponse : Valeurs de propriété. . . . . . . . . . . . . . . 70 7.5 Modèle et méta-modèle des facteurs d’influence. . . . . . . . . . . . . . . . . 71 7.6 Modèle causal enrichi avec les relations d’environnement. . . . . . . . . . . 72 7.7 Modèle causal enrichi avec les relations de dérivation. . . . . . . . . . . . . 72 7.8 Modèle causal enrichi avec les relations d’agrégation. . . . . . . . . . . . . . 73 7.9 Définition du Temps de Réponse. . . . . . . . . . . . . . . . . . . . . . . . . 75 7.10 Chaîne de déduction des relations causales de propriété. . . . . . . . . . . . 78 8.1 Processus d’évolution. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 8.2 Évolution de PicWeb. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 8.3 Étapes de l’analyse de l’évolution. . . . . . . . . . . . . . . . . . . . . . . . 88 8.4 Traduction de l’évolution en actions sur le modèle causal. . . . . . . . . . . 90 8.5 Application à PicWeb de l’analyse causale. . . . . . . . . . . . . . . . . . . 93 8.6 Application à PicWeb de l’analyse causale. . . . . . . . . . . . . . . . . . . 94 8.7 Obtention des données brutes. . . . . . . . . . . . . . . . . . . . . . . . . . . 95 8.8 Contrat de QoS qualifiant le temps de réponse de PicWeb. . . . . . . . . . 98 8.9 Détermination des causes racines de la violation du contrat de PicWeb. . . 100 9.1 Diagramme des cas d’utilisation de Smile. . . . . . . . . . . . . . . . . . . . 107 9.2 Architecture de Smile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 9.3 Procédé dirigé par les modèles de l’approche Smile. . . . . . . . . . . . . . 109 9.4 Import de PicWeb. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 9.5 Extrait de fichier composite. . . . . . . . . . . . . . . . . . . . . . . . . . . . 111Table des figures 9.6 Méta-modèle du modèle causal. . . . . . . . . . . . . . . . . . . . . . . . . . 112 9.7 Extrait d’une règle causale écrite en ATL. . . . . . . . . . . . . . . . . . . . 112 9.8 Processus de la partie QoS de Smile. . . . . . . . . . . . . . . . . . . . . . . 114 9.9 Chaîne d’outillage pour la description d’une propriété. . . . . . . . . . . . . 115 9.10 Méta-Modèle de traces de Smile. . . . . . . . . . . . . . . . . . . . . . . . . 115 9.11 Modélisation des contrat de qualité de service. . . . . . . . . . . . . . . . . 116 9.12 Méta-Modèle d’évolution de Smile. . . . . . . . . . . . . . . . . . . . . . . . 117 9.13 Utilisation de l’éditeur d’évolutions de Smile. . . . . . . . . . . . . . . . . . 118 10.1 Description des différents rôles opérationnels. . . . . . . . . . . . . . . . . . 123 10.2 Description des différents rôles d’observation. . . . . . . . . . . . . . . . . . 124 10.3 Description des différents rôles stratégiques. . . . . . . . . . . . . . . . . . . 124 10.4 Architecture du système de gestion de crises. . . . . . . . . . . . . . . . . . 127 10.5 Graphe de dépendance des processus métiers du système de gestion de crises. 127 10.6 Évolution de la taille du modèle causal au cours de la construction du système.128 10.7 Processus métier du cas d’utilisation "Exécution de la mission". . . . . . . . 129 10.8 Évolution du processus métier Gestion de la mission : UnavailableIntRes. . 130 10.9 Évolution du processus métier Gestion de la mission : UnavailableExtRes. . 131 10.10Évolution du processus métier Gestion de la mission : RehandleOnChange. 132 10.11Extrait du modèle causal du processus métier Gestion de la mission après l’évolution RehandleOnChange. . . . . . . . . . . . . . . . . . . . . . . . . . 133 xListe des tableaux Liste des tableaux 2.1 Taxonomie d’une évolution : la dimension "Où". . . . . . . . . . . . . . . . 19 2.2 Taxonomie d’une évolution : la dimension "Quoi". . . . . . . . . . . . . . . 20 2.3 Taxonomie d’une évolution : la dimension "Quand". . . . . . . . . . . . . . 21 2.4 Taxonomie d’une évolution : la dimension "Comment". . . . . . . . . . . . . 22 2.5 Récapitulatif des hypothèses de travail. . . . . . . . . . . . . . . . . . . . . . 23 3.1 Comparatif des différents processus de développement. . . . . . . . . . . . . 29 3.2 Comparatif des différentes analyses d’impact. . . . . . . . . . . . . . . . . . 35 5.1 Rôles intervenants dans la réalisation d’un système. . . . . . . . . . . . . . . 45 5.2 Description des étapes 0 à 2 du processus de développement (Blink). . . . 47 5.3 Description des étapes 3 à 5 du processus de développement (Blink). . . . 48 5.4 Description de l’étape 6 du processus de développement (Blink). . . . . . . 49 6.1 Règle causale pour les relations causales de paramètre d’entrée. . . . . . . . 62 6.2 Règle causale pour les relations causales de paramètre de sortie. . . . . . . . 63 7.1 Formules d’agrégation du temps de réponse. . . . . . . . . . . . . . . . . . . 76 7.2 Règle de production des relations causales d’environnement. . . . . . . . . . 78 7.3 Règle causale d’environnement générée. . . . . . . . . . . . . . . . . . . . . 78 7.4 Règle de production des relations causales de dérivation. . . . . . . . . . . . 79 7.5 Règle causale de dérivation générée. . . . . . . . . . . . . . . . . . . . . . . 79 7.6 Règle de production des relations causales d’agrégation. . . . . . . . . . . . 80 7.7 Règle causale d’agrégation générée. . . . . . . . . . . . . . . . . . . . . . . . 80 8.1 Liste des opérations d’évolution. . . . . . . . . . . . . . . . . . . . . . . . . 86 8.2 Correspondance entre opérations d’évolution et actions du modèle causal. . 90 8.3 Génération de la mise à jour du modèle causal de PicWeb. . . . . . . . . . 91 8.4 Description de l’opération collecte. . . . . . . . . . . . . . . . . . . . . . . . 92 9.1 Description des fonctionnalités par module. . . . . . . . . . . . . . . . . . . 108 10.1 Nombre de valeurs de propriété à re-vérifier pour chaque méthode d’analyse. 134Chapitre 1 Introduction Sommaire 1.1 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.2 Défis pour maintenir la qualité de service lors de l’évolution . . 2 1.3 Proposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.4 Organisation du document . . . . . . . . . . . . . . . . . . . . . . . 4 1.5 Liste des publications liées à cette thèse . . . . . . . . . . . . . . . 5 L ’informatique prend aujourd’hui une place de plus en plus grande dans le quotidien des personnes, et dans le quotidien des entreprises. L’outil numérique développé au cours du dernier siècle est aujourd’hui omniprésent dans la société. Cela se traduit par l’existence de nombreux systèmes logiciels, allant du simple jeu sur un téléphone portable au moteur de recherche utilisé massivement. Ces systèmes, qui autrefois étaient monolithiques et centralisés, sont devenus avec l’apogée de l’Internet et l’augmentation de la taille des organisations des entreprises des systèmes distribués, de taille conséquente, et à la complexité croissante. Les architectures orientées services (SOA) constituent une solution permettant de maî- triser cette complexité. La conception d’applications se matérialise par le biais de la chorégraphie ou de l’orchestration de services à l’aide de processus métiers, offrant ainsi un mécanisme de composition permettant de gagner en abstraction et de réduire la complexité. En ce sens, concevoir une application reposant sur les principes des architectures orientées services consiste à mettre en relation les flots de contrôle et de données de ces services. Au delà de la nécessité de produire des systèmes correspondant aux besoins des utilisateurs, la qualité de service (QoS), définie par Crnkovic et al. comme "une caractérisation de tout ou d’une partie du système, selon une préoccupation particulière" [Crnkovic 2005], constitue une préoccupation à gérer au cours du développement de logiciels. L’analyse et le maintien de la QoS d’un système sont des opérations critiques, car la QoS sert de base à l’établissement de contrats de service entre fournisseurs et utilisateurs, et un non-maintien de la QoS entrainerait une rupture de contrat. De par la composition des services, la dé- termination de la QoS d’une orchestration s’effectue par calcul, dépendant ainsi de la QoS des services la constituant. C’est ce que l’on appelle l’agrégation [Cardoso 2004]. Les logiciels que nous considérons ici, dont la taille et la complexité échappent à la compréhension d’une seule personne, sont amenés à être modifiés tout au long de leur cycle de vie. Les modifications opérées, que l’on appelle dans ce document évolutions, sont la conséquence/réaction d’un changement de besoins de la part des utilisateurs, d’un changement survenu dans l’environnement d’exécution ou encore dans l’architecture du système. Ces évolutions, de par la modification du comportement du système qu’elles entraînent, impliquent de s’assurer que la QoS n’a pas été détériorée. Ainsi, lors de chaque évolution, les changements effectués sur le logiciel impliquent de re-vérifier la QoS de l’ensemble du système.1.1. Problématique 1.1 Problématique Dans un contexte où les attentes en termes de fonctionnalités et de qualités du logiciel sont fortes, faire évoluer ce dernier est un processus critique, tant par l’effet que l’évolution peut avoir que par la nécessité d’un processus court permettant d’être réactif à l’égard des utilisateurs. Il est parfois même nécessaire d’appliquer l’évolution au cours même de leur exécution. Dans ce cas, il est vital d’établir un processus d’évolution court et minimal, pour ne pas parasiter ou ralentir son fonctionnement. Il s’agit ici d’un problème complexe, où la nécessité d’effectuer une évolution maintenant les propriétés de QoS implique une collaboration proche entre les différentes expertises de l’équipe de développement, notamment entre l’expertise de la QoS et celle de l’évolution. Le processus d’évolution nécessite d’être court dans sa réalisation, tout en s’assurant du maintien de la QoS du logiciel. L’objectif est donc ici de minimiser la re-vérification des propriétés de QoS, en déterminant de manière précise quelles parties du logiciel ont été réellement affectées par l’évolution. Dans le cadre de cette thèse, nous nous intéressons tout particulièrement aux systèmes reposant sur une architecture orientée services, pour lesquels le comportement est représenté à l’aide de processus métiers. Les mécanismes d’évolution à définir doivent permettre d’établir l’effet d’une évolution sur le reste du système, afin d’éviter un ensemble de dépendances cachées entre les éléments. De plus, le processus d’évolution devra garantir le maintien des contrats de qualité de service. Il s’agit donc non seulement de comprendre l’effet d’une évolution sur le reste du système, mais également sur les différentes propriétés de QoS ayant un intérêt pour l’équipe de développement ou pour la communauté d’utilisateurs. Enfin, ces mécanismes d’évolution devront prendre en compte la répartition des compétences et des expertises de l’équipe de développement, en définissant les différents rôles nécessaires à un processus d’évolution fiable en termes de QoS, et en identifiant les points d’interaction entre ces différents rôles pour partager leurs expertises propres. 1.2 Défis pour maintenir la qualité de service lors de l’évolution L’objectif de cette thèse est de fournir à l’équipe de développement et de maintenance les outils permettant de s’assurer que la qualité de service est maintenue au cours des différentes évolutions du logiciel, tout au long de son cycle de vie. Le maintien de la QoS lors d’une évolution est une tâche complexe, nécessitant la collaboration de différentes expertises telles que l’expertise du métier, de l’environnement d’exécution, ou encore de la propriété de QoS considérée. De plus, le contexte des architectures orientées services positionne notre travail dans un environnement où l’agilité du développement est pré-dominante. En effet, avec des changements fréquents des besoins des utilisateurs, mais également des services externes utilisés, la fiabilité de la QoS et son maintien dans de tels systèmes sont des valeurs importantes. Nous énumérons dans cette section les différents défis liés à l’évolution d’un logiciel en terme de qualité de service : 1. Collaboration entre acteurs : pour gérer une évolution et assurer le maintien de la qualité de service d’un système, la connaissance et la coopération des acteurs œuvrant au niveau du système développé, des propriétés de qualité de service étudiées, et des évolutions sont nécessaires. En effet, effectuer une évolution tout en s’assurant du maintien de la qualité de service requiert une connaissance transversale à ces différents domaines, que seule la coopération peut apporter. L’identification des différents rôles et des différentes expertises au sein de l’organisation permettront de concevoir et de 21.3. Proposition faire évoluer un système où la qualité de service est l’une des préoccupations. Cette identification est nécessaire dans le but de responsabiliser et de définir les différentes collaborations à mettre en place. 2. Interactions entre les différentes parties d’un logiciel : le logiciel réalisé par l’équipe de développement est bien souvent constitué de sous-parties, qui interagissent pour proposer des fonctionnalités attendues par les utilisateurs. Ces interactions in- fluent sur la qualité du service du système, et sont bien souvent implicites. L’identi- fication explicite des interactions entre les éléments d’un système permet d’améliorer la compréhension du système dans son ensemble, notamment lors d’une évolution. 3. Minimisation de la vérification : afin de s’assurer du maintien de la qualité de service, l’étape de l’évolution est accompagnée d’une étape de vérification, où chaque propriété de QoS est contrôlée pour l’ensemble du système. Toutefois, avec l’augmentation de la taille des systèmes, cette phase peut devenir chronophage. Ce phénomène s’accentue si l’on considère des systèmes développés de manière agile, où les évolutions sont fréquentes. Dans ces conditions, l’étape de vérification doit être la plus rapide possible afin de ne pas interférer avec le bon fonctionnement du système et de ne pas dégrader ses performances. Nous devons rendre l’étape de vérification la plus rapide possible, en minimisant le nombre d’éléments à re-vérifier. 4. Identification de la cause de la violation d’un contrat : lorsqu’une évolution viole un contrat de QoS, l’équipe de développement a pour tâche de détecter l’origine de cette violation, dans le but de pouvoir corriger l’évolution. Partant du contrat violé, il s’agit donc d’identifier l’ensemble des interactions du logiciel impliquées dans la dégradation de la QoS, afin de cibler au plus près son origine. Pour cela, nous cherchons à établir les dépendances existant entre l’exécution du logiciel et sa qualité de service. 1.3 Proposition Pour répondre à ces défis, nous présentons dans cette thèse un ensemble de contributions constituant un mécanisme d’évolution à la fois agile dans la réaction aux besoins de l’utilisateur, fiable dans le maintien de la qualité de service une fois l’évolution réalisée, et minimale, dans le sens où le processus de vérification de la qualité de service doit être le plus court possible dans le cas où l’évolution s’opèrerait à l’exécution. Ces contributions s’articulent autour d’un cycle de développement agile, nommé Blink, portant une attention particulière sur le maintien de la QoS lors de l’évolution. Notre cycle de développement met au centre des préoccupations la notion d’évolution comme élément à prendre en compte dès les premières étapes de conception du logiciel. En identifiant les différents rôles nécessaires au maintien de la QoS de l’évolution, Blink permet d’identifier l’ensemble des informations devant être fourni, et de délimiter les points d’interaction dans le but d’échanger ces informations. En complément du processus de développement, nous présentons Smile, un canevas de développement mettant en œuvre Blink. Celui-ci implémente une boucle d’évolution, permettant de concevoir, d’analyser et d’appliquer une évolution, en portant une attention particulière au maintien de la qualité de service. Le but de cette boucle est de déterminer au plus tôt l’effet que peut avoir une évolution sur le reste du système et sur sa QoS. Pour cela, notre analyse de l’évolution consiste à déterminer les relations de causalité qu’une évolution a sur le reste du système. Il s’agit ici d’utiliser ces relations causales, dans le but d’identifier les différents éléments affectés et de re-vérifier par la suite si la qualité de service de ces éléments a été affectée. Cela permet ainsi de pouvoir identifier dans un premier temps la 31.4. Organisation du document portée d’une évolution, afin de pouvoir dans un second temps minimiser le processus de re-vérification. En résumé, les contributions de la thèse sont les suivantes : – Blink, un processus de développement collaboratif pour le maintien de la QoS lors de l’évolution : nous définissons dans ce document un processus de développement pour lequel la problématique du maintien de la QoS lors de l’évolution est au centre des préoccupations. Pour cela, nous définissons un ensemble d’acteurs, devant collaborer tout au long du cycle de développement en partageant les informations propres à leur expertise qui pourraient être utile au maintien. – Une méthode de détermination des interactions entre les différentes parties du système : nous définissons dans un premier temps quels types d’influence nous pouvons retrouver dans un système et au niveau de la qualité de service. Puis, nous présentons une méthode permettant, à partir d’un système et de la description d’une propriété de qualité de service, de déterminer de manière automatique ces influences. – Une analyse d’évolution permettant de déterminer l’effet d’une évolution sur la QoS du système : en réutilisant les modèles représentant les interactions existantes au sein d’un système, nous présentons une analyse permettant, à partir d’une évolution, de savoir l’effet de cette dernière au sein du système, mais également de déterminer si un contrat de QoS a été violé ou non, gage du maintien de la QoS. – Smile, un canevas de développement automatisant les différents traitements nécessaires à Blink : nous introduisons dans ce document notre canevas supportant les différents points abordés ci-dessus, et montrons ce que ce canevas de développement apporte lors de l’évolution. Afin de valider l’apport de notre approche dans le maintien de la QoS lors de l’évolution, nous appliquons Blink et Smile sur un cas d’étude nommé Système de gestion de crises. Lors de cette validation, nous vérifions notamment si notre outil est en mesure de détecter le non-maintien de la QoS lors de l’évolution du cas d’étude. 1.4 Organisation du document Ce document est organisé en trois parties : 1. La première partie se concentre sur le contexte et les motivations de la thèse. Dans le chapitre 2, nous posons le contexte de travail, d’un point de vue conceptuel et technologique. Nous définissons ici les notions liées aux architectures orientées services, à la qualité de service, et à l’évolution des systèmes logiciels. Dans le chapitre 3, nous dressons l’état de l’art des travaux de recherche sur ce domaine. Pour cela, nous nous focalisons sur deux axes, à savoir les cycles de développement d’un logiciel, et les différentes analyses d’impact pouvant déterminer l’effet d’une évolution, ou d’un changement en général. Enfin, dans le chapitre 4, nous décrivons PicWeb, que nous utilisons comme exemple fil rouge nous permettant d’illustrer les différentes contributions de la thèse. Après avoir présenté l’exemple, nous expliquons comment un problème de qualité de service est survenu lors de son évolution. 2. La deuxième partie regroupe les contributions de la thèse, réparties en quatre chapitres. Dans le chapitre 5, nous présentons Blink, un processus de développement orienté pour le maintien de la qualité de service au cours des différentes évolutions. Nous mettons notamment en évidence les différents acteurs nécessaires au maintien de la QoS. Les chapitres 6 à 8 se focalisent alors successivement sur chaque acteur 41.5. Liste des publications liées à cette thèse impliqué dans Blink. Le chapitre 6 se centre sur la réalisation d’un système, et sur le rôle de l’architecte du système. Nous définissons un méta-modèle permettant de représenter un système à base de processus métiers. Puis, nous introduisons la notion de causalité dans un système, permettant de représenter les interactions entre ses différentes parties, et dressons une liste de causalités que l’on peut retrouver. Le chapitre 7 est focalisé sur le rôle de l’expert en qualité de service. Nous présentons ici notre méta-modèle pour représenter une propriété, ainsi que QoS4Evol, un langage permettant à l’expert en QoS de la définir de manière textuelle. De manière similaire au chapitre précédent, nous définissons ensuite la notion de causalité pour les propriétés de qualité de service. Nous listons les différents types de relation causale que nous pouvons retrouver pour une propriété de QoS, et les illustrons sur PicWeb. Enfin, nous présentons une méthode permettant d’extraire automatiquement les relations causales de la description d’une propriété. Le chapitre 8 porte sur l’architecte de l’évolution. Nous introduisons un langage d’évolution des processus métiers, permettant d’ajouter ou de supprimer des fonctionnalités. Puis, nous nous focalisons sur l’étape d’analyse d’une évolution, où nous utilisons les relations causales présentées dans les chapitres précédents pour déterminer l’effet d’une évolution sur la qualité de service d’un système, et ainsi qualifier si une évolution permet le maintien de la QoS ou non. 3. La troisième partie du document s’intéresse à l’évaluation de notre approche. Le chapitre 9 détaille la mise en œuvre des différentes contributions au travers de notre canevas, Smile, tandis que le chapitre 10 est une évaluation de notre approche sur un autre cas d’étude, le système de gestion de crise. Ce cas d’étude a l’avantage d’être de taille plus importante que PicWeb, d’être constitué de plusieurs processus métiers, et d’être doté d’une base d’évolutions conséquentes. Enfin, nous terminons avec le chapitre 11, où nous faisons le bilan des différents chapitres de la thèse, et présentons quelques pistes à explorer dans de futurs travaux. 1.5 Liste des publications liées à cette thèse Les communications mentionnées ci-dessous ont été réalisées dans des manifestations avec comité de sélection. Communications internationales – A Causal Model to predict the Effect of Business Process Evolution on Quality of Service. Alexandre Feugas, Sébastien Mosser et Laurence Duchien. Dans International Conference on the Quality of Software Architectures (QoSA’13), pages 143-152, Vancouver, Canada, juin 2013. (Rang A selon le classement CORE Austalian) Communications nationales – Déterminer l’impact d’une évolution dans les processus métiers. Alexandre Feugas, Sébastien Mosser, Anne-Françoise Le Meur et Laurence Duchien. Dans IDM, pages 71-76, Lille, France, juin 2011. 51.5. Liste des publications liées à cette thèse Posters – Un processus de développement pour contrôler l’évolution des processus métiers en termes de QoS. Alexandre Feugas, Sébastien Mosser et Laurence Duchien. Poster dans GDR GPL, pages 237-238, Rennes, France, Juin 2012. 6Première partie Contexte et MotivationsChapitre 2 Contexte Sommaire 2.1 Les architectures orientées services . . . . . . . . . . . . . . . . . . 9 2.1.1 Définitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.1.2 Organisation des architectures orientées services . . . . . . . . . . . 10 2.2 La Qualité de Service . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.2.1 Qualité du logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.2.2 Méthodes de détermination de la qualité de service . . . . . . . . . . 14 2.2.3 Contrats de Qualité de Service . . . . . . . . . . . . . . . . . . . . . 17 2.3 Évolution des systèmes logiciels . . . . . . . . . . . . . . . . . . . . 17 2.3.1 Définition de l’évolution . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.3.2 Caractéristiques d’une évolution . . . . . . . . . . . . . . . . . . . . 18 2.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 N ous avons présenté dans l’introduction l’objectif de cette thèse. Dans ce chapitre, nous présentons ses enjeux d’un point de vue conceptuel et technologique : nous abordons dans un premier temps les architectures orientées services. Puis, nous présentons la notion de qualité de service, ainsi que les approches existantes permettant de l’étudier. Nous introduisons enfin la définition de l’évolution : quelles notions se trouvent derrière ce concept, comment l’équipe de développement s’y prend pour faire évoluer un logiciel. 2.1 Les architectures orientées services 2.1.1 Définitions Les architectures orientées services (SOA) sont un nouveau paradigme de conception apparu dans la fin des années 90. Il existe différentes définitions pour caractériser les architectures orientées service. Parmi elles, nous pouvons retenir la définition du W3C [Haas 2004] : Définition 1 Architecture Orientée Services (W3C) : "une architecture orientée services regroupe un ensemble de composants qui peuvent être invoqués, et pour lesquels les descriptions de leurs interfaces peuvent être publiées et découvertes". Cette définition peut être complétée par une autre définition, d’IBM : Définition 2 Architecture Orientée Services (IBM) : "une architecture orientée services est un canevas d’information qui considère les applications métiers de tous les jours pour les fragmenter en fonctions et processus métiers individuels, appelés services. Une architecture orientée service permet la construction, le déploiement et l’intégration de ces2.1. Les architectures orientées services services indépendamment des applications et des plate-formes d’exécution". De ces deux définitions, nous pouvons comprendre que la notion de service, comme entité de calcul invocable, et pour lequel une interface est définie, est principale. Ces services sont indépendants, ils sont déployés pour pouvoir par la suite être publiés, découverts et invoqués. Il existe différentes technologies dites orientées services, reprenant les principes des architectures orientées services plus ou moins fidèlement. Parmi elle, nous retiendrons notamment les web-services [Kuebler 2001], où l’on considère que les services sont définis et exposés en utilisant les standards du Web. Propriétés remarquables Les architectures orientées service ont été définies pour concevoir des systèmes logiciels pour lesquels les entités de première classe sont les services, des entités autonomes, invocables, dont l’interface est clairement explicitée. Plusieurs travaux ont proposé la caractérisation des architectures orientées services [Papazoglou 2003, Huhns 2005, Breivold 2007, Papazoglou 2007]. Dans la suite, nous recensons les propriétés suivantes : – Couplage lâche des éléments : afin de pouvoir faciliter la reconfiguration d’un service, e.g., son remplacement, les éléments d’un système doivent bénéficier d’un couplage lâche, c’est-à-dire qu’il n’est pas nécessaire pour un appelant à un service de connaître la structure ou l’implémentation de ce dernier pour pouvoir l’utiliser. De même, une façon de permettre un couplage lâche au niveau d’un service consiste à séparer l’interface de l’opération et son implémentation. Cela offre la possibilité de pouvoir modifier l’implémentation, ou de pouvoir exposer facilement l’interface du service. – Neutralité technologique : pour permettre à tout système d’interagir avec un service, la dépendance à un contexte technologique donné est à proscrire. Cette propriété s’inscrit dans un contexte d’inter-opérabilité, facilitant ainsi l’établissement de partenariats entre différentes organisations. – Transparence de la localisation : un service doit être explicitement atteignable, de façon à permettre à tout client de pouvoir l’invoquer, dans son périmètre de disponibilité. Dans le cas des web-services, un service doit être disponible à n’importe quel point de l’Internet. – Modularité et Composabilité : les architectures orientées services mettent en avant le côté réutilisable des services. Par le biais d’une interface exposée et de l’interopérabilité des services, le concept de service a été conçu pour facilité la modularité, la réutilisabilité et la composabilité d’une application. Ainsi, il est possible de délimiter le cadre de modification d’un service par son aspect modulaire, l’exposition de son interface permet de réutiliser le service dans une autre application, et, partant de différents services, il est possible de composer un nouveau service avec une fonctionnalité différente, en utilisant d’autres services par le biais d’invocations. Pour atteindre cet ensemble de propriétés, un éco-système des architectures orientées services a été défini par Papazoglou [Papazoglou 2003] comme étant constitué de trois couches. Dans la suite de cette section, nous détaillons cette organisation en trois couches. 2.1.2 Organisation des architectures orientées services Dans son travail sur la définition des architectures orientées service, Papazoglou a imaginé l’éco-système des SOA comme étant constitué de trois couches, où chaque couche s’appuie sur les définitions des couches précédentes. La première couche concerne les services à 102.1. Les architectures orientées services leur niveau le plus simple. Ici, on s’intéressera aux notions d’interface, de publication et de sélection d’un service. La seconde couche s’appuie sur les services basiques pour définir de nouveaux services par composition. On appelle composition de services la réalisation d’un service en réutilisant d’autres services, le plus souvent pour construire une fonctionnalité de complexité supérieure. Ici, on attachera plus d’importance à la sémantique du nouveau service composé, mais également à des caractéristiques non fonctionnelles d’un service telles que les propriétés de qualité de service. Enfin, le dernière couche considère la gestion des services. Ici, il s’agit en fait de considérer l’infrastructure dans son ensemble, en ayant en tête des préoccupations telles que le cycle de vie du service, son contrôle, et la gestion du changement d’un service. 2.1.2.1 Services simples Définition d’un service Comme introduit dans les propriétés des SOA, une opération d’un service, ou par abus de langage un service, a une interface explicitement définie. Cette interface définit a minima la signature de l’opération. Concrètement, il peut s’agir d’une structure écrite dans un Language de Description d’Interface (IDL) [Bachmann 2002]. Dans le cadre des web-services, le langage adopté est le Langage de Description des Web Services (WSDL) [Chinnici 2007]. Il est ainsi possible d’y décrire des types de données, les signatures des différentes opérations, tout comme consigner la localisation du service par le biais d’un identifiant de ressource (Uniform Resource Identifier, URI en abbrégé) [Coates 2001]. Un service est en soi autonome et indépendant. C’est cette caractéristique qui permet aux architectures orientées services d’offrir un couplage lâche entre les éléments. Interactions d’un service Au niveau des interactions entre les services, il est important de différencier deux acteurs différents. Ces acteurs auront des préoccupations différentes : – Fournisseur de Service : il est en charge de l’implémentation des différentes opé- rations du service. Il doit notamment prendre en compte la qualité de service, en adoptant une politique, cette police pouvant aller d’une politique de "meilleur effort" (où aucun niveau minimal de qualité est à atteindre), jusqu’à mettre la qualité de service au rang de préoccupation majeure. Ce dernier scénario se rencontre fréquemment dans les logiciels à base de services. En effet, dans un système où les services sont publiés et disponibles pour tous, le critère de différenciation et de choix entre deux services implémentant les mêmes fonctionnalités portera sur le niveau de qualité de service garanti pour l’opération. Il est important dans ce cas de fournir le service le plus efficient possible. Afin de pouvoir établir ces contraintes et ces attentes en termes de qualité de service, il est nécessaire pour le fournisseur du service et pour l’utilisateur du service d’établir un contrat, nommé Service Level Agreement (SLA) [Ludwig 2003], où chacune des parties s’engagent respectivement à fournir un certain niveau de qualité de service et à utiliser le service dans certaines conditions. Nous reviendrons sur ce point dans la section 2.2.3. – Utilisateur du service : il s’agit de l’entité faisant appel à l’opération proposée par le fournisseur. Si l’utilisateur n’a a priori aucun engagement auprès du fournisseur de service, ce dernier doit être en mesure d’établir des limites dans l’utilisation du service invoqué, afin de pouvoir garantir un niveau de qualité de service satisfaisant. En effet, invoquer un service de façon disproportionnée (trop fréquemment par exemple) pourrait notamment détériorer les performances de ce dernier [Menasce 2002]. De 112.2. La Qualité de Service plus, l’utilisateur du service doit être le garant de la bonne intégration du service dans l’éco-système du logiciel qu’il réalise, notamment dans le cadre de transactions. 2.1.2.2 Composition de Services La notion de service est enrichie avec le concept de composition, où l’on va chercher ici à réutiliser des services existants pour, en les combinant, produire un nouveau service ayant une fonctionnalité différente. Dans les architectures orientées services, il existe principalement deux types de composition : la composition par orchestration et la composition par chorégraphie. Nous appelons orchestration de services un processus métier exécutable, pouvant interagir avec des services internes et externes [Peltz 2003]. Il s’agit en fait de la combinaison d’un flot de contrôle et d’un flot de données pour décrire la séquence des opérations à effectuer pour aboutir à un but donné. L’orchestration d’un service diffère de la chorégraphie dans le sens où cette dernière a un rôle de vision globale des interactions d’un système, là où l’orchestration représente le comportement d’une seule opération, et ses échanges avec d’autres services. 2.1.2.3 Gestion de services Le dernier niveau organisationnel consiste à gérer les différents services existants. Dans cette partie, il s’agit de gérer le cycle de vie d’un service (marche/arrêt) ainsi que le contrôle de son exécution. Dans certains cas, il pourra également s’agir de gérer le remplacement à chaud de services par un autre, en cas de défaillance par exemple. Ces techniques sont implémentées dans les Bus de Services pour les Entreprises (ESB), véritable plate-forme d’exécution gérant entre autres l’exécution des services et leurs communication. La modularité présente dans les architectures orientées services, associée à la notion d’inter-opérabilité, permet notamment de faciliter la sélection ou le remplacement d’un service par un autre aux fonctionnalités similaires. Dès lors, le concepteur a face à lui un panel de services équivalents parmi lesquels il devra en choisir un. Pour effectuer son choix, il peut désormais prendre en compte un nouveau critère de sélection : la qualité de service. 2.2 La Qualité de Service Dans cette section, nous présentons la notion de qualité de service. Nous introduisons dans un premier temps le domaine de qualité du logiciel, avant de nous concentrer sur ce qu’est la qualité de service, quelles sont les différentes méthodes de détermination, et comment il est possible de la maintenir dans les SOA. 2.2.1 Qualité du logiciel La notion de qualité du logiciel regroupe l’ensemble des caractéristiques visant à évaluer la manière dont le logiciel a été réalisé. Derrière ce terme, on retrouve un ensemble de caractéristiques ; certaines sont quantifiables, tandis que d’autres sont totalement à l’appréciation de l’humain. Afin de pouvoir caractériser les caractéristiques d’un logiciel qui ne sont pas propres à son exécution ou à sa logique métier, la notion de qualité du logiciel a été introduite dans le milieu des années 70 pour définir une classification d’un ensemble de propriétés de qualité du logiciel [Boehm 1976]. Cette notion fut normalisée par la norme ISO/CEI9126 [ISO 2001] et est régulièrement ré-actualisée [ISO 2004], pour s’inscrire désormais dans une démarche d’établissement des besoins de qualité et de son évaluation. Cette 122.2. La Qualité de Service démarche se nomme Square. On retrouve notamment dans cette norme une classification regroupant l’ensemble des propriétés de qualité autour de 5 catégories : – La capacité fonctionnelle : il s’agit de la manière dont les fonctionnalités développées correspondent au cahier des charges. On s’intéresse notamment ici aux souscaractéristiques d’aptitude, d’exactitude et d’interopérabilité [Brownsword 2004]. – La fiabilité : il s’agit de la faculté du logiciel à continuer d’être digne de confiance. Pour cela, on s’intéresse aux sous-caractéristiques de maturité, de tolérance aux fautes et de capacité de récupération [Ucla 2001, Clements 2003]. – La facilité d’usage : cette catégorie qualifie la capacité d’un utilisateur quelconque à utiliser le logiciel développé. On s’intéresse ici aux sous-caractéristiques d’exploitabilité, de facilité d’apprentissage et de facilité de compréhension – L’efficacité : cette caractéristique étudie l’adéquation entre les moyens financiers et humains mis en œuvre pour réaliser le logiciel, et les besoins effectifs. On s’intéresse ici à l’efficacité en parlant des ressources employées, et des temps de réalisation – La maintenabilité : cette catégorie regroupe toutes les caractéristiques propres à la faculté de modifier le logiciel pour ,par exemple, corriger un bogue. On s’intéresse ici aux sous-caractéristiques de stabilité, de facilité de modification, de facilité d’analyse, et de facilité à être testé. – La portabilité : enfin, une dernière caractéristique propre à la qualité se centre sur la capacité à déployer une application sur une machine quelconque. On s’intéresse ici aux sous-caractéristiques de facilité d’installation, de facilité de migration, d’adaptabilité et d’interchangeabilité. De toutes ces sous-caractéristiques, certaines sont mesurables et quantifiables, tandis que d’autres sont subjectives. Dans le cadre de cette thèse, nous considérons que les propriétés de qualité de service sont quantifiables, et dont un changement de valeur démontre un changement dans le comportement du système. À noter qu’il est important pour les différentes personnes gravitant autour du logiciel développé de prendre en compte la qualité du logiciel. Pour le client, il s’agit du gage d’un système performant. Pour les développeurs, développer un système de qualité permet de s’assurer que l’entreprise engrangera du profit au lieu d’essuyer des pertes. Qualité de Service Il existe de nombreuses définitions de la qualité de service. Parmi elles, nous retenons dans ce document la définition de Crnkovic et al. [Crnkovic 2005] : Définition 3 Qualité de Service : On appelle propriété de qualité de service "une caractérisation de tout ou d’une partie du système, selon une préoccupation particulière". Il s’agit ici de propriétés portant directement sur le comportement du logiciel. Elles sont le plus souvent quantifiables. Dans le cadre de cette thèse, nous restreignons notre étude des propriétés de QoS aux propriétés quantifiables de manière non équivoque. Un exemple de propriétés de qualité de service correspondant à notre définition est les propriétés de performance telles que la sécurité, le temps de réponse ou la disponibilité [O’Brien 2007, Rosenberg 2006], pour lesquelles il existe bien souvent des outils d’analyse ou de contrôle à l’exécution permettant d’obtenir une valeur numérique. Tout particulièrement, on regardera du côté de [Lelli 2007, Fakhfakh 2012] pour des exemples de propriétés de qualité de service que l’on rencontre dans les SOA. 132.2. La Qualité de Service Il existe de nombreux langages de modélisation de la qualité de service. Les travaux les plus proche de notre thématique sont CQML [Rottger 2003], WQSDL [Newcomer 2002] et MARTE [OMG 2009b]. Dans ces langages, une propriété est définie par son nom. À ce nom est associé a minima une unité de grandeur et un critère de comparaison permettant de savoir si une valeur est meilleure qu’une autre. Par exemple, on cherchera le plus souvent à minimiser des durées (le plus petit est meilleur), mais on cherchera à augmenter un pourcentage dans le cas de la disponibilité (le plus grand est meilleur). Outre ces informations, les langages de QoS décrivent une, ou plusieurs manières de déterminer la valeur de qualité de service. Nous discutons des différentes méthodes de détermination dans la section suivante. 2.2.2 Méthodes de détermination de la qualité de service Dans le contexte de la thèse, les propriétés de qualité de service sont des grandeurs quantifiables caractérisant un spécimen donné, à savoir le service. Nous présentons dans cette section les différentes méthodes de détermination de la qualité de service existantes. Détermination par analyse statique Une manière de déterminer les valeurs des propriétés de qualité de service consiste à effectuer une analyse statique du logiciel. Cette méthode s’opère le plus souvent au cours de la phase de conception, et peut s’appuyer sur des informations provenant de l’exécution du logiciel. De nombreuses techniques existent pour analyser un logiciel. Par exemple, de nombreux travaux transforment le logiciel/processus métier en réseau de Pétri [Reisig 1998] pour effectuer des analyses formelles. On retiendra notamment les travaux de van der Aalst et de Massuthe qui cherchent à déterminer si un logiciel est correct [Van der Aalst 2008, Massuthe 2005]. Dans le domaine de l’ingénierie des performances, l’établissement de modèles tels que les réseaux de file d’attente ("queuing network" en anglais) ou les modèles d’utilisation permettent de simuler l’exécution du système. Il est également possible de traduire un processus métier dans une logique temporelle linéaire (LTL) [Pnueli 1977, Giannakopoulou 2001] ou dans un langage de Pi-Calcul [Milner 1999]. Cela permet par exemple de déterminer des propriétés de sûreté et de correction (justesse). [Havelund 2002, Ferrara 2004]. La détermination par analyse est particulièrement adaptée pour des propriétés portant sur la structure ou l’architecture du système, et qui ne dépendent pas de l’état des éléments du système à l’exécution. Cette technique s’applique hors-ligne, à un moment où on peut se permettre de prendre plus de temps pour exécuter les analyses. Toutefois, dans certains cas, comme lorsqu’on souhaite déterminer la taille d’un message où la taille de certaines variables n’est pas fixe, l’analyse n’est pas déterminable hors ligne. Dans ce cas, l’analyse raffine en déterminant tout ce qui est possible à la conception, pour aller chercher uniquement les informations nécessaires à l’exécution. On parle alors d’analyse dynamique. Détermination par analyse dynamique Dans le cas où certaines informations ne sont pas disponibles hors ligne, la détermination d’une valeur de propriété s’effectue à l’exécution. C’est le cas notamment pour des propriétés telles que le temps de transmission d’un message ou le temps de réparation d’un service [OASIS 2010], qui ont une forte dépendance au contexte d’exécution. Pour cela, la détermination s’effectue à l’aide d’un moniteur. Un moniteur a pour rôle d’observer un 142.2. La Qualité de Service ou plusieurs événements survenant au cours de l’exécution d’un logiciel, en capturant des informations sur l’état du logiciel avant, après, ou en parallèle de ces événements. Outre la propriété qu’il observe, il est possible de qualifier un moniteur selon différents critères. Nous retiendrons ici le type de moniteur. Wetzstein et al. classifient dans leurs travaux trois types de moniteurs : moniteur externe au moteur d’exécution, instrumentation du moteur d’exécution et instrumentation du processus métier [Wetzstein 2009]. Selon la solution choisie, l’insertion de code lié à la capture des informations à l’exécution engendrera un sur-coût en terme de performance pouvant influer sur le bon fonctionnement du système et sur sa qualité de service. On dit que le contrôle à l’exécution est intrusif [Cheng 2009]. L’intrusion du moniteur ainsi que son niveau d’interopérabilité seront plus ou moins grands. Par exemple, un moniteur instrumentant le moteur d’exécution sera optimisé pour que son intrusion soit moindre, mais il ne sera par compatible avec un autre moteur d’exécution. Nous retiendrons également la granularité de l’observation d’un moniteur : il s’agit du degré de détail auquel le moniteur est sensible [Ghezzi 2007]. À titre d’exemple, une mesure peut être effectuée au niveau du processus pour avoir une vision d’ensemble, au niveau de l’activité, ou encore basé sur des événements bas niveau tels que le changement d’état d’une activité en passe d’être exécutée [De Pauw 2005]. Ici encore, cette finesse dans la granularité a un coût : plus le contrôle sera fin, et plus de données seront collectées et précises. C’est autant de données qu’il faut par la suite analyser et interpréter. En revanche, rester à niveau d’abstraction trop élevé empêchera l’observation de certains phénomènes. Détermination par dérivation de propriétés Il est également possible de définir la détermination d’une propriété comme étant une fonction mathématique dépendant de valeurs d’autres propriétés. On parle de propriété dérivée de sous-propriétés. La valeur de propriété pour un élément du système (tel qu’un service) est définie en fonction de valeurs d’autres propriétés pour le même élément du système. Par exemple, le temps de réponse d’un service peut être défini comme étant la somme du temps de transmission et du temps d’exécution. Cette définition est opérée à l’aide d’une formule mathématique, nommée formule de dérivation. La Figure 2.1 est un exemple de dérivation où le temps de réponse est calculé en se basant sur les valeurs des propriétés dont il dérive. La détermination des valeurs de propriétés par dérivation a pour avantage d’être lé- gère, les formules définies utilisant le plus souvent des opérateurs arithmétiques simples. Toutefois, il est nécessaire de déterminer les opérandes utilisés dans la formule ; ces valeurs étant d’autres valeurs de propriétés, la détermination par dérivation nécessitera au préalable d’effectuer des analyses à la conception et/ou des mesures à l’exécution. Détermination par agrégation de valeurs Nous avons restreint dans le cadre de cette thèse le champ des propriétés étudiées aux propriétés composables. Cela veut dire que pour un élément de composition (tels que les processus métiers, les séquences, ou les appels en parallèle), il existe une formule mathématique permettant de déduire la valeur de propriété de la composition, à partir des valeurs de propriétés des activités contenues. Il suffit donc d’observer ces activités (par analyse statique ou par mesure), et de composer une valeur de propriété pour la composition en utilisant une formule mathématique nommée formule d’agrégation. Il est important de noter qu’ici, contrairement à la détermination par dérivation de propriétés, la détermination par agrégation de valeurs ne repose pas sur plusieurs propriétés différentes. Ici, il s’agit de 152.2. La Qualité de Service Activity act Monitor Report Transmission Time = 30 ms Monitor Report Computation Time = 19 ms Derivation Report Response Time = 30 + 19 = 49 ms Figure 2.1 – Exemple de détermination par dérivation. déduire une valeur de propriété pour un élément de composition à partir des valeurs de la même propriété, pour les éléments le constituant. La Figure 2.2 illustre la détermination par agrégation sur un processus métier quelconque. Ici, le temps de réponse du processus est la somme des temps de réponse des activités qu’il contient. De nombreux travaux ont porté sur l’établissement de ces formules d’agrégation. Les premiers à les avoir formalisées sont Cardoso [Cardoso 2004] et Jaeger [Jaeger 2004]. Ces travaux furent repris par Mukherjee [Mukherjee 2008], et par Dumas pour permettre leur établissement dans le cadre de processus métiers mal formés [Dumas 2010]. Canfora a même étendu le concept d’agrégation à des propriétés non fonctionnelles, mais spécifiques au domaine du logiciel étudié [Canfora 2006]. a1 a2 a4 a3 Derivation Report Response Time = 9 ms Derivation Report Response Time = 30 ms Derivation Report Response Time = 55 ms Derivation Report Response Time = 6 ms Aggregation Report Response Time = 9 + 30 + 55 + 6 = 100 ms Figure 2.2 – Exemple de détermination par agrégation. De manière similaire à la détermination par dérivation, la méthode par agrégation est peu coûteuse en elle-même en termes de ressources. Toutefois, elle nécessitera également une phase préliminaire de détermination à la conception et/ou à l’exécution. 162.3. Évolution des systèmes logiciels 2.2.3 Contrats de Qualité de Service Dans l’éco-système d’un service, différentes parties œuvrant pour sa réalisation et son utilisation doivent collaborer. Il s’agit notamment du fournisseur du service, responsable de son implémentation et de sa disponibilité, et du consommateur du service, qui l’utilise. Afin de pouvoir garantir que le service proposé reste stable au niveau de sa qualité de service, les différentes parties impliquées doivent se mettre d’accord. Pour pouvoir établir cet engagement, il est nécessaire d’établir des contrats entre ces différentes parties. Il existe différents supports pour pouvoir établir ces contrats. Le plus utilisé se nomme Web Service Level Agreement (WSLA) [Keller 2003]. Un contrat est un accord liant deux ou plusieurs parties sur certaines conditions, telles que les responsabilités de chaque partie ou les engagements à respecter. Dans le cadre des WSLA, un contrat est constitué de trois sections. D’abord, il s’agit d’établir l’identité de chaque partie impliquée. Puis, le contrat se poursuit par la désignation du service pour lequel les parties se mettent d’accord. Enfin, la dernière section du contrat établit les différentes clauses d’engagement. On parle alors d’objectifs de niveau de service (SLO). Un objectif est constitué d’une partie engagée par l’objectif (l’Obligee en anglais), d’une période de validité de l’objectif, et d’une condition à respecter. Cette condition prend la forme d’une expression, indiquant un ensemble d’opérateurs sur des métriques. Par exemple, on pourra décrire que la métrique de disponibilité doit être supérieur ou égale à 80%, ce qui signifie que le service en question doit être accessible pour le consommateur au minimum 80% du temps. Une fois que le contrat est mis en place, il est nécessaire de s’assurer que tous les objectifs sont bien respectés. Une approche possible pour cela consiste à utiliser un contrôleur, qui vérifie bien qu’aucun objectif n’est violé. On retiendra notamment les travaux de Oriol et al., qui ont développé un système nommé SALMon pour l’analyse et le contrôle de SLA [Oriol 2008]. Nous venons de présenter dans cette section les travaux existants autour de la qualité de service dans les architectures orientées services. Nous avons vu différentes manières de déterminer une valeur de propriété de QoS permettent de qualifier un service, avant de s’intéresser à la manière dont la QoS peut être conservée en définissant un contrat entre le fournisseur du service et son consommateur. Si ce dernier point est facilement vérifiable au moment du contrat, il convient de s’intéresser à l’étape de l’évolution, au cours de laquelle les changements opérés peuvent interférer la validité du contrat. Pour cela, nous nous intéressons dans la section suivante aux différentes caractéristiques de l’évolution des systèmes logiciels. 2.3 Évolution des systèmes logiciels 2.3.1 Définition de l’évolution Le domaine de cette thèse se concentre sur la manière de faire évoluer un logiciel au fil du temps. Cela veut dire par exemple d’ajouter des fonctionnalités, ou de maintenir le code pour effectuer les mêmes fonctionnalités. Traditionnellement, les logiciels ont besoin de changer pour correspondre aux besoins des utilisateurs, pour corriger un bug ou pour supporter l’évolution technologique. La notion d’évolution est apparue dans la fin des années 60 [Lehman 1969]. Lehman et al. ont été les premiers à en donner une définition [Lehman 1985] : Définition 4 Évolution du logiciel : "La satisfaction [des besoins] continue demande des change- 172.3. Évolution des systèmes logiciels ments continus. Le système aura à être adapté en fonction d’un environnement changeant et des besoins changeants, en développant des concepts et en faisant progresser les technologies. L’application et le système doivent évoluer. " Ce genre de logiciel est appelé un logiciel de type-E. Pour accompagner cette définition, les auteurs ont érigé une série de lois de l’évolution, établies de manière empirique suite à l’étude de plusieurs systèmes industriels monolithiques [Lehman 1997, Lehman 2006]. Parmi elles, nous retenons les suivantes, car elles s’inscrivent tout particulièrement dans notre contexte : Définition 5 Lois de l’évolution du logiciel : – Continuité du changement : Un système satisfera progressivement de moins en moins les besoins des utilisateurs au fil du temps, à moins qu’il s’adapte de manière continue pour satisfaire les nouveaux besoins. – Croissance de la complexité : Un système deviendra progressivement de plus en plus complexe, à moins qu’un travail soit effectué pour réduire la complexité. – Déclin de la qualité : Un système sera perçu comme perdant en qualité au fil du temps, à moins que sa conception soit maintenue avec précaution et adaptée à de nouvelles contraintes opérationnelles. En s’appuyant sur des expériences industrielles concrètes, ces trois lois renforcent notre position sur le besoin de faire évoluer un logiciel, et du besoin de s’assurer que la qualité du système continue à être maintenue au fil du temps. Il est important de noter ici que la notion de changement est au centre de ces définitions. Ce changement peut s’opérer de plusieurs manières : si l’on considère l’éco-système d’un système logiciel comme étant constitué du code source du système, de l’environnement dans lequel il est exécuté, des besoins utilisateurs desquels le système a émané, le changement peut s’opérer sur chacun de ces éléments. Pour nous positionner dans cet éco-système, nous nous appuyons sur les travaux de Godfrey et al. [Godfrey 2008]. Dans leur papier, les auteurs dressent un état des lieux du vocabulaire utilisé et des différentes catégories d’opérations que l’on peut qualifier de "changement". Ils se positionnent sur l’utilisation des mots maintenance et évolution. Dans le contexte de la thèse, nous considérons que la maintenance est une phase au cours de laquelle le logiciel est modifié pour corriger des bugs. Nous appelons adaptation la modification du logiciel pendant son exécution pour réagir à un changement de son environnement. En- fin, nous appelons évolution la modification d’un système logiciel suite à l’apparition de nouveaux besoins des utilisateurs. 2.3.2 Caractéristiques d’une évolution Cette section s’intéresse aux différents facteurs permettant de caractériser une évolution. Nous présentons dans un premier temps les différentes catégories, avant de positionner nos travaux pour chaque catégorie, dessinant ainsi le type d’évolution que nous traitons dans cette thèse. Afin de pouvoir décrire les caractéristiques d’une évolution, Mens et al. ont dressé une taxonomie de l’évolution du logiciel [Mens 2003]. Dans ces travaux, les auteurs ont défini quatre dimensions pour caractériser une évolution : le Où, le Quoi, le Quand et le Comment de l’évolution. Sous chaque dimension, un ensemble de caractéristiques caractérise 182.3. Évolution des systèmes logiciels cette dimension, proposant parfois diverses alternatives. Nous reprenons chacune de ces caractéristiques dans la suite pour positionner les travaux de cette thèse, en définissant quel type d’évolution nous traitons. Le "Où" de l’évolution : Cette dimension cherche à caractériser la localisation de l’application d’une évolution. Pour cela, les auteurs se sont intéressés à différents facteurs : – le type d’artéfact logiciel modifié : une évolution va consister en la modification d’un élément du système au sens large. Ici, il peut s’agir bien évidemment du code source de l’application ; mais on peut également considérer l’évolution comme un changement au niveau des besoins de l’utilisateur, de l’architecture, ou encore de la documentation. – la granularité de l’évolution : ce facteur est un ordre de grandeur évaluant à quel niveau de finesse l’évolution opère. Il peut s’agir d’une granularité fine, telle qu’un changement d’instruction ou de paramètre, jusqu’à un changement opéré à l’échelle du fichier, du package, du service, ou même du système dans son ensemble. – l’impact de l’évolution : le facteur d’impact est un critère d’importance pour qualifier une évolution. Il a pour but de caractériser la portée de l’effet du changement sur le reste du système. Il s’agit ici également d’un ordre de grandeur, allant d’un impact local, jusqu’à un impact à l’échelle du système. – la propagation du changement : ce facteur reprend la notion d’impact, en l’appliquant à l’échelle du processus de développement. Là où le facteur d’impact d’une évolution se concentre sur l’effet de l’évolution sur le comportement du système, la propagation du changement s’intéresse aux effets sur d’autres éléments tels que la documentation ou le modèle conceptuel. Nous résumons l’ensemble des facteurs de la dimension "Où" dans la Table 2.1, où les éléments notés en gras sont ceux que nous traitons dans le cadre de la thèse. Comptetenu de la définition de l’évolution que nous avons choisie, nous traitons des évolutions portant sur une partie du code source de l’application, à savoir les processus métiers. Ces évolutions ont une granularité fine : nous souhaitons pouvoir caractériser tout changement dans un processus métier, et un impact pouvant être local comme global. Enfin, nous nous intéressons uniquement à son effet sur le comportement du système, nous ne traitons pas la propagation du changement sur d’autres documents de conception. Table 2.1 – Taxonomie d’une évolution : la dimension "Où". Où Type d’artéfact Granularité Impact Propagation du changement Documentation Paramètre Local Documentation Conception Instruction Système Conception Implémentation Fichier Implémentation Tests Package Tests Le "Quoi" de l’évolution : Cette dimension s’intéresse aux caractéristiques du système sur lequel l’évolution est appliquée. – Disponibilité : la disponibilité du système peut être définie comme la capacité du système à répondre à une requête dans un laps de temps donné. Ici, il est important de 192.3. Évolution des systèmes logiciels savoir quelles contraintes sont définies sur le système pour pouvoir prévoir l’application d’une évolution. On considère qu’il peut être requis d’un système qu’il soit tout le temps disponible, qu’il peut y avoir des périodes d’arrêt du système sur des périodes courtes, ou simplement que le critère de disponibilité n’a pas d’importance. – Dynamisme : ce facteur détermine si les changements à opérer sur le système sont guidés de l’extérieur (système réactif), ou si les changements proviennent d’une observation faites par des contrôleurs propres à l’application (système proactif). Pour ce dernier cas, on parle de système autonome, et le changement est opéré à l’exécution. – Exposition : les auteurs parlent d’ouverture du système pour désigner sa faculté à autoriser son extension. On parle de système ouvert lorsque l’architecture et l’environnement d’exécution sont constitués de mécanismes d’extension. – Sûreté : la sûreté de l’évolution désigne la propriété du système à s’assurer que l’évolution ne met pas le système dans un état erroné. Il peut s’agir de mécanismes à la compilation, ou de contrôles effectués à l’exécution. On parle de sûreté statique lorsque le contrôle de sûreté est effectué hors ligne. À l’inverse, la sûreté dynamique consiste à vérifier l’évolution au cours de l’exécution du système. Nous résumons l’ensemble des facteurs de la dimension "Quoi" dans la Table 2.2. Pour cette dimension, nous nous positionnons dans un cadre où les systèmes doivent être réactifs (le client pouvant potentiellement poser des contraintes fortes de disponibilité d’un service), mais pour lesquels un temps d’arrêt pour effectuer de l’évolution est prévisible. Nous traitons des évolutions réactives, dans le sens où elles sont déclenchées par un changement dans les besoins du client, et ne sont pas le fruit d’une adaptation à l’environnement. De part le contexte technologique des SOA, l’exposition du système est ouverte, donnant de par le couplage lâche et l’aspect modulaire des services la possibilité de l’étendre. Enfin, nous nous positionnons dans un contexte d’évolution dont nous assurons la sûreté à la conception, par le biais d’une analyse. Table 2.2 – Taxonomie d’une évolution : la dimension "Quoi". Quoi Disponibilité Dynamisme Exposition Sûreté Toujours disponible Réactif Ouvert Statique Temps d’arrêt acceptable Proactif Fermé Dynamique Indifférent Le "Quand" de l’évolution : Cette dimension s’intéresse aux caractéristiques temporelles d’une évolution. Plus particulièrement, les auteurs étudient dans cette dimension les propriétés suivantes : – le moment au cours duquel une évolution peut survenir (à la conception, à la compilation, ou à l’exécution) – l’historique des évolutions. Cette caractéristique permet de savoir s’il est possible d’appliquer plusieurs évolutions en concurrence. En effet, avec l’augmentation de la taille des systèmes, la taille des équipes de développement a également augmenté, décentralisant ainsi le développement et de fait les évolutions. On distingue ici trois cas : les évolutions peuvent être prises de manière séquentielle, c’est à dire qu’il n’est pas possible d’appliquer une évolution tant qu’une autre évolution est en cours, de manière parallèle synchrone, où ici, le développement des évolutions peut être effectué 202.3. Évolution des systèmes logiciels indépendamment, mais leur application concrète est réalisée à un point précis dans le temps, ou encore de manière parallèle asynchrone, où le développement et l’application des évolutions sont indépendants. Ce dernier cas est complexe à gérer, dans le sens où l’aboutissement à un système incohérent est possible, sans pouvoir effectuer une analyse lors du point de synchronisation, comme cela est possible dans la deuxième méthode. – la fréquence de l’évolution, à savoir si le système étudié évolue fréquemment de sorte que des périodes de temps d’arrêt du système sont à prévoir, ou non. On distingue ici une évolution continue, où le système est en perpétuel changement, une évolution périodique, où les évolutions sont appliquées de manière régulière, ou encore arbitraire, où les évolutions sont effectuées à un rythme irrégulier et peu soutenu. Nous résumons l’ensemble des facteurs de la dimension "Quand" dans la Table 2.3. Nous traitons dans cette thèse des évolutions subvenant au moment de la conception. De part l’ensemble des problématiques liées à l’historique d’une évolution, nous nous focalisons sur des évolutions entrant dans une logique d’application séquentielle. Enfin, la fréquence n’influençant pas la nécessité du maintien de la qualité de service, nous traitons les évolutions qu’elles soient à fréquence soutenue, ou plus disparates dans le temps. Table 2.3 – Taxonomie d’une évolution : la dimension "Quand". Quand Moment Historique Fréquence Conception Séquentiel Continue Compilation Parallèle synchrone Périodique Exécution Parallèle asynchrone Arbitraire Chargement Le "Comment" de l’évolution : Cette dimension s’intéresse à la manière dont l’évolution est opérée. Pour cela, les auteurs étudient les facteurs suivants : – le degré d’automatisation de la mise en œuvre de l’évolution. Une évolution peut être complètement automatisée, notamment dans le cadre des systèmes auto-adaptatifs, partiellement automatisée, où l’équipe de développement décrit les modifications à apporter dans un langage d’évolution, laissant au moteur d’évolution la tâche d’appliquer ces modifications sur les différents documents formant le système, ou manuelle, entraînant l’équipe de développement à modifier à la main tous les documents, en prenant à bien garde à garder un système cohérent. – le degré de formalité de la mise en œuvre de l’évolution. Ici, il s’agit de caractériser à quel degré de formalisme est exprimée une évolution. Par exemple, une évolution peut être effectuée de manière ad-hoc (i.e., sans aucun support), ou dans un formalisme mathématique tel que la réécriture de graphe, permettant ainsi de pouvoir s’intéresser à des propriétés de propagation de changement ou de re-factoring. – le support du processus d’évolution. Il s’agit de savoir ici si l’évolution s’effectue de manière manuelle, ou bien si un ou plusieurs outils viennent accompagner le développeur de l’évolution pour automatiser certaines tâches. – le type de changement, à savoir s’il s’agit d’un changement structurel ou comportemental. Dans le premier cas, on modifiera les fonctionnalités par un ajout ou une 212.4. Conclusion Table 2.4 – Taxonomie d’une évolution : la dimension "Comment". Comment Degré d’automatisation Formalisme Support du processus Type de changement Automatisé Ad-hoc Aucun Structurel Partiellement automatisé Formalisme mathématique Re-factoring Sémantique Manuel Analyse d’impact suppression de paramètres ou de fonctions. Dans le deuxième, il s’agit de la modifi- cation de la logique fonctionnelle du programme. À noter ici que ces deux critères ne sont pas mutuellement exclusifs : une évolution est le plus souvent à la fois structurelle et comportementale. Nous résumons l’ensemble des facteurs de la dimension "Comment" dans la Table 2.4. Nous traitons dans cette thèse des évolutions partiellement automatisées, dans le sens où elle ne sont pas le fruit d’une auto-adaptation. Nous cherchons à faire évoluer des processus métiers, en nous appuyant sur un langage pour exprimer ces évolutions. Ce langage nous permettra de raisonner dans une logique des graphes. Enfin, nos évolutions, à la fois structurelles et comportementales, seront analysées dans le but de déterminer son impact sur la qualité de service. 2.4 Conclusion Dans ce chapitre, nous avons présenté le contexte de cette thèse, en étudiant successivement les architectures orientées services, la qualité de service et la notion d’évolution. Lors de l’étude de ces domaines, nous avons émis un certain nombres d’hypothèses, que nous récapitulons dans la Table 2.5. Cette thèse s’inscrit dans un contexte de développement d’applications orientées services. Ici, les logiciels développés sont notamment modulaires et autonomes. Afin de pouvoir différencier plusieurs services aux fonctionnalités similaires, la notion de qualité de service peut être utilisée comme indicateur de comparaison. Enfin, ces systèmes répondants à des besoins changeants de la part de l’utilisateur, il est nécessaire de prévoir des évolutions semi-automatisées, subvenant à la conception, dans le but de pouvoir les analyser pour savoir si, après leur application, la qualité de service est maintenue dans le système. 222.4. Conclusion Table 2.5 – Récapitulatif des hypothèses de travail. Architectures Orientées Services Hypothèse 1 Nous étudions l’évolution dans le contexte des services. Les entités étudiées, nommées services, peuvent être distribuées. Nous considérons qu’ils sont modulaires, que leur localisation est transparente vis-à- vis de l’équipe de développement, et que leur couplage est lâche. Qualité de Service Hypothèse 2 Pour toutes les propriétés que nous étudions, il existe au moins une méthode permettant de déterminer la valeur de propriété d’un service. Hypothèse 3 Dans un système, les besoins en terme de qualité de service sont définis à l’aide d’un contrat de qualité de service. Le plus souvent, ils sont représentés sous la forme d’une SLA. Évolution Hypothèse 4 Les évolutions que nous considérons dans cette thèse s’opèrent au niveau de l’implémentation du système. Elles sont définies au niveau de granularité de la réalisation d’un processus métier, c’est-à-dire au niveau des activités qui le constitue. Hypothèse 5 Lorsqu’une évolution est appliquée, nous considérons qu’un temps d’arrêt du système est acceptable. Cette évolution est réalisée en ré- action à un changement dans les besoins de l’utilisateur. L’analyse de la validité de l’évolution est effectuée de manière statique. Hypothèse 6 Le processus d’évolution est effectué au moment de la conception. Nous considérons dans notre cas que les évolutions sont appliquées de manière séquentielle, i.e., qu’à tout moment du cycle de vie, il y a au plus une évolution en train d’être appliquée. La fréquence de ces évolutions, elle, n’importe peu. Hypothèse 7 Une évolution, si elle est appliquée de manière automatique sur le système, est déclenchée par un acteur humain. Il peut s’agir de changements structurels, ou sémantiques. Pour supporter ce processus d’évolution, nous cherchons à effectuer une analyse d’impact de son effet sur le reste du système. 23Chapitre 3 État de l’art Sommaire 3.1 Processus de développement . . . . . . . . . . . . . . . . . . . . . . 25 3.1.1 Les processus de développement généralistes . . . . . . . . . . . . . . 26 3.1.2 Les processus de développement spécialisés SOA . . . . . . . . . . . 27 3.1.3 Prise en compte de la Qualité de Service . . . . . . . . . . . . . . . . 28 3.1.4 Prise en compte de l’évolution . . . . . . . . . . . . . . . . . . . . . 28 3.1.5 Comparatif et limitations . . . . . . . . . . . . . . . . . . . . . . . . 29 3.2 Analyse d’impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.2.1 Fondements de la causalité . . . . . . . . . . . . . . . . . . . . . . . 29 3.2.2 Application de la causalité : les analyses d’impact . . . . . . . . . . 30 3.2.3 Analyse d’impact pour la qualité de service . . . . . . . . . . . . . . 32 3.2.4 Comparatif et limitations . . . . . . . . . . . . . . . . . . . . . . . . 32 3.3 Conclusion de l’état de l’art . . . . . . . . . . . . . . . . . . . . . . 33 N ous avons vu dans le chapitre 2 que les applications à base de services avaient pour particularité de devoir être réactives face aux changements des besoins des utilisateurs, tout en ayant une préoccupation particulière pour la QoS. Dans ce contexte, l’équipe en charge du système doit mettre en place une stratégie pour faire évoluer le logiciel, tout en prenant en compte le maintien de la qualité de service. Dans ce chapitre, nous dressons dans un premier temps l’état de l’art des processus de développement logiciel. Puis, nous étudions la notion d’analyse d’impact comme possibilité d’établir l’effet d’une évolution sur le reste du système. 3.1 Processus de développement Nous présentons dans cette section l’état de l’art concernant les processus de développement. Pour étudier les différents travaux, nous nous focalisons sur les critères suivants : – Agilité : le critère d’agilité est le minimum requis pour pouvoir effectuer des évolutions de manière continue. On considèrera ainsi que dans un processus de développement agile, le côté itératif et incrémental peut être vu comme une évolution. – Collaboration : nous étudions ici des systèmes complexes où plusieurs expertises au niveau de l’élaboration de services, de processus métiers, d’évolution ou de qualité de service sont requises. Il est donc important qu’une place soit accordée à ces rôles dans le processus de développement. – Prise en compte de la QoS : le but d’une équipe de développement est de produire un logiciel fonctionnel. La qualité de service n’est pas forcément considérée comme une préoccupation principale ; il s’agira de voir si elle est intégrée au sein du processus de développement.3.1. Processus de développement Dans la suite, nous considérons dans un premier temps les processus de développement généralistes. Puis, nous nous centrons sur les processus orientés SOA, et étudions ceux qui prennent en compte la qualité de service et l’évolution. Enfin, nous effectuons un comparatif des différentes approches. 3.1.1 Les processus de développement généralistes Les processus de développement ont pour rôle de guider l’équipe de développement dans la réalisation de logiciels. Il existe de nombreux processus de développement, chacun ayant ses avantages et ses inconvénients. Pour la plupart, ils sont construits autour des mêmes grandes étapes, comme référencées dans l’ISO 12207 [IEEE 2008] : – Analyse des besoins : au cours de cette étape, les besoins du client sont identifiés (par exemple à l’aide d’un diagramme de cas d’utilisation UML) et consignés dans un cahier des charges. – Conception : l’architecte logiciel conçoit une solution en se basant sur les besoins collectés précédemment. Ici, il s’agit d’une solution à haut niveau d’abstraction. L’architecte décrit ce qui doit être réalisé, sans donner les détails de comment le réaliser. – Implémentation : l’équipe de développement se base sur la conception de l’architecte pour écrire le code du logiciel. – Vérification et validation : une fois la solution logicielle développée, l’étape suivante consiste à vérifier que l’on a bien implémenté le logiciel, i.e., que le logiciel ne présente pas de bogue. Cette phase se nomme "vérification" du logiciel. On s’assure également que l’on a implémenté le bon logiciel, i.e., que le comportement du logiciel correspond aux besoins du client. Dans ce cas, on parle de validation du logiciel. – Déploiement : enfin, l’étape de déploiement consiste à installer le logiciel sur la machine de production, pour pouvoir être utilisé. Parmi les processus de développement les plus utilisés, nous retenons le modèle en cascade [Royce 1970], comme étant le déroulement séquentiel des étapes listées ci-dessus. Un autre processus est le modèle en V [IABG 1997], développé dans les années 80 par la République Fédérale d’Allemagne, qui est une extension du modèle en V. Ici, au lieu de considérer les étapes de manière séquentielle, une association est faite entre les étapes de réalisation, et les étapes de test, afin de pouvoir les mener en parallèle, et de renforcer leur cohérence. Ces approches sont dites en cascade : le client établit en amont du projet un certain nombre de besoins fonctionnels et non fonctionnels. Le porteur du projet déclenche alors le début du cycle de développement choisi. S’en suit le déroulement des différentes étapes, pour aboutir à la production d’un logiciel correspondant aux besoins établis. Toutefois, ce genre d’approche a été vivement critiqué, principalement pour un manque de réactivité vis-à-vis des besoins du client. Pour pallier ce genre de problème, de nouveaux cycles de développement ont été proposés. C’est le début des méthodes dites agiles [Beck 2001] : ici, l’accent est porté sur la livraison fréquente et le retour d’expérience, par le biais de méthodes dites itératives, l’équipe en charge de réaliser le logiciel exécute plusieurs fois le processus de développement, et incrémentales, où chaque itération augmente les fonctionnalités du logiciel réalisé [Larman 2003]. Le client est désormais au centre du processus, là où il n’était consulté auparavant qu’en début et en fin de projet, permettant ainsi d’éviter de réaliser un logiciel trop éloigné des besoins. Parmi les méthodes agiles, nous retiendrons l’Extreme Programming (XP) [Beck 2004], le Rationale Unified Process (RUP) [Kruchten 2004] ainsi que la méthode Scrum [Schwaber 2004], qui font partie des méthodes de développement les plus utilisées à ce jour. 263.1. Processus de développement Pour positionner les processus de développement par rapport à la notion d’évolution, les cycles de développement agiles sont les plus à même à en supporter les différents mécanismes liés. En effet, le caractère itératif et incrémental des méthodes agiles permet une réalisation naturelle de l’évolution, là où les cycles de développement classiques, de par leur long dé- roulement, nécessite soit d’interrompre le déroulement classique du cycle pour prendre en compte l’évolution, soit d’attendre la fin d’une itération pour prendre en compte l’évolution. Dans le premier cas, cela peut engendrer des problèmes de consistance, par exemple en abandonnant momentanément le développement en cours pour s’occuper de l’évolution. Dans le second cas, cette approche ne permet pas d’être réactif face aux besoins de l’évolution. Les approches agiles sont donc les plus à même de supporter l’évolution. 3.1.2 Les processus de développement spécialisés SOA Selon les principes énoncés dans le chapitre 2, la construction de logiciels basés sur des architectures orientées services diffère des systèmes traditionnels, notamment dans le sens où la notion de réutilisabilité est prépondérante. Pour cela, de nombreux travaux ont tenté d’adapter des processus de développement généralistes aux architectures orientées services. Ceux-ci sont comparés dans les études de Ramollari et al., et de Shahrbanoo et al. [Ramollari 2007, Shahrbanoo 2012]. Nous retiendrons ici les travaux de Papazoglou et al., qui ont développé un certain nombre de recommandations pour l’élaboration d’un processus de développement pour les SOA [Papazoglou 2006]. Leur processus de développement agile est constitué de six étapes : – Planification : l’étape initiale consiste à étudier la faisabilité de la mise en œuvre d’une solution à base de services. Il s’agit dans un premier temps d’établir les besoins de l’utilisateur. Également, c’est dans cette phase que l’équipe de développement prendra garde à s’assurer que la solution à développer s’intègrera dans un environnement existant. – Analyse et conception : Il s’agit de la première étape du cycle de développement. Ici, on établit l’existant en énumérant les différents services, et en revenant potentiellement sur les besoins de l’utilisateur pour identifier quels sont les services en place, et quels sont les services à développer ou à faire évoluer. – Construction et test : au cours de cette étape, on reprend les besoins identifiés dans l’étape précédentes pour concevoir, réaliser et tester de nouveaux services et processus métiers. Il s’agira de déterminer parmi l’ensemble des besoins quels services devront être réalisés, réutilisés, ou composés. – Approvisionnement : cette étape cherche à établir l’équilibre entre les services fournis et leur offre en termes de propriétés. Ici, l’équipe s’intéresse à l’établissement de contrats (de type SLA), en déterminant quel niveau de qualité peut être fourni, comment il peut être monnayé à une potentielle entreprise, et quel usage doit être fait du service pour garantir le niveau de qualité spécifié. – Déploiement : une fois que les nouveaux services ont été validés, ils peuvent être déployés et être promus au niveau des autres organisations potentiellement intéressées. – Exécution et Contrôle : enfin, les nouveaux services peuvent être exécutés. S’il est nécessaire, des contrôles (notamment de la qualité de service) peuvent être enclenchés, afin de pouvoir collecter des données sur la qualité du système, et amorcer ainsi la réflexion d’une autre boucle de développement. La méthode de développement nommée "Service-Oriented modeling and Architecture" (SOMA) est une autre approche développée par IBM [Arsanjani 2008]. Cette approche a 273.1. Processus de développement la particularité de mettre en évidence les rôles nécessaires pour la réalisation d’un logiciel à base de services. La méthode est constituée de sept activités assez similaire à l’approche de Papazoglou et al.. La différence principale entre ces approches et les approches généralistes résident dans la notion de réutilisation, mais également la notion de niveau de service fourni. Ainsi, certaines actions, comme par exemple l’implémentation, diffèrent des approches généralistes de par la sélection de services existants. 3.1.3 Prise en compte de la Qualité de Service Si les cycles de développement se focalisent dans un premier temps sur la livraison d’un logiciel fonctionnel correspondant au cahier des charges établi, tous ne considèrent pas la qualité de service dans leurs préoccupations. Toutefois, certains travaux ont consisté à dériver des processus de développement existants pour y inclure la qualité de service. Par exemple, Koziolek et al. [Koziolek 2006] ont dérivé le cycle de développement RUP pour intégrer la QoS dans les différentes étapes du développement de logiciels à base de composants. Ce processus a notamment pour but d’aider l’architecte à choisir parmi des composants sur l’étagère, en utilisant la QoS comme critère de comparaison. Comme RUP, leur nouveau processus est itératif et incrémental, permettant aux développeurs de proposer de nouveaux composants à chaque itération. Toutefois, chaque itération implique une revérification complète de l’architecture. Cette approche identifie quatre rôles de référence : l’expert du domaine, le responsable du déploiement du système, l’architecte du système, et le développeur de composants. Gatti et al. proposent également de prendre compte des propriétés de qualité comme le temps d’exécution pire-cas à travers l’ensemble du cycle de développement [Gatti 2011]. Dans leur approche, chaque étape est guidée par des éléments émanant de l’étape précé- dente, dans le but d’assurer la traçabilité d’une propriété de l’étape des besoins jusqu’à l’exécution. 3.1.4 Prise en compte de l’évolution Tous les processus de développement ne prennent pas en compte explicitement l’évolution comme une de leurs étapes. Il est évidemment possible de considérer dans un processus de développement itératif que l’itération est une évolution. Toutefois, il est également possible de considérer l’évolution comme une étape à part entière, en allouant également un temps pour analyser les effets de l’évolution sur le reste du système [Lewis 2010]. Il existe différents processus prenant en compte l’évolution comme une étape à part entière : Kijas et al. ont développé un processus d’évolution pour les architectures orientées services [Kijas 2013]. Pour cela, ils ont réalisé un modèle d’évolution de manière empirique, en s’appuyant sur les différents scénarios que l’on peut rencontrer dans la modification d’un système à base de services. Par exemple, la création d’un service entraîne d’autres opérations, telles que la publication de l’interface de ce service. De là, ils analysent l’effet de l’évolution sur le reste du code, en se reposant sur ces scénarios. Kim et al. proposent une approche fondée sur le tissage d’aspect pour établir et faire évoluer un système à base de services [Kim 2010]. Pour cela, ils se basent sur des réseaux de Pétri et sur la séparation des préoccupations par aspects pour établir une évolution, sur laquelle leur outil est en mesure d’effectuer des analyses de performance. 283.2. Analyse d’impact Table 3.1 – Comparatif des différents processus de développement. Rôles Support de la QoS Support de l’évolution Agilité [Koziolek 2006] Oui Oui Non Oui [Gatti 2011] Non spécifiés Oui Non Non [Papazoglou 2006] Non spécifiés Oui Non Oui [Kijas 2013] Non spécifiés Non Oui Non indiqué [Kim 2010] Non spécifiés Oui Oui Oui 3.1.5 Comparatif et limitations Le Table 3.1 regroupe les différents processus de développement que nous avons pré- sentés. Nous effectuons la comparaison selon les points suivants : – Rôles : nous pouvons voir ici qu’une minorité de processus intègre la notion de rôles ; mais si un rôle est défini, aucun des travaux ne prévoit dans le processus de développement des points de rencontre explicite où les rôles sont amenés à collaborer. – Support de la QoS : de par l’importance donnée à la qualité de service dans les fondements des architectures orientées services, presque tous les processus s’intéressent à la qualité de service. Toutefois, si la majorité des processus supporte la qualité de service, il est important de s’intéresser à la manière donc la QoS est étudiée. En effet, pour chaque évolution, une complète réévaluation du niveau global de QoS du système est effectuée. Si cette pratique permet d’obtenir le résultat escompté, bon nombre des analyses effectuées sont ré-exécutées de manière arbitraire, sans porter attention au fait que l’élément analysé n’a peut être pas été affecté par l’évolution. – Support de l’évolution et agilité : seuls les travaux les plus récents ont choisi de considérer l’évolution au sein du cycle de développement. Des cinq processus de développement que nous étudions, seul le processus développé par Gatti et al. n’est pas un processus agile, et avec un manque d’information sur le processus de Kijas et al.. En mettant en perspective ce critère avec le support de l’évolution, nous pouvons voir que tous à l’exception du processus de Gatti et al. ont une possibilité plus ou moins évidente de réaliser une évolution du logiciel, que ce soit en considérant une itération du processus, ou en l’exprimant de manière explicite. Nous venons d’effectuer une comparaison des différents processus de développement. De tous ces processus, aucun ne satisfait l’ensemble des critères nécessaires au maintien de la QoS lors de l’évolution. De manière plus spécifique, chacun de ces processus considère une re-vérification complète de la QoS du système pour chaque évolution, sans essayer de cibler les éléments affectés par l’évolution. Pour pallier ce genre de problème, il s’agit de considérer les techniques d’analyse d’impact. 3.2 Analyse d’impact 3.2.1 Fondements de la causalité La notion de causalité est un principe trans-disciplinaire, touchant à la fois la physique, les mathématiques, la philosophie. Nous retrouvons notamment les origines des concepts de cause et de conséquence dès les dialogues de Platon, dans les récits d’Artistote, ou encore dans le Discours de la méthode de Descartes. Les travaux de Judea Pearl ont posé les fondements de la causalité, en les formalisant d’un point de vue logique [Pearl 2000]. En accord avec ses travaux, nous parlons dans ce 293.2. Analyse d’impact document de relation de dépendance causale (ou relation causale en abrégé) entre deux éléments A et B, noté A −→ B, signifiant le fait que A est une cause de B, ou que B est la conséquence de A. De ces fondements, la notion d’analyse causale est apparue, introduisant des valeurs probabilistes pour représenter la potentialité d’une relation causale. Ces travaux reposent notamment sur l’établissement du modèle causal à l’aide d’un réseau Bayésien et de chaines de Markov [Spohn 2001]. Le besoin d’effectuer une analyse d’impact pour comprendre une évolution a déjà été évoqué dans les travaux de Papazoglou [Papazoglou 2011], où l’auteur explique que ce genre d’analyse serait nécessaire pour prédire et réduire le sous-ensemble des éléments impactés, et comprendre concrètement l’effet de l’évolution. 3.2.2 Application de la causalité : les analyses d’impact Les théories établies dans la section précédente ont une applicabilité directe dans l’étude de systèmes logiciels. En 2002, Moe et al. ont motivé le besoin d’étudier la causalité au sein de systèmes distribués, dans le but de résoudre certains problèmes liés à la compréhension de l’effet du système, d’un sous-système, ou même d’un message [Moe 2002]. Parmi ces problèmes, on retiendra notamment la découverte de goulots d’étranglement. Dans la suite de ce paragraphe, nous nous focalisons sur la causalité lié à un changement opéré dans un système, en présentant différentes techniques permettant de déterminer son impact. Nous les classons en deux catégories, à savoir les méthodes d’analyse de causes racines, et les méthodes d’analyse de l’impact du changement. Analyse des causes racines La détermination de la ou les causes à l’origine d’un phénomène est une discipline connue sous le nom d’analyse des causes racines (root cause analysis en anglais). Elle a été formalisée dans les années 80 [Busch 1986] dans le contexte du département de l’énergie. L’objectif des analyses de causes racine est, partant d’une situation établie (le plus souvent un problème rencontré), d’obtenir les causes de cette situation. Il s’agit d’une approche réactive, dans le sens où on cherche à remonter à l’origine d’un problème. On opposera ainsi les approches réactives aux approches proactives, où la cause est connue, et où on cherche à en prédire les conséquences. Les analyses de causes racines fonctionnent en quatre temps [Rooney 2004] : – Collecte de données : afin de pouvoir établir les causes du changement, il est nécessaire de comprendre concrètement ce qu’il se passe dans le système. Pour cela, il s’agit d’établir son état courant, c’est à dire l’état dans lequel se trouve chacun des éléments qui le constituent, mais également l’ensemble des événements l’ayant mené à cet état. – Tracé des facteurs de causalité : en partant des informations collectées, il s’agit de dresser une cartographie des différentes influences entre les éléments. Il s’agit le plus souvent d’un diagramme de séquence, où les différents événements jouent le rôle de garde et où la séquence représente la chaîne de causalité. Ainsi, une fois que le diagramme est tracé, un ensemble de branches apparaît, menant au nœud final correspondant à l’état courant. – Identification des causes racines : une fois que tous les facteurs causaux ont été intégrés au diagramme, un diagramme de décision, appelé carte des causes racine, est établi pour identifier la ou les causes ayant mené à l’état courant. Cette carte permet 303.2. Analyse d’impact d’établir comment, à partir d’une cause éloignée, par un effet de cascade, le système a pu aboutir à son état courant. – Recommandations : enfin, une fois que les causes racines sont établies, l’analyse préconise une ou plusieurs actions à effectuer pour éviter à l’avenir de se retrouver dans cet état. Une manière de représenter les résultats de l’analyse s’effectue à l’aide des diagrammes de Pareto. Dans ces diagrammes, l’ensemble des causes dont le problème émane est représenté en colonnes, classées par ordre décroissant de probabilité d’implication sur la conséquence. Les diagrammes de Pareto font partie, avec le diagramme en arêtes de poisson, des sept outils à utiliser pour contrôler la qualité [Tague 2004]. Si cette catégorie de méthode permet d’établir un diagnostic face à un problème, tel que la dégradation de propriété de qualité de service par exemple [Ben Halima 2008], elle ne s’inscrit cependant pas complètement dans le cadre de cette thèse. En effet, nous avons pour objectif de maintenir la qualité de service tout au long du cycle de vie du logiciel. Or, ce genre de méthode se positionne davantage dans la situation où la qualité de service n’est plus maintenue. Analyse de l’impact du changement L’analyse de l’impact du changement (change impact analysis en anglais) s’intéresse à l’identification des conséquences d’un changement effectué sur un système. Ces méthodes ont été définis à l’origine par Bohner et Arnold [Bohner 1996] comme étant "The determination of potential effects to a subject system resulting from a proposed software change". Cette description générale peut s’appliquer à l’ingénierie logicielle en particulier. On retrouve dans la littérature de nombreuses applications de ce principe, agissant sur différentes parties du cycle de vie : l’analyse de l’effet sur les phases de collecte des besoins, sur la conception de la solution, sur son implémentation, et sur la vérification. Les techniques d’analyse de l’impact du changement n’ont pas pour but unique de se centrer sur l’effet d’une évolution. Dans leurs travaux, Xiao et al. utilisent ces techniques pour calculer le coût d’une évolution [Xiao 2007]. En effet, modifier un processus métier s’accompagne souvent d’une modification des interfaces, voir même de la logique d’implé- mentation de certains services. Les auteurs effectuent une analyse d’impact sur le processus métier dans le but de quantifier le coût de l’évolution sur le reste du système. Nous pensons que cette technique serait une bonne approche si elle pouvait être étendue pour prendre en compte non pas le coût d’une évolution mais son effet sur la qualité de service. Cette approche contemplative de l’étude de l’évolution est appliquée de manière active dans l’outil nommé Morpheus [Ravichandar 2008]. Ici, les auteurs proposent de s’appuyer sur les relations de dépendance établies pour automatiser l’évolution, en propageant les changements sur les autres éléments constituant le système. Analyse des effets d’une évolution Plusieurs travaux se sont intéressés à l’analyse d’impact de l’évolution d’un logiciel. Par exemple, Elbaum et al. ont présenté une étude empirique sur l’effet de l’évolution du logiciel sur les tests de couverture de code [Elbaum 2001]. Ils ont montré que même une modification minime dans le logiciel peut modifier les instructions au niveau du code, impliquant de le re-tester. Fondamentalement, nous visons à réaliser le même genre d’approche au niveau des orchestrations de service, et en se préoccupant principalement de la qualité de service. 313.2. Analyse d’impact Analyse de l’évolution dans les SOA L’analyse d’impact, ou la détermination des éléments affectés par un changement, a été étudiée dans le cadre des processus métiers. Soffer a défini dans ses travaux la notion de portée du changement, dont l’identification permet de "faciliter l’ajustement du système face aux changements des processus métiers" [Soffer 2005]. Pour cela, l’auteur dresse une taxonomie des différentes modifications pouvant être effectuées sur un processus métier : modification d’un état, modification d’une transition d’état (que ce soit au niveau de la structure du flot de contrôle, ou d’une potentielle condition de garde), modification des variables, ou modification totale, en remplaçant le processus métier par un autre. Partant de cette taxonomie, l’auteur définit quel est le scope de changement pour chacune des catégories, à savoir le changement contenu (où il n’y a pas de changement indirect), le changement local, ou encore le changement global. Le canevas proposé par Ravichandar et al. vise à contrôler l’évolution de processus mé- tiers [Ravichandar 2008]. Ils établissent les relations entre les différents éléments du système, et opèrent à la fois sur le code source et sur les descriptions de haut niveau d’abstraction pour conserver la cohérence du système. Enfin, l’élaboration d’une évolution entraîne grâce à leur outil une propagation du changement dans l’ensemble de l’architecture. Ces travaux sont similaires à ceux de Dam et al. [Dam 2010] . 3.2.3 Analyse d’impact pour la qualité de service Enfin, un certain nombre de travaux ont porté sur l’étude de l’effet d’un changement sur la qualité de service. Dans le langage CQML+ [Rottger 2003], il existe la possibilité de représenter les relations de causalité pouvant exister entre les différentes propriétés. Toutefois, aucun outil, ou aucune application, n’est proposée pour pouvoir déterminer pour un système donné la chaine de conséquences entre une évolution et son effet sur la qualité de service. Becker et al. proposent une approche nommée Q-Impress visant à prédire les conséquences des évolutions, au moment de la conception du logiciel, sur les différents attributs de qualité. Pour cela, les auteurs se basent sur des modèles de prédiction tels que les chaînes de Markov ou les réseaux de file d’attente [Becker 2008]. Cicchetti et al. ont développé une approche pour analyser les effets de l’évolution sur la qualité de service d’applications à base de composants [Cicchetti 2011]. Leur approche considère une évolution effectuée de manière ad-hoc : l’équipe de développement réalise une nouvelle version du système, et l’incrément est calculé en effectuant la différence des modèles architecturaux. En fonction de cette différence, leur outil calcule l’impact de cette différence selon un ensemble de règles. Toutefois, l’inconvénient de leur approche réside dans la nécessité de mesurer a priori l’ensemble des valeurs pour pouvoir ensuite déterminer quel en a été l’impact. Il en résulte une re-vérification complète du système. 3.2.4 Comparatif et limitations La Table 3.2 regroupe les différents types d’analyse d’impact que nous avons présentés. Nous effectuons la comparaison selon les points suivants : – Adaptabilité au contexte : notre contexte circonscrit les domaines des processus métiers, de la QoS et de l’évolution. Sur l’ensemble des analyses que nous avons étudié, aucune de ces méthodes ne s’inscrit complètement dans notre contexte, prenant en compte au mieux deux des trois critères, comme le font Becker et al. ou Cicchetti et al.. 323.3. Conclusion de l’état de l’art – Identification du sous-ensemble impacté : de par notre analyse précédente, nous pouvons opposer les méthodes d’analyse des causes racines aux méthodes d’analyse de l’impact du changement. En considérant que pour garantir le maintien de la QoS lors de l’évolution, nous avons besoin de déterminer en premier lieu quel est l’impact de l’évolution, l’analyse des causes racines n’est pas adapté à notre problématique. – Quantification de l’impact : une fois que l’impact a été déterminé, c’est-à-dire que l’analyse a identifié quels sont les éléments du système affecté par une évolution, il est nécessaire de savoir si cet impact est bénéfique ou néfaste du point de vue de la QoS. Toutes les méthodes d’analyse n’effectuent pas cette vérification cependant, essentielle pour pouvoir dire si la QoS est maintenue. C’est le cas notamment de Ravichandar et al., Elbaum et al. ou Rottger et al.. – Coût de l’analyse : enfin, le dernier critère de comparaison consiste à étudier le coût pour l’utilisateur de l’analyse. Nous cherchons en effet ici à avoir une analyse la plus automatisée possible, et pour laquelle l’utilisateur sera le moins impliqué. Si la plupart des méthodes ont un coût important, en terme d’effort de modélisation ou de temps d’exécution de l’analyse en elle-même, Ben Halima et al. ainsi que Ravichandar et al. ont un faible coût. En résumé, aucune approche ne propose une analyse d’impact qui soit à la fois adapté à notre contexte, faible en coût, et fournissant l’ensemble des informations nécessaires à garantir le maintien de la QoS lors de l’évolution d’un logiciel. 3.3 Conclusion de l’état de l’art Nous venons de dresser l’état de l’art en matière de processus de développement et d’analyses d’impact pour l’évolution. Beaucoup de travaux gravitent autour de ces domaines depuis de nombreuses années. Il existe de nombreux processus de développement spécialisés dans la détermination de la qualité de service, dans l’élaboration de systèmes à base de services, ou incluant l’évolution comme étape du processus. Nous avons également étudié les travaux portants sur la détermination des effets de l’évolution en termes d’impact. Là encore, de nombreux travaux existent, s’intéressant à la cause d’un changement ou à son effet. Ces techniques ont été appliquées à différents domaines et dans différents contextes. Dans cette thèse, nous souhaitons maintenir la qualité de service d’un logiciel au cours de ses différentes évolutions, tout en minimisant la phase de re-vérification. Dans cette optique, les défis sont : – faire collaborer les acteurs de l’équipe de développement, en identifiant les connaissances requises pour le maintien de la QoS lors de l’évolution, et en caractérisant les moments au cours desquels les acteurs devront collaborer. – déterminer les interactions au sein d’un logiciel, afin de pouvoir établir le lien existant entre la modification d’un élément du système et la modification d’une propriété de qualité de service. – minimiser la vérification de la QoS, en déterminant les éléments du système impactés par l’évolution de manière à ne vérifier la QoS que sur ces derniers. – identifier la cause de la violation d’un contrat de QoS, en appliquant les techniques d’analyse des causes racines sur le contrat déterminé comme violé. Dans la suite de ce document, nous présentons nos différentes contributions permettant d’assurer le maintien de la qualité de service lors de l’application à base de processus métiers. 333.3. Conclusion de l’état de l’art Nous présentons dans le chapitre 5 un processus de développement, nommé Blink, mettant en évidence les différentes collaborations entre acteurs. Il s’agit dans un premier temps d’identifier ces acteurs, et de déterminer à quel moment du processus de développement une coopération entre acteurs est nécessaire. Puis, nous nous focalisons dans le chapitre 6 sur le rôle de l’architecte du système. Nous présentons dans un premier temps comment modéliser un système selon les principes des architectures orientées services. Nous cherchons pour cela à définir ce qu’est un système, et quelles sont les informations que l’équipe de développement doit fournir pour établir son bon fonctionnement. Puis, nous définissons le concept de causalité, à savoir l’influence que peut avoir un élément d’un système sur un autre élément. À travers la notion de modèle causal, nous identifions l’ensemble des interactions dans un système, dans le but de pouvoir déterminer l’effet d’une évolution sur les éléments du système. Dans le chapitre 7, nous considérons le rôle de l’expert en qualité de service. Après avoir fourni une définition de la qualité de service, nous présentons un langage de modélisation d’une propriété de QoS. À partir de la description d’une propriété, nous cherchons alors à enrichir le modèle causal établi dans le chapitre 6 pour déterminer les interactions entre les éléments du système et ses propriétés de QoS, et cibler les propriétés de QoS à re-vérifier lors d’une évolution. Enfin, dans le chapitre 8, nous nous intéressons au rôle de l’architecte de l’évolution. Après avoir donné une définition de ce qu’est une évolution, nous présentons un langage permettant à l’architecte de décrire des évolutions. Puis, nous présentons un outil d’analyse permettant de déterminer si oui ou non la qualité de service est maintenue une fois l’évolution appliquée. Le résultat de cette analyse est une chaine de conséquence, rendant explicite la cause possible du non-maintien de la qualité de service. L’ensemble des contributions de cette thèse est regroupé au sein de Smile, un canevas de développement pour le maintien de la qualité de service. Notre canevas regroupe la réalisation des contributions, en s’inscrivant de pair avec Blink, notre processus de développement identifiant les interactions entre les expertises de l’équipe de développement, et en implémentant les différentes contributions propres aux expertises de la modélisation du système, de la qualité de service et de l’évolution. Ces contributions sont illustrés à l’aide de PicWeb, notre exemple fil rouge dont la description est réalisée dans le chapitre suivant. 343.3. Conclusion de l’état de l’art Critères Adapté aux processus métiers Adapté à la QoS Adapté à l’évolution Identification du sous-ensemble impacté Quantification de l’impact Coût de l’analyse Analyses des causes racines [Ben Halima 2008] Non Oui Non Non Oui Bas (analyse de trace) Analyse de l’impact du changement [Ravichandar 2008] Non Non Oui Oui Non Bas (analyse de dépendance) Analyse de l’évolution [Elbaum 2001] Non Non Oui Oui Non Élevé (étude empirique) Analyse de Processus Métiers [Soffer 2005] Oui Non Oui Oui Oui Élevé (taxonomie) Analyse de Processus Métiers [Dam 2010] Oui Non Non Oui Oui Moyen (modélisation du système nécessaire) Analyse de la QoS [Rottger 2003] Non Oui Non Non Non élevé (pas d’outil disponible) Analyse de la QoS [Becker 2008] Non Oui Oui Oui Oui Élevé (besoin de modèles de performance supplémentaires) Analyse de la QoS [Cicchetti 2011] Non Oui Oui Oui Oui Moyen (besoin de re-vérifier l’intégralité du système) Table 3.2 – Comparatif des différentes analyses d’impact. 35Chapitre 4 Présentation du cas d’étude Sommaire 4.1 Séduite, un système de diffusion d’informations à base de processus métiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 4.2 PicWeb, un processus métier de recherche d’images . . . . . . . 39 4.2.1 Description de PicWeb . . . . . . . . . . . . . . . . . . . . . . . . . 39 4.2.2 Évolution de PicWeb . . . . . . . . . . . . . . . . . . . . . . . . . . 40 C e chapitre présente PicWeb, un service de recherche d’images provenant de différentes sources qui correspondent à un mot-clé passé en paramètre. PicWeb est représenté par un processus métier dont le développement s’est déroulé de manière agile. Au fil du temps, ce processus métier a évolué pour continuer de correspondre aux besoins des utilisateurs. Il constitue à ce titre un cas d’étude idéal de par sa taille raisonnable et sa compréhension aisée pour illustrer les problèmes rencontrés lors de l’évolution d’application à base de processus métiers. Tout particulièrement, nous montrons ici qu’il est difficile de garantir le maintien de la qualité de service lors de l’évolution. Nous utilisons PicWeb tout au long du document pour illustrer l’apport des différentes contributions de cette thèse. Dans ce chapitre, nous présentons le scénario d’utilisation de PicWeb : nous montrons comment il s’inscrit dans un système plus large nommé Séduite [Delerce-Mauris 2009] et en quoi les différentes évolutions de PicWeb ont été source de problèmes pour maintenir la qualité de service du système. 4.1 Séduite, un système de diffusion d’informations à base de processus métiers Séduite est un système de diffusion d’informations à destination du personnel et des étudiants d’une université. Son origine provient d’un besoin de diffuser sur un campus universitaire des informations diverses, provenant de sources différentes telles que la scolarité, le restaurant universitaire, ou encore les différentes associations étudiantes souhaitant communiquer sur leurs activités. De par l’hétérogénéité du public ciblé, ces informations doivent être affichables sur des périphériques variés tels que des écrans de contrôle positionnés au sein de l’institution, des smartphones, ou encore via un site web. La Figure 4.1 illustre l’interface graphique de Séduite. Le développement de Séduite a débuté en 2005. Originellement utilisé comme prototype de recherche à des fins d’expérimentation (il a servi notamment de validation au projet FAROS 1 ), le système prit de l’ampleur suite à l’implication d’une équipe de huit développeurs. Le système est aujourd’hui constitué de vingt-six services implémentés en Java et de sept processus métiers implémentés dans le Business Process Execution Language 1. Projet RNTL FAROS, 2005.4.1. Séduite, un système de diffusion d’informations à base de processus métiers Figure 4.1 – Utilisation de Séduite au cours de la nuit de l’info. BPEL [OASIS 2007]. Ces services ont pour tâches de collecter les différentes informations provenant des différents services administratifs de l’université, mais également de services web externes. La Figure 4.2 représente l’architecture globale de Séduite. En huit ans, Séduite a été déployé dans plusieurs institutions. Son développement s’est effectué de manière agile : en s’appuyant fortement sur les nombreux retours de la part des utilisateurs, l’implémentation de Séduite a subi de nombreuses évolutions. Nous nous focalisons dans le cadre de cette thèse sur l’évolution de l’un de ces processus métiers, nommé PicWeb. Figure 4.2 – Architecture de Séduite. 384.2. PicWeb, un processus métier de recherche d’images Activité Activité du processus métier Activité Activité modifiée au cours de l'évolution Légende: (a) PicWeb V0 (b) PicWeb V1 Evolution a1 Keyword:= receive() Pics[] := Picasa:getPics(Keyword) a2 a3 PicsF[] = shuffle(Pics[]) a4 reply(PicsF[]) a1 Keyword:= receive() PicsPicasa[] := Picasa:getPics(Keyword) a2 PicsFlickr[] := Flickr:getPics(Keyword) a21 a30 Pics[] := Helper:join(PicsPicasa[], PicsFlickr[]) a3 PicsF[] = shuffle(Pics[]) a4 reply(PicsF[]) a4 a4 Figure 4.3 – Évolutions de PicWeb. 4.2 PicWeb, un processus métier de recherche d’images De l’ensemble des évolutions de Séduite, le cas des évolutions de PicWeb se dégage particulièrement. En effet, à l’issue de l’une de ces évolutions, le déploiement de la nouvelle version entraîna le ralentissement de l’ensemble du système. Nous nous focalisons dans cette section sur cette évolution, qui nous servira d’exemple tout au long du document. 4.2.1 Description de PicWeb PicWeb est un processus métier faisant partie de Séduite. Il a pour but d’afficher sur les écrans de diffusion différentes photos de la vie du campus. Pour cela, le processus métier interroge des services web de stockage de photos tels que Flickr de Yahoo! ou encore Picasa de Google, en récupérant les photos correspondant à un mot-clé donné. Le processus métier récupère ces ensembles de photos et effectue un mélange afin de rendre l’affichage des photos aléatoire. Par exemple, sur le campus de Lille, PicWeb est utilisé pour diffuser les photos des différents événements de la vie étudiante. La Figure 4.3(a) est une représentation de la version initiale de PicWeb selon le formalisme des diagrammes d’activités d’UML, permettant la description du processus métier. Au départ, le processus métier récupère les photos correspondant à un mot-clé donné (activité a1 ). Le processus reçoit le mot-clé, effectue une invocation au service Picasa (activité a2 ) pour récupérer les correspondances, les mélange pour obtenir un ordre aléatoire (activité a3 ), et les retourne en tant que résultat (activité a4 ). 394.2. PicWeb, un processus métier de recherche d’images Dans le cadre du développement de PicWeb, l’équipe de développement s’est intéressé particulièrement à étudier le temps de réponse du service. Concrètement, il s’agissait de caractériser un appel à un service ou à un processus métier, en mesurant le temps passé entre la réception du message d’entrée, et l’envoi du résultat en sortie. Ce temps comprend le temps passé pour l’envoi des messages d’entrée et de sortie (appelé temps de transmission), et le temps passé pour calculer la réponse (appelé temps de calcul). Pour s’assurer que le temps de réponse de PicWeb se situait dans un intervalle de temps acceptable, des mesures ont été effectuées sur l’ensemble du processus. Puis, lors de chaque évolution, l’équipe de développement considérait uniquement les activités modifiées par l’évolution pour s’assurer du maintien de la qualité de service pour le temps de réponse. 4.2.2 Évolution de PicWeb Au cours de son cycle de vie, PicWeb évolua à plusieurs reprises pour répondre aux changements des besoins des utilisateurs. Nous nous focaliserons dans ce document sur l’évolution décrite dans la Figure 4.3, car elle montre comment le simple ajout d’un appel de service peut avoir un impact sur la qualité de service de l’ensemble du processus métier, voire même du système tout entier. PicWeb évolue pour prendre en considération un nouveau fournisseur d’images (Flickr), comme montré dans la figure Figure 4.3 (b). Ce fournisseur est désormais appelé en parallèle de Picasa, avant que le résultat soit concaténé dans la réponse. Lors de cette évolution, si les temps de réponse des activités a20, a21 et a30 de la Figure 4.3(b) présentaient individuellement des valeurs d’un ordre de grandeur attendu, le déploiement de la nouvelle version de PicWeb révéla une toute autre réalité. En effet, les temps de réponse de PicWeb, mais également de Séduite dans son ensemble, augmentèrent de façon significative. Cette augmentation provoqua le ralentissement du système, obligeant l’équipe de développement à déployer dans l’urgence une version précédente du système. Il est intéressant de noter ici que la cause du problème ne vient pas directement de l’évolution mais d’un autre service. Ici, l’appel à Flickr ou au service de concaténation n’était pas la cause du ralentissement du système. Toutefois, l’augmentation de la taille des données traitées par l’activité de formatage des images ralentit considérablement son exécution, causant le ralentissement de l’ensemble du système. En effet, l’implémentation de l’opération shuffle consiste, pour un ensemble de n éléments donnés en entrée, à effectuer n 2 permutations afin de mélanger l’ensemble. L’évolution appliquée à PicWeb n’a pas modifié l’implémentation de shuffle ; toutefois, le contenu de la variable Pics, donnée en entrée de shuffle, est passé de n éléments à 2n. Au niveau de shuffle, l’évolution a entrainé les n 2 permutations à devenir 4n 2 permutations, causant ainsi un ralentissement de l’exécution de l’opération, de PicWeb et du système dans son ensemble. De ce fait, il n’est pas raisonnable de limiter l’analyse de l’évolution aux seuls éléments modifiés dans l’évolution, car cette modification peut avoir des effets indirects sur le reste du système. Il est donc nécessaire de pouvoir déterminer la relation entre l’évolution et son effet sur le reste du système, afin de pouvoir qualifier l’effet concret de l’évolution sur l’ensemble du système. Ce chapitre vient de présenter le cas d’étude de ce document. Dans le chapitre suivant, nous présentons les différents problèmes rencontrés au cours de l’évolution de PicWeb. Nous en extrayons les différents défis liés à l’évolution, avant de donner un aperçu des contributions de la thèse pour apporter une solution à cette problématique. 40Deuxième partie ContributionsChapitre 5 Un processus de développement pour le maintien de la qualité de service Sommaire 5.1 Motivations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 5.2 Définition des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . 44 5.3 Description du processus de développement . . . . . . . . . . . . 44 5.4 Coopération entre acteurs . . . . . . . . . . . . . . . . . . . . . . . 45 5.5 Conclusion du chapitre . . . . . . . . . . . . . . . . . . . . . . . . . 46 C e chapitre présente notre approche pour guider l’équipe de développement dans la réalisation d’un système suivant les principes des architectures orientées services, avec un point de vue particulier pour la qualité de service. Nous identifions tout d’abord les différents acteurs opérant sur le logiciel, en décrivant leur rôle, et en quoi leurs expertises propres interviennent dans le maintien de la QoS lors de l’évolution d’un logiciel. Nous présentons ensuite le cycle de développement en lui-même. Enfin, nous mettons l’accent sur le besoin d’interactions entre les différents acteurs pour parvenir à maintenir la QoS tout au long du cycle de vie. 5.1 Motivations La conception et la réalisation d’un système informatique nécessitent la mobilisation d’un ensemble de compétences propres à un domaine particulier [IEEE 2008, Tarr 1999]. Nous nous intéressons dans le cadre de cette thèse à la réalisation d’une évolution et au maintien de la qualité de service d’un système. Si ces deux compétences peuvent être traitées indépendamment, leur implication dans la réalisation du système entraine des conflits à prendre en compte. Typiquement, l’évolution de PicWeb et les mesures de son temps de réponse peuvent être gérées de manière isolée ; toutefois, en agissant de la sorte, l’application de l’évolution a eu de fait une influence sur la propriété étudiée, ayant ainsi des conséquences inattendues. Pour pouvoir contrôler ces conséquences, il est nécessaire d’identifier les influences entre les différentes expertises, c’est-à-dire les moments dans le cycle de vie d’un logiciel où les choix techniques et architecturaux réalisés par une expertise donnée auront un impact sur une ou plusieurs autres expertises. Il s’agit donc dans un premier temps d’expliciter les compétences existantes, pour ensuite définir les moments dans le cycle de vie où les choix d’une expertise ont un impact sur une autre expertise, et où une concertation est nécessaire. Nous avons décidé dans un premier temps d’identifier les compétences requises et de les5.2. Définition des acteurs affecter à des entités nommées acteurs [Taskforce 2011]. Un acteur est une, ou plusieurs personnes, responsable d’un ensemble de tâches propres à une préoccupation. Ainsi, une tâche commune à deux acteurs implique un échange de connaissances entre les deux acteurs, que ce soit par le biais d’une rencontre, ou encore par un échange de documents et de données ; c’est ce que l’on appelle un point d’interaction. Le défi ici est de définir quelles sont les interactions nécessaires entre les différents membres de l’équipe de développement. Pour cela, nous proposons Blink, un processus de développement permettant d’ordonner les tâches en étapes, et de définir le but de chaque tâche. En identifiant les compétences fournies par les acteurs et les compétences requises pour chaque étape, nous mettons en évidence les interactions nécessaires. Dans la suite de ce chapitre, nous présentons quelles sont les acteurs gravitant autour de la réalisation d’un système. Puis, nous introduisons Blink, et détaillons l’ensemble des étapes nécessaires pour le développement d’un système avec une préoccupation pour la qualité de service. Enfin, nous explicitons les différentes interactions au sein de l’équipe de développement. Pour illustrer nos propos, nous nous appuyons sur le cas de l’évolution de PicWeb. 5.2 Définition des acteurs Au cours du développement et de l’évolution de l’application, différents acteurs interviennent pour apporter leur expertise propre. Ces acteurs ont un rôle spécifique, et sont amenés à prendre des décisions modifiant la structure et le comportement du système réalisé. Dans le contexte de la réalisation de systèmes orientés services se préoccupant de la Qualité de Service, nous listons dans la Table 5.1 les différents acteurs identifiés, et décrivons leur rôle. Ces acteurs ont été identifiés en nous inspirant des travaux de Bejaoui et al. [Bejaoui 2008], de Kajko-Mattson et al. [Kajko-Mattsson 2007], ou encore de Zimmermann et al. [Zimmermann 2006]. Nous comptons cinq rôles. Parmi eux, un est extérieur à l’équipe de développement (l’utilisateur). Le dernier rôle est un acteur non humain : il s’agit de notre canevas de développement, Smile, dont nous présentons les différentes parties tout au long du document, et dont l’implémentation est décrite dans le chapitre 9. Nous cherchons maintenant à déterminer la manière dont les acteurs œuvrent pour réaliser un système. Pour cela, nous répertorions chacune des étapes de Blink, notre processus de développement. Nous présentons chacune des étapes en décrivant leur rôle dans le processus global, et les acteurs amenés à y participer. 5.3 Description du processus de développement Afin d’éviter les problèmes d’influence entre les expertises et de pouvoir définir un système dont la qualité de service est maintenue au fil du temps, nous identifions dans cette section les étapes clés du processus de développement, au cours desquelles une mise en commun des informations et des choix effectués par les acteurs concernés est nécessaire. Pour définir notre processus de développement, Blink, nous nous sommes inspirés de processus de développement existants, tels qu’ils sont présentés dans [Papazoglou 2006] ou encore dans [Kijas 2013]. De ces processus, nous avons conçu Blink, un processus de développement pour le maintien de la qualité de service à l’évolution. La Figure 5.1 représente le diagramme d’activités de ce processus de développement. Chacune des étapes est décrite dans les Tables 5.2, 5.3 et 5.4, accompagnée d’un diagramme selon la spécification SPEM 1 . Ce processus a été conçu pour réaliser un système de façon itérative et incrémentale, où chaque 1. http://www.omg.org/spec/SPEM/2.0/ 445.4. Coopération entre acteurs Table 5.1 – Rôles intervenants dans la réalisation d’un système. Utilisateur du système Représente la communauté utilisant le logiciel. Il est responsable de faire part auprès de l’équipe de développement des nouveaux besoins, nécessitant de faire évoluer le logiciel. Architecte du processus métier Réalise la logique métier du système au moyen de processus mé- tiers et de services. Il a une connaissance approfondie du comportement du système et de la panoplie de services déjà implémentés qu’il peut utiliser. Expert en Qualité de Service Définit les propriétés de qualité de service. Il a une connaissance approfondie des propriétés et des outils pour les observer au sein de n’importe quel système. Il est en mesure de déterminer en cas de dégradation des valeurs de propriétés les facteurs d’influence pouvant en être la cause. Architecte de l’évolution Décrit les évolutions à produire pour modifier le comportement de système, en accord avec les nouveaux besoins de l’utilisateur. Il a une connaissance partielle du comportement du système. Smile Joue le rôle d’interlocuteur avec les autres acteurs de l’équipe de développement, en leur communiquant par exemple les informations nécessaires à leurs prises de décisions. Il contient des informations sur le système, son implémentation, et les différentes analyses effectuées. Dans le cadre de Blink, Smile automatise certaines tâches comme l’application de l’évolution au système, ou encore son analyse. incrément est une évolution à considérer. Il implique l’ensemble des acteurs du système et permet, à partir de l’expression de nouveaux besoins de la part de l’utilisateur, de définir une évolution qui sera analysée afin de s’assurer du maintien de la qualité de service dans le système post-évolution. Au cours des différentes étapes, certains acteurs sont amenés à interagir. Nous définissons dans la section suivante les points d’interaction du processus, où plusieurs expertises sont nécessaires pour accomplir des tâches communes. 5.4 Coopération entre acteurs Le but de cette section est de mettre en évidence les coopérations entre les différents acteurs. Il s’agit de définir pour un point d’interaction à quel moment celui-ci intervient dans le processus de développement, quels acteurs sont nécessaires, et quelles informations ils vont échanger. Nous distinguons trois points d’interaction, indiqué sur la Figure 5.1 par un titre d’étape souligné : – Évolution des besoins : au cours de cette étape, l’utilisateur et l’architecte du système collaborent ensemble pour établir le plus précisément possible les nouveaux besoins. Il en résulte une spécification des besoins. – Définition de l’évolution : pour pouvoir définir une évolution, l’architecte de cette évolution a pour tâche de proposer une modification qui satisfera les besoins spécifiés. Pour cela, la collaboration de l’architecte du système et de l’architecte de l’évolution consiste à la mise en commun des besoins, une spécification des besoins, guidée par la 455.5. Conclusion du chapitre 0 - Import initial du système 1 - Évolution des besoins 2 - Définition de l'évolution 3 - Analyse de l'évolution 4 - Vérification des éléments affectés 6 (b) - Annulation de l'évolution 6 (a) - Application de l'évolution 5 - Diagnostic et prise de décision décision='ok' décision='¬ ok' Figure 5.1 – Schéma du processus de développement Blink. connaissance pointue du système que l’architecte du système a acquis depuis le début du projet. – Diagnostic et prise de décision : une fois que l’architecte de l’évolution a conçu une modification, et que l’expert en qualité de service l’a analysée, il s’agit de mettre en commun ces deux expertises dans le but de dresser un diagnostic. Pour cela, l’expert en qualité de service apporte les différentes mesures effectuées : l’architecte de l’évolution est en mesure de les interpréter, afin de comprendre pourquoi une évolution a violé un contrat de qualité de service, le cas échéant. Cette coopération a pour but de faciliter le diagnostic, dans l’optique de l’écriture d’une nouvelle évolution qui ne violera pas de contrat de qualité de service. En se basant sur ces différentes coopérations, nous mettons en évidence à quel moment du cycle de vie il est important d’unir plusieurs expertises, évitant ainsi un cloisonnement des acteurs de l’équipe de développement. 5.5 Conclusion du chapitre Nous venons de présenter Blink, un processus de développement pour gérer le maintien de la qualité de service à l’évolution. Pour atteindre cet objectif, nous avons établi un ensemble d’acteurs, et défini leur rôle dans la réalisation d’un système logiciel. Notre processus est constitué d’un ensemble d’étapes, pour lesquelles le ou les acteurs impliqués sont désignés. De plus, cette répartition des rôles tout au long du processus de développe- 465.5. Conclusion du chapitre 0 - Import initial du système 0 - Import initial du système Description Système Description Système SMILE Architecte Système <> <> <> <> SMILE Entrée : Description architecturale d’un système Sortie : représentation du système dans Smile Acteur(s) : Architecte du système, Smile Description : afin de pouvoir unifier l’utilisation du processus de développement Blink pour des nouveaux systèmes comme pour des systèmes existants, l’import initial du système est une étape optionnelle permettant d’importer un système existant, constitué de un ou de plusieurs processus métiers, dans notre canevas de développement. Application à PicWeb : l’architecte du système initie le cycle de développement en important le processus métier dans sa première version (voir Figure 4.3). En sortie de l’étape, Smile produit une structure de données représentant le système, lui permettant par la suite de raisonner dessus. Plus d’informations dans le chapitre 6. 1 - Évolution des besoins 1 - Évolution des besoins Description Système SMILE Description Besoins Utilisateur Architecte Évolution <> <> <> <> Utilisateur Entrée : Représentation du système Sortie : Description des besoins de l’utilisateur Acteur(s) : Utilisateur, Architecte de l’évolution Description : cette étape est déclenchée à l’initiative de l’utilisateur, qui souhaite voir le système évoluer. Pour cela, l’utilisateur et l’architecte de l’évolution se réunissent pour capturer les nouveaux besoins conduisant à faire évoluer le système. Application à PicWeb : l’utilisateur a émis le souhait de voir davantage de photos différentes sur les écrans du campus. L’architecte de l’évolution a proposé alors d’inclure une nouvelle source de données, Flickr. 2 - Définition de l’évolution 2 - Définition de l'évolution Description Besoins Utilisateur Description Évolution Architecte Évolution <> <> <> Entrée : Description des besoins de l’utilisateur Sortie : Description de l’évolution Acteur(s) : Architecte de l’évolution Description : l’étape consiste à définir une évolution du système répondant aux nouveaux besoins. L’architecte de l’évolution exprime l’évolution sous formes d’opérations applicables aux processus métiers. Il décrit la séquence des opérations d’évolution (telles que l’ajout d’une variable, la modi- fication d’une activité) permettant de rendre le système satisfaisant vis-à-vis des nouveaux besoins de l’utilisateur. Application à PicWeb : l’architecte de l’évolution décrit les opérations nécessaires pour ajouter un appel à Flickr en parallèle à Picasa, et pour concaténer les résultats des deux services. Table 5.2 – Description des étapes 0 à 2 du processus de développement (Blink). ment nous a permis de rendre explicite les interactions nécessaires entre acteurs. De cette manière, chaque choix effectué au cours du processus est fondé sur l’ensemble des données nécessaires, permettant de s’assurer à tout moment qu’une décision prise n’altèrerait pas le maintien de la QoS. Il s’agit donc maintenant de savoir, pour chacun de ces acteurs, quels sont les outils à mettre en place pour leur permettre d’apporter les informations nécessaires lors des points d’interaction. Dans la suite du document, nous prenons tour à tour la place de chaque acteur, en déterminant leur problématique propre pour aider au maintien de la qualité de service, et en proposant une contribution permettant de résoudre ces problématiques. 475.5. Conclusion du chapitre 3 - Analyse de l’évolution SMILE 3 - Analyse de l'évolution Description Système Sous-Ensemble Système Architecte Évolution <> <> <> <> Description Évolution <> Entrée : Évolution, Système Sortie : Sous-ensemble du système post-évolution Acteur(s) : Architecte de l’évolution, Smile Description : l’étape d’analyse a pour objectif de déterminer quelles valeurs de propriétés du système sont affectées par l’évolution. Pour cela, Smile identifie les influences entre les éléments manipulés dans l’évolution et le reste du système, pour déterminer quels éléments ont leur comportement affecté par l’évolution. Nous verrons comment ces influences sont déterminées dans les chapitres 6 et 7, et comment l’analyse est réalisée dans le chapitre 8. Application à PicWeb : l’étape d’analyse de l’évolution a pour objectif de déterminer quelles activités sont influencées par l’ajout de Flickr. Ici, il s’agit de lever la limitation présentée dans le chapitre 4, où l’équipe de développement a vérifié uniquement le temps de réponse des activités manipulées par l’évolution. En dressant la chaine de conséquences de l’évolution, l’analyse désigne un sous-ensemble du système à re-vérifier. 4 - Vérification des éléments affectés 4 - Vérification des éléments affectés Sous-Ensemble Système Valeurs de Propriété Expert en QoS <> <> <> <> SMILE Entrée : Sous-ensemble du système post-évolution Sortie : Valeurs de propriétés collectées Acteur(s) : Expert en QoS, Smile Description : Une fois que l’analyse de l’évolution a déterminé les éléments affectés par l’évolution, il s’agit maintenant de savoir si leur modification améliore ou dégrade la qualité de service. Pour cela, l’expert en qualité de service est en charge de contrôler la qualité de service des éléments affectés, pour déterminer les nouvelles valeurs de propriété à l’aide d’outils de détermination de la qualité de service tels que des outils d’analyse statique du système, ou des contrôleurs présents à l’exécution. Application à PicWeb : une version de test est déployée, dans le but de mesurer à l’exécution le temps de réponse des activités désignées lors de l’étape précédente. Ainsi, il est possible de quantifier la différence causée par l’évolution en terme de temps de réponse en la comparant avec les valeurs mesurées sur la version précédente de PicWeb. 5 - Diagnostic et prise de décision 5 - Diagnostic et prise de décision Valeurs de Propriété Décision Architecte Évolution <> <> <> Entrée : Valeurs de propriétés collectées Sortie : Décision Acteur(s) : Architecte de l’évolution Description : le but de cette étape est de décider de l’application d’une évolution. Pour cela, l’architecte compare les nouvelles valeurs de propriétés du système post-évolution avec les contrats de QoS définis. À partir de cette comparaison, l’architecte de l’évolution peut déterminer si un contrat de QoS a été violé, et décider d’appliquer ou non l’évolution. Application à PicWeb : les données collectées révèlent une augmentation importante du temps de réponse, allant au delà du niveau maximum autorisé par le contrat de qualité de service. En observant les valeurs du temps de réponse mesurées à l’exécution, l’architecte de l’évolution est en mesure de détecter que le temps de réponse de l’activité shuffle (a3) a augmenté (voir Figure 4.3). En conséquence, il prend la décision de ne pas appliquer l’évolution. Table 5.3 – Description des étapes 3 à 5 du processus de développement (Blink). 485.5. Conclusion du chapitre 6 - Mise en application de l’évolution SMILE 6 - Mise en application de Décision l'évolution Système cohérent Architecte Évolution <> <> <> <> Description Évolution <> Entrée : Décision, Évolution Sortie : Système dans un état cohérent Acteur(s) : Architecte de l’évolution, Smile Description : la dernière étape consiste à mettre en œuvre la décision prise précédemment. Pour cela, deux choix sont possibles : 1. 6 (a) - Application de l’évolution : Dans cette alternative, il s’agit d’appliquer de manière effective l’évolution sur le système en cours d’exécution. Dans le cas où l’évolution apportée au système satisfait l’architecte de l’évolution, les processus modifiés sont mis à jour et déployés sur le serveur de production de façon atomique. 2. 6 (b) - Annulation de l’évolution : Cette alternative annule les modifications faites dans la représentation du système. Dans le cas où l’évolution apportée au système viole les contrats de qualité de service ou ne satisfont pas l’architecte de l’évolution, il est nécessaire d’annuler l’application de l’évolution. Cela se traduit par une réinitialisation des modèles de raisonnement du système à la version pré-évolution et par un effacement des mesures effectuées au cours de l’étape de vérification, afin de conserver la cohérence entre l’état du système exécutée et sa représentation. Le système retrouve un état cohérent ; l’architecte de l’évolution peut reprendre le cycle de développement en écrivant une nouvelle évolution. Application à PicWeb : Ici, le modèle du système est rétabli tel qu’il était avant d’appliquer l’évolution, et les valeurs de propriétés mesurées sur la version de test sont effacées. Partant de la cause identifiée lors de l’étape 5, l’équipe de développement modifie l’opération shuffle en réduisant le nombre d’échanges effectués et en parallélisant les traitements, permettant ainsi d’obtenir un comportement similaire tout en respectant les contrats de QoS de Séduite. Table 5.4 – Description de l’étape 6 du processus de développement (Blink). 49Chapitre 6 Modélisation d’un système à base de processus métiers Sommaire 6.1 Défis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 6.2 Modélisation du système . . . . . . . . . . . . . . . . . . . . . . . . 52 6.2.1 Univers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 6.2.2 Variables et types . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 6.2.3 Messages et Opérations . . . . . . . . . . . . . . . . . . . . . . . . . 53 6.2.4 Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 6.2.5 Activités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 6.2.6 Relations d’ordre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 6.2.7 Processus métier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 6.2.8 Système . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 6.3 Causalité de l’exécution d’un système . . . . . . . . . . . . . . . . 58 6.3.1 Mise en œuvre de la causalité . . . . . . . . . . . . . . . . . . . . . . 59 6.3.2 Relations causales fonctionnelles . . . . . . . . . . . . . . . . . . . . 59 6.3.3 Exemple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 6.4 Déduction des relations causales d’un système . . . . . . . . . . . 61 6.4.1 Méthodologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 6.4.2 Expression des règles causales . . . . . . . . . . . . . . . . . . . . . . 62 6.5 Conclusion du chapitre . . . . . . . . . . . . . . . . . . . . . . . . . 63 C e chapitre se centre sur le rôle de l’architecte du système. Celui-ci a pour tâche de décrire la structure et le comportement du système ; il doit être en mesure de comprendre les interactions entre ses différentes parties. Pour l’aider dans sa tâche, nous présentons dans un premier temps un méta-modèle permettant de décrire un système. Puis, nous définissons la notion de causalité dans le cadre d’un système à base de processus métier, et motivons l’intérêt de connaitre les relations de causalité dans un système pour comprendre les interactions existantes. Ces relations causales ont pour but de rendre explicite les interactions présentes au sein d’un système. Après avoir illlustré les différents types de relations causales que l’on peut trouver dans un système, nous montrons comment il est possible de les déterminer de manière automatique. Ces causalités, matérialisées sous la forme de relations causales, serviront de base dans le chapitre 8 pour analyser les effets d’une évolution sur la qualité de service d’un système.6.1. Défis 6.1 Défis Dans ce chapitre, nous répondons aux défis suivants : – Modélisation du système : afin de pouvoir répondre aux besoins des utilisateurs, l’architecte a besoin de pouvoir décrire la structure et le comportement du système. Pour cela, nous devons déterminer quels sont les concepts nécessaires à sa modélisation. – Comportement du système à l’exécution : lors de l’exécution du système, processus métiers, variables et appels à des opérations de services interagissent dans le but de pouvoir produire un résultat en sortie. Si l’architecte décrit l’ensemble du comportement du système, la complexité et la taille de ce dernier rendent malgré tout la compréhension des interactions difficile. Comment peut-on rendre explicite les interactions liées à l’exécution d’un système et extraire celles qui nous intéressent ? Nous proposons dans la suite de ce chapitre de présenter dans un premier temps comment l’architecte modélise un système en introduisant notre méta-modèle. Nous avons fait le choix ici de définir notre propre méta-modèle, reprenant les concepts nécessaires à la modélisation de processus métiers. Ainsi, nous offrons la possibilité d’être inter-opérable avec les différents langages de description de processus métiers, en effectuant une correspondance entre les concepts du langage utilisé et notre méta-modèle. Puis, nous définissons la notion de causalité dans un système. Cette notion nous servira à représenter les interactions entre les éléments du système (comme par exemple l’influence d’un paramètre d’un appel à un service sur le comportement de ce dernier). Après avoir présenté différentes relations causales que l’on peut retrouver dans un processus métier tel que PicWeb, nous définissons des groupes de relations, représentant le même type de causalité. Nous introduisons alors la notion de règle causale, qui sont des patrons de relation causale qu’il est possible d’appliquer à un système pour obtenir de manière automatique ses relations causales. 6.2 Modélisation du système Cette section présente notre méta-modèle permettant à l’architecte du système de modéliser un système. Nous définissons chacun des concepts, avant d’illustrer comment ils sont mis en œuvre pour modéliser PicWeb. 6.2.1 Univers L’ensemble des concepts présentés dans la thèse, qui servent à définir un système ou sa qualité de service, sont regroupés autour d’un concept appelé Univers. Un univers est composé d’un ensemble d’éléments (UniverseElement), dont tous les concepts que nous allons présenter héritent. 6.2.2 Variables et types On appelle type de données la caractérisation du sens et de la taille d’une donnée. Nous considérons deux sortes de types : – Types primitifs (SimpleType) : on appelle type primitif la structuration des données à un niveau indivisible. Par exemple, les types Integer, String ou Float sont des types primitifs, définis sur la base de normes existantes [Singh 2006]. 526.2. Modélisation du système – Types complexes (ComplexType) : il est également possible de définir des types de données comme étant une composition de types simples. Par exemple, une séquence est un type complexe constitué d’une suite d’éléments dont la taille n’a pas été définie à l’avance. L’architecte déclarera alors par exemple utiliser un type Sequence, comme étant une suite d’éléments de type Integer. – Types structurés (StructuredType) : en s’appuyant sur les types complexes et les types primitifs, l’architecte a la possibilité de définir ses propres structures de données. Pour cela, un type structuré est constitué d’un ensemble de types, que l’on différencie au sein de la structure de données à l’aide d’un nom (name en anglais). C’est ce que l’on appelle un champ (Field en anglais). À titre d’exemple, l’architecte pourrait définir un type structuré Étudiant, constitué de trois champs nom (de type String), prénom (de type String), et notes (de type Sequence). Une variable est une donnée dont la valeur peut évoluer au cours de l’exécution. Elle est caractérisée par un nom et un type de donnée. À titre d’exemple, la variable keyword est une variable de PicWeb, de type simple String. Une autre variable de PicWeb, PicsPicasa, est une variable de type complexe Sequence. La Figure 6.1 est un extrait de notre méta-modèle permettant de représenter des types et des variables : une variable a un et un seul type ; Type est un méta-élément abstrait, dont héritent SimpleType, ComplexType et StructuredType. Variable size: Natural Type name: String UniverseElement StructuredType SimpleType ComplexType Field of 1..1 fieldType innerFields 0..* 1..1 variableType 1..1 Universe 0..* elmts Figure 6.1 – Extrait du méta-modèle de Smile : variables et types. 6.2.3 Messages et Opérations Nous appelons Opération dans le contexte des architectures orientées services la dé- claration d’une tâche effectuant un traitement. Une opération est déclarée à l’aide d’une signature. Celle-ci définit le nom de l’opération, ainsi que le type de donnée en entrée de l’opération et le type de données produites en sortie. Ainsi, on définit une opération par le tuple : Opération(nom : String, entrée : Type, sortie : Type). Pour interagir avec une opération, il est souvent nécessaire de lui communiquer un ensemble de données à traiter. Cela est réalisé par le biais d’un message. On appelle message une structure de données encapsulant dans une même unité logique l’ensemble des variables nécessitant d’être transmis. Un message est déclaré en lui donnant un nom et en indiquant son type de données. L’invocation d’une opération s’effectue la plupart du temps en envoyant un message, dont le type correspond au type d’entrée de la signature de l’opération. La définition du comportement de l’opération est, dans le contexte des architectures orientées services, réalisée à l’aide d’un processus métier, ou par une implémentation dans un langage de programmation donné. 536.2. Modélisation du système À titre d’illustration, PicWeb est un processus métier implémentant l’opération du même nom. Sa signature est : Opération(nom="PicWeb",entrée="String",sortie=Sequence<"String">). Lorsqu’il est invoqué, PicWeb reçoit en entrée un message constitué d’une seule variable, keyword, de type String. Le processus décrit l’ensemble des traitements à effectuer, pour retourner au final un autre message, constitué d’une seule variable PicsF ; cette variable est de type <"String">, un type complexe constitué d’une séquence d’URLs, de type String. 6.2.4 Services Le concept principal du paradigme des architectures orientées services est le service. Le consortium OASIS définit un service comme étant "un mécanisme pour permettre l’accès à une à plusieurs fonctionnalités, où l’accès est fourni par une interface prescrite et respectant les contraintes et les polices spécifiées dans la description du service"[OASIS 2006]. Un service est une entité logique regroupant un ensemble d’opérations. Nous distinguons deux sortes de services : – Service intra-domaine : il s’agit ici d’un service interne à l’organisation, l’entité en charge du système modélisé par l’architecte du système. Ce service peut être vu comme une boîte blanche, sur lequel des ajustements sont possibles. L’implémentation est disponible, modifiable, maintenable et évolutive. Dans le cadre de PicWeb, Helper est un service dont l’implémentation dépend de l’équipe de développement du système : il s’agit là d’un service intra-domaine. Ce service comprend plusieurs opérations, dont l’opération Format. – Service extra-domaine : en plus des services intra-domaines, il est parfois nécessaire de faire appel à des services proposés par des organisations tierces. Ces services sont vus comme des boîtes noires : l’équipe de développement n’a aucune emprise sur leur implémentation ou leur déploiement. Par exemple, le service Picasa est un service extra-domaine fourni par Google. L’équipe de développement n’a aucune possibilité de changer l’implémentation des opérations de ce service. name = "Helper" localisation="10.24.108.66/Helper" :Service name = "shuffle" :Operation name = "inShuffle" :Message name = "outShuffle" :Message Figure 6.2 – modélisation du service Helper. Un service est défini comme le tuple : Service(nom:String, localisation:String, ops:Ensemble). À titre d’illustration, la Figure 6.2 est un extrait du modèle de PicWeb, représentant le service Helper et son unique opération. Ce modèle est conforme à l’extrait de notre métamodèle illustré dans la Figure 6.3, représentant les différents concepts introduits dans ce paragraphe. Un service a pour attribut sa localisation. Il est constitué de une à plusieurs opérations, possédant au plus un message en entrée et au plus un message en sortie. 546.2. Modélisation du système size: Natural Type name: String UniverseElement location: String Service 1..* Operation 0..1 0..1 input output ops Figure 6.3 – Extrait du méta-modèle de Smile : services, opérations et messages. 6.2.5 Activités Le point de vue choisi pour modéliser un système est celui d’un ensemble de tâches ordonnées dans le temps. Nous appelons activité, en lien avec la définition d’une activité dans le langage BPEL, l’instanciation d’une tâche dans le contexte d’un processus métier. Cette tâche a pour but d’effectuer un traitement sur des données. Par exemple, a2 dans la Figure 4.3 est une activité de PicWeb instanciant une invocation au service Picasa. L’activité prend en entrée un mot-clé, et produit en sortie un ensemble de photos. BasicActivity Receive Invoke Reply Sequence Flow gard: String If StructuredActivity Activity then else content name: String UniverseElement Message input input output output 0..1 0..1 0..1 0..1 1..1 0..1 1..1 0..* Variable content Figure 6.4 – Extrait du méta-modèle de Smile : activités. Nous modélisons l’ensemble des activités par la Figure 6.4. Nous distinguons différents types d’activités : – Réception : l’activité de réception consiste en l’attente bloquante d’une information de la part des partenaires. Le plus souvent, nous retrouvons une activité de réception en début du processus métier, pour récupérer les données en entrée. Le partenaire est alors l’invoquant de l’opération. Une activité de réception est définie comme un tuple Rcp(nom:String, output:Message). La Figure 6.5 est une partie du modèle de PicWeb représentant l’activité de réception d’un message, constitué d’une seule variable keyword. name = "rcv" :Receive name = "inPicWebMsg" :Message name = "keyword" :Variable output content type = "String" varType :Type Figure 6.5 – Extrait du modèle de PicWeb : activité receive. 556.2. Modélisation du système – Envoi : l’envoi est l’équivalent de l’activité de réception, mais pour transmettre des informations aux partenaires. Il sert le plus souvent à retourner le résultat d’un processus métier. Une activité d’envoi est définie comme un tuple Env(nom:String, input:Message). – Invocation : lorsqu’il est nécessaire de faire appel à d’autres services pour effectuer le traitement du processus métier, nous utilisons le type d’activité invocation. Les informations nécessaires pour qualifier une invocation sont le nom du service et l’opération à invoquer. Pour une invocation, il est également nécessaire de définir le message en entrée de l’opération invoquée, et de définir le message destiné à recevoir le résultat de l’opération. Une activité d’invocation est définie comme un tuple Inv(nom:String, op:Operation, input:Message, output:Message). En plus des activités présentés ci-dessus, nous introduisons d’autres activités, dites structurantes. Elles ont pour rôle de regrouper, sous une même entité, différentes activités, en ajoutant une sémantique supplémentaire. Ces activités sont les suivantes : – Condition : Afin de pouvoir effectuer différents traitements selon une condition donnée, l’activité condition permet de décrire les différentes alternatives. Une activité de type condition est constituée d’une condition de garde, expression pour laquelle l’évaluation retournera Vrai ou Faux, et de deux activités nommées Alors et Sinon. Si l’évaluation de la garde retourne Vrai, l’exécution du processus métier se poursuivra par l’activité Alors. Si l’évaluation de la garde retourne Faux, l’activité exécutée sera l’activité Sinon, si elle est spécifiée. Dans le cas contraire, l’activité de condition se termine. – Séquence : une activité de type séquence contient un ensemble ordonné d’activités, pour laquelle la sémantique d’exécution donnée consiste à exécuter les différentes activités dans l’ordre donné. Par exemple, les activités de la première version de PicWeb (Figure 4.3) sont toutes regroupées dans une même séquence. – Flot : une activité de type flot est associée à une sémantique d’exécution différente de celle de séquence. En effet, aucun ordre n’est défini pour l’exécution des activités contenues : elles peuvent être exécutées les unes à la suite des autres et dans un ordre aléatoire, ou bien de manière parallèle. Le flot se termine lorsque l’ensemble des activités contenues a terminé son exécution. Un exemple d’activités de type flot consiste à considérer les deux activités a2 et a3 dans la Figure 4.3 (b). Ces deux activités sont contenues dans une activité de type flot : elles s’exécutent sans aucune garantie de leur ordre relatif. 6.2.6 Relations d’ordre Afin de pouvoir définir l’ordre d’exécution des activités, il est nécessaire d’introduire un concept permettant de prioriser l’exécution des activités. Nous utilisons pour cela la notion de relation d’ordre partiel. Une relation d’ordre Ord(a1, a2 ), (a1,a2 ) ∈ (Activity×Activity) est un couple d’activités tel que a1 s’exécute avant a2. Grâce à cette notion, il est possible de définir un ensemble de relations d’ordre déterminant l’ordre dans lequel les activités vont s’exécuter. Par exemple, la Figure 6.6 représente la modélisation de l’ordre pour les activités a1, a2 et a3 de la Figure 4.3 (a). Toutefois, nous parlons d’ordre partiel puisque s’il est possible de définir l’ordre d’exécution entre deux activités, l’ordre d’exécution de trois activités n’est pas défini. En effet, si nous prenons les activités a1 a2 et a21 de la Figure 4.3 (b), les activités a2 et a21 peuvent s’exécuter en parallèle, ou l’une avant l’autre, sans avoir nécessairement besoin de connaitre cet ordre. 566.2. Modélisation du système :Order from to name = "a1" :Receive name = "a2" :Invoke name = "a3" :Invoke :Order from to Figure 6.6 – Extrait du modèle de PicWeb : relations d’ordre. Il est important de noter ici que la modélisation de l’ordre d’exécution est redondante avec la présence d’activités structurantes. En effet, puisque les activités structurantes sont associées à une sémantique d’exécution précise, dire que deux activités appartiennent à une séquence et dire qu’il existe une relation d’ordre entre ces deux activités est équivalent. Cette dualité permet à la fois d’être souple dans l’expression d’un flot de contrôle, par le biais des relations d’ordre partielle, tout en donnant un cadre hiérarchique aux différentes activités par le biais des activités structurantes. Ce dernier point permet notamment de pouvoir qualifier directement une activité structurante du point de vue de la QoS. La Figure 6.7 représente la partie de notre méta-modèle responsable de modéliser les relations d’ordre. Activity Order from to 1 1 * * Figure 6.7 – Extrait du méta-modèle : relations d’ordre. 6.2.7 Processus métier Nous avons vu dans la définition d’une opération qu’il était possible d’en définir l’implémentation par le biais d’un processus métier. Nous appelons processus métier la réalisation d’une opération par un ensemble d’activités ordonnées. Pour cela, nous réutilisons les concepts introduits précédemment : un processus métier a besoin de variables pour stocker le résultat des différents traitements, d’activités pour instancier les différentes tâches à effectuer, de messages pour communiquer avec les activités, et de relations d’ordre pour prioriser les activités. Enfin, un processus métier a besoin d’un point d’entrée, indiquant par quelle(s) activité(s) démarrer. La Figure 6.8 représente la partie de notre méta-modèle correspondant à un processus métier : formellement, nous définissons un processus métier comme un tuple Proc(vars:Ensemble, msgs:Ensemble, acts:Ensemble, ord:Ensemble, init:EntryPoint). 6.2.8 Système Il existe dans la littérature de nombreuses définitions des systèmes logiciels. Par exemple, le consortium OASIS définit un système comme étant "une collection de composants organisés pour accomplir une fonction ou un ensemble de fonctions spécifiques" [OASIS 2006]. Nous appelons système logiciel l’ensemble des ressources et infrastructures logicielles qu’une équipe de développement est amenée à gérer dans le cadre d’un projet. Un système peut ainsi être vu comme un agglomérat de services, pouvant être implémentés à l’aide de pro- 576.3. Causalité de l’exécution d’un système Business Process Order 0..* rels 1..* acts Activity Variable left right 0..* 0..* ins outs 0..* vars Message 0..* msgs location: String Service 1..* Operation ops implementation 0..1 EntryPoint 1..* start init 0..1 System processes 0..* Figure 6.8 – Extrait du méta-modèle : processus métier. cessus métiers, agissant dans un but commun. Formellement, on considère un système Sys(process:Ensemble, serv:Ensemble). Nous venons de voir dans cette section l’ensemble des concepts nécessaires à l’architecte du système pour modéliser un système. Notre méta-modèle, représenté dans son intégralité en annexe, reprend les concepts communs aux langages de description d’architecture et aux langages de description de processus métier pour fournir un méta-modèle à la fois centré sur le processus métier, mais permettant de décrire la logique d’un système dans son ensemble, comme assemblage de plusieurs processus métiers permettant à l’architecte du système d’en définir son comportement. Dans la section suivante, nous nous intéressons à la causalité présente au cours de l’exécution du système. 6.3 Causalité de l’exécution d’un système L’exécution d’un système peut être vue comme les modifications successives de son état [Turing 1936]. Dans le contexte de la thèse, ceci peut être vu comme une série d’interactions entre les différents éléments constituants le système. Par exemple, la fin d’une activité d’un processus métier peut engendrer le début d’une autre activité. Ce sont ces interactions qui modifient l’état du système, tout au long de son exécution. Lorsque l’architecte fait évoluer un système, il ajoute, modifie ou supprime des éléments. Cela a pour conséquence de changer la manière dont les éléments du système vont interagir, et par la même occasion influe sur leur qualité de service. Afin de pouvoir suivre ces interactions et par la suite calculer l’effet d’une évolution sur la qualité de service du système, il est nécessaire d’établir ces interactions de manière explicite. Ainsi, lorsqu’un élément du système évolue, savoir les conséquences de cette évolution consistera à déterminer l’ensemble des interactions que cet élément a avec le reste du système, pour pouvoir identifier quels sont les éléments pouvant être affectés. Notre objectif est de définir les causalités de notre application, afin de les utiliser lors de l’analyse d’une évolution pour prédire quelles seront les conséquences de l’évolution sur l’état du système. C’est grâce à ces causalités que nous parvenons à identifier concrètement l’effet d’une évolution sur le reste du système et sur sa qualité de service. Dans cette section, nous nous intéressons à la notion de causalité, et définissons dans le contexte de l’exécution d’un système les relations de cause à effet qui sont présentes. Après avoir défini le concept de causalité et de relation causale, nous présentons un moyen d’établir la causalité, en vue de s’en servir pour analyser l’impact d’une évolution. 586.3. Causalité de l’exécution d’un système 6.3.1 Mise en œuvre de la causalité La notion de causalité a des origines provenant de plusieurs disciplines, passant des sciences physiques à la philosophie. En informatique, la causalité a été introduite à de nombreuses reprises également. Nous retiendrons tout particulièrement la définition de la causalité introduite par Judea Pearl [Pearl 2000]. Dans ces travaux, la notion de causalité est définie de manière informelle comme étant "notre conscience de ce qui cause quoi dans le Monde, et en quoi cela est important". Dans notre contexte de système à base de services, nous nous centrons sur cette relation de "ce qui cause quoi". Nous appelons relation causale le couple (X, Y ) ∈ UniverseElement×UniverseElement, représentant l’influence de X sur Y, ou encore le fait que X cause Y. Ici, cette influence veut dire que le comportement de X régit celui de Y. De ce fait, dire que "X est une cause de Y" signifie que si l’état de X change, alors l’état de Y change également. Partant de cette notion, Rooney et al. introduisirent l’analyse de cause racine [Rooney 2004]. Il s’agit ici d’un "processus conçu pour être utilisé dans l’investigation et la catégorisation des causes racines des événements liés à la sûreté, la santé, l’environnement, la qualité, la fiabilité et la production d’impacts". En d’autres termes, ce processus permet, en se basant sur la notion de causalité, de remonter la chaîne de conséquences afin de trouver le facteur-clé à l’origine de la réaction en cascade ayant causé le changement de comportement d’un élément. Nous verrons dans le chapitre 8 que le principe d’analyse de cause racine est à la base de notre analyse des évolutions. Pour établir la chaîne de conséquences constituée lors de l’application d’une évolution, nous avons besoin dans un premier temps de déterminer les changements d’états dans notre système, i.e., les changements opérés par l’évolution, et de déterminer en quoi ces changements vont avoir une influence sur d’autres éléments. Cela nécessite au préalable d’établir les causalités au sein même de notre système. Cette section se concentre sur l’établissement des causalités. Notre objectif ici est de dresser une représentation de notre système d’un point de vue causal. Il s’agit donc d’un modèle, dont la préoccupation principale est de représenter en quoi un élément du système va avoir une influence sur d’autres éléments du système. Nous appelons ce modèle un modèle causal. Définition 6.3.1 (Modèle causal ) Un modèle causal est un couple C, où A est l’ensemble des artéfacts du système et R l’ensemble des relations causales régissant les artéfacts étudiés. Nous verrons dans la suite du document qu’il existe différents types de relations causales au sein d’un système, et relatives aux propriétés de qualité de service étudiées. La question est donc maintenant de savoir quels types de relations causales peuvent opérer dans un système. Dans ce chapitre, nous nous concentrons dans un premier temps sur les relations causales régissant l’exécution d’une système, avant de voir dans le chapitre 7 les relations propres à la qualité de service. 6.3.2 Relations causales fonctionnelles Le système décrit par l’architecte est interprété par une plate-forme d’exécution. Cette plate-forme est définie selon une sémantique précise, régissant les interactions entre les différents éléments du système. Il est donc important de voir que les éléments du système, par le biais de la plate forme d’exécution, interviennent dans l’état d’autres éléments. Cette forme d’interaction entre les éléments du système est ce que l’on cherche à représenter par des relations causales. Le but ici est de permettre à l’architecte du système de comprendre dans un premier temps quels éléments agissent sur d’autres éléments, pour pouvoir ensuite déterminer, partant du changement d’un élément, comment le reste du système va être 596.3. Causalité de l’exécution d’un système affecté. Nous cherchons dans un premier temps à représenter les relations causales propres au comportement de la plate-forme d’exécution pour orchestrer les processus métier. Il est intéressant de noter ici que ces relations causales sont une représentation de la sémantique de la plate-forme d’exécution. Cette sémantique conditionne les relations existantes entre les éléments du système. Par exemple, prenons la notion d’appel à un service. Un service prend des données en entrée, qui régissent l’exécution du service, pour au final produire d’autres données en sortie. Nous pouvons dire ici que l’entrée du service influence le calcul du service, qui lui-même influence la donnée en sortie. Il s’agit bien ici de relations de causalité. Nous introduisons par la suite deux types de relations que l’on peut trouver dans un système. Définition 6.3.2 (Relation Causale de paramètre d’entrée) Soit O une opération du système. Selon la sémantique du moteur d’exécution, le message en entrée de l’opération conditionne l’exécution de l’opération. La relation causale de paramètre d’entrée représente l’influence du paramètre en entrée sur le comportement de l’exécution d’une opération. On note ainsi que entrée in −→ S . De manière similaire, le principe de relation causale de paramètre d’entrée établit cidessus s’applique sur le message produit par le service : Définition 6.3.3 (Relation Causale de paramètre de sortie) Soit O une opération du système. Selon la sémantique du moteur d’exécution, le message en sortie de l’opération est calculé à partir de l’exécution de l’opération. La relation causale de paramètre de sortie représente l’influence du comportement de l’exécution d’une opération sur le paramètre de sortie. On note ainsi que S out −→ sortie . 6.3.3 Exemple Pour illustrer les différents types de relations causales fonctionnelles présentés précédemment, nous nous plaçons dans le contexte du développement de PicWeb. La Figure 6.9 est le modèle causal obtenu en appliquant les définitions de relations causales de paramètre d’entrée et de sortie à PicWeb. Variable Keyword Variable PicsPicasa Variable PicsFlickr Variable Pics Variable PicsF Receive Invoke Picasa Invoke Flickr Invoke Helper Invoke Format Reply Légende: Relation Causale de paramètre d'entrée in out Relation Causale de paramètre de sortie in in in in in in out out out out out Figure 6.9 – Modèle causal fonctionnel de PicWeb. 606.4. Déduction des relations causales d’un système L’observation de ce modèle permet de déterminer par exemple l’effet que pourrait avoir une modification de la variable Pics : en suivant les relations causales sortants de cette variable sur le modèle causal, l’architecte peut identifier l’activité Format comme directement affectée, mais également la variable PicsF et l’activité Reply par transitivité. Dans cette section, nous avons présenté les concepts de causalité, de relation causale fonctionnelle et de modèle causal. En faisant le focus sur le moteur d’exécution du système, nous avons exhibé deux types de relations opérant dans un système. À l’aide de ces deux types, nous avons montré à quoi pouvait ressembler un modèle causal. Si la description faite ici ne représente qu’une infime partie de la sémantique du moteur, elle n’a pour but que de poser les bases nécessaires à la compréhension des modèles causaux et à montrer comment faire le lien entre la sémantique de la description du système et celle du moteur d’exécution, ainsi qu’avec la notion de causalité. Toutefois, s’il est possible de construire le modèle causal de PicWeb à la main, la prise en compte d’autres types de relations causales, ainsi que la taille plus conséquentes des systèmes sont des critères qui nous limitent dans cette méthode. Il est nécessaire pour l’architecte du système de pouvoir automatiser la constitution du modèle causal. Dans la suite de ce chapitre, nous introduisons une méthode permettant d’extraire les relations causales d’un système donné, en caractérisant les types de relations sous la forme de règles causales. Cette méthode est implémentée dans Smile, afin de déduire automatiquement le modèle causal d’un système. 6.4 Déduction des relations causales d’un système Nous venons de définir la notion de modèle causal d’un système, permettant d’identifier les interactions entre ses éléments. Si son utilité n’est plus à montrer, une limitation réside dans son établissement. En effet, la construction manuelle d’un modèle causal est fastidieuse et sujette à erreur, compte tenu du nombre de relations causales présentes dans un système. Dans cette section, nous présentons une méthode permettant de déduire de manière automatisée le modèle causal fonctionnel d’un système. Après avoir présenté les principes de notre méthode, nous définissons la notion de règle causale qui nous sert à décrire, indé- pendamment de tout système, les types de relations causales que l’on peut déduire d’un système. Nous montrons enfin comment, en appliquant les règles causales sur un système donné, il est possible d’en déduire automatiquement ses relations causales. 6.4.1 Méthodologie Le but de la méthodologie est de décrire une transformation permettant, en partant de la description d’un système, d’obtenir son modèle causal. Nous avons présenté précédemment différents types de relations causales fonctionnelles. Il est important de noter que ces types de relations sont décrits indépendamment du système étudié, mais en fonction de la plateforme d’exécution. Il convient donc de souhaiter "instancier" par la suite ces types de relations causales, pour un système donné. Pour cela, notre méthode est un procédé de déduction : il s’agit d’appliquer au système étudié des règles correspondant aux types de relations causales, pour en déduire ses relations causales. Afin de pouvoir mettre en œuvre un tel procédé, nous introduisons la notion de règle causale. Définition 6.4.1 (Définition d’une règle causale) Une règle causale est une requête permettant de sélectionner dans un système donné des couples (a, b) ∈ (SystemElement × SystemElement) tels qu’il existe une relation causale entre a et b. 616.4. Déduction des relations causales d’un système Table 6.1 – Règle causale pour les relations causales de paramètre d’entrée. Situation Action A : Activity, M : Message, v : Variable and (A.type = Invoke or A.type = Receive) and M = A.input and v ∈ M.content v in −→ A Notre méthode consiste à définir en une seule fois les règles causales d’un moteur d’exé- cution, dans le but de les appliquer sur n’importe quel système pour en extraire ses relations causales. Pour cela, nous proposons le procédé représenté dans la Figure 6.10. Système Règles Causales Relations Causales Génération de Relations Causales SMILE expert du moteur d'exécution user Action d'un acteur Légende : Génération de Règles Causales Règles Causales step élément élément step Étape du processus Donnée L'étape step produit la donnée élément La donnée élément est en entrée de l'étape step Figure 6.10 – Procédé de déduction des relations causales. 6.4.2 Expression des règles causales Concrètement, nous avons choisi de représenter les règles causales comme un système de règles de production. Selon le spécification de l’OMG [OMG 2009a], une règle de production est "une instruction de logique de programmation qui spécifie l’exécution de une ou plusieurs actions dans le cas où ses conditions sont satisfaites. Les règles de production ont donc une sémantique opérationnelle (formalisant les changements d’état, e.g., sur la base d’un formalisme d’un système de transition d’état)". Une règle de production est représentée comme une instruction Si [condition] alors [liste d’actions]. À titre d’exemple, la Table 6.1 et la Table 6.2 sont l’expression des règles causales correspondant respectivement aux relations causales d’entrée et de sortie. On parle de Situation pour décrire la condition, et d’Action pour l’ensemble des actions à effectuer. Dans le contexte de la règle causale de paramètre d’entrée, la situation décrite consiste à raisonner sur une activité A, un message M et une variable v. Nous posons comme condition que A soit une activité de type Invoke ou Receive, que M soit le message d’entrée de A, et que v soit contenue dans M. Dans ces conditions, la situation, i.e., la relation causale à déduire, est v in −→ A. Le principe est similaire pour la règle causale de paramètre de sortie, en considérant ici les activités de type Invoke et Reply. En utilisant ces deux règles causales sur PicWeb, notre méthodologie produit le modèle causal de la Figure 6.9. 626.5. Conclusion du chapitre Table 6.2 – Règle causale pour les relations causales de paramètre de sortie. Situation Action A : Activity, M : Message, v : Variable and (A.type = Invoke or A.type = Reply) and M = A.output and v ∈ M.content A out −→ v 6.5 Conclusion du chapitre Dans ce chapitre, nous nous sommes centrés sur les besoins de l’architecte du système. Nous avons introduit les différents concepts nécessaires pour modéliser un système. Partant de cette modélisation, nous nous sommes intéressés à la notion de causalité pour retranscrire les interactions existantes au cours de l’exécution d’un système. À travers la notion de modèle causal, nous avons établi un ensemble de relations causales telles que les relations causales de paramètres d’entrée et de sortie, représentant l’effet d’un élément du système sur un autre. Nous avons enfin présenté une méthode permettant, en exprimant une fois pour toute des types de causalité par le biais de règles causales, de déduire de manière automatique le modèle causal d’un système. Notre approche reste cependant limitée par l’intervention d’un expert du moteur d’exécution qui doit transcrire la sémantique du moteur en règles causales. De plus, si le modèle causal obtenu permet de représenter la causalité d’un point de vue fonctionnel, nous pouvons toutefois nous demander ce qu’il en est de la causalité en vue de l’étude de la variation de la qualité de service dans un système. Nous traitons ce point dans le chapitre suivant. 63Chapitre 7 Modélisation de la qualité de service pour l’évolution Sommaire 7.1 Motivations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 7.2 Modélisation de la qualité de service d’un système . . . . . . . . 66 7.2.1 Propriété, unité et critère de comparaison . . . . . . . . . . . . . . . 67 7.2.2 Domaine d’application . . . . . . . . . . . . . . . . . . . . . . . . . . 67 7.2.3 Valeur de propriété . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 7.2.4 Influence et ressource . . . . . . . . . . . . . . . . . . . . . . . . . . 68 7.2.5 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 7.3 Définition des relations causales de propriété . . . . . . . . . . . . 69 7.3.1 Relations d’environnement . . . . . . . . . . . . . . . . . . . . . . . . 71 7.3.2 Relations de dérivation de propriétés . . . . . . . . . . . . . . . . . . 71 7.3.3 Relations d’agrégation de valeurs . . . . . . . . . . . . . . . . . . . . 73 7.3.4 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 7.4 QoS4Evol, un langage de description de la qualité de service . . 74 7.4.1 Présentation de QoS4Evol . . . . . . . . . . . . . . . . . . . . . . . . 75 7.4.2 Définition du langage . . . . . . . . . . . . . . . . . . . . . . . . . . 75 7.4.3 Caractéristiques du langage . . . . . . . . . . . . . . . . . . . . . . . 76 7.5 Déduction des règles causales d’une propriété . . . . . . . . . . . 77 7.5.1 Principe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 7.5.2 Obtention des relations causales d’environnement . . . . . . . . . . . 78 7.5.3 Obtention des relations causales de dérivation . . . . . . . . . . . . . 79 7.5.4 Obtention des relations causales d’agrégation . . . . . . . . . . . . . 79 7.5.5 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 7.6 Conclusion du chapitre . . . . . . . . . . . . . . . . . . . . . . . . . 81 D ans l’étude d’un système, l’expert en qualité de service a pour rôle de s’assurer du maintien de la QoS du système, à tout moment de son cycle de vie. Il apporte son expertise du domaine pour vérifier le respect des contrats de QoS, et pour identifier les causes d’une potentielle violation. Nous présentons dans ce chapitre un ensemble d’outils nécessaire à l’expert en QoS pour étudier l’effet d’une évolution sur la QoS. 7.1 Motivations Pour rappel, nous considérons qu’une évolution est une modification des fonctionnalités du système dans le but de satisfaire de nouveaux besoins des différentes parties prenantes. Si une évolution cherche en premier lieu à satisfaire de nouveaux besoins fonctionnels, il7.2. Modélisation de la qualité de service d’un système convient de s’interroger si celle-ci a également un effet sur les besoins non fonctionnels, et notamment sur la qualité de service. Selon les principes de notre cycle de développement BLINK, cette préoccupation est à la charge de l’expert en QoS. Celui-ci a pour tâche d’établir les contrats de qualité de service, de mettre en œuvre les outils de contrôle de la QoS, de s’assurer à chaque évolution qu’aucun contrat de QoS n’a été violé et, le cas échéant, il doit être en mesure de définir les causes de la violation. Concernant ce dernier point, nous avons défini dans le chapitre 6 le concept de relation causale d’un point de vue fonctionnel. Nous avons établi un modèle causal destiné à représenter ce qu’il se passe dans un système lors de l’exécution, permettant de comprendre quels éléments du système affectent d’autres éléments. Toutefois, la simple considération de ces relations ne permet pas de décrire la causalité de l’exécution du point de vue de la qualité de service. En guise d’illustration, faisons le parallèle à une machinerie mécanique. Dans ce contexte, la détermination du modèle causal fonctionnel établirait que le moteur a une influence sur les pièces mécaniques de la machine, qui ont elles une influence sur des rouages. En supposant un changement du moteur, le modèle causal indiquerait la chaîne de conséquences jusqu’aux rouages. En revanche, cette chaîne de conséquences n’indique pas de quelle manière la modification influence les rouages, c’est-à-dire si le changement de moteur a entraîné une modification de la vitesse de rotation du rouage, de son usure, de son sens de rotation, etc.. Dans une telle situation, il est donc prudent de vérifier l’ensemble des propriétés du rouage, ce qui est certes plus sûr, mais qui entraîne bien souvent un ensemble de vérifications inutiles. Pour lever ces limitations, nous cherchons à représenter quels sont les facteurs d’influence d’une propriété, dans le but de cibler de manière plus précise quelles valeurs de propriété vont être affectées par une évolution. Ces facteurs d’influence ont pour vocation d’enrichir le modèle causal établi en introduisant des relations causales propres aux propriétés de qualité de service, afin de cibler l’identification des propriétés influencées et minimiser le nombre de vérifications à effectuer. La construction de ce nouveau modèle causal nécessite dans un premier temps d’être en mesure de pouvoir représenter les valeurs de propriété d’un système, afin de pouvoir les inclure en tant qu’élément conceptuel. L’expert en QoS a pour cela besoin de modéliser la qualité de service d’un système à l’exécution, comme présenté dans la section 7.2. Dans un deuxième temps, nous nous intéressons à ce qui peut influencer une valeur de propriété. Nous présentons dans la section 7.3 les différents facteurs d’influence, traduits par le biais de relations causales de QoS. Enfin, nous introduisons dans la section 7.4 un langage permettant de décrire des propriétés de qualité de service. C’est à partir de cette description que nous présentons dans la section 7.5 un procédé permettant de déduire de manière automatique les relations causales d’un système pour une propriété donnée. 7.2 Modélisation de la qualité de service d’un système Nous avons vu dans le chapitre 2 que l’expert en qualité de service a à sa disposition un ensemble d’outils permettant de déterminer la qualité de service d’un élément du système : l’analyse statique de l’élément, le contrôle à l’exécution, ou le calcul à partir d’autres valeurs. Ces outils produisent différents ensembles de données sur lesquels l’expert devra raisonner dans le but de déterminer si oui ou non le système respecte les besoins de l’utilisateur final. Toutefois, la diversité des méthodes de détermination pose un problème d’hétérogénéité pour l’expert. En effet, la diversité des outils de détermination de la qualité de service entraîne une répartition des informations sur différents supports, rendant compliqué tout raisonnement. L’expert a besoin d’un support commun pour représenter ces informations, qui seront ensuite reprises dans le modèle causal. 667.2. Modélisation de la qualité de service d’un système Universe name: String UniverseElement PropertyElement comparator:ComparatorCriteria Property name: String type: TypeKind Unit 1 unit LowerIsBetter HigherIsBetter <> ComparatorCriteria Time DataSize DataSpeed <> TypeKind (a) Extrait du méta-modèle de propriété. name="ResponseTime" comparator=LowerIsBetter :Property name="millisecond" type=Time :Unit unit (b) Extrait du modèle du temps de réponse Figure 7.1 – Modèle et méta-modèle d’une propriété. Nous proposons dans cette section de résoudre ce problème en définissant un métamodèle pour la qualité de service permettant de centraliser les informations collectées. Nous présentons les différents concepts et les illustrons sur PicWeb en étudiant le temps de réponse. 7.2.1 Propriété, unité et critère de comparaison Une propriété est un élément mesurable qui donne une information qualifiant la manière dont le système fonctionne. Il s’agit là du concept central que l’expert en QoS manipule, pour lequel il/elle doit définir un ensemble de caractéristiques. La Figure 7.1a est la partie du méta-modèle représentant les concepts présentés dans cette partie. Une propriété a un nom et une unité, représenté dans notre méta-modèle par les méta-éléments Property et Unit. Par exemple, l’expert en QoS créé une propriété "Temps de réponse", dont l’unité est "millisecondes", comme représenté dans la Figure 7.1b. Associée à la propriété, le critère de comparaison définit pour deux valeurs de cette propriété laquelle sera considérée comme la meilleure. Par exemple, cela permet de savoir lors d’une évolution si une valeur de propriété s’est améliorée ou s’est dégradée. Dans le cas du temps de réponse, l’expert déclare que plus petite la valeur est, le mieux c’est. 7.2.2 Domaine d’application Les systèmes étudiés sont constitués de plusieurs éléments, de types différents. Par exemple, il existe dans PicWeb des activités de type Invoke, Receive, Reply. Nous voulons donner la possibilité à l’expert en QoS de définir une manière de calculer une valeur de propriété en fonction de chaque type d’élément. Par exemple, l’expert veut mesurer le temps de réponse pour les activités de type Invoke, mais calculer les temps de réponse d’une séquence en fonction des temps de réponse des activités qu’il contient. Nous appelons type d’élément du système (SystemElementKind) un type d’élément. Pour pouvoir définir comment dé- terminer la qualité de service pour un type d’élément donné, nous introduisons le concept de domaine d’application. Un domaine d’application (ApplicationDomain) associe une mé- thode de détermination (analyse, contrôle ou calcul) à un type d’élément. Nous représentons cela dans notre méta-modèle par la partie décrite dans la Figure 7.2a : un méta-élément ApplicationDomain, possède une relation avec une méthode de détermination (DeterminationTool) et un type d’élément du système (SystemElementKind). En guise d’illustration, la Figure 7.2b est la partie du modèle du temps de réponse représentant comment déterminer une valeur de propriété pour une activité simple (via le moniteur RTBasicActivityMonitor ), et pour une séquence en décrivant le domaine d’application SequenceActivity. 677.2. Modélisation de la qualité de service d’un système SystemElement name: String UniverseElement PropertyElement Application Domain SystemElementKind 1..* Application Point 1..* comparator:ComparatorCriteria Property Domains 1..1 Type Monitor Aggregation Formula Static Analyser Composition Formula Resource name: String1 DeterminationTool 1..1 Determination (a) Extrait du méta-modèle de propriété. name="ResponseTime" comparator=LowerIsBetter :Property name: "BasicActivity" :Application Domain name = "Invoke" Application Point :SystemElementKind name= "RTBasicActivityMonitor" :Monitor name = "Receive" :SystemElementKind name = "Reply" :SystemElementKind Application Point Application Point name: "SequenceActivity" :Application Domain name = "Sequence" :SystemElementKind Application Point name= "RTSequenceAggrFormula" :Aggregation Formula Determination Determination (b) Extrait du modèle du temps de réponse. Figure 7.2 – Modèle et méta-modèle du domaine d’application. 7.2.3 Valeur de propriété Une valeur de propriété (PropertyValue) est une valeur logique caractérisant un élément du système donné. La Figure 7.3 représente la partie du méta-modèle responsable de définir les valeurs de propriétés. Pour chaque élément du système pour lequel l’expert en QoS a défini un domaine d’application, une valeur de propriété sera créée. Si le méta- élément a pour but de représenter l’ensemble des mesures effectuées, il ne contient lui-même aucune valeur. En effet, les valeurs numériques concrètes sont représentées par le méta- élément Measurement. Ce choix de modélisation a été effectué pour simplifier la recherche de toutes les mesures effectuées pour un élément du système donné, et pour une propriété donnée. Enfin, afin de pouvoir regrouper les mesures effectuées au cours du même contexte d’exécution, nous introduisons le concept de trace d’exécution (ExecutionTrace). Ce concept a pour but de regrouper les valeurs de propriétés qui ont été capturées lors de la même instance d’exécution [Comes 2009]. Il est caractérisé par une estampille ("timestamp" en anglais), et par un numéro de version ("versionNumber" en anglais). Tandis que le premier a pour rôle de capturer l’heure précise à laquelle la trace a été enregistrée, le dernier sert à caractériser sur quelle version du système la trace a été capturé. Lors de chaque évolution, ce numéro est incrémenté. La Figure 7.4 est un exemple de modèle représentant les données mesurées. Ici, l’expert s’intéresse à deux propriétés, le temps de transmission et le temps de calcul. Par souci de lisibilité, le lien entre une propriété et ses valeurs de propriété est représenté par un code couleur. Chaque activité est associée à deux valeurs de propriété, une pour chaque propriété. À chaque valeur est associée un ensemble de mesures. Ici, quatre traces sont présentes, représentant quatre appels à PicWeb. 7.2.4 Influence et ressource Une valeur de propriété de qualité de service dépend de nombreux facteurs. Comme énoncé précédemment, il est courant que le contrôle à l’exécution d’une propriété fournisse des données très différentes pour les mêmes paramètres d’exécution. Cela est dû à l’in- fluence des facteurs extérieurs, tels que l’utilisation de certaines ressources physiques, mais 687.3. Définition des relations causales de propriété Universe SystemElement value: String PropertyValue name: String UniverseElement PropertyElement name: String comparator:ComparatorCriteria Property 0..* values 1 owner timeStamp: Date versionNumber: Natural ExecutionTrace value: Natural Measurement 0..* measures 0..* capturedBy measurements 1 0..* Figure 7.3 – Méta-Modèle de propriété : Valeurs de propriété. également des facteurs internes tels que des éléments du système. Afin de donner la possibilité de représenter quel type de ressource peut influencer une valeur de propriété, nous introduisons le concept de Resource dans notre méta-modèle. Par exemple, la propriété de temps de réponse d’une activité dont l’implémentation est située sur une autre machine que celle de l’appelant sera influencée par le réseau. Également, l’expert souhaite représenter l’effet d’un message en paramètre d’entrée d’une activité sur son temps de transmission. La Figure 7.5a représente la partie du méta-modèle responsable de définir les facteurs d’influence. Ces concepts sont illustrés dans la Figure 7.5b, représentant l’influence du réseau et l’influence d’un message en entrée sur une valeur de propriété. 7.2.5 Discussion Le méta-modèle que nous venons de présenter sert de base de représentation des différentes données nécessaires par l’expert en qualité de service. Nous avons fait le choix de regrouper l’ensemble des mesures effectuées pour une propriété et pour une élément du système donnée autour de l’élément PropertyValue. Selon les méthodes de détermination des valeurs de propriété, le résultat de tout calcul, toute analyse ou toute mesure effectuée sur un élément du système est représenté dans le modèle de données et associé à l’élément analysé. Par cette méthode, nous gardons trace de la provenance des données. Nous avons ici le moyen de tracer pour une mesure le moment de sa capture (permettant de savoir si la donnée a été déterminée sur la version courante du système, ou sur une version antérieure), ainsi que le type d’outil l’ayant déterminé. Ainsi, nous fournissons un support unifié pour les différents outils de détermination de la qualité de service d’un système. De plus, les éléments modélisés servent également de base pour enrichir le modèle causal du système : ce sont les nouveaux nœuds à introduire. Il s’agit donc maintenant de déterminer les nouvelles relations du modèle causal à introduire. Pour cela, nous nous intéressons aux différents éléments pouvant influencer une valeur de propriété. 7.3 Définition des relations causales de propriété Dans cette section, nous nous intéressons à ce qui peut influencer une valeur de propriété. Cette influence peut provenir du comportement du système à l’exécution, de son environnement, ou encore des valeurs de propriétés entre elles. De ces facteurs d’influence, nous en réifions 3 types de relations causales de propriété : i) les relations causales d’environnement, lorsqu’un élément de l’éco-système autour de l’application (tel que le réseau) influence une valeur de propriété, ii) les relations causales de composition, lorsqu’une valeur de propriété rentre dans le calcul d’une autre propriété, et iii) les relations causales d’agrégation, lorsqu’une valeur de propriété d’une activité composite est influencée par une 697.3. Définition des relations causales de propriété :ExecutionTrace timeStamp=1019 versionNumber=1 name="ComputationTime" comparator=LowerIsBetter :Property name="TransmissionTime" comparator=LowerIsBetter :Property name= "receive" :Activity value = 5 :PropertyValue value = 67,5 :PropertyValue value=53 :Measurement value=4 :Measurement value=2409 :Measurement value=607 :Measurement name= "getPics" :Activity :PropertyValue value = 787,25 value = 2344 :PropertyValue value=8 :Measurement value=342 :Measurement name= "shuffle" :Activity value = 543,5 :PropertyValue value = 7 :PropertyValue value=51 :Measurement value=9 :Measurement name= "reply" :Activity value = 14,5 :PropertyValue value = 53,75 :PropertyValue :ExecutionTrace timeStamp=1232 versionNumber=1 value=65 :Measurement value=6 :Measurement value=3034 :Measurement value=719 :Measurement value=4 :Measurement value=604 :Measurement value=56 :Measurement value=17 :Measurement :ExecutionTrace timeStamp=1681 versionNumber=1 value=88 :Measurement value=3 :Measurement value=1757 :Measurement value=802 :Measurement value=9 :Measurement value=285 :Measurement value=48 :Measurement value=14 :Measurement :ExecutionTrace timeStamp=3280 versionNumber=1 value=64 :Measurement value=7 :Measurement value=2176 :Measurement value=1021 :Measurement value=7 :Measurement value=943 :Measurement value=60 :Measurement value=18 :Measurement Figure 7.4 – Modèle du temps de réponse : Valeurs de propriété. valeur de propriété d’une de ses activités contenues. Nous détaillons dans la suite chacun de ces types de relation causale en les illustrant sur PicWeb. 707.3. Définition des relations causales de propriété value: String PropertyValue 0..* influencedBy PropertyElement Resource UniverseElement (a) Extrait du méta-modèle de propriété. value=19 :PropertyValue influencedBy name="Network" :Resource name="TransmissionTime" comparator=LowerIsBetter :Property values name= "getPics" :Invoke name= "inPicasaMsg" input :Message capturedBy (b) Extrait du modèle du temps de réponse. Figure 7.5 – Modèle et méta-modèle des facteurs d’influence. 7.3.1 Relations d’environnement On appelle environnement toutes les ressources physiques et logiques extérieures (tels que les liens réseaux ou la mémoire) à la définition de la logique du système. De fait, les caractéristiques des ressources de l’environnement influent sur la qualité de service du système. Pour cela, nous introduisons une relation causale liée à l’environnement : Définition 7.3.1 (Relation d’environnement) Soient A un élément du système, R une ressource de l’environnement du système, P une propriété dont R est déclarée comme influence, et P VP (A) la valeur de propriété de A pour la propriété P. Une relation causale d’environnement représente la causalité établie entre une valeur de propriété et une ressource de l’environnement : on peut dire que R env −→ P VP (A). À titre d’exemple, nous voulons représenter que la rupture d’un lien réseau peut affecter le temps de réponse d’un service S. Ici, il est important de pouvoir indiquer qu’un lien rompu affectera le temps de réponse, mais n’affectera pas la logique métier propre au service. En revanche, nous pouvons dire que toute propriété de QoS, de type temporel, dont l’élément caractérisé utilise ce lien, sera affecté. Nous établissons donc que NetworkLink env −→ P VResponseT ime(S), comme décrit pour PicWeb dans la Figure 7.6. Pour pouvoir utiliser ce type de relation causale, nous faisons ici l’hypothèse que l’information concernant l’état d’un lien réseau est établie à l’aide d’un moniteur, chargé d’observer le comportement des ressources de l’environnement. Ainsi, lorsque le moniteur détecte qu’un lien est rompu, il suffit de parcourir les relations causales d’environnement propre à la ressource NetworkLink pour déterminer en quoi cela impacte la QoS du système. 7.3.2 Relations de dérivation de propriétés Nous avons vu qu’une propriété de QoS peut être définie comme étant dérivée d’autres propriétés, i.e., qu’il est possible de déterminer une valeur de propriété en fonction des valeurs d’autres propriétés. Ces dernières ont une influence sur la valeur dérivée. Par le concept de relation de dérivation, nous voulons matérialiser cette influence. Définition 7.3.2 (Relation de dérivation) Soit un service S, caractérisé par trois propriétés, P1, P2 et P3, telles que P3 est dérivée de P1 et de P2. La valeur de S pour la propriété P3 est définie en fonction des valeurs de S pour P1 et P2. Par exemple, P VP 3(S) = P VP 1(S) + P VP 2(S). P1 et P2 717.3. Définition des relations causales de propriété Variable Keyword Variable Pics Variable PicsF Receive Invoke Picasa Invoke Shuffle Reply in in out out :PropertyValue name="ResponseTime" comparator=LowerIsBetter :Property values :PropertyValue :PropertyValue :PropertyValue name="NetworkLink" :Resource env env env env out in Légende: Relation Causale de paramètre d'entrée in Relation Causale de paramètre de sortie out env Relation Causale d'environnement Figure 7.6 – Modèle causal enrichi avec les relations d’environnement. ont une influence sur P3. Nous pouvons donc dire qu’il existe les relations causales de dérivation : – P VP 1(S) der −→ P VP 3(S) – P VP 2(S) der −→ P VP 3(S) À titre d’exemple, nous considérons la définition du temps de réponse (RT) d’un service S comme étant la somme du temps de transmission (TT) et du temps de calcul (CT). Nous avons donc la définition PVRT (S) = PVT T (S) + PVCT (S). Cette définition se traduit par deux relations causales de dérivation, PVT T (S) der −→ PVRT (S) et PVCT (S) der −→ PVRT (S). Appliquée à PicWeb, nous obtenons le modèle causal de la Figure 7.7. Ce genre de relation se déduit directement de la formule définissant le temps de réponse. Variable Keyword Variable Pics Variable PicsF Receive Invoke Picasa Invoke Shuffle Reply in in in out out out :PropertyValue name="ResponseTime" comparator=LowerIsBetter :Property values :PropertyValue :PropertyValue :PropertyValue name="NetworkLink" :Resource env env env env :Property Value name="ComputationTime" comparator=LowerIsBetter :Property values :Property Value :Property Value :Property Value :Property Value name="TransmissionTime" comparator=LowerIsBetter :Property values :Property Value :Property Value :Property Value der der der der der der der der Légende: Relation Causale de paramètre d'entrée in Relation Causale de paramètre de sortie out env Relation Causale d'environnement der Relation Causale de dérivation env env env Figure 7.7 – Modèle causal enrichi avec les relations de dérivation. 727.3. Définition des relations causales de propriété 7.3.3 Relations d’agrégation de valeurs Un processus métier est un ensemble d’activités dont l’exécution est définie par des relations d’ordre partiel. Comme présenté dans le chapitre 6, il est possible de représenter cet ordre partiel par le biais d’activités structurées, constituant ainsi une hiérarchie en forme d’arbre, où chaque activité est imbriquée dans une autre activité. Sous cette forme, il est possible de déterminer la valeur de propriété d’une activité structurée en se basant sur les valeurs de propriété des activités qu’elle contient. Par extension, la valeur de propriété d’une activité structurante pour une propriété donnée, décrit par une formule d’agrégation, est influencé par les valeurs de propriété des activités la constituant. À ce titre, nous introduisons la notion de relation causale d’agrégation. Définition 7.3.3 (Relation d’agrégation) Soit C une activité structurante d’un processus métier, constituée de 3 activités, A1, A2 et A3. La propriété P pour une activité structurante est définie comme étant fonction des valeurs de propriétés des activités la constituant. Ici, les valeurs de propriété des constituants (A1, A2 et A3) ont une influence sur la valeur de propriété de l’activité structurante (C). Nous avons donc les relations causales d’agrégation PVP (A1) agr −→ PVP (C), PVP (A2) agr −→ PVP (C) et PVP (A3) agr −→ PVP (C) À titre d’exemple, nous considérons le temps de réponse (RT) d’une activité structurante de type Séquence comme étant la somme des activités la composant. Si nous considérons la séquence présente dans PicWeb, son temps de réponse est la somme des temps de réponse des activités Receive, Picasa, Shuffle et Reply. Nous avons ici plusieurs relations causales d’agrégation, comme décrit dans la Figure 7.8. Dans cette figure, nous avons voulu représenter le modèle causal complet de PicWeb, c’est-à-dire constitué de la somme de toutes les relations causales, qu’elles soient fonctionnelles, d’environnement, de dérivation ou d’agrégation. Variable Keyword Variable Pics Variable PicsF Receive Invoke Picasa Invoke Shuffle Reply in in in out out out :PropertyValue name="ResponseTime" comparator=LowerIsBetter :Property values :PropertyValue :PropertyValue :PropertyValue name="NetworkLink" :Resource env env env env :Property Value name="ComputationTime" comparator=LowerIsBetter :Property values :Property Value :Property Value :Property Value :Property Value name="TransmissionTime" comparator=LowerIsBetter :Property values :Property Value :Property Value :Property Value der der der der der der der der env env env Sequence :Property Value agr agr agr agr Légende: Relation Causale de paramètre d'entrée in Relation Causale de paramètre de sortie out env Relation Causale d'environnement der Relation Causale de dérivation agr Relation Causale d'agrégation Figure 7.8 – Modèle causal enrichi avec les relations d’agrégation. 737.4. QoS4Evol, un langage de description de la qualité de service 7.3.4 Discussion Nous venons de voir les trois types de relations causales que nous pouvons définir sur une propriété de qualité de service. L’application de l’ensemble de ces relations causales permet de décrire de manière plus précise ce qui influence une valeur de propriété. En effet, là où le modèle causal fonctionnel indique les relations de causalités entre éléments du système, les relations causales introduites montrent directement comment les valeurs de propriétés ont une influence entre elles, et comment elles sont influencées par des éléments extérieurs. Nous pouvons cependant nous poser la question de l’exhaustivité de ces types de relations. Nous avons ici émis l’hypothèse que les propriétés étudiées étaient influencées par l’environnement, par d’autres valeurs de propriétés, ou pas le comportement du système. À partir de ces relations, nous donnons une indication sur l’interaction entre les éléments du système afin de définir le périmètre des éléments affectés. Nous pourrions aller plus loin dans l’élaboration du modèle causal, comme par exemple en caractérisant plus finement l’influence d’une ressource à l’aide d’une fonction d’utilisation [Crnkovic 2005]). Dans un tout autre domaine, nous pourrions également aller plus loin en caractérisant si l’influence représentée par une relation causale est positive ou négative pour une propriété donnée, par le biais par exemple de règles helps/hurts [Chung 2009, Bass 2003, Perez-Palacin 2014]. Ces points seront abordés dans des travaux futurs. Les différents types de relations causales que nous venons de voir forment avec les relations causales du chapitre 6 un modèle causal dont la construction manuelle serait source d’erreurs et trop couteux en temps. Nous cherchons à présent à définir une méthode pour obtenir le modèle causal de façon automatique. Pour cela, nous avons besoin dans un premier temps d’un support commun regroupant l’ensemble des informations sur une propriété de QoS. Dans la section suivante, nous présentons QoS4Evol, un langage permettant la description de propriétés. À partir de ces descriptions, nous verrons ensuite que notre canevas, Smile, est en mesure de les analyser pour en extraire des règles de transformations permettant de déduire le modèle causal enrichi de n’importe quel système. 7.4 QoS4Evol, un langage de description de la qualité de service Nous avons vu dans les sections précédentes que la détermination des propriétés de qualité de service pour un processus métier nécessitait un ensemble d’informations en provenance de l’expert en Qualité de Service. Ces informations, qualifiant si une valeur de propriété est déterminée par analyse, par mesure ou par calcul, sont représentables dans le modèle causal. La formulation de toutes ces informations est réalisée à différents moments du cycle de vie, et ne disposent pas à l’heure actuelle d’un support d’expression centralisé. En effet, l’expert doit manuellement déclencher les analyses et déployer les moniteurs d’observation. De plus, nous cherchons à permettre l’expression des relations causales. Pour cela, il nous faut cette centralisation, mais il nous faut également pouvoir définir l’influence que certains éléments du système peuvent avoir sur les autres éléments. Nous proposons dans cette section un langage pour unifier l’expression de ces informations, nommé QoS4Evol. Ce langage a pour but d’apporter une manière simple à l’expert, pour décrire une propriété dans sa manière de la déterminer, de la calculer, ainsi que ses facteurs d’influence. Nous présentons ici la grammaire du langage, avant de montrer par la suite comment il est possible d’en déduire des règles causales à appliquer sur le système étudié pour obtenir automatiquement un modèle causal enrichi. 747.4. QoS4Evol, un langage de description de la qualité de service 1 Property RT{ 2 Unit : ms ; 3 Range : p o s i t i v e ; 4 BasicComputation : CT + TT; 5 ApplicationPoint : 6 Sequence i s Sum( c h i l d r e n ) ; 7 Flow i s Max( c h i l d r e n ) ; 8 Loop i s k × c h i l d r e n ; 9 } 10 11 Property CT{ 12 Unit : ms ; 13 Range : p o s i t i v e ; 14 BasicComputation : monitor named CTMonitor ; 15 IsInfluencedBy : Inpu t ( a ) ; 16 } 17 18 Property TT{ 19 Unit : ms ; 20 Range : p o s i t i v e ; 21 BasicComputation : monitor named TTMonitor ; 22 IsInfluencedBy : Network ; 23 } Figure 7.9 – Définition du Temps de Réponse. 7.4.1 Présentation de QoS4Evol Afin de pouvoir exprimer une propriété de QoS, nous définissons un langage spécifique au domaine (DSL) décrivant l’ensemble des informations nécessaires à la détermination de valeurs de propriété pour le système [Mernik 2005]. QoS4Evol est un DSL textuel, inspiré du langage CQML+ [Rottger 2003] et supporté par notre canevas Smile. Dans la suite, nous détaillons chaque instruction du langage en utilisant ce dernier pour modéliser une propriété, à savoir le Temps de Réponse. Cette propriété est un propriété dérivée, définie comme étant la somme du temps pour transmettre un message (Temps de Transmission) et le temps pour exécuter le dit service (Temps de Calcul). La Figure 7.9 est la description du Temps de réponse écrite par l’expert en qualité de service et conforme à notre langage. Il est important de noter que la description d’une propriété est indépendante du système à étudier. Ces informations ont besoin seulement d’être décrites une fois, pour être ensuite appliquées par Smile sur n’importe quel système pour calculer les valeurs de propriétés. La description proposée fournit les informations usuelles pour gérer une propriété de QoS d’un système. 7.4.2 Définition du langage Une propriété est définie par : Déclaration de l’unité et du domaine de valeur : Considérant l’hypothèse que les valeurs de propriété sont des valeurs numériques, il est nécessaire de définir une unité, et un domaine de valeurs autorisées. Par exemple, le temps de réponse est défini comme une quantité en millisecondes, qui est toujours positif. Dans notre langage, l’unité de la valeur est décrite à l’aide du mot-clé Unit, et le domaine de valeur à l’aide du mot-clé Range. Ces instructions sont utilisées par exemple aux lignes 2 757.4. QoS4Evol, un langage de description de la qualité de service Table 7.1 – Formules d’agrégation du temps de réponse. Temps de réponse Séquence PRT(Sequence.children) Flot max(RT(F low.children)) Boucle k × RT(Loop.activity) et 3 de la Figure 7.9 Détermination des valeurs pour les éléments basiques du système : La technique de détermination de la QoS est fondée sur la composition, c’est-à-dire que les valeurs de propriétés sont déterminées au niveau le plus bas (ici pour des activités simples), pour être ensuite composées pour des éléments de plus haut niveau (les activités structurantes, les processus métiers, et le système). Par exemple, la taille d’un message est calculée par composition de la taille des variables le composant. Dans ce cas précis, les éléments de base sont les variables. Nous considérons ici trois moyens pour calculer une valeur de propriété pour les éléments basiques : par analyse statique, par contrôle, ou par calcul. (voir section 2.2.2). Dans notre exemple, l’expert a introduit trois propriétés : le temps de réponse (RT), le temps de calcul (CT) et le temps de transmission (TT). Tandis que le temps de calcul et le temps de transmission sont décrits aux lignes 14 et 21 comme étant déterminés par des moniteurs (respectivement nommés CTMonitor et TTMonitor), le temps de réponse est déterminé comme étant la somme du temps de calcul et du temps de transmission (voir ligne 4). La déclaration des analyseurs statiques et des contrôleurs permet à Smile d’effectuer de manière automatique les analyses, et de positionner les contrôleurs dans le système. Dans notre cas, le Temps de Réponse est défini comme une propriété dérivée. Le Temps de Calcul (CT) et le Temps de Transmission (TT) sont mesurés en utilisant les contrôleurs fournis. Détermination des valeurs de propriétés pour les éléments composites : Pour calculer la valeur de propriétés d’éléments composite comme les activités structurantes, l’expert en qualité de service décrit une formule d’agrégation, comme on peut en trouver dans la littérature ([Mukherjee 2008]) et rappelée ici dans le tableau 7.1 : il s’agit ici de définir la valeur de propriété d’une activité structurante en fonction de la qualité de service des éléments qu’elle contient. Par exemple, le temps de réponse d’une séquence est la somme des temps de réponse de ses activités filles. De telles formules permettent de calculer une valeur de propriété pour une activité structurante, basée sur les valeurs de propriétés des activités la constituant. Dans notre langage, l’expert en QoS définit dans la section ApplicationPoint la formule d’agrégation pour les activités Sequence, Flow et Loop (voir lignes 5 à 8). Influence de l’environnement : Les formules définies précédemment donnent une manière de calculer une valeur de propriété pour chaque élément du système. Cependant, cette formule n’explicite pas le fait qu’une valeur de propriété peut être influencée par des facteurs extérieurs. Modéliser le fait qu’une ressource spécifique influence une valeur de propriété permet d’inclure cette influence dans notre analyse de l’évolution. Ici, l’expert en QoS écrit la dépendance de la valeur de propriété à d’autres facteurs. Par exemple, l’expert définit que le temps de transmission d’une activité est influencé par le délai du réseau. 7.4.3 Caractéristiques du langage Le langage que nous venons de définir fournit les caractéristiques suivantes : 767.5. Déduction des règles causales d’une propriété Indépendance au système : nous proposons ici d’abstraire complètement la description d’une propriété du système sur lequel elle sera appliquée. Nous obtenons ainsi des propriétés réutilisables, indépendantes du système considéré. Modularité de l’expression : la définition des Points d’Applications permet de diviser les analyses en fonction du type d’élément étudié. Cela permet à l’expert en QoS de se focaliser sur un type d’élément à la fois. Expressivité de la causalité : chacune des sections définies dans la description permet d’établir une règle de causalité du système donné. Nous donnons également la possibilité de décrire comment l’environnement va pouvoir influencer le comportement du système, et donc la valeur de la propriété. En nous basant sur cette description, nous cherchons maintenant à appliquer la définition d’une propriété sur un système donné pour en déduire les relations causales propres à cette propriété. Pour cela, nous présentons dans la section suivante une méthode de déduction des règles causales d’un système propre à une propriété de qualité de service. Cette méthode repose sur le même principe que la méthode de déduction du modèle causal fonctionnel présenté dans le chapitre 6, en se basant sur des règles causales appliquées au système étudié. Toutefois, l’approche appliquée dans ce chapitre diffère dans la méthode d’obtention des règles causales : alors qu’un expert de la plate-forme était obligé d’écrire manuellement les règles causales régissant la plate-forme d’exécution, nous allons ici déduire les règles causales de la description de la propriété. 7.5 Déduction des règles causales d’une propriété L’ensemble des relations causales présentées dans la section 7.3 permet de classifier les différentes dépendances d’un point de vue qualité de service. Si ces dépendances permettent de représenter la causalité d’une propriété, la question de savoir comment obtenir ce genre de modèle reste entière. En effet, la construction manuelle d’un modèle causal, avec un ensemble non négligeable de relations, ne peut pour des raisons évidentes s’envisager : la taille du système, l’aspect fastidieux de la collecte des relations, et le haut risque d’erreur dans la construction nous amène à rejeter l’hypothèse d’une construction à la main. Nous proposons dans la suite une méthode pour enrichir automatiquement le modèle causal d’un système avec les relations causales de propriété. Dans un premier temps, nous présentons comment les informations contenues dans la description d’une propriété de QoS peuvent être transformées en règles de déduction des relations. Puis, nous montrons comment les règles causales sont appliquées à un système donné pour obtenir les différentes relations. Enfin, nous montrons sur notre exemple comment cette méthode peut être appliquée. 7.5.1 Principe La méthode que nous mettons ici en œuvre se déroule en deux temps : il s’agit d’abord de déduire de la description de la propriété un ensemble de règles causales. Ces règles causales sont, de la même manière que dans le chapitre 6, indépendantes de tout système. Dans un deuxième temps, les règles déduites sont appliquées au système étudié pour obtenir ses relations causales propres à la propriété étudiée. La Figure 7.10 est une vue schématisée de notre approche : le procédé est initié en entrée par la description de propriété. La première étape consiste à appliquer sur la description de la propriété des règles de production que nous détaillons dans la suite de ce paragraphe. Ces règles de production génèrent en sortie d’autres règles de production, que nous appelons règle causale. Dans un deuxième temps, nous appliquons les règles de productions générées 777.5. Déduction des règles causales d’une propriété Règles de production (implémentées dans SMILE) Description de propriété Système Règles Causales Relations Causales Génération de Règles Causales Génération de Relations Causales Légende : Génération de Règles Causales Règles Causales step élément élément step Étape du processus Donnée l'étape step produit la donnée élément la donnée élément est en entrée de l'étape step Figure 7.10 – Chaîne de déduction des relations causales de propriété. Table 7.2 – Règle de production des relations causales d’environnement. Situation Action P.influencedBy = R Situation Action PV.getProperty = P R env −→ P V Table 7.3 – Règle causale d’environnement générée. Situation Action PV.getProperty = TT Network env −→ P V sur le système à étudier, pour en déduire les relations causales de propriété. Nous présentons dans la suite l’application de notre méthode pour chacun des trois types de relations causales que nous avons présenté dans la section 7.3. 7.5.2 Obtention des relations causales d’environnement Pour rappel, une relation causale d’environnement établie la causalité entre une ressource de l’environnement et une valeur de propriété. Dans le langage de description des propriétés que nous avons défini, ce genre de dépendance peut-être déduit de la section influencedBy. Par exemple, l’expert a déclaré dans la Figure 7.9 que le temps de transmission est influencé par le réseau. Ainsi, pour toute valeur de propriété P VT T du temps de transmission, il existe une relation causale Network env −→ P VT T . Ce comportement est identique à toute ressource déclarée comme source d’influence. De ce fait, nous pouvons écrire une règle de production qui est applicable à n’importe quelle section influencedBy. Cette règle est consignée dans le Table 7.2. Une fois ce patron appliqué à la description de propriété (lors de l’étape de génération de règles), nous obtenons un ensemble de règles causales d’environnement. Par exemple, la génération de règles a produit plusieurs règles, dont celle consignée dans le Table 7.3. Il est important de noter que chacun des patrons écrits dans cette section est universel : il est valide pour toute règle causale de dérivation, d’agrégation ou d’environnement. 787.5. Déduction des règles causales d’une propriété Table 7.4 – Règle de production des relations causales de dérivation. Situation Action P.basicComputation=f (Props) Situation Action ∀Px ∈ Props, P V1.prop=Px and P V2.prop=P and P V1.owner=P V2.owner P V1 der −→ P V2 Table 7.5 – Règle causale de dérivation générée. Situation Action ∀Px ∈ {TT,CT}, P V1.prop=Px and P V2.prop=RT and P V1.owner=P V2.owner P V1 der −→ P V2 7.5.3 Obtention des relations causales de dérivation Une relation causale de dérivation intervient lorsque une propriété est définie à l’aide d’une formule de dérivation. Cette information est également présente dans la description de la propriété : dans la section BasicComputation, une valeur possible pour cette section est d’indiquer une formule de dérivation. Le cas échéant, chacune des opérandes de la formule est une source d’une relation causale de dérivation. Pour construire les relations causales de dérivation, il s’agit donc de trouver toutes les valeurs de propriétés dérivées, et créer une relation entre chaque opérande de la formule de dérivation et la propriété dérivée. Pour obtenir ces règles causales de dérivation, nous avons écrit une autre règle de production spécifique aux relations causales de dérivation. Celui ci est consigné dans le Table 7.4. Une fois la règle de production appliquée sur la description de propriété, nous obtenons une règle causale de dérivation similaire à celle consignée dans la Table 7.5. Celleci sélectionne toute propriété dont la méthode de calcul basique est une fonction dont les paramètres sont l’ensemble Props. Partant de l’ensemble des paramètres, la règle de production générée recherche les valeurs de propriété correspondant à la propriété donnée (P V1.prop=Px), ainsi que les valeurs de propriété de P (P V2.prop=P), et sélectionne l’unique couple P V1 et P V2 tel qu’ils caractérisent le même élément du système (P V1.owner=P V2.owner). Cette situation résulte en l’action de la création de la relation causale de dérivation P V1 der −→ P V2. 7.5.4 Obtention des relations causales d’agrégation Les relations causales d’agrégation interviennent pour calculer la valeur de propriété d’une activité structurante à partir des valeurs de propriété de ses activités contenues. Pour cela, il suffit de collecter l’information à partir de la section ApplicationPoint de la description de propriété. Nous décrivons dans le Table 7.6 la règle de production correspondant aux règles causales d’agrégation. Une fois appliquée à la description du temps de réponse, notre méthode génère la règle de production décrite dans le Table 7.7, correspondant au point d’application des activités de type Séquence. La situation de cette règle est constituée d’un ensemble de conditions, le but étant de sélectionner les valeurs du temps de réponse d’une séquence et de ses activités filles. Pour cela, nous raisonnons sur deux acti- 797.5. Déduction des règles causales d’une propriété Table 7.6 – Règle de production des relations causales d’agrégation. Situation P.ApplicationPoint.isStructuredType=True and P.ApplicationPoint=f (Children) Action Situation Action A1, A2 : Activity and A1.type=P.applicationDomain. applicationPoint and A2 ∈ A1.content and PV1.prop = P and PV2.prop = P and PV1.owner = A1 and PV2.owner = A2 PVP (A1) agr −→ PVP (A2) Table 7.7 – Règle causale d’agrégation générée. Situation Action A1, A2 : Activity and A1.type=Sequence and A2 ∈ A1.content and PV1.prop = RT and PV2.prop = RT and PV1.owner = A1 and PV2.owner = A2 PVRT (A1) agr −→ PVRT (A2) vités A1, A2 telles que A1 correspond aux activités de type Séquence (A1.type=Sequence ), et A2 les activités qu’elle contient (A2 ∈ A1.content). Nous raisonnons ensuite sur l’ensemble des valeurs de propriété, en sélectionnant les valeurs correspondant au temps de réponse (PV1.prop = RT and PV2.prop = RT), pour enfin sélectionner les deux valeurs de propriétés attachées à A1 et A2. Nous ne montrons ici que l’application de la règle de production pour le point d’activité séquence, l’équivalent pour le flot ("flow" en anglais) et la boucle ("loop" en anglais) étant similaire. Une fois que les règles causales ont été déduites, il est possible de les appliquer à n’importe quel système pour en extraire ses relations causales de propriété. Comme décrit dans le chapitre 6, Smile applique les règles causales de propriété sur le système pour produire un modèle causal correspondant à celui que nous avons décrit dans la section 7.3 (voir Figure 7.8). 7.5.5 Discussion Le procédé que nous venons de décrire permet de déduire de manière automatique le modèle causal de propriété d’un système, en se basant sur la description d’une propriété. Nous avons identifié un ensemble de trois types de relations causales propres aux propriétés de qualité de service. Toutefois, notre approche dépend fortement de la description de la propriété réalisée par l’expert en QoS. Elle est ainsi limitée dans le sens où des informations supplémentaires doivent y être inscrites, nécessitant un effort supplémentaire de la part de l’expert en QoS. Malgré cette limitation, notre approche améliore le modèle causal du système décrit dans le chapitre 6, en apportant une granularité plus fine dans la détermination des causes et des conséquences au sein d’un système. De plus, les règles de production décrites pour générer les règles causales sont génériques pour toutes les propriétés : il suffit pour l’expert en qualité de service de décrire sa propriété pour obtenir les règles causales correspondantes, 807.6. Conclusion du chapitre pour pouvoir les appliquer à n’importe quel système. Cette contribution permet d’apporter une réponse au défi "interactions entre les différentes parties d’un logiciel", en enrichissant le modèle causal par des relations causales propres à la qualité de service. En augmentant notre modèle causal de relations propres à la QoS, nous apportons également des éléments de réponses au "minimisation de la vérification" : grâce à un niveau de précision supérieur, nous permettons ici de cibler au plus près les valeurs de propriété à re-vérifier. 7.6 Conclusion du chapitre Dans ce chapitre, nous avons proposé un modèle de données permettant de modéliser la définition d’une propriété de QoS, ainsi que la représentation unifiée des données de détermination. Pour faciliter la tâche de l’expert, nous avons défini un langage spécifique au domaine permettant de décrire des propriétés de qualité de service. L’intérêt de la définition d’un nouveau langage ici provient du besoin d’exprimer les influences entre les différents éléments du système. En effet, la plupart des langages existants se focalisent sur la manière d’observer la propriété. Il est important de noter toutefois que ce prototype de langage est à fin expérimentale. Dans un futur proche, il serait utile d’étendre un langage existant avec les concepts de ce langage, afin de bénéficier de toute la puissance du langage étendu. À partir de la description de propriété, nous avons présenté une méthode permettant d’extraire automatiquement des règles causales spécifiques à la propriété, dans le but de les appliquer de manière automatique à n’importe quel système afin d’en extraire un modèle causal enrichi. Cette méthode permet de s’affranchir d’une construction manuelle qui aurait été coûteuse en temps et sujette à erreur. De manière générale, si notre solution pour l’expert en qualité de service diminue et simplifie la gestion de la qualité de service en unifiant l’ensemble des outils dans une seule description, un effort reste à faire pour automatiser complètement la gestion de la qualité de service. En effet, pour chaque outil envisagé, il sera nécessaire de définir une transformation des données produites par l’outil pour les intégrer dans le modèle unifié. De plus, si notre canevas permet de s’assurer de la cohérence du modèle de données tout au long du cycle de vie du système, le principe de pérennité des données capturées au cours de la détermination reste à la charge de l’expert. Il s’agira à l’avenir de réfléchir à une méthode automatique visant à supprimée les données obsolètes, après un certain nombre d’évolutions par exemple. Dans le chapitre suivant, nous nous intéressons au rôle de l’architecte de l’évolution. Nous présentons son rôle et expliquons comment ce modèle causal enrichi peut l’aider dans l’analyse d’une évolution. 81Chapitre 8 Analyse de l’évolution du logiciel orientée QoS Sommaire 8.1 Présentation générale du processus d’évolution . . . . . . . . . . 84 8.1.1 Enjeux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 8.1.2 Spécification du processus d’évolution . . . . . . . . . . . . . . . . . 84 8.1.3 Hypothèses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 8.2 Un langage pour l’évolution des processus métier . . . . . . . . . 86 8.3 Spécification de l’analyse de l’évolution . . . . . . . . . . . . . . . 87 8.3.1 Aperçu des différentes étapes . . . . . . . . . . . . . . . . . . . . . . 88 8.3.2 Étape 1 : mise à jour du modèle causal . . . . . . . . . . . . . . . . . 89 8.3.3 Étape 2 : analyse causale . . . . . . . . . . . . . . . . . . . . . . . . 92 8.3.4 Étape 3 : re-vérification . . . . . . . . . . . . . . . . . . . . . . . . . 93 8.3.5 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 8.4 Résultat de l’analyse et prise de décision . . . . . . . . . . . . . . 96 8.4.1 Enjeux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 8.4.2 Vérification des contrats . . . . . . . . . . . . . . . . . . . . . . . . . 97 8.4.3 Détermination des causes racines . . . . . . . . . . . . . . . . . . . . 98 8.4.4 Déploiement et retour en arrière (roll-back) . . . . . . . . . . . . . . 99 8.4.5 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 8.5 Conclusion du chapitre . . . . . . . . . . . . . . . . . . . . . . . . . 101 D ans ce chapitre, nous présentons notre approche pour effectuer et analyser une évolution. Cette approche se centre sur l’architecte de l’évolution, pour lequel il est nécessaire de savoir si l’évolution qu’il/elle a décrit ne cause pas le viol d’un contrat de qualité de service à l’échelle du système lorsqu’elle est appliquée. Ce chapitre présente la contribution finale de ce document, où nous expliquons comment le modèle causal déduit dans le chapitre précédent est utilisé pour effectuer une analyse des conséquences de l’évolution sur la qualité de service du système. L’objectif de l’analyse est d’identifier le sous-ensemble du système affecté, directement ou indirectement, par l’évolution, afin de déterminer son effet sur la qualité de service. Le résultat de l’analyse permet de renseigner l’architecte de l’évolution sur une potentielle amélioration ou dégradation de la qualité de service. Au final, l’analyse de l’évolution détermine si l’application de l’évolution sur le système maintient les différentes propriétés de qualité de service considérées. Ce chapitre est constitué comme suit : dans un premier temps, nous présentons la spé- cification des différentes étapes constituant une évolution, de la définition des nouveaux besoins, à l’expression des modifications à appliquer au système. Puis, nous détaillons chacune des étapes de l’analyse en expliquant leurs spécificités et les choix conceptuels que8.1. Présentation générale du processus d’évolution nous avons pris. Enfin, la dernière section détaille comment le résultat de l’analyse de l’évolution, à savoir l’ensemble des éléments affectés du système, est utilisé pour re-vérifier le système dans le but de quantifier l’effet de l’évolution et de dire si la qualité de service est maintenue. 8.1 Présentation générale du processus d’évolution 8.1.1 Enjeux L’objectif de ce chapitre est de présenter une méthode permettant de garantir le maintien de la qualité de service au cours de l’évolution. Pour cela, nos objectifs sont les suivants : – Maintien de la qualité de service : nous cherchons par le biais de notre analyse à savoir si une évolution a un effet sur la qualité de service. Pour cela, nous introduisons le concept de caractérisation d’une évolution : Définition 8.1.1 (Caractérisation d’une évolution) Une évolution peut être caractérisée comme étant neutre, bénéfique ou néfaste, si elle n’a respectivement aucun effet, un effet d’amélioration ou un effet de dégradation sur la valeur de la propriété de QoS considérée. On considère également qu’une évolution sera jugée satisfaisante en terme d’une propriété de QoS si l’évolution ne cause pas de violation de contrat. Concrètement, la caractérisation d’une évolution s’effectue en comparant la valeur de qualité de service pour le système avant l’évolution à la valeur après l’évolution. Si la valeur s’améliore (voir chapitre 7), alors l’évolution sera bénéfique. – Diagnostic en cas de non-maintien de la qualité de service : lorsqu’une évolution dégrade une valeur de QoS et qu’elle cause la violation d’un contrat de QoS, l’architecte de l’évolution doit être en mesure de modifier la description de l’évolution pour corriger l’erreur. Dans ce cas, il est nécessaire de savoir quel est l’élément du système responsable de la violation. Pour répondre à ces défis, nous proposons un processus d’évolution s’assurant du maintien de la qualité de service et de l’identification de la cause d’une violation de contrat. Afin de montrer le fonctionnement du processus, nous utilisons PicWeb comme illustration. 8.1.2 Spécification du processus d’évolution Le processus d’évolution peut être vu comme une transformation du système d’un état S à un état S’. À titre de guide, la Figure 8.1 en représente les différentes étapes : l’architecte de l’évolution décrit en (1) une évolution à appliquer sur le système. En s’appuyant sur cette description, ainsi que sur les descriptions de propriétés à contrôler, l’évolution est alors analysée en (2), afin de déterminer si elle est satisfaisante du point de vue de la QoS. Le cas échéant, l’évolution est en (3) appliquée de manière effective, ou bien l’architecte de l’évolution observe les causes déterminées par l’analyse pour pouvoir corriger son évolution et en proposer une nouvelle. Nous détaillons chacune des étapes dans la suite de cette section. 848.1. Présentation générale du processus d’évolution 2 - Analyse de l'évolution 1 - Description de l'évolution Architecte de l'évolution 3 - Prise de S décision S' Figure 8.1 – Processus d’évolution. 8.1.2.1 Étape 1 : description de l’évolution WriteEvolution : ∅ −→ Évolution La première étape consiste à décrire les modifications que l’on veut apporter au processus métier. L’architecte du système décrit dans un premier temps la séquence de modifications à opérer sur le système, telles que les ajouts, suppressions ou mises à jour des différents éléments du système. L’objectif de cette étape est de construire une modification de la structure et du comportement du système, dans le but de satisfaire les changements des besoins de l’utilisateur. Nous montrons dans la section 8.2 comment cette description peut être établie avec notre langage pour l’évolution. 8.1.2.2 Étape 2 : analyse de l’évolution Analyse : Évolution −→ Set, Set La deuxième étape consiste à déterminer les effets de l’évolution sur la qualité de service du système. Pour cela, l’analyse repose sur l’établissement du modèle causal futur, i.e., tel qu’il serait si l’évolution était établie. Partant de ce modèle, l’analyse identifie le sousensemble des valeurs de propriétés affectées par l’évolution. Enfin, l’analyse se termine par une re-vérification de ces valeurs, afin de pouvoir déterminer si les contrats de QoS sont toujours respectés, ou si au contraire ils ont été violés. 8.1.2.3 Étape 3 : prise de décision Decision : Set, Set −→ Boolean La dernière étape de l’analyse a pour rôle d’apporter les informations nécessaires à l’architecte de l’évolution afin de savoir si l’évolution proposée respecte bien les contrats de qualité de service définis. Au cours de cette étape, l’architecte choisit d’appliquer l’évolution de manière effective sur le système en production. En cas de problème sur un contrat, il s’agira de rentrer dans une phase de diagnostic afin de comprendre pourquoi le contrat a été violé. Les modifications faites sur le modèle causal sont alors annulées avant de revenir au début du processus, afin de définir une nouvelle évolution. 8.1.3 Hypothèses Afin de pouvoir garantir la cohésion du système, nous devons poser un certain nombre d’hypothèses : – Nous considérons ici que pour garantir la cohérence du système, deux évolutions ne peuvent être appliquées en parallèle. Notre processus d’évolution devra être conçu 858.2. Un langage pour l’évolution des processus métier Table 8.1 – Liste des opérations d’évolution. Opération Description addVariable(var) var est ajoutée au modèle delVariable(var) var est retirée du modèle addActivity(id, nom) act est ajoutée au modèle delActivity(id) act est retirée du modèle addInParameter(act,var,pos) var est dans les paramètres de act, en position pos delInParameter(act,var) var est retirée des paramètres de act addOutParameter(act,var,pos) var est dans le résultat de act, en position pos delOutParameter(act,var) var est retirée du résultat de act addRelation(idFrom, itTo) une relation d’ordre est créée entre les activités idFrom et idTo delRelation(idFrom,itTo) la relation d’ordre entre les activités idFrom et idTo est supprimée pour effectuer les évolutions de manière séquentielle et atomique, ce dernier point permettant ainsi de revenir à la version précédente en cas de problème. – Pour pouvoir déterminer si la QoS est maintenue, nous supposons que la description des propriétés de QoS est disponible, et que des contrats sont définis au préalable. Dans la suite de ce chapitre, nous détaillons chacune des étapes du processus d’évolution. Après avoir introduit notre langage pour décrire une évolution, nous nous focalisons sur les spécificités de chacune des étapes du processus d’analyse. Nous détaillons chacune des étapes, avant de les illustrer à l’aide du cas d’étude. Nous désignons dans le reste du chapitre les parties du système telles que les variables, les services, les activités, ou les paramètres en entrée/sortie d’un service comme étant des éléments du système (voir chapitre 6). 8.2 Un langage pour l’évolution des processus métier L’étape initiale du processus d’évolution consiste à exprimer les changements à effectuer sur le système décrit par l’architecte du système pour satisfaire les nouveaux besoins de l’utilisateur. Pour cela, de nombreux langages de description de l’évolution d’un système existent. Par exemple, Praxis est un outil d’analyse de l’évolution de modèles [Blanc 2009]. Plus proche de notre domaine d’application, Adore est un langage d’évolution de processus métier basé sur les techniques de tissage de modèle [Mosser 2013]. Ces langages expriment une évolution en proposant principalement des modifications structurelles du système. Il s’agira de pouvoir déclarer l’ajout, la suppression ou la mise à jour de concepts du système étudié. Nous proposons ici de reprendre les concepts communs aux langages d’évolution pour définir notre propre langage d’évolution. Nous avons défini des opérateurs permettant de manipuler des variables, des activités et des relations d’ordre. Notre langage d’évolution permet l’ajout, la suppression et la mise à jour des différents éléments du système. Il est constitué d’un jeu de dix opérations destiné à ajouter, supprimer des éléments propres aux processus métiers. La Table 8.1 dresse la liste des différentes opérations disponibles. 868.3. Spécification de l’analyse de l’évolution Dans le cadre de notre exemple fil rouge, nous rappelons que suite à la première version de PicWeb, les utilisateurs ont émis le souhait de bénéficier d’une source de données supplémentaire, Flickr, pour les photos retournées par le processus métier. L’architecte de l’évolution conçoit alors une évolution répondant à ce besoin. Elle se découpe en trois étapes : – Ajout de l’appel à Flickr : afin de faire évoluer le processus métier, l’architecte de l’évolution propose d’ajouter en parallèle de l’appel à Picasa un appel au service de Flickr. Il s’agit donc ici d’ajouter une nouvelle activité au processus métier, ayant en entrée le mot-clé recherché. Afin de pouvoir récupérer des données en sortie, une nouvelle variable, PicsFlickr, a besoin d’être créée et ajoutée en temps que valeur de sortie de l’activité Flickr. – Ajout de l’appel à Concat : désormais, le processus métier doit manipuler deux ensembles de données, que nous souhaitons concaténer. De manière similaire à l’ajout de l’activité Flickr, l’architecte ajoute une activité, concat, prenant en entrée les deux ensembles, pour produire en sortie un nouvel ensemble concaténant le deuxième ensemble à la suite du premier. – Mise à jour de l’ordre d’exécution : la création de deux nouvelles activités dans notre processus métier implique de rendre de nouveau cohérent l’ordre partiel d’exé- cution. Pour que Flickr s’exécute en parallèle de Picasa, l’architecte introduit une relation temporelle entre l’activité receive et l’appel à Flickr. Les deux services de récupération de données sont suivis désormais par concat qui termine la modification en reprenant la suite du processus métier. Pour effectuer cette évolution, l’architecte de l’évolution décrit en Figure 8.2 l’ensemble des opérations à effectuer. L’évolution est composée de quatre parties : les lignes 2 à 4 mettent à jour l’activité Picasa en changeant le nom de sa valeur de retour par une nouvelle variable, PicsPicasa. Les lignes 6 à 9 ajoutent l’appel à l’activité Flickr. Les lignes 11 à 14 sont responsables de l’appel à l’activité Helper, qui va concaténer PicsPicasa et PicsFlickr dans Pics. Enfin, les lignes 16 à 20 rétablissent l’ordre partiel entre les activités. Une fois que l’évolution est décrite, l’architecte de l’évolution peut déclencher l’analyse de l’évolution. 8.3 Spécification de l’analyse de l’évolution L’analyse de l’évolution est une étape cruciale du processus d’évolution. Elle soulève les objectifs suivants : – Minimisation de la re-vérification : nous cherchons à effectuer le moins de véri- fications inutiles possibles, particulièrement dans le cas où la re-vérification doit être effectuée à l’exécution, pouvant potentiellement affecter les utilisateurs du système. Il s’agira de cerner au plus près l’ensemble des éléments impactés, en écartant les éléments neutres vis à vis de l’évolution, sans pour autant écarter d’éléments affectés. – Qualification de l’évolution : afin de pouvoir caractériser l’évolution, nous cherchons à savoir ici si l’évolution est bénéfique, neutre ou néfaste du point de vue d’une propriété de qualité de service. À la fin de cette étape, l’architecte de l’évolution a besoin de connaître les valeurs de propriétés pour l’ensemble du système, afin d’être en mesure de comparer les valeurs avant évolution et après évolution. Au delà d’un rapport qualitatif, l’architecte de l’évolution doit être en mesure de pouvoir quantifier son apport, afin de déterminer si elle est acceptable ou non. 878.3. Spécification de l’analyse de l’évolution 1 Evolution{ 2 addVariable ( Pi c s Pi c a s a ) 3 delOutParameter ( a2 , Pi c s ) 4 addOutParameter( a2 , Pi c s Pi c a s a , 0 ) 5 6 addVariable ( P i c s F l i c k r ) 7 addActivity ( a22 , F l i c k r ) 8 addInParameter ( a22 , Tag , 0 ) 9 addOutParameter( a22 , Pi c s Fli c k r , 0 ) 10 11 addActivity ( a23 , j o i n ) 12 addInParameter ( a23 , Pi c s Pi c a s a , 0 ) 13 addInParameter ( a23 , Pi c s Fli c k r , 1 ) 14 addOutParameter( a23 , Pic s , 0 ) 15 16 addRelation( r e c ei v e , a22 ) 17 addRelation( a22 , a23 ) 18 addRelation( a23 , a3 ) 19 addRelation( a2 , a23 ) 20 delRelation ( a3 , a2 ) 21 } Figure 8.2 – Évolution de PicWeb. Le but de cette section est de présenter les différentes étapes constituant l’analyse de l’évolution, tout en motivant leur intérêt. Notre analyse a pour objectif de montrer à l’architecte de l’évolution les effets développés sur les propriétés de qualité de service du système. Elle prend en entrée un système, une évolution, et des propriétés à considérer, afin de lister en sortie le ou les contrats de qualité de service violés, accompagnés d’une trace d’exécution montrant la violation de contrat. Nous présentons chacune des trois étapes la constituant, et l’illustrons en les appliquant sur PicWeb. 8.3.1 Aperçu des différentes étapes Nous présentons dans cette partie les différentes étapes de l’analyse d’évolution décrite dans la Figure 8.3, en précisant leurs entrées et sorties, et en expliquant l’objectif et l’intérêt de chacune des étapes. 2 - Analyse Causale 1 - Mise à jour du Modèle Causal 3 - Re-vérification des valeurs de propriétés 2 - Analyse de l'évolution Evolution Modèle Causal Description propriété S Modèle Causal Set Set Set Figure 8.3 – Étapes de l’analyse de l’évolution. – Étape 1 : mise à jour du modèle causal Evolution × CausalModel −→ CausalModel Une fois que l’évolution est décrite, l’analyse de l’effet de l’évolution sur le système débute. Puisque cette analyse se base sur le modèle causal de l’application, la première 888.3. Spécification de l’analyse de l’évolution étape de l’analyse consiste à mettre à jour le modèle causal. Il s’agit ici de défaire les relations n’ayant plus de sens, et d’ajouter les nouvelles relations causales correspondant à l’évolution en cours d’application. Similairement, des nœuds du modèle causal sont créés ou détruits, afin de refléter au plus près les causalités entre les éléments du système tel qu’il serait si l’évolution était effectivement appliquée. – Étape 2 : analyse Causale CausalModel × Set −→ Set Prenant en entrée les éléments ajoutés ou supprimés, l’analyse causale consiste en un parcours du modèle causal, afin d’identifier les éléments du système affectés par l’évolution. En sortie, l’analyse causale produit une liste des tous les éléments du système ayant une relation de causalité établie avec l’évolution, et pour lesquels une nouvelle vérification est nécessaire. – Étape 3 : re-vérification des valeurs de propriétés Set −→ Set La dernière étape de l’analyse détermine les nouvelles valeurs de propriétés des élé- ments affectés, afin de connaître l’effet concret de l’évolution sur les propriétés de qualité de service étudiées. Ici, l’analyse déclenche alors les outils de re-détermination des valeurs de propriétés adéquats, et déploie si besoin sur un serveur de test une version du système évolué et enrichi de moniteurs afin de pouvoir collecter les valeurs de propriétés modifiées. Le résultat de cette étape produit un différentiel entre les valeurs du système pré et post-évolution. À partir de ce différentiel, l’analyse vérifie les contrats de QoS afin de détecter une potentielle violation. Nous présentons dans la suite le comportement de l’analyse de l’évolution, et expliquons en quoi les contraintes énumérées ci-dessus sont respectées. 8.3.2 Étape 1 : mise à jour du modèle causal L’analyse de l’évolution repose sur un parcours du modèle causal, afin de déterminer quels éléments seront affectés. Pour cela, il est nécessaire d’établir l’hypothétique modèle causal du système, en considérant que l’évolution a déjà eu lieue, afin de pouvoir en analyser les effets. La première étape de l’analyse consiste à mettre à jour le modèle causal pour obtenir les causalités du système post-évolution. Il s’agit d’une étape cruciale, car c’est elle qui garantit l’exactitude du modèle causal, permettant par la suite à l’analyse de l’évolution de produire un résultat précis. La mise à jour du modèle causal se résume par une mise à jour de ses nœuds et de ses relations causales. Cette étape se réalise en deux temps : d’un point de vue fonctionnel, où Smile traduit les opérations d’évolution en opérations de modification du modèle causal, et d’un point de vue qualité de service, où Smile déduit de la mise à jour fonctionnelle et de la description des propriétés les différentes relations causales de qualité de service La Figure 8.4 est une représentation schématique du processus de mise à jour. Cette étape prend en entrée la description des propriétés de QoS, l’évolution à appliquer, et le modèle causal du système. En sortie, nous trouvons un modèle causal futur, tel qu’il serait si l’évolution était appliquée. En supplément, l’étape de mise à jour retourne également un ensemble d’éléments constituant les éléments explicitement affectés par l’évolution. C’est à partir de cette liste que l’étape d’analyse causale détermine quels autres éléments du système sont indirectement affectés par l’évolution. Pour effectuer le traitement attendu, la mise à jour du modèle causal s’effectue en trois sous-étapes : 898.3. Spécification de l’analyse de l’évolution 1- Mise à jour fonctionnelle 2 - Mise à jour QoS 0 - Sauvegarde du Modèle Causal 3 - Collecte des éléments racines Copie du Modèle Causal Évolution Modèle Causal Modèle Causal modifié Modèle Causal futur Set Description Propriété Actions sur le Modèle Causal 1 - Mise à jour du Modèle Causal Actions sur le Modèle Causal Figure 8.4 – Traduction de l’évolution en actions sur le modèle causal. Table 8.2 – Correspondance entre opérations d’évolution et actions du modèle causal. Opération d’évolution Action(s) sur les nœuds Action(s) sur les relations addActivity(act) addNode(act) – delActivity(act) delNode(act) ∀var ∈ input(act), delCausalRel(var,act) ∧ ∀var ∈ output(act), delCausalRel(act,var) addVariable(var) addNode(var) – delVariable(var) delNode(var) – addInPar(act,var,pos) – addCausalRel(var,act) delInPar(act,var) – delCausalRel(act,var) addOutPar(act,var,pos) – addCausalRel(act,var) delOutPar(act,var) – delCausalRel(var,act) addRelation(act,act2) – – delRelation(act,act2) – – 1 - Mise à jour fonctionnelle : la mise à jour fonctionnelle du modèle causal consiste à ajouter/supprimer les nœuds modifiés par l’évolution, et à ajouter/supprimer les relations causales sous-jacentes. Cette étape est nécessaire car elle permet d’avoir un modèle causal reflétant le système une fois que l’évolution a été appliquée. La mise à jour des nœuds du modèle causal consiste à identifier au sein de la description de l’évolution les éléments du système ajoutés ou supprimés. Pour cela, Smile traduit les opérations de l’évolution modifiant la structure du système en actions à effectuer sur le modèle causal. Nous avons défini une correspondance entre les différentes opérations du langage d’évolution, et les actions à effectuer sur le modèle causal, consignée dans la Table 8.2. Cette correspondance est valable pour n’importe quelle évolution. À titre d’illustration, nous établissons la correspondance entre les opérations d’évolution utilisées dans l’évolution de PicWeb et les actions effectuées sur son modèle causal dans la Table 8.3 (écrites en bleu). Ici, nous ajoutons simplement deux nœuds pour les variables PicsPicasa et PicsFlickr et deux nœuds pour les activités Flickr et Join. 908.3. Spécification de l’analyse de l’évolution 1 Evolution{ 2 addVariable ( Pi c s Pi c a s a ) 3 delOutParameter ( a2 , Pi c s ) 4 addOutParameter( a2 , Pi c s Pi c a s a ) 5 6 addVariable ( P i c s F l i c k r ) 7 addActivity ( a22 , F l i c k r ) 8 addInParameter ( a22 , Tag ) 9 addOutParameter( a22 , P i c s F l i c k r ) 10 11 addActivity ( a23 , j o i n ) 12 addInParameter ( a23 , Pi c s Pi c a s a ) 13 addInParameter ( a23 , P i c s F l i c k r ) 14 addOutParameter( a23 , Pi c s ) 15 16 addRelation( r e c ei v e , a22 ) 17 addRelation( a22 , a23 ) 18 addRelation( a23 , a3 ) 19 addRelation( a2 , a23 ) 20 delRelation ( a3 , a2 ) 21 } CausalEvolution{ addNode( Pi c s Pi c a s a ) delCausalRel ( a2 , Pi c s ) addCausalRel ( a2 , Pi c s Pi c a s a ) addNode( P i c s F l i c k r ) addNode( F l i c k r ) addCausalRel ( tag , a22 ) addCausalRel ( a22 , P i c s F l i c k r ) addNode( j o i n ) addCausalRel ( Pi c s Pi c a s a , a23 ) addCausalRel ( Pi c s Fli c k r , a23 ) addCausalRel ( a23 , Pi c s ) −− −− −− −− −− } Table 8.3 – Génération de la mise à jour du modèle causal de PicWeb. De manière similaire à la construction initiale du modèle causal (voir chapitre 6), la mise à jour des relations causales fonctionnelles s’effectue en appliquant les règles causales fonctionnelles sur les nouveaux éléments de l’évolution. À titre d’exemple, nous considérons les règles causales introduites dans le chapitre 7. L’application de ces règles sur les éléments manipulés au cours de l’évolution permet de reconstruire les relations causales manquantes. Pour cela, nous avons établi la correspondance entre les opérations d’évolution et les actions sur le modèle causal du point de vue de la construction des relations causales fonctionnelles. Cette correspondance est décrite dans la Table 8.2 : elle permet de générer pour l’évolution de PicWeb la mise à jour décrite dans la partie droite de la Table 8.3 (écrite en rouge). 2 - Mise à jour de la QoS : de manière similaire, la mise à jour du modèle causal d’un point de vue qualité de service consiste à introduire les nouvelles valeurs de propriétés et les nouvelles relations causales de QoS. Compte tenu de sa similitude avec l’étape de mise à jour fonctionnelle, nous décrivons brièvement cette étape : ici, il s’agit dans un premier temps d’assurer la cohérence du modèle, en ajoutant ou en supprimant les PropertyValues correspondant aux modifications effectuées du point de vue fonctionnel. Par exemple, si une nouvelle activité est ajoutée, il s’agit d’ajouter également dans le modèle causal l’ensemble de ses PropertyValues. Une fois la cohérence retrouvée d’un point de vue structurel, il est nécessaire de construire les nouvelles relations causales propres aux propriétés de QoS étudiées. Cette tâche s’effectue simplement en appliquant de nouveaux les règles causales de QoS déduites, comme présenté dans le chapitre 7. 3 - Collecte des éléments racines : afin de pouvoir établir les conséquences liées à l’évolution, nous avons besoin de déterminer les causes racines [Rooney 2004], qui seront dans ce contexte les éléments fonctionnels directement manipulés par l’évolution. L’étape de collecte des éléments racines analyse chacune des actions effectuées sur le modèle causal. Pour chaque action, la collecte consiste à capturer le ou les éléments du système, facteurs d’influence. Pour cela, nous considérons chacun des quatre types d’opération de mise à jour du modèle causal pour déterminer les éléments-causes racines de l’effet de l’évolution. La recherche des éléments racine est réalisée à l’aide de l’opérateur collecte(CausalOperation). Nous décrivons sa spécification pour chacune des opérations de mise à jour du modèle causal 918.3. Spécification de l’analyse de l’évolution Table 8.4 – Description de l’opération collecte. Modèle Causal Description de l’opération de collecte B E D C N collecte(addNode(N)) : l’ajout d’un nœud dans le modèle causal, considéré séparément, n’a d’influence que sur lui-même. En effet, à ce stade, le nœud n’est relié causalement à aucun autre nœud ; le seul élément racine ici est donc N. collecte(addN ode(N)) = N. B E D C N collecte(delNode(N)) : pour la suppression d’un nœud, nous considérons comme pré-condition que l’ensemble des relations causales dont N est la source ou la cible a déjà été supprimé avant d’effectuer la suppression du nœud. Dans cette situation, N n’est lié causalement à aucun autre élément, et ne peut donc pas être une cause racine. Le résultat de collecte(delNode(N)) est donc égal à ∅. B E D C N collecte(addCausalRel(N, B)) : l’ajout d’une relation causale signifie que N a une influence sur B. Toutefois, il existe peut-être d’autres influences provenant de N qui, elles, n’ont pas changé. il s’agit donc de considérer B comme une cause racine. collecte(addCausalRel(N, B)) = B. B E D C N collecte(delCausalRel(N, B)) : la suppression d’une relation entraîne potentiellement la détermination de nouvelles causes racines. En effet, si une relation causale entre N et B est supprimée, cela veut dire que N n’opère plus d’influence sur B. De ce fait, l’état de B libéré de cette influence changera comparé à son état dans la version pré-évolution. Il est donc nécessaire de considérer B comme une cause racine. collecte(delCausalRel(N, B)) = B. dans la Table 8.4. Dans le cas de PicWeb, les différents opérations de mise à jour du modèle causal consignées dans les mises à jour du modèle causal déduites sont analysées pour collecter les causes racines. Cela produit l’ensemble de nœuds . Nous venons de voir comment, à partir de la description d’une évolution, il était possible de mettre à jour le modèle causal. Dans l’étape suivante, il s’agit d’utiliser le modèle causal mis à jour pour déterminer quelles valeurs de propriétés de QoS sont affectées par l’évolution. 8.3.3 Étape 2 : analyse causale L’objectif de cette étape est d’identifier les valeurs de propriétés qu’il est nécessaire de re-vérifier. En utilisant les éléments racines identifiés dans l’étape précédent, l’analyse causale consiste à visiter le modèle causal pour établir l’influence de l’évolution sur le reste du système et sur sa qualité de service. Le modèle causal est parcouru afin de capturer les différents nœuds qui seraient directement ou indirectement affectés. Principe Pour analyser l’effet d’une évolution sur le système, l’analyse causale consiste à effectuer un parcours de graphe, où chaque nœud rencontré est collecté. En effet, nous partons du principe que les éléments racines sont des sources de causalité. Il s’agit donc de considé- rer les éléments liés aux causes racines par une relation causale comme étant influencés. De plus, selon notre définition de la causalité, l’état de ces éléments est potentiellement affecté : de la même manière que pour les éléments racines, ce changement d’état a une influence sur d’autres éléments du système. C’est ce que Judea Pearl appelle l’inférence de causalité [Pearl 2000]. Pour prendre en compte cette influence, l’analyse causale consiste en 928.3. Spécification de l’analyse de l’évolution Variable Keyword Variable PicsPicasa Variable PicsFlickr Variable Pics Variable PicsF Receive Invoke Picasa Invoke Flickr Invoke Helper Invoke Shuffle Reply in in in in in in out out out out out Légende: Relation Causale de paramètre d'entrée in Relation Causale de paramètre de sortie out Élément racine collecté Relation Causale suivie pendant l'analyse causale Élément collecté pendant l'analyse causale Figure 8.5 – Application à PicWeb de l’analyse causale. une clôture transitive des relations causales. En suivant les relations causales partant des éléments-racines, l’analyse causale détermine l’ensemble des éléments affectés par l’évolution. Application à PicWeb Nous illustrons l’application de l’analyse causale à PicWeb en l’observant du point de vue des relations causales fonctionnelles, puis des relations de qualité de service. La Figure 8.5 représente le parcours effectué par l’analyse causale sur la partie fonctionnelle du modèle causal ; l’analyse démarre des éléments cerclés en rouge (causes racines), pour suivre les relations causales représentées en gras, pour identifier une série d’éléments causalement affectés, cerclés en vert. Ici, l’analyse causale détermine donc que l’évolution a impacté les éléments Shuffle, PicsF et Reply. Afin d’illustrer le même principe sur les éléments propres à la qualité de service, nous raisonnons sur une sous-partie du modèle causal, décrite dans la Figure 8.6. Dans cette figure, nous étudions la partie terminale du processus métier, où l’ensemble des éléments fonctionnels présents a été déterminé comme affecté par l’évolution. Ici, l’analyse causale continue son parcours en suivant les relations d’environnement vers les valeurs de propriété de temps de transmission, puis vers les temps de réponse des activités simples par dérivation, et enfin vers la valeur de propriété de temps de réponse de la séquence entière. Nous pouvons souligner que les valeurs de propriétés de temps de transmission n’ont pas été sélectionnées, grâce à la spécialisation des relations causales de QoS. Dans le cas où nous avions limité notre modèle causal aux seuls éléments fonctionnels, il aurait fallu re-contrôler les valeurs de toutes les propriétés. Nous économisons ainsi la re-vérification de certaines valeurs de propriétés, comme le temps de transmission. 8.3.4 Étape 3 : re-vérification L’analyse causale effectuée lors de l’étape précédente a identifié un ensemble d’éléments causalement reliés aux changements opérés par l’évolution. Maintenant que nous savons quels éléments ont été affectés, il est nécessaire de savoir à quelle hauteur le changement 938.3. Spécification de l’analyse de l’évolution Variable Pics Variable PicsF Invoke Shuffle Reply in out in name="ResponseTime" comparator=LowerIsBetter :Property values :PropertyValue :PropertyValue name="ComputationTime" comparator=LowerIsBetter :Property values :Property Value :Property Value name="TransmissionTime" comparator=LowerIsBetter :Property values :Property Value :Property Value der der der der env env Sequence :Property Value agr agr Légende: Relation Causale de paramètre d'entrée in Relation Causale de paramètre de sortie out env Relation Causale d'environnement der Relation Causale de dérivation Relation Causale d'agrégation agr Élément collecté pendant l'analyse causale Relation Causale suivie pendant l'analyse causale Figure 8.6 – Application à PicWeb de l’analyse causale. effectué sur les éléments améliore ou détériore la qualité de service. L’étape de re-vérification a pour rôle de re-déterminer uniquement les valeurs de propriétés affectées, en générant une version outillée du système post-évolution, afin de pouvoir effectuer les analyses, contrôles et calculs nécessaires à l’architecte de l’évolution pour l’obtention de nouvelles valeurs de propriétés. Ces valeurs aideront par la suite à savoir si le système, ayant évolué, continue de respecter ses contrats de qualité de service. 8.3.4.1 Analyses et contrôles ciblés L’objectif de cette partie est de re-vérifier de manière minimale les valeurs de propriété indiquées lors de l’analyse causale, afin de dresser un diagnostic qui servira de base à l’architecte de l’évolution pour prendre une décision quant à l’applicabilité de l’évolution. Nous expliquons dans un premier temps comment les valeurs de propriétés sont re-vérifiées, avant de montrer comment de ces valeurs il est possible de poser un premier diagnostic. Afin de déterminer ces valeurs, le processus de détermination présenté dans le chapitre 7 est ré-utilisé. Nous nous intéressons dans un premier temps à des valeurs de propriétés élémentaires, i.e., des valeurs de propriétés qui ne peuvent être composées ou déduites d’un calcul. Ce sont des valeurs déterminées par analyse ou par contrôle de l’application à l’exécution. La mesure en environnement de test produit un ensemble de données brutes, caractérisant les parties du système suspectées d’avoir changé pour une propriété donnée. De ces données, le challenge est de déterminer leur impact à l’échelle du système. La Figure 8.7 décrit le procédé permettant d’obtenir les instance de PropertyValue. Partant de la liste des éléments affectés, Smile outille le système à l’aide des analyses et des contrôleurs décrits dans la description de la propriété considérée, pour obtenir de nouvelles 948.3. Spécification de l’analyse de l’évolution valeurs. Cette phase est nécessaire pour connaître les nouvelles valeurs de propriétés. Une fois l’outillage effectué, les analyses et les mesures sont effectuées. Si l’outillage est automatisé, la phase de mesures reste manuelle, afin de laisser la possibilité à l’architecte de l’évolution d’exécuter les cas de tests qu’il désire. Le processus de re-vérification consiste à exécuter plusieurs fois une activité afin de prendre plusieurs échantillons de la même mesure. Chacune des exécutions du système produit des mesures, caractérisant la valeur de propriété sur le système évolué. Nous appelons échantillon l’ensemble des mesures effectuées. Cette phase, partiellement outillée, joue un rôle important dans l’analyse d’une évolution. Elle quantifie de quelle manière l’évolution a affecté les éléments pointés par l’analyse causale. Outillage Analyses Mesures en environnement de test Données brutes Figure 8.7 – Obtention des données brutes. 8.3.4.2 Déduction des métriques Les mesures produites lors de la phase de test constituent un ensemble de données. Nous cherchons à caractériser l’évolution, à savoir déterminer si après une évolution, les PropertyValues sont améliorées ou dégradées. Pour cela, notre approche consiste à comparer cet ensemble avec les données pré-évolution, afin de pouvoir caractériser, pour une activité donnée, si l’évolution a amélioré, dégradé ou n’a pas changé la valeur de propriété d’une activité donnée. Pour effectuer cette comparaison, nous préconisons à l’architecte de l’évolution de constituer un ensemble de données post-évolution conséquent, afin d’avoir un échantillon représentatif. Nous cherchons ici non pas à comparer deux valeurs discrètes (pré-et post évolution), mais à comparer deux ensembles de données. Pour cela, nous proposons de caractériser chaque ensemble à l’aide de trois valeurs : le meilleur cas, le pire cas, et la moyenne. Ces trois valeurs correspondent respectivement au maximum, au minimum et à la moyenne de l’ensemble, dans le cas où le maximum représente le meilleur cas. Une fois que ces métriques sont calculées, nous pouvons les comparer avec les mêmes métriques établies pré-évolution en utilisant l’opérateur de comparaison (comparisonType), disponible dans la description de la propriété. Si pour une métrique, la valeur a changé, il est nécessaire de reporter ce changement en continuant de parcourir la chaîne de causalité vers les valeurs de propriété de dérivation et d’aggrégation. 8.3.4.3 Dérivations et agrégations ciblées Si pour une métrique donnée, le différentiel pré-post évolution montre un changement, il est nécessaire de le propager au niveau des valeurs de propriétés dérivées, le cas échéant. 958.4. Résultat de l’analyse et prise de décision Nous nous plaçons dans le cas où la propriété étudiée rentre dans la détermination d’une propriété dérivée, comme c’est le cas pour le temps d’exécution qui rentre dans la détermination du temps de réponse. Pour une activité donnée, si la métrique maximum du temps de calcul a changé, il est nécessaire de re-calculer la métrique maximum du temps de ré- ponse pour la même activité. Il s’agit donc ici de limiter le re-calcul des propriétés dérivées uniquement pour celles dont les sous-propriétés ont changé. À titre d’illustration, le temps maximal de calcul de l’activité Format de PicWeb a changé. Il est donc nécessaire de re-calculer le temps maximal de réponse de la même activité. De manière similaire à la dérivation, l’aggrégation de valeurs de propriétés est influencée par les valeurs des activités prise en compte dans leurs détermination. Par exemple, pour une activité structuré S, contenant les activités A, B et C, il est nécessaire de ré-aggréger la valeur de propriété de S si l’une des valeurs de propriétés de A, B ou C a changé. Pour cela, en suivant les relations causales depuis les activités contenues, nous provoquons le re-calcul de la PropertyValue de S. 8.3.5 Discussion Nous venons de présenter les différentes étapes constituant l’analyse de l’évolution. Ces étapes permettent de répondre aux enjeux à relever : – Minimisation de la re-vérification : notre méthode consiste à identifier le sousensemble du système affecté par l’évolution, et à regrouper l’ensemble des analyses et contrôles des éléments désignés par l’analyse causale. En ré-exécutant uniquement ces vérifications, nous minimisons les déploiements. Notre approche réduit donc le nombre de vérifications à effectuer, comparé à la re-vérification de l’ensemble du système, grâce à l’identification des éléments impactés par l’analyse causale. – Qualification de l’évolution : La politique de différentiel entre le système pré et post-évolution permet d’arrêter les calculs au plus tôt, dès qu’une causalité est détectée comme étant neutre. De plus, les métriques de maximum, minimum et de moyennes établies avant et après l’évolution permettent de quantifier la différence entre les deux versions. Enfin, la chaîne de causalité établie par l’analyse causale renseigne l’architecte de l’évolution en lui donnant un premier élément de diagnostic, dans le cas d’une violation de contrat. 8.4 Résultat de l’analyse et prise de décision Une fois que les nouvelles mesures provenant des contrôleurs ont été récupérées de l’exécution, l’ensemble des informations nécessaires est disponible pour faire un différentiel complet entre l’état de la qualité de service avant et après l’évolution. Il est ainsi maintenant possible de savoir si une évolution a été bénéfique ou néfaste pour une propriété donnée. En cas de dégradation, la détermination ciblée permet de savoir concrètement quelles sont les valeurs qui ont changé, permettant de restreindre le champ d’investigation. Mieux encore, la notion de causalité dans le système permet de poser un premier diagnostic en remontant la chaîne de conséquences. Nous montrons dans cette section comment les contrats de qualité de service peuvent être vérifiés pour voir si aucun d’entre eux n’a été violé. Puis, nous expliquons comment le modèle causal peut aider à déterminer, en cas de dégradation, l’origine de la dégradation en suivant les relations causales dans le sens inverse. Enfin, nous présentons l’ultime étape de l’analyse, laissant à l’architecte le choix de déployer la version évoluée du système, ou de revenir à la version précédente. 968.4. Résultat de l’analyse et prise de décision Dans cette phase, l’analyse cherche avant tout à caractériser si l’évolution est bénéfique, neutre, ou néfaste aux propriétés de qualité de service (voir chapitre 7), et de déterminer si des contrats ont été violés. L’architecte de l’évolution n’aura qu’à prendre connaissance du diagnostic de l’analyse pour savoir si oui ou non l’évolution peut être appliquée de manière effective. 8.4.1 Enjeux L’ultime étape de l’analyse d’évolution fait intervenir l’architecte de l’évolution, afin qu’il prenne la décision finale de savoir si l’évolution doit effectivement être appliquée, ou bien si un retour en arrière doit être effectué. C’est une étape lourde de conséquences où il faut être sûr qu’aucun contrat de qualité de service ne sera violé. Cela entraîne les enjeux suivants : – Disponibilité des informations essentielles : afin de pouvoir prendre la décision d’appliquer ou non l’évolution, l’architecte de l’évolution a besoin de l’ensemble des informations collectées tout au long de l’analyse. Nous devons déterminer quelles informations sont nécessaires afin de l’accompagner dans la phase de diagnostic. – Retour en arrière : Au delà de l’annulation de l’évolution sur le modèle de données et sur le modèle causal, nous devons également nous assurer que la suite du processus, à savoir la conception d’une nouvelle évolution, sera accompagnée du diagnostic de l’itération précédente. Cet élément semble essentiel pour éviter de réaliser les mêmes erreurs lors de la conception de la nouvelle évolution. 8.4.2 Vérification des contrats Afin de garantir le maintien de la qualité de service au fil des évolutions, l’architecte de l’évolution doit s’assurer que les contrats de QoS sont toujours respectés. La détermination des trois métriques à l’échelle du système (effectuée lors de l’étape précédente) permet d’avoir un aperçu de l’état du système pour une propriété donnée. Partant de ces valeurs, il est maintenant possible de se positionner selon les contrats pré-établis. Nous pouvons classer le résultat de la comparaison en quatre catégories : – Meilleur : la moyenne, le maximum et le minimum définis post-évolution sont chacun meilleur que les mêmes métriques pré-évolution. – Pire : la moyenne, le maximum et le minimum définis post-évolution sont chacun moins bons que les mêmes métriques pré-évolution. – Neutre : les valeurs des métriques pré et post-évolution sont identiques. – Différents : cas particuliers pour lesquels une règle générale n’est pas applicable pour chacune des métriques. Pour chacune des quatre catégories, le comportement de l’architecte vis-à-vis de l’évolution sera différent : dans le cas où l’évolution est établie comme étant meilleure, ou neutre, dans l’hypothèse où le contrat de qualité de service était respecté auparavant, nous pouvons dire que le maintien de la qualité de service est garanti pour cette évolution. En effet, si la qualité de service pour une propriété donnée n’a pas changé ou s’est améliorée, le contrat continue d’être respecté. Dans la situation où la valeur de propriété pour le système est pire, il est nécessaire de comparer pour savoir si les conditions du contrat continuent d’être respectées ou non. Finalement, dans la situation où la valeur de propriété est différente, il est nécessaire de vérifier au cas par cas si les contrats sont toujours respectés, et d’isoler les cas où une violation est détectée. 978.4. Résultat de l’analyse et prise de décision Application à PicWeb Dans le cas de PicWeb, le contrat établi pour la propriété du temps de réponse ne caractérise que le pire temps. La Figure 8.8 est une partie de notre modèle représentant ce contrat. Ici, le processus métier ne doit pas voir son temps d’exécution dépasser les cinq secondes. Ici, en comparant la nouvelle valeur de propriété de PicWeb avec la valeur de contrat, nous pouvons nous rendre compte que le contrat a été violé. name="ResponseTime" comparator=LowerIsBetter :Property type = "Worst" value = "5000" :Contract value = 9217 VersionNumber=2 :PropertyValue name = PicWeb :Process Figure 8.8 – Contrat de QoS qualifiant le temps de réponse de PicWeb. 8.4.3 Détermination des causes racines De prime abord, si la cause d’une dégradation est bien évidemment l’évolution, il est plus complexe de savoir exactement pourquoi un contrat a été violé. En effet, l’évolution est constituée de plusieurs opérations. Restreindre la cause de la dégradation à une seule opération permettrait de faciliter le diagnostic. Notre approche permet toutefois à l’architecte de l’évolution d’obtenir plus d’informations : la violation d’un contrat est détectée sur une valeur de propriété, qui a été déclarée par l’analyse causale comme étant modi- fiée : cette PropertyValue a été détectée au cours du parcours du modèle causal comme étant potentiellement affectée. Il existe donc une chaîne de causalité reliant un des nœuds de l’évolution à la PropertyValue. La chaîne de causalité explique comment d’un nœud de l’évolution, différentes causalités ont été établies pour mener à la violation d’un contrat par la PropertyValue. Cette information est une aide pour l’architecte de l’évolution, dans son investigation visant à comprendre pourquoi un contrat a été violé. Par la chaîne causale, nous aidons l’architecte à poser un premier diagnostic. Nous proposons dans Smile une méthode permettant de réduire par comparaison de valeurs les causes possibles. Pour cela, notre approche consiste à démarrer de la PropertyValue correspondant au contrat violé, et de remonter successivement les relations causales ayant servi à construire l’ensemble des éléments affectés. Pour chaque PropertyValue rencontrée, deux cas sont à envisager : – la PropertyValue qualifie un élément du système existant dans la version précédente : dans ce cas là, il est possible de comparer la valeur actuelle avec la valeur déterminée avant que l’évolution soit appliquée. Si la valeur s’est dégradée après l’évolution, il s’agit de la considérer comme une cause possible. Dans le cas contraire, nous pouvons l’exclure de l’ensemble des causes racines, ainsi que toutes les propertyValues l’ayant influencée. – la PropertyValue qualifie un élément du système créé par l’évolution : dans cette situation, il n’est pas possible de se comparer avec une valeur précédente. Smile considère donc cette valeur comme une cause potentielle. Application à PicWeb Afin de déterminer la cause de la violation du contrat de PicWeb, appliquons notre approche au modèle causal établi. La Figure 8.9 représente le parcours inverse de notre 988.4. Résultat de l’analyse et prise de décision modèle causal. Nous pouvons ici distinguer quatre cas : – Cas 1 : lorsque l’analyse de causes racines traite la PropertyValue liée à la séquence, la comparaison avec la version précédente montre que la QoS s’est détériorée. En conséquence, l’analyse se poursuit en suivant en sens inverse les relations causales d’agrégation. – Cas 2 : ici, la PropertyValue liée à l’activité structurante flow a été créée par l’évolution. En conséquence, aucune comparaison n’est possible. L’analyse identifie cet élément comme étant une cause potentielle, et poursuit son analyse en suivant la relation causale d’agrégation vers le temps de réponse de l’activité Flickr. – Cas 3 : lorsque l’analyse traite la PropertyValue de Shuffle, la comparaison détecte une dégradation du temps de calcul. De plus, cet élément est la dernière PropertyValue avant de raisonner du point de vue du fonctionnement du système. Celle-ci est identifiée comme étant une cause racine. – Cas 4 : au niveau de l’activité reply, la comparaison des PropertyValues pour le temps de réponse montre qu’il n’y a pas de dégradation une fois l’évolution appliquée. En conséquence, l’élément n’est pas identifié comme une cause racine de la violation du contrat. Au final, le modèle causal de PicWeb est constitué de vingt et une PropertyValues qui, dans une hypothèse pessimiste, auraient toutes dues être re-vérifiées. La méthode que nous avons employée re-vérifie quinze PropertyValues, et désigne neuf potentielles causes racines réparties sur trois branches. 8.4.4 Déploiement et retour en arrière (roll-back) Dans le cas précis où aucun contrat n’a été violé et que l’architecte de l’évolution est satisfait, l’évolution est intégrée à part entière dans le système. Celui-ci est déployé dans les différents serveurs de production. Toutefois, si l’évolution ne convient pas à l’architecte, il est nécessaire de déclencher un retour en arrière. Le modèle du système, le modèle de données des valeurs de propriétés, mais également le modèle causal doivent être restaurés à l’état pré-évolution. Notre politique de sauvegarde des modèles avant l’analyse permet à Smile de restaurer facilement l’état du système, comme si rien ne s’était passé. L’architecte de l’évolution peut alors définir une nouvelle évolution, en utilisant les informations fournies sur le diagnostic pour éviter de commettre la même erreur. Application à PicWeb Suite à la détection de la violation du contrat, l’architecte de l’évolution prend en compte les causes racines de cette violation. Il conçoit alors une nouvelle évolution après avoir effectué un roll-back de PicWeb, évolution pour laquelle l’implémentation de shuffle fut modifier de sorte à ce que le traitement soit parallélisé. Au final, la nouvelle évolution ne violant plus de contrat, elle put être appliqué au système déployé. 8.4.5 Discussion Nous venons de présenter l’interaction finale entre l’architecte de l’évolution et Smile pour prendre la décision de l’applicabilité de l’évolution. Cette interaction s’est soldée par les challenges suivants : 998.4. Résultat de l’analyse et prise de décision Variable Pics Variable PicsF Invoke Shuffle Reply in in out name="ResponseTime" comparator=LowerIsBetter :Property values name="ComputationTime" comparator=LowerIsBetter :Property values der der env env Sequence agr agr Légende: Relation Causale de paramètre d'entrée in Relation Causale de paramètre de sortie out env Relation Causale d'environnement der Relation Causale de dérivation Relation Causale d'agrégation agr Cas de l'analyse de causes racines value = 9217 VersionNumber=2 :PropertyValue Process PicWeb agr value = 19217 VersionNumber=2 :PropertyValue value = 4123 VersionNumber=1 :PropertyValue value = 2143 VersionNumber=1 :PropertyValue value = 12 VersionNumber=1 :PropertyValue value = 12 VersionNumber=1 :PropertyValue value = 1585 VersionNumber=1 :PropertyValue value = 12 VersionNumber=2 :PropertyValue value = 13491 VersionNumber=2 :PropertyValue value = 12858 VersionNumber=2 :PropertyValue value = 12 VersionNumber=2 :PropertyValue Invoke Flickr Invoke Join Variable PicsFlickr Variable PicsPicasa out in in out value = 286 VersionNumber=2 :PropertyValue value = 2109 VersionNumber=2 :PropertyValue der value = 286 VersionNumber=2 :PropertyValue value = 2615 VersionNumber=2 :PropertyValue Flow value = 3154 VersionNumber=2 :PropertyValue agr der agr agr Cas 1 Cas 2 Cas 3 Cas 4 Relation Causale suivi lors de l'analyse de causes racines Figure 8.9 – Détermination des causes racines de la violation du contrat de PicWeb. – Disponibilité des informations essentielles : l’architecte de l’évolution est guidé dans sa prise de décision par les informations fournies par Smile, à savoir la chaîne de causalité incriminée, et le différentiel des PropertyValues. En prenant connaissance de la chaîne de causalité et à l’aide des différentiels entre les métriques pré et post- évolution, l’architecte de l’évolution possède les premiers éléments de réponse quant à une possible violation de contrat. Si ces informations ont besoin d’être interprétées par un humain, la mise en évidence d’un sous-ensemble du système responsable de la violation, et la synthèse des données de contrôle en métriques permet toutefois à l’architecte de comprendre de manière plus aisée les effets de l’évolution sur la QoS que s’il avait du analyser manuellement l’ensemble des données de contrôle du système dans sa globalité. – Retour en arrière : en proposant la possibilité de rétablir l’état du système tel 1008.5. Conclusion du chapitre qu’il était avant l’évolution, Smile assure la cohésion du système à chaque instant du cycle de vie, et permet ainsi à l’architecte de l’évolution de tester facilement des possibilités d’évolution pour satisfaire les nouveaux besoins de l’utilisateur. 8.5 Conclusion du chapitre Ce chapitre a couvert l’ensemble des étapes pour analyser les effets d’une évolution sur la qualité de service d’un système à base de processus métiers. Constitué d’un langage d’évolution, d’un analyse et d’une étape de prise de décision, l’analyse a de nombreuses propriétés. Parmi elles, nous mettons en avant le caractère d’automatisation de l’approche, où la construction du modèle causal et le déploiement d’une version de test pour effectuer des mesures sont totalement automatisés. Notre approche est également remarquable en terme de réduction du nombre de vérification à effectuer : en réduisant le nombre d’éléments du système à re-vérifier, nous améliorons les performances de la phase de vérification, et facilitons le diagnostic avec une quantité de données inférieure à traiter. Enfin, grâce à ces données, nous mettons à disposition de l’architecte de l’évolution une trace de violation de contrats permettant de le guider dans son diagnostic en cas de violation. Toutefois, nous pouvons également identifier un certain nombre de limitations à notre approche. L’analyse de l’évolution est un procédé non-concurrent. En effet, nous avons émis l’hypothèse simplificatrice qu’une seule évolution était appliquée à la fois. Toutefois, dans un éco-système où le système développé est de plus en plus grand, il n’est pas déraisonnable de penser que plusieurs équipes travaillent en parallèle, et peuvent être amenées à faire évoluer le système en même temps. Il faudrait alors pouvoir déterminer des zones d’évolution, afin d’être en mesure de limiter l’aspect séquentiel à cette seule zone. Ainsi, deux évolutions n’opérant pas sur la même partie du système pourraient s’opérer en concurrence. C’est un défi à résoudre dans le futur. De plus, notre approche repose en grande partie sur l’établissement et la mise à jour du modèle causal. Nous avons vu dans les chapitres précédents comment établir le modèle causal. Notre approche considère que le modèle est consistant et exhaustif en termes de relations causales, si l’on considère uniquement celles que nous avons défini. Toutefois, si d’autres relations causales venaient à être déterminées, il s’agirait alors de les intégrer dans notre module d’évolution. Dans le but d’améliorer notre approche, nous préconisons de réfléchir aux possibilités d’évolution concurrentes du système. Une piste supplémentaire serait d’améliorer la fiabilité des relations causales. En effet, notamment au niveau de l’influence des ressources, peu d’informations sont fournies par l’expert en QoS. Il serait intéressant de renforcer la description des propriétés pour obtenir des relations causales plus précises. Enfin, de la phase d’analyse, nous pensons que davantage d’informations pourraient être fournies à l’architecte en cas de violations dans l’optique de l’aider à diagnostiquer les causes d’une violation de contrat. 101Troisième partie ValidationChapitre 9 Mise en œuvre et utilisation de Smile Sommaire 9.1 Réalisation de Smile . . . . . . . . . . . . . . . . . . . . . . . . . . 105 9.1.1 Présentation du canevas . . . . . . . . . . . . . . . . . . . . . . . . . 106 9.1.2 Besoins des utilisateurs de Smile . . . . . . . . . . . . . . . . . . . . 106 9.1.3 Architecture de Smile . . . . . . . . . . . . . . . . . . . . . . . . . . 106 9.2 Smile pour la description du système . . . . . . . . . . . . . . . . 109 9.2.1 Import de système . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 9.2.2 Description des règles causales . . . . . . . . . . . . . . . . . . . . . 111 9.3 Smile pour la qualité de service . . . . . . . . . . . . . . . . . . . 113 9.3.1 Principe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 9.3.2 Description d’une propriété . . . . . . . . . . . . . . . . . . . . . . . 113 9.3.3 Gestion des règles causales de propriété . . . . . . . . . . . . . . . . 114 9.3.4 Collecte des données . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 9.3.5 Description d’un contrat . . . . . . . . . . . . . . . . . . . . . . . . . 116 9.4 Smile pour l’évolution . . . . . . . . . . . . . . . . . . . . . . . . . 117 9.4.1 Description d’une évolution . . . . . . . . . . . . . . . . . . . . . . . 117 9.4.2 Analyse causale de l’évolution . . . . . . . . . . . . . . . . . . . . . . 118 9.4.3 Contrôle à l’exécution . . . . . . . . . . . . . . . . . . . . . . . . . . 119 9.5 Limites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 9.6 Conclusion du chapitre . . . . . . . . . . . . . . . . . . . . . . . . . 120 C e chapitre présente la réalisation du canevas Smile, conçu pour mettre en pratique les différentes contributions de la thèse. L’implémentation du canevas 1 propose les outils nécessaires aux différents acteurs de l’équipe de développement pour réaliser les tâches nécessaires à une évolution contrôlée. Notamment, les langages de description de propriétés de qualité de service et d’évolution sont pris en charge, de même que l’analyse causale de l’évolution. Nous détaillons dans ce chapitre les différents choix technologiques, et présentons les fonctionnalités de Smile pour chacun des acteurs identifiés. 9.1 Réalisation de Smile Dans cette section, nous présentons l’architecture de Smile. Après avoir introduit le contexte du canevas, nous énumérons les besoins des différents utilisateurs, avant de pré- senter l’architecture de Smile et son découpage en plug-ins. 1. disponible à l’adresse https://github.com/smileFramework/SMILE9.1. Réalisation de Smile 9.1.1 Présentation du canevas Le canevas Smile a été conçu dans le but de fournir les outils nécessaires aux différents acteurs de l’équipe de développement, pour suivre la méthodologie Blink. Nous avons cherché à implémenter Smile de façon modulaire, afin de faciliter sa maintenance, et de façon extensible, afin de pouvoir faire évoluer les fonctionnalités présentes. Pour cela, nous avons fait le choix d’étendre une plate-forme existante, Eclipse 2 . Eclipse est un environnement de développement intégré, dont la réalisation a débuté par IBM en 2001. Gérant de nombreux langages de programmation tels que Java ou C++, Eclipse est doté d’un environnement de conception de modèles ainsi que de différents outils propres aux architectures orientées services, tel qu’un éditeur BPEL ou un outil de description d’interfaces WSDL pour les web services. La plate-forme repose sur une construction par plug-ins, rendant possible son extension. Pour toutes ces raisons, Eclipse est devenu un standard de facto, faisant d’elle la plate-forme à notre connaissance la plus adaptée pour le développement de Smile. 9.1.2 Besoins des utilisateurs de Smile Le processus de développement Blink et sa réalisation via Smile ont été pensés pour mettre au centre des préoccupations les trois profils d’acteurs, à savoir (i) l’expert en qualité de service, (ii) l’architecte du système et (iii) l’architecte de l’évolution. Chacun de ces profils ont des besoins spécifiques, besoins devant être satisfaits par une fonctionnalité de Smile. La Figure 9.1 est un diagramme de cas d’utilisation écrit selon le formalisme d’UML. Ce diagramme représente les différents besoins de chaque acteur : – L’architecte du système a pour tâche d’importer ou de modéliser un système, et de déclencher les analyses de QoS du système, afin de vérifier si les contrats sont respectés (voir chapitre 6). Cela pré-requiert que les contrats et les propriétés de QoS aient été préalablement définis par l’expert en QoS. La section 9.2 présente le support de Smile pour l’architecte du système. – L’expert en QoS a pour tâche de gérer la QoS du système. Il doit donc pouvoir modéliser une propriété caractérisant le système, définir des contrats de qualité de service pour le système donné et associer les outils de vérification correspondants (comme décrit dans le chapitre 7). Nous verrons dans la section 9.3 les outils fournis par Smile pour réaliser ces tâches. – L’architecte de l’évolution doit pouvoir définir une évolution en réponse à de nouveaux besoins, analyser les effets de cette évolution sur la qualité de service du système, et vérifier si les contrats sont toujours respectés une fois l’évolution appliquée (voir chapitre 8). La description des fonctionnalités de Smile pour réaliser ses tâches est consignée dans la section 9.4. Nous présentons par la suite l’architecture de Smile, avant de voir comment les besoins des utilisateurs sont réalisés par Smile. 9.1.3 Architecture de Smile Afin de pouvoir faciliter la maintenance et l’évolution du canevas, nous avons pensé notre canevas comme un ensemble de modules, réalisés sous formes de plug-ins dans la plate-forme Eclipse. La Figure 9.2 représente l’architecture de notre canevas, constitué de plusieurs modules dont leur description est consignée dans le tableau Table 9.1. 2. http://www.eclipse.org/ 1069.1. Réalisation de Smile Expert QoS Architecte Système Architecte Évolution Modéliser une propriété Définir le contrat d'une propriété Importer un système Analyser la QoS d'un système Définir une évolution Analyser une évolution Vérifier le respect des contrats de QoS Voir chapitre 7 - Modélisation d'un système à base de processus métiers Voir chapitre 8 - Modélisation de la qualité de service pour l'évolution Voir chapitre 9 - Analyse de l'évolution du logiciel orientée QoS Modéliser un système Figure 9.1 – Diagramme des cas d’utilisation de Smile. Le processus de développement Blink suit les principes des architectures dirigées par les modèles [OMG 2003]. En se basant sur le concept de développement par raffinements successifs, notre processus a été pensé comme une succession d’étapes où chacune a pour tâche d’enrichir le modèle. De façon similaire, l’implémentation de Smile suit la logique de Blink, en présentant le système comme un modèle centralisé, enrichi successivement par les différents acteurs de l’équipe de développement. Pour cela, l’implémentation du canevas repose sur des outils mettant en œuvre l’ingénierie dirigée par les modèles, notamment la librairie Eclipse Modeling Framework (EMF) [Steinberg 2008]. EMF est une bibliothèque qui permet, en partant d’une description d’un méta-modèle, de générer les classes java correspondant à son implémentation. La bibliothèque gère notamment le chargement et l’enregistrement de modèles, et permet de fusionner plusieurs modèles entre eux. La Figure 9.3 est une représentation schématique du flot de données de Smile par rapport aux différents utilisateurs. Chacun des trois profils interagit avec le canevas, pour enrichir le modèle de l’application développé avec leurs connaissances propres. L’expert en 1079.1. Réalisation de Smile SmileCore SmileGUI SmileImporter SmileCausalModel Handler SmileEvolution Engine SmileQoSHandler SmileDeployer SmileEvolution Analysis A B Légende: Le plug-in A a une dépendance au plug-in B Figure 9.2 – Architecture de Smile. Module Description Lignes écrites Lignes générées SmileCore plug-in central, orchestrant l’interaction entre les différents plug-ins 6853 0 SmileGUI gère l’interface graphique du canevas 1355 0 SmileImporter gère l’import des processus métiers écrits en BPEL et des fichiers Composite, en les transposant dans le formalisme de Smile 731 0 SmileQoSHandler gère l’infrastructure liée aux propriétés de qualité de service : description de propriétés et de contrats, déduction des règles causales 537 2808 SmileCausalModelHandler gère la synchronisation entre le système et le modèle causal 258 732 SmileEvolutionEngine applique les opérations d’évolution sur le système étudié 837 0 SmileEvolutionAnalysis analyse les effets de l’évolution sur le système étudié en s’appuyant sur le modèle causal 1162 0 SmileDeployer gère le déploiement du système sur le serveur de test ou sur le serveur de production 291 0 Table 9.1 – Description des fonctionnalités par module. QoS écrit la description d’une propriété, qui est utilisé par le plug-in SmileQoSHandler pour produire les règles causales permettant de construire le modèle causal. L’architecte du système utilise le plug-in SmileImporter pour produire un modèle du système conforme à notre méta-modèle. Ce modèle est alors transformé par le plug-in SmileCausalModelHandler pour produire le modèle causal du système en utilisant les règles causales obtenues précé- demment. Enfin, l’architecte de l’évolution décrit une évolution, qui est appliquée sur le système importé par le plug-in SmileEvolutionEngine. Cette même description de l’évolution est enfin analysée par le plug-in SmileEvolutionAnalysis : en s’appuyant sur le modèle causal du système, le plug-in réalise l’analyse causale de l’évolution, pour produire un rap- 1089.2. Smile pour la description du système port d’analyse contenant les informations sur le maintien de la QoS, à savoir quel contrat a été violé, et quelles causes racines ont engendré cette violation. Expert QoS Architecte du Système Architecte de l'Évolution Description de Propriété Règle Causale Système Modèle Causal du Système