Spécifications de la plateforme Les Fûts
Sommaire

Spécifications de la plateforme Les Fûts 	[À METTRE À JOUR : TOUCHE "F9"]  
Chapitre 1. Expérience utilisateur 	[À METTRE À JOUR : TOUCHE "F9"]  
Chapitre 2. Concepts 	[À METTRE À JOUR : TOUCHE "F9"]  
Chapitre 3. Architecture 	[À METTRE À JOUR : TOUCHE "F9"]  
Chapitre 4. Version 1.0 	[À METTRE À JOUR : TOUCHE "F9"]  
Glossaire 	[À METTRE À JOUR : TOUCHE "F9"]  
Index 	[À METTRE À JOUR : TOUCHE "F9"]  
Spécifications de la plateforme Les Fûts
Résumé :
La plateforme web « Les Fûts » est un socle technique de publication de sites web à destination des organisations à but non lucratif, de type associations françaises loi 1901.

« Les Fûts » est un projet à but non lucratif, qui met à disposition auprès d'autres organisations à but non lucratif, de type associations françaises loi 1901, une plateforme technique de publication de sites web.
Chaque association concernée peut demander l'ouverture d'un site web à son nom, site web qui sera géré d'un point de vue technique (mise en place des serveurs, etc.) par les Fûts, et qui sera alimenté et maintenu en termes de contenu par l'association elle-même.
C'est l'association elle-même qui édite ses articles, met en forme ses pages, rajoute ses photos, organise des discussions, etc.
Les Fûts ne s'occupent que de la partie technique.
Les sites associatifs seront dans un premier temps constitués de briques de base très populaires actuellement : blogs, forums, wikis. L'ambition des Fûts est de faciliter l'accès aux technologies répandues dans l'internet grand public, à des petites associations qui n'ont pas forcément le temps ni le budget d'investir directement dans ce domaine.
Chapitre 1. Expérience utilisateur
Résumé :
La plateforme web « Les Fûts » s'adresse à des membres d'associations, qui ne sont pas techniciens et qui n'ont pas forcément l'habitude du web.

