Architecture de l'Ecosysteme

Vue d'ensemble

L'écosystème se compose de 3 projets qui fonctionnent ensemble pour fournir une plateforme complète de chiptuning ECU :

Projet	Stack	Rôle
FRT-CMS1	PHP 7.0, Zend Framework 1.x	Back-office admin, gestion providers, workflow tuners
FRT-File-Service	PHP 8.1, Symfony 5.4	Plateforme client, upload/download, paiement
FRT-Intellitune	Python 3.11, Celery, CherryPy	Moteur de tuning, encryption/décryption, catégorisation ECU

---

FRT-File-Service — Plateforme client

Rôle

C'est le site web client. Les professionnels du chiptuning s'y connectent pour uploader leurs fichiers ECU, sélectionner un tuning, payer et télécharger le résultat.

Stack technique

• PHP 8.1 avec Symfony 5.4
• Doctrine ORM avec multi-database (3 bases MySQL)
• Webpack Encore pour le frontend (jQuery, Bootstrap, Chart.js, DataTables)
• Stimulus.js pour les controllers JS
• Google Cloud Storage pour le stockage des fichiers ECU
• Symfony Messenger pour le traitement asynchrone

Bases de données

Base	Contenu
olsx	Users, Vehicle, FileRequest, FileReceived, ReadingTool, Payment, Credit
shiftech	Manufacturers, Models, Engines, ECUs, Tunings, Options, Prix, CMS Users
olsx_graph	Données de calibration et parsing graphique

Fonctionnalités principales

Upload de fichiers ECU

User sélectionne véhicule + tuning + options
  → FileUploadController
  → Validation formulaire
  → Création Vehicle (BDD)
  → Calcul du prix (crédits)
  → Hash SHA256 du fichier
  → Upload vers Google Cloud Storage
  → Envoi à Intellitune pour traitement

Gestion Master / Slave

Le système distingue deux types d'outils de lecture ECU :

• Master : KESS, KTag, interfaces OBD/JTAG directes → fichier ECU non-encrypté
• Slave : AutoTuner, KESS slave, FLEX slave → fichier encrypté par l'outil

Calcul de prix

Le prix d'une opération dépend de :

• Type de tuning : stage0, stage1, stage2, stage3, stage4, fullpack
• Options : DPF off, EGR off, DTC removal, AdBlue, vmax, gearbox...
• Outil : Master (moins cher) vs Slave (+ crypt_fee)
• Provider : OLSx, Shiftech, Motortech, Rstronic, TCM-Turbo...
• Historique : prix réduit pour les clients récurrents
• Frais : platform_fee + crypt_fee (slave) + beta_fee (intellidrop)

Paiement

• Stripe — paiement par carte (tokenized, multi-devises)
• PayPal — Express Checkout
• Zoho Books — génération de factures

GraphBundle — Parsing de calibration

Parse les fichiers de diagnostic pour visualiser les maps moteur :

Format	Source
VAG CSV	Groupe Volkswagen (VAG, Audi, Skoda, Seat)
KESS	Module KESS
INCA	Protocole Bosch INCA
VCDS	VAG-COM Diagnostic System
Durametric	Diagnostic Porsche
Raw	Format binaire brut

Réception des fichiers tunés

Intellitune termine le tuning
  → Callback HTTP vers File-Service
  → FileReceiver::receive()
  → Création FileReceived (BDD)
  → Écriture fichier dans /var/files/{ori|prepa|hold|development}/
  → Comptabilité provider
  → Notification push + email au client

Traitement asynchrone (Symfony Messenger)

Message	Rôle
TuneCallData	Soumet le fichier à l'API Intellitune pour tuning
BackupCallData	Archive les données ECU
OriCallData	Traitement du fichier original
InvoiceData	Génération de facture
RetryBackupCallData	Retry des backups échoués

Multi-langue

9 langues supportées : FR, EN, NL, ES, DE, ZH, EL, RO, IT. Toutes les routes ont un préfixe {_locale}.

Stockage fichiers

Local :
  /var/files/ori/              ← Dumps ECU originaux (zippés)
  /var/files/original_ori/     ← Fichiers originaux .ori
  /var/files/prepa/            ← Fichiers tunés (prêts au download)
  /var/files/prepa_hold/       ← En attente de review manuelle
  /var/files/development/      ← Dev only
  /var/files/hold/             ← En attente

Google Cloud Storage :
  bucket hash_full             ← Fichiers non-encryptés (Master)
  bucket crypted               ← Fichiers encryptés (Slave)

---

FRT-Intellitune — Moteur de tuning ECU

Rôle

