Pourquoi la photo de la Redoute est-elle restée en ligne plus d’une heure ?

Tout Twitter et Facebook sont en plein buzz : la photo d’homme nu sur le site de La Redoute fait le tour du web.

Mais on peut légitimement se demander pourquoi le site, pourtant informé, a mis plus d’une heure à réagir et à supprimer la photo.

Pourtant la raison en est simple : pour un gros site transactionnel comme La Redoute, tout changement sur le site doit répondre à une succession de vérifications.

Dans ce genre de process, le fonctionnement est généralement le suivant :

  • les développeurs (et/ou les chefs de produits) font des changements sur le site
  • ces changements sont effectifs sur des serveurs de préproduction
  • les équipes testent et restestent, parfois via des service d’assurance qualité
  • les changements passent sur un serveur de « recette » (on re-vérifie si tout est ok)
  • au milieu de la nuit (période de trafic faible) les changements sont déployés sur les serveurs de production (ceux qui envoient les pages web au grand public)

Comme vous le voyez, on est loin  de la modification effectuée fissa sur un serveur mutualisé.

Donc, pour reprendre le cours de notre histoire, quand le community manager de La Redoute s’est aperçu de la bourde, il était tout bonnement impossible d’effectuer un déploiement. Le risque aurait été trop grand : prix incorrects, bugs, fichiers en cours de modification… Bref, impossible d’utiliser cette voie là.

Que s’est-il alors passé ?

La réponse est arrivée plus d’une heure après la découverte du problème par La Redoute, sûrement par le biais direct de l’hébergeur.

En effet, si l’image a bien disparue, elle n’a pas été supprimée proprement : le site affichait encore une image de lien brisé, très Netscape old school et super anecdotique dans le web d’aujourd’hui.

Qu’est ce que cela signifie ? Tout simplement qu’un admin du site s’est connecté sur les serveurs de production et a supprimé les images à la main.

Une démarche très rare et complètement contraire aux principe de l’administration d’un important site web e-commerce (ou la sécurité joue un rôle fondamental, bien plus que pour un site d’information).

Mais au delà de la démarche employée, on peut légitimement se demander si ces déploiements peu agiles sont toujours efficaces dans un monde où Twitter s’enflamme en quelques secondes.

Prévoir une couche d’intervention « de crise » va devenir une vraie préoccupation des DSI et pendant ce temps là, je vous parie que La Redoute va finir en cas d’étude dans les manuels de marketing :-)


Ces billets pourraient aussi vous intéresser :

  1. Pourquoi les Start-ups n’utilisent-elles jamais Oracle ?
  2. MyFacture : la facturation en ligne pour les PME et les indépendants
  3. Les hackers s’attaquent à la bourse en ligne aux USA
  4. Halfnote : stockez et partagez vos informations confidentielles en ligne

3 commentaires

  1. bixibu dit :

    Pour le coup, ça m’étonnerait fortement que la redoute ait besoin de faire une livraison/déploiement de leur application pour une modification de ce type.

    C’est clairement un loupé de « contenu » : une banale image de produit; aucunement un loupé dans leur applicatif. Ils auraient dû pouvoir supprimer l’image en 1 minute maxi via l’interface d’administration de leur solution e-commerce (backoffice).

    Sinon je plussoie l’esprit du post : la réactivité des entreprises à gérer leur image sur le net va devenir un vrai enjeu avec tout ces loupés. (si c’en est ..)

    bixibu

  2. netking dit :

    Je me suis dit la exactement la même chose, jusqu’au coup du lien brisé.

    Pour enlever l’image brutalement des frontaux, il faut bien supposer que le back office (ou une limitation de droits, ce qui revient au même au final) ne pouvait gérer la suppression (du moins dans le délai le plus court).

  3. PadTunes dit :

    Je suis d’accord avec le process décrit… C’est pas le petit site vitrine de 3 pages avec édition via le Front Office.
    Si j’avais été en charge du pépin, j’aurai photoshopé vite fait l’image (pour virer le ‘monsieur tout nu’) et aurait remplacé l’image bad par l’image good sur le filer de prod…
    (toujours mieux qu’un lien cassé)…
    Le délai est peut être aussi dû à un mécanisme de cache…
    L’optimisation technique qu’impose les gros traffic n’est pas toujours compatible avec une réactivité immédiate…

Poster un commentaire