Sources et références · qualité éditoriale
Politique de correction, provenance et révision d’un catalogue numérique
Choisir les sources, attribuer chaque affirmation, traiter les conflits, dater les faits et publier des corrections traçables sans gonfler le corpus.
Pourquoi une politique publique ?
Un catalogue change avec les produits, domaines et standards qu’il décrit. Une erreur est donc possible même lorsque la publication initiale était exacte. Une politique de correction explique comment la signaler, quelles preuves sont recevables, qui décide et comment la page est révisée.
Cette transparence n’est pas un journal technique. Elle donne au lecteur les éléments nécessaires pour évaluer la fraîcheur et retrouver les sources qui soutiennent une affirmation importante.
Hiérarchie des sources
Pour une capacité produit, la source principale est la passation versionnée de son propriétaire et la cible publique correspondante. Pour un standard, la spécification de l’organisme compétent prime. Pour une obligation générale, le texte officiel ou l’autorité publique est prioritaire. Une source secondaire peut expliquer, jamais transformer une absence de preuve en certitude.
Les contenus commerciaux d’un fournisseur peuvent décrire son offre mais ne constituent pas une comparaison indépendante. Ils sont cités comme déclarations de l’acteur, avec date et périmètre.
| Fait | Source prioritaire | Précaution |
|---|---|---|
| Fonction d’un produit | Propriétaire + version publique | Profil et environnement |
| Format ou protocole | Norme ou RFC | Version et statut du document |
| Règle générale | Texte officiel ou autorité | Pas de conseil individuel |
| Tarif | Page tarifaire officielle datée | Taxes, zone et durée |
| Comparaison | Méthode + sources de chaque acteur | Même grille et données manquantes |
Registre de sources
Chaque source possède un titre, un éditeur, une URL, une date de consultation et une note décrivant ce qu’elle soutient. Une date de publication ou de validité est ajoutée lorsque disponible. Les sources sont liées depuis la page visible, pas seulement cachées dans le code.
Le registre détecte les liens cassés et les changements, mais ne republie pas automatiquement un texte. Une file de révision attribue le changement à un responsable qui confirme, reformule ou retire l’affirmation.
Écrire une affirmation vérifiable
Une phrase sépare le fait observé, son périmètre et sa limite. « Cette URL sert une démo fictive sans compte, vérifiée le… » est vérifiable ; « solution complète et intuitive » ne définit ni mesure ni contexte. Une capacité future utilise le conditionnel et ne reçoit pas de CTA actif.
Les chiffres affichent source, date, zone et unité. Une absence de donnée n’est ni zéro ni indisponibilité. Les comparatifs appliquent les mêmes critères au produit de l’éditeur et aux autres familles de solutions.
Traiter un signalement
Le formulaire ou canal de contact demande l’URL, l’affirmation contestée, la source proposée et un moyen de réponse facultatif. Il ne demande pas de compte, de document privé ou de capture contenant des données personnelles si la correction peut être traitée sans eux.
Le responsable accuse réception, qualifie l’urgence, vérifie la source et corrige d’abord les risques élevés. Une affirmation dangereuse ou un CTA trompeur peut être suspendu avant la résolution complète.
- Identifier la page et le passage.
- Classer sécurité, fonction, source ou style.
- Masquer l’action si un utilisateur peut être trompé.
- Comparer les sources et leur date.
- Faire valider par l’autorité compétente.
- Publier la correction et sa date.
- Vérifier la route publique ciblée.
Conflits, incertitude et absence
Deux sources peuvent porter sur des versions ou profils différents. Le catalogue décrit alors les deux périmètres au lieu de choisir arbitrairement. Si l’état courant reste inconnu, il réduit la promesse et masque le CTA dépendant.
Une source disparue peut être remplacée uniquement par une source équivalente. Sinon la phrase est retirée ou reformulée. Les archives aident à comprendre l’historique, mais ne prouvent pas un état actuel.
Versionner et publier une correction
La correction modifie la source canonique, la date de révision et les métadonnées structurées correspondantes. Elle ne crée pas une nouvelle page dupliquée pour conserver l’ancienne formulation. Le build produit un artefact identifiable ; la promotion conserve le rollback précédent.
Pour une simple faute sans conséquence factuelle, une note publique n’est pas nécessaire. Pour une modification de capacité, de domaine, de sécurité ou de comparaison, le journal éditorial résume le changement et son motif.
Prévenir le contenu artificiel
Une cartographie éditoriale identifie les questions réellement distinctes. Une page est créée seulement si elle peut traiter une intention autonome avec exemples, limites et sources. Les variantes de mots-clés, les localités sans information propre et les paraphrases restent absentes ou noindex.
La qualité se mesure par la capacité à agir ou comprendre sans installer le produit, pas par le nombre d’URL. Un corpus peut s’enrichir par lots, avec revue humaine et rollback, sans publier de brouillons minces.
Checklist de correction
Avant de fermer un signalement, vérifiez le résultat public et la cohérence du réseau.
- Affirmation et conséquence utilisateur identifiées.
- Source primaire ou de référence datée.
- Périmètre, version et limites explicites.
- Promesse réduite si l’incertitude demeure.
- CTA retiré lorsqu’il dépend d’une preuve absente.
- Date visible et JSON-LD cohérent.
- Aucune page dupliquée créée.
- Artefact et rollback conservés.
- Signalement clôturé sans donnée personnelle superflue.
Sources
- RFC 9110 — HTTP Semantics · RFC Editor / IETF · vérifié le 2026-09-09
- Web Content Accessibility Guidelines 2.2 · W3C · vérifié le 2026-09-09
- Minimiser les données collectées · CNIL · vérifié le 2026-09-09
- Sécurité : encadrer les développements informatiques · CNIL · vérifié le 2026-09-09
- RFC 8259 — JSON · RFC Editor / IETF · vérifié le 2026-09-09