C'est le cerveau algorithmique. Il gère l'encryption/décryption, la catégorisation des ECU, et l'application des algorithmes de tuning.

Stack technique

• Python 3.11 avec Poetry (package management)
• CherryPy 18.10 — API REST (WSGI)
• Celery 5.4 — Workers distribués (tâches asynchrones)
• RabbitMQ — Broker Celery
• Redis 5.0 — Result backend Celery + cache
• Google Cloud : Datastore, Storage (GCS), Logging, Secret Manager
• NumPy / SciPy — Calculs numériques (maps de calibration)
• MySQL 9.0 — Données relationnelles

Architecture interne

Composants principaux

Composant	Rôle
backend-web-interface	API REST CherryPy, validation, routing
celery-main	Workers de tuning, catégorisation, algorithmes
ecu-runner	Moteur de catégorisation ECU, détection d'originalité
lib/intellitools	Manipulation bas-niveau des fichiers ECU, wrappers crypto
lib/intellitune	Algorithmes de tuning, parsing binaire, signatures ECU

Encryption / Décryption des fichiers ECU

C'est ici et uniquement ici que l'encryption/décryption a lieu. Chaque outil slave a sa propre API propriétaire :

Données slave nécessaires

Pour chaque opération crypto, Intellitune a besoin de :

• tool — identifiant de l'outil (AT, KESS_V2, KESS_V3, KTAG, FLEX, BFLASH, CMD)
• slave_data.slave_extension — extension du fichier slave
• slave_data.slave_ids — identifiants client de l'outil (ex: customer ID Alientech)

Flux complet d'un fichier slave

Catégorisation ECU

Le système analyse le binaire brut pour identifier automatiquement l'ECU :

Processus

1. Détection format — Fichier vide ? ID file ? Format binaire valide ?
2. Détection marque — Signatures texte dans le binaire (ex: "Ford Motor Company", numéros Toyota 89663-...)
3. Classification ECU — Bosch EDC16, MEDC17, MDG1, Denso, Delphi, Siemens...
4. Détection maps de calibration — Signatures connues → offsets, dimensions, types de données
5. Détection DTC — Codes erreur OBD2 et leurs offsets de désactivation

Marques supportées (60+)

Alfa Romeo, Aston Martin, Audi, BMW, Cadillac, Chevrolet, Dodge, Ferrari, Fiat, Ford, GM, Honda, Hyundai, Isuzu, Iveco, Jeep, Kia, Lamborghini, Land Rover, Lexus, Lincoln, Maserati, Mazda, McLaren, Mercedes, Mitsubishi, Nissan, Opel, Pagani, Peugeot, Porsche, Ram, Renault, Rolls-Royce, Saab, Seat, Skoda, Smart, Subaru, Suzuki, Tesla, Toyota, Volkswagen, Volvo...

Le fichier de catégorisation principal fait 426 000 lignes avec 100 000+ signatures ECU.

Algorithme de tuning

Types de modifications

Type	Description
ABS	Valeur absolue
DIFF	Delta / différence
PERCENT	Changement en pourcentage
POWER	Boost puissance/couple
POWER_ADD	Boost additif
MAX	Valeur maximale autorisée
MIN	Valeur minimale autorisée
SUBS	Substitution directe
SQUARE	Transformation quadratique
SEQUENCE	Changements séquentiels

Stages de tuning

Stage	Description
stage0	Baseline / original (pas de changement)
stage1	Tuning modéré
stage2	Tuning agressif
stage3	Configuration avancée
stage4	Configuration maximale

Options courantes

• dpf — Suppression filtre à particules
• egr — Suppression vanne EGR
• vmax — Suppression limiteur de vitesse
• dtc — Suppression codes erreur
• adblue — Suppression AdBlue
• gearbox — Modification boîte de vitesses

Stockage

Bucket GCS	Contenu
FULL_STORAGE	Fichiers ECU non-encryptés (hash SHA256 = clé)
CRYPT_STORAGE	Variantes encryptées (slave)

Hash utilisés :

• hash_full — Hash du fichier ECU complet
• hash_full_crypt — Hash de la variante encryptée
• hash_calib — Hash de la zone de calibration uniquement

API endpoints

Endpoint	Méthode	Rôle
/v1/tune/submit_categorize	POST	Soumettre un fichier pour catégorisation
/v1/tune/poll_categorize	POST	Vérifier le résultat (polling async)
/v1/tune/submit_tune	POST	Soumettre pour tuning
/v1/tune/get_tune	POST	Récupérer le résultat tuné
/v1/tune/send_and_backup_client_decrypt	POST	Envoi + backup avec décryption client
/v1/ori/get_file_from_storage	POST	Récupérer un fichier par hash
/v1/ori/get_entities_from_sw1	POST	Requêter les entités ECU par software ID
/v1/ori/file_in_storage	POST	Vérifier si un fichier existe
/v1/intellitune/upload_pair_from_request	POST	Uploader une paire original/tuné
/v1/statistics/user_ranking	POST	Classement des utilisateurs

