Intégrer un APS en environnement industriel : retour d'expérience

[!NOTE] TL;DR : L’intégration d’un outil d’ordonnancement (APS) en usine ne s’improvise pas. Dans le cadre de mon alternance chez Orange Business, j’ai transformé un pipeline d’extraction monolithique en une architecture modulaire robuste : passage de 1543 lignes de code à un socle de ~130 lignes par module, réduction des erreurs de typage (323 → 0) et sécurisation par 716 tests automatisés.

L’industrie 4.0 n’est plus un concept abstrait. Sur le terrain, j’accompagne de grands groupes industriels dans l’optimisation de leurs flux de production en temps réel. Mon rôle au quotidien consiste à assurer la convergence entre l’informatique (IT) et les technologies d’exploitation (OT).

Ce défi prend tout son sens lorsqu’il s’agit d’intégrer une solution de planification et d’ordonnancement (APS) unifiée à l’échelle de plusieurs usines européennes.

Contexte : Le choix du sur-mesure (Module vs ETL)

Historiquement, le client industriel avec lequel je collabore fonctionnait en silos : systèmes fragmentés, fichiers de données épars et processus souvent manuels. L’objectif stratégique était d’imposer un outil centralisé, capable de briser ces barrières et de consolider les données de production de chaque usine.

Pour alimenter cet outil complexe, nous devions récolter et traduire les informations de multiples sources (systèmes de gestion, ressources humaines, équipements). Nous aurions pu opter pour un ETL clé en main du marché. J’ai pourtant privilégié un script Python sur mesure, adossé à des tables de transition sécurisées. Pourquoi ce choix structurant ?

• Transparence totale : Essentielle pour diagnostiquer les écarts et comprendre chaque transformation appliquée (impossible avec un ETL “boîte noire”).
• Testabilité : Un script sur mesure permet de valider unitairement chaque règle métier.
• Évolutivité : Isoler la logique source du format cible garantit que l’ajout d’une nouvelle usine n’impactera pas le système global.

Pour découvrir comment j’ai géré mon rôle de référent sur ce projet, lisez mon article sur l’autonomie et la collaboration.

Refonte architecturale : La fin du monolithe de 1543 lignes

Pour répondre à l’urgence des premiers déploiements en Allemagne et en Italie, une première version fonctionnelle a été livrée très rapidement. Cependant, au fil des mois, ce script s’est enrichi pour devenir une véritable dette technique à intérêt composé : un fichier monolithique atteignant 1543 lignes.

Garder cette structure menaçait l’arrivée des futurs sites. J’ai donc imposé une refonte architecturale totale. En m’appuyant sur les modèles de domaine de l’outil cible, j’ai découpé le système en modules à responsabilité unique (configuration, données, modèles, utilitaires). Résultat : le fichier orchestrateur est passé à environ 130 lignes. Dorénavant, toute évolution ne touche qu’un module précis, éliminant les effets de bord incontrôlables.

flowchart LR
    ERP[(ERP Central)] <-->|API REST / JSON| APS{Moteur APS<br/>PlanetTogether}
    APS -->|Nomenclatures| MES[Système MES<br/>Atelier]
    MES -->|Retours Prod| APS
    
    subgraph Cloud [Infrastructure Cloud / Edge]
        APS
    end
    
    subgraph Factory [Usine - Réseau Local]
        MES
    end
    
    classDef db fill:#9333ea,stroke:#7e22ce,stroke-width:2px,color:#fff;
    classDef engine fill:#dc2626,stroke:#b91c1c,stroke-width:2px,color:#fff;
    classDef factory fill:#16a34a,stroke:#15803d,stroke-width:2px,color:#fff;
    class ERP db;
    class APS engine;
    class MES factory;

flowchart TD
    ERP[(ERP Central)] <-->|API REST / JSON| APS{Moteur APS<br/>PlanetTogether}
    APS -->|Nomenclatures| MES[Système MES<br/>Atelier]
    MES -->|Retours Prod| APS
    
    subgraph Cloud [Infrastructure Cloud / Edge]
        APS
    end
    
    subgraph Factory [Usine - Réseau Local]
        MES
    end
    
    classDef db fill:#9333ea,stroke:#7e22ce,stroke-width:2px,color:#fff;
    classDef engine fill:#dc2626,stroke:#b91c1c,stroke-width:2px,color:#fff;
    classDef factory fill:#16a34a,stroke:#15803d,stroke-width:2px,color:#fff;
    class ERP db;
    class APS engine;
    class MES factory;

Assurance qualité : 0 erreur Pyright et 716 tests automatisés

L’architecture seule ne garantit pas la stabilité d’une ligne de production. Pour atteindre une fiabilité de niveau industriel, j’ai piloté la refonte avec des indicateurs stricts :

1. Typage et analyse statique : Le code initial accusait 323 erreurs Pyright. J’ai imposé l’objectif “0 erreur” comme critère strict d’achèvement avant toute mise en production.
2. Couverture de tests massive : Grâce à l’architecture découplée, j’ai pu intégrer 688 tests unitaires et 28 tests d’intégration automatisés via notre GitLab CI. J’ai ciblé les règles les plus critiques, notamment un système de synchronisation qui, dans l’ancienne version, écrasait silencieusement les modifications manuelles des planificateurs.

Cette rigueur, grandement accélérée par ma démarche d’architecte IA (détaillée dans mon approche multi-modèles), a transformé un risque de production en un véritable levier de fiabilité.

Ce que j’en retiens