Aller au contenu

6. Méthode pédagogique

6.1 Progression en cinq niveaux

Chaque concept majeur est traité selon la même progression, sans jamais passer à la configuration avant d'avoir établi le fonctionnement :

  1. Comprendre : le concept expliqué simplement, avec le problème qu'il résout ;
  2. Visualiser : un schéma ou une représentation logique lorsque cela éclaire ;
  3. Approfondir : le fonctionnement technique réel, y compris les cas limites ;
  4. Manipuler : un exemple concret ou un travail pratique ;
  5. Sécuriser : les risques, les erreurs classiques, les bonnes pratiques, et les hypothèses sous lesquelles elles valent.

6.2 Structure type d'un chapitre

Chaque chapitre suit une structure stable : Objectifs pédagogiques ; Prérequis ; Cours ; Exemple ; Architecture (si pertinent) ; Sécurité ; Erreurs fréquentes ; Mise en pratique ; Questions de compréhension ; Synthèse. Une section sans objet pour le sujet traité est omise plutôt que remplie artificiellement.

6.3 Conventions d'écriture

  • Toute commande ou configuration porte un marqueur de contexte : [Laboratoire] (jamais en production), [Démonstration] (acceptable ponctuellement, limites indiquées), [Production] (conforme aux bonnes pratiques). Toute commande dangereuse (vault server -dev, tls_disable = true, restauration forcée, révocations de masse) est accompagnée d'un avertissement explicite avant le bloc de code.
  • Chaque commande importante est expliquée, paramètre critique par paramètre critique. Aucun copier-coller aveugle.
  • Toute opération importante est montrée en CLI et, lorsque c'est éclairant, accompagnée de l'appel d'API équivalent (méthode, chemin, corps) : le cours applique lui-même le principe « tout est chemin ».
  • Les comportements dépendant de la version sont signalés par une Note de version ; les fonctionnalités absentes de la Community Edition sont marquées Enterprise.
  • Lorsque c'est nécessaire, les énoncés sont qualifiés explicitement : comportement documenté, recommandation officielle, pratique courante, choix d'architecture, compromis.
  • La nomenclature (section 10) est contractuelle : aucun nom de machine, de chemin, de rôle ou de policy n'est modifié arbitrairement au fil du cours.
  • Tableaux et schémas ne sont utilisés que lorsqu'ils apportent réellement une comparaison ou une représentation utile ; les schémas ASCII sont sobres et fonctionnels.