Discussion:Autostabilisation/Article de qualité

Cet article a été promu comme Article de qualité en vertu de ce vote.
Merci de remplacer ce modèle par {{Contestation CdQ}} si le vote est remis en cause.

Article promu au terme du premier tour.

• Bilan : 11 pour, 0 bon article, 1 attendre, 0 autre(s) vote(s).
• Commentaire : au moins 8 votes  Article de qualité et (pour) / (pour bon article attendre) = 91,7% > 90%

Gemini1980 oui ? non ? 24 février 2010 à 00:34 (CET)

Autostabilisation

Proposé par : O_yP·✉ 23 janvier 2010 à 17:53 (CET)

L'article traite de tous les aspects du sujet qui peuvent raisonnablement figurer dans une encyclopédie, avec ce qu'il faut de formalisme tout en se voulant accessible aux non-spécialistes. Le plan commence, exprès, par un exemple d'application concrète traité de façon informelle (suggestion de relecteur), pour ne pas décourager le lecteur que la technique rebute. D'ailleurs, la section Définitions, indispensable pour que l'article soit complet, n'est pas du tout nécessaire pour comprendre le reste. Les illustrations se veulent informatives. Le livre de Dolev, qui fait autorité, est largement utilisé comme source. Après plusieurs relectures, je pense que les critères sont remplis.

Votes

Format : Motivation, signature.

Article de qualité

