Posture : Pourquoi je crée mes propres plateformes web

N’est-il pas étrange de consacrer des efforts à créer ma propre plateforme alors que je pourrais tout simplement publier un flux d’images dans Instagram ou Twitter, des albums dans Facebook, Google+ ou Flickr, des récits dans Exposure, Medium ou Stampsy?

D’ailleurs, j’obtiendrais probablement plus de visibilité sur ces plateformes, grâce à leurs dimensions «sociales». Et puis ne pouvant consacrer qu’un temps limité au développement de mes sites personnels, je ne pourrai jamais offrir à mes visiteurs un ensemble de fonctionnalités aussi riche que sur ces réseaux sociaux soutenus par des entreprises disposant de ressources énormes.

Malgré tout, je m’entête à aménager mes propres petits espaces sur le web, et je crois que cela s’explique en partie par les raison suivantes :

• J’aime faire un pied de nez à tous ces jardins privés que sont les Facebook et Instagram de ce monde, qui restreignent souvent l’accès aux contenus créés par leurs utilisateurs et cherchent à emprisonner leur public dans leur plateforme, pour répondre à des impératifs commerciaux, à l’encontre de l’esprit d’ouverture et de partage par lequel est né le Web.
• Je déplore l’homogénéité des plateformes centralisatrices. Publier sur le Web est facile, plus facile que jamais, et j’espère que les individualités et la diversité continueront à s’illustrer sur le Web.
• Mes données m’appartiennent — c’est particulièrement vrai pour mes photographies et mes récits, qui sont un peu une partie de moi-même — et je tiens à conserver sur elles un plein contrôle et un plein accès. Je veux pouvoir les copier, les déplacer, les analyser ou les transformer à mon gré.
• Un projet personnel est une belle occasion d’explorer des technologies ou des outils qui m’intéressent et qui pourraient servir dans mes activités professionnelles.
• Avoir ma propre plateforme ne m’empêche pas de publier aussi dans les autres réseaux, si je le désire.

Concernant la motivation derrière lieux.photo en particulier, il existait déjà des services en ligne permettant de réaliser un concept semblable à celui que j’imaginais, notamment Exposure, une plateforme de «storytelling» axée sur la photographie. Mais Exposure présente plusieurs inconvénients. Outre le sérieux inconvénient d’emprisonner mes données dans une plateforme dépourvue d’outils d’exportation, son expérience utilisateur, pourtant très réussie sur appareil mobile est, selon moi, exécrable sur ordinateur, avec des photos souvent trop grandes pour entrer au complet dans l’écran, et son environnement unilingue anglophone ne convient pas au public francophone auquel s’adresse mon site.

Par ailleurs, sur Exposure et sur les autres plateformes, le récit semble passé et figé. Or je considère la notion de récit dans un sens large, où un «récit» est une séquence d’images, et j’avais pour idée qu’un récit soit appelé, parfois, à évoluer dans le temps. Je souhaitais concilier une certaine notion de flux d’images à celle de récit. Tout en considérant le récit comme l’unité primaire de contenu, je voulais à la fois permettre l’enrichissement d’un récit existant et mettre en valeur les nouvelles images. Ainsi, sur lieux.photo, la page d’accueil montre en premier les récits dont la date de mise à jour, plutôt que la date de création, est la plus récente. Également, la page de flux montre les photos les plus récentes du site, avec liens directs vers leurs récits respectifs.

Bref, je n’ai trouvé aucun service en ligne répondant à mes critères. En créant ma propre solution je pouvais réaliser fidèlement mes idées.

Technologie : Pourquoi j’ai choisi Django

Lorsque j’ai finalement décidé de me lancer dans la création de lieux.photo, le choix de la plateforme Django s’est imposé naturellement. J’utilise maintenant Python, le langage avec lequel Django est codé, pour l’essentiel de mon travail; choisir Django créait une nouvelle opportunité d’utiliser des outils que j’apprécie. J’ai caressé un peu l’idée d’utiliser un générateur de sites statiques tel que Pelican, également en Python, dont j’apprécie grandement l’architecture ultrasimple et que j’aurais pu enrichir d’extensions particulières au traitement des images. Mais puisque j’entrevois que d’autres utilisateurs que moi-même pourraient publier sur le site, j’ai préféré Django pour son interface d’administration conviviale. Désirant un système aussi minimal que possible, j’ai ignoré des options plus élaborées comme Mezzanine, DjangoCMS ou Wagtail, des CMS (gestionnaires de contenus) construits autour de Django.

Mes anciens sites, vu|photographie et Explora étaient basés respectivement sur Drupal 5 et Drupal 7. En faisant fi de mes intérêts actuels, j’aurais sans doute pu poursuivre avec le CMS Drupal, voire avec son petit frère Backdrop, mais voilà, la stratégie d’innovation de Drupal qui permet de tout changer entre chaque nouvelle mouture du logiciel fait qu’il n’est pas significativement plus efficace de refondre un système Drupal 5 ou Drupal 7 pour le faire passer à Drupal 8 que de passer à un environnement complètement différent comme Django.

De toute façon, Drupal me semble de moins en moins s’adresser aux programmeurs même si, paradoxalement, sa complexité croissante le place souvent hors de la portée des non-programmeurs. Je ne m’étendrai pas plus ici sur ce genre de contradiction affligeant l’écosystème Drupal, ni sur le langage PHP qui, malgré une prétendue «PHP Renaissance», continue à accumuler les monstruosités. Pour avoir utilisé Drupal et contribué à son développement depuis 10 ans, je connais parfaitement la bête! En revanche, choisir Django et Python c’est choisir une plateforme et un langage qui évoluent avec la priorité de maximiser la productivité du programmeur. La devise de Django illustre bien ce choix stratégique : «La plateforme de développement web pour les perfectionnistes sous pression»!

