Le web-to-print évolue à l'heure du no-code / low-code
Pendant longtemps, voire quasiment depuis toujours, se lancer dans l’imprimerie en ligne ou la personnalisation de masse impliquait de développer soi-même une grande partie de sa plateforme, soit pour intégrer des briques logicielles existantes, soit pour créer sa propre solution « from scratch », soit pour faire un mix des deux. Avec à la clé, tous les affres du développement logiciel : maintenance, debugging, gestion des mises à jour, des changements de framework, itération des améliorations, problèmes de sécurité… Bon nombre d’imprimeurs en ligne m’ont confié qu’au fil des années, ils ont l’impression d’être ainsi devenus des éditeurs de logiciels, plus que des imprimeurs.
On le voit d’ailleurs dans la composition des équipes dans les entreprises qui font de l’imprimerie en ligne : qu’ils soient internalisés ou outsourcés, il y a de plus en plus de développeurs… ce qui entraîne la nécessité de disposer de chef de projet ou de product owners pour les encadrer, spécifier les besoins, réaliser les tests. Autant de profils totalement nouveaux qu’il faut intégrer, et également, de ressources rares aussi coûteuses à embaucher que difficiles à trouver sur le marché.
Le poids du « code » est lourd dans des projets de web-to-print : dans les phases de démarrage, il absorbe la majeure partie des budgets, au détriment souvent de l’acquisition ou du développement commercial. Et les dirigeants qui pensent qu’une fois le projet lancé, cela s’arrêtera, se trompent énormément : pour maintenir l’investissement à flot, il faut sans cesse de nouveaux développements, de la maintenance, du debugging, des mises à jour. C’est un écosystème vivant que vous avez créé, et il se nourrit de code.
Jusqu’à présent, la seule alternative au développement interne de sa propre plateforme consistait à acheter une solution sur-étagère, en mode « clé en mains ». Plusieurs éditeurs ont connu de belles réussites dans ce domaine, grâce à la rapidité de déploiement et à la tranquilité d’esprit qu’ils procuraient à leurs clients.
Mais au fil des années, ces solutions souvent fermées ont commencé à se faire distancier par les nouvelles générations technologiques, ou parfois même par la règlementation, au point de ne plus pouvoir répondre aux nouveaux besoins de leurs clients. Car l’utilisateur final a mûri au fil des ans, et il ne se satisfait plus aujourd’hui de simples grilles de prix avec quelques variantes et attributs. Il veut des calculateurs dynamiques, capables de donner des tarifs par surface, en tenant compte d’une multitude de paramètres…
Les power-users internes aussi ont évolué, suivant les avancées du eCommerce. Ils veulent que leur plateforme puisse alimenter une CRM, un logiciel de service client, un système d’emailing, et souvent, les solutions « sur-étagère » ne sont pas en mesure de dialoguer avec ces nouveaux outils. Ce qui oblige, souvent, à commander de nouveaux développements… Et puis les juristes exigent une compatibilité avec le RGPD et les lois anti-fraude à la TVA (NF 525).
L’ère du no-code / low-code
Si vous me lisez régulièrement, vous savez que je milite pour les architectures web organisées autour d’API. Ce n’est pas nouveau, mais tous les logiciels ne sont pas pensés de cette façon, et c’est bien dommage. Aujourd’hui, la plupart des solutions utilisées en entreprise pour la CRM, la gestion commerciale, le service client, l’envoi d’emails, le stockage de fichiers… proposent des API.
Les grandes plateformes de eCommerce comme Magento, Shopify ou Prestashop proposent également, dans leurs marketplaces, des modules d’édition en ligne pour gérer du print-on-demand, via aussi des API. Et des plateformes intégrées d’imprimerie en ligne offrent des connecteurs génériques vers ces outils… Quant à ceux qui ne seraient pas disponibles dans les librairies, il est possible de les interconnecter via des interfaces tierces telles que Zapier.
Concrètement, cette nouvelle façon d’appréhender l’informatique consister à assembler des modules pour construire sa plateforme de web-to-print, sans coder. Il « suffit » d’être un utilisateur expérimenté, à l’aise avec des aspects techniques et débrouillard, pour interconnecter ces modules, leur permettre de dialoguer entre eux… Ce n’est pas un fantasme, c’est une réalité, qui va transformer la relation entre consommateurs de logiciels et éditeurs.
A l’instar par exemple de Chili Publish, de nombreux éditeurs envisagent désormais leur logiciel sous la forme de modules qui tels des briques de Lego™ peuvent venir se greffer à une plateforme de vente en ligne pour répondre à un besoin, et enrichir son périmètre fonctionnel.
Certaines solutions plus complètes, dédiées à l’imprimerie en ligne ou au MIS, s’ouvrent dans un schéma similaire : en complément des fonctions du cœur, elles offrent une marketplace de connecteurs qui permettent soient de remplacer une fonction native par un outil plus avancé, soit de dialoguer avec les logiciels tiers utilisés par la société, pour fluidifier les échanges de données.
Vers moins de silos
Cette évolution est à prendre sérieusement en compte, car elle modifie le coût de lancement et de maintenabilité des plateformes, et le time-to-market. Parallèlement, selon comment est appréhendé le schéma directeur de l’IT de votre entreprise, elle peut permettre de réduire les silos qui trop souvent, conduisent à des reprises manuelles de données, ou à des outils incapables de dialoguer entre eux. Toutefois, ce n’est pas la panacée, et il reste indéniablement un aspect un peu « bricolo » derrière cela, susceptible de créer des usines à gaz ou de provoquer des failles de sécurité… Mais personnellement, je trouve que côté terrain de jeu, c’est diablement tentant…
Crédit photo : Pixabay