Une approche content-centric du display
Le display (communication écran) pose de nombreux problèmes, à la fois techniques et de contenus. 6 ans de création pour ce média nous ont amené à une approche “content-centric”. Voilà pourquoi…
En 2000, nous avons commencé à créer pour le media écran. A l’époque, aucune méthode n’était en place, nous avons cherché tous azimuts : vidéo, html, director, flash, mpeg4, soap, Hypnotizer, et j’en oublie. Nous ne savions pas si les codes de référénces pertinents étaient ceux de la télévision, du multimedia (CD-Rom, bornes, etc), du web, ou du print. Nous diffusions avec un logiciel axé planification, dont les fonctions principales étaient la création de séquences, la gestion de calendrier, et la gestion de players. Un embryon d’éditeur de contenu, ressemblant à Power Point très simplifié, n’a jamais été utilisé en production.
Puis, nous avons eu le cas Consoshop.
Consoshop: tout à la main
Une chaîne de magasins qui ne vend rien, mais qui propose des réductions. Nous avons créé du contenu interactif et non-interactif, avec des prix, des offres, des visuels, etc. Les temps de rendus et les poids de fichiers de la vidéo nous ont vite fait comprendre qu’il fallait la réserver à des jingles, mais surtout pas à des offres, parce que les prix, les conditions générales ou les visuels sont susceptibles de changer bien trop souvent. Nous avons eu la bonne intuition du Flash. Depuis, l’histoire nous a donné raison, mais à l’époque, l’hésitation avec Director, le SVG ou le DHTML était importante. Bref, nous avons créé des animations Flash pour présenter toutes ces offres. Par exemple, pour présenter une offre de 10% de réductions sur une boîte de pâtes, il fallait récupérer le visuel de la boîte (packshot), le logo (merci La Logothèque), les textes, souvent par mail en plusieurs fois et pas très clair. Il fallait ensuite construire une animation Flash : préparer les images, intégrer, animer. Puis, faire valider au client. Là, problème classique (nous ne savions pas encore qu’il allait être classique), le client ne lit pas les animations swf. Il faut lui expliquer qu’il doit la glisser dans le navigateur, et souvent, il n’y arrive pas. On essaie alors l’exécutable, qui ne passe pas l’antivirus, le firewall, et de toutes façons ne se lit pas, parce que le client est sur un mac. Bref, on finit par lui faire parvenir, il la voit, mais demande de toutes façons des captures d’écran, pour pouvoir imprimer et corriger sur papier, soit parce qu’il n’arrive pas à corriger sur écran, soit parce qu’il doit partir en week-end, soit parce qu’il doit faire valider l’animation par un chef allergique à l’ordinateur. On se retrouve donc à faire des captures d’écran, les mettre en page rapidement, faire un pdf, et l’envoyer. A chaque retour de correction, on reprend : animation, captures, pdf. Chaque animation demandait des dizaines d’étapes inintéressantes. Après quelques mois à ce régime, Consoshop a fait faillite. Heureusement pour nous.
Eurosport Café: tout vidéo
Un bar à thème près des Champs-Elysées, avec des écrans pour faire moderne. Nous avons créé des jingles, et des jingles, et encore des jingles. Manquait le contenu. Le client n’avait probablement pas de budget, donc en plus des jingles, on avait des images fixes pour présenter les offres (restauration, événements, etc). Pas brillant. Là encore, faillite (j’ose croire que les écrans n’y sont pour rien).
Un peu plus tard, après d’autres péripéties, nous arrivons aux conclusions suivantes : la vidéo, c’est beau mais lourd (à produire, à envoyer) ; le Flash statique (à la main), c’est moins lourd que la vidéo, potentiellement moins spectaculaire, mais quand on en fait des dizaines, ça n’est plus possible. Nous arrivons alors à la solution technologique suivante : le Flash dynamique (avec des variables).
Brittany Ferries: tout Flash dynamique
Une compagnie de ferries, qui équipe un superbe bateau, avec de nombreux écrans à bord. Nous avons créé des offres marchandes, restauration, animation, sécurité, et des bornes tactiles. Mais là, plus de Flash à la main: un tout nouvel outil maison, qui permettait d’éditer des fichiers de variables directement, en prévisualisant le résultat en live. On développe donc des animations, capables de s’adapter aux différents besoins de communication, puis nous déclinons tout çà en de très nombreux exemplaires, pour pouvoir communiquer sur de très nombreux sujets à la fois. Et c’est là que le bât blesse. Une modification de la structure après déclinaison nous oblige à tout redécliner, des centaines de fichiers. Puis une autre. Et nous réalisons que le système est très pratique pour l’utilisateur, mais pas pour nous. L’utilisateur est indépendant, mais la création n’est pas évolutive.
Après d’autres mises en pratique de cette méthode, nous en réalisons les limites : un seul utilisateur peut travailler sur un contenu, il n’y a pas d’historique des modifications, il n’y a pas de process de validation, il n’y a pas de gestion multilingue.
Parallèlement, nous développons un système de gestion de contenus automatisés. Les flux RSS, aujourd’hui habituels, étaient encore peu connus, et nous fabriquons une plate-forme d’agrégation et de redistribution. En entrée, de l’info AFP, de l’info financière, de l’info ad hoc écrite par des journalistes. En sortie, diffusion sur des réseaux display différents, avec des habillages différents.
Senso System 1: CMS web
Nous développons Senso System 1, un système de gestion de contenu (CMS) dédié au web, avec l’idée de l’ouvrir plus tard au display. Là, nous mettons en place une gestion multi-utilisateurs, une historisation, une gestion multilingue. Le coeur de notre approche est en place, le contenu prime sur les autres couches techniques.
Senso System 2: CMS pluri-media
Nous rencontrons Medialon, avec qui nous établissons un partenariat. Medialon a un moteur display, capable de faire les playlists (séquences), les transferts ftp, et la diffusion. Nous avons un CMS capable de faire de la gestion de contenus. Nous décidons de construire ensemble un système display intégré, géré en ligne, et centré sur le contenu. Ce sera une Rich Internet Application, c’est à dire une application web reprenant les fonctionnements d’une application offline: fenêtres, applications, explorateur, etc. Nous intégrons la gestion des séquences, persuadés que cette fonction n’est plus discriminante par rapport à l’état du marché: n’importe quel logiciel est capable de jouer des fichiers les uns après les autres. Winamp le fait, Videolan le fait, et ils sont gratuits. Ce n’est donc pas là-dessus que nous allons faire la différence.
Nous mettons en place une gestion centralisée de la création, indépendante de l’écriture de contenus, tout à fait analogue à la séparation XHTML/CSS. Plutôt que d’essayer de résoudre le problème des modes de planification (chaque client veut planifier ses contenus selon des règles dépendant de son métier), nous mettons en place un système de base, et une architecture modulaire, permettant l’intégration de briques implémentant une logique métier ad hoc. En clair, le système ne sait pas tout faire, mais on peut lui apprendre.
La gestion de workflow devrait être améliorée dans Senso System 3, mais nous croyons que la base de réflexion est bonne. Soit on diffuse des vidéos décoratives, et un DVD suffit souvent, soit on diffuse des contenus riches, avec des textes, des images, des sons, des vidéos provenant de sources hétérogènes, remises à jour souvent, et une solution content-centric est indispensable à la viabilité du système d’information, surtout à moyen/long terme.
L’approche content-centric consiste à placer le contenu au centre de la réflexion stratégique, communicationnelle et technique.
En effet, les utilisateurs sont la clé du bon fonctionnement d’un outil, et la perte de temps induite par les systèmes axés planification est telle, qu’ils finissent par être laissés à l’abandon.