Base de données

Google Cloud Datastore (namespace intellitune)

Entité	Champs clés
Full Entity	sw1, sw2, ecu_path, brand_group, file_structure, tuning, is_ori
Upload Pair	hash_full_original, hash_full_tuned, stage, options, provider
Source	hash_full, tuning, source, provider, tuner, request_id

---

FRT-CMS1 — Back-office admin

Rôle

C'est le back-office pour les administrateurs et les tuners professionnels. Il gère les providers, le workflow des demandes, la comptabilité et l'interface Intellidrop.

Stack technique

• PHP 7.0.33 avec Zend Framework 1.x
• MySQL 5.7 (3 bases : shiftech, shiftech_cms, olsx)
• jQuery 1.9.1, Bootstrap, DataTables, Select2, TinyMCE
• Docker : PHP-FPM 7.0 + Nginx + Supervisor

Fonctionnalités principales

Fonction	Description
Gestion providers	CRUD providers, groupes, permissions, outils assignés
Workflow tuners	File d'attente des demandes, assignation aux préparateurs
Comptabilité	Suivi des crédits, frais platform/crypto, facturation par provider
Intellidrop (UI)	Interface web pour le tuning manuel — reçoit les fichiers décryptés d'Intellitune
ACL	140+ ressources, rôles visitor/user, row-level auth
2FA	Email token ou Google Authenticator (TOTP)
Gestion fichiers	Download, upload manuel décrypté, historique
Services API	Jira, Zoho, WhatsApp, CloudFlare, EVC, Push notifications

Gestion des fichiers dans le CMS

Le CMS ne fait pas d'encryption/décryption. Il gère uniquement le workflow :

La méthode getFileCryptedPath() est la seule qui distingue Master/Slave :

• Master → retourne false (pas de fichier encrypté séparé)
• Slave → retourne le chemin vers le fichier .slave_ori dans /var_upload/

Répertoires de stockage

/data/file-service/var_upload/    ← Fichiers uploadés (encryptés slave)
/data/file-service/var_files/     ← Fichiers en traitement
  ├── /ori/                       ← Originaux (.zip, .ini, .ori)
  ├── /prepa/                     ← Tunés (.prepa, .prepa-crypted)
  ├── /partial/                   ← Tuning partiel (.tun_partial)
  ├── /development/               ← Dev (.tun, .prepa)
  ├── /hold/                      ← En attente
  └── /original_ori/              ← Backup originaux

---

Flux complet : de l'upload au téléchargement

Scénario : Client avec un outil Slave (AutoTuner)

Scénario : Client avec un outil Master (KESS)

Le flux est identique mais sans les étapes d'encryption/décryption :

• Le fichier est uploadé en clair dans le bucket hash_full
• Pas de crypt_fee
• Intellitune reçoit directement le binaire brut
• Le fichier tuné est renvoyé en clair

Scénario : Tuning manuel requis (Intellidrop)

Quand Intellitune ne peut pas traiter automatiquement un fichier (ECU non reconnu, tuning complexe, review requise), le fichier passe en statut hold et un tuner intervient manuellement via l'interface Intellidrop dans le CMS.

Point clé

Le tuner travaille toujours sur le fichier décrypté. Intellitune gère l'encryption/décryption de manière transparente :

• GET /v1/tune/get_ori → renvoie le binaire ECU décrypté
• POST /v1/tune/submit_tuned → Intellitune ré-encrypte avant d'envoyer au client

Le tuner n'a jamais à manipuler de fichier encrypté, même pour un outil slave.

---

Architecture Multi-Provider / Resellers

Le CMS gère deux niveaux d'entités commerciales :

• Providers (CMS) — entreprises qui opèrent le tuning avec leurs propres tuners
• Resellers (File-Service) — réseaux commerciaux qui uploadent pour leurs clients

Providers (CMS)

Les providers sont des entreprises de tuning indépendantes qui opèrent leur propre back-office :

Provider	Description
OLSx	Provider principal (plus gros volume)
Motorperf	...
SD Performance	...
917+	...

Chaque provider :

• A ses propres tuners et équipe
• Opère son back-office (workflow, comptabilité, Intellidrop)
• Peut définir ses tunings et options spécifiques (OlsxTuningsProviders, OlsxOptionsProviders)
• A sa comptabilité séparée (OlsxProvidersAccounting)
• A son propre domaine (détection via OlsxProviders::findByDomainName)

