On a tendance à l’oublier, mais ce type de vidéo ne se prépare pas en un claquement de doigts. Le tournage lui-même a duré une journée complète (un samedi) et a réuni aussi bien l’équipe de Simple IT que des membres de la communauté du site, des collègues et des amis. Et il ne faut pas oublier le travail formidable en amont (script, scénario…) et en aval (montage, effets spéciaux…) de l’équipe de tournage !

Bien que la journée de tournage ait été intense, l’essentiel était là : nous nous sommes vraiment amusés ! Nous nous sommes dits que vous auriez aimé être là vous aussi, alors… Pour découvrir l’envers du décor, nous vous proposons un petit making of. En espérant que vous l’apprécierez autant que nous avons pris de plaisir à faire cette vidéo !

Merci à tous ceux qui ont participé : collègues, amis, membres du Site du Zéro, de Simple IT et évidemment toute l’équipe de tournage !

Hackaton au bureau !

Le hackaton du Site du Zéro, c’était :

• 9 candidats
• 1 pièce close
• 28 caméras
• 8 pizzas
• 15 fonctionnalités à mettre en ligne en 2 jours

Un sacré défi qui a donné des résultats très concrets ! Bravo à Jonathan, Vincent, Sylvain, Kévin, Alexandra, Jiyong et Romain pour le travail de dingue abattu en si peu de temps !

La carte des connaissances est en ligne sur l’accueil du site, nouveaux menus d’accès rapide aux tutoriels, lancement d’une version vidéo du tutoriel HTML5, liens de navigation entre tutoriels revus et corrigés, indication des cours recommandés pour les débutants, mise en avant des cours stars du site pour chaque thématique, signatures sur les forums, mini-biographies des membres, amélioration du système de notifications, améliorations de la pertinence de la recherche, enquête automatique de satisfaction des visiteurs et bien d’autres choses ! Tout ça est dès maintenant visible en ligne sur le Site du Zéro ! :)

Cadavres de tasses de café le lendemain matin

Parmi les speakers, beaucoup de britanniques et d’américains. Les conférences étaient donc essentiellement en anglais et dans l’ensemble plutôt techniques. On a parlé :

• Du format ePub, bien sûr, et de ses futurs développements. Bill Mc Coy, directeur de l’IDPF, était là.
• De HTML5, avec Robin Berjon du W3C, car HTML5 et ePub3 sont indissociables
• De processus de gestion des flux numériques, par Luc Audrain, responsable numérisation chez Hachette, qui manifestement ne jure que par XML !
• De gestion des métadonnées des livres
• Et quelques présentations de startups

Bill McCoy (IDPF) pendant sa conférence

J’étais dans le public parmi un public hétéroclite d’autres éditeurs et startupers. Que fallait-il retenir de l’essentiel de cette journée ? Petit résumé. :o)

La vision du futur d’ePub et HTML5

Le livre numérique est un vrai sujet aux Etats-Unis. En 2014, on s’attend à ce que 50% (cinquante pour cent) des ventes des éditeurs proviennent des livres numériques. On est loin de cela en France (bien que la situation évolue dans la même direction) mais cela montre bien l’importance prise par le livre numérique.

Bill Mc Coy voit le livre numérique du futur comme :

• interactif
• richmedia
• connecté
• dynamique et personnalisé
• créé et consommé socialement

Autant dire qu’on en est assez loin, quand la plupart des livres numériques actuels ne sont que des portages de livres papier, souvent réalisés à partir des versions PDF ! La majorité sont des romans qui ne tirent pas encore parti des possibilités offertes par ePub 3. Il faut dire que les logiciels de lecture d’ePub n’offrent qu’un support limité et insatisfaisant d’ePub 3 à l’heure actuelle.

Pour être concret, un livre numérique peut aujourd’hui prendre 3 formes :

• Un eBook
• Une application
• Un site web

Les eBooks et les sites web ont l’avantage de ne nécessiter qu’une seule source pour tous les usages, et d’être basés sur le même noyau HTML5. Le monde des applications est beaucoup plus fragmenté et nécessite de coûteux développements et des adaptations souvent longues, bien que des solutions émergent pour améliorer les choses.

J’ai appris à cette occasion que Bill Mc Coy était loin d’être un débutant : il a participé au développement du format PDF au début des années 90, et il retrouve toujours aujourd’hui des lignes de code qu’il a écrites dans le lecteur Acrobat d’Adobe !

De la technique

Comme cela semble être souvent le cas dans les conférences américaines, une bonne partie des discussions portaient sur des sujets techniques (voire parfois très techniques). Je m’attendais à des discussions à plus haut niveau autour du livre numérique, finalement j’ai été agréablement surpris que le sujet soit aussi concret.

Si la présentation de HTML5 n’avait rien de révolutionnaire (on a énuméré les nouvelles balises, la différence avec XHTML, les APIs Javascript…), il était intéressant d’avoir la vision de membres du W3C sur son évolution. J’ai notamment appris que :

•  HTML5 avait fait le choix de se séparer d’une structure XML parce que XHTML ne prenait pas suffisamment auprès des développeurs (jusque là pas de surprise) mais aussi parce que le W3C s’attend à ce qu’il y ait de futures évolutions de HTML5 qui ne puissent pas être compatibles XML. J’ai hâte de voir lesquelles.
• L’IDPF et le W3C sont conscients que ePub3 et HTML5 sont des formats proches. Ils anticipent dans le futur un rapprochement entre les deux et pourquoi pas un unique langage. Ce serait logique. Le chemin pour y parvenir n’en est pas moins sinueux et incertain et dépend beaucoup de l’adoption d’ePub3. Pour HTML5 il y a beaucoup moins de craintes aujourd’hui étant donné l’enthousiasme qu’il suscite.

Des émotions

La conférence de Peter Meyers « Beyond read-only ebooks » détonnait au milieu de toutes ces conférences techniques et a contribué à donner une bouffée d’air frais. Il nous a incité à voir plus loin que les livres numériques basés sur des romans et à imaginer des histoires avec les technologies d’aujourd’hui.

• Les histoires doivent-elles être uniquement constituées de texte ? De vidéo ?
• Doivent-elles forcément être linéaires ?
• Doivent-elles avoir une fin ?

La présentation était essentiellement visuelle avec des exemples d’histoires exploitant les technologies actuelles. Elles méritent vraiment le détour :

