Projet Data Legacy

1. Le Contexte et l'Urgence Opérationnelle

Le projet "Legacy" a été initié par la Direction du Support Avions Falcon (DAFS) face à une urgence physique et comptable : la saturation critique de nos espaces logistiques. Les sites de Montrichard (MTRS) et de Tremblay-en-France (CDGS) manquaient cruellement de place.

L'objectif stratégique était double :

• Libérer des surfaces logistiques indispensables pour accueillir les pièces du futur programme Falcon 10X.
• Restituer des espaces sur le site de MTRS pour les confier aux activités de la Direction Générale du Soutien Militaire (DGSM).

La cible ? Les stocks dormants de la gamme "Legacy", regroupant les pièces des anciens modèles Falcon 10, 20 et 50. Après une analyse de la Supply Chain, un périmètre de 10 000 lignes de stock m'a été confié pour traitement et ferraillage.

2. Le Défi Technique : L'Architecture SAP & SPEED

La complexité majeure de cette mission résidait dans l'architecture informatique de Dassault Aviation. Nos processus s'appuient sur deux systèmes distincts qui doivent impérativement rester synchronisés via des messages d'interface (IDOC) :

Pour chaque ligne de stock, il fallait croiser les données de trois fichiers massifs : le fichier cible (SCRAPP), l'extraction des stocks SAP (ZINV) et l'extraction physique SPEED. Une vérification manuelle de ces 10 000 lignes, à raison de 5 minutes par ligne, aurait nécessité 833 heures de travail (soit 24 semaines à temps plein).

3. Ma Solution : L'Algorithme Python

Pour sécuriser le projet, éviter les erreurs humaines et tenir les délais serrés, j'ai pris l'initiative de concevoir et développer un script d'automatisation en langage Python.

Ce programme a permis de :

• Homogénéiser les formats de données et standardiser les Part Numbers (PN).
• Prioriser géographiquement le site militaire de MTRS.
• Vérifier automatiquement les quantités de façon croisée : la quantité retenue était le minimum disponible entre le besoin SCRAPP, la réalité comptable SAP et la présence physique SPEED.
• Générer un fichier de synthèse prêt à être injecté par batch dans les demandes SAP.

4. Gestion de Crise : Le Piège des Rejets IDOC

Après un audit complet des logs d'erreurs, j'ai identifié la source du conflit. Le WMS (SPEED) regroupait parfois certains lots physiques, tandis que l'ERP (SAP) les fragmentait en plusieurs sous-lots stricts. Mon script initial, qui se basait sur la logique physique (SPEED) pour déterminer les quantités, créait donc un décalage comptable dans SAP.

Résultat de la correction : Le taux d'erreur informatique et de rejet IDOC est tombé instantanément sous la barre des 2%.

5. Résultats et Chiffres Clés (KPIs)

L'approche algorithmique, couplée au suivi rigoureux des exécutions, a permis d'atteindre et de dépasser les objectifs fixés par la Direction. La ventilation des résultats met en évidence une destruction comptable de 2,7 millions d'euros. Le reliquat des pièces non détruites sur le site militaire a ensuite été transféré avec succès par mes soins vers le hub de Tremblay.