1.  Article de qualité Proposant. O_yP·✉ 23 janvier 2010 à 18:03 (CET)
2.  Article de qualité Je trouve cet article à la portée de l'ensemble des lecteurs. Gemini1980 oui ? non ? 24 janvier 2010 à 00:42 (CET)
3.  Article de qualité Merci pour cet article accessible (ce qui n'était pas gagné étant donné le sujet) et complet. Lebrouillard (d) 24 janvier 2010 à 00:56 (CET)
4.  Article de qualité Super article sur un sujet pointu ! FR · ✉ 24 janvier 2010 à 13:47 (CET)
5.  Article de qualité. Sujet pointu traité en quelques pages. Références suffisantes. Du bon travail. Cantons-de-l'Est 24 janvier 2010 à 19:22 (CET)
6.  Article de qualité. L'article semble faire le tour du sujet (je ne connais pas le sujet), est illustré de quelques schémas, est bien wikilié, possède introduction claire et brève, et enfin est bien sourcé. Bravo. Freewol (d) 24 janvier 2010 à 19:36 (CET)
7.  Article de qualité Oui. Amqui (d) 26 janvier 2010 à 02:06 (CET)
8.  Article de qualité Très bon travail. J'ai même compris le sujet. Mafiou44 (d) 29 janvier 2010 à 15:17 (CET)
9.  Article de qualité AdQ sur les deux premières sections, bien faites. Pas eu le temps de lire les autres mais je vois que d'autres contributeurs s'y sont attelées et que des modifications ont été faites, donc ça a l'air d'aller aussi. Bonne continuation à O_yP. Philippe Giabbanelli (d) 31 janvier 2010 à 10:57 (CET)
10.  Article de qualité Du bon boulot. Pmpmpm (d) 3 février 2010 à 17:08 (CET)
11.  Article de qualité ---Bserin ^{(Bar des Ailes)} 8 février 2010 à 21:58 (CET)

Attendre

#  Attendre Très satisfaisant en l'état, mais il reste quelques points à travailler, détaillés en discussion. En résoudre la majeure partie, surtout pour la Section 2, devrait permettre le label. Philippe Giabbanelli (d) 24 janvier 2010 à 12:38 (CET) Bon traitement des remarques. Philippe Giabbanelli (d) 31 janvier 2010 à 10:55 (CET)

1.  AttendreVoir discussion Pline (discuter) 20 février 2010 à 19:28 (CET)

Discussions

Toutes les discussions vont ci-dessous.

Lecture de Philippe Giabbanelli

Je suis très content que quelqu'un se soit attelé à ce sujet qui m'intéresse. Les références sont très bien choisies et le plan est clair. Mes suggestions sont résumées comme suit.

1. Références. je préférerai les distinguer par type, tel que je l'ai fait sur l'Hypercube. Ainsi, il me paraîtrait plus clair pour le lecteur de séparer les ouvrages consacrés au sujet, les chapitres, les thèses et les articles (conférence et journaux). Au final, cela ferait quatre groupes. Au niveau de la référence nommée "EE 382 N Vijay Garg Spring 2010", il vaudrait mieux la remplacer par le titre effectif de la page, qui est "EE 382N: Distributed Systems Syllabus". La référence "The soldier helmet that pinpoints enemy snipers" devrait être accompagnée de son auteur et magazine, soit David Greig et gizmag, respectivement.
2. Section 1. J'ai fait quelques modifications. « dans un biotope afin d'observer des animaux sans les perturber[5] [...] Ceci peut servir, par exemple, à observer des animaux sauvages sans risquer de perturber leur comportement[13],[14 » : ces deux phrases devraient être regroupées. Je suggèrerai de supprimer la première et de rajouter la référence [5] à la seconde. « Il existe également des réseaux de capteurs mobiles » : rien ne permet de comprendre au lecteur que les capteurs considérés dans les sections précédentes sont fixes. Les exemples d'algorithmes donnés sont ils pour des capteurs fixes ou mobiles ? « avec[15] et sans station de base[16 » : pour mieux comprendre ce que la présence de la station implique au niveau algorithmique, a-t-on dans [15] un cas où les capteurs envoient leurs informations à la base qui les renverra vers les capteurs (i.e., centralisé) ? « Cette problématique rejoint celle des protocoles de populations » : il faudrait peut être clairement exposer la problématique dont on parle en début du paragraphe.
3. Section 2. « Chaque processus est un automate défini en fonction de l'algorithme considéré muni de variables dans lesquelles sont enregistrées les informations que possède le processus. » : un automate muni de variables dans lequel on enregistre des informations, est-ce à dire un automate à pile ? Caractériser l'automate apparaît comme important afin de comprendre la classe de complexité dans laquelle il se situe. « La configuration du système est la collection de l'état de tous les processus et moyens de communication. » : j'aurai plutôt dit l'ensemble des états, mais je n'en suis pas certain. Dans l'ensemble, la section Modèle est très générale puisqu'elle ne fait que décrire brièvement deux formalismes pour des processus distribués. A noter que cette section ne possède pas la moindre référence, alors que ces formalismes sont, sommes toutes, classiques. Pour des références, j'ai donné quelques présentations sur le formalisme de systèmes concurrents et on peut piocher dedans. Sur les modèles vraiment formels, je citerai J. C. M. Beaten, A brief history of Process Algebra, Theoretical Computer Science, volume 335, 2005, ainsi sur ce livre. L'auteur de l'article wiki a choisit de mettre l'accent sur les automates plutôt que l'algèbre, et ça se défend dans ce cadre. Un excellent papier à citer serait donc Luca de Alfaro et Thomas A. Henzinger, Interface-based Design, Engineering Theories of Software-intensive Systems, Springer 2005. « Cet ensemble peut en théorie être quelconque. En pratique, on le choisit afin qu'il représente les exécutions dans lesquelles le système se comporte correctement. » : drôle de phrase. Je remplacerai ça par "d'exécutions dans lesquelles le système de comportement correctement légitimes. Ces exécutions sont appelées légitimes". Je rajouterai la phrase suivante à la fin de ce paragraphe : "Autrement dit, un système est autostabilisant si, quel que soit son état lorsqu'il démarre et l'exécution qui s'ensuit, son comportement est correct". Le problème jusque là est que l'effort est entièrement sur une compréhension informelle du sujet et qu'il n'y a aucune notation. Si on pouvait écrire formellement ce qu'est une exécution, alors cela rendrait le sujet plus clair. « À la suite de tout incident qui change l'état du système, l'autostabilisation assure de retrouver automatiquement, après un certain temps de fonctionnement sans erreur, une exécution légitime, et donc un fonctionnement correct. » : cette phrase n'est pas claire. Par exemple, la différence n'est pas évidente entre un fonctionnement sans erreur et un fonctionnement correct. De plus, une exécution légitime est définie comme un fonctionnement correct, tandis que cette phrase ferait du second une conséquence du premier. Tolérer une défaillance transitoire n'est pas du tout indiqué par le formalisme de la section Autostabilisation : il faut introduire des variables correspondants à une étape pour dire qu'il existe une étape à partir de laquelle le système est clôt dans L. « mémoire en lecture seule » : pourquoi ne pas l'appeler mémoire morte, surtout par opposition à la mémoire vive citée plus tôt ? « Une autre possibilité est de réaliser directement le programme sous forme de circuit intégré. » : ça se fait, ça ? Exemple ?
4. Section 3. L'anneau à jeton de Dijkstra est certes un bon exemple historique, mais sa place dans l'article me paraît très exagérée. Un article séparé et un résumé serait préférable, pour présenter davantage d'algorithmes ou au moins une variété dont les méthodes de construction ont un intérêt pédagogique.

Vais manger. Philippe Giabbanelli (d) 24 janvier 2010 à 12:37 (CET)

Voilà des remarques abondantes. Je me repenche dessus ce soir. Rapidement : grouper les références ne me dérange pas, OK pour compléter celles qui le nécessitent et clarifier les phrases sur les réseaux de capteurs. Pour le modèle, j'ai repris celui de Dolev, qui est effectivement très standard. Après, on peut être très précis sur le rapport entre automates et processus, mais je pense que comme ce n'est pas central pour cet article, il faut rester succint. Ça n'empêche pas de préciser un peu cette section et de renforcer son sourçage, bien sûr. Sur la réalisation d'un programme sous forme de circuit intégré, en pratique on utiliserait plutôt un circuit logique programmable, de nos jours qu'est-ce que ça coûte…

Sur l'anneau à jeton, je lui ai dédié pas mal de place exprès, essentiellement parce qu'il est à la fois historiquement important et très simple. Si le lecteur a une chance de comprendre un algorithme autostabilisant, ce sera celui-là. Je pense donc que le jeu en vaut la chandelle, tu ne crois pas ? O_yP·✉ 24 janvier 2010 à 12:56 (CET)

Concernant l'anneau à jeton, j'ai une approche pédagogique différente, c'est-à-dire que je préfère exposer un ensemble d'algorithmes et montrer plus en détails un voire tout au plus deux points de chacun. Ton approche consiste à faire principalement un algorithme en détail, et je comprend tes motivations, donc pourquoi pas. Philippe Giabbanelli (d) 24 janvier 2010 à 13:58 (CET)

Bon, j'ai commencé, mais ça va prendre quelque temps. Heureusement que la phase de vote dure un mois… O_yP·✉ 25 janvier 2010 à 00:46 (CET)

Bonjour. Je n'ai pas lu toute les suggestions, mais au sujet des références, je ne vois pas l'intérêt de regrouper des références par autre chose que par ouvrage, la section « références » n'étant pas pour moi destinée à être lue en tant que telle. Quelle est votre justification à cela ? (je n'y suis pas du tout opposé, juste curieux). Cordialement, Freewol (d) 24 janvier 2010 à 19:34 (CET)

C'est la façon habituelle de grouper les publications d'une personne. Le sujet n'est pas traité de la même façon selon les types de publication. Les articles de conférence sont court (habituellement 12 pages max en double colonne) et portent le plus souvent sur un algorithme proposé par les auteurs. Les articles de journaux et les chapitres sont plus long, peuvent être une source utile pour aller trouver des références ou se mettre au sujet (surtout s'il s'agit d'un review) si on a pas le temps de lire un livre. Les thèses ont souvent un chapitre d'introduction qui contient également des références. Bref, chacun utilise ces différents supports comme il veut, mais je trouve une certaine utilité à cette organisation. Philippe Giabbanelli (d) 24 janvier 2010 à 20:32 (CET)

