Laurent Rebiere

Afin d'étendre le marcher cible de la solution Clariprint au métier du Packaging et plus particulièrement de permettre aux clients web-to-print de proposer dans leur e-boutique une offre de Packaging personnalisée à partir de templates paramétriques de "boite".

L'objectif était de pouvoir aisément paramétrer des modèles de packaging, de pouvoir personnaliser les dimensions, support, impression, de visualiser le pliage en 3D, de calculer le prix en temps réel et de fournir un gabarit SVG au client final pour qu'il puisse l'éditer sur Indesign.

J'ai mené le projet seul et en autonomie. J'ai créé le product backlog. J'ai créé un projet de recherche élligible CIR pour la modélisation paramétrique d'une boite réalisée par pliage et la visualisation du pliage en 3D. J'ai réalisé l'opération de recherche dans un environnement technique javascript, webGL, Claire Language. Enfin, j'ai réalisé les développements fonctionnels et l'intégration à la solution. 

Cette étude et réalisation permet de traiter efficacement le cas le plus général de l'amalgame de forme à imprimer sur une feuille d'impression, c'est à dire un ensemble de X formes multi-modèles de tirage différent en Offset feuille ou bobine sortie à plat :

Une forme Fx à plat est définie par une hauteur hx et une largeur lx.

A chaque forme Fx correspond un ensemble kx de modèles M de Q(M) produits.

{F1[M1-1/Q1-1 .. M1-k/Q1-k1] , F2[M2-1/Q2-1 .. M2-k2/Q2-k2] .. Fx[Mx-1/Qx-1 .. Mx-kx/Qx-kx]}

Le problème consiste à déterminer l'ensemble de feuilles d'impression minimisant le coût total de fabrication dans un référentiel de supports (papier, bobine, stock imprimeur, stock distributeur, fabrication) et un référentiel de poste de fabrication (presse offset feuille, rotative ...).

{PF1(X1F1 .. X1Fx) .. PFz(XzF1 .. XzFx)}

Chaque feuille d'impression PF propose un vecteur de nombre de pose par forme.

Vf[X1F1 .. XxFx] puis par spécialisation de l'arrangement, un vecteur de nombre de pose par modèle Vm[X1M1 .. XxMw]. Avec comme ensemble de contraintes à satisfaire :

- Chaque modèle M apparaît sur une et une seule feuille PF.

- Pour chaque feuille d'impression PF, pour chaque modèle M, le nombre de bonnes feuille Qpf >= Qm / Xm ou Qm est la quantité objectif de modèle M et Xm le nombre de poses affectées au modèle M.

D'un point de vue technologique comment cela fonctionne ?

Clariprint fait appel à plusieurs algorithmes d'optimisation, à travers les étapes suivantes :

