Relation Master / Slave : ce que chacun doit attendre de l’autre

Une conviction de terrain, partagée par un contributeur et que nous faisons nôtre : la qualité d’un file service ne dépend pas uniquement du fichier envoyé par le Master. Elle repose sur une collaboration technique où chacun tient son rôle — et où chacun sait ce qu’il est en droit d’attendre de l’autre.

Ce que le Master attend de son Slave

Le Master travaille sur ce qu’on lui donne. Il est donc en droit d’exiger :

• une identification précise du véhicule et du calculateur : marque, modèle, motorisation, référence et version exacte du calculateur — pas « une Golf TDI » ;
• un fichier d’origine correctement lu, complet, avec l’outil et le mode de lecture indiqués ;
• l’état mécanique connu du véhicule : entretien, kilométrage, modifications éventuelles (échangeur, ligne, turbo, embrayage…) ;
• les DTC présents AVANT l’intervention : un défaut préexistant découvert après écriture devient un litige évitable ;
• des logs quand c’est nécessaire, et surtout des symptômes décrits techniquement : « à-coups entre 2000 et 2500 tr/min à charge partielle, moteur chaud » se travaille ; « ça marche pas » ne se travaille pas.

Ce que le Slave attend de son Master

Dans l’autre sens, le Slave confie sa réputation au fichier qu’il écrit. Il est en droit d’attendre :

• un fichier adapté au véhicule réel et à la demande réelle, pas une recette générique ;
• des délais annoncés réalistes — et tenus, ou expliqués ;
• une communication claire en cas de limite ou de doute : dire « cette configuration ne permet pas ce résultat » avant l’écriture vaut mieux que le silence après ;
• un vrai suivi après écriture : si un problème apparaît, pouvoir comprendre ce qui a été modifié, obtenir une correction rapide, et revenir à l’origine si nécessaire ;
• la traçabilité des versions : quelle version a été livrée, quelle correction a suivi, où est l’origine.

Les erreurs classiques, des deux côtés

Côté Slave : lecture partielle ou outil inadapté, identification approximative, mécanique fatiguée passée sous silence, demande de correction « au voyant » sans le moindre élément, écriture sans avoir vérifié les DTC avant. Côté Master : fichier expédié sans regarder la demande, absence de réponse quand un souci apparaît, corrections en boucle sans expliquer, origine introuvable au moment où on en a besoin. Un bon Master ne se contente pas d’« envoyer un fichier » ; un bon Slave ne se contente pas de « lire, écrire, et appeler dès qu’un voyant s’allume ».

La check-list avant chaque demande

Avant d’envoyer un dossier, trente secondes suffisent :

1. Identification complète du véhicule ET du calculateur (référence + version).

2. Fichier d’origine lu proprement, outil et mode précisés, origine archivée de votre côté.

3. État mécanique et modifications déclarés.

4. DTC relevés avant intervention, joints au dossier.

5. Demande formulée précisément (prestations voulues, contraintes, usage du véhicule).

6. En cas de souci après écriture : symptômes techniques, conditions d’apparition, logs si possible — puis la demande de révision, avec ces éléments.

Un dossier qui passe cette liste se traite plus vite, mieux, et presque toujours sans aller-retour.

Contribution : proposition et argumentaire de Pegasus (septembre 2026), complétés par notre pratique du traitement de dossiers au quotidien.

Source : pratique du file service des deux côtés de la relation. Les process exacts (formats de dossier, délais, révisions) sont ceux de votre prestataire ; cette fiche décrit ce qu’une bonne collaboration doit contenir, quel que soit l’outil.

Sur ANP Engineering — file service de reprogrammation moteur pour professionnels : file service ECU, correction de checksum, calculateurs pris en charge, tarifs.