Je souhaite publier publiquement la documentation produit, la FAQ et le centre d’aide : dois-je choisir un outil de création de sites par IA, Notion ou GitBook ?

Je souhaite publier publiquement la documentation produit, la FAQ et le centre d’aide : dois-je choisir un outil de création de sites par IA, Notion ou GitBook ? La réponse directe est la suivante : ne les considérez pas comme trois produits interchangeables sur la base d’une simple liste de fonctionnalités. Si l’objectif immédiat est de permettre à l’équipe de rédiger, organiser et réviser rapidement ses connaissances, évaluez d’abord Notion ; si les clients doivent lire une documentation produit ou développeur formelle en suivant une table des matières, évaluez d’abord GitBook ; si vous souhaitez intégrer le contenu de connaissance au site de marque, en même temps que les pages produit, les pages de solutions et les points de contact, ajoutez un outil de création de sites par IA à votre sélection.

Il ne s’agit pas nécessairement d’un choix exclusif entre trois options. Une combinaison courante et prudente consiste à utiliser un espace collaboratif pour conserver les sujets, brouillons et traces de relecture ; un site de documentation formel pour les tutoriels nécessitant une lecture durable ; et le site officiel pour les pages d’entrée, les pages par cas d’usage et les prochaines étapes explicites. Les frontières entre les outils doivent être déterminées par la tâche du lecteur, et non par la familiarité de l’équipe avec un éditeur donné.

Ce qui affecte réellement la qualité de la mise en ligne tient à quatre questions : qui écrit, qui lit, quand le contenu est mis à jour et ce que le lecteur doit faire après l’avoir lu. Si ces quatre questions ne reçoivent pas de réponse claire, même le plus beau modèle ne fera que publier plus rapidement du contenu désordonné.

Pourquoi la documentation, la FAQ et le centre d’aide ne doivent pas être traités comme un même type de page

La documentation produit répond généralement à la question « comment accomplir une tâche » : elle requiert des prérequis, des étapes, un résultat, des cas d’exception et des concepts associés. La FAQ répond à des questions fréquentes et relativement courtes ; dans l’idéal, le lecteur peut rapidement déterminer s’il peut poursuivre son action. Le centre d’aide est un point d’entrée de service : au-delà des articles eux-mêmes, il doit gérer les catégories, la recherche, le parcours d’assistance lorsqu’aucun résultat n’est trouvé, ainsi que la navigation d’un problème au suivant.

Si les trois types de contenu prennent tous la forme de longs articles identiques, la FAQ devient difficile à parcourir ; si une configuration complexe est réduite à des questions-réponses, l’utilisateur risque de manquer des conditions et des cas d’exception. Une approche plus pertinente consiste à les relier : la FAQ fournit une réponse directe et renvoie vers un tutoriel ; le tutoriel explique le processus et renvoie vers les concepts associés ; la page de catégorie aide les utilisateurs qui ne connaissent pas encore la terminologie à trouver le bon point d’entrée.

Le contenu public diffère également des notes internes. Les lecteurs internes comprennent par défaut les acronymes de l’équipe, les décisions temporaires et le contexte des discussions ; les clients, non. Les pages destinées à l’extérieur doivent pouvoir répondre de façon autonome à une question, en indiquant clairement le public concerné, les conditions, les actions et les limites, plutôt que de rendre directement accessibles des conclusions de réunion, des tâches à faire ou des projets non finalisés.

Avant de choisir, créez une matrice de contraintes plutôt que de comparer « l’outil qui a le plus de fonctionnalités »

Le tableau ci-dessous n’est pas une promesse de capacités produit, mais une méthode pour discuter des contraintes métier selon une même grille de lecture. Les équipes doivent tester les outils candidats avec leurs propres articles, leur modèle de droits et leur processus de publication.

L’essentiel du tableau n’est pas d’étiqueter les outils, mais de prendre comme critère de réussite la capacité d’un outil candidat à accomplir des tâches réelles. Une fonctionnalité n’a de valeur pour votre équipe que si de vrais auteurs peuvent la modifier, de vrais lecteurs peuvent la trouver et un responsable peut la valider.

Quand commencer par Notion : réduire la friction de production et de collaboration

