Treize ans d’évolutions du web en une seule mise à jour : l’histoire de Numerama

Baptiste M.
Numerama Backstage
Published in
8 min readOct 12, 2015

Hello, my name is Baptiste. Je suis co-fondateur de Humanoid et voici l’histoire de la seconde jeunesse de Numerama.

Baptiste et Jérémie

Pour expliquer comment est née cette nouvelle version de Numerama, il faut une intro à la «Amicalement vôtre». C’est parti !

FrAndroid est né en 2007

Tout commence en 2007, en pleines brumes alcooliques estudiantines lorsque, j’ai fondé avec des amis FrAndroid.com. À l’époque où l’on s’extasiait sur Fon et OpenWRT, FrAndroid n’était qu’un petit blog de veille sur une thématique que l’on sentait pleine de promesses.

Au fil des années, le petit blog est devenu grand, l’équipe s’est professionnalisée et un groupe média indépendant en est né, Humanoid. J’ai suivi l’évolution de ce dernier : je suis devenu a̶d̶u̶l̶t̶e̶ grand, nous l’avons professionnalisé, je suis aujourd’hui son président, mais surtout son CTO. ;)

Numerama, le sage du web est né 5 ans plus tôt

En 2002. À l’époque, Ratiatum, c’était son nom, se crée sur les convictions que des bouleversements technologiques sont à l’œuvre et vont avoir une incidence de plus importante sur nos vies et sur notre société.

Guillaume, son fondateur, a inculqué à son média des valeurs importantes et dans lesquels je me reconnais : indépendance, intransigeance sur la qualité, rigueur…

On s’est rencontré, on s’est regardé et la magie est née ;), Guillaume raconte d’ailleurs cette rencontre dans son histoire.

Cette rencontre, on la veut ambitieuse pour le paysage médiatique francophone.

Julien et Ulrich ont leurs formules secrètes ? Moi aussi. Et cet article est là pour en parler !

Plongeon dans la tambouille Humanoid

Chez Humanoid, l’équipe technique, c’est un peu notre marque de fabrique. Là où des médias mettent des années à faire une refonte, ou en imaginer une qui ne vient jamais, nous aimons itérer rapidement. Dès que nous avons une nouvelle idée, nous la développons et la testons.

Ivan et Jérémie au travail

Ces évolutions, rapides et régulières sont essentielles : elles font vivre nos sites ; elles montrent que nos sujets ne sont pas bloqués dans un autre espace-temps que celui du lecteur ; elles montrent que l’on prend soin des lecteurs et de leurs avis d’utilisateur.

Romain sur sa tablette graphique

Le dernier point est l’un des plus important. Un média doit investir au moins autant sur ses pages (d’un point de vue éditorial comme d’un point de vue technique) que ses lecteurs investissent par leur temps, par leurs commentaires, par leurs partages ou par leurs contributions (articles de blog, posts sur le forum, etc.).

La recette

Avoir une équipe, c’est bien. Avoir une bonne équipe, c’est mieux. Mais pour bien bosser, il faut savoir bosser ensemble !

Humanoid travaille selon une version allégée de la méthode Scrum, la reine des méthodes agiles.

Nous découpons le temps en sprints, de petites itérations de développement pour lesquelles on définit des livrables à l’avance que l’on pourra tester à la fin.

Leur durée est la plupart du temps d’une semaine car il est facile, dans le web, d’avoir en quelques jours des livrables montrables et testables. Les sprints courts nous permettent une grande flexibilité puisqu’il est plus facile de remettre en question une fonctionnalité qui a pris une semaine qu’une fonctionnalité qui en aurait pris deux ou trois.

Chaque matin a lieu le scrum. C’est une petite réunion où nous échangeons sur les problèmes (et les solutions) du jour car, non, en entreprise, échanger sur les problèmes que l’on rencontre n’est pas spontané. On se dit donc ce qu’on a fait la veille, ce qu’on fera aujourd’hui et sur quoi on bloque. C’est comme ça qu’on ne reste pas bloqué toute une semaine sur un bug, aussi coriace soit-il.

Lecteur gestionnaire, lecteur développeur, lecteur scrum master, tu te demandes probablement comment nous organisons nos tâches de développement. Ma réponse va sûrement te surprendre : un bon vieux Trello des familles. Est-ce que c’est parfait ? Non, bien sûr que non. Est-ce que ça fait tout ? Non plus. Mais sa richesse est dans sa simplicité : tout le monde sait instinctivement l’utiliser. Et donc, tout le monde l’utilise, parce qu’expliquer comment on met une estimation à jour dans une tâche sans user-story, mais déjà dans un sprint, c’est pas mon boulot.

12 000 lignes de PHP/HTML, 4 300 lignes de JS, 6 000 lignes de SCSS … produites en 3 mois.

J’ai par contre choisi avec plus grand soin les outils de dev :

Hipchat pour une communication plus simple, et pas Slack. Parce que les différences entre les deux solutions peuvent s’écrire sur un ticket de métro parisien et que je peux payer une pinte par semaine à tous mes devs avec la différence de prix. Bitbucket et git pour l’échange et le versionning de code, et pas GitHub. Parce que les prix de GitHub pour les entreprises ressemblent à une faute de frappe.

Ces outils permettent à l’équipe technique de fonctionner sous la forme de pull request :

Chaque fonctionnalité est développée séparément des autres (dans une “branche”), puis ajoutée à la base de code, mais seulement après avoir été relue et approuvée par un autre membre de l’équipe.

Commits par auteur sur le repos principal

