jan 28

Le coup du mailing…

Alors voila…

Imaginons que la cellule marketing d’un client décide unilatéralement d’une super offre marketing. (ca n’arrive jamais rassurez vous, c’est dans un monde imaginaire)

Elle envoie un gros mailing pour soutenir le feu mais… Oublie de prévenir l’IT ou son hébergeur (pareil, c’est totalement utopique, toute ressemblance avec des faits réels serait fortuite). Forcément, le site monte dans les tours.

La solution

L’hébergeur et le DSI détecte le problème et se mettent d’accord, on lance trois machines en Cloud et là, le problème est résolu :) Merci Extend To Cloud.

Les ventes marche, le client est content, on va tous manger, satisfait de ce devoir accomplit.

Le vrai drame

Quand tout à coup… Entre en scène M. X et il appuie sur le bouton « Flush Magento cache », sans raison particulière, juste pour être sûr, parce que dans le doute, l’humain curieux explore tout son potentiel de liberté et que c’est aussi un peu cela le fameux « développement personnel », cliquez là où on veut, quand on veut !

Alors là, forcément, c’est pas la même…

Les serveurs ne disposent plus de leur cache, le drame arrive inexorablement. Une plateforme sans son cache chaud (hot cache) est 2 à 3 fois moins performante. Bilan, les utilisateurs en surfant vont petit à petit réchauffer le cache et générer les pages statiques mais ca demande de la ressource, le système rame.

Le drame « visuellement » parlant

Sur le Graph ci-dessous, lié au CPU de la machine qui sert la base de données, la barre nommée 1 montre le début du mailing et la barre nommée 2 montre le début du vidage de cache. (bien sur c’est un graph totalement hypothétique vous l’aurez compris)

Clairement, durant le mailing, on monte en charge mais ca tient bien. Dès que le bouton magique est pressé, la machine consomme 2 à 3 fois plus de CPU et se met à ramer.

La Conclusion

Si je ne l’ai pas dit cent fois, je ne l’ai jamais dit, mais informer, c’est aussi répéter :

  • On ne vide JAMAIS le cache en production sans raison
  • On ne vide JAMAIS le cache lors d’un pic de trafic type solde ou d’un mailing
  • On ne met jamais un nouveau site en production avant un pic (ce qui implique un vidage de cache)
  • Faire du développement personnel ne passe pas forcément par le fait de cliquer sur tous les boutons et particulièrement sur le bouton « Flush Cache »

D’une manière générale, avant d’appuyer sur le bouton magique qui provoque l’armaggedon, on en discute, on se pose la question de pourquoi on le fait, on vérifie si c’est indispensable, si c’est le seul moyen et dans le doute on en le fait pas.

Ce n’est pas une solution magique mais une solution de dernier recours. Un site en « cold cache » c’est atrocement lent pour les visiteurs et atrocement lourd pour les serveurs. J’ai même vu des setup ou les gens vident les caches en Cron toutes les heures, d’autres où sont lancé des réindexation de base de données plusieurs fois par jour…

Tout cela contribue à tuer les performances et là, pour le coup, Magento n’y est pour rien et n’y peut rien.

écrit par Philippe Humeau \\ tags: , , , , ,

jan 25


teaser_bargento_v2_CS3 par nbs-system

C’est un peu tôt pour parler des détails complets mais nous allons révolutionner un peu le modèle avec la team. Le dernier Bargento 5 a été un succès par sa fréquentation mais le format avait trop peu évolué à mon goût et nous avons eu de nouvelles idées qui peuvent transformer l’évènement.

Où cela se déroulerait il ?


Pour le moment, nous (Xavier, Gabriel, Nicolas et moi) envisageons de le faire de nouveau à CAP15. La salle est couteuse mais très pratique, bien située et propose des prestations techniques de qualités. C’est donc une option probable.

Changement de fréquence


La fréquence de Bargento devient annuelle. Cela permettra de mieux organiser et de faire des évènements un peu plus gros, de se positionner uniquement sur le premier semestre car le second est très chargé et de maintenir un intérêt du public.

De plus, Magento Inc va organiser son propre évènement, Imagine, en Europe également. Celui-ci se situera au second semestre, à priori en septembre. Bien que la cible, l’organisation et la fréquentation seront différentes, nous avons convenu que les évènements nationaux auraient lieu sur le premier semestre et celui de Magento sur le second.

