lint(standard): corrections completes mode standard

- Em dashes: 1712 remplaces par tirets simples (86 fichiers + _index.md,
  en-tete section Limagrain conserve)
- Checklists: 24 '- [ ]' -> '- ☐' (3 pages operations, plus de todos Obsidian)
- Ancres: 33 reparees (slugs GitHub + ancres HTML <a id> reconnues),
  1 reciblee (manuel de reten)
- related: tenseflow -> tense-flow, pie -> mechanical-elements,
  group.md retire (doublon shipping)
- Registre: compteur global 122 -> 131 pages
- Rapport racine _lint_report.md mis a jour (scan v2 + re-scan final: 0 anomalie)
- Aucun fichier limagrain/ modifie (cloisonnement)

wiki/operations/development-methodology.md

@@ -22,10 +22,10 @@ Méthode de développement interne Mecalux EasyWMS France pour les **custom appl
 
 Objectifs :
 
-1. **Réduire les temps de compilation** — chaque développeur compile uniquement sa propre branche
+1. **Réduire les temps de compilation** - chaque développeur compile uniquement sa propre branche
 2. **Distinguer clairement** trois états : ce qui est **en production**, ce qui est **à livrer** (validé, prêt pour release) et ce qui est **en cours de développement** (non validé)
 
-Référence source : Confluence EasyWMS France — *Présentation méthode de développement* (v8, 29/12/2023).
+Référence source : Confluence EasyWMS France - *Présentation méthode de développement* (v8, 29/12/2023).
 
 ## Stratégie de branches GIT
 
@@ -49,7 +49,7 @@ Référence source : Confluence EasyWMS France — *Présentation méthode de d
 
 1. Lorsqu'une partie ou la totalité des développements est terminée, la custom application est déployée sur une **machine dédiée hébergée sur le serveur de test**.
 2. Les **testeurs** testent depuis ce serveur sans avoir à monter une machine sur leur propre PC.
-3. Correction des bugs — **deux options** (point à valider selon le chantier) :
+3. Correction des bugs - **deux options** (point à valider selon le chantier) :
    - **Option A** : le développeur corrige **directement sur le serveur de test**.
    - **Option B** : le développeur corrige sur sa **machine de développement locale** puis **redéploie sur le serveur de test**.
 
@@ -75,10 +75,10 @@ post-production ───────────────● ─── (cré
 
 ## Règles pratiques
 
-- **Ne jamais committer directement sur `master`** — toute modification passe par `développement` puis release.
-- **Ne jamais merger `post-production` prématurément** — cela écraserait des correctifs présents sur `master`.
+- **Ne jamais committer directement sur `master`** - toute modification passe par `développement` puis release.
+- **Ne jamais merger `post-production` prématurément** - cela écraserait des correctifs présents sur `master`.
 - **Redéploiement de la custom app après chaque merge/rebase** pour vérifier que la compilation passe et que l'app démarre.
-- **Fichier Markdown obligatoire pour le manuel de reten** durant tout le développement — la conversion vers DOC n'intervient qu'en fin de chantier.
+- **Fichier Markdown obligatoire pour le manuel de reten** durant tout le développement - la conversion vers DOC n'intervient qu'en fin de chantier.
 
 ## Common errors
 
@@ -89,6 +89,6 @@ post-production ───────────────● ─── (cré
 
 ## Related
 
-- [System Architecture Overview](../architecture/overview.md) — contexte de déploiement custom apps (IIS, compilation, SaaS vs on-premise)
-- [Application Dictionary](../architecture/application-dictionary.md) — éléments AD packagés dans la custom app
-- [Configuration Guide](configuration-guide.md) — configuration post-déploiement
+- [System Architecture Overview](../architecture/overview.md) - contexte de déploiement custom apps (IIS, compilation, SaaS vs on-premise)
+- [Application Dictionary](../architecture/application-dictionary.md) - éléments AD packagés dans la custom app
+- [Configuration Guide](configuration-guide.md) - configuration post-déploiement