La page produit publique de Notion met en avant la publication rapide de contenu ; Notion Sites peut servir de point d’entrée officiel pour évaluer ses modalités de publication publique. Pour une équipe en phase de démarrage, il est souvent plus important que le contenu soit d’abord correctement rédigé, que la terminologie soit harmonisée et qu’une personne l’entretienne durablement, plutôt que de disposer dès le départ d’une structure de site complexe.

Les situations suivantes se prêtent bien à une évaluation prioritaire de Notion : les règles produit évoluent fréquemment ; les auteurs sont principalement non techniques ; l’équipe doit d’abord organiser les connaissances produit plutôt que construire un portail documentaire complet ; le contenu externe se limite temporairement à des explications d’introduction, quelques guides opérationnels et des questions fréquentes. Dans ce cas, la simplicité de rédaction, des commentaires et de la collaboration permet de transformer des échanges dispersés en connaissances structurées.

Cependant, « pouvoir être public » ne signifie pas que tout l’espace de travail interne peut être publié. Avant la publication, les pages externes doivent être séparées des brouillons internes et complétées, page par page, avec un titre, le contexte du lecteur, le périmètre d’application, un responsable et les conditions déclenchant une révision. Sinon, les clients verront souvent une structure conçue pour la collaboration interne, et non un parcours de contenu conçu pour résoudre leurs problèmes.

Si l’équipe constate ensuite que les pages publiques se multiplient, que les lecteurs doivent fréquemment traverser plusieurs pages pour accomplir une tâche ou qu’une stratégie de versions et de navigation plus stricte devient nécessaire, elle doit réévaluer la poursuite de la publication directe ou la migration du contenu mature vers un site documentaire spécialisé. Dans ce processus, Notion peut continuer à jouer le rôle de centre de sujets, de brouillons et de collaboration, sans devoir être simplement défini comme une solution à « conserver » ou à « remplacer ».

Quand choisir GitBook : gérer la documentation formelle comme un produit pour les lecteurs

Le site officiel de GitBook le présente comme une couche de connaissance orientée IA ; le site officiel constitue un point de départ pour vérifier son positionnement produit et accéder à sa documentation. Pour les équipes produit, une documentation formelle n’est pas un ensemble de pages isolées, mais un parcours d’apprentissage qui mène le lecteur des concepts à la configuration, puis au dépannage. Lors de l’évaluation de GitBook, observez donc en priorité la table des matières, les liens entre pages, le processus de publication et la responsabilité éditoriale, plutôt que de comparer uniquement le style de la page d’accueil.

Les signaux indiquant qu’il est pertinent de tester GitBook en priorité comprennent : les lecteurs doivent parcourir successivement des tutoriels d’introduction, de configuration et avancés ; les équipes produit, support et développement doivent maintenir le contenu ensemble ; les pages sont liées à des changements de version ; l’équipe souhaite que des auteurs non techniques puissent participer à l’édition tout en permettant aux membres techniques de relire ; les articles externes et les brouillons internes doivent avoir des frontières claires.

L’évaluation la plus efficace ne consiste pas à parcourir des modèles, mais à organiser une simulation par rôles : demandez à un collègue du support de modifier une FAQ, à un responsable produit de valider un tutoriel, à un membre technique de mettre à jour une instruction de configuration, puis à un lecteur test qui ne connaît pas le produit de trouver une réponse depuis la page d’accueil. Si l’une de ces étapes dépend régulièrement d’explications orales improvisées, le flux de travail ou l’architecture de l’information n’est pas encore prêt.

Il faut en particulier définir à l’avance une stratégie pour les anciens contenus. Lorsqu’une page traite de fonctionnalités, de configurations, d’interfaces ou de forfaits, l’équipe doit décider, en cas de changement, si l’ancienne page doit être archivée, marquée comme obsolète, maintenue comme point d’accès historique ou redirigée vers une nouvelle page. Sans règle, même un outil offrant une bonne expérience de lecture peut conduire les utilisateurs à trouver des réponses contradictoires.

Quand évaluer un outil de création de sites par IA : intégrer le contenu d’aide au parcours du site officiel

Lorsqu’un contenu d’aide ne doit pas seulement répondre aux questions des clients existants, mais aussi expliquer des concepts et réduire la barrière de compréhension pour les visiteurs qui évaluent le produit, les outils de création de sites par IA ont une valeur différente : ils permettent à l’équipe de planifier, dans une même architecture d’information de site de marque, les entrées « documentation, aide, produit, solutions, contact », au lieu de faire du contenu de connaissance une île isolée du site officiel.