Bargento aura donc lieu annuellement, au premier semestre, en général fin Mai autant que possible.

Quand aura t’il lieu ?


Nous avons pour le moment réservé la date du 30 mai 2011. Il est peu probable qu’elle change mais rien n’est pour le moment totalement confirmé car je fais le point avec nos fournisseurs au niveau des dates.

Les nouveautés


Ce qui va changer en quelques lignes :

  • moins de stands
  • plus d’ateliers / tables rondes
  • autant de conférence mais plus guidées en thème
  • un réseau wifi fonctionnel :)
  • un espace démonstration / découverte plus poussé
  • quatre espaces (si on peut) seront définit découverte/freelance-communauté/technique-developpement/grands projets
  • Une ouverture aux autres technos opensource connexes (openerp, sugarcrm)
  • Un système de ticketing/VIP/nourriture mieux organisé
  • Un retour à des threads et ateliers « hardcore technique », orientés développeurs

Si vous avez des propositions, elles sont les bienvenues, n’hésitez pas à nous les envoyer à contact[à]bargento.fr

écrit par Philippe Humeau \\ tags: , , ,

jan 23

Après plusieurs mois de travail, on peut commencer à en parler car Nitrogento va enfin voir le jour !

Depuis trois ans, NBS System s’est spécialisé dans l’hébergement de Magento, WordPress et Drupal, cela m’a donné l’occasion de faire de nombreuses conférences, pendant les Bargento notamment, sur la performance et l’optimisation. Ce blog en est d’ailleurs le reflet, j’y ai souvent distillé des conseils sur ces sujets.

Mais nous avons voulu aller plus loin en mettant sur le marché une extension qui boost les performances de Magento. Les points clefs sont connus mais cela nécessitait beaucoup de travail. Voici donc un avant goût de Nitrogento, de son contenu et de ses performances.

Voici les quelques questions qui se posent probablement à la lecture de ces lignes :

Qui

J’ai commandité (par NBS System) la création d’une extension Magento auprès de L’academy et de l’Agence DnD.

Les deux maîtres codeurs derrière ce petit bijou sont essentiellement Matthieu Bouchot (Academy) et Aymeric Aitamer (Agence DnD). J’ai conçu le cahier des charges et demandé les fonctionnalités, la réalisation des caches (FPC / Bloc / Custom Bloc) a été faite par Matthieu, les CDN /Minify/Sprite et l’admin en Back office par Aymeric.

Ce sont des experts dans le domaine Magento et de vieux complices en matière de performances, j’ai notamment un peu co-écrit avec Aymeric sur ce blog et on aime beaucoup faire la course à l’optimisation tous les deux.

Quand

Tout est quasi finit en terme de développement, nous en sommes à la phase de beta test depuis quelques jours. Une fois celle-ci terminée on attaquera la phase de benchmark et la mise sur le marché se fera aux alentours de mi-février, tout début Mars au plus tard si on tombait sur un pépin.

Quand au « Quand cela a commencé » : depuis quelques mois, environ 6.

Sur le Web of course :)

Julien et Christophe (de DnD, aidé par notre illustrateur Flash de talent, Yoann Dondicol) m’ont monter le site Magento qui sera en ligne prochainement pour vendre l’extension sur www.nitrogento.com. (ouverture mi février normalement). Je pense qu’on le mettra peut être aussi dans Magento Connect. Les partenaires NBS System pourront aussi l’acheter directement auprès de leur interlocuteur habituel.

Pourquoi

Parce que Magento est flexible et puissant mais il est également assez lent et consommateur de ressources. Parce qu’un magasin rapide vend plus et offre une meilleure expérience à l’utilisateur.

Les chiffres et statistiques sont là :

  • Akamai & Forrester : 5 secondes de temps de chargement : 20% des personnes partent
  • Shopzilla a augmenté ses revenus de ~10% en chargeant en 2s au lieu de 7s
  • Yahoo perd 5 à 9% de trafic en chargent avec 400 ms de plus
  • Google : +500 ms, -20% trafic
  • Amazon : +100 ms, -1% de ventes
  • Les utilisateurs interrogés disent que 2 secondes c’est acceptable, 4s c’est trop
  • 52% des visiteurs considère que la vitesse de chargement d’un site est un critère essentiel pour revenir
  • En 2010, 75% des visiteurs ne reviennent pas si le site est lent (contre 64% in 2006) }
  • La vitesse influe directement sur votre SEO ET votre SEM
  • Google a divisé le web en deux clans (voir webmaster tools->labo->performances) : les sites rapides, qui chargent en moins de 1,5 secondes et les lents, qui chargent en plus de 1,5 secondes…