• http://thegoodman.cc : une histoire courte et prenante construite uniquement à base d’animations HTML5 et CSS3 sans images. Pensez à activer les sous-titres si vous n’êtes pas à l’aise avec l’anglais avant de démarrer la vidéo.
• http://pinepoint.nfb.ca : un processus narratif mêlant vidéo, texte et progression décidée par le lecteur.
• http://robinsloan.com/fish : une courte histoire sous forme d’application mobile, qu’on peut uniquement lire en avançant, jouant sur les émotions avec une couleur de fond et la typographie seulement.

Extrait de la narration animée TheGoodMan

Une annonce

Enfin, en fin de journée, Bill Mc Coy s’est fait l’écho d’un communiqué de presse que l’IDPF avait envoyé dans la journée : le lancement de la fondation Readium du lecteur ePub éponyme. Cette nouvelle fondation, lancée par bon nombre d’entreprises du secteur, vise à pousser l’adoption du format ePub 3 en proposant un moteur de lecture d’ePub de qualité, Readium. Actuellement disponible sous forme d’extension Google Chrome, il a vocation à devenir une application web à part entière et à proposer un SDK pour en faciliter l’adaptation sur d’autres plateformes.

L’annonce est étonnante et compréhensible à la fois. Imaginez : c’est un peu comme si le W3C décidait de créer un groupe de travail sur Amaya Webkit parce qu’il n’est pas satisfait de l’implémentation des moteurs d’affichage des navigateurs actuels. Avec toutes les discussions en ce moment sur la concentration des navigateurs autour de Webkit, voilà une annonce qui ne sera pas reçue sans questionnements. Mais l’IDPF a-t-il vraiment le choix ? Contrairement à HTML5, largement adopté aujourd’hui, ePub 3 doit encore faire ses preuves et percer. S’il ne le fait pas, le risque est grand qu’un format propriétaire émerge au profit d’une unique entreprise privée (non, je ne citerai pas de nom :p ).

Le sujet des DRM, attendu par de nombreux éditeurs présents sur place, a été évoqué rapidement sur certains slides. Bill Mc Coy a été assez élusif à ce sujet. Il m’a donné le sentiment, mais ce n’est que mon impression, que cela lui est imposé par les éditeurs et qu’il n’y est pas favorable au fond de lui-même. Pragmatique, il sait qu’il ne peut pas se passer des éditeurs.

C’est assez triste de sentir que l’histoire de l’industrie musicale cherche à se répéter dans l’industrie du livre. Mais je suis un éternel optimiste : tout le monde finira bien tôt ou tard par comprendre ce qui marche… et ce qui ne marche pas. ;o)

La journée était en tout cas riche en informations et en rencontres. C’était Mateo21 en direct du séminaire IDPF, à vous les studios !

Passé les premiers instants mouvementés de la transition vers la nouvelle version, ce qui nous intéresse tous est de savoir vers où l’on se dirige. Pour nous, les choses sont très claires : nous venons de poser les bases pour créer la plateforme de l’e-learning dont nous rêvons. Nous la souhaitons à la fois communautaire, multithématiques et interactive. Qu’est-ce que ça signifie concrètement ?

Evidemment, nous n’en sommes pas encore là. Mais le fait de mettre en ligne la v4 a d’ores et déjà eu les premiers effets bénéfiques que nous attendions :

• Une obligation (morale) de se concentrer sur les fonctionnalités essentielles : c’est ainsi que nous avons pu ajouter de nombreuses fonctionnalités nécessaires au bon fonctionnement de la communauté du site. Plutôt que de rajouter des fonctionnalités peu utiles, les retours de l’équipe et de la communauté nous ont incités à réaliser rapidement ce qui manquait le plus.
• Des correctifs très ciblés liés aux performances : nous avons pu repérer et corriger rapidement les plus gros soucis de performances que nous rencontrions lors du lancement. Bien entendu, beaucoup d’éléments encore pourraient être améliorés, mais le plus gros a déjà été fait.
• Une plus grande maturité pour le projet CLAIRE : confronter un projet de R&D à la réalité du terrain n’est jamais simple, nous venons d’en faire l’expérience. Mais nous sommes certains que c’est ce qui sera le plus intéressant sur le long terme. D’ores et déjà, le code a gagné en stabilité et en maturité car il a dû absorber les dizaines de milliers de pages de nos tutoriels !
• Une fusion des équipes de maintenance (de la v3) et de développement (v4) : cela veut dire tout simplement ne plus avoir 2 sites à maintenir en parallèle. Cela permet de concentrer nos efforts sur une même base de code et de ne pas se disperser.

A l’heure où j’écris ces lignes, la base de code du projet CLAIRE qui sert de socle technique aux tutoriels a énormément progressé en moins d’un mois. Il reste bien évidemment du chemin mais nous commençons à en voir le bout. C’est en bonne partie là que nous concentrerons nos efforts durant toute l’année à venir. Une grande partie du plan est écrite sur le cahier des charges du projet CLAIRE  : générateurs d’exercices interactifs, tableaux de bord pour l’auteur et pour le lecteur, annotations sémantiques, gestionnaire de contenu richmedia accessible, export multiformats… Il y a de quoi faire !

Au-delà, nous ambitionnons comme vous l’avez vu de mettre plus en lumière la section Sciences du site, avant d’en ouvrir une nouvelle liée à l’univers de l’Entreprise (comptabilité, juridique… globalement tout ce qui touche à l’entrepreneuriat). Evidemment, la section Informatique ne sera pas en reste et nous comptons sur l’attrait des outils de rédaction de CLAIRE pour voir fleurir de nouveaux tutoriels variés de la communauté !

En ce qui me concerne, 2013 marquera pour moi le retour à ma première passion à savoir la rédaction de tutoriels. Je compte attaquer au moins un tutoriel important sur le développement web cette année et me remettre activement à travailler la section Sciences puis à ouvrir les premiers tutoriels de la section Entreprise. J’ai d’ores et déjà rédigé mon premier tutoriel (le premier depuis plus d’un an !) sur Markdown… pour m’échauffer. :)

Au-delà du contenu lui-même, nous avons l’intention de travailler particulièrement les parcours d’apprentissage et les exercices d’évaluation. Nous voulons que tout le monde, en particulier les débutants, puisse se repérer par rapport aux nombreux tutoriels que nous proposons. Lesquels lire en premier ? Comment savoir si on les a bien compris ? Comment se situer par rapport au reste de la communauté ? Comment obtenir de l’aide de la part d’autres lecteurs plus avancés ? Autant de questions qui nous passionnent plus que jamais !

