Skip to main content

Pegasus

Plan à destination des développeurs et chefs de projet techniques. Les sections non concernées par le projet sont annotées « sans objet ».

VersionDateObjet de la révision
1.006/07/2026Version initiale.
1.110/08/2026Révision de l'analyse de risque (mesures compensatoires) ; décision d'architecture sur le proxy API.
1.210/08/2026Intégration des résultats de l'audit technique complet ; inventaire des anomalies et plan de correction.
1.318/08/2026Simplification. Les correctifs de l'audit sont appliqués (branche fix/audit-correctifs) et couverts par la suite de tests : l'inventaire d'anomalies et le plan de correction, devenus obsolètes, sont retirés. Le document décrit l'état courant du code. L'audit complet reste consultable dans l'historique git (docs/Audit technique.md, retiré au commit c56cda9 ; version 1.2 du présent document au même commit).

Ce document porte le contexte, la sécurité et l'exploitation. Le fonctionnement détaillé (plafond des 10 000, découpage par famille, clés de dédoublonnage, parcours du code) est documenté dans le README.md, qui fait référence.

1. Introduction générale​

1.1 Contexte​

« Pegasus » est une application web interne du Groupe Niort servant d'interface à l'API TecDoc / TecAlliance (référentiel mondial de pièces détachées automobiles). Elle permet d'extraire et d'exporter les catalogues des équipementiers (CSV/XLSX), de combiner plusieurs exports Excel en dédoublonnant, et de recouper les équivalences OE entre un fichier maître et un catalogue tiers. Outil utilisé par un petit nombre d'utilisateurs, sans exposition publique.

Objectif technique fondateur : rester une application 100 % statique — aucun serveur applicatif, aucun build, aucune dépendance téléchargée à l'exécution.