Switch Provider

Les utilisateurs avec le flag can_switch_provider peuvent basculer entre providers via le menu en haut à droite du CMS. Utile pour les admins qui gèrent plusieurs providers.

Resellers (File-Service)

Les resellers sont des réseaux commerciaux côté File-Service qui interagissent avec les clients finaux :

Reseller	Description
Shiftech	Réseau de garages en France
Motortech	...
Rstronic	...
TCM-Turbo	...

Chaque reseller :

• A ses propres groupes de clients sur File-Service
• Upload les fichiers ECU pour ses clients
• Est rattaché à un provider pour le traitement
• A un accès limité au CMS via le rôle reseller

Vue d'ensemble

Flux typique

1. Client final amène sa voiture chez un garage Shiftech (reseller)
2. Shiftech lit l'ECU et upload le fichier sur File-Service
3. La demande arrive chez le provider rattaché (ex: OLSx)
4. Un tuner du provider traite la demande (via Intellidrop ou automatiquement)
5. Le fichier tuné est renvoyé à File-Service
6. Shiftech télécharge et flashe le véhicule du client

Isolation des données

• Chaque provider ne voit que ses propres demandes et tuners
• La comptabilité est séparée par provider
• Les resellers sont rattachés à un provider spécifique via leurs groupes

---

Répartition des responsabilités

Projet	Encryption / Decryption	Categorisation ECU	Algo Tuning	Upload Client	Paiement	Back-office Admin	Providers	Comptabilite	Graph / Calibration	Multi-langue
FRT-CMS1	—	—	—	—	—	X	X	X	—	—
FRT-File-Service	—	—	—	X	X	—	—	X (Zoho)	X	X
FRT-Intellitune	X	X	X	—	—	—	—	—	—	—

Outils de lecture ECU supportés

Outils Master

Les outils Master lisent et écrivent directement dans la mémoire de l'ECU. Les fichiers sont non-encryptés.

• Interfaces OBD directes
• Interfaces JTAG/BDM
• Outils avec licence "master"

Outils Slave

Les outils Slave produisent des fichiers encryptés qui nécessitent un passage par l'API du fabricant pour décryption/ré-encryption.

Fabricant	Outil	Code	API
Alientech	KESS v2	KESS_V2	Alientech API
Alientech	KESS v3	KESS_V3	Alientech API
Alientech	KTag	KTAG	Alientech API
Autotuner	Autotuner	AT	Autotuner API
Magic Motorsport	FLEX	FLEX	Magic Motorsport API
BFlash	BFlash	BFLASH	BFlash API
Focus Research	CMD Flash	CMD	Local (filesystem)

Entités en base de données

---

Communication entre les projets

File-Service → Intellitune

Endpoint Intellitune	Appelé quand
POST /v1/tune/submit_categorize	Upload d'un nouveau fichier ECU
POST /v1/tune/poll_categorize	Polling du résultat de catégorisation
POST /v1/tune/submit_tune	Demande de tuning
POST /v1/tune/get_tune	Récupération du fichier tuné
POST /v1/ori/get_file_from_storage	Récupération d'un fichier par hash

Intellitune → File-Service

• Callback HTTP avec le fichier traité (base64) + métadonnées
• Paramètre callback_domain passé à chaque requête

CMS → Intellitune

Le CMS appelle directement les endpoints Intellitune pour l'interface Intellidrop. Communication via le service OlsxApi (nom historique — c'est en réalité le client Intellitune).

Endpoint Intellitune	Utilisé pour
POST /v1/tune/submit_categorize	Catégoriser un fichier uploadé manuellement
POST /v1/tune/poll_categorize	Polling du résultat de catégorisation
POST /v1/tune/get_ori	Récupérer le fichier ECU décrypté (pour tuning manuel)
POST /v1/tune/submit_tune	Soumettre un tuning
POST /v1/tune/submit_tuned	Soumettre un fichier tuné manuellement
POST /v1/tune/automatic_available	Vérifier si tuning automatique disponible
POST /v1/intellitune/upload_pair_from_request	Uploader une paire original/tuné

• Authentification : Google Cloud Identity (token JWT via intellitune-front.json)
• Les 3 projets partagent les bases de données MySQL (shiftech, olsx)

Tracking cross-projet

• request_id (UUID) — identifiant unique d'une demande, partagé entre les 3 projets
• file_hash (SHA256) — identifiant unique d'un fichier, utilisé pour la déduplication
• provider_id — identifiant du provider, cohérent entre CMS et File-Service