Méthodologie éditoriale et politique des sources

Cette page présente la méthode utilisée pour concevoir, vérifier et maintenir les contenus du site.

Elle précise notamment :

• comment les sujets sont sélectionnés ;
• comment les articles sont structurés ;
• quelles sources sont privilégiées ;
• comment les informations sont vérifiées ;
• comment les contenus sont actualisés ;
• quel rôle peuvent jouer les outils d’intelligence artificielle ;
• comment les erreurs sont corrigées.

L’objectif est de rendre le processus éditorial aussi transparent que les systèmes de connaissances décrits dans les articles.

Un contenu consacré à la connaissance doit lui-même conserver ses sources, ses limites et son contexte.

Objectifs éditoriaux

Les contenus poursuivent quatre objectifs principaux.

Expliquer

Présenter les notions de Knowledge Engineering dans un langage compréhensible.

Distinguer

Clarifier les différences entre des concepts proches.

Exemples :

• donnée, information et connaissance ;
• taxonomie et ontologie ;
• ontologie et graphe ;
• RAG et GraphRAG ;
• base vectorielle et graphe ;
• Knowledge Management et Knowledge Engineering.

Mettre en pratique

Proposer des méthodes, exemples, checklists et structures réutilisables.

Relier

Construire un parcours cohérent entre :

• les concepts fondamentaux ;
• les méthodes ;
• les technologies ;
• les cas d’usage ;
• les métiers.

Sélection des sujets

Un sujet peut être retenu lorsqu’il répond à au moins un des critères suivants :

• il est nécessaire à la compréhension du parcours ;
• il correspond à une question fréquente ;
• il complète une page existante ;
• il répond à une intention pratique distincte ;
• il aide à comparer plusieurs solutions ;
• il permet de traiter une difficulté de qualité ou de gouvernance.

Un nouveau contenu ne devrait pas être créé lorsqu’il répète simplement une page existante.

Vérification de l’intention

Avant la rédaction, le sujet est formulé sous forme de question.

Exemples :

Qu’est-ce qu’une ontologie informatique ?

Comment construire un système RAG fiable ?

Quelle différence existe-t-il entre une base vectorielle et un graphe ?

Cette question permet de définir :

• le public ;
• le niveau ;
• le périmètre ;
• les exemples ;
• les contenus voisins.

Construction du plan

Chaque article cherche à suivre une progression identifiable.

Structure fréquente :

Définition
  ↓
Composants
  ↓
Fonctionnement
  ↓
Exemple
  ↓
Méthode
  ↓
Limites
  ↓
Erreurs fréquentes
  ↓
Synthèse

Les guides pratiques suivent plutôt :

Problème
  ↓
Résultat attendu
  ↓
Étapes
  ↓
Tests
  ↓
Checklist

Niveau de langage

Les articles privilégient :

• des phrases explicites ;
• des termes définis ;
• des exemples concrets ;
• des tableaux comparatifs ;
• des relations représentées visuellement ;
• une progression pédagogique.

Les acronymes sont développés lors de leur première utilisation.

Exemple :

Retrieval-Augmented Generation, ou RAG

Utilisation des exemples

Les exemples servent à rendre une notion abstraite plus observable.

Les domaines fréquemment utilisés sont :

• la formation ;
• le support technique ;
• les produits ;
• les compétences ;
• les contrats ;
• la maintenance.

Ces exemples sont généralement fictifs.

Les noms comme :

Marie Dupont
Entreprise Alpha
Produit X200
Contrat 458

ne désignent pas nécessairement des personnes, entreprises ou produits réels.

Politique des sources

Les sources peuvent être classées selon plusieurs niveaux.

Sources officielles

Elles sont privilégiées pour :

• les standards ;
• les spécifications ;
• les logiciels ;
• les définitions institutionnelles ;
• les obligations réglementaires.

Exemples de familles de sources :

• organismes de normalisation ;
• documentation officielle ;
• publications institutionnelles ;
• documentation des projets ;
• textes réglementaires.

Publications scientifiques

Elles sont utilisées pour :

• les concepts ;
• les méthodes ;
• les évaluations ;
• les architectures ;
• les résultats de recherche.

Une publication ne doit pas être présentée comme une vérité définitive lorsque ses résultats restent débattus ou limités à un contexte.

Ouvrages de référence

Ils permettent de replacer les notions dans leur contexte historique et méthodologique.

Ils sont particulièrement utiles pour :

• la représentation des connaissances ;
• les systèmes experts ;
• l’ingénierie ontologique ;
• la logique ;
• le Web sémantique.

Documentation technique

Elle est utilisée pour expliquer :

• les logiciels ;
• les langages ;
• les formats ;
• les API ;
• les méthodes d’implémentation.

