Le web-to-print a besoin d'une API d'impression universelle pour exprimer tout son potentiel
Le web-to-print, qu'est-ce que c'est aujourd'hui ? D'un côté, des éditeurs de webapps clés en main, généralement issus du web et qui s'arrêtent à la production d'un PDF plus ou moins normé et, parfois, d'un bon de commande. De l'autre, des imprimeurs qui montrent de l'intérêt pour le procédé tout en étant encore trop souvent entravés dans des infrastructures informatiques lourdes, et généralement propriétaires. Sans oublier, des clients, annonceurs, réseaux de franchisés, chaînes de magasin, collectivités, qui aimeraient bien se procurer ce type de technologie, mais tout en gardant la possibilité d'imprimer où bon leur semble.
Bref, prise individuellement, chaque brique qui compose le web-to-print fonctionne parfaitement. C'est aux coutures que ça coince : comment exploiter les données générées par une webapp de web-to-print dans mon système de production d'imprimerie, en évitant la moindre resaisie et en garantissant une remontée efficace d'information ? Comment m'assurer que les documents que vont produire mes utilisateurs sur le portail w2p seront parfaitement exploitable par un imprimeur que je n'ai pas encore choisi ? Aujourd'hui, à part quelques systèmes totalement intégrés, il n'y a pas de solutions, à moins de se lancer dans des développements lourds, et pas nécessairement rentables. On retrouve à nouveau les points de friction entre les mondes du web (conception), et du print (production) qui caractérisent si bien le procédé du web-to-print.
Pourtant, il y aurait bien une solution. Il suffirait de développer une API qui se charge d'assurer la liaison entre n'importe quelle application web et le système de production d'un imprimeur, en associant les PDF d'impression à un dossier de fabrication en JDF. En effet, le JDF est le format pivot qui convient à tout le monde : aux développeurs, car ce n'est ni plus ni moins que du XML ; aux imprimeurs, car désormais, la plupart de leurs outils de gestion de production sont capables de recevoir ce type de données, puisqu'il s'agit d'une norme internationale. D'ailleurs, beaucoup de ces systèmes utilisent le JDF en interne, pour gérer les jobtickets.
L'API se chargerait ainsi de convertir les données dans le sens éditeur-imprimeur, pour transmettre le dossier de fab' ; mais aussi dans l'autre sens, pour faciliter la remontée des informations de suivi de fabrication et de tracking colis vers l'interface web. Une vraie gare de triage en somme.
Avec une solution de ce type, notre secteur d'activité disposerait enfin d'un levier majeur pour développer les usages web tout en dé-corrélant la conception de la fabrication.
Une imprimerie toute seule ne peut pas assumer ce type de développement, ne nous leurrons pas : mais par contre, c'est le genre de mission que pourrait mener à bien un réseau ou une fédération d'imprimeurs... Commander la réalisation de ce type d'API pour la fournir ensuite à tous ses membres, afin de les rendre "compatibles" avec n'importe quelle solution de web-to-print, où qu'elle se trouve. Voilà un vrai levier de croissance, et un véritable différenciateur sur le marché.
Bref, prise individuellement, chaque brique qui compose le web-to-print fonctionne parfaitement. C'est aux coutures que ça coince : comment exploiter les données générées par une webapp de web-to-print dans mon système de production d'imprimerie, en évitant la moindre resaisie et en garantissant une remontée efficace d'information ? Comment m'assurer que les documents que vont produire mes utilisateurs sur le portail w2p seront parfaitement exploitable par un imprimeur que je n'ai pas encore choisi ? Aujourd'hui, à part quelques systèmes totalement intégrés, il n'y a pas de solutions, à moins de se lancer dans des développements lourds, et pas nécessairement rentables. On retrouve à nouveau les points de friction entre les mondes du web (conception), et du print (production) qui caractérisent si bien le procédé du web-to-print.
Pourtant, il y aurait bien une solution. Il suffirait de développer une API qui se charge d'assurer la liaison entre n'importe quelle application web et le système de production d'un imprimeur, en associant les PDF d'impression à un dossier de fabrication en JDF. En effet, le JDF est le format pivot qui convient à tout le monde : aux développeurs, car ce n'est ni plus ni moins que du XML ; aux imprimeurs, car désormais, la plupart de leurs outils de gestion de production sont capables de recevoir ce type de données, puisqu'il s'agit d'une norme internationale. D'ailleurs, beaucoup de ces systèmes utilisent le JDF en interne, pour gérer les jobtickets.
L'API se chargerait ainsi de convertir les données dans le sens éditeur-imprimeur, pour transmettre le dossier de fab' ; mais aussi dans l'autre sens, pour faciliter la remontée des informations de suivi de fabrication et de tracking colis vers l'interface web. Une vraie gare de triage en somme.
Avec une solution de ce type, notre secteur d'activité disposerait enfin d'un levier majeur pour développer les usages web tout en dé-corrélant la conception de la fabrication.
Une imprimerie toute seule ne peut pas assumer ce type de développement, ne nous leurrons pas : mais par contre, c'est le genre de mission que pourrait mener à bien un réseau ou une fédération d'imprimeurs... Commander la réalisation de ce type d'API pour la fournir ensuite à tous ses membres, afin de les rendre "compatibles" avec n'importe quelle solution de web-to-print, où qu'elle se trouve. Voilà un vrai levier de croissance, et un véritable différenciateur sur le marché.