Conduire un projet web-to-print : bien plus compliqué que mener un "simple" projet web
Je le reconnais, ce titre est volontairement provocateur. Loin de moi l'idée de laisser croire que gérer un projet web est une tâche facile. Pour l'avoir fait à plusieurs reprises, je sais ô combien la conduite d'un site web, e-commerce ou CMS est complexe...
Mais j'assume cette touche de provoc' : en effet, les projets web-to-print – des simples printshops aux plateformes éditoriales sophistiquées – sont souvent abordés exactement de la même façon que les services web .
A tort.
En caricaturant à l'extrême, le scénario est le suivant :
- cahier des charges,
- spécifications,
- design de l'interface,
- développement,
- intégration,
- recette
- et... mise en route !
Bien entendu, le niveau de complexité varie suivant l'environnement, les exigences du client et l'intégration d'applications tierces. Mais globalement, tout projet web suit grosso modo cette route.
Les écueils potentiels sont globalement connus et identifiés : conduite du changement, problématiques de compatibilité et d'accessibilité, performances, sécurité, disponibilité des services et surtout, planning de déploiement. En d'autres termes, DSI du client, intégrateur, chefs de projet avancent en terrain connu, en sachant où poser le pied à chaque étape.
Avec au final, un résultat binaire : soit le service web fonctionne, soit il ne fonctionne pas. Là encore, je caricature à l'extrême... volontairement. Je parle de "binaire" pour expliquer qu'à mon sens, un projet web a une dimension "numérique" par opposition au print qui lui, a plus la fibre "analogique" dans son ADN.
Bien sûr, un projet web-to-print va connaître ces mêmes phases de spécification, design, développement ou intégration, recette et mise à flots. Mais beaucoup d'étapes intermédiaires vont devoir s'intercaler. Des étapes essentielles, pour ne pas dire cruciales, que le prestataire, qu'il soit intégrateur ou éditeur, doit parfaitement maîtriser...
La chaîne alimentaire du web-to-print
Dans la grande majorité des cas, un projet web-to-print modélise des façons de travailler déjà en place, avec des processus et des méthodes employées depuis plusieurs années. Il faut donc commencer par :
- formaliser ces méthodes pour modéliser des workflows ;
- rationaliser ces processus pour les rendre compatibles avec une logique web-to-print, ce qui implique d'imposer parfois à certains collaborateurs de modifier la façon dont ils travaillent depuis des années : et là, il convient généralement d'ajouter au terme "conduite au changement" le suffixe "en milieu hostile, voire très hostile" ;-)
- identifier les différents intervenants, comprendre les échanges qui s'établissent et dessiner le scénario qui rythme ces échanges ;
- définir le scénario de validation de chaque document, de sa production à son bon à tirer : qui valide quoi ?
C'est à ces niveaux que se situent les premières différences entre projet web et projet web-to-print : la multiplicité des intervenants. Dans une plateforme éditoriale, vous allez trouver des créatifs, des graphistes pré-presse, des freelances, des photograveurs, des directeurs artistiques, des responsables marketing, des rédacteurs, des photographes... et tout un tas de responsables qui doivent approuver le document avant sa mise sous presse : validation technique, orthographique, juridique, commerciale... Sans oublier que ces intervenants n'ont pas la logique technique qui coule dans leurs veines : ils pratiquent souvent des professions artistiques ou graphiques, loin des contraintes industrielles et des méthodologies informatiques.
Mine de rien, ce premier travail est essentiel : il va permettre de comprendre comment l'entreprise fonctionne en mettant en évidence certaines incohérences et nécessairement, des adaptations rendues obligatoires par la mise en place d'une plateforme éditoriale web-to-print.
Le champ de mines du Print
D'un point de vue technique, les projets print s'apparentent pour moi à des champs de mines. Et il faut savoir les déminer à l'avance pour que le déploiement de la plateforme web-to-print se déroule correctement. Parmi les “mines” potentielles, je distingue :
- celles causées par à la façon dont les fichiers sont mis en page : logiciels utilisés, rigueur dans les méthodes de mise en page, répartition du travail entre plusieurs graphistes, structuration des documents, respect des règles de l'art...
- celles causées par les éléments liés : types d'images, formats, problématiques de gestion colorimétrique, stockage et partage des assets...
- celles causées par les contraintes de sortie : une plateforme web-to-print a pour vocation ultime de produire un fichier prêt à être imprimé. Or il ne suffit de produire un fichier PDF-X pour qu'il soit utilisable en l'état par un imprimeur. Preflight, gestion colorimétrique, validation, certification, respect du cahier des charges imprimeur, choix et tests du profil de distillation, softproofing... un vrai parcours du combattant !
- celles liées aux performances : dans les projets web-to-print, on manipule des fichiers très lourds (images et mises en page) dans des environnements qui, à l'origine, ne sont pas conçus pour cela : interfaces web, réseaux locaux, connexions internet aux performances variables, ordinateurs de bureau... Il faut donc conduire beaucoup de tests de montée en charge pour s'assurer des performances, celles des serveurs comme celles des accès réseaux.
- celles liées à l'usabilité : la plupart des projets web-to-print ont pour finalité de permettre à des non-spécialistes de réaliser des tâches qui jusque-là étaient réservées à des spécialistes. Il faut donc réussir à réaliser de façon très simple des choses compliquées ; l'interface et les enchaînements d'écran doivent donc être pensés, analysés et structurés pour être utilisables par tous. L'ergonomie prend alors toute son importance.
Il est illusoire de croire que l'on peut prendre n'importe quel fichier PAO, le “balancer” dans une plateforme web-to-print en espérant que tout se passera miraculeusement du premier coup...
Un projet de plateforme éditoriale w2p exige une profonde remise en cause des méthodes de travail de chaque maillon de la chaîne : il faut savoir se poser et comprendre comment les gens travaillent, pour adapter ces méthodes de travail à un système automatisé.
Une fois que cette première analyse a été menée, il est ensuite indispensable de décortiquer les fichiers qui vont alimenter la plateforme pour identifier chaque problème potentiel afin de l'éliminer comme autant de "mine" potentielle... C'est un long mais indispensable travail.
Et puis, il va falloir ensuite roder le système, le faire monter en puissance, l'affiner et l'améliorer, au niveau de la technique et des méthodes. Un peu à la manière de l'artisan qui affine son ouvrage par petites touches.
C'est à ce stade que web et web-to-print diffèrent le plus, à mon avis : loin du fonctionnement "binaire" du web, un projet web-to-print est rarement tout bon ou tout mauvais. Il demande à se roder, à s'améliorer, à monter en chauffe pour atteindre un régime de croisière satisfaisant pour tout le monde...
Il faut bien comprendre que même si techniquement, tout fonctionne, une plateforme éditoriale peut être un échec : délais trop longs, manipulations trop fastidieuses, ergonomie mal pensée peuvent rendre totalement inutilisable un outil à priori opérationnel. Les métiers de la communication et du marketing sont des environnements dans lesquels les délais sont souvent très courts : la plateforme éditoriale ou le service web-to-print doit donc être tout sauf un frein, sinon les utilisateurs auront vite fait de débrayer pour revenir à des techniques certes traditionnelles, mais éprouvées. Le “déminage” et les tests répétés, à chaque étape, permettront donc d'éviter un rejet de ce type, en avançant doucement mais sûrement.
Le projet web-to-print doit donc être conduit de façon à s'intégrer dans un environnement existant tel un poisson dans l'eau. Et non pas comme un barrage sur une rivière.
C'est pas moi, c'est Confucius qui l'a dit... Enfin Confucius 2.0.
C'est à ce stade que web et web-to-print diffèrent le plus, à mon avis : loin du fonctionnement "binaire" du web, un projet web-to-print est rarement tout bon ou tout mauvais. Il demande à se roder, à s'améliorer, à monter en chauffe pour atteindre un régime de croisière satisfaisant pour tout le monde...
Il faut bien comprendre que même si techniquement, tout fonctionne, une plateforme éditoriale peut être un échec : délais trop longs, manipulations trop fastidieuses, ergonomie mal pensée peuvent rendre totalement inutilisable un outil à priori opérationnel. Les métiers de la communication et du marketing sont des environnements dans lesquels les délais sont souvent très courts : la plateforme éditoriale ou le service web-to-print doit donc être tout sauf un frein, sinon les utilisateurs auront vite fait de débrayer pour revenir à des techniques certes traditionnelles, mais éprouvées. Le “déminage” et les tests répétés, à chaque étape, permettront donc d'éviter un rejet de ce type, en avançant doucement mais sûrement.
Le projet web-to-print doit donc être conduit de façon à s'intégrer dans un environnement existant tel un poisson dans l'eau. Et non pas comme un barrage sur une rivière.
C'est pas moi, c'est Confucius qui l'a dit... Enfin Confucius 2.0.