etc, etc, etc… Le web fourmille d’étude en ce sens, la vitesse joue sur tout, y compris massivement sur le taux de transformation, bien que là je n’ai pas retrouvé l’étude qui m’intéressait dans l’immédiat.

Quoi

Eh oui, ca reste le plus important en fait, ça fait quoi Nitrogento ?

Vous l’aurez voulu, on est partit :

  1. Full Page Cache pour la version CE et plus efficace (et moins buggé) que celui de la EE
  2. Bloc caching (y compris si les développeurs ont oublié de l’instancier)
  3. Custom Bloc Caching (cache des blocs non natifs à Magento)
  4. Auto Sprite : génération automatique du sprite lié au template pour diminuer le nombre de requêtes
  5. Déploiement automatique en CDN (pour paralléliser les downloads des ressources statiques)
  6. Concaténation des JS et CSS en un seul fichier
  7. Minify et compression de : HTML / JS / CSS
  8. Paramétrage depuis le backoffice des Expire headers, Etags et compression Gzip

Voila, j’ai oublié une ou deux choses involontairement, une ou deux de plus qui sont encore en gestation pour notre roadmap de la version 1.1.

Au final on atteint quoi ?

Pour le moment, ce sont des statistiques temporaires, le temps de finaliser les benchmarks réels :

  • -0,5 seconde en moyenne sur le temps de chargement des pages
  • ~8 fois moins de charge serveur sur la home (FPC)
  • ~2 fois moins de charge serveur sur les pages internes (bloc cache+custom bloc cache)
  • ~2 fois moins de requêtes HTTP (Sprite)
  • chargement des ressources statiques 2 à 3 fois plus rapides (CDN)
  • grade A/A sur Gtmetrix.com (98 en Yslow et 96 en Pagespeed) au lieu de C/C (78% Yslow / 76% pagespeed)
  • avec un serveur de base, on arrive à 1,9 seconde au lieu de 3,1 pour la home
  • avec un serveur optimisé pour Magento, on arrive sous la barre des 0,7 seconde pour la home
  • économie de ~15% de bande passage (sprite + minify + gzip)
  • pour un visiteur qui revient sur une page ou repasse sur la home, on atteint un temps de chargement qui en général est sous la barre des 0,4 secondes et moins de 20 Ko

Coté Serveur :

  • En période « normale », ça accélère le chargement
  • En période de pic (soldes, mailings, ventes privées) ça diminue considérablement la charge des serveurs et la bande passante utilisée

Coté Navigateur :

  • Ça accélère le rapatriement des données statiques (Minify + Gzip + CDN)
  • Ça optimise le cache du navigateur (ETags+Expire headers)
  • Ça diminue le temps d’affichage des pages

On peut vérifier ?

Oui, le Nitrogento store sera équipé aussi d’un demostore et d’un « Nitrostore » (un démostore sous Nitrogento) , sur la même machine, ce qui permettra à tout le monde de voir la performance, de tester et de vérifier avec GTmetrix, Pagespeed et /ou Yslow.

Vous pouvez aussi vous porter volontaire pour la phase de Beta, si vous êtes retenu, l’extension sera alors gratuite pour votre site une fois qu’elle sera commercialisée.

Voici déjà un shoot, pris pendant l’intégration :

L’image est un peu petite, mais la note du Yslow est bien à 98%…

Les limites

Pour être honnête, il faut aussi parler de  ce que le produit ne fait pas ou ne peut pas faire.

Par exemple, quand on est authentifié ou qu’on a un bloc contenant des informations de session, de panier ou d’authentification, le FPC (Full Page Cache) se désactive, ce qui est normal et indispensable.

Ensuite, la mise en cache des custom blocs nécessite d’appeler un helper pour être prise en compte dans le back office et donc visible pour activation / désactivation. Rien de compliquer à faire mais ce n’était pas automatisable.

