chore(vm): retouche et mise en forme

docs/principes.html

@@ -362,7 +362,7 @@
 * Mesurer un **temps de réponse moyen** (indicateur de performance)
 * Mettre en oeuvre une **alerte pour traiter au plus vite une indisponibilité**
 
-Pour les services exposés en ligne, la mise en oeuvre sera triviale avec des outils tels [UptimeRobot](https://uptimerobot.com/), [Uptrends](https://www.uptrends.fr/),...
+Pour les services exposés en ligne, la mise en oeuvre sera triviale avec des outils tels [UptimeRobot](https://uptimerobot.com/), [Uptrends](https://www.uptrends.fr/)...
 
 <div class="center">
     <img src="img/uptimerobot-gpp.png" style="height: 170px" />
@@ -492,7 +492,7 @@
 * Être interrompus et relancés (**atomicité**)
 * [Cohabiter avec d'autres](annexe/iac-cohabitation.html) (~orthogonalité)
 * Être testés par exemple avec des environnements de qualification et de pré-production.
-* Permettre à la fois la mise à jour du système et sa reconstruction.
+* Permettre à la fois la mise à jour du système et sa reconstruction
 
 Nous privilégierons **une approche déclarative** à une approche impérative pour faciliter la mise en oeuvre de ces principes.
 
@@ -502,7 +502,7 @@
 
 ### Quels pré-requis sur l'infrastructure?
 
-L'approche IaC laissera une grande liberté de choix dans les outils du cadre technique dès lors qu'ils sont **compatibles avec l'automatisation**. Il conviendra principalement d'**être attentif aux méthodes de configuration disponibles** (1) :
+L'approche IaC laissera une grande liberté de choix dans les **outils du cadre technique** dès lors qu'ils sont **compatibles avec l'automatisation**. Il conviendra principalement d'**être attentif aux méthodes de configuration disponibles** (1) :
 
 * La configuration est basée sur des **variables d'environnements**?
 * La configuration est basée sur des **fichiers de configuration**?
@@ -521,7 +521,7 @@
 
 En fonction des possibilités offertes par l'infrastructure et de la politique de l'entreprise, l'**automatisation pourra être partielle** mais il faudra **être conscient des conséquences**.
 
-A titre d'exemple, **si la configuration du reverse proxy/load balancer n'est pas automatisée** :
+En particulier, **si la configuration du reverse proxy/load balancer n'est pas automatisée** :
 
 * Comment pourrez vous **avoir un système qui s'adapte à la charge**?
 * Comment pourrez vous **éviter les indisponibilités pendant les déploiements de nouvelles versions**?
@@ -558,7 +558,7 @@
   * Les rôles habilités à valider les *pull request*
 * Résoudre des problématiques de **traçabilité des déploiements** :
   * Qui a lancé quelle version du script de déploiement?
-  * Qui a proposé/validé la configuration?
+  * Qui a proposé/validé la modification?
 
 GitOps est ainsi une illustration de l'utilisation du concept de **pull request** en lieu et place d'un processus de validation plus traditionnel.
 
@@ -612,7 +612,10 @@
 Nous remarquerons par exemple :
 
 * Des **schemas as code** avec des outils tels [Diagrams](https://diagrams.mingrammer.com/docs/getting-started/examples)
-* Des **standards as code** (ex : [cnigfr - PCRS](https://github.com/cnigfr/PCRS#pcrs))
+* Des **standards as code** :
+  * [cnigfr - PCRS](https://github.com/cnigfr/PCRS#pcrs)
+  * [opengeospatial/ogcapi-features](https://github.com/opengeospatial/ogcapi-features?tab=readme-ov-file#ogc-api---features)
+  * ...
 * Des **référentiels as code** quand la volumétrie le permet :
   * [BaseAdresseNationale/codes-postaux](https://github.com/BaseAdresseNationale/codes-postaux#codes-postaux)
   * [gregoiredavid/france-geojson](https://github.com/gregoiredavid/france-geojson#france-geojson)

docs/vm.html

@@ -29,7 +29,7 @@
 * [PostgreSQL](https://www.postgresql.org/) avec l'extension [PostGIS](https://postgis.net/) pour stocker des données géographiques.
 * [GeoServer](https://geoserver.org/) pour diffuser ces données en WMS et WFS.
 
-Nous appellerons le système résultant **GeoStack** (afin d'avoir un nom de base pour le dépôt dédié au déploiement : `geostack-deploy`)
+Nous appellerons le système résultant **GeoStack** (afin d'avoir un nompour le dépôt dédié au déploiement : `geostack-deploy`).
 
 ---
 
@@ -82,14 +82,16 @@
 
 Dans le cas où il convient de créer un livrable pour sa propre application, nous remarquerons que :
 
-* Il existe une **grande variété de formats de livrables possibles** en fonction des technologies et OS cible (c.f. [format supportés par Nexus qui permet de créer différents types de dépôt](https://help.sonatype.com/repomanager3/nexus-repository-administration/formats) )
+* Il existe une **grande variété de formats de livrables possibles** en fonction des technologies et de l'OS cible (c.f. [format supportés par Nexus qui permet de créer différents types de dépôt](https://help.sonatype.com/repomanager3/nexus-repository-administration/formats) )
 * Packager des applications telles PostgreSQL est un métier (construire et maintenir des .deb ou .rpm dans les règles de l'art n'est pas trivial).
 * Dans le cas des **langages interprétés** (NodeJS, PHP...) :
   * Nous pourrons nous contenter en guise de livrable d'une simple archive (**.zip avec le code de la version + les dépendances**)
-  * Nous pourrons aussi facilement produire des .deb ou .rpm avec des outils tels [FPM](https://fpm.readthedocs.io)
+  * Nous pourrons aussi facilement produire des .deb avec des outils tels [FPM](https://fpm.readthedocs.io) (1)
 
 Nous n'entrerons pas trop dans le détail (*spoiler* : nous verrons comment l'utilisation de conteneurs solutionne ce problème)
 
+> (1) Voir [github.com - IGNF/validator - build-deb.sh](https://github.com/IGNF/validator/blob/master/build-deb.sh) pour un exemple trivial (sans script pré/post-installation).
+
 ---
 
 ## La création d'un livrable (4/4)

src/slides/principes.md

@@ -547,7 +547,7 @@ Cette approche permettra de :
   * Les rôles habilités à valider les *pull request*
 * Résoudre des problématiques de **traçabilité des déploiements** :
   * Qui a lancé quelle version du script de déploiement?
-  * Qui a proposé/validé la configuration?
+  * Qui a proposé/validé la modification?
 
 GitOps est ainsi une illustration de l'utilisation du concept de **pull request** en lieu et place d'un processus de validation plus traditionnel.
 
@@ -601,7 +601,10 @@ Au final, il sera très vite tentant de gérer un maximum d'élément à l'aide
 Nous remarquerons par exemple :
 
 * Des **schemas as code** avec des outils tels [Diagrams](https://diagrams.mingrammer.com/docs/getting-started/examples)
-* Des **standards as code** (ex : [cnigfr - PCRS](https://github.com/cnigfr/PCRS#pcrs))
+* Des **standards as code** :
+  * [cnigfr - PCRS](https://github.com/cnigfr/PCRS#pcrs)
+  * [opengeospatial/ogcapi-features](https://github.com/opengeospatial/ogcapi-features?tab=readme-ov-file#ogc-api---features)
+  * ...
 * Des **référentiels as code** quand la volumétrie le permet :
   * [BaseAdresseNationale/codes-postaux](https://github.com/BaseAdresseNationale/codes-postaux#codes-postaux)
   * [gregoiredavid/france-geojson](https://github.com/gregoiredavid/france-geojson#france-geojson)

src/slides/vm.md

@@ -18,7 +18,7 @@ Nous allons voir en pratique comment se passe le déploiement d'une application
 * [PostgreSQL](https://www.postgresql.org/) avec l'extension [PostGIS](https://postgis.net/) pour stocker des données géographiques.
 * [GeoServer](https://geoserver.org/) pour diffuser ces données en WMS et WFS.
 
-Nous appellerons le système résultant **GeoStack** (afin d'avoir un nom de base pour le dépôt dédié au déploiement : `geostack-deploy`)
+Nous appellerons le système résultant **GeoStack** (afin d'avoir un nompour le dépôt dédié au déploiement : `geostack-deploy`).
 
 ---
 
@@ -71,14 +71,16 @@ Pour le déploiement d'une application en PRODUCTION, il est important de :
 
 Dans le cas où il convient de créer un livrable pour sa propre application, nous remarquerons que :
 
-* Il existe une **grande variété de formats de livrables possibles** en fonction des technologies et OS cible (c.f. [format supportés par Nexus qui permet de créer différents types de dépôt](https://help.sonatype.com/repomanager3/nexus-repository-administration/formats) )
+* Il existe une **grande variété de formats de livrables possibles** en fonction des technologies et de l'OS cible (c.f. [format supportés par Nexus qui permet de créer différents types de dépôt](https://help.sonatype.com/repomanager3/nexus-repository-administration/formats) )
 * Packager des applications telles PostgreSQL est un métier (construire et maintenir des .deb ou .rpm dans les règles de l'art n'est pas trivial).
 * Dans le cas des **langages interprétés** (NodeJS, PHP...) :
   * Nous pourrons nous contenter en guise de livrable d'une simple archive (**.zip avec le code de la version + les dépendances**)
-  * Nous pourrons aussi facilement produire des .deb ou .rpm avec des outils tels [FPM](https://fpm.readthedocs.io)
+  * Nous pourrons aussi facilement produire des .deb avec des outils tels [FPM](https://fpm.readthedocs.io) (1)
 
 Nous n'entrerons pas trop dans le détail (*spoiler* : nous verrons comment l'utilisation de conteneurs solutionne ce problème)
 
+> (1) Voir [github.com - IGNF/validator - build-deb.sh](https://github.com/IGNF/validator/blob/master/build-deb.sh) pour un exemple trivial (sans script pré/post-installation).
+
 ---
 
 ## La création d'un livrable (4/4)