(je reviens à la ligne pour plus de clarté)

• Références
• Section 1 J'ai distingué plus clairement entre réseaux de capteurs fixes et mobiles, il ne devrait plus y avoir de confusion possible.
• Section 2 J'ai clarifié là où il le fallait. Concernant le modèle, j'ai rouvert le livre de Dolev, et il n'en dit guère plus, car il n'en a pas besoin dans son livre (or, il connaît très bien le sujet). Du coup, je pense que l'article de WP n'en a pas besoin non plus. En fait, les définitions données sont celles dont on a besoin pour écrire la définition d'autostabilisation, d'où leur pertinence dans l'article. Mais tout ce qui va plus loin, et notamment l'équivalence avec les automates, n'est pas lié à l'autostabilisation mais à l'algorithmique répartie. Ces notions auraient donc leur place dans l'article dédié, actuellement à l'état d'ébauche. Ça me semble d'ailleurs clair quand on considère que ces modèles et leurs équivalences concernent tous les articles de la branche « algorithmique répartie », il ne serait clairement pas désirable de répéter les définitions partout. J'ai donc modifié cette partie pour y inclure ce que met Dolev dans son livre, avec de quoi écrire clairement une exécution pour mieux comprendre la notion d'autostabilisation, et je pense que si on veut en mettre plus, ce n'est pas dans cet article qu'il faut le faire.
• J'ai essayé de tenir compte du reste aussi, dis-moi s'il reste des choses qui te semblent à modifier. O_yP·✉ 29 janvier 2010 à 14:46 (CET)