… et la v4 est le point de départ de tous ces projets excitants. :)

Le jour J, malgré les milliers de bêta-testeurs, la bêta privée puis la bêta publique et tous les tests effectués, le site n’a pas fonctionné comme prévu. Certes, c’est le principe d’une mise en prod’ après tout. ;o)

Que s’est-il passé ? Comment l’opération a-t-elle été vécue de l’intérieur ? Quels problèmes avons-nous rencontré et surtout quelles solutions avons-nous trouvé ?

Les grosses mises en production, on le sait, ont tendance à mettre les nerfs à rude épreuve. Celle-ci n’a pas fait exception, à la seule différence près que nous l’anticipions depuis le lancement du projet v4. En effet, l’ambition était élevée : remplacer entièrement le code du site et la structure de la base de données par une version entièrement neuve. Il s’agissait, et de loin, de la mise en production la plus complexe à laquelle nous ayons eu affaire.

En comparaison, la plupart des mises en production du site depuis les débuts étaient beaucoup plus simples :

• En 2005, lors du passage de la v2 à la v3, tout avait changé (code et schéma sql), mais à une différence majeure près : nous avions fait le choix de repartir de zéro pour les données. Les forums avaient donc été réinitialisés et seuls les principaux tutoriels (que j’avais écrits) avaient été portés un par un à la main. Un choix que nous ne pouvions plus faire sur la v4. Par ailleurs, à l’époque, le trafic était de l’ordre de 100x plus faible.
• Entre 2005 et 2012, sur la v3, il s’agissait de mises à jour incrémentielles, plus ou moins discrètes mais dans tous les cas toujours basées sur le même socle de code. Par conséquent, il ne s’agissait jamais d’un grand chamboulement et tout était progressif.

Avec la v4, nous voulions reproduire le changement majeur que nous avions fait en 2005 avec le lancement de la v3. Un lancement qui avait été difficile, je m’en souviens encore, mais duquel nous nous étions rapidement remis. Et surtout, on le sait aujourd’hui, c’est à partir de ce moment-là que le site a réellement commencé à décoller. Etait-ce le nouveau design ? La possibilité donnée à chacun de rédiger des tutoriels ? La création d’une véritable section membres, liant tutoriels, forums et messagerie privée ? La combinaison de tout cela ?
Nous n’avions pas touché juste dès le début. Le design, fade et confus au départ, avait dû faire l’objet de plusieurs mises à jour dans les mois qui avaient suivi.

Comme je l’expliquais dans le précédent billet, nous ressentions fortement le besoin de ne pas faire diverger la v3 et la v4 plus longtemps. Nous avions donc fixé le lancement à ce début janvier (le 8 janvier précisément) et nous préparions en conséquence. Malgré la quantité de choses que nous voulions faire, nous avons dû nous forcer à nous concentrer sur l’essentiel, et de ce fait à nous demander : qu’est-ce qui est vraiment essentiel ? C’est un exercice difficile, car on a souvent tendance à vouloir en faire beaucoup pour être sûr de ne rien oublier d’important, mais cela a toujours eu pour effet au final de brouiller le message et de nous disperser.

Nous avions fait le maximum pour réduire la durée d’indisponibilité du site, la migration totale des données du schéma de la v3 vers celui de la v4 pouvant prendre jusqu’à une semaine (et il n’était pas question de couper le site une semaine !). Il ne nous était nécessaire de migrer que les données les plus récentes des dernières semaines avant d’ouvrir la nouvelle version. Le serveur était prêt et configuré. Rapidement, il était complet avec le maximum de données que nous pouvions y mettre à ce stade.

Avoue, c’est toi qui a confondu le bouton de mise en prod avec celui de la machine à café !

Le « switch » s’est réellement produit lorsque nous avons redirigé les visiteurs de siteduzero.com vers l’IP du nouveau serveur. L’opération est d’une simplicité enfantine : on indique une nouvelle IP aux serveurs DNS qui font la traduction entre le nom d’hôte (siteduzero.com) et l’IP (ex : 87.90.108.100). Le changement n’est pas instantané. On dit qu’il peut prendre jusqu’à 24h, mais dans la pratique les premiers résultats commencent à apparaître au bout d’une dizaine de minutes environ.

Très rapidement, le nouveau serveur est passé du stade léthargique (0 visites, si on ne compte pas celles que nous faisions en interne pour nous assurer que ça fonctionnait bien), au stade que l’on appellera « apocalyptique ». En réalité, il était tout simplement impossible à quiconque de charger la page d’accueil. Après avoir coupé méthodiquement une à une les sections du site pour voir laquelle pouvait être la source des problèmes (et après avoir englouti une bonne dizaine de pizzas à la va-vite), nous avons finalement repéré la source de l’incident : contrairement à ce que nos recherches et tests préalables semblaient indiquer, le partage des sessions dans une base de données ne fonctionnait pas (en tout cas sur l’architecture Heroku sur laquelle nous étions basés).

Que faire ? Il nous était impossible d’utiliser un système de session PHP « traditionnel ». Dans ce mode, la machine gère elle-même les sessions en mémoire. Mais il y a un gros défaut : les sessions PHP de base considèrent qu’il y a un seul serveur. Or, avec la v4, nous sommes passés d’une architecture antédiluvienne très basique (un frontal web et un seul serveur sql pendant toute la durée de la v3, le croira-t-on !) à une architecture largement plus distribuée. Il n’y avait pas 1 serveur frontal qui récupérait toutes les requêtes mais… entre 4 et 25 selon la puissance que nous décidions de lui accorder. Ah les joies du cloud. ;o)

L’heure était déjà assez avancée mais nous tenions le bon bout. Le problème était que nous n’avions pas un million de choix pour gérer les sessions :