La version de la documentation doit être vérifiée lorsque le comportement peut évoluer.

Sources secondaires

Les articles, synthèses et tutoriels externes peuvent être utilisés pour :

• identifier un problème ;
• comparer des pratiques ;
• découvrir un exemple ;
• compléter une recherche.

Ils ne doivent pas remplacer une source primaire lorsqu’une affirmation importante peut être vérifiée directement.

Hiérarchie de vérification

Pour une affirmation technique ou normative, l’ordre de recherche recommandé est :

1. Source officielle
2. Standard ou publication primaire
3. Documentation du projet
4. Ouvrage de référence
5. Source secondaire spécialisée
6. Article généraliste

Cette hiérarchie peut varier selon le sujet.

Critères d’évaluation d’une source

Une source est évaluée selon plusieurs critères.

Autorité

Qui publie l’information ?

Pertinence

La source traite-t-elle précisément du sujet ?

Fraîcheur

La version ou la date est-elle encore applicable ?

Traçabilité

Les affirmations sont-elles elles-mêmes sourcées ?

Périmètre

La source concerne-t-elle le même contexte ?

Indépendance

Plusieurs sources se copient-elles sans apporter de vérification supplémentaire ?

Stabilité

La ressource est-elle susceptible de disparaître ou d’être modifiée ?

Vérification des affirmations

Les affirmations importantes doivent être rapprochées de leurs sources.

Une attention particulière est accordée aux éléments susceptibles d’évoluer :

• versions logicielles ;
• fonctionnalités ;
• normes ;
• recommandations ;
• interfaces ;
• réglementations ;
• chiffres ;
• pratiques de sécurité.

Les explications conceptuelles stables peuvent s’appuyer sur plusieurs références de fond.

Citations et liens

Une citation doit permettre au lecteur de retrouver la ressource.

Elle devrait identifier, selon le cas :

• l’auteur ;
• le titre ;
• l’organisme ;
• la version ;
• la section ;
• la date.

Les liens externes ne doivent pas être ajoutés uniquement pour augmenter leur nombre.

Chaque lien doit apporter :

• une preuve ;
• un approfondissement ;
• une documentation ;
• un outil ;
• un contexte historique.

Distinction entre fait et interprétation

Les articles doivent distinguer :

Le fait documenté

Le langage permet de représenter telle structure.

L’interprétation

Cette structure semble particulièrement adaptée à ce type de projet.

La recommandation

Pour un premier prototype, commencez par une solution plus simple.

Une recommandation doit être présentée comme un choix méthodologique, et non comme une règle universelle.

Gestion de l’incertitude

Lorsqu’une information n’est pas certaine, le texte doit utiliser une formulation adaptée.

Exemples :

peut permettre

est généralement utilisé

dans ce contexte

selon le modèle retenu

cette conclusion doit être validée

Évitez de transformer une tendance en obligation.

Actualisation des contenus

Chaque page importante devrait idéalement conserver :

• une date de publication ;
• une date de dernière révision ;
• une version ;
• un responsable ;
• une prochaine date de contrôle.

Exemple de front matter

---
title: "Comment construire un système RAG fiable"
status: "publié"
version: "1.2"
author: "[Nom]"
reviewed_by: "[Nom ou fonction]"
published_at: "2026-07-12"
last_reviewed_at: "2026-07-12"
next_review_at: "2027-01-12"
---

Déclencheurs de révision

Une page peut être révisée lorsqu’un événement survient :

• nouvelle version d’un standard ;
• nouvelle version d’un logiciel ;
• lien externe supprimé ;
• erreur signalée ;
• exemple devenu obsolète ;
• changement important du domaine ;
• nouvelle page créant un risque de répétition ;
• évolution du parcours éditorial.

Fréquence de révision

Une fréquence indicative peut être définie.

Type de contenu	Révision indicative
Notion fondamentale	Tous les 12 à 24 mois
Tutoriel logiciel	Tous les 3 à 6 mois
Architecture IA	Tous les 6 mois
Page comparative	Tous les 6 à 12 mois
Politique éditoriale	Une fois par an
Ressources et liens	Tous les 3 à 6 mois

Cette fréquence doit être adaptée au rythme d’évolution réel.

Utilisation de l’intelligence artificielle

Les outils d’IA peuvent assister plusieurs étapes.

Préparation

• génération de plans ;
• regroupement d’idées ;
• proposition d’exemples ;
• analyse de vocabulaire.

Rédaction

• reformulation ;
• simplification ;
• structuration ;
• production de variantes.

Contrôle

• détection de répétitions ;
• vérification de cohérence interne ;
• repérage de liens manquants ;
• proposition de questions fréquentes.

Ce que l’IA ne doit pas valider seule