Pour le moment seul le CDN accessible en CNAME par FTP est géré. Dans la v1.1, un support natif du CDN de NBS, de celui d’Akamaï et de MaxCDN devrait être intégré.

Enfin, pour le moment, nous avons pris le partit de le mettre en Anglais car la très grande majorité du marché est anglophone et que les intégrateurs Français parlent presque tous anglais.

Combien

500 $ par an pour un serveur frontal.

Si vous avez plusieurs serveurs frontaux, il faut avoir l’extension sur chacun d’entres eux mais les suivants seront facturés 100$ par an. Ce tarif intègre également les mises à jour et les évolutions.

(Les clients et partenaires NBS System profiterons d’une tarifications spéciale)

écrit par Philippe Humeau \\ tags: , , , , ,

jan 20

Bonjour à tous,

Je suis particulièrement content de vous annoncer la création de l’apérogento Nantais !
Cela me touche car je suis moi même de la région et cela fait une belle boucle :)
Bientôt on vous parlera de aussi de Bargento 2011, enfin si on trouve une salle adaptée.

Voici le communiqué de presse :

Le 10 février 2011, porteurs de projets Magento, e-commerçants : soyez au rendez-vous de l’apérogento Nantais !

Nantes, le 20/01/2011 - La technologie Magento s’est imposée depuis maintenant plus de deux ans comme une évidence dans le secteur de l’e-commerce. Dans ce contexte et pour promouvoir cette solution e-commerce, le premier rendez-vous régional de l’Ouest dédié à Magento se tiendra le jeudi 10 février 2011, de 12h00 à 17h00.

Apérogento Nantes : se rencontrer, découvrir, échanger au tour de Magento

Cet événement réunira en un même lieu, le restaurant TEO (Hangar à Banane – Ile de Nantes) des porteurs de projets, des e-commerçants et des spécialistes de l’e-commerce proposant des solutions innovantes en matière de création de site, de gestion, de référencement et de sécurité.

Organisé en parallèle des évènements Bargento – rendez-vous Magento à l’échelle européenne – l’Apérogento Nantes est l’occasion de s’informer, de découvrir et de rencontrer des spécialistes e-commerce dans une ambiance conviviale. La formule choisie par les organisateur est celle d’un déjeuner, suivi d’ateliers- conférence d’une heure (en rotation) permettant un échange simplifié et une meilleur interaction public / conférenciers.

Afin de faciliter les échanges et de rester dans un cadre professionnel, l’accès à l’Aperogento Nantes est limité à 50 personnes (entrée payante : 45 euros / personnes). Les billets sont en vente ici.

Apérogento Nantes : programme des conférences et ateliers

Les ateliers seront orientés autour de trois thématiques :

L’Apérogento Nantes en pratique :

Pour en savoir plus et pour vous inscrire, rendez-vous sur le site de l’évènement : www.aperogento.fr

Les trois sociétés organisatrices présentes le 10 Février à l’Aperogento Nantes : SQLI Nantes, CyberCité, NBS System.

A propos de SQLI

Créée en 1990, SQLI est une société de services spécialisée dans les NTIC (technologies & usages Internet). Le Groupe SQLI figure parmi les acteurs majeurs français sur le secteur de l’ecommerce et fut l’un des premiers intégrateur Magento. Avec son Agence Web (Sqli Agency, basée à Nantes et Bordeaux), nous proposons l’ensemble des savoirs-faires stratégiques pour répondre à vos enjeux e-business (consulting ecommerce, e-communication, intégration de solutions ecommerce, mobilité, expertise sur le système d’information, maintenance, …). Nos clients Magento : Insudiet, TheNorthFace, Salomon, Lancaster, Somfy, Phox, Bébé 9, Téléshopping, Discounteo, Cegid Group, Signals, …Fort de 2 000 collaborateurs, SQLI a réalisé en 2009 un chiffre d’affaires de 154,7 M€. Depuis le 21 juillet 2000, la société SQLI est cotée au Nouveau Marché (code SICOVAM : 7547).
www.sqliagency.com.

A propos de Cybercité