• Les sessions PHP de base : je viens d’expliquer pourquoi elles étaient inadaptées. Quand il y a un seul serveur, cela fonctionne très bien. A partir de 2, c’est la loterie : si en chargeant une page vous ne « tombez » pas sur celui qui contenait votre session, vous vous retrouvez déconnecté. Evidemment, on ne contrôle pas sur quel serveur sera redirigé à chaque fois le visiteur et on ne peut pas le renvoyer vers le même. C’est l’architecture cloud Heroku qui se charge de rediriger les visiteurs vers le serveur le moins chargé (et de redémarrer discrètement ceux qui auraient pu planter au passage).
• Les sessions en base de données : alors que tout indiquait que les sessions pouvaient être partagées autour d’une base de données centrale, notre expérience lors de la mise en production a révélé que cela mettait complètement à genoux le serveur SQL. Cela n’aurait normalement pas dû arriver et je suis assez certain qu’on aurait pu trouver une solution utilisant une base de données qui marche, mais nous manquions de temps à ce stade pour faire une analyse plus poussée. Nous avons donc dû écarter très rapidement l’idée d’une base de données pour les sessions.
• Les sessions dans un serveur Memcached : il s’agissait d’une possibilité offerte récemment par Symfony2.1, vers lequel nous avions migré il y a peu de temps (heureusement, sinon nous n’aurions pas pu réagir aussi rapidement !). Concrètement, un serveur spécial contenant Memcached, un système de stockage volatil en mémoire de paires de clés/valeurs, se charge de stocker les sessions. Ce type d’outil supporte beaucoup beaucoup mieux les accès concurrents qu’un serveur de base de données, et c’est précisément ce dont nous avions besoin.

En théorie, dans Symfony2, le changement de « driver » de gestion des sessions se fait très simplement dans un fichier de configuration. En pratique, il fallait quand même que nous montions un serveur Memcached… pour découvrir que celui-ci imposait l’utilisation de SASL pour chiffrer les communications avec le serveur Heroku.

Coup de froid.

Pas le choix. Il nous a fallu adapter le driver sur le champ. Le moins qu’on puisse dire est qu’il s’agissait d’un travail de haute voltige pour toute l’équipe technique à cette heure avancée. Ce billet leur est donc dédié en hommage.

Loin d’être parfaitement fonctionnel, le site pouvait alors néanmoins tourner. C’est tout ce que nous demandions avant de pouvoir aller prendre une (courte mais nécessaire) nuit de sommeil. :)

Prochainement dans « Battle of Zozor » : traversant tempêtes et ouragans, le valeureux équipage du navire SSSDZ4 mené par le capitaine Zozor sait que des cieux plus bleus les attendent au loin. Quelle est leur destination ? Quel trésor cherchent-ils ? Zozor a-t-il le mal de mer ? Vous le saurez en lisant le dernier épisode de… « Battle of Zozor » !

C’est un principe bien connu du développement : ship or die (littéralement : « livrer le projet ou mourir »). Dans le monde des startups, il est courant de sortir des versions intermédiaires d’un produit tôt (entendre « dès que possible ») pour confronter le projet à la réalité du terrain… et être ainsi plus rapidement capable de s’adapter au besoin des utilisateurs.

Bien entendu, c’est plus facile à dire qu’à faire. Qu’est-ce qu’une version intermédiaire acceptable ? En réalité, de plus en plus de personnes expérimentées du monde des startups tendent à suivre l’approche lancée par le mouvement « Lean Startup » dont le principal conseil est le suivant : dès que vous avez une version minimale d’un produit, lancez-la. Regardez ce qu’il se passe, ça ne sera en général pas ce que vous aviez imaginé. Apprenez, faites des évolutions très vite, et améliorez-vous jusqu’à ce que ça fonctionne.

C’est peu dire que prétendre que « The Lean Startup »  nous a influencé. C’était en réalité plutôt une révélation pour Pierre et moi. Une révélation de choses que nous savions déjà implicitement, mais sans être en mesure de les appliquer réellement et de les confronter à la réalité. Et la réalité, c’est que les gros projets, très ambitieux, ça ne marche pas du premier coup :

• Pensez au lancement de Free Mobile l’an dernier : beaucoup d’enthousiasme, mais aussi beaucoup de problèmes lors du lancement. Progressivement heureusement, les choses se sont améliorées, mais ça n’a pas été sans heurts. On ne crée par un réseau mobile national stable et mature d’un claquement de doigts, surtout quand des millions de personnes souhaitent l’utiliser immédiatement.
• Pensez au lancement de KDE 4 en 2008 : une toute nouvelle version du gestionnaire de bureau de Linux. KDE 3 était stable et mature, les développeurs ont décidé de tout reprendre from scratch pour créer le KDE dont ils rêvaient. Ils étaient ambitieux. Ils ont choisi de lancer une version incomplète pour stimuler l’innovation des développeurs et avoir des retours.
  « The KDE development team controversially decided to release 4.0 in a premature state in order to stimulate user interest and promote accelerated development. » - Ars Technica

Quand on n’a pas le produit parfait dont on rêve, la solution est en général toute trouvée : « passons plus de temps à tout peaufiner avant de lancer ». Ca semble tout à fait logique sur le papier, mais cela amène une autre réalité : le produit n’est pas lancé, il est retardé. D’un mois, de 3 mois, 6 mois, 1 an, 2 ans… et si, pendant ce temps, vous avez fait des suppositions erronées ? Si vous avez mis 1 an à développer une fonctionnalité qui, finalement, n’intéresse personne ou n’est pas utilisée comme vous le pensiez ? Vous prenez le gros risque de perdre 1 an de travail et de devoir tout jeter à la poubelle. Pendant cette année perdue, vous auriez aussi bien pu prendre des congés, le résultat aurait été le même.

La seule solution à ce problème est d’oser appuyer sur le bouton de lancement. Le jour J, nous avons osé le faire.

Evidemment, ce choix n’a rien d’anodin et nous en étions parfaitement conscients. Définir ce qu’est une « version finale » d’un site est en réalité impossible. Chacun a sa propre vision d’un site finalisé. Bien sûr, nous aurions toujours voulu faire plus de choses. Mais nous en avions déjà fait beaucoup en un an, et décaler la date de la sortie n’aurait fait que repousser le problème que nous avions : le projet avait besoin d’être confronté à la réalité de la production pour pouvoir évoluer rapidement et surtout dans la bonne direction en fonction des retours.

Prochainement dans « Battle of Zozor » : comment s’est passée la mise en prod dans les bureaux ? Les serveurs ont-ils pris feu ? Zozor a-t-il fait une crise cardiaque ? Vous le saurez en lisant le prochain épisode de… « Battle of Zozor » !

Evidemment, ce projet CLAIRE ne s’est pas lancé du jour au lendemain. Il y a eu en fait une année de préparation, les prémisses ayant commencé en mars 2011, soit un an plus tôt avant le lancement effectif du projet.

