Glossaire
Glossaire de l'éditique
et de l'Output Management
Output management, spooling, ordonnancement, failover, LPD, AFP, accounting documentaire : les termes techniques de l'éditique et de la gestion des flux documentaires définis clairement, dans le langage des équipes SI. 30 définitions rédigées par des praticiens, avec les usages réels en contexte grands comptes.
L'éditique et ses fondamentaux
L'éditique est l'ensemble des processus informatiques permettant la production, l'ordonnancement et la distribution en masse de documents personnalisés (courriers, relevés, contrats, bulletins) à partir de données structurées issues d'un système d'information. Elle couvre la composition documentaire, le traitement des flux, l'impression industrielle et la dématérialisation.
Le terme "éditique" est un néologisme français né dans les années 1980, contraction d'édition et d'informatique. Il désigne une discipline sans équivalent direct en anglais : on parle plutôt de document output management, production printing ou transactional document processing.
Dans un grand compte, l'éditique couvre une chaîne complète : composition documentaire (CCM), ordonnancement des flux, impression industrielle haute cadence, dématérialisation et archivage. Un responsable éditique DSI pilote cette chaîne de bout en bout, en garantissant les SLA de production et la traçabilité des envois réglementaires.
« Le relevé de compte du client Dupont a-t-il bien été produit et envoyé ce matin ? Avec quelle imprimante ? Sur quel site ? » La réponse à cette question est le quotidien d'un responsable éditique.
Une chaîne éditique bancaire produit typiquement plusieurs millions de documents par mois : relevés, avis d'opérations, courriers réglementaires. L'Output Management en est le chef d'orchestre, de la réception du fichier de données jusqu'à la preuve de distribution.
Un logiciel d'Output Management (OMS) se positionne entre les applications productrices de données (ERP, applicatifs métier, chaîne éditique) et les canaux de sortie (imprimantes réseau, SMTP, GED, coffre-fort électronique). Il assure la réception des fichiers entrants, leur qualification, leur ordonnancement et leur routage vers les bons destinataires selon des règles configurables sans développement spécifique.
Dans un environnement grand compte, un OMS traite des milliers de jobs quotidiens provenant de sources hétérogènes. Sans cette couche de supervision, les DSI subissent des goulots d'étranglement, des pertes de documents et une absence totale de traçabilité. L'Output Management apporte la visibilité en temps réel et la reprise sur erreur automatisée.
« Nous n'avons aucune visibilité sur les flux sortants. Si un job part sans destination précise, on le sait deux heures après, quand le client appelle. »
Dans ScopIOM, la réception d'un flux est appelée Input Management. Un job peut arriver par différents canaux : protocole LPD (qui attribue à ScopIOM le rôle d'une imprimante réseau), outil de soumission NJ (pour les automatisations de ligne éditique), files de type INPUT (surveillance d'un répertoire), interface manuelle ou soumission par email.
À la réception, ScopIOM qualifie automatiquement le flux — type MIME, extension, magic number — pour déterminer le traitement à appliquer. Cette qualification conditionne l'ensemble des règles d'ordonnancement en aval.
Une application SAP envoie ses flux de facturation par protocole LPD vers ScopIOM, exactement comme elle enverrait vers une imprimante réseau. ScopIOM intercepte, qualifie et orchestre la suite sans aucune modification de l'application source.
Le flux documentaire est la matière première de l'éditique. Dans ScopIOM, chaque fichier attaché à un job constitue un flux. Ce fichier peut être de n'importe quelle nature (données PCL, AFP, PDF, script de transformation) et transite par les files de traitement selon un ordonnancement paramétré.
La gestion des flux documentaires en entreprise dépasse l'impression : elle englobe les règles de distribution multicanale (qui reçoit quoi, par quel canal, à quelle heure), la gestion des priorités et la preuve de remise. Dans les secteurs réglementés (banque, assurance, administration publique), cette traçabilité constitue une obligation légale et un prérequis d'audit.
Un centre éditique interne gère le parc d'imprimantes haute cadence, les files d'ordonnancement et la logistique documentaire (mise sous pli, affranchissement). Un centre éditique externalisé confie tout ou partie de cette production à un prestataire spécialisé, tout en maintenant la supervision des flux depuis le SI client.
Les logiciels d'Output Management comme ScopIOM constituent le socle technique d'un centre éditique performant : ordonnancement des milliers de jobs quotidiens, prioritisation par type de document, contrôle de la production jusqu'à la preuve de remise.
Un centre éditique bancaire produit des millions de pages par mois. Sans ordonnancement automatisé, les risques sont réels : retard sur les relevés réglementaires, mélange de lots de clients différents, impossibilité d'audit en cas de litige.
La confusion entre Print Management et Output Management est fréquente dans les appels d'offres DSI. Les deux disciplines ont des périmètres distincts : le Print Management (PaperCut, Pharos, Canon Uniflow) administre le parc d'imprimantes — authentification, quotas, coût à la page, sécurité des impressions confidentielles. L'Output Management pilote les flux applicatifs : ordonnancement des jobs, routage métier, supervision, reprise sur erreur.
Dans une architecture SI complète, les deux coexistent et se complètent. L'Output Management orchestre les flux éditiques haute cadence tandis que le Print Management supervise les impressions bureautiques. ScopIOM peut s'interfacer avec des solutions de Print Management pour les environnements mixtes.
Le CCM et l'Output Management sont complémentaires dans une chaîne éditique. Les plateformes CCM (Quadient Inspire, OpenText Exstream, Smart Communications) composent et personnalisent les documents : templates, logique conditionnelle, branding. L'Output Management prend le relais pour l'ordonnancement, la supervision et la distribution multicanale.
ScopIOM s'intègre en aval des plateformes CCM : il reçoit les flux composés et prend en charge leur ordonnancement, leur routage vers les bons canaux de sortie et la traçabilité des envois. Cette architecture ERP-agnostic permet d'associer n'importe quelle solution CCM à ScopIOM sans contrainte d'éditeur.
Ordonnancement et traitement des flux
Dans ScopIOM, les files de traitement sont les entités responsables de l'exécution des demandes de jobs. Chaque file est liée à un processus spécifique (impression, conversion, routage, archivage) et contrôle l'exécution de tous les traitements qui lui sont soumis, avec reprise automatique en cas d'erreur.
Un traitement dans une file possède un nombre illimité d'attributs : nom, propriétaire, date d'entrée, statut, priorité. L'exécution peut être locale ou distante via un agent déporté sur un serveur séparé. Chaque file gère sa propre politique de rétention des données, différenciée selon que le traitement s'est terminé en succès ou en erreur.
Passer une file en statut HOLD pendant une intervention sur une imprimante permet d'accepter tous les nouveaux jobs sans les lancer, puis de reprendre la production en une seule action dès que le périphérique est de nouveau disponible.
Dans ScopIOM, l'ordonnancement commence dès la réception du flux. Le Scheduler évalue en permanence les files de traitement actives et déclenche les jobs selon les règles définies : priorité, disponibilité des agents, fenêtres calendaires, dépendances entre jobs.
Un ordonnancement efficace est critique pour les centres éditiques à fort volume. Les jobs de facturation réglementaire doivent partir avant minuit, les relevés bancaires avant l'ouverture des agences, les documents urgents doivent prendre le pas sur les lots standards. ScopIOM permet de définir ces règles directement depuis l'interface, sans développement spécifique.
« Les relevés doivent être disponibles en agence à 8h. Si l'ordonnanceur ne priorise pas ce lot, on se retrouve avec des clients qui appellent parce que leur relevé n'est pas là. » - Responsable éditique, groupe bancaire.
Dans ScopIOM, un job est une entité qui représente la demande d'exécution d'un traitement. Il fournit les informations relatives à cette demande et peut avoir un flux de données attaché pour effectuer des transformations sur le document (conversion, impression, routage, archivage).
Les jobs peuvent être liés entre eux par des relations de dépendance : un job fils ne peut s'exécuter que lorsque son père s'est correctement terminé. Cette logique de dépendances est fondamentale pour les chaînes éditiques complexes : la conversion d'un fichier AFP doit précéder son impression, l'archivage doit suivre la distribution réussie.
Le module Workflow de ScopIOM permet de construire des chaînes de traitement complexes sans développement : réception d'un flux AFP, conversion en PDF, archivage dans la GED, impression sur l'imprimante du bon site, notification par email en cas d'erreur. Chaque étape est liée à une file de traitement ; les conditions définissent les branchements logiques.
Une condition dans ScopIOM est un test exprimé dans un mini-langage dédié : "si le volume dépasse 1 000 pages ET l'heure est entre 8h et 20h, alors exécuter l'étape impression haute cadence". Cette logique conditionnelle différencie un logiciel d'Output Management mature d'un simple spouleur.
La Table d'exploitation permet à un responsable éditique de définir, depuis l'interface ScopIOM, des règles de traitement conditionnelles à granularité fine : source du flux, type de document, volume de pages, heure d'arrivée, propriétaire du job. Ces règles s'appliquent automatiquement à chaque job entrant qui correspond aux critères.
Exemple : "SI le flux provient de l'application paie ET que le volume dépasse 500 pages ET que l'heure est inférieure à 20h, ALORS router vers l'imprimante haute cadence du site de Paris ET archiver dans la GED centrale." Sans Table d'exploitation, cette règle exige un développement spécifique côté applicatif ou ERP.
« On avait des règles de routage codées dans l'ERP. Chaque modification prenait une semaine de développement et un passage en recette. Avec la Table d'exploitation, l'opérateur change la règle en cinq minutes. » - DSI, groupe industriel multisite.
SPOOL est l'acronyme de Simultaneous Peripheral Operations On-Line. Le concept résout un problème fondamental : une application ne peut pas rester bloquée à attendre qu'une imprimante ait terminé son travail. Le spouleur prend en charge le document, libère l'application source et gère lui-même l'envoi vers le périphérique.
Dans les environnements de production éditique, le spouleur est la première ligne de contrôle des flux. Sans lui, les jobs partent directement vers l'imprimante sans possibilité de reprise ni de supervision. Dans ScopIOM, le spouleur intègre les règles d'ordonnancement : un job urgent peut passer devant des centaines d'autres en attente, sans intervention manuelle.
"Spouler les documents" signifie les placer dans la file de traitement ScopIOM. Un opérateur peut alors visualiser tous les documents en attente, modifier les priorités, suspendre un lot ou relancer un job en erreur depuis l'interface ScopSpooler.
Le Scheduler est le composant critique de ScopIOM : c'est lui qui pilote l'exécution effective de toutes les files de traitement. Il est à distinguer de la notion d'ordonnancement au sens large — la logique de planification — dont il est l'implémentation technique en temps réel.
La disponibilité du Scheduler est un indicateur de santé critique en production éditique. La supervision ScopIOM surveille son état en permanence, émet des alertes en cas d'arrêt imprévu et permet de configurer un redémarrage automatique dans un environnement haute disponibilité.
L'architecture ScopIOM dissocie le serveur central (configuration, ordonnancement, interface) des agents (exécution des traitements). Un agent local est installé sur la même machine que le serveur. Un agent distant est déployé sur un serveur séparé, y compris sous un OS différent.
Cette architecture distribuée est particulièrement adaptée aux organisations multisites : un agent peut être déployé sur le site de Lyon pour exécuter les traitements locaux, tandis que l'ordonnancement reste centralisé sur le serveur ScopIOM du datacenter central. L'administrateur visualise l'état de tous les agents en temps réel depuis l'interface.
Les calendriers sont un composant d'ordonnancement temporel dans ScopIOM. Ils s'appliquent au niveau du job pour définir des fenêtres d'exécution précises : un job de production de relevés mensuel peut être configuré pour devenir éligible le premier jour ouvré de chaque mois à 2h du matin, indépendamment de l'heure à laquelle il a été soumis.
Les expressions de dates supportées vont de la date fixe simple au schéma complexe : "n'importe quel lundi à midi", "le dernier jour ouvré du mois", "tous les jours sauf samedi et dimanche". Cette flexibilité élimine les scripts cron personnalisés, difficiles à maintenir et non visibles depuis l'interface de supervision.
Impression et périphériques
La notion de périphérique dans ScopIOM découple les traitements des équipements physiques. Un périphérique logique peut pointer vers plusieurs imprimantes physiques pour la haute disponibilité ou l'équilibrage de charge. Cette abstraction permet de modifier la destination physique d'un flux sans toucher aux règles d'ordonnancement ni aux applications sources.
Les médias (types de papier) peuvent être associés à un périphérique pour garantir que les documents imprimés utilisent le bon support (papier préimprimé, papier couleur, enveloppes). ScopIOM vérifie la disponibilité du média avant l'envoi et peut mettre le job en attente si le support requis n'est pas chargé.
Dans ScopIOM, le routage dynamique repose sur le système d'Agences : chaque agence regroupe des utilisateurs et définit des règles de routage qui leur sont appliquées. Un job soumis par un utilisateur de l'agence "Paris Nord" est automatiquement dirigé vers les imprimantes du site correspondant, sans configuration manuelle job par job.
Le routage peut prendre en compte de nombreux critères : l'identifiant de l'expéditeur, le type de document (AFP, PDF, PCL), le volume de pages, l'heure d'arrivée, la priorité du job. En cas d'indisponibilité du périphérique cible, le routage bascule automatiquement vers un périphérique de secours.
Dans un groupe industriel avec 12 sites, les factures clients sont automatiquement dirigées vers l'imprimante du site géographiquement proche du destinataire, sans intervention de l'opérateur et sans modification de l'ERP source.
ScopIOM intègre un module de supervision qui surveille en permanence l'état des files de traitement, des agents et des périphériques. Les alertes sont configurables par seuil (file en erreur, périphérique hors ligne, volume anormal) et peuvent être notifiées par email ou via le protocole SNMP vers les outils de supervision réseau existants (Nagios, Zabbix, PRTG).
L'accounting d'exécution conserve l'historique complet de tous les traitements, même après purge des jobs. Cette traçabilité est exploitable pour le reporting (nombre de pages imprimées par site, par utilisateur, par période) et pour les audits de conformité.
« L'auditeur veut la preuve que ce contrat a bien été imprimé le 14 mars à 14h22 sur l'imprimante du site de Bordeaux. Sans supervision et accounting, c'est impossible à produire. » - RSSI, groupe assurance.
À distinguer du failover applicatif (voir Haute disponibilité) : le failover imprimante opère au niveau des périphériques de sortie. Lorsque ScopIOM détecte qu'une imprimante est hors ligne (via SNMP ou timeout), il redirige automatiquement les jobs en attente vers un périphérique de secours configuré, selon les règles de routage définies.
La reprise à la page complète ce mécanisme : si une imprimante tombe en cours d'impression d'un document de 800 pages à la page 320, ScopIOM peut reprendre l'impression à la page 321 sur le périphérique de secours, sans réimprimer les 320 premières pages.
« L'imprimante du site de Lyon s'est arrêtée. Nous avions perdu 200 pages. Maintenant, avec ScopIOM, le basculement est automatique et la reprise à la page évite de tout réimprimer. »
La reprise à la page est une fonctionnalité critique pour les environnements haute cadence traitant des documents volumineux. Un lot de relevés peut représenter plusieurs centaines de pages : sans reprise à la page, un incident à la page 847 sur 1 000 implique de réimprimer les 846 premières pages, avec la perte de temps, de papier et de coût que cela représente.
ScopIOM maintient un pointeur de position d'impression pour chaque job en cours. En cas d'incident, l'opérateur peut reprendre exactement à la page interrompue, sur le même périphérique ou sur un périphérique de substitution.
Le protocole LPD est l'un des modes d'alimentation les plus répandus dans les environnements éditiques. Il permet à n'importe quelle application (ERP SAP, Oracle, application métier sous UNIX/Linux) d'envoyer ses flux vers ScopIOM comme si c'était une imprimante réseau standard, sans modification du code applicatif.
La commande LPR de ScopIOM étend le protocole standard avec des attributs additionnels permettant de transmettre des métadonnées au moment de la soumission : priorité, propriétaire, type de document, instructions de traitement. Ces attributs alimentent directement les règles de la Table d'exploitation.
L'AFP est le format natif des environnements IBM iSeries (AS/400) et z/OS (mainframe). Il encode le document avec une précision absolue : polices de caractères, positionnement au dixième de millimètre, overlays graphiques, données variables. Les chaînes éditiques bancaires et d'assurance l'utilisent massivement pour leur fiabilité et leurs performances en très hauts volumes.
MPI Tech dispose d'une expertise reconnue sur les flux AFP/IPDS. ScopIOM gère nativement les flux AFP en entrée et en sortie, y compris les ressources AFP associées (polices, overlays, segments de page) nécessaires à l'impression correcte sur les imprimantes compatibles IBM.
Un groupe bancaire avec un mainframe IBM z/OS qui génère ses relevés en AFP peut envoyer directement ses flux dans ScopIOM pour ordonnancement, supervision et distribution multicanale, sans conversion intermédiaire ni perte de fidélité documentaire.
L'intégration SNMP dans ScopIOM opère dans les deux sens. ScopIOM interroge les imprimantes via SNMP pour connaître leur état en temps réel : en ligne, hors ligne, bourrage papier, niveau de toner bas. Cette remontée d'état déclenche les mécanismes de failover automatique avant même qu'un opérateur soit alerté.
ScopIOM peut également émettre des traps SNMP vers les outils de supervision de l'organisation (Nagios, PRTG, Zabbix) pour intégrer les alertes éditiques dans le monitoring global du SI. La production documentaire devient ainsi un composant supervisé au même titre que les serveurs et les équipements réseau.
Gouvernance, sécurité et intégration SI
Dans ScopIOM, la haute disponibilité repose sur un mode cluster : plusieurs instances ScopIOM sont déployées, dont une active et une ou plusieurs en attente (passif). En cas de défaillance de l'instance active, le basculement vers l'instance passive est automatique, sans perte des jobs en cours ni des jobs en attente.
Ce niveau de HA opère au niveau applicatif, entre nœuds du cluster ScopIOM. Il ne doit pas être confondu avec le failover imprimante, qui opère au niveau des périphériques de sortie. Pour les DSI des secteurs banque, assurance et administration, l'objectif est un RTO (Recovery Time Objective) inférieur à 5 minutes et un RPO (Recovery Point Objective) nul : aucune perte de job.
« Si le serveur d'output tombe un lundi matin pendant l'envoi des relevés mensuels, on ne peut pas se permettre de perdre deux heures à redémarrer manuellement et tout reprendre à zéro. » - DSI, groupe assurance mutualiste.
L'accounting dans ScopIOM est distinct du journal des jobs actifs : il persiste en base de données après que les jobs ont été purgés. Ce mécanisme permet de reconstituer l'historique complet de la production documentaire sur des périodes longues, indispensable pour les audits réglementaires et les litiges clients.
Sur la base de l'accounting, ScopIOM génère des rapports PDF paramétrables : nombre de pages imprimées par imprimante, par utilisateur, par période, taux d'erreur, temps de traitement moyen. Ces données alimentent le reporting DSI et la facturation interne dans les organisations qui facturent leurs services d'impression aux directions métier.
Un DSI peut répondre en quelques secondes à la question : "Le courrier X a-t-il été imprimé, sur quelle imprimante, à quelle heure, par quel utilisateur ?", sans fouiller des fichiers de logs épars.
Dans ScopIOM, la gestion des droits s'articule autour de groupes et de profils. Les groupes regroupent des utilisateurs et définissent leurs droits d'accès aux ressources (files de traitement, périphériques, workflows). Les agences organisent les utilisateurs selon leur appartenance géographique ou organisationnelle pour le routage et la supervision.
La granularité des droits permet des configurations précises : un opérateur peut surveiller les files de traitement et relancer des jobs en erreur, sans pouvoir modifier la configuration des périphériques ni accéder aux paramètres système. Cette séparation des responsabilités est un prérequis dans les environnements soumis à des audits de sécurité.
ScopIOM supporte l'authentification fédérée via Keycloak, le serveur d'identité open source. Cette intégration permet de centraliser l'authentification des utilisateurs ScopIOM dans l'annuaire de l'entreprise (Active Directory, LDAP), d'appliquer les politiques de mot de passe corporate et de couper automatiquement l'accès lors du départ d'un collaborateur.
Pour les DSI soumis à des exigences de conformité (ANSSI, NIS2, audits internes), la traçabilité des authentifications et l'intégration IAM sont des prérequis non négociables. ScopIOM répond à ces exigences tout en supportant les standards d'accessibilité WCAG 2.1 / RGAA 4 pour les organisations publiques françaises.
L'API REST est le fondement de l'architecture ERP-agnostic de ScopIOM. Un ERP SAP envoie ses flux par protocole LPD, un applicatif Java les soumet par API REST, un script dépose les fichiers par FTP : ScopIOM les orchestre de façon homogène, quelle que soit la source. Cette indépendance vis-à-vis de l'ERP source est un différenciateur majeur face aux solutions architecturalement liées à un seul éditeur.
L'API REST de ScopIOM couvre les opérations principales : soumission de jobs, consultation du statut et de l'historique, gestion des files de traitement, accès aux données d'accounting. Elle est documentée et accessible depuis le portail de documentation intégré à ScopIOM.
Dans les organisations multisites, la consolidation documentaire répond à une problématique concrète : chaque site ou applicatif génère ses propres flux, ses propres formats, ses propres règles d'impression. Sans consolidation, la DSI gère une multitude de points de production indépendants, impossibles à superviser globalement.
ScopIOM agit comme logiciel de consolidation documentaire en centralisant tous les flux entrants (SAP, Oracle, applications métier, fichiers déposés par FTP) dans une file unique d'ordonnancement. La visibilité devient globale, les règles sont centralisées, la production est supervisée depuis un seul tableau de bord.
Avant consolidation : 8 imprimantes sur 4 sites, 5 applications sources, aucune visibilité globale, un incident non détecté pendant 3 heures. Après consolidation via ScopIOM : tableau de bord unique, alertes en temps réel, toute la production sous contrôle.
Les groupes de ressources répondent à un besoin d'organisation dans les environnements ScopIOM complexes où coexistent de nombreuses files, périphériques et workflows. Ils permettent de créer des vues métier : le groupe "Production paie" contient les files, imprimantes et workflows dédiés au traitement des bulletins de salaire.
Cette organisation facilite la supervision opérationnelle : un opérateur peut surveiller l'ensemble des ressources liées à sa mission depuis un groupe dédié, sans être exposé aux ressources des autres métiers. L'interface ScopSpooler utilise les groupes de ressources pour personnaliser les tableaux de bord par profil.