Remarques de TomT0m

Construction de systèmes autostabilisants

• Introduction : je pense que l'intro mérite d'être réécrites, j'ai pas compris de suite à la lecture que c'était une introduction à la section, par exemple Il est possible en théorie de l'obtenir automatiquement à partir d'un algorithme réparti classique au moyen d'un stabilisateur, (j'attendais une définition d'un stabilisateur sans voir que c'est dans la suite)

OK, je vais voir ça. O_yP·✉ 25 janvier 2010 à 00:46 (CET)

• composition : ça mériterait un lien vers un des articles sur la composition, on parle ici de composition d'algorithme, ça n'apparait pas aussi clairement. On pourrait confectionner un équivalent de bibliothèques de code classique, auto stabilisant, pour la construction de système grâce à ce concept ? Ça existe en pratique ?

Peux-tu préciser de quels articles tu parles ?

Oui, on pourrait se faire une bibliothèque de cette façon. En pratique, ce qu'on trouve, c'est essentiellement des articles (NB : l'autostab n'est pour le moment qu'un sujet théorique) qui disent : pour résoudre notre problème P, on a besoin de résoudre le problème annexe Q pour lequel X a proposé un algorithme, donc l'algorithme qu'on donne par la suite est à composer avec celui de X. Ainsi, on évite de réinventer la roue à chaque fois. O_yP·✉ 25 janvier 2010 à 00:46 (CET)

• Conception d'un matériel autostabilisant faire le lien avec le "problème de l'arrêt", par exemple en algorithmique classique ? Ou encore des techniques de spécifications formelles comme la méthode B ou Coq qui visent à construire des systèmes sûrs, histoire de mettre en contexte un peu plus ? Par ailleurs je ne vois pas clairement en quoi le matériel est visé ici, un processeur ne se bloque pas comme ça dans mon esprit, c'est les programmes qui tournent dessus qui plantent éventuellement. Il s'agit de s'assurer que le processeur n'a pas de "bug" et que dans toutes les situations il exécutera correctement les instructions qu'on lui a donné ? Même chose pour le compilateur, ça ne m'a pas l'air spécifique à l'autostabilisation mais plutôt à l'informatique sure. Il s'agit d'avoir un compilateur dont on a prouvé formellement qu'il transforme le code en respectant la sémantique du programme, et que donc la propriété d'autostabilisation est maintenue (comme n'importe quelle autre propriété du code) ?

Je ne vois pas en quoi il y aurait un lien avec le problème de l'arrêt, peux-tu préciser ? En fait, en pratique, de nombreux processeurs ont des bugs qui permettent bel et bien de les bloquer irrémédiablement (de mémoire, avec certains x86, mettre une valeur trop basse dans RSP et effectuer un PUSH, par exemple). Donc dans les articles sur le matériel / OS / pilotes autostab, le leitmotiv est de trouver des solutions à ce genre de problèmes. Un exemple cité dans l'article est d'ajouter un chien de garde qui remet le système à zéro automatiquement, c'est radical mais le résultat est garanti. O_yP·✉ 25 janvier 2010 à 00:46 (CET)

Pour le problème de l'arrêt, j'ai cité une problématique logicielle classique, mais il y a bien un lien : un logiciel autostabilisant à priori ne s'arrête jamais, mais il doit satisfaire certaines propriétés. Si il part dans une boucle sans s'arrêter mais sans satisfaire ces propriétés, c'est pas bon, et c'est exactement le genre de chose qu'on cherche à détecter lors du problème de l'arrêt. Par exemple le stabilisateur qui enregistre tous les états du système pourrait faire penser à un algo naïf et pas infaillible pour détecter les boucles infinies dans un programme : tu enregistres tous les états du systèmes et tu testes pour savoir si l'état courant a déja été rencontré. Pour l'autostab il faudrait aussi "revenir en arrière" et tester si la séquence qui a mené à ce retour à un état précédent est valide, et dans ce cas ne pas arrêter le programme. Pas si lointain, le rapport, donc. D'un point de vue didactique, voire historique c'est pas forcément inintéressant de faire le rapport : comment se situe l'autostabilisation par rapport à d'autre domaines du génie logiciel (ou informatique/électronique, puisque cet aspect des choses à l'air d'être important aussi) comme la preuve de programme ? Est ce que l'autostabilisation peut être considérée comme une forme de preuve de programme particulière dans laquelle on cherche à montrer la propriété "autostabilisation" ? Je te titille mais c'est moitié par curiosité, moitié pour essayer d'améliorer l'article, et moitié parce que la problématique d'avoir un matériel prouvé, un compilateur prouvé et tout c'est aussi des grosses problématique du GL en recherche, je pense, avec des gens qui bossent sur des réseaux de pétris, des preuves de programmes, des langages de spécification avec preuve de programme et tout.

Je pense que je vois ce que tu veux dire. Un algorithme est autostabilisant si et seulement si on peut lui associer une suite strictement décroissante dans un espace noethérien, ce qui est aussi une façon de démontrer l'arrêt d'un algorithme séquentiel. C'est spécifique à l'autostabilisation, car une telle association n'existe pas pour un algorithme réparti quelconque. C'est prouvé et publié, donc ajoutable à l'article, je vais le faire. Ça répond à ta question ? O_yP·✉ 30 janvier 2010 à 18:08 (CET)

Variantes

• Ceci ne permet pas de définir un ensemble d'exécutions légitimes, car on ne sait rien de la façon dont les processus sont réalisés. : pas compris ce bout de phrase. Si on pense aux maths et à la définition des ensembles par compréhension, c'est à dire par un prédicat, on a un équivalent ici ... Tu parlais d'une définition de l'ensemble en extension (en listant effectivement toutes les configuration sures), précédemment, ou c'est autre chose ? Pareil, je comprends pas trop le "la manière dont les processus sont réalisés" ... on ne connait pas leur code ou leur définition dans ce contextes ? c'est le même genre de processus que ceux de l'anneau de Dijkstra ?

On ne peut définir les exécutions légitimes que sur un système donné, la tâche à résoudre ne suffit pas. Je vais préciser. O_yP·✉ 25 janvier 2010 à 00:46 (CET)

• Dans l'Exemple en quoi l'état A' est différent de l'état A ? Je me doute que quelque chose a changé dans le système à la suite de la perte du message, mais je n'ai qu'une vague idée de ce que ça pourrait être ici, et qu'une vague intuition de la pseudo stabilisation du coup. Est ce qu'on ne pourrait pas définir l'ensemble des états stabilisants comme l'union de A->S->B->T et consors avec A'->S'->B'->T' de manière équivalente dans cet exemple ?

C'est complètement dépendant de l'implémentation. À préciser, donc. O_yP·✉ 25 janvier 2010 à 00:46 (CET)

Dans ce cas je ne comprends pas comment tu peux définir les états, alors. Tu connais un genre de spécification du comportement des processus (genre si je suis dans l'état A et que je pers un message, alors je passe dans l'état A' ?) sans connaître leur implémentation ? sachant que l'état A est une abstraction d'un ensemble d'états "réel" du processus implémenté ? TomT0m (d) 30 janvier 2010 à 12:50 (CET)

• superstabilisation : je crois reconnaître ici le concept d'interruption matérielle familière des programmeurs bas niveau, qui permet de gérer les entrée sortie sans recourir à l'attente active. pendant la convergence je me trompe peut être mais le mot "convergence" n'a pas été expliqué ici. C'est un synonyme de stabilisation ?

Tiens effectivement, je n'ai pas défini convergence. En gros, stabilisation = convergence garantie de rester « convergé ». O_yP·✉ 25 janvier 2010 à 00:46 (CET)

Par ailleurs, est-ce équivalent à avoir un état "stabilisation" dans l'automate des processus, et un arc qui part de n'importe quel état de l'automate vers cet état ?

Ce que tu décris, si on considère l'automate comme celui qui décrit tout le système (produit synchronisé des automates de processus et de canaux), c'est la stabilisation instantanée. O_yP·✉ 25 janvier 2010 à 00:46 (CET)

Donc ce serait plutôt un genre d'automate à pile qui se souviendrait de l'état dans lequel il était avant interruption pour y revenir au besoin après l'interruption ?TomT0m (d) 30 janvier 2010 à 12:50 (CET)

Non non, c'est un algorithme autostabilisant normal (donc sans pile car à état fini) auquel on ajoute une section d'interruption, déclenchée pour tout P en cas d'arrivée ou de départ d'un processus Q voisin de P, et telle que si la configuration est sûre avant l'arrivée ou le départ de Q, alors elle est à nouveau sûre après l'exécution de la section d'interruption. C'est effectivement inspiré des interruptions matérielles. Mais l'historique de l'exécution n'est pas exploité, seule la configuration avant changement et l'info sur le changement lui-même le sont. D'autre part, si la section d'interruption est exécutée à partir d'une configuration non sûre, il n'y a aucune garantie. O_yP·✉ 30 janvier 2010 à 18:08 (CET)

TomT0m (d) 24 janvier 2010 à 21:32 (CET)

OK, merci pour toutes ces remarques, il va me falloir du temps pour en tenir compte… O_yP·✉ 25 janvier 2010 à 00:46 (CET)

Je pense que ça devrait aller maintenant. O_yP·✉ 29 janvier 2010 à 14:46 (CET)

Remarques de Pline

• L'introduction n'est pas un modèle de clarté. L'introduction de la version anglaise, outre qu'elle replace le sujet dans un contexte plus vaste, est bien plus lisible.

L'article anglais souligne la capacité d'un tel système à démarrer en étant en erreur puis à revenir dans un état nominal ce qui le distingue d'un système à tolérance de panne. Est que ce n'est pas à une caractéristique à mette en exergue ?

• Démarrer le corps de l'article pas un exemple avant de poser les concepts n'est pas très orthodoxe.
• L'exposé du concept qui suit utilise des concepts dont il ne fournit pas les définitions (processus, registre). Les grands principes ne sont pas d'une complexité telle qu'ils ne puissent être expliquées en termes simples. Me semble t'il. Pline (discuter) 20 février 2010 à 19:28 (CET)

L'intro de l'article anglais te semble peut-être plus claire, mais je ne suis pas sûr que ce soit pour les bonnes raisons. Par exemple, Self-stabilization is considered a highly desirable property est non neutre. J'ai rencontré plein de spécialistes des systèmes répartis, et beaucoup d'entre eux « croient » en d'autres approches, pas en l'autostabilisation (je leur pardonne : il y en a bien qui admettent l'axiome du choix, alors… ). J'ai ajouté le fait que la perturbation peut être une mauvaise initialisation, ce qui aurait dû s'y trouver dès le départ.

L'exemple avant le reste est fait exprès pour rendre l'article plus accessible, j'en parle d'ailleurs dans la proposition, en haut de la page. Voir aussi la page de discussion de l'article. Du reste, commencer par un exemple est habituel quand on veut vulgariser ; si je suis le plan « académique » définition-théorème-preuve, le résultat sera à peu près imbitable et je suis bien placé pour le savoir.

Quant à savoir ce qu'il faut définir, c'est un marronnier. Faut-il définir processus, registre, algorithme, réseau ? La question se pose dans tous les articles qui dépendent d'autres articles, autant dire tous. Je suis ouvert aux avis… 0_ЧⱣ·✉ 20 février 2010 à 23:08 (CET)

Ma critique découle du label visé. L'intro anglaise n'est pas parfaite (l'article n'est ni AdQ ni BA) mais elle fait passer beaucoup d'informations importantes dans un langage clair. Il y a deux étapes dans la réalisation d'un article technique : exposer les choses de manière juste, puis revoir sa copie pour en faire quelque chose de pédagogique (parce qu'on est dans Wikipedia). Pline (discuter) 20 février 2010 à 23:52 (CET)

J'espérais des remarques d'autres participants, mais l'ordonnanceur n'a pas l'air de vouloir les activer. On ne t'a pas attendu pour réfléchir sur ce que tu as dit et le mettre en application, ça se voit en lisant cette page et la pdd de l'article. Un grand nombre de modifications ont rendu l'article plus accessible, mais cet objectif, aussi louable qu'il soit, ne doit pas autoriser l'introduction de choses fausses dans l'article. L'introduction de en:, actuellement, est peut-être plus facile à « comprendre », mais elle est fausse. 0_ЧⱣ·✉ 23 février 2010 à 11:58 (CET)