Technologie : Les composantes du site

Outre Python 3 et Django, lieux.photo emploie un sympathique cortège de composantes :

• MySQL et mysqlclient : Je m’en suis tenu au bon vieux MySQL pour la base de données relationnelle, le site n’ayant pas de besoins particuliers de ce côté. Je connais la bête et elle fait le travail.
• Redis et django-redis : Les intégrations de Memcache pour Python 3 n’étant pas tout à fait à point, j’ai choisi Redis pour la mise en cache des pages. Aucun regret de ce côté; Redis est bien supporté dans l’environnement Python, facile à déployer et très performant. Les pages des récits comportant un grand nombre d’éléments sont relativement longues à construire et, pour l’instant, je n’ai pas cherché à optimiser leur traitement. Le principal secret de la performance du site réside dans les caches!
• Celery : Grâce à Celery, avec Redis comme support des messages, le système exécute de manière asynchrone, donc non bloquante, les processus parfois très longs, comme le traitements des images et l’envoi de notifications par courriel (via django-celery-email).
• django-imagekit et Pillow : Mon système conserve des images originales de grande dimension et génère, via django-imagekit, plusieurs images dérivées de différentes tailles pour différents formats d’affichage, tout en leur appliquant la signature du site en filigrane. J’ai considéré Easy-Thumbnails, Sorl-Thumbnails et Django-StdImage, mais opté pour django-imagekit principalement en raison de son intégration harmonieuse aux modèles Django. Il est ainsi possible d’ajouter aux modèles des «champs virtuels», où un champ virtuel spécifie un ensemble de transformations d’image et peut ensuite être accédé depuis un template aussi naturellement qu’un champ régulier. En outre, django-imagekit supporte la délégation des tâches à Celery pour le traitement asynchrone des transformations, peut utiliser Redis pour conserver en cache les informations sur les images, sa documentation est pas mal et son code m’a semblé plus élégant, compréhensible et extensible que certaines des autres solutions pressenties (les traitements d’images personnalisés, comme l’application du filigrane au moyen d’opérations maison utilisant Pillow, s’intègrent de manière élégante).
• django-assets et webassets : Les indispensables pour gérer les ressources statiques comme le code JavaScript et CSS. Mes feuilles de styles sont écrites en Sass, compilées par Compass et enrichies par Autoprefixer, tout cela sous la supervision transparente de webassets. Les entêtes HTTP transmises par mon serveur peuvent indiquer au navigateur de garder très longtemps ces ressources en cache, puisqu’en cas de changement webassets assignera de nouveaux identifiants aux nouvelles versions, assurant que les visiteurs ne resterons pas liés aux versions en cache (et obsolètes) des ressources (stratégie de cache busting).
• django-simple-history : Ceci gère le contrôle des versions des contenus. Je l’ai préféré au populaire django-reversion car ce dernier me semble souffrir d’un vice fondamental de conception : les données des versions antérieures d’un objet sont stockées dans la base de données sous une forme sérialisée (en JSON). Si le schéma change, ces données deviennent incompatibles avec le nouveau schéma, donc inutilisables. Quant à lui, django-simple-history stocke les versions antérieures dans des tables calquées sur les tables originales et pour lesquelles il génère des migrations équivalentes à celles des tables originales, lorsque le schéma change. Les données de l’historique survivent ainsi aux modifications de schéma, au même titre que les données courantes.
• django-mptt : Une belle solution pour gérer les classifications hiérarchiques, en particulier les toponymes que j’associe aux récits et aux photographies.
• django-suit : Une présentation attrayante pour l’interface d’administration, avec quelques fonctionnalités fort utiles, dont l’organisation des longs formulaires sous plusieurs onglets, des widgets améliorés pour la saisie de dates, le tri d’éléments liés (par exemple, l’ordonnancement des photos peut se faire directement dans le formulaire du récit). La prochaine version de django-suit, basée sur Bootstrap 3, semble prometteuse.
• django-ckeditor : Pour l’édition WYSIWYG avec CKEditor.
• django-bleach : Pour le nettoyage des contenus, notamment au moyen d’un filtre pour templates très pratique.
• typogrify : Pour peaufiner le balisage des textes.

D’autres composantes ne touchent que le «front-end», le volet client du site :

• jQuery : Dans l’univers bouillonnant de JavaScript, jQuery fait figure du vétéran un peu dépassé par les événements, mais il convient tout à fait aux besoins du projet : tout au plus quelques manipulations du document HTML et de classes CSS. Je n’utilise pas les animations de jQuery, confiant plutôt ces dernières à CSS (transitions), car les navigateurs gèrent nativement les animations bien mieux que n’importe quelle solution JavaScript.
• Modernizr : Je l’utilise pour détecter si le navigateur supporte les unités vh et vw en CSS et pour appliquer, si nécessaire, un polyfill (substitut), vminpoly.
• jPlayer : La lecture des fichiers audio (car il y a aussi des enregistrements sonores sur le site) est prise en charge par jPlayer, qui exploite HTML5 autant que possible et se rabat sur Flash si nécessaire.

Des questions à propos de l’architecture du site ou du projet en général? N’hésitez pas à commenter!