• les faits techniques changeants ;
• les références ;
• les citations ;
• les règles métier ;
• les affirmations juridiques ou médicales ;
• les qualifications de l’auteur ;
• les résultats chiffrés ;
• les recommandations critiques.

Une réponse générée constitue une proposition de travail.

Elle ne devient un contenu validé qu’après contrôle.

Risques liés à l’utilisation de l’IA

Invention de sources

Un modèle peut produire une référence plausible mais inexistante.

Mélange de versions

Il peut combiner une ancienne documentation avec une nouvelle terminologie.

Généralisation excessive

Un cas particulier peut être présenté comme une règle générale.

Suppression d’une nuance

Une possibilité peut devenir une certitude.

Répétition

Plusieurs articles peuvent reprendre les mêmes paragraphes sous des titres différents.

Ton d’autorité

Une formulation très assurée peut masquer une information incertaine.

Processus éditorial recommandé

1. Définition du sujet
2. Vérification de l’intention
3. Recherche des sources
4. Construction du plan
5. Rédaction
6. Vérification des faits
7. Contrôle des répétitions
8. Vérification des liens
9. Relecture
10. Publication
11. Révision programmée

Contrôle avant publication

Contenu

• [ ] la question principale reçoit une réponse ;
• [ ] les termes sont définis ;
• [ ] les exemples sont compréhensibles ;
• [ ] les limites sont présentées ;
• [ ] les répétitions sont limitées ;
• [ ] les affirmations importantes sont vérifiées.

Sources

• [ ] les sources prioritaires sont consultées ;
• [ ] les versions sont adaptées ;
• [ ] les citations correspondent aux affirmations ;
• [ ] les liens fonctionnent ;
• [ ] les sources secondaires ne remplacent pas inutilement les sources primaires.

Structure

• [ ] le titre est unique ;
• [ ] la description est unique ;
• [ ] les niveaux de titres sont cohérents ;
• [ ] les liens internes sont pertinents ;
• [ ] la page possède une place claire dans l’architecture.

Transparence

• [ ] l’auteur ou l’éditeur est identifié ;
• [ ] la date est présente ;
• [ ] les exemples fictifs sont reconnaissables ;
• [ ] les limites sont explicites ;
• [ ] un moyen de signaler une erreur existe.

Correction des erreurs

Lorsqu’une erreur est signalée :

Signalement
  ↓
Vérification
  ↓
Classification
  ↓
Correction
  ↓
Relecture
  ↓
Publication
  ↓
Journal de modification

Classification possible

Erreur factuelle
Erreur de source
Lien cassé
Imprécision
Exemple ambigu
Erreur technique
Contenu obsolète
Faute éditoriale

Journal des modifications

Une page peut comporter une section ou un fichier séparé.

Exemple :

Version 1.2 — 12 juillet 2026
- correction de la définition de la provenance ;
- ajout d’un exemple de versionnement ;
- remplacement d’un lien obsolète.

Les petites corrections typographiques ne nécessitent pas toujours une entrée détaillée.

Contributions et signalements

Ajoutez avant publication un moyen de contact :

Pour signaler une erreur :
[Adresse électronique ou formulaire]

Demandez au contributeur de fournir :

• la page concernée ;
• le passage ;
• la correction ;
• une source ;
• son nom, s’il souhaite être mentionné.

Indépendance éditoriale

Cette section doit être adaptée au modèle économique réel du site.

Exemple à personnaliser :

Le site indique clairement les éventuels partenariats, liens commerciaux ou contenus sponsorisés.

Une relation commerciale ne détermine pas automatiquement l’évaluation d’un outil ou d’une méthode.

Ne publiez cette déclaration que si elle correspond réellement au fonctionnement du site.

Contenus sponsorisés et affiliations

Lorsqu’ils existent, ils doivent être :

• identifiés ;
• séparés du contenu éditorial ;
• signalés au lecteur ;
• conformes aux obligations applicables.

Les avantages et limites d’un outil doivent rester présentés de manière compréhensible.

À retenir

1. La méthodologie éditoriale définit comment les contenus sont produits et contrôlés.
2. Un nouveau sujet doit répondre à une intention distincte.
3. Les sources primaires et officielles sont privilégiées.
4. La version et le périmètre d’une source doivent être vérifiés.
5. Les faits, interprétations et recommandations doivent être distingués.
6. L’incertitude doit être formulée explicitement.
7. Les outils d’IA peuvent assister la rédaction, mais pas valider seuls les faits.
8. Chaque page importante doit être révisée.
9. Les erreurs doivent suivre un processus de correction traçable.
10. Les informations sur l’auteur, les partenariats et les contacts doivent correspondre à la réalité.

Continuer

À propos du site

Consulter les ressources et la bibliographie

Comprendre la gouvernance des connaissances