device not ready

OVH a toujours été pour moi synonyme de qualité et de service bien ficelé. Depuis qu'il ont laissé mon site inaccessible, s'enfonçant dans une procédure absconse et inadaptée, ce n'est plus le cas.

Il s'agissait assez simplement, pour un de mes sites, de partager l'hébergement avec un autre de mes sites, le tout (noms de domaines et hébergement) étant chez OVH. Quand j'ai senti le roussi, j'ai pris les devants pour m'assurer que tout serait OK mais rien n'y fit. Mon site finit par être inaccessible, et mes emails aussi.

Après un premier coup de gueule, j'ai fait un suivi ici ici puis là.

Depuis, je ne conseillerai plus à des clients, des collègues ou des amis de choisir un hébergement chez OVH.

Ils ont été tellement lamentables que j'ai failli basculer vers un serveur @home, chez Mike, mais pas de bol, il était lui-même aux prises avec de solides boulets le laissant sans internet. Comme quoi la médiocrité est peut-être devenue le nouveau standard de service.

Attention, mon propos n'est pas de "descendre" gratuitement OVH et ça ne veut pas dire que rien ne va plus avec ce fournisseur. De manière nuancée, l'expérience me montre qu'il est tout à fait possible que votre site pro soit inaccessible plusieurs jours à cause de leur incapacité à effectuer une action simple.

Pour le même prix, car rien ne permet de penser qu'ils auraient agi différemment, s'il s'agit d'un site de vente en ligne, il ne vous restera plus qu'à voir vos clients partir mécontents et voir votre business s'écrouler.

En pièce jointe de ce billet, la retranscription de mes échanges avec les différents services OVH.

Consternant.

Il a osé critiquer PHP. Oh le vilain. Il le savait, il allait se prendre un retour de manivelle bien prévisible. Et ça se transforme rapidement en attaque ad hominem, raison pour laquelle vous ne devez jamais laisser votre nom dans du code ni jamais rien partager.

Ca doit être dans la nature humaine : s'approprier une marque de voiture, une équipe de foot, un groupe de musique, une langage de programmation et ne pas supporter la critique à son sujet.

Le développeur PHP retiendra que "son" langage est simple, puissant, et qu'il est facile de déployer son code. Le développeur Java ricanera devant la porcherie qu'est PHP, la contingence de son modèle objet, le code spaghetti à coup de queries SQL mélangé à la sauce PHP et assaisonné d'HTML servi sur les forums. Le développeur PHP rétorqua que Java c'est lourd, c'est lent, et c'est gourmand en resource. En plus, bonne chance pour trouver un hébergeur. En retrait, le développeur Rails se sentira sans doute au-dessus de la mêlée, sourire au coin des lèvres, et on s'abstiendra simplement d'adresser la parole au gars qui pratique le Python.

Et la passe d'arme ainsi continuera sans fin, un cliché répondant à une mauvaise pratique.

J'aime beaucoup l'argument sur les dates : autant leur traitement est bancal en PHP, autant il est foireux en Java. Les javateux utilisent JodaTime pour contourner le problème. Les dev php n'ont que leur yeux pour pleurer. Ha, je me marre bien. PHP 0 - Java 0 pour le coup.

Le propos de Seb Sauvage était pourtant assez clairement exprimé : "php est moche, mais ça n'a aucune importance. php suck, but it doesn't matter. On y arrive. Avec de la discipline, on peut faire assez propre". Mais il était trop tard : l'offense était là.

Heureux soient ceux qui programment en PHP et ne le trouve pas rébarbatif ou dépassé. Tant mieux pour eux : ils ne sont pas malheureux! Il n'y aurait rien de pire que d'utiliser un langage ou une techno en fronçant les yeux à longueur de journée ou en soupirant. Mais l'API incohérente, souvent mal retravaillée au fil des versions, le modèle objet pathétique et le support unicode défaillant finissent de me couper l'appétit. Surtout, c'est une langage d'une vieille génération et si vous avez goûté à des denrées plus modernes, c'est dur de revenir en arrière, indépendamment des mérites de PHP.

PHP, ça marche, ça fait ce pourquoi c'est prévu, mais je n'ai pas particulièrement envie d'utiliser cette vieillerie en 2012. Je veux d'ailleurs aussi plus que le verbeux Java et son stack enterprise lourdingue qui change plus vite qu'une mode vestimentaire et qui fait perdre plus de temps qu'il n'en fait gagner.

Plus! Je veux un truc qui soit une tuerie à tous les niveaux : syntaxe, librairie, déploiement, support IDE, robustesse. Pas encore trouvé. Si vous tombez dessus, laissez un commentaire.

