Cas SLAM corrigé : mettre en production une application web

Ce chapitre déroule de bout en bout la mise à disposition d'une application web interne : Prêt'Matos, l'application de prêt de matériel de Sorbier Logistique, écrite en Node.js et React avec une base MySQL, hébergée dans une machine virtuelle du labo. Chaque étape renvoie au chapitre qui en donne la méthode et montre ce qui a été produit : commandes, documents, résultats. C'est le type de réalisation que tu peux présenter à l'E5 si tu as participé à la mise en service d'une application, en stage ou en atelier.

Le contexte

La logistique de Sorbier prête aux salariés 24 matériels : des ordinateurs portables, un vidéoprojecteur, des casques et des webcams. Jusqu'ici, les demandes arrivent par courriel à Nadia Faure, la responsable logistique, et un intérimaire les note dans un tableur. Il part à la fin du mois : l'application doit être en service avant.

La fiche service complète est au chapitre 1, l'architecture, les dépendances et la matrice des flux au chapitre 2.

Le planning

Préparer l'hébergement

Moussa crée srv-pretmatos en clonant le modèle Debian 13 de l'hyperviseur, avec cloud-init pour l'adresse et la clé SSH (modèles, clones et cloud-init), puis installe Docker Engine et Compose (installer Docker). Chloé enregistre le serveur et l'alias du service dans le DNS de l'annuaire, depuis un contrôleur de domaine :

Add-DnsServerResourceRecordA -ZoneName "ad.sorbier.example" -Name "srv-pretmatos" `
    -IPv4Address "192.168.21.130"
Add-DnsServerResourceRecordCName -ZoneName "ad.sorbier.example" -Name "pretmatos" `
    -HostNameAlias "srv-pretmatos.ad.sorbier.example"

Les utilisateurs taperont le nom du service, pretmatos, et non celui du serveur : le jour où l'application change de machine, seul l'alias change.

Le dossier du service sur le serveur :

/srv/pretmatos/
├── compose.yaml        # versionné dans le dépôt, identique en recette et en production
├── Caddyfile           # versionné : HTTPS, routage de /api vers l'API
├── .env                # VERSION=1.0.0 et les réglages propres à la production
├── certs/              # certificat du service émis par Sorbier-AC, sa clé privée (droits 600), racine de Sorbier-AC
├── secrets/            # mots de passe de la base et du compte svc-pretmatos (droits 600)
├── import/             # fichiers de reprise du tableur, supprimés après la bascule
└── tests-fumee.sh      # le script du chapitre 5

Le fichier .env de production ne contient que de la configuration ; les secrets sont des fichiers montés dans les conteneurs (les secrets dans Compose) :

VERSION=1.0.0
URL_PUBLIQUE=https://pretmatos.ad.sorbier.example
LDAP_URL=ldaps://ad.sorbier.example
LDAP_BIND_DN=svc-pretmatos@ad.sorbier.example
GROUPE_UTILISATEURS=GG-PretMatos-Utilisateurs
GROUPE_LOGISTIQUE=GG-PretMatos-Logistique
SMTP_HOST=192.168.21.10
SMTP_PORT=25
LOG_LEVEL=info

L'adresse de l'annuaire est le nom du domaine, ad.sorbier.example, que le DNS résout vers les deux contrôleurs : si l'un tombe, l'application utilise l'autre. Avec srv-ad seul, la redondance de l'annuaire ne servirait à rien (chapitre 2). Le conteneur api reçoit aussi la racine de Sorbier-AC, désignée par la variable NODE_EXTRA_CA_CERTS du fichier Compose : par défaut, Node.js n'utilise pas le magasin de certificats du système, et la connexion LDAPS échouerait sur un certificat inconnu.

Enfin, Moussa ajoute sur pfSense les règles des flux F1 à F4 et F6 à F9 de la matrice, chacune dans l'onglet de l'interface d'entrée de sa source (POSTES pour F1, OpenVPN pour F2, SERVEURS pour F7, APPLIS pour les autres), avec une description qui cite le numéro du flux ; F5 reste dans le VLAN 21 et F10 est déjà couvert par la règle du bastion (écrire les règles du pare-feu).