A cette époque, nous venions d’intégrer Cap Digital, le pôle de compétitivité de la région Ile-de-France. Disons-le tout net : c’est un endroit formidable tenu par des personnes qui le sont tout autant. C’est grâce à eux que j’ai pu rencontrer et discuter directement avec les project leaders du W3C pour le web sémantique et pour HTML5. Grâce à eux que nous avons pu nous entraîner à faire connaître notre projet auprès des fonds d’investissement du Web. Grâce à eux, enfin, que nous avons pris connaissance d’une occasion unique : un appel à projets « e-Education » lancé par le précédent gouvernement et visant à faire collaborer des laboratoires de recherche avec des entreprises.

La thématique « e-Education » correspondait parfaitement au Site du Zéro. Nous avions beaucoup d’idées pour inventer l’éducation de demain, mais trop peu de moyens et de compétences à l’époque pour y parvenir. Il fallait investir dans la R&D, le moment était idéal.

C’est pour cela que nous nous sommes acharnés, Pierre et moi, à monter un dossier en à peine quelques semaines, la deadline étant toute proche. Ce type de dossier pour répondre à un appel à projets est volumineux et conséquent. D’autres entreprises travaillant sur la même thématique ont voulu nous en dissuader, en nous disant que nous ne pourrions pas y arriver en aussi peu de temps, qu’ils y travaillaient depuis près d’un an (évidemment, nous étions concurrents)…

La tâche était immense mais, encore une fois, nous y tenions et nous avons retroussé nos manches. Pierre a pris son téléphone et contacté un grand nombre de laboratoires de recherche français en informatique pour trouver ceux qui partageraient notre vision et qui auraient des connaissances complémentaires à nous apporter. C’est dans ce contexte qu’il a rencontré le LIRIS et l’INRIA Grenoble, qui sont devenus nos partenaires sur ce projet.

De mon côté, je commençais en parallèle à rédiger la réponse à l’appel à projets, constituée de plusieurs documents. L’un d’eux pesait près d’une centaine de pages et décrivait les innovations que nous voulions créer, l’état de l’art des technologies et analysait les projets présentant des similitudes.

Finalement, nous avons pu rendre le dossier tout juste à temps (après quelques nuits très courtes, certes). Et nous avons attendu. Et attendu. Nous savions qu’entre 50 et 100 projets seraient soumis, pour une quinzaine retenus au final. Nous savions que nos chances étaient minces, d’autant plus que la concurrence était là depuis bien plus longtemps que nous, plus connectée, mais aussi tout simplement plus imposante (des grandes entreprises comme Orange pour ne citer qu’eux ont aussi soumis leurs projets). Mais nous y croyions dur comme fer et comptions sur le fait que notre motivation et notre expérience nous permettraient de nous démarquer du lot.

Finalement, début 2012, nous avons reçu une réponse… positive ! C’était une excellente nouvelle pour nous. Dans le même temps, nous venions de boucler une levée de fonds, une première pour nous. Nous allions pouvoir mener à bien nos ambitions : la v4 pour préparer le renouveau du site d’un côté, et le projet CLAIRE pour servir de terreau à notre recherche et à nos innovations.

Concrètement, la v4 et CLAIRE ont été conçues dès le départ pour être liées. En effet, CLAIRE est un projet de plateforme open source de rédaction et de consultation de ressources pédagogiques… en somme, c’est la section Vos Tutoriels de la v3, nouvelle génération ! Nous avons construit les deux afin qu’ils puissent s’interfacer. Ainsi, quand vous consultez des tutoriels sur la v4, vous faites implicitement appel au projet CLAIRE qui se charge de stocker et structurer les contenus.

Plusieurs mois de réflexion et de conception ont été nécessaires. Nous avons vraiment pu prendre le temps de concevoir de façon solide le noyau de CLAIRE. Nous avons construit un moteur sémantique et structuré, versionné, capable de gérer des branches (fortement inspiré de Git en réalité). Surtout, nous voulions que ce noyau de CLAIRE que nous lancerions en même temps que la v4 puisse servir de base à toutes les innovations dont nous rêvions. En premier lieu, nous voulions que la plateforme puisse s’adapter à tous les supports (tant actuels que futurs) et donc il ne fallait pas bêtement stocker du HTML en base. Dans CLAIRE, il y a des « titres », des « paragraphes », des « codes source », des « schémas », des « vidéos chapitrées », etc. Le tout est restitué, en fonction du besoin, soit en HTML5, soit en ePub3, soit en LaTeX et demain en PDF, ODT, Docx, audio…

Il y aura eu au final presque autant de temps de conception (d’avril à août) que de développement (de septembre à décembre) pour cette première version de CLAIRE. Nous avons pu associer les deux comme nous le souhaitions, et nous arrivions enfin à afficher des tutoriels sur la v4. Visuellement, c’était un rafraîchissement de voir les tutoriels présentés différemment. Intrinsèquement, nous avons posé des bases techniques solides pour pouvoir réaliser les innovations dont nous rêvions.

Prochainement dans « Battle of Zozor » : comment décide-t-on de lancer une nouvelle version d’un site ? Quel est le rapport entre un opérateur mobile, un gestionnaire de bureau et un site de tutoriels ? Ca fait quoi si on appuie sur ce gros bouton rouge là au milieu ?

• Quand le travail sur cette nouvelle version a-t-il débuté ?
• Comment le site a-t-il été développé et sur quelles technologies repose-t-il ?
• Pourquoi certaines fonctionnalités étaient absentes lors du lancement ? Qu’en adviendra-t-il ?

Je vais vous raconter l’histoire de la v4 et vous expliquer les choix que nous avons faits. Cette histoire étant riche en informations, j’ai choisi de la découper en une série de 5 épisodes que nous appellerons… « Battle of Zozor ».

Battle of Zozor – Saison 4 (VOSTFR)

1. V4 : génèse d’un nouveau bébé (épisode pilote)
2. CLAIRE entre en scène
3. Le bouton rouge
4. Mayday, mayday, ça marche pas !
5. Un nouveau départ

Et tout de suite, voici l’épisode 1 !

V4 : génèse d’un nouveau bébé

La v4 ? Cela fait des années que nous en parlons. Aussi loin que je me souvienne, il en était déjà question en 2009, il y a 4 ans. Le dernier plus gros changement du site avait eu lieu en 2005 avec le lancement de la v3. A l’époque, le site avait beaucoup moins de visiteurs : 180 000 visiteurs uniques par mois, contre 2,3 millions aujourd’hui. Le nombre de personnes qui visitent le site a été littéralement décuplé.