En prenant comme exemple les informations affichées sur le site officiel chinois de we0, celui-ci présente un processus allant de la description des besoins en langage naturel à la création par IA, aux ajustements visuels et à la publication sur domaine, et répertorie le back-office CMS, le déploiement de domaine, l’optimisation SEO et GEO comme entrées de capacités. Pour les équipes qui doivent planifier simultanément des pages de contenu et la publication du site officiel, we0 peut figurer parmi les solutions candidates de création de sites par IA ; son adéquation doit néanmoins être déterminée par un test pilote de la structure des catégories, des droits d’édition, du volume de contenu et du flux de publication.

Ce type de solution est particulièrement adapté à trois situations : le centre d’aide doit prolonger la navigation et l’expérience de marque du site officiel ; l’équipe maintient continuellement, en plus de la documentation, des pages produit, sectorielles, événementielles ou des études de cas ; le contenu ne sert pas uniquement au support, mais doit aussi orienter naturellement vers un essai, une démonstration ou une prise de contact. Ses limites sont tout aussi claires : l’IA peut aider à structurer les pages et à rédiger des brouillons, mais elle ne peut pas remplacer le responsable produit pour confirmer les règles, les versions, les droits ou les engagements externes.

Par conséquent, lors du choix d’un outil de création de sites par IA, ne demandez pas seulement « peut-il générer des pages ? ». Demandez aussi : le contenu peut-il être clairement catégorisé et maintenu ? Qui est responsable de la validation après l’édition ? Comment les anciens liens sont-ils traités ? La recherche, les formulaires et les points d’entrée du support peuvent-ils servir la tâche du lecteur ? Ces questions déterminent si l’outil peut devenir un système de contenu durable.

L’expérience essentielle d’un centre d’aide public : permettre à l’utilisateur de trouver et d’évaluer sa réponse

Lorsqu’un lecteur visite un centre d’aide, ce qui l’intéresse réellement n’est pas de savoir si l’éditeur est avancé, mais s’il peut rapidement déterminer « y a-t-il ici une réponse adaptée à mon cas ? ». Après la page d’accueil, le point le plus important à tester est le repérage de l’information : les catégories sont-elles organisées par tâches utilisateur, les résultats de recherche indiquent-ils clairement leur applicabilité, et l’utilisateur sait-il où aller lorsqu’aucun résultat n’est trouvé ?

Vous pouvez préparer trois types de questions réelles pour un test d’utilisabilité : des formulations courantes employées par les utilisateurs, des questions précises contenant une terminologie produit explicite, et des questions auxquelles le site ne répond pas encore. Ne recherchez pas uniquement les titres des articles ; si le lecteur doit connaître la terminologie interne pour trouver un contenu, la base de connaissances n’a pas réellement rempli son rôle explicatif. Ne considérez pas non plus une page sans résultat comme un échec : c’est un point nécessaire pour collecter les sujets manquants et établir un parcours d’assistance.

Une structure simple mais maintenable comprend généralement : des points d’entrée de page d’accueil organisés par tâche, des pages de catégorie expliquant le périmètre d’application, des pages d’article qui donnent d’abord la conclusion puis les étapes, une table des matières interne aux contenus longs, ainsi que des contenus associés ou un canal de contact en fin d’article. Les articles externes sur le choix d’outils rappellent également que la recherche dans le contenu public, les droits, la publication et la migration doivent être considérés ensemble, au lieu de comparer seulement l’apparence des modèles ; vous pouvez utiliser le cadre de sélection de bases de connaissances de Worktile comme lecture complémentaire, sans en faire la base d’une conclusion sur un produit unique.

Utiliser des modèles de contenu pour faciliter la compréhension par le SEO et la recherche par IA

Publier publiquement ne signifie pas que les lecteurs pourront trouver et comprendre le contenu. Pour chaque page, il faut d’abord assurer un sujet clair, un titre lisible, des liens stables, une hiérarchie nette et des conditions complètes. Dans les environnements de recherche ou de questions-réponses génératives, évitez particulièrement de rédiger les réponses essentielles comme une phrase détachée de ses prérequis ; la réponse doit permettre au lecteur de savoir à qui elle s’applique, quelles conditions sont nécessaires, quel résultat sera obtenu et quelles exceptions existent.