Contexte
Pour un utilisateur, un site web associatif distribué par les Fûts s'apparente un site web tout simple, avec des fonctionnalités standard.
De ce point de vue, chaque association a son site web, avec son contenu et ses documents spécifiques, et son apparence à lui.
Cependant, si une personne fait partie de plusieurs associations membres des Fûts, elle peut accéder de façon unique et homogène à toutes les informations de ses associations. Par exemple, la personne pourra avoir sur une même page de type calendrier, les dates des différents événements de ses différentes associations.
Cas d'utilisation de bases
En tout premier lieu, les visiteurs du site doivent au moins être capables de :
·	laisser des commentaires à propos de tout élément du site
·	rechercher des informations sur l'ensemble du site
·	imprimer facilement un élément du site
·	faire un copier/coller d'une URL sur le site, et qu'elle soit encore valide un an après (sous réserve évidemment que l'association ait conservé son site)
·	s'abonner au site, soit par une newsletter, soit par l'intermédiaire des flux RSS, soit en demandant une notification par e-mail de réactions à un message, à un commentaire...

De même, les membres habilités de l'association qui possède le site, doivent au moins être capables de :
·	publier une note courte, suivant le modèle du blog ou du forum
·	ajouter, modifier, gérer, supprimer, des pages, suivant le modèle du wiki
·	attacher des tags aux éléments du site
·	gérer les habilitations des utilisateurs
·	 uploader des documents, des images
·	avoir une page personnalisée, et gérer leurs préférences,

Les personnes qui sont membres de plusieurs associations dont le site est distribué par les Fûts doivent au moins être capables de :
·	disposer d'une page d'accès unique aux sites des différentes associations dont elles sont membres.

Briques de bases
Chaque site distribué par les Fûts doit avoir :
·	une charte graphique,
·	une politique de sécurité,
·	un annuaire des membres,
·	un calendrier,
·	un forum,
·	un blog,
·	un wiki,
·	un moyen public d'envoyer un feedback, ne serait-ce que par l'intermédiaire d'un forum.

Tags
Tous les éléments du site doivent pouvoir être « taggés ».
Un tag est simplement un mot-clef, ou une expression simple, attachés à un élément. Par exemple, tel article peut se voir attaché le mot-clef « vie de l'association », ou encore le mot-clef « ag/2006/06/12 ».
Les membres habilités peuvent poser des tags publics. Ils sont alors visibles par tous.
Si l'association l'a permis, les visiteurs peuvent également poser des tags. Ils sont visibles en tant que propositions de tags, et doivent être confirmés par un membre habilité pour rester en tant que tag définitif.
On peut également poser des tags privés dans son espace personnel. C'est une façon d'organiser son espace.
Tags avancés : en-têtes
Pour la technique, un tag est une méta-donnée, un en-tête attaché à un élément.
En l'occurrence, on propose que ce soit un en-tête de nom « X-Semantic-Tag: ».
Un utilisateur, sous certaines conditions à définir, devrait également être capable d'attacher d'autres en-têtes arbitrairement.
Ainsi, lorsqu'un commentaire est laissé à propos d'un document, l'utilisateur devrait pouvoir décider que le commentaire apparaîtra également dans tel(s) newsgroup(s), en spécifiant un en-tête « Newsgroup: ». Idem pour les « Followup-To: ».
Par ailleurs, il serait bon que les messages (d'un point de vue technique, tout est message dans les Fûts) aient un en-tête qui spécifient leur domaine d'appartenance, leur namespace. On propose « X-Semantic-Namespace: ».
Ainsi, les tags identiques de domaines différents pourraient être définis comme apparentés... ou non. Par exemple, si deux associations utilisent le tag « réunions », on peut décider de les apparenter ou non. Ou si deux associations ont chacune un forum « tournois », on peut décider sur une page d'agrégation de les apparenter ou non.
Noter que les recherches sur mots-clefs doivent pouvoir se faire sur tous les d'en-têtes.
Commentaires
Les commentaires peuvent être laissés à propos de chaque élément du site : articles de blog, pages institutionnelles, images, documents, et évidemment discussions sur un forum.
Tous les caractères sont permis, en particulier les caractères accentués (utilisation d'Unicode). Voir plus bas.
Les commentaires suivent le modèle text only, en vigueur généralement sur Usenet.
Ainsi, la saisie d'un commentaire ne permet pas de grandes fioritures : du texte, un peu de mise en forme (gras, italiques), un peu d'éléments inclus (liens HTTP, FTP ou mailto:), des indentations pour citations, des listes.
Mais : pas d'images, de son, de vidéo.
On peut choisir que le commentaire soit publié en police à chasse fixe.
Annuaire
Les adhérents d'une association doivent être capables de voir la liste des autres adhérents.
Timezones
Les actions sont tracées avec leur date, mais également leur fuseau horaire quand c'est possible.
Dans les vues de dates et d'heures, on présente à l'utilisateur les différences entre fuseaux horaires. Cela permet de mettre en relation temporelle différentes actions tracées, en particulier ce qui concerne le postage d'articles.
On tracera également quand c'est possible la ou les langues utilisées dans les actions (rappelons que toute action est en fait un message), et le pays d'origine de l'action.
Multilinguisme
La plateforme du site des Fûts doit être prévu au moins en français et en anglais.
Les utilisateurs doivent pouvoir publier des articles, des commentaires et des documents, dans n'importe quelle langue, et la spécifier s'ils le désirent.
Pas d'identifiant numérique interne à l'écran
Les identifiants internes de l'application, qu'il s'agisse de personnes, de messages, de groupes, d'articles, de documents... ne doivent pas apparaître à l'écran de l'utilisateur. Surtout s'il s'agit d'identifiants numériques.
En effet, un identifiant numérique peut renseigner sur le nombre total d'éléments stockés, ou sur la séquence de leur création... L'utilisation d'identifiants numériques peut également permettre l'accès « pirate », du moins « aléatoire », à des éléments, puisqu'on peut forger soi-même des URLs.
On préfèrera afficher des identifiants numériques fonctionnels (numéros de chapitres, dates...) et des identifiants texte sans accents (US-ASCII).
Prenons un exemple : un groupe de discussion (ou forum, ou newsgroup, comme vous voulez) qui s'appellerait « Les Fûts, Général ». À l'écran, l'utilisateur voit évidemment le nom « Les Fûts, Général » avec ses accents. Mais dans les URLs, que verra-t-on passer ? Certainement pas des paramètres du genre « ?forum=123 » comme chez phpBB, mais plutôt du genre « ?group=lesfuts », voire carrément pas de paramètre : « /group/lesfuts/ », comme chez Google Groups.
Caractères accentués
Il ne doit y avoir aucun problème de caractères accentués dans l'interface utilisateur (utilisation d'Unicode) :
·	si mon navigateur et mon système d'exploitation me permettent de saisir des accents courants (par exemple, le « e » accent aigu) ou des caractères diacritiques moins courants sur le web (par exemple, le « oe » lié), voire des caractères qui n'ont rien à voir avec la choucroute (par exemple, du coréén), la plateforme doit être capable de stocker mon texte accentué, et de me le restituer exactement comme je l'ai saisi.
·	si mon navigateur et/ou mon système d'exploitation ne me permettent que de saisir certains accents, la plateforme doit être capable de stocker mon texte accentué, et de me le restituer exactement comme je l'ai saisi.
·	si un autre utilisateur a saisi des caractères accentués ou diacritiques trop complexes pour mon navigateur et/ou mon système d'exploitation, j'aurai une limitation à l'affichage, mais cette limitation doit porter sur ces caractères, et non sur l'ensemble de la page ou de l'application.
·	si par malheur (remboursez !) des accents causaient des problèmes majeurs d'affichage sur mon navigateur, je dois être capable par un changement de mes préférences, de passer explicitement dans un mode dégradé, reconnu par l'application.

Back & Reload
L'application doit être robuste au bouton Back, et au bouton. Reload.
Par exemple, si après avoir posté un message, je fais Back, puis de nouveau Publish, l'application doit me prévenir que mon message a déjà été publié et qu'il ne le sera pas une seconde fois.
À moins bien sûr que le contenu du deuxième message soit différent, ou que l'utilisateur souhaite explicitement republier le message quand même.
Les heuristiques sont à étudier.
Messages d'erreurs
Les messages d'erreurs doivent être clairs, et comporter les éléments suivants :
·	 Description de l'erreur. Exemple : « votre article est vide et ne peut donc pas être envoyé ».
·	 Solutions probables. Exemple : « merci de saisir le contenu de votre article ».
·	 Informations de référence. Exemple : ...

Les messages d'erreurs applicatifs doivent être préférés à l'apparition à l'écran de messages d'erreurs techniques bloquantes. Par exemple, lorsqu'une demande applicative met du temps à recevoir sa réponse, on peut tomber en timeout applicatif, c'est-à-dire que l'utilisateur a un affichage clair : « votre demande a été prise en compte, mais elle n'a pas encore été traitée. Merci de revenir sur cette page d'ici une minute ». De cette façon le problème de traitement n'est pas bloquant.
Liste de messages publiés
En plus des vues classiques du genre blogs et forums web (phpBB), l'utilisateur a accès aux messages présentés par liste : tous les titres messages, filtrés ou non, présentés sous forme de liste à plat.
C'est une vue complètement évidente, qui permet de regrouper sur un même écran articles, commentaires, etc. et de les classer par auteurs, par dates...
Penser aux blogs, qui donnent une place prépondérante aux articles, et qui relèguent les commentaires à un voire deux clics. La liste à plat complètera le suivi des commentaires.
Penser aux forums web, qui regroupent de façon quasiment obligatoire les messages par discussions. La liste à plat complètera le suivi de l'activité du forum.
Les éléments affichés dans cette liste sont :
·	le type de l'élément : document, article de blog, page de wiki, article de forum, commentaire...
·	le nom de l'auteur, éventuellement tronqué à 40 caractères, dans ce cas on rajoute des points de suspension « ... »
·	la taille du message en lignes, ou en caractères, ou en octets après un encodage en UTF-8
·	la date d'envoi du message, avec une indication de timezone relative lorsqu'il s'agit d'une autre timezone que celle de l'utilisateur qui voit la liste
·	le sujet du message, éventuellement tronqué à 200 caractères, dans ce cas on rajoute des points de suspension « ... »

La pagination de ce type de liste est par défaut de 50 éléments, mais ce nombre peut être modifié par l'utilisateur.
L'affichage peut être filtré en :
·	n'affichant que les messages lus, non lus, cochés, nouveaux,
·	n'affichant que les messages qui sont moins vieux que 7 jours, 14 jours, un mois, 2 mois, 3 mois, 6 mois, un an

La liste peut être triée par :
·	auteur (ignorer les majuscules et minuscules, convertir les signes accentués en ASCII, ne se baser que sur ce qui est affiché/tronqué),
·	date (ramener à GMT),
·	sujet (ignorer les préfixes standard comme « Re: », ignorer les majuscules et minuscules, convertir les signes accentués en ASCII, ne se baser que sur ce qui est affiché/tronqué),
·	enfilade (regroupement préalable des messages en discussions, puis tri par sujet).

Représentations arborescentes des discussions
Lorsque les commentaires sont nombreux, chacun répondant soit à l'élément initiateur (un document, un article...) soit à un autre commentaire, ils forment de véritables discussions.
Ces discussions doivent être représentées sous forme arborescente, pour permettre la visualisation rapide, le tagging et/ou le dépôt dans un kill-file par sous-discussion.
Écrans de consultation
Les écrans de consultation à prévoir pour la v1.0 des Fûts sont :
·	 Page d'accueil. Page d'accueil de blog classique : articles récents, et liens vers les commentaires.
·	 Pages classiques. Les pages classiques sont : le plan du site, la page « à propos », les mentions légales, et un formulaire pour contacter l'équipe.
·	 Archives du blog par mois. 
·	 Archives du blog par année. 
·	 Articles du blog. 
·	 Liste des tags. 
·	 Calendrier. 
·	 Annuaire. 
·	 Liste à plat des messages. 
·	 Liste des forums. 
·	 Articles des forums. 

C'est le même site qui « est » à la fois un blog et un forum. En effet, la vue des messages par liste concerne aussi bien les éléments du blog que du forum. Dans cette perspective, au lieu de prévoir des liens « Vers le blog » et « Vers le forum », prévoir des boutons « Afficher le site en mode blog », « Afficher le site en mode forum ».
·	Un article de blog (et ses commentaires, qui nécessitent un lien en mode blog), peut être directement affiché sous forme de discussion (ses commentaires apparaissent à plat, avec d'autres commentaires sur d'autres articles).
·	Une discussion de forum peut être rattachée à une vue blog en « remontant » vers l'article d'origine. Cliquer sur « Afficher le site en mode blog » positionnerait l'utilisateur sur cet article.

Sur chaque page, on doit avoir les informations sur la session en cours, avec la date en cours, la timezone utilisée, la langue utilisée, le nom de l'utilisateur, les liens vers ses préférences, etc. Ou bien, si l'utilisateur n'est pas encore identifié, des zones de saisies pour qu'ils s'identifie quand il le souhaite. Un m
On doit également avoir une zone de recherche sur chaque page.
La navigation structurelle doit être implémentée de A à Z, avec visualisation de l'emplacement courant sous la forme « A/B/C », ou « A -> B -> C », et présence de liens « Up », « Top », « Prev », « Next », quand c'est pertinent.
Chapitre 2. Concepts
Résumé :
Pour mieux appréhender la plateforme web « Les Fûts », partageons ensemble quelques concepts élémentaires qui fondent l'application.

Utilisateurs et associations
Chaque association a son site spécifique, visible publiquement par tous, en mode « invité ».
Un utilisateur enregistré, c'est-à-dire un membre d'une association chez les Fûts, dispose d'un accès personnalisé au système. Cet accès unique lui permet de naviguer dans les sites de toutes les associations chez les Fûts dont il est membre.
Actions et messages
En général, une action est ce que fait un utilisateur auprès d'un système. Par exemple, l'utilisateur peut publier des messages dans un blog, laisser un commentaire, publier un document, notifier que tel événement va avoir lieu à telle date...
Noter que les actions sont à différencier des tâches de consultation, telles que la lecture, la recherche, le téléchargement de documents depuis le site.
Dans les Fûts, ce sont les messages qui portent les actions, et non les
Lorsque le système permet à un utilisateur d'effectuer une action, en interne l'action est traduite sous forme de message, et ce message est stocké pour mémoire.
Ainsi, les articles de forums, et les commentaires, sont des messages publiés.
Mais tout message n'est pas forcément publié. Par exemple, l'action de créer un nouvel utilisateur, produit bien un message stocké en interne, mais ce message n'est pas publié en tant que tel.
Versioning des objets métier
Les objets métier sont versionnés, et leurs versions antérieures sont accessibles en ligne.
Il y a une réflexion à mener par la suite sur la possibilité de gérer des modifications concurrentes pour un même objet métier. Exemple : depuis un site associatif, on change l'adresse de tel utilisateur, et en parallèle sur un autre site associatif on change son numéro de téléphone. Comment se résout le « conflit » ?
Accès à des informations privées
Chaque site associatif a ses propres données sur son site applicatif.
Mais, en attendant mieux, les données des sites associatifs sont également centralisées sur le serveur métier. Cela pose donc un problème d'hébergement de données privatives.
En particulier, lorsqu'on connaît le niveau de sécurité de la v1.0...
Les conditions d'utilisation devront clairement poser le problème et donner la position des Fûts sur le sujet.
Vie privée
En attendant mieux, les données des sites associatifs sont centralisées sur le serveur métier. Cela pose un problème d'hébergement de données privatives.
En particulier, lorsqu'on connaît le niveau de sécurité de la v1.0...
Les conditions d'utilisation devront clairement poser le problème et donner la position des Fûts sur le sujet.
Mentions légales
Les droits et la responsabilité sur le contenu des sites associatifs doivent appartenir aux associations elles-mêmes.
Le problème, c'est qu'avec le système de centralisation, dans le cas où une erreur de distribution survient, comme par exemple un envoi sur un site associatif de données appartenant à un autre site associatif, il faut que tout existe pour régler le problème.
Donc d'une part il faut régler un problème de non-répudiation : savoir dire en cas de litige que c'est bien telle association qui a écrit tel contenu.
Et d'autre part il faut bétonner les clauses juridiques.
Open source
Le code PHP et l'architecture PHP/MySQL déployés sur les serveurs applicatifs devraient passer en open source, avec une licence non restrictive, de type Apache ou BSD.
Le code Java sur le serveur métier n'a pas de raison de passer en open source.
L'architecture applicative PHP présente des APIs pour être sollicitée par callback par le serveur métier. Ces APIs doivent être publiques, et des exemples d'implémentation, donc en premier chef le code PHP qui est déployé par les Fûts, doivent être disponibles.
Le serveur métier J2EE présente des APIs pour être sollicité par les serveurs applicatifs. Ces APIs doivent être publiques, mais l'implémentation peut rester privée dans un premier temps.
Chapitre 3. Architecture
Résumé :
Le socle technique de la plateforme web « Les Fûts » suit plusieurs lignes directrices.

Couches
La plateforme web « Les Fûts » a une architecture organisée en couches :
·	 Couche Présentation. C'est ce qui est renvoyé à l'utilisateur, ce qu'il voit à travers son navigateur. De l'UTF-8, du HTML 4.01 conforme, de la CSS standard, deux lichettes de JavaScript, emballé c'est pesé.
·	 Couche Applicative. On y gère la session du site courant, l'authentification éventuelle de l'utilisateur, ses préférences. On traite en local les actions de consultation et de recherche, et on pose des demandes pour les actions de créations, modifications et suppressions.
·	 Couche Communication Applicatif/Métier. Les serveurs applicatifs émettent des demandes vers le serveur métier. Le serveur métier distribue des données vers les serveurs applicatifs. Il y a une couche dédiée à cette communication. En particulier, lorsqu'une demande applicative met du temps à recevoir sa réponse, on peut tomber en timeout applicatif, c'est-à-dire que l'utilisateur a un affichage clair : « votre demande a été prise en compte, mais elle n'a pas encore été traitée. Merci de revenir sur cette page d'ici une minute ».
·	 Couche Métier. On y reçoit des demandes d'actions, on les traite, en résolvant au besoin les conflits, et on distribue les résultats vers les serveurs applicatifs concernés.
·	 Couche Données - Cache Applicatif. La couche applicative a besoin de données en local pour la consultation. Ces données sont des extraits des données métier, et sont distribuées par le serveur métier.
·	 Couche Données - Objets Métier. Les données de la couche métier sont centralisées. Les objets métier sont versionnés.
·	 API publique de connexion aux Fûts. Le serveur métier peut être invoqué directement depuis l'extérieur, grâce à une API publique de services web REST.
Côté infrastructure, on distingue les serveurs applicatifs (PHP) du serveur métier (J2EE).
Pour chaque site associatif, le serveur applicatif utilise PHP 4, Sablotron, MySQL 5, chez Free ou équivalent. Il est autonome pour les fonctionnalités de suivis de sessions, de consultation, et de recherche mono-site. Ses données sont préalablement calculées puis distribuées sous forme de cache par le serveur métier. Ce choix garantit des bons temps de réponse et une répartition de charges.
Le serveur métier est partagé par les associations. Il utilise J2EE 1.3, ServiceMix 2.0 et MySQL 5. Il est invoqué à chaque publication, que ce soit une publication d'article complexe ou de simple commentaire. Sa charge est estimée à 10% de l'utilisation globale du système.
La communication entre les deux serveurs se fait à base de protocole REST.
Les couches sont servies de la façon suivante :
·	La couche de présentation est servie par le serveur applicatif.
·	La partie « Consultation » de la couche applicative est servie par le même système que la couche de présentation : PHP 4, Sablotron, MySQL 5, chez Free ou équivalent. Ces données de la couche applicative sont calculées et distribuées sous forme de cache par le Back Office.
·	La partie « Action » de la couche applicative fait l'objet d'une communication asynchrone entre le serveur applicatif et le serveur métier.
·	La couche métier est implémentée en services web.

Sessions
Les sessions applicatives sont gérées en local, par chaque serveur applicatif.
Le timeout par défaut est de 30 minutes d'inactivité.
La gestion du SSO se fait par l'intermédiaire du serveur métier. On considère que la fonctionnalité de SSO est une fonctionnalité métier, car il peut y avoir des problématiques de gestion de conflits, notamment au niveau des habilitations.
Le suivi de sessions doit pouvoir se faire entièrement par URL-rewriting.
L'utilisation de cookies, quand c'est possible, est là à des fins de contrôles, mais pas suivi de sessions. En particulier, lorsqu'une session disparaît de l'URL mais qu'un cookie est présent, on contrôlé qu'il s'agit d'une session qui existe réellement, on émet un log de warning, et on recrée la session dans les URLs. Les heuristiques sont à étudier.
On ne peut pas s'appuyer uniquement sur les cookies, à cause de la fonctionnalité voulue de SSO entre différents serveurs applicatifs, qui sont de simples serveurs Apache/PHP.
Il y a une question de rapprochement des sessions : comme les résolutions de conflits inter-sites se font de façon asynchrone car on passe par le serveur centralisé, un utilisateur pourrait très bien se logger sur deux sites différents, que chaque site lui crée une session, et qu'on s'aperçoive plus tard (le serveur centralisé doit interroger les serveurs applicatifs à intervalles réguliers) qu'il s'agit du même utilisateur, donc qu'on doit fusionner ses deux sessions.
Si une session passée dans l'URL est invalide, l'action demandée est quand même analysée, et si elle est possible (par exemple une consultation publique) on recrée une session, et on lance l'action. Les heuristiques sont à étudier.
Tout utilisateur, enregistré ou simple invité, doit avoir la possibilité de clôre lui-même sa session. Cette action supprime côté serveur applicatif tout ce qui était lié à la session : résultats de recherche, formulaires en cours, etc.
Sécurité
D'un point de vue technique, il n'y a strictement aucune sécurité dans les Fûts v1.0.
En effet, Free ne propose pas le SSL.
En fait, le système d'authentification par un identifiant et un mot de passe, système qui est prévu dès le lancement, ne sert pas à la sécurité (il ne saurait arrêter aucun pirate), mais à l'identification des utilisateurs, et notamment à savoir si tel utilisateur est un administrateur ou non.
Récapitulatif de la sécurité des flux :
·	les requêtes HTTP qui arrivent sur le serveur sont systématiquement analysées, contrôlées, et transformées en objets. On ne déclenche jamais aucune action à partir des requêtes HTTP elles-mêmes. Exemple de ce qu'il ne faut pas faire : construire des requêtes SQL vers la base de données en utilisant les paramètres HTTP sans les encoder.
·	la saisie éventuelle d'un identifiant et d'un mot de passe, produisent un flux HTTP en clair vers le serveur applicatif.
·	les communications des serveurs applicatifs vers le serveur métier (envoi de demandes) se font par des flux HTTP en clair.
·	les communications du serveur métier vers les serveurs applicatifs (distribution de données) se font par des flux HTTP en clair.

Récapitulatif de la sécurité des données :
·	les données soumises à habilitations ne sont pas accessibles par une bête URL. Exemple de ce qu'il ne faut pas faire : lire sur le système de fichiers un fichier dont le nom est dans l'URL.
·	les serveurs applicatifs stockent leurs données en clair sur le système de fichiers et dans une base MySQL.
·	le serveur métier stocke ses données en clair sur le système de fichiers et dans une base MySQL.

Récapitulatif des concepts d'identification et d'habilitations :
·	les utilisateurs peuvent arriver en tant qu'invités, et ils ont alors accès à toutes les parties publiques des sites associatifs. La session est créée dès que le besoin existe. Ces utilisateurs peuvent modifier des préférences minimales, mais celles-ci seront effacées à la fin de la session.
·	les utilisateurs enregistrés peuvent s'identifier. Ils peuvent modifier leurs préférences, et celles-ci seront stockées de manière persistante.
·	selon leurs habilitations, les utilisateurs accèdent à plus ou moins de fonctionnalités.

Respect des standards
Le standard choisi pour le HTML envoyé aux utilisateurs est le « HTML 4.01 Transitional ». En effet, les vieux navigateurs ne comprennent pas le XHTML.
Pour la même raison, CSS 1.0 devrait être suffisant.
Modules internes, modules externes
Les Fûts proposent des fonctionnalités de blogs, de forum, de wiki, le tout mâtiné de SSO.
Dans un premier temps, on propose que les modules suivants soient implémentés de façon monolithique :
·	blog,
·	forum,
·	wiki.

En revanche, les modules suivants doivent dès maintenant être pensés comme découplés de l'infrastructure centralisée des Fûts :
·	serveur d'identités (voir les approches Account Authentication de Google, InfoCard de Microsoft, Project Higgins de IBM et Novell, et surtout OpenID de VeriSign)
·	stockage de documents,
·	stockage d'images (voir l'approche Flickr).

Des services existent, avec des APIs publiques. Autant les utiliser.
Pour le serveur d'identités, j'ai peur qu'il ne faille développer quelque chose soi-même pour commencer, mais ce sera de toute façon minimal. L'important est de penser découplage dès le début.
Chapitre 4. Version 1.0
Résumé :
La plateforme web sortira dans un premier temps en v1.0, une version minimale qui contiendra ou ne contiendra pas certaines fonctionnalités.

Sécurité
Aucune sécurité réelle en v1.0, uniquement de l'identification.
Forums
Dans les forums, les threads ne seront calculés que pour un groupe donné. Ainsi, si une discussion joue à saute-mouton entre plusieurs groupes, soit par cross-posting soit par followup, on calculera plusieurs threads, qui pourront être totalement différents, pour cette discussion : un thread par groupe où elle apparaît.
Images, vidéos, sons
En v1.0, ça serait bien de pouvoir télécharger des images auprès des sites associatifs, et d'utiliser un module de gestion d'images comme Flickr, mais on n'aura pas les moyens de faire la même chose pour les vidéos ou les MP3.
En tout cas, la fonctionnalité basique de téléchargement de tout type de fichier auprès des sites associatifs, devra exister. C'est la question de la gestion ensuite, qui pose problème.
Glossaire

Membre habilité
Un membre d'une association, connu par le système, et habilité à certaines tâches.
Utilisateur
Tout utilisateur de la partie publique d'un site associatif distribué par les Fûts.
Hébergement
La solution concrète de stockage et de mise à disposition du contenu des sites associatifs. En général, un hébergement chez Free ou équivalent. Les Fûts ne font pas d'hébergement, mais font de la distribution.
Distribution
Les Fûts calculent les données sur un serveur central, puis les distribuent vers les caches locaux des sites associatifs. À distinguer de l'hébergement.
Index

[INDEX À METTRE À JOUR : UTILISEZ LA TOUCHE DE FONCTION "F9"]