La recette

Les tests d'intégration I-01 à I-12 du chapitre 4 sont passés sur srv-recette, puis rejoués sur srv-pretmatos avant la bascule pour ceux qui dépendent de l'environnement (DNS, certificat, flux, annuaire, relais). Deux ont échoué la première fois :

La recette par Nadia, Julie et Karim a suivi le cahier de recette du chapitre 4 : deux tours, trois anomalies, une réserve mineure (A-05, le format des dates de l'export). Le rapport de test et le procès-verbal, signés à J−7, sont ceux du chapitre 4.

La mise en production

Le samedi matin, Moussa et Yanis déroulent le plan de déploiement du chapitre 3, en tenant le journal. D'abord l'instantané de la VM, depuis l'hyperviseur, qui servira de retour arrière :

qm snapshot 130 avant-1-0-0 --description "Avant la mise en production de Prêt'Matos 1.0.0"

Puis le déploiement, sur srv-pretmatos :

cd /srv/pretmatos
grep '^VERSION=' .env                     # VERSION=1.0.0, la version recettée
sudo docker compose config --quiet && echo valide
sudo docker compose pull
sudo docker compose up -d
sudo docker compose ps                    # bdd healthy, proxy, front et api running

La base est créée vide au premier démarrage, avec son schéma. Yanis lance ensuite la reprise du tableur, d'abord en mode essai, avec le script d'import versionné dans le dépôt. Le dossier import/ est monté en lecture seule dans un conteneur temporaire de l'API :

sudo docker compose run --rm -v /srv/pretmatos/import:/import:ro api \
    npm run import -- --essai /import

Catalogue : 26 lignes lues, 2 doublons ignorés, 24 matériels à importer
Réservations à venir : 19 lignes lues, 2 dates passées ignorées, 17 à importer
Prêts en cours : 5 à importer
Mode essai : rien n'a été écrit dans la base.

Les chiffres sont ceux qu'on attendait (préparés et vérifiés deux fois en recette). Yanis relance la commande sans --essai, puis contrôle la base avec la requête du chapitre 5 : 24, 17 et 5. Lina lance les tests de fumée :

./tests-fumee.sh https://pretmatos.ad.sorbier.example

OK  page d'accueil
OK  route de santé de l'API
KO  redirection HTTP vers HTTPS
OK  certificat valable 30 jours
Tests de fumée : 1 échec(s). Ne pas ouvrir le service.

Le port 80 n'était pas publié par le conteneur proxy : la ligne avait été retirée du fichier Compose de recette, où personne ne tapait l'adresse en HTTP. Lina corrige compose.yaml dans le dépôt, Moussa récupère le fichier et redémarre le seul proxy, puis les tests de fumée passent à 4 sur 4. Lina vérifie à la main la connexion avec un compte réel, la création et l'annulation d'une réservation de test, et un rappel de test reçu dans sa boîte. Nadia compare son planning de la semaine avec le tableur : identique. À 11 h 15, Antoine décide go : le service est conservé, l'ouverture aura lieu lundi.

Les fichiers de reprise sont supprimés du dossier import/ : ils contiennent des noms de salariés et n'ont plus d'utilité. Le tableur, lui, reste archivé en lecture seule sur srv-partages.

La sauvegarde et la supervision

La sauvegarde de la base est faite chaque nuit par mysqldump dans le conteneur bdd, puis copiée sur le partage NFS de srv-partages, monté sur /mnt/sauvegardes :

sudo docker compose -f /srv/pretmatos/compose.yaml exec -T bdd \
    sh -c 'exec mysqldump --single-transaction -u root -p"$(cat /run/secrets/db_root_password)" pretmatos' \
    | gzip > "/mnt/sauvegardes/pretmatos-$(date +%F).sql.gz"

La commande est placée dans un script lancé chaque nuit par un minuteur systemd, et la restauration a été testée sur srv-recette avant la mise en production (sauvegarder une base MySQL). Côté supervision, Moussa a ajouté l'hôte dans Zabbix avec l'agent 2, un scénario web sur la page de connexion et la route de santé, et un élément sur la date d'expiration du certificat ; l'agent Wazuh envoie les journaux du serveur à srv-journaux (chapitre 7).

L'ouverture et l'accompagnement

Le plan d'accompagnement du chapitre 6 est déroulé :

• J−14 : l'annonce de Nadia ;
• J−5 : un atelier d'une heure pour Julie et Karim sur srv-recette, une heure pour Nadia sur les écrans de la logistique ;
• J−3 (vendredi) : briefing de Chloé, quatre articles de base de connaissances, la catégorie « Prêt de matériel » dans GLPI ; le rappel aux salariés, avec la fiche réflexe en pièce jointe ; un favori « Prêt de matériel » déployé dans Edge par la stratégie de groupe des postes (la stratégie Edge des favoris gérés, ManagedFavorites) ;
• J, 9 h : une démonstration de 10 minutes à la réunion d'équipe, puis Yanis passe à la logistique ;
• J à J+11 : support renforcé, point quotidien à 9 h.

La fiche réflexe, une page affichée près de la logistique et envoyée à tous :

Prêt'Matos en 4 gestes — pretmatos.ad.sorbier.example, ou le favori « Prêt de matériel »

1. Se connecter : ton identifiant et ton mot de passe Windows.
2. Réserver : Nouvelle réservation, le type de matériel, tes dates (15 jours au plus), Réserver.
3. Retrouver ou annuler : Mes réservations.
4. Rendre : rapporte le matériel à la logistique avant la date de retour ; un rappel arrive la veille.

Un souci ? GLPI, catégorie « Prêt de matériel », ou demande à Julie ou à Karim.

Le suivi et le bilan

Les chiffres du premier mois sont ceux du chapitre 7 : 99,70 % de disponibilité sur la plage de service, 90,2 % des réservations faites par les salariés eux-mêmes, 22 tickets dont 11 la première semaine, une satisfaction de 83,3 %. Le support renforcé s'arrête comme prévu à J+11, la réserve A-05 levée (corrigée en version 1.0.1 à J+9, déployée cette fois par le script et le pipeline) ; le bilan à J+30 transfère le service à l'exploitation. La première demande d'évolution, prolonger un prêt, part au backlog : elle deviendra la version 1.5, avec sa propre recette (le cahier de recette de la prolongation).

Variante : héberger sur un PaaS

Une plateforme d'hébergement d'applications (PaaS, Platform as a Service) exécute l'application sans que tu administres de serveur : tu lui confies le code ou l'image, elle fournit l'HTTPS, le nom, la base de données gérée, les journaux et le redémarrage. Scalingo et Clever Cloud sont deux plateformes françaises, qui proposent un hébergement des données en France. Pour Prêt'Matos, la démarche reste la même ; ce qui change :

Le choix dépend du besoin : une application interne réservée aux salariés, qui s'appuie sur l'annuaire, reste naturellement dans le réseau de l'entreprise ; une application ouverte à des clients ou à des partenaires extérieurs gagne à être hébergée sur une plateforme. Le cours Cloud compare les modèles d'hébergement, et le TP Déployer et héberger sur un VPS ou un PaaS te fait déployer une application Node.js de bout en bout.

Les preuves pour l'E5

Ce cas donne une réalisation complète pour la compétence « Mettre à disposition des utilisateurs un service informatique ». Les preuves à garder, et l'indicateur que chacune démontre :

Dans ton portfolio, dis précisément ce qui était à toi : « j'ai écrit le cahier de recette et le script d'import, j'ai animé l'atelier des référents » vaut mieux que « nous avons déployé Prêt'Matos ». Le chapitre 10 montre comment la présenter.

Exercices