Comment est construit ce site photo?

Cet article va couvrir une petite partie de ce qui se passe dans les coulisses de Lanuit.Paris:

• quels outils et connaissances sont nécessaires pour construire ce site?
• quels choix, directions ont été pris et pourquoi ?
• cette stratégie est-elle adaptable à votre projet?

Je vais essayer de vous livrer la vision générale et quelques grands principes de développement que j’ai appliqués ici. Vision qui allie la photographie et les technologies Internet liés aux sites dits “de contenu”.

Tout n’est pas nécessairement pertinent pour vous. Cela dépend du contexte et des besoins de votre projet.

Certains passages pourront vous sembler un peu caricaturaux. J’ai augmenté certains contrastes pour appuyer mon message.

Cet article est, de fait, un peu technique.

Bonnes pratiques, photographie et expérience utilisateur au coeur du projet

Lanuit.Paris est fondé sur deux piliers liés à des techniques, connaissances et outils spécifiques:

• La photographie
  • être capable de capturer et créer de belles photos en utilisant du matériel adapté.
  • Utiliser les logiciels standards du marché (LightRoom/DXO, Photoshop ou Gimp) pour éditer et retoucher au besoin.
  • Se documenter. S’inspirer du travail des autres. Explorer.
• Publier de manière autonome sur internet et constituer une audience:
  • Partager des photographies et du contenu de qualité.
  • Proposer au visiteur un site performant, rapide, le plus largement compatible (smartphone, tablette, ordinateur)
  • Construire un site internet de manière flexible et facile à faire évoluer
  • Utiliser les outils et technologies appropriés et adaptés au besoin
  • Suivre les bonnes pratiques de référencement

Une méthode anti-naturelle pour construire le projet

L’approche la plus commune pour construire un tel projet depuis une feuille blanche est de sélectionner un outil (Content Management System) qui semble le plus facile d’utilisation et qui fournit un maximum de fonctionnalités. Pour ne rien rater et s’assurer un futur sans limites.

Démarrer avec une solution “plug-and-play” ou “tout est sur l’étagère” en partant du principe que la plupart de nos besoins seront comblés sans trop d’effort. Si c’est gratuit c’est encore mieux.

Je suis parti dans la direction totalement opposée (sauf pour la partie gratuite).
Je vais essayer de vous expliquer pourquoi et comment.

Travailler et construire itérativement. Appréhender la complexité étape par étape. Apprendre en construisant

Le site que vous visitez est basique et n’embarque pas d’intelligence particulière.

Il n’inclut pas de fonctionnalité e-commerce ou de briques complexes qui nécessitent des traitements côté serveur. Il n’a pas besoin de “backend” (exécution de code dynamique) comprenant du Php, Java, .Net, Go ou encore NodeJS.

Au lieu de partir d’une solution intégrée et utiliser 5% de ce super-pouvoir, j’ai décidé de partir d’une base technique plus simple, d’un scope de fonctionnalités plus restreint, que je puisse manipuler facilement et faire grandir au besoin.

Pour cette raison, j’ai décidé de ne pas avoir recours à Joomla, Drupal ou WordPress même s’ils répondaient en partie à mon besoin actuel.

Mes buts et besoins techniques étant:

• un canevas, layout, “templating” moderne et flexible (standard, open-source, responsive, mobile first)
• un outil flexible pour administrer les URLs, les taxonomies, les catégories, les tags, une version multilingue
• avoir la possibilité de recueillir un retour immédiat, être capable de tester et mesurer les impacts de mes modifications localement sur un portable standard
• pousser simplement vers la production depuis un logiciel standard de contrôle de code source (CVS)
• Utiliser le mécanisme standard du contrôle de code source pour revenir à une version N-1 en cas de problème
• Ne pas être dépendant d’une infrastructure spécifique, d’un système d’exploitation, de composants techniques compliqués, d’un framework à maintenir ou à mettre à jour
• Ne pas avoir (ou presque) à gérer d’installation N-Tiers, de pouvoir lancer le projet localement, facilement, de la même manière qu’en production (approche systématique)