Je m'estime bien loti : pour l'instant, je développe principalement en Grails. Il n'y a pas de silver bullet, et Grails n'en est pas un, mais il a au moins le mérite de m'apporter un langage relaxant (Groovy) et un stack intégré. Grails a ses travers, comme toute plateforme qui permet de faire du boulot sérieux, mais c'est une expérience plaisante qui m'apporte satisfaction. Même Python et Django me semblent tarabiscotés quand j'y jette un oeil.

Pour la petite histoire, je suis principalement développeur Java/JEE, je travaille actuellement avec Grails, je fais du PHP sur mes projets pro sur le côté pour des petits clients, un peu de C quand il me prend l'envie de bricoler une babiole électronique, j'ai eu ma période où je scriptais tout en Python (les collègues me regardaient avec un air intrigué et vaguement admiratif) et avec lequel j'ai appris les rudiments à mon jeune apprenti padawan. J'ai commencé ma carrière en PowerBuilder. Je lorgne sur Scala avec envie en attendant qu'un stack solide soit dispo (Play?). Comme beaucoup de développeurs, je passe plus de temps à apprendre une nouvelle techno, un nouveau framework qu'à l'utiliser.

L'important est de rester ouvert et d'aimer ce que l'on fait. Et de choisir un outil adapté à la situation.

Il faut arrêter de prendre la mouche à la moindre critique. Admettez le bon et le mauvais dans ce que vous utilisez et dans ce que vous appréciez. Aérez-vous l'esprit, combinez les outils existant, prenez du recul et créez quelque chose et profitez-en ou faites-en profiter les autres. Et si souhaitez voir les choses évoluer, plutôt que de réagir personnellement à la moindre attaque contre ce que vous connaissez, prenez le parti d'exiger toujours plus et mieux. Parce qu'on le mérite bien.

Alors que je lui demandais s'il pouvait héberger mon site pro à la maison (VDSL, Mac Mini) puisque pour OVH, ça semblait être la mer à boire, Mike me dit que son raccordement internet EDPNet / Belgacom ne s'est tout simplement pas fait.

Je lui laisse la parole.

Petit résumé de mon harcèlement par Belgabrol:

• vendredi 30, entre "8 et 18h", un technicien Belgacom passe activer le VDSL2: il arrive à 20h (!) et part à 22h30(!!!) quand il part, non seulement je n'ai pas internet mais plus de téléphone non plus sur aucune des deux paires de cuivre de ma maison, au plus il chipottait, au moins ca fonctionnait. Il prétent que le câble est défectueux alors que je téléphonais encore 30min avant qu'il n'arrive... Il me promet de m'envoyer une équipe technique en urgence pour arranger la ligne.
• lundi 2, EDPnet me signale que Belgacom doit tirer une nouvelle ligne, il passeront jeudi 2 et cela me coutera 650€. Je leur explique la situation et leur dit de refuser tout paiement à Belgacom étant donné qu'ils doivent réparer leurs dégâts. J'appelle Belgacom et ils me disent qu'effectivement une équipe passera mais qu'il n'est pas dit que ca me coutera quoi que ce soit, fort bien me dis-je, wait and see.
• jeudi 2, entre 8 et 18h personne ne vient. J'appelle le support à 19h: réponse "toutes vos interventions ont été annulées et votre abonnement est résilié" alors que je n'ai rien demandé ?? "j'envoie des emails pour demander ce qu'il se passe en interne, ils vous rappelleront demain". Pas de nouvelles.
• lundi, je téléphone au support technique: "pour nous vous n'avez pas d'abonnement, je peux rien faire, contactez le support commercial". Support commercial: "votre abonnement est en ordre, je ne vois aucun problème" :/ Elle crée "un ticket interne" (dixit, SMT sans doute) pour le service technique pour qu'ils mettent leurs données à jour. "Je vous rappelle en fin de journée, ça devrait être en ordre pour 17h". Pas de nouvelles.
• ce matin, rebelotte: support technique me remballe vers le support commercial. Elle téléphone en interne et me promet que ma ligne sera rétablie dans les 24h "à distance". Etant donné que le technicien sur place n'avait plus de jus dans le câble, je me demande comment ils vont faire pour arranger ca à distance... bref j'en suis là, et demain je pense que je vais commencer à rédiger des mises en demeure.

Mike, on est avec toi, contre les bozos et les je-m'en-foutistes de sociétés commerciales pour qui le client n'est qu'une entrave au profit.

Mon site pro est down depuis ce week-end, et OVH continue à attendre... une procédure!

Dernier échange en date :