Ici, le contexte était différent. Si à l’époque du lancement de la v3 nous pouvions nous permettre de repartir sur un site totalement vierge, ce n’était pas le cas pour la v4. Des milliers de tutoriels, des millions de messages sur les forums, il était inenvisageable de repartir de zéro.

En revanche, en ce qui concerne le code, notre volonté était la même : repartir d’une base entièrement vierge. Quand on sait que les fondations de la v3 ont été posées en 2003 (à l’époque en grande partie par Pierre Dubuc, d’autres collègues et moi-même), on peut se douter qu’il n’était plus tout à fait en phase avec les bonnes pratiques qui ont évoluées. Certes, nous avions une architecture MVC, c’était déjà ça. Mais ça s’arrêtait là : nous ne reposions sur aucun socle technique commun (les frameworks PHP étaient inexistants à l’époque), aucune bonne pratique qui pourrait permettre au code d’être facilement modifié par une dizaine de personnes en même temps. Ne parlons pas de la réusabilité, des tests unitaires ni même d’une quelconque charte graphique : il n’y avait rien de tel sur la v3.

Bien entendu cela n’empêchait pas le site de « fonctionner ». Mais au fil du temps, nous voulions aller de plus en plus loin. Tester de nouvelles façons de promouvoir les interactions entre les auteurs et leurs lecteurs. Valoriser les membres qui s’impliquent. S’ouvrir à de nouvelles thématiques qui nécessitent de nouvelles méthodes d’apprentissage. Tout cela était devenu extrêmement compliqué à cause essentiellement de l’architecture du code qui était devenue trop faiblarde par rapport à nos ambitions. Eh oui, il ne suffit pas de construire un site en MVC pour le rendre maintenable d’un claquement de doigts. S’il y a bien une chose que nous avons appris au cours du temps, c’est ça.

L’idée était donc de commencer par partir sur un socle technique solide. Pour cela, nous avons dans un premier temps envisagé de migrer en douceur le code de la v3 et de l’adapter au framework Symfony (v1.4 à l’époque). Cela fonctionnait mais tenait par deux bouts de ficelles. Nous avions pu migrer les sections les plus simples du site, mais arrivés aux colosses qu’étaient les forums et le module de rédaction de tutoriels, nous avons dû nous rendre à l’évidence : cela ne pourrait pas se passer en douceur et il allait falloir sacrément se retrousser les manches. Bref, repartir complètement de Zéro au niveau du code source. On ne fait pas un git init tous les jours.

Le projet v4 était né. C’était en janvier 2012.

Le framework Symfony2 venait d’être lancé il y a peu et c’était une occasion idéale pour nous de partir sur de nouvelles bases. Cependant, nous savions que pour réussir nos ambitions, il faudrait faire un véritable bond technique. Pour y parvenir, il nous faudrait une équipe technique plus importante, avec en particulier des personnes qui ont des expériences variées dans différents types d’entreprise. C’est dans ce contexte que nous avons notamment cherché à lever des fonds mais aussi à nouer des partenariats avec des chercheurs expérimentés sur les problématiques que nous rencontrions.

Le projet CLAIRE était né. C’était en mars 2012.

Prochainement dans « Battle of Zozor » : qui est CLAIRE ? Que veut-elle au Site du Zéro ? Qui sont ces mystérieux chercheurs en informatique ? Zozor choisira-t-il d’utiliser Doctrine2 ou Propel ?
Vous le saurez en lisant le prochain épisode de… Battle of Zozor !

Si les problèmes que l’on rencontre actuellement sur la v4 ne sont pas totalement une surprise (nous nous attendions à en rencontrer), l’état dans lequel se trouve le site aujourd’hui n’est pas satisfaisant. Il ne l’est pas plus pour vous qu’il ne l’est pour nous. Pour cela, nous tenons à vous présenter des excuses et surtout des explications.

Le point sur les problèmes en cours

Plusieurs questions reviennent régulièrement dans les messages que vous nous avez envoyés. Voici des explications aussi détaillées que possible :

• Les erreurs 500 : celles-là, on pourra dire qu’on les aura vues ! Cela signifie que le serveur n’a pas été capable d’exécuter votre requête. Les raisons peuvent être multiples et il est délicat de toutes les identifier. Ce n’est en général pas une erreur dans le script (la bêta-test nous aurait permis de nous en rendre compte avant) mais souvent un problème d’optimisation. Et c’est un cercle vicieux : plus ça s’emballe… plus ça s’emballe ! Heureusement nous avons pu assez bien stabiliser les choses sur l’ensemble du site, le plus gros des soucis des erreurs 500 restant sur la section « Tutoriels » (pas de pot, c’est le coeur du site !). Concrètement, quand vous lisez un tutoriel, vous faites appel à la plateforme CLAIRE qui s’exécute sur un autre serveur et répond par API. Or, si CLAIRE met trop de temps à répondre, le SdZ s’impatiente et renvoie une erreur 500.
  

  Les projets SdZ et CLAIRE communiquent entre eux par API

  Nous avons réduit le problème au maximum en mettant en cache les pages des tutoriels (inutile de faire appel à CLAIRE à chaque fois !). Pour le moment nous utilisons une solution à base de memcached-sasl, et nous réfléchissons à mettre en place des ESI (Edge Side Includes) qui sont bien adaptés pour nous vu que nous utilisons Symfony2.

• Les anciens messages absents des forums : nous avons travaillé plusieurs mois en amont pour faire en sorte que les anciens messages des forums soient présents dès le lancement de la v4. Et ils l’étaient. Seul problème, de taille : les nouveaux forums ne tenaient pas suffisamment la charge avec tous ces millions de messages et toutes les visites. Nous nous sommes en effet trop reposés sur l’ORM Doctrine2 sans veiller suffisamment à l’optimisation des requêtes. Résultat : si les nouveaux forums étaient plus solides dans leur construction technique, ils étaient tout simplement inutilisables sur un site aussi gros que le SdZ. Nous avions fait des tests de charge avec une base pleine, mais pas avec des milliers de visiteurs qui naviguent aléatoirement sur une base pleine. Le choc a été rude et nous avons dû nous rendre à l’évidence : il allait falloir reprendre toutes les requêtes une à une et les optimiser… ce que nous avons commencé à faire dès le jour de la sortie de la v4.
  A un moment nous avons été confrontés à un choix :
  • Option A : couper entièrement les forums le temps de les optimiser (estimation : deux bonnes semaines), et les rouvrir avec tous les messages d’un coup. Cela signifiait pas de forums du tout pendant un moment.
  • Option B : ouvrir les forums avec le code actuel mais sans les millions de messages, pour que les visiteurs puissent quand même poser leurs questions et réagir.

  Nous avons fait le choix de partir sur l’option B, plus sûre. En effet, elle vous permettait d’utiliser les forums (car ils fonctionnent bien tant qu’il n’y a pas des millions de messages) et nous permettait de notre côté d’ajouter petit à petit les anciens messages des forums au fur et à mesure des optimisations de code, afin de vérifier que le tout tient bien la charge. A l’heure où j’écris ces lignes, tous les messages des forums « Autres langages » et « Vos études » sont passés. Les autres forums arrivent.

