Contribue à la présence en ligne de l'organisation

01Distingue trois couches

PRESENCE EN LIGNE
ce que l'organisation rend visible ou accessible

CONTENU / SERVICE
information, page, formulaire ou service réellement attendu

INFRASTRUCTURE
DNS, HTTPS, hébergement, reverse proxy, réseau, sauvegarde, supervision

Les cours IIS et Apache/DMZ couvrent déjà largement la troisième couche. Ici, tu apprends à relier les trois.

02Pars d’une demande métier

SORIA Distribution souhaite publier une page synthétique pour son espace partenaires fictif.

Demande initiale :

"Ajoutez une page partenaires et rendez-la disponible vendredi."

Avant de modifier quoi que ce soit, clarifie :

objectif de la page
public visé
contenu validé et propriétaire
URL attendue
informations qui ne doivent pas être publiées
responsable de validation
fenêtre de changement
critères de recette
rollback

Une demande de contenu n’autorise pas implicitement un changement d’architecture.

03Définis une fiche de publication

ID : WEB-CHANGE-021
Objectif : publier la page partenaires validée
Propriétaire contenu : rôle métier fictif
Responsable technique : rôle infrastructure fictif
URL : https://portal.dmz.soria.test/partenaires
Données personnelles réelles : aucune
Secret : aucun
Précondition : contenu approuvé + environnement de lab sain
Rollback : version précédente conservée
Recette : contenu + lien + HTTPS + tests négatifs

Le nom de domaine est synthétique. N’utilise pas une vraie marque, un vrai client ou une vraie donnée pour « rendre le TP réaliste ».

04Contrôle le contenu avant la technique

Vérifie au minimum :

[ ] titre et objectif compréhensibles
[ ] information attribuable à un propriétaire
[ ] absence de donnée ou secret non prévu
[ ] liens nécessaires identifiés
[ ] contenu obsolète ou contradictoire signalé
[ ] texte alternatif prévu pour une image informative éventuelle
[ ] structure de titres logique

Tu n’es pas chargé d’inventer une promesse commerciale manquante. Une information non validée reste hors publication.

05Relie publication et dépendances

Dessine la chaîne :

lecteur
→ DNS
→ TLS
→ point de publication
→ application / contenu
→ journaux / supervision

Ajoute pour chaque dépendance :

propriétaire
symptôme en cas d'échec
preuve de recette
rollback ou action d'exploitation

Le TP DMZ t’a déjà appris à vérifier techniquement cette chaîne. Ici, tu la relies à la demande métier.

06Prépare une recette avant le changement

Tests fonctionnels

le nom attendu résout
la page répond en HTTPS
le titre et le contenu validés sont présents
les liens internes prévus fonctionnent
la page reste lisible à largeur réduite
la navigation clavier de base permet d'atteindre les actions utiles

Tests négatifs

une ancienne URL supprimée ne redirige pas vers un contenu trompeur
aucun fichier de travail ou secret n'est publiquement exposé
une zone d'administration n'est pas rendue publique par le changement

Un test technique vert ne valide pas un contenu incorrect.

07Applique un changement borné

Le changement doit répondre à la demande, pas devenir une refonte opportuniste.

état avant
→ modification minimale
→ build / contrôle syntaxique si applicable
→ recette fonctionnelle
→ recette sécurité
→ preuve
→ décision de conserver ou rollback

Si le changement échoue, conserve le symptôme et la preuve au lieu de masquer l’échec.

08Observe l’accessibilité sans surpromettre

Dans le laboratoire, tu peux vérifier des éléments observables :

langue de page déclarée
structure de titres
libellés de liens compréhensibles
texte alternatif pertinent pour les images informatives
focus clavier visible
absence de dépendance exclusive à la souris pour l'action testée
lecture à largeur réduite

Ces contrôles ne constituent pas à eux seuls un audit complet de conformité. Note cette limite dans le dossier.

09Documente ce qui a réellement changé

Dans ton dossier de preuves :

EXIGENCE
publier la page partenaires validée

CONTEXTE
site fictif SORIA Distribution / laboratoire

ACTION
modification bornée du contenu et publication dans l'environnement prévu

RESULTAT OBSERVE
URL accessible, contenu attendu, HTTPS et liens vérifiés

VERIFICATION
recette fonctionnelle + contrôle négatif + contrôle largeur/clavier

LIMITE
pas de validation réelle sur tous navigateurs, appareils ou technologies d'assistance

La limite protège la qualité de la conclusion.

10Mission

Prépare le dossier WEB-CHANGE-021 sans publier quoi que ce soit sur Internet.

Livre :

1. fiche de demande reformulée ;
2. propriétaire du contenu et responsable technique ;
3. dépendances de publication ;
4. six tests de recette dont deux négatifs ;
5. plan de rollback ;
6. une entrée dans le ledger de preuves ;
7. trois limites que ton laboratoire ne permet pas de lever.