A/ recherche de solutions de discrétisations du problème en classes de produit en explorant plusieurs quantités de classes (1 classe correspondant à 1 feuille d'impression au final). Clariprint utilise la méthode de discrétisation statistique de minimisation de l'inertie intra-classe. Le calcul de l'inertie utilise d'une part la surface des formes des produits, d'autre part les quantités objectifs pour chaque modèle de produit.

Clariprint utilise le solver de contrainte Choco pour minimiser la somme des inertie intra-classe avec un maximum pour la surface totale d'une classe.

B/ Pour chaque solution de discrétisation trouvée, pour chaque classe, génération de feuilles d'impression.

Clariprint fait appel à un problème Choco avec en entrée :

- liste des formes à imposer ;

- liste des quantités objectifs ;

- format maxi ;

Clariprint utilise 2 logiques de composition de feuilles d'impression différentes :

1/ N colonnes de forme unique + jusqu'à 2 colonnes de forme partagées (4 en bascule In8)

2/ N lignes de forme unique

Chaque logique est déclinée en 3 sous-logiques :

- côté-côté (pas de symétrie),

- In8 (symétrie d'axe parallèle à la hauteur),

- In12 (symétrie d'axe parallèle à la largeur)

Pour rappel les feuilles symétriques permettent de disposer sur un même côté de la feuille d'impression à la fois le Recto des produits et le Verso des produits, ainsi par basculement de la feuille avant un repassage, on peut imprimer à la fois le Recto et le Verso avec les mêmes plaques réduisant de moitié les coûts fixes d'impression par rapport à la méthode côté-côté.

C/ Les feuilles d'impression trouvées sont regroupées en vecteur de forme (nombre de pose pour chaque forme F1 .. Fx). Pour chaque discrétisation, pour chaque classe, Clariprint recherche le meilleur vecteur de forme (celui qui donne le tirage le plus faible). Clariprint utilise ici encore le solver de contraintes Choco.

D/ Enfin, pour déterminer la meilleure solution de fabrication, un algorithme de type Branch and bound explore les propositions de discrétisation dans les référentiels de ressources (papier, presse offset feuille, presse rotative ...).

Depuis la création de Clariprint, à l’issu d’un calcul, l’utilisateur voit, soit un résultat exploitable, soit la mention « impossible à calculer ». Il en ressort que l’utilisateur n’est pas capable de comprendre directement pourquoi un calcul est « impossible », donc incapable d’agir avec certitude sur :

• les caractéristiques du produit dont il souhaite le chiffrage (en phase d’exploitation)

• les données machines ou papier qu’il doit modifier pour calculer le produit (en phase de

paramétrage des données)

Il est donc obligé de procéder à taton, par exemple en modifiant les spécifications du produit jusqu’à ce qu’il obtienne un calcul valide.

D’autre part, quand un calcul abouti, certains utilisateurs experts souhaitent vérifier la logique de l’optimisation afin de s’assurer que le calculateur n’est pas passé à côté d’une meilleure solution, ou afin de comprendre ce qui a entravé le cheminement vers une solution pressentie comme bonne.

Enfin, bien qu’il existe des traces écrites dans un fichier log, elles sont activables uniquement dans le paramétrage du serveur de calcul, nécessite le redémarrage de celui-ci, de se connecter en ssh au serveur pour visionner les logs à la console. Cette procédure, très chronophage, nécessite les compétences d’un développeur, or l’analyse du cheminement et de la pile d’appel est souvent indispensable à la rédaction d’un rapport de bogue ou simplement à la détermination des paramètres manquants ou bloquants dans le paramétrage technique des machines ou des supports.

Donc les objectifs de cette opération sont de résoudre ces problèmes, plus précisément :

1/ être capable en moins de 100 caractères d’exprimer de manière intelligible pour un utilisateur de profil deviseur ou fabricant en imprimerie, une raison à l’impossibilité de calcul (il ne s’agit pas d’être exhaustif mais concis et précis)

2/ produire un log simplifié du cheminement du calculateur :

a/ à l’attention des utilisateurs de profil deviseur ou fabricant en imprimerie,

b/ qui soit accessible directement depuis l’interface graphique,

c/ qui soit hiérarchisé (sous la forme d’un arbre dépliable)

d/ qui met en évidence les points de blocage

3/ de produire un log étendu du cheminement du calculateur :

a/ à l’attention des utilisateurs avancés (gestionnaire d’exploitation chez le client, support Clariprint,

développeurs Clariprint)

b/ qui reprend l’arborescence du log simplifié en la complétant avec les appels fonctionnels jugés

pertinents, les itérations jugées pertinentes (boucle de contrôle « For ») et les interceptions

d’exceptions jugées pertinentes (bloc de traitement encadré par « try » ... « catch »)

Les verrous technologiques et incertitudes

Comment instrumenter le code du calculateur sans l’alourdir ?

Comment déterminer à priori le domaine d’utilisation d’une machine au regard du support

choisi afin de pré-filtrer les impossibilités métiers en amont de la recherche de solution ?

Comment gérer les impossibilités métiers dans un arbre de recherche alternant les branches

complémentaires et les branches concurrentes afin de remonter à l’utilisateur une erreur pertinente

et intelligible ?

Comment minimiser le volume des données du log ?

Quel est l’impact sur le temps de calcul si on systématise la génération du log ?

Le plan de l’opération est le suivant :

1/ customisation du langage Claire et de son compilateur pour créer des « call-back » pour les nouvelles instructions « tfor », « ttry »

2/ création d’un module contrôleur des « front logs » exploitant des « call-back » pour générer des lignes de traces pour les instructions « tfor », « ttry » et « tcall »

3/ création d’apis pour hiérarchiser le log par chapitre et ajouter des commentaires

4/ étape 1 de l’instrumentation du code du calculateur pour tests de génération de logs

5/ création du visualiseur de log : code qui interprète le log et génère dynamiquement une page html

6/ création d’une procédure de pré-contrôle de l’adéquation des données d’un environnement de calcul (parc-machine, papier etc ...) aux spécifications de la demande

7/ Instrumentation du code du calculateur pour détecter les points de blocage, les signaler par des erreurs dans le log, interrompre le calcul ou pas suivant l’apparition du blocage dans un groupe de branche concurrente ou complémentaire.

8/ afficher l’erreur la plus pertinente si le calcul n’a pas abouti

Conclusion :

Même si les résultats gagnent encore à être plus lisible pour les utilisateurs finaux, cette opération est un succès au-delà de toute espérance. Dans le cadre de cette étude nous nous sommes rapidement heurté à l’inadéquation initiale de la conception du calculateur

de Clariprint avec les objectifs visés. Ceci nous a conduit a repensé certaines parties qui au final ont profité à la robustesse de la solution et même à réduire le temps moyen de réponse grâce à des pré-contrôles systématiques.