Au lieu d’utiliser un système CMS (Content Management System) qui nécessite d’être installé, et qui a souvent besoin d’une base de données, j’ai décidé d’opter pour une approche différente et baser ce projet sur GoHugo : un générateur de sites statiques.

Pas de base de données, pas de modules à installer: des fichiers textes, des images et des répertoires

GoHugo est une application qui est légère, simple à installer et à exécuter. Elle est disponible sur toutes les plateformes Windows, Mac OS et Linux.

L’architecture d’un projet repose sur des fichiers textes (configuration, template et contenu) et des répertoires. L’outil est codé en langage Go mais son utilisation ne requiert pas de le connaître.

Le langage de “templating” est la partie la plus complexe à comprendre. Cela peut prendre quelques jours d’apprentissage en mode essai/erreur.

La documentation est très claire, les principes bien détaillés. Le forum et la communauté sont actives.

Dans la mesure oú toutes vos sources sont gérés et accessibles à travers des fichiers, un seul éditeur est nécessaire. De préférénce proposant une coloration syntaxique. Beaucoup d’alternatives gratuites existent. J’utilise “Visual Studio Code”.

Le simple fait d’utiliser un logiciel de contrôle de code source (Git par exemple) garantit la sécurité du projet.
Il est facile de modifier le code, tester, se tromper, comparer les modifications.

La chaîne de génération est complètement transparente et totalement déterministe.
Vous avez le contrôle total du rendu du site.
Sans surprise vous retrouvez vos modifications dans le code final.
Cela prend moins d’une seconde pour générer un site comme celui-ci (environ 400 pages) et 1 minute pour le mettre en ligne.

Le résultat de l’exécution de GoHugo est un site internet complet statiquement généré.
Il peut être hébergé par la plupart des partenaires techniques de manière totalement standard.
J’utilise pour ma part Netlify.

Dans ce scénario, les fonctionnalités ne sont pas directement sur l’étagère

Vous ne pouvez pas cliquer dans un panneau de configuration pour installer des fonctionnalités telles qu’un carrousel, un joli rollover, un formulaire de contact.
Vous allez avoir besoin d’apprendre à trouver et sélectionner les briques de base pour construire votre propre LEGO.
Vous allez avoir besoin de constituer un bagage technique de base. La difficulté reste très modérée.

Par exemple, vous allez devoir:

• suivre les recommandations SEO
• savoir déterminer comment construire une URL efficace
• utiliser le hiérarchie correcte des titres (h1,h2,h3)
• comprendre les media queries pour charger correctement les images sur mobile.

A vous de suivre les bonnes pratiques en HTML, CSS ou encore Javascript.
Enormément de documentations et de tutoriels existent.
Vous allez devoir suivre l’impact de vos dernières modifications en matière de performance dans LightHouse, faire attention au poids de vos pages etc etc…

Vous allez être amené à comprendre dans le détail ce que vous construisez et mettre l’accent sur les contraintes qui ont un impact direct sur votre projet.

Est-ce plus ou moins difficile de faire tout cela que d’utiliser une solution sur l’étagère?

Cela dépend de la manière dont vous souhaitez dépenser votre temps et votre énergie.
Les solutions magiques, qui marchent toutes seules et n’ont pas besoin de compétence technique ou d’attention particulière, à un moment ou à un autre, n’existent pas.

Laissez moi vous donner quelques éléments basés sur mon expérience de projets IT.

J’ai utilisé de manière poussée des Content Management System (WordPress, Joomla, Drupal) durant les dernières années (implémentation de projets, maintenance, développement de modules, migrations).

La part de la maintenance relative à l’intégration d’un framework est toujours sous estimée.
Que vous le souhaitiez ou non, vous allez être obligés d’intégrer des contraintes et de gérer des spécificités techniques qui ne seront pas nécessairement alignées avec vos objectifs.

Pour ce site de photos: Pourquoi devrais-je comprendre comment administrer/mettre à jour une base de données alors que je devrais plutôt concentrer mon énergie sur la partie photographique et expérience utilisateur?