Ce fonctionnement a deux objectifs :

  • Il assure une qualité de code constante : un média n’est pas un produit avec une date de péremption, mais un service qui devra évoluer sur de (très) nombreuses années.
  • Sur chaque fonctionnalité développée, la connaissance est partagée au sein de l’équipe.

Nous utilisons également Vagrant pour des environnements de développement reproductibles, et Ansible pour tout ce qui est provisionnement de machines (déploiement de configuration). L’objectif est qu’on ne perde pas une journée à installer un environnement de développement. On ? C’est toi, jeune recrue, mais pour l’instant, c’est surtout moi.

Enfin, gulp nous permet de lancer la compilation du JavaScript et du CSS (qui est bien évidement écrit en SASS). L’ensemble de nos sites tourne sur des serveurs hébergés par Online (des grosses Dedibox ENT sous Proxmox) et nous réalisons l’administration nous-mêmes.

Ces choix ne sont pas parfaits. Ils ne sont peut-être pas les meilleurs.

C’est là que vous vous attendez à lire « mais ce sont les nôtres », mais ce n’est pas de ça non plus dont il s’agit. Ces choix ne sont pas le fruit d’une politique IT menée par le CTO mais par de nombreuses itérations, plusieurs expériences et le travail d’une équipe. De fait, ils évolueront.

Comment cette recette s’applique à Numerama ?

J’ai commencé à travailler en avril sur le code de Numerama. L’une des premières étapes a été la mise à jour de l’hébergement selon notre savoir-faire (plus performant et surtout moins coûteux). Nginx a remplacé Apache dans l’optique d’ajouter du cache, ce qui n’a pas été facile au vu du nombre de règles de réécriture.

Le code de Numerama avait mal évolué. Il sent parfois la naphtaline, parfois le duck tape et nous y avons trouvé des horreurs qui s’y étaient accumulées avec le temps. La façon d’écrire du code pour le web a bien changé ces dernières années. Les frameworks (Ruby on Rails, Symfony) sont arrivés, imposant une qualité de code, et les développeurs ne voudront plus revenir en arrière. L’époque où l’on faisait un site from scratch (à partir de rien) est révolue. Aujourd’hui, même « bootstraper » un site signifie utiliser un framework.

// TODO Update Here in 2012 … oups, on est en 2015

Il faut dire que, comme FrAndroid à ses débuts, Numerama ne disposait pas de ressources techniques à plein temps. Tout ce vieux code a dû être compris, assimilé dans ses particularités, pour pouvoir écrire les scripts de migrations entre l’ancien Numerama et le nouveau. Car il faut être bien clair là-dessus : pas une ligne de l’ancien site n’a été gardée.

Pour la partie média, rien ne fait mieux le boulot qu’un bon vieux Wordpress. Wordpress présente de nombreuses qualités : une base de code en constant développement ainsi qu’un écosystème extrêmement riche avec de nombreuses places de marché où l’on trouve des plugins de toutes les qualités. Les développeurs qui maîtrisent cette plateforme ne sont pas rares. Et, chose importante, c’est aussi une plateforme que connaissent bien les journalistes qui sont les premiers utilisateurs… que je n’aurais pas à former.

À nos yeux, Wordpress a quand même un paquet de défauts : l’architecture interne commence à accuser le poids des années, et tout est tourné vers l’utilisateur, pas vraiment vers les développeurs. Nous avons donc sélectionné themosis, un framework qui apporte une base solide aux développements. Inspiré de Laravel et de Symfony, ce framework apporte nombre de fonctionnalités indispensables pour un développement moderne. Un simple exemple : la gestion des environnements. Grâce à themosis nous avons un environnement de développement, de test et de production.

Tout n’a pas été facile

Un site ne vit que grâce à ses lecteurs. Pour qu’ils deviennent une communauté, il faut faciliter les échanges.

Les rencontres FrAndroid : Bardroid

Pour la partie discussions, il fallait quelque chose qui soit résolument moderne et tourné vers l’avenir. Il était inconcevable de retourner vers un forum façon PhpBB : nous sommes en 2015 !

Après plein d’essais, Discourse a semblé être le système le plus prometteur.

Hélas il ne s’intègre pas encore bien en tant que système de commentaire de Wordpress. Peu importe : nous avons réalisé ce travail d’intégration, de synchronisation et de connexion unifiée. À terme, on pourra commencer une discussion à partir d’une phrase d’article ou d’une idée commencée dans un commentaire.

Beaucoup de temps a également été passé à la réalisation de certaines fonctionnalités assez simples comme ce que nous appelons l’« infinite scroll » (défilement continu), qui permet de lire tous les articles sans jamais changer de page. C’est une fonction complexe qui touche à la fois à l’ergonomie générale, la gestion des affichages publicitaires, le cache et l’historique du navigateur… et tout cela doit être géré parfaitement pour ne pas perdre le lecteur.

Une équipe technique au service du média, du rédacteur au lecteur

Tous ces efforts sont bien évidemment faits en interne. Proposer une expérience média confortable pour le rédacteur comme pour le lecteur, c’est le métier d’Humanoid. Il nécessite des développeurs, des designers UX et UI, des chefs de produits marketing autant que des journalistes ou encore des gestionnaire de communautés.

J’espère que cet article vous aura donné une bonne vision d’ensemble de ce que Humanoid fait autour de FrAndroid et de Numerama.

Vos commentaires sont les bienvenus. Vos candidatures aussi :).

--

--

Baptiste M.
Numerama Backstage

Co-fondateur d'Humanoid, société éditrice de FrAndroid et de Sidereo - solution mobile pour l'entreprise. #veille #web #dev #apps