Brevet FR3106227A1 — publié le 20210716

L’invention propose un procédé de traitement de données pour la réalisation d’un travail d’impression, le procédé étant mis en œuvre par un calculateur et comprenant la mise en œuvre d’au moins une tâche de contrôle ou de validation d’un fichier d’épreuve du travail d’impression, comportant : - l’émission d’une requête de contrôle ou de validation comprenant le fichier d’épreuve, - la génération, d’un délai de surveillance de la réception d’une réponse à la requête émise, - si aucune réponse n’est reçue à l’expiration du délai de surveillance, l’émission d’un message de rappel, le procédé comprenant en outre la réception d’une réponse à la requête émise, ou à défaut, la génération d’une tâche de relance affectée à un opérateur. Procédé et système de traitement de données pour la réalisation d’un travail d’impression La présente demande concerne un procédé et un système de traitement de données pour la réalisation d’un travail d’impression, comprenant notamment une tâche de contrôle d’un fichier d’épreuve, également appelé Bon à Tirer, du travail d’impression. Le domaine de l’impression est un domaine soumis à de fortes contraintes d’organisation. En effet, un travail d’impression implique le plus souvent un grand nombre de tâches mises en œuvre par des ressources, humaines ou matérielles, différentes. Les travaux d’impression doivent être exécutés selon un planning précis et souvent très contraint dans le temps, ce qui implique d’avoir à la fois une bonne connaissance de l’état d’exécution des travaux d’impression, et une bonne gestion des plannings des différentes ressources impliquées. En particulier, les machines de production dans le domaine de l’imprimerie sont reconfigurées à chaque changement de support d’impression (papier, bâche, adhésif, etc.), ce qui implique, pour limiter les temps de changement, d’organiser le cycle de production pour que tous les travaux liés à un même support soient regroupés. Les travaux d’impression sont également soumis à des aléas de calendrier qui imposent d’être très réactif sur la réorganisation des projets. Dans ce contexte, la validation des fichiers d’épreuve, également appelés BAT ou bons à tirer, peuvent parfois être critiques. En effet, il est nécessaire de faire contrôler le fichier d’épreuve par l’imprimeur pour vérifier qu’il satisfait à des critères techniques de production, et d’autre part par le client, pour vérifier qu’il satisfait au cahier des charges fourni par celui-ci. La validation fournie par le client permet de lancer la production du travail d’impression, il faut donc être réactif à la réception de cette validation pour que le travail puisse être terminé rapidement. En revanche, un défaut de réponse du client peut mettre le projet en retard et avoir des implications sur d’autres projets nécessitant les mêmes ressources, il faut donc pouvoir surveiller simultanément l’état de validation de bons à tirer par tous les clients pour gérer son planning de production au mieux. Le contrôle par l’imprimeur ou le professionnel des arts graphiques a également un impact puisqu’il est un prérequis à l’envoi du fichier d’épreuve au client. De même, ce contrôle, s’il n’est pas réalisé à temps, compromet l’achèvement dans les délais du projet. Pour pallier ces inconvénients, il est prévu aujourd’hui qu’un opérateur envoie manuellement des relances, par exemple par téléphone ou par email, à un imprimeur ou à client pour qu’il aille contrôler un fichier d’épreuve en attente. Ceci induit une perte de temps importante et n’est pas pratique puisque le client ou l’imprimeur doit ensuite faire par lui-même la démarche d’accéder au fichier d’épreuve pour le contrôleur. Et malgré cela, il est toujours nécessaire de prévoir qu’une personne vérifie en permanence les plannings et les adapte en fonction des retards pris ou des changements de priorités pour certains travaux. Cette tâche est rendue encore plus complexe du fait qu’il n’est pas possible avec cette solution actuelle de connaître avec précision et en temps réel l’état d’avancement de chaque travail d’impression, et en particulier l’état de validation du bon à tirer. On connaît également du document FR3057091 un procédé de traitement d’informations dans lequel un serveur met en relation des graphistes et des clients, permettant à un graphiste de rendre accessible à un client, par le serveur, un projet que le client peut valider. A réception de la validation du client, le graphiste transmet un fichier au serveur dans un format requis par l’imprimerie, et le fichier est ensuite envoyé à une imprimerie pour impression. Ce document ne tient pas compte des contraintes techniques et organisationnelles du côté de l’imprimerie, et en particulier ne prévoir aucun contrôle technique du fichier d’épreuve par un imprimeur, ni aucune gestion des différents travaux d’impression du côté de l’imprimeur, en fonction des informations fournies par le client sur les bons à tirer. Résumé Compte-tenu de ce qui précède, l’invention a pour but de pallier au moins en partie les inconvénients de l’art antérieur décrit ci-avant. En particulier, un but de l’invention est de proposer un procédé de traitement de données pour la réalisation d’un travail d’impression, qui permette la gestion automatique du contrôle d’un fichier d’épreuve par un imprimeur ou un graphiste et par un client, et la prise en compte de cette étape de contrôle dans la gestion de l’organisation d’un site de production. A cet égard, l’invention propose un procédé de traitement de données pour la réalisation d’un travail d’impression, le procédé étant mis en œuvre par un calculateur et comprenant la mise en œuvre d’au moins une tâche de contrôle ou de validation d’un fichier d’épreuve du travail d’impression, comportant : - l’émission d’une requête de contrôle ou de validation comprenant le fichier d’épreuve, - la génération, d’un délai de surveillance de la réception d’une réponse à la requête émise, - si aucune réponse n’est reçue à l’expiration du délai de surveillance, l’émission d’un message de rappel, le procédé comprenant en outre la réception d’une réponse à la requête émise, ou à défaut, la génération d’une tâche de relance affectée à un opérateur. Dans des modes de réalisation, le procédé comprend en outre, à la réception d’une information d’une réponse négative à la requête émise, la mise en œuvre d’une tâche de modification du fichier d’épreuve, comprenant - l’émission d’une requête de remplacement du fichier d’épreuve, - la génération d’un deuxième délai de surveillance de la réception d’une réponse à la requête de remplacement, - si aucune réponse à la requête de remplacement n’est reçue à l’expiration du deuxième délai de surveillance, l’émission d’un message de rappel, le procédé comprenant en outre la réception d’un fichier d’épreuve de remplacement ou, à défaut, la génération d’une tâche de relance affectée à un opérateur. Le procédé de traitement peut être mis en œuvre par un serveur d’une architecture client-serveur, et la requête est alors envoyée à un client de l’architecture client-serveur. En variante, la requête peut être un email comprenant un lien vers une interface de validation permettant l’obtention, par le calculateur, d’une réponse. Optionnellement, l’émission de la requête de contrôle ou de validation est accompagnée simultanément de l’envoi d’un SMS au destinataire de la requête, informant ledit destinataire de l’émission de cette requête. Dans des modes de réalisation, le procédé comprend la mise en œuvre d’une tâche de contrôle et d’une tâche de validation, et la commande du démarrage d’une tâche de production à la réception d’une réponse favorable à une requête émise pour celle de la tâche de contrôle et de la tâche de validation mise en œuvre en dernier. La tâche de contrôle est avantageusement mise en œuvre pour l’obtention d’une information de conformité technique du fichier d’épreuve, et la tâche de validation est mise en œuvre pour l’obtention d’un accord d’un donneur d’ordre sur le fichier d’épreuve. Dans des modes de réalisation, le procédé comprend une étape préliminaire de génération d’un projet d’impression pour la réalisation du travail d’impression, le projet d’impression comprenant un ensemble de tâches, et le procédé comprend en outre l’association à chaque tâche d’un statut de réalisation de la tâche, et la mise à jour en temps réel du statut de réalisation de chaque tâche. L’étape de génération du projet d’impression peut comprendre en outre l’association à chaque tâche d’une durée prédéterminée d’exécution, et la génération, à partir des durées associées à chaque tâche, d’une date de fin de travail d’impression. L’étape de génération du projet d’impression peut également comprendre, pour au moins une tâche, l’association de la tâche à une ressource d’exécution, et le procédé comprend en outre une étape d’élaboration, pour au moins une ressource d’exécution de tâches, d’un calendrier d’exécution des tâches des projets d’impression. Le procédé peut alors comprendre le recalcul d’une date de fin de travail d’impression, en cas de durée effective d’une tâche supérieure à la durée allouée, la date recalculée étant déterminée à partir des durées des tâches restant à réaliser et des calendriers des ressources associées à ces tâches. La présente a également pour objet un produit programme d’ordinateur, comprenant des instructions de code pour la mise en œuvre du procédé la description qui précède, lorsqu’il est mis en œuvre par un calculateur. La présente a également pour objet un calculateur, caractérisé en ce qu’il est configuré pour la mise en œuvre du procédé selon la description qui précède. Selon un autre objet, la présente porte également sur un système de traitement de données pour la réalisation d’un travail d’impression, comprenant une architecture client-serveur comprenant un serveur configuré pour la mise en œuvre du procédé selon la description qui précède, et au moins un client configuré pour : - recevoir une requête de contrôle comprenant le fichier d’épreuve émise par le serveur, - afficher le fichier d’épreuve, et - envoyer au serveur une réponse à la requête de contrôle comprenant une information de conformité du fichier d’épreuve. L’invention proposée permet de gérer de manière automatique et informatique les étapes de contrôle d’un fichier d’épreuve par un imprimeur ou un graphiste et de validation d’un fichier d’épreuve par un client, la réalisation de ces étapes étant surveillée par la mise en place d’un délai d’envoi de relance, éventuellement automatiquement réitéré. Dans un mode de réalisation, le procédé est mis en œuvre dans une architecture client – serveur qui permet par exemple à un imprimeur d’accéder, sur un même espace client, à une requête de contrôle du fichier d’épreuve comprenant le fichier d’épreuve, et aux éventuelles relances. Dans des modes de réalisation, le procédé proposé permet également de tenir compte de la bonne réalisation de ces étapes de contrôle et de réalisation pour adapter l’organisation d’un site de production en adaptant les calendriers d’exécution des ressources et/ou en adaptant le délai de réalisation du travail d’impression. Il n’est donc pas nécessaire de prévoir qu’un opérateur soit dédié à la gestion de l’agenda de réalisation des travaux d’impressions. De plus, le procédé proposé permet de connaître l’état de réalisation de chaque travail d’impression en temps réel. D’autres caractéristiques, détails et avantages apparaîtront à la lecture de la description détaillée ci-après, et à l’analyse des dessins annexés, sur lesquels : Fig. 1 représente schématiquement un environnement dans lequel est mis en œuvre le procédé de traitement de données pour la réalisation d’un travail d’impression. Fig. 2 représente schématiquement un exemple d’un procédé de traitement de données pour la réalisation d’un travail d’impression. Fig. 3a représente schématiquement la mise en œuvre d’une tâche de contrôle d’un travail d’impression. Fig. 3b représente schématiquement la mise en œuvre d’une tâche ou de validation d’un fichier d’épreuve d’un travail d’impression. Fig. 4 représente schématiquement la mise en œuvre d’une tâche de modification d’un fichier d’épreuve. Fig. 5 représente un exemple d’affichage de l’état d’avancement d’un ensemble de projets d’impression. Fig. 6 représente un exemple d’affichage de l’état d’avancement d’un projet d’impression. On va maintenant décrire un procédé de traitement de données pour la réalisation d’un travail d’impression. Par « travail d’impression », on entend dans la suite l’impression physique d’une représentation graphique sur un support, le support pouvant être variable (papier, banderole, adhésif, etc.), en un nombre d’exemplaires déterminé. En référence à la figure 1, le procédé de traitement de données est mis en œuvre informatiquement par un calculateur 10, par exemple un processeur, exécutant des instructions de code stockées dans une mémoire 12. Le procédé de traitement de données est avantageusement mis en œuvre par une application logicielle exécutable par le calculateur, cette application pouvant être implémentée dans un serveur situé physiquement dans des locaux d’une entreprise d’impression, ou un serveur distant. Dans un mode de réalisation, le procédé de traitement de données est mis en œuvre par une application serveur 11 exécutée par le calculateur 10 d’une architecture client-serveur 1, dont un ou plusieurs logiciels clients 21 peuvent être exécutés sur des terminaux 20 (ordinateur, tablette, téléphone mobile) d’opérateurs d’une entreprise d’impression et, éventuellement, de donneurs d’ordre des travaux d’impression. Le procédé de traitement de données permet la réalisation et la gestion d’une pluralité de travaux d’impression. En référence à la figure 2, le procédé de traitement de données comprend, pour chaque travail d’impression, la génération 100 d’un projet d’impression pour la gestion et la réalisation du travail d’impression, le projet d’impression comprenant un ensemble de tâches nécessaires à la réalisation du travail d’impression, comprenant par exemple tout ou partie des tâches listées ci-dessous: - la réalisation d’un fichier d’épreuve du graphisme à imprimer, - le contrôle du fichier d’épreuve par un imprimeur, pour vérifier qu’il respecte des spécifications techniques (format, compatibilité, etc.) - la validation du fichier d’épreuve par le client, - l’impression du graphisme sur un support en un nombre déterminé d’exemplaire, - la lamination du support imprimé, - la découpe du support imprimé, - la pose du support imprimé, - l’expédition du travail imprimé, - la facturation du travail d’impression. De plus, chaque tâche peut être affectée à une ressource d’exécution déterminée, cette ressource d’exécution pouvant être humaine, par exemple un graphiste, un opérateur technique, un opérateur commercial, ou encore un client, ou matérielle, par exemple une machine d’impression, une machine de découpe, etc. Dans un mode de réalisation, chaque tâche est associée par défaut à une ressource d’exécution déterminée lors de la génération du projet d’impression. Chaque tâche peut également être associée à une durée d’exécution par défaut, qui correspond, si la tâche est associée à une ressource d’exécution, à un temps d’occupation de la ressource considérée. Avantageusement, mais facultativement, plusieurs types de projets d’impression sont prédéfinis en fonction de la nature du travail d’impression considéré, chaque type de projet étant associé à un ensemble de tâches convenant spécifiquement à la réalisation du type de projet. La durée d’exécution d’une tâche peut également dépendre du type du projet. Dans ce cas, la génération 100 du projet d’impression comprend la réception 110 d’un type de projet d’impression à générer parmi les types prédéfinis. Le type de projet peut par exemple être saisi, par un opérateur d’une entreprise d’impression à réception d’une commande d’un donneur d’ordre, sur une interface de communication avec le serveur, comme par exemple une interface graphique de l’application cliente mentionnée ci-avant. La génération 100 du projet d’impression comprend alors une création 120 du projet comprenant l’ensemble des tâches correspondant au type de projet, avec leurs durées d’exécution respectives. Optionnellement, la génération 100 du projet d’impression peut comprendre en outre une étape de réception 130 d’une modification de ressource ou de modification de durée d’au moins une tâche du projet, cette modification pouvant être demandée par un opérateur en fonction de la situation particulière du travail d’impression à réaliser ou de l’entreprise d’impression. La décomposition des projets d’impression en tâches affectées à des ressources et associées à des durées d’exécution déterminées peut permettre d’élaborer dans une étape 140, pour chaque ressource, un planning ou un calendrier d’exécution de l’ensemble des tâches qui lui sont associées. La génération du projet peut alors également comprendre une détermination 150 d’une date de fin de projet, à laquelle toutes les tâches ont été réalisées, cette date étant déterminée à partir de la durée des tâches, des ressources allouées, et des calendriers d’exécution des ressources. Optionnellement, la génération du projet d’impression peut comprendre une étape 160 de réception d’une date impérative de fin de projet, qui peut, le cas échéant, impliquer une modification du calendrier d’exécution des ressources pour déplacer la mise en œuvre de certaines tâches afin de respecter la date de fin de projet. Les étapes décrites ci-avant ne sont pas nécessairement mises en œuvre dans l’ordre indiqué, et par exemple un opérateur peut saisir simultanément un type de projet et une date de fin de projet, auquel cas les étapes de création de projet 120 et de détermination 150 d’une date de fin de projet sont simultanées. De plus, l’étape 140 d’élaboration d’un calendrier d’exécution peut être une tâche récurrente, qui est mise à jour à chaque fois qu’une tâche est réalisée ou qu’une modification est demandée. Avantageusement, chaque tâche est également associée à un statut d’exécution, permettant d’obtenir immédiatement des informations sur l’état d’avancement du projet. Par exemple, un statut d’exécution peut être « à faire », « en cours », « terminé », etc. Le statut de chaque tâche est avantageusement mis à jour en temps réel. Par exemple, lorsqu’une tâche est affectée à un opérateur, il peut indiquer par une interface dédiée qu’il a terminé la tâche, qui passe alors de l’état « en cours » à l’état « terminé ». La terminaison d’une tâche entraine immédiatement le démarrage de l’étape suivante, qui passe de « à faire » à « en cours ». Dans un mode de réalisation, une ressource matérielle peut également être interfacée avec le calculateur de manière à indiquer automatiquement le moment où la tâche est achevée. En variante, un opérateur peut contrôler la réalisation de la tâche et saisir manuellement que la tâche est terminée. De préférence, le calculateur est adapté pour générer une représentation graphique représentant tout ou partie des projets d’impression générés ou en cours d’exécution, éventuellement triables ou filtrables par ressource, par tâche, ou par date de début ou de fin du projet, et permettant de représenter la tâche en cours d’exécution ou la prochaine tâche à démarrer. Avantageusement, la représentation des projets d’impression permet de sélectionner un projet et d’accéder au détail du projet, permettant de visualiser l’ensemble des tâches du projet et le statut d’exécution de chaque tâche, ce qui permet de déterminer l’état d’avancement du projet. On a représenté en figure 5 un exemple de représentation d’un ensemble de projets, et en figure 6 un exemple de représentation de l’état d’avancement d’un projet. Sur l’exemple de la figure 5, les projets sont filtrés par catégorie de projets et au sein de chaque catégorie, par la tâche actuelle du projet, ce qui permet d’obtenir des informations sur la situation globale d’un atelier de production. Chaque projet d’impression comprend au moins une tâche 200 de contrôle d’un fichier d’épreuve ou bon à tirer du travail d’impression, représentée plus en détails sur la figure 3a, et une tâche de validation 400 du fichier d’épreuve, représentée plus en détails sur la figure 3b. La tâche de contrôle a pour but d’obtenir une confirmation de la conformité du fichier d’épreuve avec des spécifications techniques liées à des contraintes d’impression comme par exemple une compatibilité entre le format informatique du fichier d’épreuve et le format nécessaire pour l’impression, ou encore une compatibilité de dimensions, etc. La tâche de validation a quant à elle pour but d’obtenir une confirmation, de la part du donneur d’ordre du travail d’impression, que le fichier d’épreuve correspond à ses attentes. La validation 400 peut être mise en œuvre après la tâche de contrôle 200, comme représenté dans l’exemple de la figure 2, mais peut également être mise en œuvre avant cette dernière. Dans les deux cas, si le fichier d’épreuve est satisfaisant, la tâche suivante est automatiquement engagée, tandis que s’il n’est pas satisfaisant, la tâche de contrôle 200 ou de validation est suivie d’une tâche de modification du fichier d’épreuve 300, représentée en figure 4. De retour à la figure 3a, la mise en œuvre de la tâche de contrôle 200 comprend l’émission 210 d’une requête de contrôle, comprenant le fichier d’épreuve. Avantageusement, cette requête de contrôle est envoyée à un logiciel client de l’architecture client-serveur évoquée ci-avant, permettant par exemple à un opérateur, par exemple un imprimeur ou un graphiste, de recevoir, par une interface du logiciel client, la requête et le fichier d’épreuve à contrôler. Optionnellement, l’émission 210 de la requête de contrôle peut s’accompagner simultanément d’un envoi de SMS pour avertir le destinataire de la requête, par exemple graphiste, opérateur ou imprimeur, qu’il a reçu cette requête. Dans un mode de réalisation, le logiciel client présente une interface permettant la visualisation du fichier d’épreuve et l’envoi, au serveur, d’une indication de conformité en réponse à la requête de contrôle, cette information pouvant être une acceptation si le fichier d’épreuve est conforme aux spécifications, ou un refus dans le cas contraire. En variante, la requête de contrôle peut également être envoyée par email, et comprendre une ou plusieurs pièce-jointe comprenant un fichier d’épreuve ou différentes versions de fichier d’épreuve, ou comprendre un lien vers une page web de visualisation du fichier d’épreuve et/ou d’envoi d’une réponse. A partir de l’émission de la requête de contrôle, le statut de la tâche peut passer à un statut « en cours », ou à un statut spécifique comme « requête de contrôle envoyée ». Simultanément à l’émission de la requête de contrôle, un premier délai 220 est généré, pour surveiller la réception d’une réponse à la requête de contrôle. Si aucune réponse à la requête de contrôle n’est reçue à l’expiration du premier délai de surveillance, la tâche comprend l’émission 230 d’au moins un message de rappel, soit par email, soit via le logiciel client. En variante, la tâche peut comprendre la réception 240 d’une information de conformité en réponse à la requête de contrôle. Dans le cas d’une acceptation, la réception 240 de l’information de conformité induit automatiquement un changement de statut de la tâche qui adopte le statut « terminé » ou « accepté », et le passage à la tâche suivante. Dans le cas d’un refus, la réception 240 de l’information de conformité induit automatiquement un changement de statut de la tâche qui peut adopter un statut « refusé », et qui génère une nouvelle tâche de modification du fichier d’épreuve affectée à un opérateur (par ex. graphiste), suivie d’une nouvelle tâche de contrôle. Dans un mode de réalisation, les étapes de génération d’un délai de surveillance et d’envoi d’un message de rappel peuvent être répétées un nombre prédéterminé de fois. Dans un mode de réalisation, un nouveau délai de surveillance est généré 220 lors de l’envoi d’un message de rappel, et si à l’expiration de ce délai, pour le premier ou le nombre déterminé de messages de rappel envoyés, aucune réponse n’a été reçue à la requête de contrôle, le procédé comprend la génération 250 d’une tâche de relance affectée à un opérateur. La tâche de contrôle peut conserver le statut « en cours » tant qu’aucune réponse n’a été reçue. La tâche de contrôle permet donc une automatisation du contrôle et de la surveillance de la réalisation de ce contrôle dans des délais déterminés, et permet de centraliser les informations en recevant directement l’indication de conformité d’un opérateur, sans passer par des échanges entre deux opérateurs. La tâche de modification du fichier d’épreuve 300 est détaillée en référence à la figure 4 et comprend l’émission 310 d‘une requête de remplacement du fichier d’épreuve, cette requête pouvant être envoyée à un logiciel client du serveur pour être traitée par un graphiste. Avantageusement, la tâche 300 comprend, simultanément à l’émission 310 de la requête de remplacement, la génération d’un deuxième délai de surveillance de la réception d’une réponse à la requête de remplacement, et, si aucune réponse à la requête de remplacement n’est reçue à l’expiration du deuxième délai de surveillance, l’émission 330 d’un message de rappel. Comme précédemment, les étapes de génération 320 d’un deuxième délai de surveillance et d’émission 320 d’un message de rappel peuvent être répétées un nombre prédéterminé de fois, et à l’issue du dernier délai de surveillance généré sans réception de réponse à la requête de remplacement, la tâche 300 comprend la génération 350 d’une tâche de relance affectée à un opérateur. Alternativement, la tâche de modification 300 comprend une réception 340 d’un fichier d’épreuve de remplacement. La tâche de modification prend alors un statut « terminé », et le projet passe automatiquement à une nouvelle tâche de contrôle 200 du fichier d’épreuve. La tâche de validation 400 d’un fichier d’épreuve est détaillée sur la figure 3b. Elle comprend l’émission 410 d’une requête de validation comprenant le fichier d’épreuve. Avantageusement, cette requête de contrôle est envoyée par email à un donneur d’ordre, l’email comprenant le fichier d’épreuve en pièce-jointe, ou comprenant un lien vers une page web permettant la visualisation du fichier d’épreuve. En outre, l’email comprend avantageusement un lien vers une interface de validation permettant l’envoi au serveur d’une réponse. En variante, elle peut également être envoyée à un logiciel client de l’architecture client-serveur, dans le cas où le donneur d’ordre peut accéder ou dispose d’un tel logiciel. A cet égard, le logiciel client comprend avantageusement une interface permettant la visualisation du fichier d’épreuve et l’envoi, au serveur, d’une réponse à la requête de validation, cette réponse pouvant être une acceptation si le fichier d’épreuve convient au client, ou un refus dans le cas contraire. Optionnellement, l’émission 410 de la requête de validation s’accompagne simultanément d’un envoi de SMS pour avertir le donneur d’ordre qu’il a reçu cette requête. A partir de l’émission de la requête de validation, le statut de la tâche peut passer à un statut « en cours », ou à un statut spécifique comme « requête de validation envoyée ». Simultanément à l’émission de la requête de contrôle, un troisième délai 420 est généré, pour surveiller la réception d’une réponse à la requête de validation. Si aucune réponse à la requête de contrôle n’est reçue à l’expiration du troisième délai de surveillance, la tâche comprend l’émission 430 d’au moins un message de rappel, soit par email, soit via le logiciel client. En variante, la tâche peut comprendre la réception 440 d’une réponse à la requête de validation. Dans le cas d’une validation, la réception 440 de cette validation induit automatiquement un changement de statut de la tâche qui adopte le statut « terminé » ou « accepté », et le passage à la tâche suivante. Dans le cas d’un refus, la réception 440 de la réponse induit automatiquement un changement de statut de la tâche qui peut adopter un statut « refusé », et qui génère une nouvelle tâche 300 de modification du fichier d’épreuve affectée à un opérateur (graphiste), suivie d’une nouvelle tâche de validation. La tâche de modification du fichier d’épreuve est identique à celle décrite précédemment. Dans un mode de réalisation, les étapes de génération d’un troisième délai de surveillance et d’envoi d’un message de rappel peuvent être répétées un nombre prédéterminé de fois. Dans un mode de réalisation, un nouveau délai de surveillance est généré 420 lors de l’envoi d’un message de rappel, et si à l’expiration de ce délai, pour le premier ou le nombre déterminé de messages de rappel envoyés, aucune réponse n’a été reçue à la requête de validation, le procédé comprend la génération 450 d’une tâche de relance affectée à un opérateur. La tâche de validation peut conserver le statut « en cours » tant qu’aucune réponse n’a été reçue. La tâche de validation permet donc une automatisation de la validation et de la surveillance de la réalisation de cette validation dans des délais déterminés, et permet de centraliser les informations en recevant directement l’indication de conformité d’un opérateur, sans passer par des échanges entre deux opérateurs. Dans des modes de réalisation, la tâche de contrôle suit immédiatement la tâche de validation ou inversement, de sorte que l’obtention d’une acceptation du fichier d’épreuve dans celle de ces tâches effectuée en dernier déclenche automatiquement et immédiatement la mise en production 500 du travail d’impression, par le démarrage de la tâche suivante qui est une première tâche du travail d’impression. Dans les cas décrits ci-avant où une tâche de contrôle ou de validation est allongée du fait de l’envoi successifs de plusieurs rappels, ou de la nécessité de modifier le fichier d’épreuve, la date de fin de projet d’impression et/ou les calendriers d’exécution de certaines ressources peuvent être recalculés pour tenir compte de ces nouvelles étapes. Le procédé décrit ci-avant permet donc à un imprimeur ou à un graphiste de connaître en permanence et en temps réel l’état d’avancement de l’ensemble des projets, et notamment la situation des fichiers d’épreuve, permettant de déterminer le nombre et la nature des tâches à réaliser à chaque instant, ce qui permet un gain de temps significatif. Procédé de traitement de données pour la réalisation d’un travail d’impression, le procédé étant mis en œuvre par un calculateur (10) et comprenant la mise en œuvre d’au moins une tâche de contrôle (200) ou de validation (400) d’un fichier d’épreuve du travail d’impression, comportant : - l’émission (210, 410) d’une requête de contrôle ou de validation comprenant le fichier d’épreuve, - la génération (220, 420), d’un délai de surveillance de la réception d’une réponse à la requête émise, - si aucune réponse n’est reçue à l’expiration du délai de surveillance, l’émission (230, 430) d’un message de rappel, le procédé comprenant en outre la réception (240, 440) d’une réponse à la requête émise, ou à défaut, la génération (250, 450) d’une tâche de relance affectée à un opérateur. Procédé de traitement de données selon la revendication précédente, comprenant en outre, à la réception d’une information d’une réponse négative à la requête émise, la mise en œuvre d’une tâche de modification (300) du fichier d’épreuve, comprenant - l’émission (310) d’une requête de remplacement du fichier d’épreuve, - la génération (320) d’un deuxième délai de surveillance de la réception d’une réponse à la requête de remplacement, - si aucune réponse à la requête de remplacement n’est reçue à l’expiration du deuxième délai de surveillance, l’émission (330) d’un message de rappel, le procédé comprenant en outre la réception (340) d’un fichier d’épreuve de remplacement ou, à défaut, la génération (350) d’une tâche de relance affectée à un opérateur. Procédé de traitement de données selon l’une des revendications précédentes, comprenant la mise en œuvre d’une tâche de contrôle (200) et d’une tâche de validation (400), et la commande du démarrage d’une tâche de production (500) à la réception d’une réponse favorable à une requête émise pour celle de la tâche de contrôle et de la tâche de validation mise en œuvre en dernier. Procédé de traitement de données selon l’une des revendications précédentes, dans lequel la tâche de contrôle est mise en œuvre pour l’obtention d’une information de conformité technique du fichier d’épreuve, et la tâche de validation est mise en œuvre pour l’obtention d’un accord d’un donneur d’ordre sur le fichier d’épreuve. Procédé de traitement de données selon l’une des revendications précédentes, comprenant une étape préliminaire de génération (100) d’un projet d’impression pour la réalisation du travail d’impression, le projet d’impression comprenant un ensemble de tâches, et le procédé comprend en outre l’association à chaque tâche d’un statut de réalisation de la tâche, et la mise à jour en temps réel du statut de réalisation de chaque tâche. Procédé de traitement de données selon la revendication précédente, dans lequel l’étape de génération (100) du projet d’impression comprend en outre l’association à chaque tâche d’une durée prédéterminée d’exécution, et la génération, à partir des durées associées à chaque tâche, d’une date de fin de travail d’impression. Procédé de traitement de données selon la revendication précédente, comprenant le recalcul d’une date de fin de travail d’impression, en cas de durée effective d’une tâche supérieure à la durée allouée, le recalcul étant déterminée à partir des durées des tâches restant à réaliser et des calendriers des ressources associées à ces tâches. Produit programme d’ordinateur, comprenant des instructions de code pour la mise en œuvre du procédé selon l’une des revendications qui précède, lorsqu’il est mis en œuvre par un calculateur (10). Calculateur (10), caractérisé en ce qu’il est configuré pour la mise en œuvre du procédé selon l’une des revendications 1 à 7. Système de traitement de données pour la réalisation d’un travail d’impression, comprenant une architecture (1) client-serveur comprenant un serveur (11) configuré pour la mise en œuvre du procédé selon l’une des revendications 1 à 7, et au moins un client (21) configuré pour : - recevoir une requête de contrôle comprenant le fichier d’épreuve émise par le serveur, - afficher le fichier d’épreuve, et - envoyer au serveur une réponse à la requête de contrôle comprenant une information de conformité du fichier d’épreuve.