De : **** Pour : ****

Date : 2012-02-06 11:16:24

Bonjour,

Malheureusement on peut pas effacer un hébergement mutualisé que 15 jours aprés la date d'expiration (minimum). Je vous invite à nous envoyer une procédure de fermeture d'hébergement en précisant que vous souhaitez une destruction immédiate. Dans ce cas là on pourra le faire.

Auquel je réponds (bientôt je vais me mettre à larmoyer et à supplier) :

De : dnr

C'est déjà fait (vendredi soir par fax).

Je ne comprends toujours pas pourquoi il n'est pas possible d'activer l'hébergement multi-domaine depuis devicenotready.com.

Et je ne comprends toujours pas pourquoi le hosting ******.net qui est déjà expiré devrait être fermé en suivant une procédure papier.

Je m'y suis pris une semaine à l'avance, j'ai contacté le support pour m'assurer que tout serait ok, on m'a affirmé que oui et au final, mon site est DOWN et OVH me demande de suivre une procédure papier.

Si je peux me permettre, j'ai envie de vous dire : JUST DO IT! Vous avez mon accord répété, par ticket, par fax, par blog et je subis un préjudice qui s'accroit avec le temps qui passe à ne pas opérer le basculement.

C'est tout simplement insensé!

Et ce genre d'échange, ça va crescendo depuis une semaine.

La "procédure OVH" semble primer sur le bon sens et sur le service au client!

Grosse déception avec le support OVH.

J'ai tenté une opération assez simple en apparence :

• Domaine A, nom de domaine chez OVH, hébergé en mutualisé, expire le 4/2/2011
• Domaine B, nom de domaine chez OVH, hébergé en mutualisé

Comme je n'ai pas besoin d'un hébergement "complet" pour A (avec sa propre DB et un espace généreux pour mes fichiers), je décide ne renouveler que le nom de domaine A, pas son hébergement, et d'héberger A sur B. C'est possible chez OVH : cela s'appelle le multi-domaine. Je mets cela en place une semaine avant l'expiration de A.

Je bénéficie encore du hosting A, en plus d'avoir activé le hosting sur B en multi. Mon site est toujours servi par mon mutualisé A qui n'a pas encore expiré.

Le comportement souhaité est qu'à l'expiration de A, le multi-domaine configuré sur B prendra le dessus. Mais en bon techies, je me méfie de ce genre de présomption d'automatisme qui, s'il est de bon sens, ne va pas forcément de soi. J'ouvre donc *préventivement* un ticket auprès du support email d'OVH pour m'assurer que le hosting basculera de A vers B à l'expiration de A.

Échange par tickets interposés : on me dit d'abord que c'est bien le multi-domaine depuis B qui sert les fichiers de mon site A, ce qui est faux (j'ai introduit une légère différence entre A et B pour justement m'en assurer). L'échange s'étire sur une semaine, le support prenant à chaque fois un jour ou deux pour répondre, et la date d'expiration se rapproche.

Le support email me demande alors, la veille de l'expiration, de lancer la procédure papier de fermeture d'hébergement. Cela suppose de remplir un document papier et de le faxer avec les statuts de ma société et ma carte d'identité. J'ai beau protester et mettre en avant le non-sens que constitue cette proposition, rien n'y fait. Il y a toutes les chances que A expire *avant* que la procédure n'aboutisse, et les faits vont malheureusement me donner raison. Sans compter que ce n'est pas tout à fait ce que je souhaite : pour moi, un basculement avant la date d'expiration ou justement à l'expiration me sied. Pas besoin de fermeture anticipée. Mais je me plie à cette demande étrange.

J'insiste encore et le support email me conseille d'ouvrir un "incident", ce qui correspond à un support de 2è ligne si je comprends bien les rouages OVH.

Pas moyen que la première personne au support ne prenne cela en charge en assurant la coordination. Non, c'est un autre service. Mais bon sang, on se croirait dans une banque ou dans une administration! Coup de gueule : quand la demande du client est fondée et qu'il va subir un préjudice ou un désagrément, bougez-vous pour assurer le suivi! Fuck la procédure si elle s'avère inopérante ou inadaptée.

À ce stade, mon site A est *down* et n'est pas servi par le multi-domaine B, qui est pourtant bien configuré selon le support email OVH. J'ai demandé une augmentation de la priorité de traitement.

Déception au final : j'ai moi-même flairé le soucis potentiel une semaine avant la date fatidique et OVH n'a pas été capable de m'indiquer la marche à suivre ou de prendre les mesures utiles.

Franchement, basculer un hosting, c'est vraiment la mer à boire?

