Avant de confier une rédaction, remplissez et approuvez une fiche d’une page comprenant neuf champs : public visé, question utilisateur, rôle de la page, message clé, preuves requises, action souhaitée, format, responsable et date de révision. Commencez toutefois par comparer la demande au contenu, aux outils, aux transactions et aux autres points de service qui existent déjà. La conclusion peut être d’actualiser, de regrouper, de rediriger, de refuser ou de créer. Un titre proposé, une envie de vidéo ou une échéance interne ne transforme donc pas automatiquement une demande en mandat de rédaction.
À retenir
Une demande devient un mandat de rédaction seulement lorsque le besoin documenté et le rôle distinct de la page tiennent la route.
La bonne décision peut être d’actualiser, de regrouper, de rediriger, de refuser ou de créer.
La fiche couvre le public, la question, le rôle, le message, les preuves, l’action, le format, la responsabilité et la révision.
L’action souhaitée peut être de comprendre, comparer, décider, repérer ou poursuivre une tâche, pas seulement de convertir.
La fiche encadre une décision; elle ne remplace pas la recherche, l’accessibilité, la vérification ni l’expertise spécialisée.
Pourquoi établir la raison d’être de la page avant de rédiger?
Il faut décider avant de rédiger parce qu’une équipe doit confirmer un besoin valide, un rôle distinct, les preuves nécessaires, le résultat attendu et la responsabilité d’entretien avant de traiter la demande comme un travail de rédaction. Sinon, la personne qui écrit doit deviner le public, la question centrale, les limites du sujet et le rapport avec les pages existantes. Un texte peut alors être bien tourné tout en demeurant mal mandaté ou en rivalisant avec une réponse qui existe déjà.
La fiche en neuf champs constitue une synthèse éditoriale réutilisable, et non une norme officielle. Elle réunit des principes de besoin utilisateur, de planification du contenu et de gestion du cycle de vie afin de rendre les hypothèses visibles et la décision vérifiable. Elle donne aussi aux parties prenantes des critères pour évaluer la future ébauche. Elle ne remplace pas la découverte, la recherche utilisateur, le travail d’accessibilité, la vérification factuelle, l’évaluation technique ou l’approbation d’un spécialiste.
Canevas de fiche de mandat de page
Champ
Question à remplir
Vérification avant approbation
Public visé
Qui se trouve dans la situation que la page doit servir?
La tâche, la situation ou le niveau de connaissance modifie réellement le contenu.
Question utilisateur
Quelle question ou tâche documentée faut-il résoudre?
La formulation vient du public et peut être reliée à des preuves.
Rôle de la page
Quel travail unique la page accomplit-elle dans le parcours?
Une page, un outil, une transaction ou un autre canal existant ne le fait pas mieux.
Message clé
Quelle conclusion essentielle le public doit-il retenir?
La conclusion est précise, utile à la tâche et soutenable.
Preuves requises
Qu’est-ce qui prouve le besoin et chacune des affirmations prévues?
Les sources, données, dossiers et validations nécessaires sont nommés.
Action souhaitée
Que pourra comprendre, décider, faire ou atteindre le public ensuite?
Le résultat est observable sans être artificiellement réduit à une conversion.
Format
Quelle forme sert le mieux la tâche et le moment du parcours?
Le format découle du besoin plutôt que d’une préférence interne.
Responsable
Qui répondra de l’exactitude et de l’entretien?
Une personne ou une équipe imputable est nommée, distinctement des autres rôles.
Date de révision
Quand et à quel changement connu la prochaine vérification est-elle liée?
Une date et, si possible, son déclencheur sont consignés.
Que faut-il vérifier avant d’approuver une nouvelle page?
Avant d’approuver une page, cherchez où le même besoin est déjà pris en charge dans le site et dans le parcours complet. Examinez les pages, les outils, les formulaires, les transactions, la documentation de soutien et les autres canaux pertinents. Les orientations de GOV.UK recommandent justement de repérer tôt le contenu actualisable, les répétitions et les renseignements manquants. Des réponses semblables peuvent brouiller la source faisant autorité, mais la proximité thématique ne commande pas automatiquement une fusion.
Actualiser lorsque la page existante possède déjà le besoin et le rôle.
Regrouper lorsque plusieurs fragments se disputent une même réponse.
Rediriger ou retirer lorsque la source devenue désuète n’est plus celle qui fait autorité.
Refuser lorsque ni le besoin ni un rôle distinct ne sont suffisamment documentés.
Créer seulement lorsque le besoin, le rôle, les preuves, l’action, le format, le responsable et la révision forment une proposition cohérente.
Évitez cependant une consolidation mécanique. Une courte consigne répétée au point d’utilisation peut aider une personne à poursuivre une transaction sans quitter son contexte; elle n’équivaut pas à maintenir deux pages complètes comme sources concurrentes. La vérification peut également révéler qu’une modification de l’outil, de la transaction ou d’un canal hors Web répondrait mieux au besoin. La fiche doit pouvoir consigner cette conclusion au lieu de forcer chaque problème dans une nouvelle page.
Ne demandez pas d’abord à la rédaction de produire une page; demandez à l’organisation de justifier le travail de cette page.
Comment définir le public visé et la question utilisateur?
Définissez le public par la tâche, la situation ou le niveau de connaissance qui change réellement ce que la page doit accomplir, puis formulez la question centrale dans des mots qu’il reconnaîtrait. « Tous les clients » ne donne aucune indication exploitable. « Administrateurs clients qui préparent leur première configuration » précise plutôt le contexte et les connaissances probables. Une question centrale peut contenir des sous-questions étroitement liées, pourvu que l’ensemble corresponde à un besoin cohérent que la même ressource peut raisonnablement résoudre.
Appuyez cette définition sur des traces pertinentes : recherche antérieure, demandes au centre de soutien, données analytiques, entrevues ou données externes adaptées au problème. Ces sources ne sont pas interchangeables. Le volume de visites révèle une activité, mais ne suffit pas à expliquer l’intention ni à démontrer qu’une page supplémentaire est nécessaire. Une préférence de partie prenante, un titre de travail ou un format déjà choisi demeure une hypothèse de solution tant que le besoin sous-jacent n’est pas validé.
Comment articuler le rôle, le message clé et les preuves requises?
Ces trois champs doivent former une chaîne logique : le rôle décrit la contribution unique de la page au parcours, le message clé énonce la conclusion essentielle et les preuves requises établissent ce qui permettra de soutenir cette conclusion. Le rôle doit aussi expliquer pourquoi une ressource existante, une transaction, un outil ou un autre canal ne remplit pas mieux la fonction. Le message n’est ni un slogan ni un titre provisoire; il correspond à la substance que le public doit saisir avant les détails.
Distinguez deux familles de preuves. La première montre que la page répond à un besoin réel; la seconde étaye les affirmations qui paraîtront dans le contenu, par exemple des dossiers à jour, des données internes contrôlées ou la validation du spécialiste responsable. Dans un parcours de soutien, une courte page peut expliquer les préalables avant qu’un administrateur ouvre un outil de configuration. La page clarifie alors la préparation, tandis que l’outil demeure l’endroit où la configuration est effectuée.
Au moment de publier, comparez le titre, le titre principal et l’ouverture au mandat. Le critère WCAG 2.4.2 exige que le titre d’une page en décrive le sujet ou la fonction; le W3C souligne qu’un titre descriptif aide à reconnaître, distinguer et évaluer une page. Cette vérification confirme la cohérence avec le message clé, mais elle ne suffit pas à démontrer que l’ensemble de la page est accessible.
Comment l’action souhaitée doit-elle guider le format?
L’action souhaitée doit nommer ce que le public pourra comprendre, comparer, décider, repérer, faire ou atteindre ensuite, puis le format doit être choisi en fonction de ce résultat. Traitez cette action comme une condition d’acceptation pratique : elle aide à vérifier si le contenu remplit son mandat. Elle n’est pas nécessairement une vente, une piste commerciale ou l’envoi d’un formulaire. Une personne peut simplement devoir reconnaître sa situation, choisir une option ou poursuivre une tâche au bon endroit.
Choisissez ensuite entre une explication, une marche à suivre, une comparaison, une référence, une vidéo, une étape transactionnelle, un outil ou une autre forme justifiée. Les orientations disponibles établissent le principe selon lequel le type de contenu et son emplacement suivent le public, la tâche et le parcours; elles ne fournissent pas une taxonomie universelle pour tous les sites B2B. Si un changement à l’outil ou un canal non Web accomplit mieux le travail, inscrivez cette décision au dossier.
Qui est responsable de la page, et quand faut-il la réviser?
Nommez une personne ou une équipe imputable de l’exactitude et de l’entretien, puis consignez séparément les personnes qui contribuent, vérifient ou approuvent. La gouvernance du contenu couvre sa création, son entretien, sa mise à jour et son retrait; la vérification spécialisée et les approbations y demeurent des fonctions distinctes. Le responsable coordonne donc le travail sans remplacer les spécialistes de l’accessibilité, du droit, de la réglementation, des données, de la technique ou du domaine lorsque leur jugement est requis.
Fixez la prochaine révision selon les changements connus, la volatilité du sujet, le risque, l’état des preuves et les engagements de publication, plutôt qu’avec une cadence universelle. Notez le déclencheur avec la date lorsque c’est pratique : nouvelle version d’un produit, remplacement d’une politique interne ou échéance d’une donnée, par exemple. Un dossier de publication peut signaler une révision échue et soutenir une décision d’actualiser, de corriger, de regrouper, de rediriger ou de retirer. Le point de contrôle ne garantit toutefois pas son exécution.
À quoi ressemble une fiche en neuf champs dûment remplie?
Une fiche complète tient en peu de mots, mais chaque champ doit être assez précis pour permettre une décision. Prenons le cas hypothétique d’une équipe de soutien B2B qui envisage une page avant un outil de configuration. L’exemple ne suppose aucun gain de trafic, de conversion, de temps ou de coût. Dans une situation réelle, l’équipe devrait remplacer chaque hypothèse par des preuves propres à son produit, à son public et à son parcours.
Public visé : administrateurs clients qui préparent la configuration d’une intégration prise en charge.
Question utilisateur : que faut-il confirmer avant de commencer la configuration?
Rôle de la page : expliquer les préalables avant l’accès à l’outil de configuration.
Message clé : confirmer les accès, la compatibilité et les dossiers requis avant de commencer.
Preuves requises : documentation actuelle, dossiers de soutien révélant la question et validation du spécialiste produit.
Action souhaitée : décider si l’organisation est prête, puis rejoindre le bon outil ou le bon service de soutien.
Format : courte marche à suivre accompagnée d’une liste de vérification des préalables.
Responsable : équipe du contenu de soutien, avec réviseurs produit et accessibilité nommés.
Date de révision : prochain contrôle planifié, lié à un déclencheur documenté de mise à jour du produit.
Avant d’autoriser la rédaction, demandez si les preuves appuient le public et la question, si la décision retenue et le rôle sont distincts, si le message et les preuves concordent, si l’action a du sens, si le format est justifié et si une responsabilité ainsi qu’une révision ont été acceptées. Toute réponse importante qui demeure incohérente ou non étayée devrait ramener la demande à la recherche ou à la révision. Le mandat peut être approuvé lorsque ces éléments et l’engagement de cycle de vie tiennent ensemble.
Questions fréquentes
Qu’est-ce qu’une fiche de mandat de page?
C’est un court dossier décisionnel interne préparé avant la rédaction. Il relie le public, la question, le rôle, le message, les preuves, l’action, le format, la responsabilité et la révision afin que l’organisation puisse justifier le travail demandé à la page.
Que doit contenir un mandat de contenu Web?
Le canevas proposé comprend neuf champs : public visé, question utilisateur, rôle de la page, message clé, preuves requises, action souhaitée, format, responsable et date de révision. Il s’agit d’une synthèse éditoriale pratique, pas d’une norme universelle officielle.
Comment préparer un mandat de contenu avant la rédaction?
Vérifiez d’abord le contenu et le parcours existants, puis validez le besoin et remplissez les neuf champs. Choisissez ensuite d’actualiser, de regrouper, de rediriger, de refuser ou de créer, et faites approuver cette décision avant d’attribuer l’ébauche.
Chaque besoin utilisateur exige-t-il une nouvelle page Web?
Non. Une page existante, un regroupement, une redirection, une modification transactionnelle, un outil ou un canal non Web peut mieux servir le besoin; une demande insuffisamment étayée peut aussi être refusée.
À quelle fréquence faut-il réviser le contenu d’un site Web?
Il n’existe pas d’intervalle universel convenant à toutes les pages. Fixez le prochain contrôle selon les changements connus, la volatilité, le risque, les preuves disponibles et les engagements de l’organisation, puis consignez la date et son déclencheur lorsque c’est possible.
Références et sources
Cet article a été préparé à partir des sources suivantes :
Nous couvrons les décisions qui façonnent un site Web longtemps après sa mise en ligne. Nous partons de sources nommées, distinguons nos constats de nos opinions et utilisons l’IA pour la recherche et la rédaction selon des normes éditoriales documentées. Nous divulguons les relations commerciales partout où elles existent.