• Les news : plusieurs personnes ont cru que nous avions choisi de retirer les news du Site du Zéro sur la v4. Les choses sont plus subtiles que ça, et nous en parlions avec les newsers du site depuis quelques mois. C’est vrai, il n’y a pas de module de news sur la v4 et nous ne souhaitons pas en coder un. Cela ne veut pas dire que nous ne voulons pas rédiger sur des sujets d’actualité mais plutôt que nous voulons concentrer nos efforts sur un seul outil de publication de contenus : le projet CLAIRE. Plutôt que de gérer un outil de rédaction de news d’un côté et un outil de rédaction de tutoriels de l’autre, de même que deux processus de validation différents, nous avons fait le choix de les unifier dans CLAIRE.
  Concernant le contenu des news, nous avons fait un constat qui nous était rappelé depuis longtemps par la communauté : nous ne sommes pas faits pour publier des brèves sur l’actualité. Des dizaines de sites sont meilleurs que nous là-dessus et ils emploient des journalistes à plein temps pour ça : PC INpact, Clubic, 01net, Tom’s Guide, Frenchweb… la liste est longue. A chaque fois que nous publiions une brève, les reproches étaient les mêmes : « c’est trop court », « pas assez expliqué »… quand ça n’arrivait tout simplement pas trop tard. Soyons clairs : nous ne pouvons pas lutter et ne souhaitons pas lutter contre des sites qui emploient des journalistes pour parler de l’actualité high-tech. Notre spécialité, ce sont les explications, les sujets de fond. Les news qui marchaient le mieux étaient en réalité de véritables articles (ce que certains sites comme PC INpact appellent eux des « dossiers »). Nous avons donc fait le choix de nous recentrer là-dessus et de permettre aux membres de rédiger des articles sur l’actualité, exactement comme les « news » de la v3, que nous pourrions ensuite mettre en avant (notamment via le slideshow, dans la newsletter, etc.). Pour cela, les membres utiliseront les outils de rédaction de CLAIRE. Ce qui nous amène au point suivant…
• La rédaction de tutoriels et articles: nous avons choisi de nous concentrer sur ce qui fait notre spécificité, à savoir les tutoriels et les articles de fond. Oui mais… comment fait-on pour rédiger des tutoriels me direz-vous ? A mon grand dam, à l’heure où j’écris ces lignes, on ne peut pas encore. En fait, nous avions fait des prototypes de CLAIRE permettant une rédaction basique sur des petits contenus (équivalent de mini-tutoriels). CLAIRE gère déjà les branches, le versionnement de chaque élément d’un tutoriel, etc. Il manque cependant deux choses :
  • Une interface (au moins basique pour commencer) : nous sommes en train de la développer en ce moment même.
  • Des performances : nous avons déjà beaucoup optimisé la vitesse de lecture d’un tutoriel mais nous pouvons encore aller plus loin pour que l’édition de tutoriels soit elle aussi suffisamment rapide.

  C’est pour nous très important de proposer une première interface de rédaction dans les semaines qui viennent.

• Les tutoriels qui ne fonctionnent pas : c’est le cas de certains tutoriels (heureusement une minorité) comme J2EE et PHP POO. Nous avions testé plusieurs tutoriels différents lors de la préparation de la migration (qui est complexe, car elle passe d’un contenu non structuré à un contenu fortement structuré dans CLAIRE). Malheureusement, quelques tutoriels avaient une spécificité bien précise que nous n’avions pas vue et que CLAIRE ne supporte pas : des titres dans leur introduction. Il faut savoir que CLAIRE se base sur les niveaux de titre de HTML5 pour structurer le cours (en parties, chapitres…) et un titre de niveau 3 ou 4 avant un titre de niveau 1 et 2… ça fait des chocapic. Heureusement le problème est bien identifié et est en cours de résolution.

Quelles leçons en tirer ?

Je suis convaincu qu’il est un peu tôt pour vraiment tirer les leçons de la v4 et de son lancement. Nous avons prévu quelques jours de pause avec toute l’équipe dans quelques semaines pour justement faire le point sur ce que nous avons fait et nous organiser pour être meilleurs en 2013 !

Voici quelques pistes cependant en attendant peut-être un autre billet plus à tête reposée sur le sujet :

• Ajuster notre ambition : était-elle trop haute ? Nous avons voulu faire beaucoup de choses à la fois : remettre le site entièrement à plat, sans garder une ligne de code, et lancer en parallèle un projet de R&D avec des chercheurs répartis aux 4 coins de la France, en faisant en sorte que le noyau du projet soit utilisé dans la v4 dès son lancement.  C’est costaud, très costaud. Je crois sincèrement que nous avons bien fait de fixer la barre très haut et que nous ne le regretterons pas au final.
• Faire plus de tests de charge : je pense que c’est un sujet où nous aurions pu être meilleurs et pour lequel nous avons manqué de connaissances et d’expérience. Nous avons certes testé le site avec des millions de messages, mais pas avec des milliers de visiteurs naviguant sur des millions de messages, dans des conditions aussi proches que possible de la prod. C’est donc un domaine où nous devrons nous améliorer en 2013.
• Sortir des versions intermédiaires qui marchent encore plus tôt : c’est probablement LE point principal. Il faut éviter autant que possible d’avancer dans des projets sous-marins trop longtemps sans qu’ils ne passent en production. Là, malgré la bêta, nous avons quand même travaillé un an à près de 10 personnes en moyenne sans que le projet ne voie le jour en prod. C’est long. Très long. Surtout pour l’équipe qui y travaille. C’est une des raisons pour lesquelles nous avons souhaité lancer la v4, malgré les potentiels problèmes, car nous ne pouvions pas rester dans l’ombre plus longtemps. Pourtant, je suis persuadé qu’il aurait fallu trouver un moyen de lancer le site plus tôt, en nous concentrant mieux sur les fonctionnalités les plus importantes.
• Faire des transitions douces autant que possible : c’est un des points les plus compliqués, à mettre en relation avec le précédent. En effet, avec la v4, nous avons tout changé : tout le code, le framework, la structure d’hébergement (nous utilisons Heroku), l’architecture technique, etc. Ca fait beaucoup de paramètres qui changent d’un coup et autant de bonnes raisons de rencontrer des problèmes. Nous aurions aimé faire une transition plus progressive. Nous n’avons pas vu comment faire. A l’heure actuelle, je ne vois toujours pas comment on aurait pu faire autrement (mais peut-être que cela viendra dans quelques semaines avec les idées plus claires !). En attendant, la transition n’a pas été douce mais je pense sincèrement que c’était un mal nécessaire que nous ne regretterons pas sur le long terme. :)

