Brevet FR2832525A1 — publié le 20030523

La présente invention concerne un procédé et un dispositif de constitution et mise à jour de contenus multi-sites Internet. Elle s'applique, en particulier, au développement de nouveaux services Intemet pour les collectivités locales, comprenant une solution clés en main de création et d'entretien de sites web institutionnels. On connaît des services de création et d'entretien de sites. Cependant, chaque mise à jour des données publiées ainsi que les opérations de maintenance du site demandent une intervention individuelle qui pénalise le gestionnaire du site car elle prend du temps et représente des coûts importants, même lorsque les mises à jour sont de même nature pour de nombreux sites. On constate, dans le domaine des sites institutionnels, que les sites Internet des petites et moyennes structures souffrent d'un déficit chronique de mise à jour des informations. En effet, une fois le site réalisé, ces structures ne disposent pas des moyens techniques (ou budgétaires) pour entretenir et actualiser leurs sites web. Une étude réalisée par l'inventeur à ce sujet montre que sur un panel de 250 sites de collectivités locales, 90% des sites n'étaient plus actualisés depuis plus de 6 mois (certains sites annonçant encore les prochaines festivités de l'année passée). Les collectivités locales ne sont pas les seules structures confrontées à cette problématique de mise à jour et d'évolution des sites Internet : toutes les petites et moyennes entreprises, commerces, organismes de service, professions libérales, associations... rencontrent les mêmes difficultés. Historiquement, plusieurs modèles d'architecture de site on été successivement utilisés. 1/Les sites en pages statiques : Le modèle de publication Internet le plus ancien consiste à développer des pages HTML à l'aide d'outils de publication web (frontpage, dreamweaver...). Le seul moyen de mise à jour des pages statique est de re-développer les pages à actualiser et de les publier à nouveau (envoi des pages corrigées par FTP). De nombreuses petites structures ne disposent encore que de sites en pages statiques. Dans ce modèle, chaque site est hébergé par un hébergeur et comporte des pages, généralement décrites en langage HTML qu'il faut éditer pour la maintenance et la mise à jour. Les caractéristiques de ce modèle sont les suivantes : - chaque site web est composé d'un ensemble de pages HTML reliées entre elles par des liens hypertextes, - les pages HTML modifiées remplacent les anciennes pages, - la communication des pages vers le serveur de l'hébergeur est effectuée directement en FTP, - ce modèle est inutilisable par des non-professionnels 2/Sites en pages statiques générées à l'aide d'une boîte à outils. Une variante du modèle précédant a vu le jour avec les outils générateurs de sites spécialisés. Ce modèle de sites en pages statiques générées à l'aide d'une boîte à outils entend répondre à la problématique de mise à jour (et de création) des sites en proposant un outil, on line ou off line, capable de générer et de modifier un site web en quelques clics de souris. Ces outils s'appuient sur la notion de modèles de mise en page (skins) à la disposition des utilisateurs pour créer et modifier leurs sites. Bien que pratique dans son approche, cette démarche ne semble pas correspondre à l'esprit des technologies du web où l'originalité créatrice est essentielle. En outre, les limites de tels outils (car en réalité ils constituent une sur-couche par rapport aux langages de publication professionnels) sont trop importantes pour faire face à l'évolution incessante des normes HTML/XML... et à la prise en compte des traitements transactionnels. Les caractéristiques de ce modèle d'architecture sont les suivantes : - chaque site web est composé d'un ensemble de pages reliées entre elles par des liens hypertextes, - le client a la possibilité de régénérer des pages à actualiser, - les pages modifiées remplacent les anciennes pages, - les possibilités sont limitées au niveau de la charte graphique, du mode de navigation et de la présentation. 3/Le modèle des pages hébergées sur des sites portails spécialisés consiste à héberger des pages descriptives d'entités de même nature au sein d'un portail spécialisé. Ce modèle ne permet pas la publication de sites autonomes avec nom de domaine propre mais présente un intérêt technologique certain, les informations de chaque entité étant dans ce cas stockée dans une même base de données. Les caractéristiques de ce modèle d'architecture sont les suivantes : - le client ne bénéficie pas d'un site web autonome, - les pages descriptives sont conçues selon un même modèle de présentation, - une base de données commune aux différents sites est unique, - le client peut mettre à jour les informations de ses fiches descriptives en temps réel. 4/Les sites en pages dynamiques : Pour permettre une mise à jour récurrente des informations qu'elles présentent, les pages ne sont pas développées en mode statiques HTML, elles sont dites dynamiques car reliées à une base de données. De multiples technologies permettent aujourd'hui de créer des pages dynamiques (Active Server Pages de microsoft, PHP, CGI, Java Server Pages...). Dans ce schéma, les pages du site, la base de données, les formulaires de mise à jour sont développés spécifiquement pour chaque site client : ces sites sont donc coûteux en création initiale comme en maintenance évolutive. Les caractéristiques de ce modèle d'architecture sont les suivantes : - les informations du site peuvent être mises à jour par les clients via des formulaires, - à chaque site web sont associés les formulaires de mise à jour, la base de données et les pages dynamiques, - aucun contenu ne peut être commun entre les sites, même s'ils sont hébergés chez un même hébergeur, - le coût de production et de maintenance d'un site comprend les pages dynamiques, la base de données et les formulaires de mise à jour. Compte tenu des coûts et des compétences qu'elles requièrent, ces réalisations sont aujourd'hui réservées à de grandes structures. L'exposé ci-dessus explique les carences des sites que les inventeurs ont pu constater par le sondage donné plus haut. La présente invention vise à remédier à ces inconvénients. En particulier, la présente invention entend proposer : - la maintenance d'un outil informatique de gestion de contenus élémentaires, réalisée en une seule fois, pour tous les clients, - une évolutivité technique et fonctionnelle de cet outil, - un prix d'acquisition et d'entretien d'un site réduit car mutualisé, - une logique de maintenance contractuelle et mutualisée des sites assurant la pérennité du système d'information. A cet effet, l'homme du métier pourrait penser utiliser le modèle de l'édition de progiciels. Cependant, celui-ci n'est pas applicable au problème de la présente invention pour les deux raisons essentielles suivantes, propres au média web : - contrairement au progiciel, le site Internet n'est pas physiquement installé chez le client (la ville dans notre cas) ni utilisé par lui (l'utilisateur final est en fait l'internaute), - contrairement au progiciel de gestion, le site web requiert une présentation originale, à l'image de l'institution qu'il représente, ainsi qu'un plan de site original (organisation des rubriques, sous-rubriques...). La présente invention vise, selon un premier aspect, un procédé de constitution et mise à jour de contenus de pages d'une pluralité de sites informatiques accessibles par l'intermédiaire d'Internet, à des adresses différentes entre elles sur Internet, caractérisé en ce qu'il comporte : Al une étape de définition de modèle de contenu commun à plusieurs sites, ce contenu commun étant conservé dans une base de données, B/une étape de définition de la structure de la base de données, C/une étape de définition de formulaires communs à tous lesdits sites, chaque formulaire comportant des champs en référence avec la base de données, une partie des champs des formulaires étant en correspondance avec un contenu de la base de données disponible pour tous les sites et une partie des champs des formulaires étant en correspondance avec un contenu spécifique à chaque site et permettant la mise à jour de ce contenu spécifique, DI une étape de constitution d'une application informatique de distribution des formulaires hébergée à une adresse sur Internet indépendante des adresses desdits sites sur Internet, et, pour chaque site : E/une étape de définition des éléments graphiques de présentation de pages dudit site, la présentation étant spécifique audit site, FI une étape de définition de contenu de pages dudit site, en relation avec ladite base de données, G/une première étape de remplissage de contenu spécifique audit site, ledit contenu spécifique étant conservé en base de données, les pages dudit site étant constituées de : a) une partie présentation de pages, spécifique audit site, b) une partie représentative du contenu de champ susceptible d'être mis à jour par utilisation des formulaires, et c) une partie représentative des contenus communs à plusieurs sites ; et, de manière itérative, H/une étape de mise à jour de contenu spécifique audit site, par l'intermédiaire de ladite application informatique et d'au moins un dit formulaire, le contenu spécifique mis à jour étant conservé dans la base de données. Ainsi, la création du site de chaque client est réalisée sur mesure, en ce qui concerne la présentation. La création de chaque site web est originale pour chaque client, chaque site répondant simplement à des impératifs de gestion d'un périmètre potentiel de contenus. On note que le périmètre du système d'information publié (contenus) est connu a priori dès lors que le domaine d'activité est lui-même cerné. Le système objet de la présente invention permet ainsi la dissociation la plus large entre la présentation de l'information (pages du site Internet), qui est propre à chaque site, et la gestion des contenus qui est partagée. Grâce à ces dispositions, des contenus de tous les sites gérés sont conservés dans une même base de données multimédias et sont mis à jour par la mise en oeuvre de mêmes formulaires, et les sites présentent donc un modèle conceptuel de données unique. Ainsi, les formulaires de mise à jour de contenus spécifiques à chaque site sont uniques et partagés (et non développés spécifiquement pour chaque client), ce qui permet leur-évolution et leur maintenance par versions successives et les sites bénéficient d'une partie commune partagée. La maintenance et correction des pages de chaque site est effectuée sur un seul serveur et est immédiatement mis en oeuvre sur ledit site tandis que la maintenance et la correction des champs communs des formulaires est immédiatement mis en oeuvre sur tous les sites reliés à ce serveur et mettant en oeuvre le contenu dudit formulaire De même, les pages sont immédiatement compatibles avec chaque nouveau navigateur, et chaque nouvelle norme (html, javascript...). Selon des caractéristiques exemplaires de l'invention succinctement exposée ci-dessus, au cours de l'étape de mise à jour, l'application informatique hébergée de distribution de formulaires affiche à l'utilisateur la liste des contenus élémentaires publiés sur son site, indépendamment des pages du site qui les contiennent et, lorsque l'utilisateur a sélectionné un contenu de ladite liste, un formulaire de mise à jour du contenu est automatiquement sélectionné. On observe que l'application informatique hébergée fait référence au modèle "Application Services Provider" (pour"fournisseur de services applicatifs"). Grâce à ces dispositions, l'utilisateur accède simplement au formulaire de mise à jour en sélectionnant le contenu qu'il veut mettre à jour. Selon des caractéristiques exemplaires de l'invention succinctement exposée ci-dessus, au cours de l'étape de mise à jour, chaque formulaire est associé à une indication représentative des pages du site mis à jour concernées par les données mises à jour. Grâce à ces dispositions, l'utilisateur qui effectue la mise à jour peut appréhender les conséquences de la mise à jour du contenu sélectionné sur toutes les pages du site qui présentent ce contenu élémentaire. Selon des caractéristiques exemplaires de l'invention succinctement exposée ci-dessus, l'étape de définition du contenu de chaque page comporte des instructions faisant appel à des données dynamiques. Grâce à ces dispositions, lorsque le nombre d'informations de même type contenu dans la base de données (par exemple le nombre d'équipements sportifs ou culturel) évolue, le site est automatiquement modifié pour tenir compte de cette évolution, sans que l'utilisateur n'ait à effectuer la moindre programmation. La présente invention vise, selon un deuxième aspect, un dispositif de constitution et mise à jour de contenus de pages d'une pluralité de sites informatiques accessibles par l'intermédiaire d'Internet, à des adresses différentes entre elles sur Internet, caractérisé en ce qu'il comporte : Al un moyen de définition de modèle de contenu commun à plusieurs sites, ce contenu commun étant conservé dans une base de données, B/un moyen de définition de la structure de la base de données, CI un moyen de définition de formulaires communs à tous lesdits sites, chaque formulaire comportant des champs en référence avec la base de données, une partie des champs des formulaires étant en correspondance avec un contenu de la base de données disponible pour tous les sites et une partie des champs des formulaires étant en correspondance avec un contenu spécifique à chaque site et permettant la mise à jour de ce contenu spécifique, D/un moyen de constitution d'une application informatique hébergée de distribution des formulaires à une adresse sur Internet indépendante des adresses desdits sites sur Internet, et, pour chaque site : El un moyen de définition des éléments graphiques de présentation de pages dudit site, la présentation étant spécifique audit site, FI un moyen de définition de contenu de pages dudit site, en relation avec ladite base de données, G/un moyen de remplissage de contenu spécifique audit site, ledit contenu spécifique étant conservé en base de données, les pages dudit site étant constituées de : a) une partie présentation de pages, spécifique audit site, b) une partie représentative du contenu de champ susceptible d'être mis à jour par utilisation des formulaires, et c) une partie représentative des contenus communs à plusieurs sites ; et, de manière itérative, H/un moyen de mise à jour de contenu spécifique audit site, par l'intermédiaire de ladite application informatique et d'au moins un dit formulaire, le contenu spécifique mis à jour étant conservé dans la base de données. La présente invention vise, selon un troisième aspect, un procédé de constitution et mise à jour de contenus de pages d'une pluralité de sites informatiques accessibles par l'intermédiaire d'un réseau informatique, à des adresses différentes sur ledit réseau informatique, caractérisé en ce qu'il met en oeuvre : - une base de données comportant un contenu commun à plusieurs sites, la base de données ayant une structure définie, - des formulaires communs à tous lesdits sites, chaque formulaire comportant des champs en référence avec la base de données, une partie des champs des formulaires étant en correspondance avec un contenu de la base de données disponible pour tous les sites et une partie des champs des formulaires étant en correspondance avec un contenu spécifique à chaque site et permettant la mise à jour de ce contenu spécifique, - une application informatique hébergée de distribution des formulaires à une adresse sur Internet indépendante des adresses desdits sites sur Internet, chaque site mettant en oeuvre : - des éléments graphiques de présentation de pages dudit site, la présentation étant spécifique audit site, - un contenu de pages dudit site, en relation avec ladite base de données, le contenu spécifique audit site étant fourni à ladite base de données, les pages dudit site étant constituées de : a) une partie présentation de pages, spécifique audit site, b) une partie représentative du contenu de champ susceptible d'être mis à jour par utilisation des formulaires, et c) une partie représentative des contenus communs à plusieurs sites ; et, de manière itérative, l'application informatique et au moins un dit formulaire étant itérativement mis en oeuvre pour mettre à jour le contenu spécifique audit site, le contenu spécifique mis à jour étant conservé dans la base de données. Les avantages, buts et caractéristiques exemplaires des deuxième et troisième aspects de la présente invention étant identiques à ceux du premier aspect, ils ne sont pas rappelés ici, dans un but de clarté. D'autres avantages, buts et caractéristiques de la présente invention ressortiront de la description qui va suivre, faite en regard des dessins annexés dans lesquels : - la figure 1 représente, de manière schématique, une architecture d'un mode de réalisation particulier de la présente invention, - la figure 2 représente, de manière schématique, une application de mise à jour partagée de l'architecture illustrée en figure 1, - la figure 3 représente, de manière schématique, un modèle de données mis en oeuvre dans l'architecture illustrée en figures 1 et 2, - la figure 4 représente le principe relationnel d'enregistrements de sites, conformément à l'architecture illustrée en figures 1 à 3, - la figure 5 représente une source de formulaire de mise à jour d'un contenu de site, - la figure 6 représente un formulaire de mise à jour utilisé par un client, - la figure 7 représente des liens entre un formulaire de mise à jour et une page du site mettant en oeuvre ladite mise à jour, et - la figure 8 représente, de manière schématique, les étapes d'un mode de réalisation du procédé objet de la présente invention. En figure 1 sont représentés trois sites web 1,2 et 3 comportant des pages 4,5 et 6, respectivement, contenues dans une base de donnée commune 7 d'un serveur S, qui supporte également une application hébergée partagée 9 mettant en oeuvre des formulaires de mise à jour 8. Des clients C1, C2 et C3 qui gèrent les sites 1, 2 et 3, respectivement, mettant en oeuvre l'application hébergée 9 pour mettre à jour les sites 1,2 et 3. Les sites web 1,2 et 3 sont autonomes et originaux dans leurs présentations. Ils possèdent, chacun, une adresse sur un réseau informatique, par exemple Internet, sous forme d'une url (pour"uniform resource locator"ou localisateur de ressource uniforme), par exemple de type www. maille. fr. Les sites 1,2 et 3 sont conçus en pages dynamiques 4,5 et 6. La base de données commune 7 est commune pour tous les sites et paramétrée pour chaque site (contenu utilisé, plan du site). On observe que la base de données commune 7 peut être constituée soit d'une base de données unique soit de bases de données synchronisées, c'est-à-dire mise à jour par diffusion, sur une base de données unique La base de données commune 7 comporte un contenu disponible pour tous les sites, chaque client décidant de mettre en page, ou non, chaque composant du contenu disponible. Ce contenu disponible comporte, par exemple, des textes de lois, de l'information institutionnelle, des informations pratiques sur les démarches administratives, des liens avec des sites tiers, par exemple la météorologie nationale, les ambassades et organismes consulaires à l'étranger, les associations de consommateurs, les services de transport nationaux, les services d'urgence et de santé. La base de données 7 conserve aussi les informations de présentation de chaque site, dans un langage de description de pages de sites informatiques (par exemple HTML, XML, applets JAVA), les fichiers images, son et vidéo présentés par chaque site. La base de donnée 7 conserve, pour chaque site, les contenus de champs de formulaires 8 mis à jour par les clients en utilisant l'application hébergée 9. Les formulaires 8 de mise à jour sont uniques, communs à tous les sites et sont intégrés dans l'application) hébergé 9 qui gère également la reconnaissance des caractéristiques de chaque site (liens entre plans de sites et contenus stockés en base de données 7). Chaque formulaire comporte des champs dont le contenu, spécifique à chaque site, est conservé dans la base de données 7. Chaque formulaire comporte aussi des informations de description des contenus à insérer dans les champs (par exemple "adresse de la mairie") et des informations de relation entre les champs et des pages du site du contiennent les contenus desdits champs. L'application hébergée 9 possède une adresse urt différente des adresses url des sites 1, 2 et 3. Avant la mise en place d'un site, on met en base de données 7 le contenu disponible pour tous les sites, on met en place l'application hébergée 9 et les formulaires 8 et on référence l'adresse uri du site de l'application hébergée dans les serveurs dns (pour"domain name server"ou serveurs de noms de domaines). Pour mettre en place un nouveau site, on procède de la manière suivante : - on attribue à chaque client un identifiant de son site (par exemple le code INSEE de la ville) et un mot de passe secret ; - on référence l'adresse url du site du client dans les serveurs dns ; - on définit le plan du site et les liens entre les pages ; - on définit, pour chaque page du site : a) sa présentation, b) le contenu statique, c) le contenu qui provient du contenu disponible pour tous les sites dans la base de données 7, et d) le contenu qui provient des contenus des champs de formulaires. Toutes les descriptions de pages et les références à la base de données 7 sont conservées dans la base de données 7. Pour mettre à jour un site, les étapes suivantes sont effectuées : - le client accède à l'application hébergée 9, par l'intermédiaire d'un terminal informatique relié au réseau informatique, en utilisant un navigateur classique ; - une page d'accueil des clients est affichée sur l'écran du terminal et invite le client à fournir un identifiant du site et un mot de passe secret ; - le client fournit un identifiant de site (par exemple le code INSEE de la ville) ; - le client fournit le mot de passe qui lui a été attribué ; - l'application hébergée 9 vérifie la correspondance entre le mot de passe et l'identifiant ; - le client visualise un descriptif des contenus élémentaires de son site, sélectionne une information qu'il veut mettre à jour ; - l'application hébergée 9 fournit le formulaire qui correspond à l'information à mettre à jour et des informations représentatives de toutes les pages du site du client dont le contenu dépend du contenu du ou des champs dudit formulaire qui correspondent à l'information qui va être mise à jour ; - le client met à jour l'information et la valide ; - l'application hébergée 9 met à jour la base de données 7 avec le nouveau contenu des champs modifiés ; - le site du client est, en conséquence, immédiatement modifié en fonction des mises à jour effectuées. Par ailleurs, le gestionnaire de la base de données 7 effectue des mises à jour du contenu de la base de données 7 disponible pour tous les sites et les sites sont immédiatement modifiés pour tenir compte de cette mise à jour. Ainsi, conformément à un aspect de la présente invention, l'application de mise à jour de sites est une application hébergée et non un système installé localement chez le client. Le terme application hébergée représente ici une application publiée sur Internet, selon le modèle ASP (Application Services Provider). L'application hébergée est pourvue d'un frontal de communication assurant la correspondance entre les pages de chaque site et l'appel des formulaires adaptés à la mise à jour des contenus associées à ces pages. Cependant, la création du site de chaque client est réalisée sur mesure, en ce qui concerne la présentation. La création de chaque site web est originale pour chaque client, chaque site répondant simplement à des impératifs de gestion d'un périmètre potentiel de contenus. On note que le périmètre du système d'information publié (contenus) est connu a priori dès lors que le domaine d'activité est lui-même cerné. Le système objet de la présente invention permet la dissociation la plus large entre la présentation de l'information (pages du site Internet), qui est propre à chaque site, et la gestion des contenus qui est partagé. L'ensemble des contenus de tous les sites gérés est stocké dans une même base de données multimédias, présentant donc un modèle conceptuel de données unique. Les formulaires de mise à jour des tables de la base données sont communs (et non développés spécifiquement pour chaque client), ce qui permet leur évolution et leur maintenance par versions successives. Ainsi : - la base de données est partagée entre tous les clients grâce à un code identifiant unique (ici, le code insee de la ville). Pour ce faire, la structure de la base de données est assez large pour accueillir tout type d'information susceptible d'être publiée sur un site de officiel de ville. La base de donnée étant commune et reliée à tous les domaines des sites utilisateurs , elle est accessible sur Internet et donc hébergée (adresse http propre). - le système objet de la présente invention repose sur la notion de contenus élémentaires, assimilables au plan technique à une forme de composant (modèle objet). Le contenu élémentaire est le niveau le plus fin de publication possible. Ce niveau est défini et personnalisé pour chaque client. Le système permet d'établir la corrélation, au sein de la base de données, entre les contenus à publier pour un site, et les tables de la base de données impactées par la mise à jour de ces contenus. A cet effet, la base de données intègre un plan de site dynamique pour chaque client définissant l'appartenance des contenus à publier aux différentes pages du site. Un contenu peut appartenir à 0 à N pages, de même une page peut comprendre de 0 à N contenus. - l'application de mise à jour partagée 9 met à disposition des villes clientes l'interface nécessaire à la mise à jour du contenu de leurs sites, après authentification de l'utilisateur. Les formulaires sont reliées à la base de données partagée. La base de données 7 prend en compte l'organisation des rubriques de chaque site (plans de site) et les relie-aux contenus de la base, la vision des clients étant partielle et personnalisée. Une interface 10 (illustrée en figure 2) permet au client de voir les modifications réalisées sur le site en temps réel (grâce au lien entre les contenus et les pages du site). Le modèle de données mis en oeuvre correspond au système d'information qu'une ville peut publier dans le cadre de son site Internet officiel, d'une part, enrichi de données gérées par l'éditeur destinées à définir le client et ses attributs, d'autre part. Le synoptique des données est illustré en figure 3. Les données gérées par ! e système pour la personnalisation de chaque site comportent : 11 Les données d'identification du site 11 : toutes les tables de l'application (à l'exception des tables de références communes) sont reliées au code identifiant du site client, défini dans la table T-Ville lors de la création initiale du site. Cette table comprend l'adresse urt du site Internet ainsi que les mots de passe (ou"codes d'accès") utilisés par le client concerné pour se connecter à l'application de mise à jour hébergée 9 ; 2/Les données d'identification du client 12 : ces données permettent de définir les principales caractéristiques d'un client, notamment en ce qui concerne les interlocuteurs et les modules de l'application utilisés. Cette table peut être utilisée par exemple pour générer des listes de diffusion en fonction de certains critères ; 3/Les données du plan de site dynamique 13 (voir aussi la figure 4) : le plan de site dynamique est géré par l'intermédiaire de trois tables de paramétrage sur lesquelles se base l'interface de l'application hébergée pour présenter au client le contenu personnalisé de son site Internet. Ces paramètres sont essentiels : ils constituent un aspect de l'invention en permettant de relier un contenu personnalisé, un plan de site par client, et des formulaires de mise à jour uniques ; 4/Les données gérées par le client via l'application hébergée 9 : nous donnons ici la liste des autres données de la base BaseVilte. Une règle de construction de la base est que le code identifiant du site (code Insee ici) est une clé de l'ensemble des tables dont les données sont gérées par le client. N Données descriptives 14 : - La mairie et ses annexes : coordonnées, horaires, photos, localisation géographique, - Le conseil municipal : le maire, les élus, photos personnelles ou collectives, permanences, commissions municipales,... - Les services municipaux : annuaire des services, coordonnées, photos, horaires, descriptifs,... - Présentation de la ville : descriptifs, photos, plan d'accès, historique de la ville,... - Les réglementations : toutes les réglementations propres à la ville- (encombrants, ordures ménagères, ordre public, environnement,...) - Les équipements sportifs : coordonnées, horaires, photos, localisation géographique, tarifs,... - Les équipements culturels : coordonnées, horaires, photos, localisation géographique, tarifs,... - Les équipements sectaires : coordonnées, horaires, photos, localisation géographique, tarifs,... - Les équipements sociaux : coordonnées, horaires, photos, localisation géographique, tarifs,... - Le patrimoine : coordonnées, horaires, photos, localisation géographique, tarifs,... de tous les éléments, - Lieux remarquables : coordonnées, horaires, photos, localisation géographique, tarifs,... de tous les lieux, - Lieux ou équipements de loisir : coordonnées, horaires, photos, localisation géographique, tarifs, descriptif de tous les lieux de loisir... - Les lieux de culte : coordonnées, horaires, photos, localisation géographique, tarifs, ... de tous les lieux de culte, BI Les Annuaires Locaux : - Urgences : coordonnées, contacts, localisation géographique, descriptifs,... - Santé : coordonnées, contacts, localisation géographique, descriptifs,... - Annuaires Pratiques : coordonnées, contacts, localisation géographique, descriptifs, - Commerçants : coordonnées, contacts, localisation géographique, fiches descriptives,... - Entreprises : coordonnées, contacts, localisation géographique, fiches descriptives, offres d'emploi... - Associations : coordonnées, contacts, localisation géographique, fiches descriptives, types d'associations, actualités... CI Les données événementielles : - Actualités Ville : titre, date de publication, résumé, détail de l'article, photo, date de manifestation, liens... - Actualités Associations (option portail seulement) : titre, date de publication, résumé, détail de l'article, photo, date de manifestation, liens... - Edito : titre, résumé, détail, photo, archives... - Manifestations : titre, date de publication, résumé, détail de l'article, photo, date de manifestation, liens... - Documents à télécharger : tous documents à proposer en téléchargements (délibérations, journal...) : titre, résumé, date, adresse... DI Références à du contenu externe : - Les Liens paramétrés : météo locale, horaire SNCF, démarches administratives,... - Les Liens spécifiques : tous les liens libres classés par thème... - Channels (canaux) d'information : sources externes d'informations en continu pour agrémenter le site (informations locales, actualités...) Les pages dynamiques 4,5 et 6 des sites 1,2 et 3 des différents clients sont connectées à la base de données multi-clients 7 (directement en SQL ou par l'intermédiaire de composants). Les pages sont développées sur la base d'un mode de navigation et d'une charte graphique réalisées sur mesure. Le plan de site est également personnalisé pour chaque client. La construction du site respecte des règles : - pour un site client donné, tous les jeux d'enregistrement de la base de données doivent présenter un filtre sur le code d'identification du client (code insee dans notre cas) pour ne sélectionner que les éléments du client (puisque la base est multi-clients), - la conception des pages, même si elle est originale pour chaque client, ne doit intégrer que les contenus définis dans le modèle des données de la base (il est cependant possible de gérer des évolutions de version de la base de données), - les menus qui font appel à des données correspondant à plusieurs occurrences de la base doivent en tenir compte et être extensibles . Par exemple un menu présentant les équipements culturels de la ville ne doit pas être traité en statique mais généré par appel des différents noms des enregistrements (centre culturel, bibliothèque, MJC..) de la table des équipements culturels. Ceci permet au client d'ajouter (ou de supprimer) lui-même des occurrences sans que le menu (et la page qui le présente) ne soit à modifier. - on ne manipule pas, dans les pages, des numéros d'identification pour afficher spécifiquement un enregistrement donné. En effet, les enregistrements peuvent être supprimés par le client et les pages correspondantes ne fonctionneraient plus. En revanche, les numéros d'identification peuvent être passés en paramètre à partir de listes ou de menus dynamiques. Pour gérer le problème des items affichés par défaut à l'ouverture d'une rubrique (exemple le centre culturel dans la rubrique équipements culturels), les tables contiennent un indicateur page de garde rubrique positionné à "vrai" lorsque l'enregistrement doit figurer par défaut. Ceci permet en outre au client de changer s'il le souhaite, sans aucune programmation, l'enregistrement qui doit apparaître en page de garde en modifiant la valeur de cet indicateur. Une fois ces quelques règles observées, le concepteur des pages a toute liberté pour la présentation des informations, et le mode de navigation. Dans des modes particuliers de réalisation, l'application 9 est hébergée sur le même serveur S que la base de données multi-clients 7. Les clients peuvent y accéder par une adresse"uri", puis ils peuvent se connecter à l'application de mise à jour 9 de leurs sites respectifs en s'identifiant. La base de données 7 est toutefois conçue pour permettre également la reconnaissance de plusieurs utilisateurs par ville cliente (dans les structures plus importantes, les mises à jour peuvent être confiées à plusieurs interlocuteurs en fonction des secteurs). On observe que les formulaires de mise à jour 8 (voir aussi la figure 5) sont définis une seule fois puisqu'ils sont communs à toutes les villes connectées à l'application hébergée 9. Une table des formulaires est utilisée dans le cadre de l'interface de mise à jour 10 pour appeler l'url du formulaire à utiliser pour mettre à jour le contenu souhaité. Les formulaires de mises à jour 8 sont des pages dynamiques de l'application hébergée 9 qui permettent de modifier les données des tables de la base de données. Par exemple, un formulaire MaL Ville Description a pour fonction de mettre à jour la table T-VitteDescription. Dans le cadre de l'utilisation de l'application hébergée 9, le code identifiant du client (code Insee) est passé en paramètre de session pour que le formulaire ne permette de ne mettre à jour que les enregistrements du client concerné ; Le plan du site (voir aussi la figure 4) : pour chaque ville cliente (c'est à dire pour chaque code Insee) on définit les contenus publiés et le plan de site. Le plan de site est un ensemble de pages publiées. Il se décrit comme un organigramme : il s'agit d'un arbre sur lequel sont positionnées les pages du site Internet en fonction de leur niveau dans l'arborescence (pèrefils). La table du plan de site a deux usages : - elle permet, au niveau du site Internet résultant lui-même, de présenter dynamiquement à l'internaute le plan du site Internet, selon plusieurs critères de recherche ; - elle permet aussi, au niveau de la base de données, de référencer pour chacune des pages, les contenus qui la composent. Une page peut posséder de 0 à N contenus. Par exemple, la page de description de la mairie peut présenter à la fois les coordonnées de la mairie (premier contenu), la liste des services municipaux (deuxième contenu), la liste des élus (troisième contenu). Pour une autre ville, cette page pourra ne présenter que les coordonnées de la mairie (contenu unique). Pour chaque client, une table des contenus recense l'ensemble des contenus publiées, quelles que soient les pages du site. Un contenu fait référence à un formulaire de mise à jour. Plusieurs contenus peuvent pointer sur le même formulaire de mise à jour. Par exemple, les contenus [Ecole maternelle X] et [Ecole primaire Y] pointent pour un client donné sur le même formulaire de mise à jour des équipements scolaires (Maj~EqScolaires). Pour travailler sur la l'école voulue, lors de la mise à jour, le contenu dispose en attribut d'un paramètre de formulaire. Le principe relationnel est schématisé en figure 4 dans laquelle chaque client et chaque site est l'objet d'enregistrements de pages, 20 à 25, faisant référence à des enregistrements de contenus, 26 à 29, faisant eux-mêmes référence à des enregistrements de formulaires 30 à 32. Telle que nous l'avons précédemment décrite, l'application hébergée 9 comprend deux grandes fonctions : elle fait office de frontal de communication entre les contenus et le site client, d'une part, et réunit un ensemble de formulaires de mise à jour 8, d'autre part. Le frontal de communication utilise le plan de site dynamique de la base de données 7 pour sélectionner automatiquement, en fonction du client, les contenus que le site Internet de ce client publie. On observe qu'il ne s'agit pas des pages du site mais bien des contenus élémentaires. Pour certains sites, la liste des contenus est plus fournie (site plus riche en informations) que pour d'autres sites et certaines occurrences (ex : stade appartenant aux équipements sportifs) sont identifiés en tant que contenus élémentaires (parce qu'ils font l'objet d'occurrences dans les menus du site Internet). Concernant le lien entre contenus et formulaires 8, l'application hébergée 9 relie ces contenus aux formulaires 8 de la base de données 7 permettant de mettre à jour les données correspondantes. Par exemple, dans le cadre du modèle relationnel exposé précédemment en figure 4, ce lien est représenté par la requête SQL suivante : FROM T~Contenus INNER JOIN T~Formulaires ON Contenus. ldFormulaire = T~Formulaires. IdFormulaire WHERE Codelnsee = MM~ColParam > . Les formulaires de mise à jour 8 sont semblables à ceux d'un site Internet dynamique traditionnel. L'application hébergée 9 contient, dans le mode de réalisation particulier exposé ici, environ deux cents formulaires 8 pour l'insertion, la suppression, la mise à jour et les listes d'enregistrements de la base. Comme pour le reste de l'application la spécificité des formulaires 8 est de filtrer systématiquement les données par le paramètre de session du client connecté. Lorsqu'un client accède à l'application hébergée 9, il voit une page qui lui décrit le contenu actuel du site qui le concerne. Ce contenu est représenté, par exemple, par une liste de sujets auquel ledit site fait référence, par ordre alphabétique : - actualité générales associations, - actualité générale ville, - annuaire santé, - annuaire des artisans, - annuaire des associations, - annuaire des commerçants, - annuaire pratique, - annuaire urgences, - clubs ados, - composition du conseil municipal, - coordonnées de la mairie, - courrier contact, - délibérations du conseil municipal, - édite périodique, - équipements culturels : bibliothèque - équipement culturel : contre culturel, En sélectionnant l'un de ces contenus, par exemple ici"coordonnées de la mairie", le client atteint un formulaire de l'application hébergée 9, formulaire dont la source est représentés en figure 5, et comporte, préférentiellement, trois jeux d'enregistrement : - un jeu d'enregistrement client 40 qui permet de filtrer les enregistrements de la base sur le code du client, - un jeu d'enregistrement de la table (ou des tables) à mettre à jour 41 (dans cet exemple il s'agit de la table T~Mairie) et - un jeu d'enregistrement plan de site 42 qui permet d'afficher les pages du sites concernées par le contenu initialement sélectionné par le client pour accéder au formulaire de mise à jour. En utilisation par le client, le formulaire 8 prend la forme illustrée en figure 6 et comporte : - le nom de la ville concernée 50, - le code identifiant de la ville 51, - la date de la dernière mise à jour 52, - une description du sujet du formulaire 53 (ici"mise à jour descriptif mairie") - des descriptifs de contenus de champs 54, - des champs 55, prenant la forme de fenêtre éventuellement munies de scrollbar (ou ascenseurs), - une liste 56 des pages 57 et 58 du site du client concernées par le contenu des champs du formulaire 8 (c'est-à-dire les pages reprenant au moins un contenu de l'un des champs dudit formulaire), - des liens 59 vers des composants non complètement représentés sur le formulaire, par exemple des photos, - un bouton de validation 60 de la mise à jour de l'enregistrement. Concernant le lien entre le formulaire 8 illustré en figure 6, et une page du site résultant, illustré en figure 7, le contenu à mettre à jour sélectionné par le client (dans la liste des contenus) peut appartenir à plusieurs pages du site (par exemple : les dernières actualités sportives peuvent figurer dans la rubrique sport et dans la rubrique actualités du site). Pour permettre au client de voir directement l'impact des modifications sur toutes les pages du site concernées, l'écran des formulaires présente la liste 56 des pages 57 et 58 avec accès direct sur le site via un lien pointant sur l'adresse urt de la page. Le lien entre les formulaires et les pages du site est réalisé à l'aide du plan de site dynamique, selon le modèle relationnel (plan de site/contenus/formulaires) présenté plus haut. La mise en oeuvre de la présente invention ne se limite pas aux sites institutionnels. Elle est, au contraire reproductible et, en terme d'usage, l'invention donne une solution aux futurs prestataires spécialisés dans des métiers différents en leur permettant d'industrialiser leur production et leurs prestations de maintenance et de diffuser leur produit auprès d'une clientèle ciblée. L'application hébergée illustrée en figures 1 à 7, solution Internet multi-sites destinée aux sites des collectivités locales, est une des illustrations de l'application de l'invention à un secteur particulier. Le procédé de l'invention peut être mis en oeuvre pour tous les corps de métier, en s'appuyant sur une base de données de contenus potentiels pour ces corps de métier. On donne ci-après quelques exemples de domaines applicables : - PME, PMI (éventuellement par type d'activité), - Professions libérales (éventuellement par types d'activité), - Commerces, - Associations, - Assurances, - Banques, - Hôpitaux, - Cliniques, - Laboratoires, D'une manière générale, tous les domaines d'activité particuliers se prêtent à priori à la mise en oeuvre de la présente invention. En terme technique, la mise en oeuvre de l'invention à d'autres domaines d'activité que celui des sites des collectivités locales est aisée. On présente ci-dessous deux tableaux montrant, d'une part, les règles de mise en oeuvre du procédé et, d'autre part, les variantes possibles en terme d'outils de production de la solution. AI Règles de mise en oeuvre : Règles commentaires Spécialisation marché ou métier Une solution Internet multi-sites du prestataire éditeur de la solution ne peut adresser qu'un secteur d'activité précis Définition d'un modèle de La spécialisation induit cette données de contenus à publier connaissance à priori du contenu à publier pour un secteur d'activité déterminé Création des sites clients selon le Il n'est bien entendu pas possible modèle de la solution Internet multi-d'appliquer le système de mise à jour sites à un site déjà existant qui n'aurait pas été conçu en pages dynamiques connectées (directement ou par l'intermédiaire de composants) à la base de données multi-sites de la solution. Seule la charte graphique d'un site existant, si elle est satisfaisante, pourra être conservée. Conception et création de la base La solution repose sur une base de données multi-sites selon le modèle de données regroupant les de la solution 1 nternet multi-sites, informations publiées de tous les sites intégrant notamment un frontal de clients communication entre contenus personnalisés et formulaires de mise à jour. Développement d'un application C'est cette application, avec la hébergée de mise à jour multi-sites base de données, que le prestataire comprenant l'interface de de solution Internet multi-sites devra communication avec le site client et les faire évoluer au fil du temps (évolution formulaires de mise à jour technologique, correction des anomalies, évolution du périmètre de contenus...) B/Vanantes technolootoues : Technologies Solution illustrée aux Variantes possibles figures 1 à 7 Langage de Active Server Pages PHP, Java Server création des pages (ASP) de microsoft Pages (JSP) ou tout autre dynamiques des langage permettant la sites clients communication entre des pages HTML et des bases de données Modèle de Scripting ASP Tout autre scripting connexion des (connexion directe dans les ou bien modèle pages des sites à la pages elles-même par le d'architecture à base de base de données biais de requêtes SQL sur la composants (JB, EJB, base) COM/DCOM...) Base de SQL Server 2000 de Tout Système de données microsoft Base de Données Relationnel (Oracle, Sybase,...) Le SGBDR doit toutefois permettre l'adressage distant de la connexion de manière à ce que la base soit hébergée sur un nom de domaine externe par rapport au site client. Langage de Active Server Pages PHP, Java Server création des pages (ASP) de microsoft Pages (JSP) ou tout autre dynamiques de langage permettant la l'Application communication entre des hébergée de mise à pages HTML et des bases jour multi-sites de données Architecture Les sites clients et Techniquement, les d'hébergement l'application hébergée noms de domaine (et les partagée (incluant la base de pages dynamiques données) sont hébergées associées) des sites chez un même hébergeur. clients pourraient être hébergées chez des L'accès aux données hébergeurs distincts. par les pages dynamiques des différents sites empruntent donc les liaisons locales de l'hébergeur et non des liaisons distantes via Internet. (Microsoft, Java, ASP, JSP, SQL, JB, EJB, COM/DCOM, Oracle et Sybase sont des marques déposées) Les avantages de la mise en oeuvre de la présente invention sont nombreux, tant pour le client final que pour le prestataire Internet. Pour le client (une collectivité locale dans la solution Internet multi-sites décrite en figures 1 à 7) : - le coût réduit de création du site dynamique : l'application hébergée et la base de données étant déjà constituées, la seule charge à supporter par le client pour son site est la réalisation de la maquette originale de son site. Dans une offre traditionnelle, le client devrait payer la création de la base de données associée à son site ainsi que les formulaires de mise à jour reliés à cette base. - la complétude de contenu : l'application est basée sur le principe qui peut le plus peut le moins . Avec l'application hébergée exposée dans la description, une petite ville bénéficiera donc d'un potentiel de publication très important, assimilable à celui d'une grande collectivité locale, même si elle n'utilise qu'une partie des contenus possibles. - le délai de réalisation : les contenus potentiels étant pré-déterminés, le délai réalisation est très raccourci car le client choisit ses contenus et son plan de site. La phase d'étude est très largement réduite. Les développements de la base et des formulaires sont déjà réalisés. - la simplicité de mise à jour : l'application hébergée offre la possibilité intrinsèque de modifier/ajouter/supprimer la totalité des contenus publiés sur le site, dans le cadre d'une interface utilisateur (aucun développement web). L'interface utilisateur évolue avec les technologies. - le coût de maintenance et l'évolution du site : le client ne paie qu'une cote part minime du coût de maintenance de la solution puisque celle-ci est commune à plusieurs clients. Il est également assuré (à concurrence de la durée de vie de son prestataire ! ) d'une évolution du système (nouvelles versions). Pour le prestataire éditeur de la solution Internet multi-sites : - l'avantage concurrentiel : sur son marché, l'éditeur d'un solution Internet multi-sites bénéficiera de l'avantage concurrentiel apportés par les avantages clients exposés cidessus, notamment le coût, la complétude et la pérennité de l'offre. - l'industrialisation de la production et le modèle progiciel : il est actuellement quasiment impossible d'industrialiser la production et l'entretien de sites Internet originaux. Aussi, les web agency interviennent-elles au coût par coût, sur devis, lorsqu'elle sont sollicités par leurs clients. Avec notre solution, la base de données et l'application hébergée ne sont réalisées qu'une seule fois. Le modèle de production et de maintenance de l'édition de progiciel peut donc totalement s'appliquer. Le business modèle se fonde ici sur le revenu récurrent de location mensuelles de l'application hébergée. - la possibilité de fourniture de contenus en plus du contenant : les sites clients étant reliés à une même base de données, il est possible de fournir des contenus, simultanément, à tout ou partie des sites, en accord avec des fournisseurs de contenus. La figure 8 représente, de manière schématique, les étapes d'un mode de réalisation du procédé objet de la présente invention. Ce mode de réalisation du procédé peut être implémenté sur un ordinateur ou un serveur pour réalisé un mode de réalisation du dispositif objet de la présente invention. Le procédé illustré en figure 8 permet la constitution et la mise à jour de contenus de pages d'une pluralité de sites informatiques accessibles par l'intermédiaire d'Internet, à des adresses différentes entre elles sur Internet, tous les sites appartenant au même domaine d'activité. Le procédé illustré en figure 8 comporte : - une étape 100 de définition de modèle de contenu commun à plusieurs sites, ce contenu commun étant conservé dans une base de données, - une étape 110 de définition de la structure de la base de données, ladite structure permettant d'accéder, en lecture ou en écriture, à toutes les données contenues dans la base de données, - une étape 120 de définition de formulaires communs à tous lesdits sites, chaque formulaire comportant des champs en référence avec la base de données, une partie des champs des formulaires étant en correspondance avec un contenu de la base de données disponible pour tous les sites et une partie des champs des formulaires étant en correspondance avec un contenu spécifique à chaque site et permettant la mise à jour de ce contenu spécifique, et - une étape 130 de constitution d'une application informatique de distribution des formulaires hébergée à une adresse sur Internet indépendante des adresses desdits sites sur Internet. Pour constituer chaque site, le procédé comporte : - une étape 140 de définition des éléments graphiques de présentation de pages dudit site, la présentation étant spécifique audit site, - une étape 150 de définition de contenu de pages dudit site, en relation avec ladite base de données (Préférentiellement, l'étape de définition du contenu 150 de chaque page comporte des instructions faisant appel à des données dynamiques et/ou comporte des instructions faisant appel à des références dans la base de données), et - une première étape 160 de remplissage de contenu spécifique audit site, ledit contenu spécifique étant conservé en base de données. Ainsi, les pages dudit site sont constituées de : a) une partie présentation de pages, spécifique audit site, b) une partie représentative du contenu de champ susceptible d'être mis à jour par utilisation des formulaires, et c) une partie représentative des contenus communs à plusieurs sites. Pour mettre successivement à jour le site, son administrateur effectue, de manière itérative, une étape de mise à jour 170 de contenu spécifique audit site, par l'intermédiaire de ladite application informatique et d'au moins un dit formulaire, le contenu spécifique mis à jour étant conservé dans la base de données. Dans un mode de réalisation exemplaire, au cours de l'étape de mise à jour 170, l'application informatique hébergée de distribution de formulaires affiche à l'utilisateur la liste des contenus élémentaires publiés sur son site, étape 175, indépendamment des pages du site qui les contiennent et, lorsque l'utilisateur a sélectionné un contenu de ladite liste, étape 180, affiche un formulaire de mise à jour du contenu est automatiquement sélectionné, étape 185. Préférentiellement, au cours de l'étape de mise à jour 170, chaque formulaire est associé à une indication représentative des pages du site mis à jour concernées par les données mises à jour. REVENDICATIONS 1-Procédé de constitution et mise à jour de contenus de pages d'une pluralité de sites informatiques accessibles par l'intermédiaire d'Internet, à des adresses différentes entre elles sur Internet, caractérisé en ce qu'il comporte : A/une étape (100) de définition de modèle de contenu commun à plusieurs sites, ce contenu commun étant conservé dans une base de données, B/une étape (110) de définition de la structure de la base de données,- CI une étape (120) de définition de formulaires communs à tous lesdits sites, chaque formulaire comportant des champs en référence avec la base de données, une partie des champs des formulaires étant en correspondance avec un contenu de la base de données disponible pour tous les sites et une partie des champs des formulaires étant en correspondance avec un contenu spécifique à chaque site et permettant la mise à jour de ce contenu spécifique, DI une étape (130) de constitution d'une application informatique de distribution des formulaires hébergée à une adresse sur Internet indépendante des adresses desdits sites sur Internet, et, pour chaque site : El une étape (140) de définition des éléments graphiques de présentation de pages dudit site, la présentation étant spécifique audit site, F/une étape (150) de définition de contenu de pages dudit site, en relation avec ladite base de données, G/une première étape (160) de remplissage de contenu spécifique audit site, ledit contenu spécifique étant conservé en base de données, les pages dudit site étant constituées de : a) une partie présentation de pages, spécifique audit site, b) une partie représentative du contenu de champ susceptible d'être mis à jour par utilisation des formulaires, et c) une partie représentative des contenus communs à plusieurs sites ; et, de manière itérative, H/une étape (170) de mise à jour de contenu spécifique audit site, par l'intermédiaire de ladite application informatique et d'au moins un dit formulaire, le contenu spécifique mis à jour étant conservé dans la base de données. 2 - Procédé selon la revendication 1, caractérisé en ce que, au cours de l'étape de mise à jour (170), l'application informatique hébergée de distribution de formulaires affiche à l'utilisateur la liste des contenus élémentaires publiés sur son site (175), indépendamment des pages du site qui les contiennent et, lorsque l'utilisateur a sélectionné un contenu de ladite liste (180), un formulaire de mise à jour du contenu est automatiquement sélectionné (185). 3 - Procédé selon l'une quelconque des revendications 1 ou 2, caractérisé en ce que, au cours de l'étape de mise à jour (170), chaque formulaire est associé à une indication représentative des pages du site mis à jour concernées par les données mises à jour. 4 - Procédé selon l'une quelconque des revendications 1 à 3, caractérisé en ce que l'étape de définition du contenu (150) de chaque page comporte des instructions faisant appel à des données dynamiques. 5 - Procédé selon l'une quelconque des revendications 1 à 4, caractérisé en ce que l'étape de définition du contenu (150) de chaque page comporte des instructions faisant appel à des références dans la base de données. 6-Dispositif de constitution et mise à jour de contenus de pages d'une pluralité de sites informatiques (1,2, 3) accessibles par l'intermédiaire d'Internet, à des adresses différentes entre elles sur Internet, caractérisé en ce qu'il comporte : - une base de données (7) structurée conservant un contenu commun à plusieurs sites, - un moyen de mémorisation d'une pluralité de formulaires (8) communs à tous lesdits sites, chaque formulaire comportant des champs en référence avec la base de données, une partie des champs des formulaires étant en correspondance avec un contenu de la base de données disponible pour tous les sites et une partie des champs des formulaires étant en correspondance avec un contenu spécifique à chaque site et permettant la mise à jour de ce contenu spécifique, - un moyen de mise en oeuvre d'une application informatique hébergée de distribution des formulaires (9) à une adresse sur Internet indépendante des adresses desdits sites sur Internet, et, pour chaque site de la pluralité de site des pages (4,5, 6) constituées de : a) une partie présentation de pages, spécifique audit site, b) une partie représentative du contenu de champ susceptible d'être mis à jour par utilisation des formulaires, et c) une partie représentative des contenus communs à plusieurs sites ; le moyen de mise en oeuvre de l'application informatique hébergé étant adapté à mettre à jour le contenu spécifique audit site, en mettant en oeuvre au moins un dit formulaire, le contenu spécifique mis à jour étant conservé dans la base de données. 7-Dispositif selon la revendication 6, caractérisé en ce que le moyen de mise en oeuvre de l'application informatique (9) est adapté à afficher à l'utilisateur la liste des contenus élémentaires publiés sur son site, indépendamment des pages du site qui les contiennent et, lorsque l'utilisateur a sélectionné un contenu de ladite liste, un formulaire (8) de mise à jour du contenu est automatiquement sélectionné. 8 - Dispositif selon l'une quelconque des revendications 6 ou 7, caractérisé en ce que le moyen de mise en oeuvre de l'application informatique (9) est adapté à ce que chaque formulaire (8) soit affiché avec une indication représentative des pages du site mis à jour concernées par les données mises à jour. 9 - Dispositif selon l'une quelconque des revendications 6 à 8, caractérisé en ce que la description de pages comporte des instructions faisant appel à des données dynamiques. 10 - Dispositif selon l'une quelconque des revendications 6 à 9, caractérisé en ce que la description de pages comporte des instructions faisant appel à des références dans la base de données.