Assurance Qualité - IMAGINEimagine.enpc.fr/.../teaching/GenLog/slides/GenLogAssuranceQualite.pdf · Génie logiciel – Assurance Qualité © 2005-2007 Renaud Marlet 14 Liens entre

Génie logiciel – Assurance Qualité © 2005-2007 Renaud Marlet 1

Cours de génie logicielCours de génie logiciel

Assurance QualitéAssurance Qualité

Renaud Marlet

LaBRI / INRIA

http://www.labri.fr/~marlet

(d'après A.-M. Hugues)

màj 23/04/2007


Les deux facettes de la qualitéLes deux facettes de la qualité

● Conformité avec la définition

(contrôlable en cours de fabrication ainsi qu'en maintenance)

● Réponse à l'attente du client

(contrôlable à la livraison principale ainsi que lors des livraisons intermédiaires)


Contrôle qualitéContrôle qualité

Activité tout au long du cycle de vie– plus de 50% des erreurs sont découvertes en phase

d'exploitation– le coût de réparation croît exponentiellement avec

l'avancée dans le cycle de vie


TerminologieTerminologie

● Validation– Faisons-nous le bon produit ?

● Vérification– Faisons-nous le produit correctement ?

☛ Attention, en pratique– souvent confondus, ou pris l'un pour l'autre– on parle de « V&V » (validation et vérification)


Terminologie IEEETerminologie IEEE

● Erreur :– commise par le développeur– conduit à un défaut

● Défaut :– imperfection dans le logiciel– conduit ou non à une panne

● Panne :– comportement anormal d'un programme

Terme courant mais ambigu : bogue (bug)


Qualité : Approche de MacCallQualité : Approche de MacCall

● Caractéristiques « externes »– facteurs de qualité

● Caractéristiques « internes »– critères de qualité

● Caractéristiques mesurables– métriques


Facteurs de qualitéFacteurs de qualité

Facteurs de qualité classés en 3 catégories :– qualités opérationnelles

(product operation)

– facilité à changer ou à corriger (product revision)

– facilité à faire des transitions d'environnement (product transition)


Facteurs de qualité (1) :Facteurs de qualité (1) :Qualités opérationnellesQualités opérationnelles

Conformité aux besoins :● le produit fait-il ce qu'on souhaite ?

Fiabilité :● le fait-il correctement dans tous les cas ?

Efficacité :● utilise-t-il au mieux les ressources matérielles / logicielles ?

Intégrité :● est-il protégé contre les intrusions ?

Facilité d'emploi :● ... au niveau de l'apprentissage, de la mise en œuvre, de la

fourniture des données, de l'interprétation des résultats, etc.


Facteurs de qualité (2) :Facteurs de qualité (2) :Facilité à changer ou à corrigerFacilité à changer ou à corriger

Maintenabilité :● facilité avec laquelle on peut localiser et corriger les

erreurs

Flexibilité :● facilité de modification et d'évolution

Testabilité :● effort requis pour tester (après modification)


Facteurs de qualité (3) : Facilité à Facteurs de qualité (3) : Facilité à faire des transitions d'environnementfaire des transitions d'environnement

Portabilité :● peut-on utiliser le logiciel sur une autre machine ?

Réutilisabilité :● peut-on réutiliser des parties du logiciel dans d'autres

applications ?

Interopérabilité :● facilité d'interfaçage avec d'autres systèmes


Influence des facteurs de qualité Influence des facteurs de qualité les uns sur les autresles uns sur les autres

Ex. facteurs qui diminuent l'efficacité– intégrité (nécessité d'introduire des vérifications)– maintenabilité (sacrifice de l'efficacité pour la lisibilité)– portabilité (moindre efficacité des structures portables)– testabilité, flexibilité, réutilisabilité, interopérabilité, ...

Ex. facteurs qui diminuent l'intégrité– flexibilité, réutilisabilité, interopérabilité


Critères de qualitéCritères de qualité

Opérabilité

Apprentissage

Volume et taux d'E/S

Communicabilité

Contrôle d'accès

Consommation mémoire

Vitesse d'exécution

Traçabilité

Complétude

Cohérence

Tolérance aux fautes

Simplicité

Précision

Modularité

Concision

Auto-description

Instrumentation

Généralité

Evolutivité

Indépendance machine

Indépendance système

Communications banalisés

Données banalisées



Exercice : trouver les (>40) liens entre Exercice : trouver les (>40) liens entre facteurs de qualité et critères de qualitéfacteurs de qualité et critères de qualité

Opérabilité

Apprentissage


Communicabilité

Contrôle d'accès



Traçabilité

Complétude

Cohérence

Simplicité

Précision

Modularité

Concision

Auto-description

Instrumentation

Généralité

Évolutivité





Facilité d'emploi

Intégrité

Efficacité

Conformité

Fiabilité

Maintenabilité

Testabilité

Flexibilité

Portabilité

Réutilisabilité

Interopérabilité

Crit

ères

de

qual

ité(c

arac

téris

tique

s in

tern

es)

Facteurs de qualité

(caractéristiques externes)


Liens entre facteurs de qualité et Liens entre facteurs de qualité et critères de qualitécritères de qualité

Opérabilité

Apprentissage


Communicabilité

Contrôle d'accès



Traçabilité

Complétude

Cohérence


Simplicité

Précision

Modularité

Concision

Auto-description

Instrumentation

Généralité

Évolutivité





Facilité d'emploi

Intégrité

Efficacité

Conformité

Fiabilité

Maintenabilité

Testabilité

Flexibilité

Portabilité

Réutilisabilité

Interopérabilité

QuestionY a-t-il

un critère « majeur » ?

Crit

ères

de

qual

ité(c

arac

téris

tique

s in

tern

es)




Liens entre facteurs de qualité et Liens entre facteurs de qualité et critères de qualitécritères de qualité

Opérabilité

Apprentissage


Communicabilité

Contrôle d'accès



Traçabilité

Complétude

Cohérence


Simplicité

Précision

Modularité

Concision

Auto-description

Instrumentation

Généralité

Évolutivité





Facilité d'emploi

Intégrité

Efficacité

Conformité

Fiabilité

Maintenabilité

Testabilité

Flexibilité

Portabilité

Réutilisabilité

Interopérabilité

☛

Impactfort de la

modularité

Crit

ères

de

qual

ité(c

arac

téris

tique

s in

tern

es)




Métriques associées aux Métriques associées aux critères de qualitécritères de qualité

● Mesure des caractéristiques « internes »– mesures objectives

● ex. : taille, complexité du flot de contrôle, cohésion modulaire / couplage entre modules, ...

● Mesure des caractéristiques « externes »– évaluations stochastiques (statistiques)

● ex. : délai moyen de réponse à une requête, nombre de requêtes simultanées sans « écrouler » un serveur, ...

☛ Ce sont des mesures a posteriori→ arrivent parfois « trop tard »


Exemples de mesures deExemples de mesures decritères de qualité (1)critères de qualité (1)

● Fiabilité :– mesures stochastiques :

● temps moyen de réparation● temps moyen entre deux pannes● taux de disponibilité

● Portabilité :– mesure objective :

● nb d'instructions dépendant de la plate-forme cible


Exemples de mesures deExemples de mesures decritères de qualité (2)critères de qualité (2)

● Facilité d'utilisation :– mesures objectives :

● nb de paramètres ayant une valeur par défaut (pertinente)● nb d'écrans d'aide

– mesures stochastiques :● nb de fausses manipulations par jour● nb de jours d'apprentissage● temps de lecture / interprétation des résultats affichés


MétriquesMétriques

● Métriques– de Halstead, de McCabe, de Henry et Kafura, ..

● Quantités mesurées– concision (taille programme / taille de l'algorithme),

complexité textuelle, difficulté, effort, complexité des liaisons inter-modules (ou -classes), encombrement d'une classe, complexité structurelle, ...

● Implémentées par des outils– Logiscope, ...


Exemple : Métrique de McCabeExemple : Métrique de McCabe

● Analyse du graphe de contrôle● Mesure de la complexité structurelle● Nombre cyclomatique

= nb de noeuds (blocs d'instructions séquentielles)

− nb d'arcs (branches de programme)

+ nb points d'entrée

+ nb points de sortie● Représente le nombre de chemins indépendants

~ nb conditions + 1 (si les décisions sont binaires)


Métrique de McCabe : exempleMétrique de McCabe : exemple

C1

C2 X2

X3X1nb entrées = 1nb sorties = 1nb noeuds (blocs) = 5nb arcs (branches) = 6nb cyclomatique = 6 – 5 + 1 + 1 = 3(nb décisions = 2)


Qualité : comment faire ?Qualité : comment faire ?

Un grand nombre de métriques– difficile de les connaître toutes, et souvent discutables

(vision partielle/artificielle du problème)

L'important, c'est la démarche :– définir un plan qualité adapté au contexte– détailler une mesure des différents critères– s'interroger sur la validité des métriques (pertinence)

Problème des mesures a posteriori– trop tard, mais forge l'expérience (☺)


Assurance qualité et gestion projet (1)Assurance qualité et gestion projet (1)

Le contrôle qualité aide la gestion projet :– mesure de l'avancement– meilleure estimation des coûts


Assurance qualité et gestion projet (2)Assurance qualité et gestion projet (2)

Mais (écueils) :

● dilemme : moins cher ou plus sûr ?– souvent prééminence du planning sur la qualité

● sous-estimation des ressources qui sont nécessaires à l'assurance qualité– par les développeurs (activité jugée marginale)– par les managers (réticence à prévoir un budget

maintenance)


Moyens de l'assurance qualitéMoyens de l'assurance qualité

● Méthodes statiques a priori (sans exécuter le logiciel)– examen critique de documents et de code– analyse automatique (ou assistée) de code / spécification

● analyse statique de programme● vérification de modèle (model checking)● outils de preuves formelles

● Méthodes dynamiques a posteriori (en exécutant le logiciel)– test



● Méthodes statiques a priori (sans exécuter le logiciel)– examen critique de documents et de code– analyse automatique (ou assistée) de code / spécification


● Méthodes dynamiques a posteriori (en exécutant le logiciel)– test


Examen critique de documents (1)Examen critique de documents (1)

● Avoir un point de vue différent de l'auteur

→ quelqu'un d'autre

● Avoir différents points de vue

→ compétences multiples

● Avoir des points de vue objectifs

→ participants hors de l'équipe de développement


Examen critique de documents (2)Examen critique de documents (2)

● Critiquer les aspects techniques, pas l'auteur (!)● Juger la forme

– format [voir cours sur la documentation], structure, satisfaction des normes du plan qualité...

● Juger le fond– précision, non-ambiguïté, complétude, cohérence

(pas de référence imprécise ou inexistante)– conformité par rapport aux documents amont, au

plan projet


Coût des inspectionsCoût des inspections(ordres de grandeur)(ordres de grandeur)

● Cahier des charges 5-10 pages/h● Spécifications fonctionnelles 10 pages/h● Conception globale 5-15 pages/h● Conception détaillé 10 pages/h● Code 20-50 lignes/h

(Selon moi :– effort trop faible dans les phases amont– effort difficile et peu productif dans les phases aval)


Méthodes de relecture (1)Méthodes de relecture (1)

● Auto-correction (desk-checking)– relecture personnelle– bilan : efficacité quasi nulle pour les documents

amont, faible pour le code● Lecture croisée (author-reader cycle)

– un collègue recherche des ambiguïtés, oublis, imprécisions

– bilan : efficacité faible pour les documents amont, plus adapté pour la relecture du code



● Revue (walkthrough)– discussion informelle au sein d'un groupe– un lecteur résume paragraphe par paragraphe– bilan : contribution moyenne à l'assurance qualité

(évaluation très liée à la prestation du lecteur)● Revue structurée

– constitution pendant le débat d'une liste de défauts, utilisation d'une liste de défauts typiques (checklist)

– direction des débats par un secrétaire– bilan : bonne contribution à l'assurance qualité



● Inspection– cadre de relecture plus formel– recherche des défauts avant les débats– suivi des décisions et corrections– bilan : excellente contribution à l'assurance qualité


Méthodes de relecture :Méthodes de relecture :Inspection (1)Inspection (1)

Organisation

1. préparation● recherche des défauts● rédaction d'un rapport de défauts basé sur des fiches type

2. cycle de réunions● examen des défauts● prise de décision

3. suivi● vérification des corrections ou nouvelle inspection



Planification – pour chaque type de document :– dates de début et de fin par rapport au plan projet– critères de sélection des inspecteurs– plan d'inspection (parties à inspecter)– types de défauts les plus communs (checklist)– formulaires d'inspection (description de défauts)– critères de succès de l'inspection

(Ce plan figure en partie dans le plan qualité)



Responsabilités– inspecteurs :

● responsables de la qualité du produit final● responsables du respect des principes de qualité

– auteur :● mise à disposition des documents à la date prévue● fournit une opinion sur chaque défaut signalé

– ...



Responsabilités– ...– secrétaire :

● enregistre les défauts considérés et les décisions prises ● assiste le modérateur

– modérateur :● responsable du bon déroulement des réunions

– convocation, tenue, suspension● veille au maintien des objectifs et aux facteurs humains● préside la prise de décision



● Conséquence– la formalisation oblige à planifier et à observer les

principes de qualité● Bilan

– excellente contribution à l'assurance qualité– amélioration du cycle de vie (contrôle au plus tôt)– influence positive sur la communication et la

formation dans le projet

☛ la meilleure des méthodes de relecture


Et maintenant...Et maintenant...

Quelques exercices d'inspection de code...

(et de correction)


Exercice 1 : trouver 4 erreursExercice 1 : trouver 4 erreurs(Elles sont typiques)(Elles sont typiques)

int factorielle(int n){ int f; while (n >= 0) { n = n-1; f = f*n; } return n;}


Exercice 1 : les 4 erreursExercice 1 : les 4 erreurs(Elles sont typiques)(Elles sont typiques)


● variable f non initialisée (à 1)

● tour de boucle en trop (n = 0)

● opération sur un mauvais indice (n-1 et non n)

● retour d'une mauvaise variable (ici n)


Exercice 1 (suite) : corriger les erreursExercice 1 (suite) : corriger les erreurs


● variable f non initialisée (à 1)

● tour de boucle en trop (n = 0)

● opération sur un mauvais indice (n-1 et non n)

● retour d'une mauvaise variable (ici n)


Exercice 1 (suite) : version corrigéeExercice 1 (suite) : version corrigée

int factorielle(int n){ int f = 1; while (n > 0) { f = f*n; n = n-1; } return f;}

● variable f initialisée (à 1)

● pas de tour de boucle en trop

● opération sur un bon indice (n)

● retour de la variable correcte (f)



.../* Entrée pt cardinal */printf("Direction : ");scanf("%c", direction);switch (direction){ case 'N' : y++; case 'O' : x--; case 'S' : x++;}deplacer(x,y);...



● variable au lieu de pointeur sur variable

● case manquant● break oubliés● copy/paste non

ou mal adapté● default

manquant




● variable au lieu de pointeur sur variable

● case manquant● break oubliés● copy/paste non

ou mal adapté● default

manquant




.../* Entrée pt cardinal */printf("Direction : ");scanf("%c",&direction);switch (direction) { case 'E' : x++; break; case 'N' : y++; break; case 'O' : x--; break; case 'S' : y--; break; default : error();}deplacer(x,y);

● pointeur sur variable

● tous les case présents et corrects

● break présents● pas d'erreur de

copy/paste● default présent



int tab[]; /*de taille size*/int indiceTqTabNul(int size){ int i; if (size > 0) for(i=1; i <= size; i++) if (tab[i] = 0) return i; else printf("tab est vide"); error(); return -1;}



● oubli d'un cas d'indice

● cas d'indice hors borne

● test par = au lieu de ==

● dandling else● accolades

manquantes




● oubli d'un cas d'indice

● cas d'indice hors borne

● test par = au lieu de ==

● dandling else● accolades

manquantes




● pas d'indice oublié

● pas d'indice hors borne

● test par '==' et non '='

● accolades appropriées

int tab[]; /*de taille size*/int indiceTqTabNul(int size){ int i; if (size > 0) { for(i=0; i < size; i++) if (tab[i] == 0) return i; } else { printf("tab est vide"); error(); } return -1;}


Exercice 4 : trouver une erreurExercice 4 : trouver une erreur(Elle est typique)(Elle est typique)

int compte = ...;int decouvert_max = -1000;void transact(int montant)/* débit: montant < 0 * crédit: montant > 0 */{ if (compte + montant < decouvert_max) printf("Refusé"); else compte += montant;}


Exercice 4 : l'erreurExercice 4 : l'erreur(Elle est typique)(Elle est typique)


● overflow non maîtrisé : compte + montant > 231 → compte + montant < 0

● underflow non maîtrisé : si compte=-500 et montant=-231 alors compte + montant > 0 !(= 231-500)


Exercice 4 (suite) : corriger l'erreurExercice 4 (suite) : corriger l'erreur


● overflow non maîtrisé : compte + montant > 231 → compte + montant < 0

● underflow non maîtrisé : si compte=-500 et montant=-231 alors compte + montant > 0 !(= 231-500)



void transact(int montant)

{

if (montant > 0 && compte > 0 && compte+montant < 0)

printf("Overflow");

else if (montant<0 && compte<0 && compte+montant>0)

printf("Underflow");

else if (compte+montant < decouvert_max)

printf("Refusé");

else

compte += montant;

}



/* Si p non nul pointe sur * un entier positif */if (p != NULL & *p >= 0) ...

/* Si x est pair et * de valeur absolue >= 5 */if (x%2 == 0 && x <= -5 || 5 <= x) ...

/* Si x et y sont positifs * ou nuls */if (x && y >= 0) ...



● expression évaluée ne devant pas l'être

● précédence des opérateurs logiques

● comparaison factorisée






● expression évaluée ne devant pas l'être

● précédence des opérateurs logiques

● comparaison factorisée





Exercice 5 : version corrigéeExercice 5 : version corrigée

● expression évaluée que si nécessaire

● parenthésage des opérateurs logiques

● comparaison non factorisée

/* Si p non nul pointe sur * un entier positif */if ((p != NULL) && (*p >= 0)) /* Si x est pair et * de valeur absolue >= 5 */if (x%2 == 0 && (x <= -5 || 5 <= x)) ...

/* Si x et y sont positifs * ou nuls */if (x >= 0 && y >= 0) ...



typedef struct lst { int elem; struct lst *reste;} *list;

int dernierElem(list l){ do { l = l->reste; } while (l->reste != NULL); return l->reste->elem;}



● cas d'un argument pointeur nul (liste vide) non traité

● premier élément non traité (liste à un élément)

● déréférence d'un pointeur nul au terme de l'itération





● cas d'un argument pointeur nul (liste vide) non traité

● premier élément non traité (liste à un élément)

● déréférence d'un pointeur nul au terme de l'itération




Exercice 6 : version corrigéeExercice 6 : version corrigée


int dernierElem(list l){ if (l == NULL) error(); while (l->reste != NULL) l = l->reste; return l->elem;}

● cas d'un argument pointeur nul (liste vide) traité

● premier élément traité correctement

● déréférence du bon pointeur au terme de l'itération


Inspection de code :Inspection de code :Défauts typiques à examiner (1)Défauts typiques à examiner (1)

Référence aux données :– variables non initialisées

☛ savoir si le langage initialise par défaut et quand

☛ dans les cas douteux, initialiser explicitement

– indices de tableaux hors bornes☛ principale source des failles de sécurité (!)

– accès à des structures/records à champs variables ou à des unions



Référence aux données :– confusion entre donnée et pointeur vers la donnée – déréférence de pointeurs nuls– pointeurs sur des données désallouées ou pas

encore allouées– pointeurs sur des données devenues inutiles mais

non libérées



Calculs :– conversions de type (implicites et explicites)– underflow/overflow (dépassement de capacité du type)– division par zéro– précédence des opérateurs

☛ dans le doute (pour la lisibilité), toujours parenthéser



Comparaisons :– incohérence des types

● mélanges d'entiers et de booléens

– inclusion ou non des bornes incorrecte● < au lieu de <=, >= au lieu de >, ...

– inversion du test● == au lieu de !=, > au lieu de <, ...

– confusion en égalité (==) et affectation (=)● if (x = y) {...} au lieu de if (x == y) {...}



Comparaisons :– confusion entre opérateurs binaires (bits) et logiques

● et (&, &&, and), ou (|, ||, or), négation (~, !, not)

– négation incorrecte d'une condition logique● !(x ==1 && (y < 2 || !z)) équiv. x !=1 || (y >= 2 && z)

– précédence des opérateurs booléens● x || y && z équiv. x || (y && z)

☛ dans le doute (pour la lisibilité), toujours parenthéser



Contrôle :– switch

● ensemble de case incomplet● cas default manquant● break oublié

– rattachement du else au if (« dandling else »)1. if (a) if (b) x=0; else x=1;

2. if (a) {if (b) x=0;} else x=1; /* diff. de 1. */

3. if (a) {if (b) x=0; else x=1;} /* idem 1. */



Contrôle :– terminaison du programme

● boucles et récursions sans fin

– boucles● conditions initiales (indices, ...) incorrectes● itérations en plus ou en moins● incohérences après une sortie de boucle anticipée● incohérences après une sortie de boucles emboîtées

– procédures et fonctions● incohérences après une sortie anticipée

– exceptions non rattrapées



● Méthodes statiques a priori(sans exécuter le logiciel)– examen critique de documents et de code– analyse automatique (ou assistée) de code / spécification


● Méthodes dynamiques a posteriori(en exécutant le logiciel)– test


Analyse statique de code (1)Analyse statique de code (1)

● Définition générale :– étude d'un programme (généralement source) sans

exécution● Attention, deux sens pour « analyse statique » :

– inspection manuelle (humaine) du code– outil d'analyse automatique

→ messages d'erreur comme ceux d'un compilateur

● Dans tous les cas– effectuée avant les tests, car élimine des erreurs de

« logique », coûteuses à corriger si découvertes tard



Exemples de propriétés vérifiées :– typage– variables non initialisées– déréférence de pointeurs nuls– débordement de tableaux– fuites mémoire– problèmes d'interopérabilité– problèmes de sécurité : fuite de secrets, ...– ...



● Outils– très high-tech– encore peu répandus

● Réussites– bug d'Ariane 5

● Difficultés– faux positifs (avertissement injustifiés)

erreur certaine

erreur possible

pas d'erreur


Limites théoriques (1)Limites théoriques (1)

● Notion d'indécidabilité– propriété indécidable = qu'on ne pourra jamais prouver

dans le cas général (pas de procédé systématique)

● Exemples de propriétés indécidables– l'exécution d'un programme termine– deux programmes calculent la même chose– un programme n'a pas d'erreur


Limites théoriques (2)Limites théoriques (2)

● Quand un propriété est indécidable, juste dire que c'est possible et laisser l'humain juger

● Erreur possible ≠ outil pas assez puissant

erreur certaine

erreur possible

pas d'erreur







Vérification de modèleVérification de modèle

● Vérification– qu'un état est accessible ou non (vivacité)– qu'un état est accessible en un temps fini (équité)

● Application– programmes pas trop gros (< 10000 LOC)– nécessité de faire des abstractions– 1020 états avec certaines approches, et même plus







Outils de preuves formellesOutils de preuves formelles

● Preuves de– correction (par rapport à une spécification)– terminaison de l'exécution– propriétés spécifiques (sûreté, sécurité, ...)

● Assistants de preuve (theorem prover)– systèmes : Coq, PVS, Isabelle / HOL, ...– encore difficiles d'usage pour des non spécialistes







TestTest

● Vérification (conformité aux spécifications)– tests unitaires– tests d'intégration

● Qualification– validation par rapport aux contraintes non

fonctionnelles● tests de performance● tests de capacité de charge

– validation par rapport aux besoins● bêta-test (chez l'utilisateur final)


TestTest

☛ Voir cours spécifique sur le test


Et au stade de recherche avancée...Et au stade de recherche avancée...

● Génération automatique de programmes à partir des spécifications

→ programmes corrects par construction

● Mais– méthode encore trop mathématique pour le public

des développeurs– problème d'efficacité du code généré– problème de rendement (malgré l'automatisation)

● beaucoup de choses à spécifier avec soin● dilemme bien connu : moins cher ou plus sûr ?


ÀÀ retenir retenir

● Contrôle qualité : durant tout le cycle de vie● L'important, c'est la démarche

– définir un plan qualité adapté au contexte

– détailler les mesures des critères (a posteriori ☹)

– s'interroger sur la pertinence des métriques● Méthodes statiques (sans exécuter) :

– inspection : par des extérieurs, checklist de défauts– analyse automatique (ou assistée) de programme

● Méthodes dynamiques (en exécutant) : test

Documents

Assurance Qualité - IMAGINEimagine.enpc.fr/.../teaching/GenLog/slides/GenLogAssuranceQualite.pdf · Génie logiciel – Assurance Qualité © 2005-2007 Renaud Marlet 14 Liens entre