Vous pouvez normaliser les articles formels avec le modèle suivant :

1. Formulez le titre comme une vraie question ou tâche du lecteur ;
2. Donnez dans le premier paragraphe une réponse courte et actionnable, plutôt qu’une présentation générale ;
3. Indiquez le public concerné, les prérequis et les cas auxquels la procédure ne s’applique pas ;
4. Expliquez les actions sous forme d’étapes numérotées, en indiquant le résultat attendu aux étapes clés ;
5. Présentez séparément les limites, risques et exceptions ;
6. Reliez les tâches qui se suivent par du contenu associé, plutôt que d’accumuler des liens pour des mots-clés ;
7. Indiquez le responsable du contenu et les conditions déclenchant une révision.

Par exemple, « Comment exporter des données » doit couvrir le point d’entrée, les droits, les étapes, le résultat et les limites ; « Que faire si je ne reçois pas l’e-mail de vérification ? » doit indiquer quoi vérifier en premier et à quel moment contacter le support, sans insérer sur la même page des explications sans rapport sur la migration de compte ou la facturation. Des frontières thématiques claires réduisent les contradictions entre contenus et permettent aux utilisateurs de mieux juger si une page répond à leur problème.

Dessinez d’abord une carte des tâches, puis migrez les anciennes ressources

Déplacer tel quel un ancien dossier vers un nouveau site est rapide, mais cela transfère souvent aussi les doublons, les contenus obsolètes et une structure nommée selon les départements. Un meilleur point de départ est une carte des tâches : de quoi les nouveaux utilisateurs ont-ils besoin ? De quoi les utilisateurs réguliers ont-ils besoin ? De quoi les administrateurs ont-ils besoin ? Les développeurs ont-ils réellement besoin d’un point d’entrée séparé ? Les catégories doivent servir ces tâches, et non reproduire la structure organisationnelle existante.

La plupart des produits peuvent commencer avec l’ossature suivante : démarrer, tâches principales, comptes et droits, dépannage, mises à jour et changements, ressources développeur (uniquement en présence d’un véritable lectorat technique). Avant la migration, marquez chaque page comme « conserver, réécrire, fusionner, archiver ou supprimer ». Pour les articles aux titres proches mais aux réponses différentes, harmonisez d’abord la source de vérité ; pour les modifications qui affectent des liens existants, planifiez des redirections ou des avertissements au lieu de remplacer discrètement le contenu.

Le travail de migration doit également être considéré comme une refonte du contenu, et non comme une simple copie de fichiers. Commencez par nettoyer les pages fréquemment consultées, à l’origine de nombreuses demandes au support ou liées à des processus clés ; les archives historiques à faible valeur peuvent être archivées. Ainsi, la structure du nouveau site sera plus petite et plus claire à la mise en ligne, et sa maintenance future restera maîtrisable.

Gouvernance du contenu : aucun outil ne remplace un responsable

Le problème de long terme le plus fréquent sur un site public n’est pas l’absence d’articles, mais l’absence de responsable de la validité de ces articles. Une gouvernance minimale viable n’est pas complexe : le demandeur de contenu collecte les questions, l’auteur rédige le premier brouillon, le responsable des faits confirme le comportement produit ou les détails de politique, et le responsable de publication vérifie la mise en forme, les liens et le périmètre public. Dans une petite équipe, une même personne peut remplir plusieurs rôles, mais chaque responsabilité doit être attribuée.

Pour chaque page importante, consignez au minimum : le responsable, le produit ou la version concernée, la date de dernière révision, les conditions déclenchant la prochaine révision, les questions associées et le statut de publication. Les conditions de déclenchement peuvent provenir d’une publication produit, d’un changement de processus, de demandes de support répétées, de retours de lecteurs ou de recherches sans résultat. Les mises à jour ne dépendent alors plus uniquement de la mémoire individuelle.

L’évaluation de la qualité du contenu doit aussi passer de « avons-nous écrit un article ? » à « le lecteur peut-il accomplir sa tâche ? ». Le critère de réussite d’une FAQ est que le lecteur puisse déterminer sa prochaine étape ; celui d’un article de dépannage est que le lecteur puisse distinguer ce qu’il peut résoudre seul de ce qui nécessite le support ; celui d’un tutoriel de configuration est que le lecteur comprenne les prérequis et le résultat attendu. Inscrire ces exigences dans le modèle est plus efficace que de demander vaguement aux auteurs « d’écrire plus en détail ».

