Output Management : définition, fonctionnement et cas d'usage pour les DSI

Le terme est anglophone, le sujet ne l’est pas. En France, l’output management s’inscrit historiquement dans le domaine de l’éditique, qui couvre l’ensemble de la chaîne de production, de traitement et de diffusion des documents issus du système d’information.

L’output management intervient plus précisément au niveau de leur orchestration. Une facture générée par SAP, un relevé produit par un cœur bancaire, un courrier issu d’une application métier ou un flux d’impression provenant d’un environnement IBM i (AS/400, iSeries) doit être pris en charge, priorisé, routé puis suivi jusqu’à sa destination : imprimante, email, portail, GED ou système d’archivage.

Ce n’est donc pas un synonyme de GED. Une GED sert principalement à classer, indexer, conserver, rechercher et consulter des documents déjà produits. L’output management gère leur mise en circulation : il détermine quand et dans quel ordre les flux doivent être traités, vers quel périphérique ou quel canal les acheminer, puis supervise leur exécution afin de détecter un blocage, reprendre un job en erreur ou assurer la traçabilité de sa distribution.

Quatre briques fonctionnelles se combinent pour prendre en charge, orchestrer et distribuer les flux documentaires vers leurs destinations, quel que soit leur système d’origine ou leur canal de sortie.

Ordonnancement des flux d'impression

L’ordonnancement pilote quand et dans quel ordre chaque job d’impression ou de diffusion s’exécute, en fonction de règles métier : horaires de fermeture d’agence, priorité réglementaire, dépendance entre documents, contraintes postales. C’est le niveau qui manque le plus souvent aux outils qui raisonnent d’abord au niveau du poste de travail ou d’un seul ERP : un ordonnancement pertinent se pilote au niveau du processus métier, pas de l’imprimante.

Distribution multicanale et routage

Une même donnée peut être émise vers trois destinations différentes : un exemplaire imprimé pour l'archive papier réglementaire, une version PDF envoyée par email, un dépôt dans le portail client ou un routage vers un coffre-fort électronique. Le routage dynamique choisit la bonne destination sans intervention manuelle, y compris quand un périphérique est indisponible.

Spooling et gestion des files d'attente

Le spouleur reçoit les jobs, les place en file d’attente puis les transmet vers le bon périphérique au moment prévu. Sur un réseau de plusieurs dizaines ou centaines de sites, l’enjeu n’est plus seulement de savoir si l’impression fonctionne, mais de pouvoir identifier rapidement un blocage, reprendre un job en erreur et maintenir la continuité des traitements.

Supervision et reporting

Un DSI qui découvre une panne d'impression parce qu'une agence l'appelle a déjà perdu la partie. La supervision expose en temps réel l'état des files d'attente, des périphériques et des jobs en erreur, avec les indicateurs nécessaires pour l'intégrer à des outils comme Nagios, Zabbix ou Grafana via une API REST plutôt que par un tableau de bord isolé de plus. Le module de workflow relie ces quatre briques entre elles..

Trois familles d'outils se recoupent souvent dans les appels d'offres, à tort :

• Une GED classe, indexe, conserve et permet de retrouver des documents déjà produits.
• Un pilote d’impression classique transmet un fichier vers une imprimante, sans assurer à lui seul l’ordonnancement métier, la supervision centralisée ou la reprise sur incident.
• Un système d’output management prend en charge, oriente et supervise les flux documentaires au moment de leur distribution : mise en file d’attente, ordonnancement, routage, gestion des périphériques et suivi de leur traitement.

Confondre les trois conduit souvent à choisir le mauvais outil pour le mauvais problème : une GED généraliste ne répond pas, par exemple, à un besoin de spooling, d’ordonnancement ou de continuité des flux d’impression.

Trois situations reviennent, sous une forme ou une autre, dans la plupart des problématiques rencontrées par les DSI et responsables éditiques :

À ces situations opérationnelles s’ajoutent deux enjeux : l’accessibilité des interfaces et des contenus et la souveraineté des données lorsqu’une brique du dispositif documentaire dépend d’un hébergement ou d’un service cloud externe.

Les mêmes briques fonctionnelles répondent à des priorités différentes selon le secteur :