J’espère que ce billet vous aura permis d’y voir plus clair ! Si vous avez des questions n’hésitez pas à les poser, je ferai de mon mieux pour y répondre.

Vous avez toutes nos excuses pour les désagréments que cela a occasionné. Sachez que toute l’équipe est mobilisée pour résoudre au plus vite les problèmes cités ici. Vous pouvez avoir des informations régulièrement mises à jour sur cette page.

Sachez par ailleurs que j’ai préparé pour ceux que ça intéresse une série de billets pour raconter la génèse de la v4, les raisons de son lancement et comment celui-ci s’est déroulé à nos bureaux. A très bientôt ! :)

L’aventure du Site du Zéro

Le Site du Zéro est pour moi une aventure de longue date : lancé en 1999 à l’origine pour aider quelques amis du collège à apprendre le HTML, le « site perso » a grandi, s’est étoffé de nouveaux tutoriels et une communauté d’un demi-million de membres s’est formée ! Passer de 200 à plus de 2 millions de visiteurs par mois en quelques années est vraiment une aventure unique.

A ceux qui me demandent parfois si j’avais anticipé que cela prendrait cette ampleur, la réponse que je donne à chaque fois est : « évidemment non ». :o)
Non le site n’a pas été créé pour devenir une référence dans le e-learning, mais juste pour aider des amis proches. Et si le site a atteint la notoriété qu’il a aujourd’hui, je suis convaincu que c’est parce qu‘il aide réellement des milliers de personnes et que nos efforts pour le faire évoluer ont été constants. Nous l’avons maintenu en parallèle des études et avons ensuite créé Simple IT, l’entreprise qui fait vivre le Site du Zéro, avec mon associé Pierre Dubuc.

La v4, un nouveau départ

La plupart du temps, un site évolue de façon progressive. C’est l’avantage du Web : on peut mettre en ligne des petits changements régulièrement. Une page remaniée  par-ci, une image par-là, etc.

En revanche, le changement qui vient d’apparaître ces jours-ci n’est PAS une petite nouveauté traditionnelle. Comme je l’indiquais en introduction, c’est le fruit d’un an de travail pour réimaginer le Site du Zéro. Nous sommes partis d’une page blanche. Nous n’avons pas gardé une seule ligne de code. Nous avons pris le temps de vider nos esprits et de nous demander : si on créait le Site du Zéro aujourd’hui, à quoi ressemblerait-il ?

Pourquoi tout changer d’un coup ? Après tout, l’ancienne version marchait très bien en apparence. La réponse complète à cette question serait assez longue mais je compte bien vous la détailler dans un prochain billet. En attendant, je peux vous en donner la version courte : nous savions que nous avions besoin d’une nouvelle base pour créer la plateforme d’e-learning de demain. Nous avons en effet tellement appris pendant ces 13 années d’existence du site que nous avons petit à petit commencé à nous faire une idée précise d’où nous voulions aller. De ce que nous pouvions faire pour innover et contribuer à changer le monde. Et nous savions qu’avec l’ancienne version du site, la v3, nous ne pouvions pas y arriver. Nous avions besoin de ce nouveau départ.

C’est pour cela que nous avons lancé un projet de R&D ambitieux en parallèle de la v4 : le projet CLAIRE. Trois groupes travaillent dessus : deux laboratoires de recherche en informatique (LIRIS et INRIA) et Simple IT. Le projet a pour but de créer la plateforme d’e-learning de demain. Pour le Site du Zéro, c’est très important car CLAIRE est le programme qui fait fonctionner les tutoriels de la v4 du Site du Zéro. Pour le communauté, c’est aussi très important car c’est un projet qui sera diffusé en open-source dans l’année et auquel tout le monde pourra contribuer.

Le projet est loin d’être terminé, vous n’en voyez en fait que les premières briques sur le site. Toutes les nouveautés développées sur CLAIRE apparaîtront immédiatement sur le Site du Zéro. Pour le projet, c’est une occasion rêvée d’avoir des retours, de tester ses usages, de vérifier qu’il fonctionne bien et qu’il est réellement utile ! C’est aussi une façon de vérifier qu’il tient bien la charge sur un site à fort trafic (et à l’heure où j’écris ces lignes, ce n’est pas franchement le cas, mais nous travaillons très dur pour corriger ça rapidement ! ;o).

Remerciements

La v4 que vous voyez actuellement en ligne est donc le début du renouveau de ce Site du Zéro qui nous tient tant à coeur… à Pierre et moi les premiers évidemment, car nous sommes investis depuis très longtemps dans l’aventure (nous travaillons ensemble sur le site depuis 2003 !), mais aussi les 27 personnes de l’équipe de Simple IT et évidemment toute la communauté du Site du Zéro, cette communauté qui est le site.

Je souhaite remercier chaleureusement toute l’équipe technique qui n’a pas ménagé ses efforts pendant cette année 2012 intense : Romain, Sylvain, Kévin, Jiyong, Adrien, Jonathan, Alexandra, Isabelle, Vincent, Vincent, Vincent et Vincent (non ce n’est pas une erreur) ; merci aussi à toutes les autres personnes de l’équipe de Simple IT qui ont participé de près ou de loin à cette nouvelle version : Zeina, Jonathan, Anna, Laetitia, Cécile, Yohann, Christophe, Marie, Charlotte, Virginie, Valérie, Radouane, Pedro… et bien évidemment Pierre !

A très bientôt pour un nouveau billet !
S’il y a des éléments dont vous aimeriez que l’on parle à propos du site et de la v4, n’hésitez pas à nous l’indiquer dans les commentaires !