Trace 5 - Experimentation VRS/MongoDB puis simplification

Trace 5

Tester une piste MongoDB puis choisir plus simple

Agrandir

Cette trace concerne une piste que j'ai exploree pendant la refonte de l'export Cockpit : faire recuperer et preparer les donnees par l'API VRS directement depuis MongoDB, avec des index adaptes aux filtres Cockpit. Cette approche permettait de travailler sur la performance de recherche et de reduire certains traitements frontend.

Elle n'est finalement pas devenue l'architecture finale. Apres les tests et les changements de direction, j'ai choisi un flux plus simple a maintenir : le frontend garde les resultats Cockpit deja recherches, les transforme en feuilles/lignes, puis l'API PHP les recoit par batches et genere le fichier.

1. La piste VRS/MongoDB m'a permis de comprendre comment les checks etaient filtres et recuperes.
2. Les index montrent le raisonnement initial : rapprocher les index des filtres reels comme site, UAP, GAP, poste, machine et date.
3. Le choix final a ete de retirer cette dependance du flux d'export pour garder une architecture plus directe et plus maintenable.

Exemples d'index testes

Ces index peuvent encore etre visibles dans MongoDB et servir de preuve de la piste exploree. Par contre, ils ne doivent pas etre presentes comme indispensables au flux final d'export, puisque la version actuelle ne repose plus sur cette preparation cote VRS.

{ type: 1, is_draft: 1, 'localisation.site.id': 1, createdAt: -1 }
{ type: 1, is_draft: 1, 'localisation.uap.id': 1, createdAt: -1 }
{ type: 1, is_draft: 1, 'localisation.gap.id': 1, createdAt: -1 }
{ type: 1, is_draft: 1, 'localisation.post.id': 1, createdAt: -1 }
{ type: 1, is_draft: 1, 'localisation.machine.id': 1, createdAt: -1 }

Pourquoi cette piste n'a pas ete gardee

La piste VRS/MongoDB avait un avantage : elle rapprochait la preparation des donnees de la base MongoDB. Mais elle ajoutait aussi plusieurs contraintes :

• une dependance plus forte entre l'API PHP et l'API VRS ;
• plus de coordination au deployement ;
• un flux plus difficile a expliquer et a maintenir ;
• un risque de doubler la logique entre recherche Cockpit et export.

Le flux final est plus simple : les donnees deja visibles dans Cockpit servent de base a l'export, puis l'API PHP se concentre sur la reception des batches, le stockage temporaire et la generation OpenSpout.

Analyse des savoir-faire

Le savoir-faire donnees est comprendre comment MongoDB sert la recherche Cockpit. Meme si les index ne sont plus au coeur de l'export final, cette piste m'a aide a comprendre les volumes, les champs de localisation et les filtres importants.

Le savoir-faire architecture est savoir retirer une complexite qui n'apporte plus assez de valeur. Une solution peut etre techniquement interessante mais moins bonne pour le systeme final si elle complique trop le flux.

Le savoir-faire projet est assumer une decision apres experimentation. Cette trace montre que le chantier n'a pas ete lineaire : j'ai teste une approche, mesure ses interets, puis conserve une solution plus simple et plus robuste pour la suite.