Un petit puzzler que j'ai écrit aujourd'hui. C'est en Groovy mais ce serait du Java que ça serait pareil.

interval1.startDate = MyDateUtil.createDate(2012, 01, 07)
interval1.endDate   = MyDateUtil.createDate(2011, 02, 08)
interval2.startDate = MyDateUtil.createDate(2012, 02, 01)
interval2.endDate   = MyDateUtil.createDate(2012, 02, 02)

Sans tricher : que fait ce code?

Un client ING me montre les messages qu'il a reçu au self bank parmi ses extraits de compte.

Le premier annonce une baisse des taux d'intérêt créditeurs, pour suivre ceux de la BCE. Logique, me direz-vous.

Le second annonce une hausse des taux d'intérêt débiteurs en cas de découvert. Et là vous m'expliquez la logique : ces taux devraient également suivre ceux de la BCE et donc diminuer, pas augmenter.

ING prouve une fois de plus, avec une inélégance risible, qu'elle se paie la tête de ses clients.

Bad bank, baaaad bank!

Dans l'attente d'un nouveau MacBook Pro que j'achèterai l'année prochaine, je suis décidé à booster les performances de mon MBP actuel en remplaçant mon disque dur par un SSD.

La techno n'est plus "bleeding edge", les opérations de TRIM sont finalement bien supportées et les prix sont passés de "exorbitant" à "très, très cher". C'est le moment d'en profiter.

Avant de me précipiter, je fais quelques recherches et je tombe sur ce test.

Ca commence mal :

SandForce SF2281 : gare aux freezes et aux BSOD !

Certains d'entre vous le savent peut être déjà, plusieurs forums sont actuellement envahis de messages rapportant des problèmes avec les SSD équipés du dernier contrôleur de SandForce. De nombreux utilisateurs se plaignent en effet de lenteurs, de blocages de leurs machines ou encore de BSOD intempestifs.

C'est pourquoi, faute de correctif disponible actuellement, nous vous déconseillons tout simplement l'achat de tels modèles. Nous ne modifions cependant pas la note attribuée, représentative des performances que peuvent atteindre ces modèles lorsque ces problèmes seront résolus. Rapidement, on l'espère...

On parle bien d'un test effectué en mars 2011. Et pour ne pas arriver à la conclusion aberrante qu'il faut fuir le tiers ou la moitié des modèles testés, le magazine préfère prendre l'approche optimiste sur le mode : "un correctif finira bien par arriver".

Ce contrôleur SF2281 est largement utilisé. Pas de risque de BSoD sur mon Mac mais cela ne présage rien de bon : si l'OS le plus répandu n'est déjà pas bien supporté, à quoi faut-il s'attendre pour OSX?

Le problème commence à trouver un début de correction, chez un fabricant en tout cas. On est en septembre 2011... Et je ne sais pas où les autres en sont.

Je ne m'effraie pas pour autant. Tant qu'à acheter un SSD qui dépote, autant opter pour du SATA3. Et bien, ce n'est pas gagné. La nappe SATA3 dans le MBP serait de qualité médiocre et provoquerait des interférences. Voyez cette éloquente bidouille pour blinder la nappe à moindre frais.

Tout cela n'est pas rassurant mais je tente l'aventure.

Si vous hésitez, pour l'achat d'un nouveau MBP, les SSD fournis par Apple sont relativement moins performants et sont exagérément coûteux par rapport à l'offre disponible, mais ce n'est pas pour autant un mauvais choix : au moins, vous bénéficiez d'une solution supportée aux résultats nettement moins aléatoires. Mieux vaut encore un SSD cher payé qu'une SSD inopérant.

Va-t-on vers une réhabilitation du bon vieux "mailto:" à la sauce Chrome?

Google Chrome lets websites ask you whether you'd like to use their services to handle specific web protocols, such as “mailto:” links or “webcal:” links.

Le bon vieux truc qu'on utilisait jamais parce qu'en pratique, ça ne marchait pas et que même quand le client mail s'ouvrait malgré tout, ça sentait le sapin parce que le visiteur avait quitté son navigateur.

C'est pourtant la bonne façon de procéder : je déteste les sites qui ne laissent qu'un "formulaire de contact" à l'issue incertaine. Espace limité, bugs, obligation de sélectionner des catégories inadaptées, feedback inexistant ou aléatoire, et souvent aucune trace de mon côté. Non, le formulaire de contact ne remplace pas un email, et c'est aussi utile qu'une boîte postale en guise d'adresse pour se rendre dans un magasin. Et n'ayant pas de client email "lourd", le fait que mon navigateur honore le lien mailto est une bonne chose.