Parties prenantes : Groupe Niort (donneur d'ordre, exigences qualité / assurances) ; équipe de développement ; utilisateurs métier (service pièces / catalogue). Dépôt GitHub privé : ndjpc/Pegasus (origine : BNiort/Pegasus).

1.2 Objectif de la documentation​

Clarifier le fonctionnement de l'outil pour des raisons de qualité et répondre aux exigences des assurances du Groupe Niort.

1.3 Périmètre​

Inclus : les 3 outils front (index.html, pages/grpExcel.html, pages/analyseRef.html), l'intégration à l'API TecDoc Pegasus 3.0, les exports CSV/XLSX, la configuration d'accès. Exclus : l'API TecDoc elle-même (voir docs/TecDoc Pegasus 3.0 API - Onboarding Guide 3.0.pdf) ; backend, base de données, authentification utilisateur (inexistants) ; CI/CD (non implémentée — des tests automatisés existent, voir §7.1).

1.4 Glossaire​

  • TecDoc / TecAlliance : fournisseur du référentiel de pièces auto ; expose l'API « Pegasus 3.0 ».
  • Équipementier (dataSupplier) : fabricant de pièces, identifié par dataSupplierId.
  • OE / OEM : référence d'origine constructeur (oemNumbers) ; base des équivalences.
  • assemblyGroup : catégorie de pièces dans l'arborescence TecDoc.
  • SheetJS (xlsx) : librairie de lecture/écriture Excel, embarquée en local (js/vendor/).
  • DPAN / Rtec / TMM : marques cibles du recoupement dans l'outil d'analyse.

2. Architecture & environnements​

2.1 Architecture globale​

Architecture entièrement côté client : le navigateur charge des fichiers statiques puis dialogue directement avec l'API TecDoc en HTTPS. Aucun backend, aucune base de données ; les exports sont téléchargés localement. Les trois outils sont indépendants (un JS et un CSS par page, aucun code partagé) ; seul index.html/script.js parle à l'API.

Poste utilisateur (réseau Groupe Niort)
┌───────────────── Navigateur ─────────────────┐
│ index.html + js/script.js   (catalogue)      │──── POST JSON + X-Api-Key ───► API TecDoc
│ pages/grpExcel.html         (combinaison)    │      webservice.tecalliance.services
│ pages/analyseRef.html       (équivalences OE)│      /pegasus-3-0/…jsonEndpoint
│ SheetJS embarqué — grpExcel et analyseRef    │
│ fonctionnent 100 % hors ligne API            │
└──────────────────────▲───────────────────────┘
                       │ HTTPS statique — 403 hors réseau autorisé
             BunnyCDN (pegasus.dpan.fr)

Conséquences structurelles du choix « 100 % statique » : la clé API est nécessairement présente côté client (§5.3), et le flux navigateur → TecDoc suppose que TecAlliance autorise le CORS (constaté fonctionnel en production).

2.2 Environnements​

  • Dev : serveur statique local (python3 -m http.server 8000). L'ouverture en file:// n'est pas fiable (CORS) : toujours passer par un serveur local.
  • Production : pegasus.dpan.fr, servie par BunnyCDN. Le contrôle d'accès (403 hors réseau autorisé) et le HTTPS sont configurés dans la pull zone Bunny. ⚠️ Le .htaccess du dépôt est une directive Apache : il n'a aucun effet sur BunnyCDN. Il ne sert que si l'application est un jour redéployée sur Apache, et n'a pas pu être validé faute d'Apache disponible (voir §9).
  • Variables d'environnement : aucune. La configuration est codée en dur (§3.3).

2.3 Technologies​

  • JavaScript vanilla ES2020, sans framework ni gestionnaire de packages. Navigateurs minimaux : Chrome/Edge 80+, Firefox 74+, Safari 13.1+.
  • SheetJS 0.20.3 : unique librairie tierce, hébergée en local (js/vendor/xlsx.full.min.js), chargée en defer. Aucun CDN à l'exécution. ⚠️ La publication npm de SheetJS est arrêtée depuis la 0.18.5 : les mises à jour se récupèrent uniquement sur https://cdn.sheetjs.com/.
  • CI/CD : aucune pipeline. Suite de tests Node (tests/, 44 assertions, sans npm ni framework) à lancer manuellement avant tout commit touchant les JS (§7.1). Déploiement manuel : git push, puis mise en ligne des fichiers statiques.

3. Installation & mise en place​

3.1 Récupération et lancement​

git clone https://github.com/ndjpc/Pegasus.git
cd Pegasus && python3 -m http.server 8000    # puis http://localhost:8000/

Aucune installation ni build. Seul un accès réseau à l'API TecDoc est nécessaire. En déploiement sur serveur, ne jamais exposer .git/ : préférer rsync --exclude='.git' à un git clone dans le DocumentRoot (le .htaccess bloque .git/ et docs/, mais uniquement sur Apache).

3.2 Configuration & secrets​

  • La seule configuration fonctionnelle est l'objet API_CONFIG en tête de js/script.js (baseUrl, provider 22783, apiKey envoyée en header X-Api-Key).
  • index.html réaffiche le Customer Number et la clé dans deux champs désactivés et purement décoratifs : aucun code ne les lit.
  • Changement de clé : modifier API_CONFIG.apiKey dans js/script.js et le champ d'affichage d'index.html, puis redéployer. Rotation : voir §5.3.

3.3 Jeux de données​

Aucun seed (pas de base). Les jeux de test sont des fichiers Excel réels : exports catalogue, fichier maître ExportCombineDPAN_Rtec_Tmm.xlsx, catalogue tiers (ex. BE TURBO). ⚠️ Ces fichiers ne sont pas dans le dépôt — leur emplacement doit être communiqué au repreneur.

4. Architecture interne​

Arborescence, parcours détaillé du code et invariants à ne pas régresser : voir le README.md. Composants critiques :

  • makeApiCall (js/script.js) : point d'entrée unique vers TecDoc. Injecte articleCountry: 'FR' et lang: 'fr', et force includeOENumbers + includeAll sur getArticles — c'est ce qui conditionne les colonnes OE / Poids / Longueur / Norme pollution des exports. apiAvecReprise l'enveloppe de 3 tentatives avec backoff.
  • extraireCatalogue / extrairePages : extraction en flux au-delà du plafond API de 10 000 résultats, par découpage en familles d'articles puis dédoublonnage par articleNumber. C'est l'invariant central du projet (tests/test-partition.js en est le garde-fou).
  • Exports : implémentation unique — articleToCsvRow/articlesToCsv (CSV), articleToExportRow (XLSX), downloadBlob. csvCell neutralise les préfixes de formule Excel (= + - @).
  • detecterColonnes (js/grpExcel.js) : détection stricte des colonnes ; échec explicite si une colonne manque. Dédoublonnage sur la clé composite marque + référence.
  • buildMasterOEIndex / findOEMatches (js/analyseRef.js) : index inversé numéro OE → référence, construit une fois au chargement du maître.

Conventions : pas de lint ; fonctions en camelCase (mélange français/anglais) ; fins de ligne LF. Depuis l'audit : une branche par sujet, main reste déployable.

5. Sécurité & contraintes​

5.1 Validation & sanitization​

  • Fichiers importés : contrôle d'extension et plafond de 25 Mo par fichier, lecture séquentielle (readAsArrayBuffer) ; détection de colonnes bloquante avec message listant les colonnes trouvées.
  • Exports CSV : guillemets échappés, préfixes de formule neutralisés, BOM UTF-8.
  • Risque XSS résiduel accepté : des insertions innerHTML sans échappement systématique subsistent (données TecDoc et rendus internes ; l'outil d'analyse échappe ses messages). Risque jugé faible et écarté volontairement : pas d'authentification, de session, de cookie ni de stockage navigateur (aucun jeton à voler), et aucun paramètre d'URL n'alimente le DOM (pas de déclenchement par lien piégé). Le seul scénario est l'import volontaire d'un fichier hostile par un utilisateur autorisé.

5.2 Contrôle d'accès​

Pas de RBAC ni d'authentification applicative. Deux mesures compensatoires cumulatives :

  1. 403 BunnyCDN : l'application n'est servie qu'au réseau autorisé du Groupe Niort (configuration en pull zone), HTTPS forcé.
  2. Dépôt GitHub privé, contributeurs limités aux comptes internes.

Contrôle périodique recommandé, depuis une connexion externe : curl -o /dev/null -w "%{http_code}" https://pegasus.dpan.fr/ doit retourner 403.

5.3 Secrets​

  • La clé API TecDoc est en clair dans js/script.js, index.html et tout l'historique git depuis le commit initial. Toute copie du dépôt la contient.
  • Risque maîtrisé tant que les deux mesures du §5.2 tiennent. Risque résiduel : la clé est valide depuis n'importe quelle origine réseau (pas de restriction IP côté TecAlliance à ce jour — voir §9).
  • Rotation à déclencher lors de toute passation du dépôt à un tiers : régénérer la clé côté TecAlliance, la reporter dans js/script.js + index.html, redéployer (~10 min de redéploiement, hors délai TecAlliance).
  • Décision d'architecture : le proxy backend qui masquerait la clé a été écarté volontairement (il contredirait le choix 100 % statique pour un gain marginal dans ce contexte). Réversible si le périmètre d'exposition évolue.

5.4 Sauvegardes et RGPD​

Le dépôt GitHub est la seule source de vérité du code ; restauration = re-clone + redéploiement. Aucune donnée personnelle traitée, pas de cookies ni de tracking ; logs standard côté hébergeur.

6. Exploitation​

  • Monitoring / alerting : aucun. Erreurs affichées dans l'interface et la console. En cas de quota dépassé, clé invalide ou API indisponible : vérifier le compte TecAlliance.
  • Limites connues (état courant, après correctifs) :
    • Une famille d'articles dépassant à elle seule 10 000 références reste tronquée (contrainte API) ; le résultat est marqué partiel et l'UI invite à affiner par catégorie.
    • La recette navigateur complète des trois outils n'a pas été refaite après l'audit : la logique a été vérifiée sous Node contre l'API réelle, pas le rendu ni les interactions.
    • Les exports produits avant les correctifs d'août 2026 peuvent être faux (dédoublonnage, lots, recherche tronquée) — voir §9.

7. Maintenance & évolutivité​

7.1 Tests​

for t in tests/test-*.js; do node "$t"; done

44 assertions couvrant les fonctions dont un bug produit un fichier plausible mais faux : dédoublonnage composite, partitionnement de l'extraction, index OE, exports CSV/XLSX. ⚠️ test-script.js et test-partition.js appellent l'API de production (quota). À lancer avant tout commit modifiant script.js, grpExcel.js ou analyseRef.js. Détails : tests/README.md.

7.2 Dette résiduelle et arbitrages​

  • Restes assumés de l'audit : quelques sélecteurs CSS en doublon dans css/style.css, commentaires anciens (// NOUVEAU:), deux fonctions de téléchargement proches.
  • Arbitrage : sur ~4 000 lignes statiques maintenues par deux personnes, l'industrialisation (framework, bundler, npm, CI, modules ES) coûterait plus qu'elle ne rapporte : elle est délibérément écartée tant que l'usage ne s'étend pas.
  • Règle de priorisation : tout ce qui peut produire un fichier faux sans message d'erreur prime sur le reste. Préserver les invariants du §4 ; les tests sont le garde-fou.

8. Annexes​

Formats d'export​

ExportOutilColonnes
CSV catalogue / catégorieindex8 : Numéro Référence, Marque, ID Data/Man, Références OE, Numéros OE uniquement, Poids, Longueur, Norme pollution. Séparateur ;, BOM UTF-8.
XLSX (lot affiché, recherche)index8, identiques au CSV (articleToExportRow, implémentation unique).
Export-Combine.xlsxcombinaisonToutes les colonnes des fichiers importés, dédoublonnées sur marque + référence.
<fichier>_Equivalences_OE_vers_OE.xlsxanalyseColonnes du fichier analysé + DPAN, Rtec, TMM, Nombre d'équivalences trouvées. ⚠️ Restreint aux lignes ayant au moins une équivalence (comportement voulu).

API​

  • Exemple : POST sur le jsonEndpoint, header X-Api-Key, corps { "getArticles": { "provider": 22783, "dataSupplierIds": [...], "perPage": 100, "page": 1 } }.
  • Introspection : ajouter ?xsd=1 à l'URL du soapEndpoint renvoie le schéma complet — source de vérité quand un paramètre est en doute.
  • Guide fournisseur : docs/TecDoc Pegasus 3.0 API - Onboarding Guide 3.0.pdf.

9. Points à confirmer par le Groupe Niort​

Éléments extérieurs au dépôt, non vérifiables depuis le code :

#PointEnjeu
1403 effectif en production : curl depuis une connexion externe, et revue de la règle d'accès dans la pull zone BunnyCDN.C'est le seul contrôle d'accès de l'application (§5.2).
2L'IP publique autorisée est bien celle du Groupe Niort, et elle est fixe.Une réattribution ouvrirait l'accès à un tiers.
3Liste des personnes ayant accès au dépôt GitHub (pas seulement les auteurs de commits).Base de l'évaluation « risque maîtrisé » de la clé (§5.3).
4Politique TecAlliance : restriction de la clé par IP, quotas, procédure et délai réels de régénération.Conditionne le risque résiduel et la rotation (§5.3).
5Sort des exports produits avant les correctifs d'août 2026 : à régénérer ou non.Des fichiers faux ont pu alimenter des décisions métier (§6).
6Volumétrie réelle des fichiers traités par l'outil d'analyse.Dimensionne les limites à surveiller.