Vous allez aussi découvrir que les modules sont intéressants et faciles à installer mais qu’ils peuvent au fil des mises à jour devenir incompatibles entre eux ou simplement abandonnés.

Vous allez découvrir que votre système peut devenir rapidement obsolète si vous ne gardez pas le rythme.

Vous allez remarquer que “le développeur” a pensé le système, le module, le template, d’une manière qui ne correspond pas exactement à vos besoins ou à vos contraintes.

Logiquement, vous allez devoir modifier cette partie pour coller à vos besoins.

Pour modifier cela, vous allez devoir entrer dans le code, en comprendre les principes, réécrire voire surcharger un module en respectant des standards de programmation inhérents au framework, bien souvent sans avoir de possibilité facile de tester.

Vous allez devoir investir du temps et de l’énergie dans un processus un peu douloureux dont vous ne voyez pas le bénéfice direct. Cela sera frustrant la plupart du temps.
Vous pourrez tomber dans le syndrome du “Mais pourquoi cela ne marche pas comme ca ? Ce n’est pas logique!”

Vous devrez investir du temps et de l’energie sur des sujets que vous n’aviez pas identifiés comme faisant partie de votre chemin critique.
Vous devrez faire peut-être faire des concessions et “tordre” votre projet pour l’adapter à l’outil.

La personnalisation peut aussi devenir un sujet quand vous utilisez une plateforme telle que wix.com, 500px.com, duda.com ou encore slickpic.com.

En fonction du degré de personnalisation que vous souhaitez obtenir, vous devrez passer par des services professionnels, demander un devis ou souscrire à des services additionnels.
La question de “faire vous-même” ou de de “faire-faire”, moyennant finance est centrale.

Plus vous ajoutez de couches techniques ou d’intermédiaires dans votre projet, plus grande est la place pour l’incertitude, les paramètres cachés et paradoxalement, le manque de souplesse.

La conclusion est que dans les deux scénarios, vous allez devoir choisir où investir votre temps/énergie et quelles connaissances acquérir ou améliorer pour sortir votre projet.

Choisissez vos batailles, concentrez vos efforts sur ce qui compte pour vous!

Mon projet est simple.
J’ai donc fait le choix de réduire au maximum les intermédiaires techniques et utiliser GoHugo pour être au plus proche de la matière que je dois produire.

Nous parlons ici des briques de base de l’Internet à savoir: HTML, CSS, Javascript, formats d’images. Ce qui est le cas pour la majorité des blogs.

De nombreux morceaux de codes(“snippets”), exemples, tutoriels sont accessibles gratuitement en particulier sur W3Schools ou encore sur HTML5UP!

A ce niveau de complexité, la plupart du temps, un copier/coller est un bon début pour mettre le pied à l’étrier et avancer étape par étape.
Le chemin entre le prototype et la production est assez court.
Les itérations peuvent être rapides entre les versions.

Si un jour ce projet grossit. Si le besoin se fait sentir d’ajouter des fonctionnalités plus avancées comme une page d’authentification, un panier e-commerce, la possibilité pour le visiteur de laisser des commentaires, il sera temps de chercher des solutions adaptées.

Etudier les solutions les plus en phase avec la philosophie décrite ci-dessus.
L’idée étant d’ajouter étape par étape la complexité et les nouvelle contraintes.

N’est-il pas plus lent et moins performant d’adopter une telle stratégie ?

Je ne suis pas convaincu de cela.
Cela dépend également de vos ressources (temps et argent) mais pas uniquement.
J’ai toujours pensé que l’apprentissage faisait partie du voyage.
Que maintenir une capacité d’apprentissage et d’adaptation étaient des composantes importantes.
Qu’il valait mieux maîtriser un plus petit périmètre et se poser les bonnes questions pour le faire grandir.
Qu’il était plus sécurisant d’effectuer de plus petits pas, plus souvent, plutôt qu’un pas de géant très incertain.

Si vous avez des questions, si vous souhaitez discuter de cet article, de ce projet ou de votre projet, vous pouvez écrire à photo@lanuit.paris