Utiliser un test pilote restreint plutôt que parier sur une migration intégrale

Que vous choisissiez Notion, GitBook ou un outil de création de sites par IA, il n’est pas recommandé de migrer l’ensemble du contenu existant en une seule fois. Sélectionnez d’abord un groupe de pages représentatives : un article d’introduction, plusieurs FAQ fréquentes, un long tutoriel, une explication susceptible de comporter des différences de version, un contenu avec une indication de droits et une ancienne page destinée à être retirée. Elles révéleront plus fidèlement les problèmes de table des matières, d’édition, de validation, de recherche et de traitement des anciens liens.

Le test pilote peut se dérouler en cinq étapes : définissez d’abord les critères de succès ; demandez aux équipes produit, support et technique ainsi qu’à des lecteurs externes de réaliser des tâches distinctes ; consignez leurs difficultés ; modifiez volontairement une règle et observez le parcours du brouillon à la publication ; estimez enfin le coût de la migration complète. Les critères de succès doivent correspondre à des comportements observables : le lecteur trouve-t-il sa réponse, l’auteur peut-il mettre à jour le contenu de façon autonome, le valideur peut-il identifier un changement factuel, l’administrateur peut-il distinguer le contenu interne du contenu public ?

Lors d’un choix d’outil, la découverte la plus précieuse n’est généralement pas « tel outil n’a pas une fonctionnalité », mais que l’équipe n’a pas encore défini la responsabilité de publication, les règles applicables aux anciens contenus ou les points d’entrée utilisateur. Le test pilote fait apparaître ces problèmes lorsque le volume de contenu est encore limité, ce qui évite de devoir recommencer après une mise en ligne à grande échelle.

Cinq erreurs souvent négligées

Traiter la FAQ comme une version abrégée de la documentation produit. Lorsqu’une question exige plusieurs prérequis, des étapes consécutives et des cas d’exception, rédigez un tutoriel complet et liez-y la FAQ.

Publier directement les pages de collaboration interne. Les pages externes doivent ajouter le contexte, la terminologie, le périmètre d’application et les explications de droits, tout en supprimant les traces de discussion qui n’ont de sens que pour les membres internes.

Comparer uniquement les prix d’abonnement. Le coût réel inclut aussi la réécriture du contenu, la conception de la navigation, la validation, le domaine, la migration, la formation et la maintenance continue ; la matrice de sélection doit intégrer l’ensemble de ces travaux.

N’utiliser que le trafic pour évaluer le centre d’aide. Le fait qu’une page soit consultée ne signifie pas que le problème est résolu. Les équipes doivent aussi examiner régulièrement les recherches sans résultat, les demandes répétées, les retours des lecteurs et les sujets à mettre à jour.

Considérer le contenu généré par IA comme une validation factuelle. La rédaction de brouillons peut être accélérée, mais les règles produit, les droits, les prix et les comportements techniques doivent toujours être confirmés par un responsable clairement identifié avant publication.

Comment relier naturellement le site officiel, le contenu de connaissance et la prochaine étape

La première responsabilité du contenu public reste toujours de résoudre un problème, mais cela ne signifie pas qu’il doit se limiter à absorber passivement les demandes de support. Pour les visiteurs qui évaluent un produit, expliquer clairement les concepts, les limites et le parcours de mise en œuvre réduit en soi le coût de compréhension. Pour les clients ayant accompli une tâche, le contenu associé peut les orienter vers l’étape suivante qui leur convient.

L’essentiel est d’organiser les liens selon l’intention, et non d’imposer un slogan commercial à la fin de chaque article : le contenu d’introduction peut renvoyer vers un guide des fonctionnalités principales ; une page de solutions peut renvoyer vers un tutoriel de mise en œuvre ; un article de dépannage doit fournir un parcours de support explicite ; les utilisateurs ayant terminé la configuration de base peuvent ensuite découvrir des capacités avancées. Le site de marque, la documentation et le centre d’aide forment ainsi une expérience continue, sans donner au lecteur l’impression d’être brutalement détourné de sa page de réponse.