Créée en 1999 et spécialisée dans le webmarketing et référencement à travers trois activités principales : le référencement naturel, le référencement payant et le développement d’application de veille et de tracking, CyberCité gère les stratégies de référencement de près de 700 entreprises, PME et Grands Comptes. Au fil de ses 11 années d’existence, CyberCité est passée de deux salariés à soixante aujourd’hui et annonce pour 2009 un chiffre d’affaires de 6,5 millions d’euro. La croissance soutenue et régulière de CyberCité a été récompensée une première fois en 2006 en recevant le label « Gazelle » par le ministre des PME et une seconde fois en 2008 en intégrant les classements Deloitte Technology Fast50 et Fast500 EMEA.  Site web : www.cybercite.fr

A propos de NBS System

Créée en 1999, la société NBS System possède  une double activité de sécurité informatique et d’infogérance de serveurs. En matière de sécurité informatique, nos experts interviennent dans les domaines des tests d’intrusions, du conseil en infrastructure, de la mise en place de dispositifs de sécurité et en formation. Depuis 2008, NBS System s’est engagé aux cotés de Varien pour héberger de manière optimisée des systèmes Magento. Depuis 2 ans, nous avons crée des systèmes dédiés spécifiques à la solution, développé une expertise que nous partageons sur www.wikigento.fr et au travers de Bargento dont NBS System est fondateur. A ce jour, NBS System héberge plus de 200 sites Magento et de nombreux autres serveurs sur tout type de technologie opensource. Sites Web :  www.nbs-system.com, www.wikigento.com, www.bargento.fr

Merci à Profileo pour son soutient logisitique sur les sites *gento

Profileo est une agence web spécialisée dans la solution e-commerce Magento, comptant 25 collaborateurs en France (Paris et Aix-en-Provence).Situées à New York, Buenos Aires et Amsterdam, trois agences complémentaires organisent l’extension des sites à l’international. Membre des Experts Magento (www.LesExpertsMagento.fr), Profileo assure depuis 10 ans la création de site internet marchands, de ventes privées et ventes événementielles, etc. La web agency gère la chaîne des prestations attendues d’un prestataire e-commerce : création graphique et ergonomique du site web, développement, blogs événementiels et e-marketing. www.profileo.com

écrit par Philippe Humeau \\ tags: , , , ,

jan 12

Il parait qu’aujourd’hui, c’est le début des soldes :)

Techniquement, ce n’est pas le graph de bande passante de nos infrastructures qui me dit le contraire. Après le pic d’un client à 400 Mb/s de BP pendant une émission sur M6 (passé sans aucun incident ceci étant dit), il semble que les sites sous Magento soient en plein activité ce jour.

Les offres d’hébergement Magento sont conçues pour permettre à chacun des clients d’absorber son trafic normal et, la plupart du temps, les infogérants mettent à disposition des serveurs supplémentaires pour cette période très spécifique à très fort trafic.

Que ce soit en Cloud (Extend To Cloud) et donc de manière élastique ou en mode booster temporaire, les sites ont définitivement besoin de ce type d’aides pour passer la marche !

Par contre, il faut éviter certaines erreurs… La charte du bon soldeur :

  1. Je ne mettrai pas en production un site la veille des soldes sans l’avoir testé/fait testé car c’est le meilleur moyen d’avoir un imprévu qui va provoquer une indisponibilité. Un bug de code sera vu par dix fois plus de personnes à cette période, la sagesse et la prudence sont donc de mise. Il vaut mieux mettre en place son nouveau site sur une zone de préproduction, le tester, le mettre en production 24 à 48H à l’avance pour le tester avant le rush et laisser les caches se mettre en place.
  2. Je ne ferai pas de vidage de cache juste avant le rush. Eh oui, un site dont le cache est « froid » est 3 fois moins rapide et efficace qu’un site dont les caches ont eu le temps de se charger, où les reverse proxy ont eu le temps de travailler. 3 fois moins efficace quand on a 4 fois plus de monde en moyenne, c’est un très mauvais ratio de 12 fois plus de  travail pour le(s) serveur(s).
  3. Je lisserai mes mailing. Envoyer 1 ou 2 millions de mails en très peu de temps, cela provoque des embouteillages car tout le monde ouvre en même temps le mailing, d’où une surcharge de travail. A l’inverse, lisser dans le temps, 2 millions en 4 heures par exemple au lieu d’une, cela va imposer une charge de travail 4 fois moins importante à l’infrastructure.
  4. Je préviens mon infogérant et je reste en contact avec lui, je regarde mes statistiques de visites mais je ne martyrise pas mon backoffice toutes les 2 minutes pour savoir si je vend ou non. Déjà, cela n’améliorera pas les ventes, en plus le BO de Magento est lent et c’est un bon moyen de faire monter les serveurs en charge.
  5. Je ne mettrai pas en place plusieurs Cron lentes et lourdes au moment du rush. Je laisse la puissance aux visiteurs, à mes clients, je fais mes traitements (qu’ils soient manuels ou automatisés) la veille ou le lendemain mais pas pendant les heures de pointes.

