Aller au contenu

Roadmap Engineering

Status: HISTORICAL SNAPSHOT / GOVERNANCE GUIDE

Cette page conserve la logique de l’ancienne roadmap d’industrialisation, mais ne doit pas être lue comme le backlog CURRENT de CMonChoix Platform.

Depuis sa rédaction, plusieurs chantiers ont été réalisés, déplacés ou remplacés par une architecture plus précise. Les cases historiques restent utiles pour comprendre l’ordre des préoccupations, pas pour décider automatiquement du prochain chantier.

Comment utiliser cette roadmap

Avant de reprendre une tâche historique :

  1. vérifier qu’elle est encore pertinente dans la révision courante ;
  2. identifier la couche réellement concernée ;
  3. vérifier les tests, Contracts et bootstraps actuels ;
  4. relire la dette technique et les ADR associés ;
  5. définir une preuve de sortie mesurable ;
  6. travailler par petit lot réversible.

Une case non cochée n’est donc pas une preuve qu’un travail manque encore. Une case cochée n’est pas non plus une certification permanente.

Principes qui restent valides

  • un chantier poursuit un objectif principal ;
  • les extractions risquées sont précédées de tests de caractérisation ;
  • la documentation évolue avec l’architecture ;
  • les priorités peuvent changer après audit ;
  • toute mutation de données est séparée de l’observation ;
  • une projection reste dérivée et rebuildable ;
  • le Runtime orchestre sans décider de la vérité métier ;
  • le Frontend consomme les projections ;
  • les Vertical Modules restent isolés du Domain Core.

Anciennes phases — lecture historique

Phase 1 — Engineering Foundation

L’ancien objectif était d’introduire :

  • Engineering Standard ;
  • registre des composants ;
  • matrice de certification ;
  • dette technique priorisée ;
  • ADR fondateur ;
  • cadre d’audit.

Ces briques existent aujourd’hui, mais leur contenu a évolué. Les statuts historiques ne remplacent pas les preuves de la révision courante.

Phase 2 — Frontend modulaire

L’ancien plan était centré sur l’extraction progressive de responsabilités depuis des fichiers Frontend monolithiques : galerie, variantes, filtres, SEO, navigation, cartes, offres et fiche produit.

La lecture CURRENT doit désormais partir des documents :

  • ../frontend/overview.md ;
  • ../frontend/projections.md ;
  • ../frontend/navigation-runtime.md ;
  • ../adapters/wordpress.md.

La question n’est plus « quelle case de l’ancienne extraction reste ouverte ? », mais : quelle responsabilité est réellement chargée où, et respecte-t-elle encore la frontière projection / Read Service / Adapter / renderer ?

Phase 3 — Audits reproductibles

L’objectif historique était d’obtenir des contrôles reproductibles du dépôt, de Docker, du VPS, de MariaDB et de la documentation.

La posture CURRENT utilise notamment les entrées versionnées du Makefile et les procédures d’exploitation :

make doctor
make guard-static
make guard-runtime
make docs-check
make backup
make backup-verify BUNDLE=...
make restore-check BUNDLE=...

Ne pas recréer automatiquement un ancien tools/audit/ ou une commande make audit simplement parce qu’elle apparaît dans la roadmap historique. Vérifier d’abord quel besoin n’est pas couvert par les commandes actuelles.

Phase 4 — Backend et Pipeline

Les objectifs historiques restent de bonnes règles de méthode :

  • cartographier avant de découper ;
  • identifier les sources de vérité ;
  • ajouter les tests de caractérisation ;
  • isoler les responsabilités autonomes ;
  • garder les règles marchands hors des composants génériques.

La documentation CURRENT à consulter se trouve notamment dans :

  • ../pipeline/ ;
  • ../domain-core/ ;
  • ../contracts/ ;
  • ../read-services/ ;
  • ../write-services/ ;
  • ../adapters/.

Phase 5 — Exploitation et transmission

Cette phase visait la cartographie VPS, les playbooks, la restauration, le glossaire et la reprise par un nouveau mainteneur.

Une grande partie de ce travail est désormais portée par :

  • ../operations/ ;
  • ../runtime/ ;
  • ../database/ ;
  • ../glossary/ ;
  • les pages de transmission de chaque domaine.

Les exercices de reprise qui dépendent d’un état réel du VPS doivent toujours être datés et exécutés explicitement ; la documentation seule ne prouve pas qu’un backup récent est restaurable.

Phase 6 — Automatisation

L’ancien plan envisageait des commandes comme make audit, make inventory ou make health.

Aujourd’hui, les noms de commandes ne doivent pas être créés pour satisfaire la roadmap. On ajoute une nouvelle commande uniquement si elle réduit réellement le risque ou la complexité, avec :

  • contrat clair ;
  • effets documentés ;
  • sortie stable ;
  • code de retour exploitable ;
  • tests ;
  • absence de duplication avec make doctor, guards ou scripts existants.

Construire une nouvelle roadmap

Une roadmap CURRENT doit partir de preuves récentes, pas de cette liste historique.

Pour chaque chantier proposé, documenter :

Champ Question
problème observé qu’est-ce qui est réellement faux, fragile ou coûteux ?
couche Domain Core, Vertical, Application, Adapter, Runtime, DB, Frontend, Ops ?
preuve test, audit, incident, métrique ou observation Runtime ?
risque que se passe-t-il si on ne fait rien ?
résultat cible quel état observable doit être atteint ?
garde-fous quels invariants ne doivent pas bouger ?
validation comment prouver que le changement fonctionne ?
rollback comment revenir en arrière ?

Ordre de priorité recommandé

En cas de concurrence entre chantiers, privilégier généralement :

  1. intégrité et sécurité des données ;
  2. capacité de reprise et d’exploitation ;
  3. violation d’une frontière architecturale ;
  4. absence de preuve ou d’observabilité sur un comportement critique ;
  5. dette qui bloque les évolutions fréquentes ;
  6. optimisation et confort de développement.

Une dette esthétique ou un refactoring de confort ne doit pas passer devant un risque de mutation incorrecte, de restauration non vérifiée ou de source de vérité concurrente.

Voir aussi