• Banque et assurance : traitement sécurisé des contrats, relevés et documents réglementaires, avec traçabilité de leur prise en charge et de leur distribution.
• Mutuelle : volumes importants de décomptes et de relevés à distribuer dans des délais contraints.
• Industrie et logistique : production de documents liés aux opérations, bons de livraison, étiquettes, ordres de fabrication ou documents d’expédition, avec distribution vers les bons sites, ateliers ou équipements d’impression et supervision centralisée des flux.
• Administration publique : exigences renforcées de traçabilité, de continuité de service et de maîtrise des données.
• Centre éditique : volumes industriels et flux d’impression issus de multiples systèmes, notamment des environnements IBM i (AS/400, iSeries) ou mainframe, avec prise en charge de flux AFP/AFPDS ou IPDS selon les architectures.

Le détail par secteur est développé sur la page cas d'usage output management.

La continuité des flux documentaires repose sur plusieurs mécanismes, qu’il vaut mieux distinguer au moment de comparer les solutions :

• La reprise à la page, qui permet à l’opérateur de reprendre un travail interrompu à partir d’un point déterminé, selon les capacités du flux et du périphérique.
• Le failover de groupe d’imprimantes, où un job peut être redirigé vers un périphérique disponible appartenant au même groupe.
• Le failover d’instance en cluster, qui assure la continuité du service d’output management lui-même en cas d’indisponibilité d’une instance.

Le premier niveau concerne la reprise d’un travail après incident. Les deux suivants répondent à des problématiques de disponibilité des périphériques et de la plateforme elle-même. Le détail de ces mécanismes est développé dans notre article sur le failover.

MPI Tech est un éditeur logiciel français indépendant. Dans un marché où plusieurs acteurs longtemps présentés comme européens ou indépendants sont récemment passés sous capital nord-américain, cette continuité pèse concrètement pour les secteurs régulés : administration, banque, assurance.

ScopIOM peut fonctionner en 100 % on-premise, sans dépendance à une brique cloud pour opérer. La plateforme expose une API REST documentée pour la création et le suivi des jobs et des périphériques, l'intégration dans des outils de supervision tiers, et l'exposition d'indicateurs opérationnels. Le détail technique de la version actuelle est disponible sur la page ScopIOM v6, et une vue d'ensemble de la plateforme sur la page solution output management.

Quelle différence entre output management et éditique ?

L’éditique désigne historiquement en France l’ensemble de la chaîne de production, de traitement et de diffusion des documents issus du système d’information. L’output management en couvre plus spécifiquement l’orchestration et la distribution : prise en charge des flux, spooling, ordonnancement, routage vers les différents périphériques ou canaux, supervision et traçabilité. Dans l’usage, les deux termes sont parfois employés de manière interchangeable, mais leurs périmètres ne sont pas strictement identiques.

Un système d'output management remplace-t-il mon ERP ?

Non. Il s’interface avec les systèmes d’émission, comme SAP, Oracle, Sage ou les applications métiers, afin de prendre en charge et d’orchestrer les flux qu’ils génèrent, sans s’y substituer.

L'output management fonctionne-t-il avec mon IBM iSeries (AS/400) ?

Oui. IBM i, historiquement AS/400 puis iSeries, dispose de son propre environnement de spooling et de files de sortie. Un système d’output management peut prendre en charge ces flux afin de les centraliser avec ceux provenant d’autres systèmes d’information, puis appliquer les mêmes règles d’ordonnancement, de routage, de supervision et de traçabilité. Selon l’architecture en place, cette intégration peut notamment concerner des environnements utilisant LPD/LPR et des flux AFP/AFPDS ou IPDS.

IBM i constitue ici un environnement d’émission distinct d’un ERP comme SAP, Oracle ou Sage.

L'output management est-il compatible RGAA ?

L’accessibilité de l’interface d’un système d’output management et celle des documents numériques qu’il distribue sont deux sujets distincts. Le RGAA peut s’appliquer aux interfaces et aux contenus numériques selon leur contexte de mise à disposition. Pour une organisation concernée par ces obligations, ces différents périmètres doivent donc être évalués séparément.

Un système d’output management ne se choisit pas sur un mot dans une plaquette commerciale. Il se choisit sur des situations opérationnelles concrètes : que devient un job lorsqu’une imprimante tombe, comment retrouver la trace de son traitement, comment maintenir les flux en cas d’incident et jusqu’à quel point la plateforme dépend de composants externes au système d’information.