Le contexte
Notre client exploite une ligne de transformation qui déroule simultanément une bobine de matière et un support, imprime le résultat avec des plaques montées sur un nombre limité d’encriers, perfore, puis découpe la laize dans le sens de la longueur pour produire plusieurs bobines finies en un seul passage.
Préparer un passage machine — ce que le métier appelle un plan de production — consiste à choisir de façon cohérente la bobine d’alimentation et son support, l’outillage de perforation, le plan de découpe qui fixe la séquence exacte des largeurs, les produits finis placés dans chaque emplacement, puis les plaques d’impression et la répartition des couleurs sur les encriers disponibles.
Ces choix ne sont pas indépendants, et c’est là que le métier devient difficile.
Avant le projet, tout cela vivait dans la tête de quelques opérateurs expérimentés, avec un tableur en appui. Les conséquences étaient prévisibles : dépendance forte à deux ou trois personnes, préparation longue, combinaisons sous-optimales retenues faute de temps pour explorer mieux, et erreurs détectées en pied de machine — donc réglages à refaire et matière perdue.
La question posée au logiciel est en apparence simple : étant donné ce que l’opérateur a déjà sélectionné, que peut-il encore choisir ? Y répondre exactement suppose de résoudre à chaque clic un pavage exact avec séquencement, doublé d’une coloration sous contrainte de ressources. Ces sous-problèmes sont NP-difficiles, le catalogue compte plusieurs milliers de références, et la réponse doit arriver assez vite pour qu’on la prenne pour une interface.
Ce que nous avons fait
Nous avons développé le logiciel, mis en service en 2019, et nous le maintenons et l’enrichissons depuis.
- Un configurateur interactif, pas un optimiseur en boîte noire. La décision reste à l’opérateur ; le logiciel lui interdit seulement les impasses. Ce qui est grisé est impossible, et quand une contrainte ne laisse plus qu’un candidat, le logiciel le sélectionne seul et propage. Un optimiseur qui rend un plan « idéal » sans l’expliquer aurait été contourné en trois semaines.
- Une propagation jusqu’au point fixe. À chaque action, une vingtaine de filtres réduisent mutuellement les ensembles de candidats et itèrent jusqu’à ce que plus rien ne bouge. Ils sont ordonnés du moins coûteux au plus coûteux, et dès qu’un filtre bon marché a éliminé quelque chose, le cycle repart : les filtres coûteux ne travaillent jamais sur un ensemble qu’on aurait pu réduire à moindre frais.
- Une réduction par classes d’équivalence. Deux références qui partagent largeur, nombre d’empreintes et couleurs sont interchangeables du point de vue de la faisabilité. Le moteur les regroupe derrière une empreinte commune : l’espace de recherche s’effondre, et un résultat devient réutilisable d’une référence à l’autre.
- Un cache de faisabilité à double indexation. Les combinaisons valides déjà trouvées sont mémorisées comme multi-ensembles d’empreintes. Le cache répond soit directement sur la sélection courante, soit par inclusion, en réutilisant une combinaison plus large déjà connue dès lors qu’elle contient la sélection et que son complément reste disponible. En usage réel, la grande majorité des questions posées au moteur n’atteint jamais la recherche.
- Une preuve d’existence plutôt qu’une énumération. Pour valider une option, il suffit d’exhiber une combinaison réalisable : la recherche s’arrête au premier témoin, et les candidats sont explorés dans un ordre choisi pour tomber vite dessus.
- Une synchronisation continue avec l’ERP. Articles, stocks et historique de ventes sont répliqués en incrémental sur horodatage de modification, par lots, avec reprise sur erreur. Deux pièges propres à la source ont dû être absorbés : un décalage de fuseau horaire sur les dates, et un horodatage arrondi à la minute qui oblige à relire une fenêtre glissante pour ne rien perdre. L’atelier travaille sur des données à jour sans ressaisie, et l’ERP reste la source de vérité.
- Un dialogue direct avec l’automate de la ligne. Un service dédié interroge sa vitesse plusieurs fois par seconde et relance la liaison en cas de blocage. Ce flux brut est agrégé en périodes de production, périodes d’arrêt et métrage réalisé : la production n’est plus déclarée, elle est mesurée. Un émulateur permet de développer et de démontrer hors atelier.
- La planification, les quantités et le reporting. Calendrier, plages d’ouverture, maintenances et durées de changement de série réparties entre les postes concernés. L’historique de ventes alimente un calcul de quantités qui classe chaque produit par criticité, de l’impératif au surstock : l’opérateur voit non seulement ce qu’il peut produire, mais ce qu’il devrait produire. Le rapport quotidien est généré en PDF, archivé et envoyé sans intervention humaine.
Côté ingénierie, deux décisions ont porté le reste. Le vocabulaire métier est encodé dans le système de types — une soixantaine de types décrivent formellement matières, outillages, plans de découpe et objets d’ordonnancement — et ce fichier fait davantage référence sur le métier que n’importe quelle documentation. Et le moteur ne connaît rien de l’affichage : il expose un état que l’interface se contente de rendre, ce qui a permis de le refondre en profondeur sans toucher aux écrans.
Le résultat
Le logiciel tourne en atelier depuis 2019. Il est utilisé tous les jours, au cœur de l’entreprise : aucun passage machine ne se prépare sans lui. Il continue de recevoir des évolutions, y compris une migration de son moteur de stockage — le signe le plus fiable qu’un logiciel métier a trouvé sa place : on continue d’investir dessus.
Le savoir-faire de préparation est passé de la mémoire de quelques personnes à un actif logiciel de l’entreprise. La préparation d’un plan est devenue affaire de minutes, et les combinaisons invalides ne remontent plus jusqu’à la machine. La production réelle est mesurée à la source, et le reporting quotidien ne coûte plus de temps humain.
L’enseignement le plus utile est un détail d’implémentation qui décide de la tenue de l’ensemble : chaque filtre renvoie le tableau d’origine par référence quand il n’élimine rien. La détection de convergence devient alors une comparaison de références, gratuite, au lieu d’une comparaison profonde à chaque itération. Sur une boucle qui tourne à chaque clic, c’est la différence entre une interface et un sablier.