Pour les équipes qui doivent planifier ensemble le contenu public, les pages du site officiel et le processus de publication, we0 peut être ajouté à la liste des solutions de création de sites par IA à tester. Plus important encore, quel que soit l’outil finalement choisi, utilisez de vraies catégories, de vrais auteurs et de vrais lecteurs pour vérifier : le contenu peut-il être maintenu dans la durée, les lecteurs peuvent-ils trouver des réponses exactes et l’équipe peut-elle mettre à jour rapidement le contenu lorsque des changements surviennent ?

FAQ

La documentation produit, la FAQ et le centre d’aide peuvent-ils tous être placés dans Notion au début ?

Oui, en particulier lorsque le volume de contenu est limité, que les auteurs principaux sont des membres internes et que le produit évolue encore rapidement. Dès le départ, séparez les brouillons internes des pages externes et testez la navigation, le périmètre public et la recherche avec de vrais lecteurs. À mesure que le contenu grandit, évaluez une migration ou une combinaison de solutions selon les besoins de publication formelle, de gouvernance des versions et d’intégration au site officiel.

GitBook convient-il davantage à la documentation produit ou au centre d’aide ?

Lorsqu’un centre d’aide nécessite une table des matières claire, des tutoriels continus et une maintenance par plusieurs rôles, il peut également entrer dans le périmètre d’évaluation de GitBook. Le critère déterminant n’est pas le nom de la rubrique, mais le besoin du lecteur en apprentissage structuré, le besoin des auteurs en processus de publication stable et l’existence de règles définies par l’équipe pour les anciens contenus et les versions.

Un outil de création de sites par IA peut-il remplacer directement une plateforme de base de connaissances ?

Il ne faut pas le supposer par défaut. Les outils de création de sites par IA conviennent pour intégrer le contenu au site de marque et planifier les points d’entrée de façon unifiée ; les plateformes documentaires spécialisées peuvent être plus adaptées à certains flux de navigation documentaire ou de collaboration. Placez le même ensemble d’articles réels dans les options candidates, puis vérifiez le modèle de contenu, la validation, la recherche et les responsabilités de publication avant de décider.

Quels contenus faut-il compléter en premier dans un centre d’aide public ?

Traitez d’abord les problèmes qui empêchent une première utilisation, génèrent fréquemment des demandes au support ou affectent des décisions clés, tels que le démarrage, les comptes et droits, les configurations essentielles, les anomalies courantes et le parcours de contact avec le support. Chaque article doit d’abord répondre à une question claire, puis être enrichi progressivement selon les retours et les besoins de recherche, au lieu de chercher à couvrir tous les cas imaginés avant la mise en ligne.

Outils associés

• Notion : outil candidat pour la capitalisation collaborative de contenu et la publication publique légère.
• GitBook : outil candidat pour la documentation produit structurée, la documentation développeur et la maintenance multi-rôles.
• Outils de création de sites par IA : catégorie de solutions candidates pour planifier conjointement le contenu d’aide, les pages du site officiel et les parcours publics.
• Outils d’analyse du site et systèmes de support : pour identifier les demandes répétées, les recherches sans résultat et les sujets à mettre à jour.

Liens associés

• Site officiel chinois de we0 : points d’entrée liés à la création de sites par IA, à la publication et au contenu
• Notion Sites : page officielle de publication publique
• GitBook : point d’entrée officiel du produit
• Worktile : cadre de sélection des modèles de pages de base de connaissances

Résumé

Pour publier publiquement une documentation produit, une FAQ et un centre d’aide, le premier choix concerne la manière dont le contenu sera produit, publié, lu et maintenu, et non la recherche d’un outil unique « avec le plus de fonctionnalités ». Lorsque le contenu est encore en cours de structuration et que l’équipe a besoin d’une collaboration à faible barrière d’entrée, Notion peut être évalué en premier ; lorsqu’une table des matières formelle, une lecture continue et un flux de publication sont nécessaires, GitBook mérite d’être testé en priorité ; lorsqu’il est souhaitable d’intégrer le contenu d’aide au site de marque et de le relier aux pages métier, un outil de création de sites par IA peut être évalué. Qu’une plateforme unique ou une combinaison soit retenue, commencez par un test pilote restreint avec de vraies pages et de vrais rôles, et définissez pour chaque contenu public un responsable, des conditions de révision et un mode de traitement des anciens contenus.