L’essentiel, c’est que tout se passe bien pour le client, il faut donc se montrer efficace plus qu’innovant parfois. Un site qui est rodé, qui tourne et à fait ses preuves fera souvent mieux que la toute dernière vitrine, à peine testée sur des caches froids et soutenant le feu d’un mailing compact passé en une heure. Le mieux est souvent l’ennemi du bien, c’est aussi vrai online.

écrit par Philippe Humeau \\ tags: ,

jan 10

Magento et les imports

Comme souvent, quand vous avez un site Web à faire tourner ou à lancer, vous aller envisager de faire des imports. Que ce soit un one-time ou une automatisation, vous aller vivre avec une limitation de rapidité. Celle-ci est dûe en partie à la structure de la base en EAV et au fonctionnement du Framework.

Cette limite vous borne à un rythme de un a deux secondes par produits à 10/20 produits par secondes selon la méthode utilisée, la machine et la complexité de l’import.

Dès que l’on touche à une grande masse, gagner un peu va jouer beaucoup au final.

Vitaminer un peu vos bases

Désactiver les binlogs

Ce tips est utilisable aussi bien pendant vos imports que sur votre production. Seul petit soucis, sur la production, désactiver les binlogs va vous empécher de faire du master/master ou du master/slave (peut être du cluster je ne sais pas) et ca peut ne pas coller avec vos besoins.

Dans votre fichier my.cnf, pour désactiver les binlogs, vous pouvez passer la ligne sync_binlog=1 à sync_binlog=0.

C’est typiquement utile/faisable pour un mono serveur dédié ou virtualisé avec base de donnée et frontal web sur la même instance/machine.

Innodb_flush_log_at_trx_commit

Deuxième limite, si vous passer la paramètre innodb_flush_log_at_trx_commit à 2, vous aller limiter votre niveau de protection en cas de crash et encore, nous parlons ici de la dernière seconde de transaction. Vos machines sont censées être au chaud dans un datacenter, redondante et un crash arrive très très rarement. Une seconde de transaction, chez vente privée à 8h00 du matin, ca peut faire très mal, mais sur un site un peu plus raisonnable à minuit, ca ne représente en général rien. Le risque est donc très limité, d’autant que de nombreux hoster mette maintenant ce paramètre par défaut.

La doc de Mysql nous dit :
If the value of innodb_flush_log_at_trx_commit is 0, the log buffer is written out to the log file once per second and the flush to disk operation is performed on the log file, but nothing is done at a transaction commit. When the value is 1, the log buffer is written out to the log file at each transaction commit and the flush to disk operation is performed on the log file.

When the value is 2, the log buffer is written out to the file at each commit, but the flush to disk operation is not performed on it. However, the flushing on the log file takes place once per second also when the value is 2. Note that the once-per-second flushing is not 100% guaranteed to happen every second, due to process scheduling issues.

With a value of 2, then only an operating system crash or a power outage can erase the last second of transactions. However, InnoDB’s crash recovery is not affected and thus crash recovery does work regardless of the value.

Il faut savoir que les disques durs et les controlleurs peuvent aussi prendre sur eux de retourner un joyeux « ok c’est fait » alors qu’en fait, la donnée est en cache mémoire en attendant un flush… Mais dans ce cas, le mode 1 n’est pas plus sécurisant, donc autant rester sur le 2.

Pour modifier votre valeur de commit :
passer innodb_flush_log_at_trx_commit = 1 à 2

Résultats attendus

Si vous mettez ces deux valeurs en place, vous devriez avoir un gain de performances pour vos imports mais aussi en exploitation, de 20 à 40% de performances. C’est un choix à bien réfléchir cependant mais un risque limité. Coté binlog, c’est faisable ou non, tout dépend de votre environnement.

écrit par Philippe Humeau \\ tags: , , ,