Calvaire de la résiliation chez Orange

Quand un système informatique n’est pas au point ça m’énerve. D’autant plus quand c’est un grand groupe de télécommunication qui pense mal ses processus.

Dans un premier temps vous devez trouver le chemin vers la première étape de résiliation. Ce n’est pas chose facile mais en même temps, ça se comprend. Il ne faut pas rendre la vie facile à ceux qui veulent se désabonner de vos services.

Une fois que vous avez trouvé ce lien, vous arrivez enfin sur une page qui vous parle. On vous explique en toute simplicité le processus de résiliation. Ça a l’air carré, bien pensé, on est sous le charme. On a presque plus envie de partir…

Puis se suivent les encarts qui ne correspondent pas à votre cas mais que vous vous devez de lire pour être sûr de ne rien faire de travers. Jusqu’à ce que vous arriviez en bas de page à nouveau.

Je suis dans un « autre cas de résiliation », sympathique encore faut il être sûr que je ne suis pas dans un « autre motif légitime » comme il est indiqué dans l’encart au-dessus.

Bon je clique quand même pour ouvrir cet énième encart.

Félicitation à l’ergonome. On cache des boutons par des boutons. On évite par la même occasion que les petits malins puissent utiliser la fonction de recherche dans la page pour trouver l’information qu’ils recherchent. En plus on voit un nouveau bouton à cliquer ! Super, moi qui n’avait plus jouer au labyrinthe depuis longtemps, je suis servi.

Vous cliquez pour être rappelé et là c’est le retour aux années 2000. Chez Orange quand vous avez un forfait mobile et un forfait internet et que vous voulez résiliez on ne sait pas vous proposer vos numéros sur lequel vous appeler, ni les lignes qui pourraient être concernées…

Remarqué aussi qu’ici la seule chose qu’on vous sépcifie c’est que le premier champ est obligatoire. On est samedi et je suis motivé, malgré une pointe d’énervement que je sens venir. Je saisie donc mon numéro de portable et mon numéro de ligne concerné.

J’appuie sur suivant. Quelques secondes mon portable sonne. J’attends 3 secondes avant de décrocher. Une voix robotique me signifie « Au revoir et à bientôt chez Orange » et après 10 secondes et un petit jingle, ça raccroche à l’autre bout de la ligne.

Je suis bluffé ! Ok, ils ne savent pas proposer des informations automatiquement et l’ergonomie est un peu douteuse mais un appel de 15 secondes pour résilier ça laisse rêveur.

Maintenant j’attends que ma demande soit confirmée par mail et SMS comme écrit dans leur encart « Résilier en 4 étapes » (d’ailleurs je n’ai pas forcément saisie un mail ou un numéro de téléphone qui peut recevoir un SMS).

J’attends jusqu’au mardi suivant. Soit 4 jours. Quand je décide de retenter l’opération. Rebelote pour toutes les étapes ci-dessus. Mais cette fois je n’indique pas mon numéro de ligne.

Une femme décroche (ou un robot très bien entrainé, allez savoir). Je lui explique mon problème du samedi. Qu’elle feint de ne pas comprendre. Suis je le seul à me faire avoir ? Rien n’est moins sûr. Elle me demande mon numéro de ligne qui enfaite n’est pas le numéro de téléphone associé au contrat mais un numéro choisi arbitrairement par Orange et que vous retrouvez à quelques endroits (quand ça veut bien charger).

Je lui fourni et elle en profite que je n’ai encore jamais fait de demande de résiliation pour mon contrat, puis me fait patienter. Après quelques minutes d’attente elle me certifie que la résiliation s’est bien passée.

Conclusion

Avec ce genre de méthode, un grand groupe comme Orange peut s’assurer quelques jours de facturation de plus par résiliant. En terme de retombée financière, par exemple, pour une offre fibre à plus de 40€ par mois, 4 jours de plus, c’est 5 euros facturés en plus par rapport à une résiliation qui marcherait du premier coup.

Le calvaire de la résiliation se ressent dans ces 3 éléments

  • l’ergonomie
  • la description et le suivi de la procédure
  • ainsi que par inexistence de l’aide par pré-remplisage

Ces manques montrent un grand manque d’attention porté à ceux qui souhaitent résilier, quel qu’en soit le motif. En tant que consommateur ce n’est pas ce genre de processus qui donnent envie de se réabonner de si tôt, même si pour le reste le service est relativement bon.

Le dernier point sur lequel il pourrait y avoir une amélioration c’est le passage par une conseillère, qui n’est là que pour recliquer elle même sur un bouton pour valider ma résiliation et m’expliquer en trois phrases comment je vais rendre mes boites et mes câbles le tout en une dizaine de minute.

Après tout et pour ma consolation, les 5 euros que je paierais en plus avec mes 4 jours d’attentes en vain serviront surement à payer cette conseillère qui passe ses journées à cliquer et répéter les mêmes phrases jours après jours à chaque client.

[ArchLinux] Passage à yay

Focus rapide sur l’accès aux paquets AUR sous ArchLinux. J’utilisais jusqu’à présent yaourt, mais celui-ci n’étant plus maintenu, je vais tester yay pour la gestion de mes paquets AUR.

Le processus d’installation est simple, récupération d’une copie des sources, construction du paquet puis installation. Le programme étant écrit en go, on installera au préalable de quoi le compiler: sudo pacman -S go.

Installation :

git clone https://aur.archlinux.org/yay.git
cd yay
makepkg -si

Onduleur – Surveillance sur le réseau

Dans un article précédent, nous nous étions quitté avec une connexion directe par USB entre l’une des machines connectée à l’onduleur et l’onduleur lui-même. Aujourd’hui, retour sur la configuration du service de surveillance de l’état de l’onduleur, cette fois pour que la machine connectée partage l’information sur le réseau. Le but étant que les autres machines connectées à l’onduleur soit elles aussi capable de connaître son état, de déclencher un arrêt en cas de batterie faible et ainsi, de pouvoir s’éteindre avant de subir une perte de courant totale.

Je repars ici de ma configuration déjà en place. Comme la première fois, plusieurs fichiers sont à modifier, mais en nombre plus réduit. Je commence par éditer le fichier /etc/nut/upsd.users, sur la machine déjà configurée en mode client et connectée à l’onduleur, pour y ajouter un utilisateur « esclave » qui servira à mon autre ordinateur pour l’authentification des demandes d’état.

[slave]
  password = PASSWORD
  upsmon slave

Je modifie ensuite /etc/nut/upsd.conf pour que le serveur nut soit accessible sur le réseau et non plus seulement en localhost; en considérant que l’IP de ma machine est statique.

LISTEN 192.168.24.42 3493

J’enchaîne ensuite avec /etc/nut/nut.conf, où je précise que nut devra désormais fonctionner en mode serveur.

MODE=netserver

Enfin, pour terminer la configuration de la machine principale, je redémarre ups-monitor et nut-server.

Passons maintenant à la machine cliente, où, après avoir installé nut, je définie la manière dont nut va récupérer les informations d’état de l’onduleur, en modifiant /etc/nut/upsmon.conf. J’utilise ici l’utilisateur « slave » configuré précédemment.

MONITOR eaton@192.168.24.42 1 slave PASSWORD slave

Ensuite, édition du fichier /etc/nut/nut.conf afin de préciser le mode de fonctionnement de nut, à savoir ici, client du réseau.

MODE=netclient

Pour finir sur cette machine cliente, redémarrage de ups-monitor et nut-client.

Dernier point de configuration important, mais non lié à nut, au démarrage, j’ai constaté que nut n’était pas capable d’écouter sur l’IP définie dans la configuration, cela étant due, au fait que la récupération de l’IP était encore en cours d’acquisition (statique côté DHCP), au moment du démarrage de nut. Pour palier au problème, j’ai configuré mon RPI pour attendre la connexion au réseau avant de continuer plus avant dans la procédure de boot. Sur un RPI, la configuration s’effectue comme suit :

  • sudo raspi-config
  • 3 Boot Options
  • B2 Wait for Network at Boot
  • « Yes ».
  • Sauvegarder et quitter.

Une fois ces configurations réalisées sur mes deux machines, je suis en mesure de consulter l’état de l’onduleur sur chacune des machines. Un test d’arrêt forcé, m’a permis de vérifier que l’extinction de la machine cliente a bien lieu avant l’extinction de la machine ayant le rôle de serveur, et de m’assurer que l’ensemble redémarre sans assistance au retour du courant.

Récupération de variables système sur Windows

Aujourd’hui j’ai installé Python et Django sur mon système Windows pour essayer de faire un petit site web rapidement, disons avant la fin de la journée.

Je commence donc ma configuration sur mon système Windows et en parallèle je fais la même chose en SSH sur une console MSYS2,une VM en mode console d’un système linux pour faire simple.

Sur windows je teste alors que sur la console MYSYS je suis connecté à mon serveur dédié de l’autre côté de la France mon serveur de production en quelque sorte.

Arrivé à l’étape d’installation de Django sur mon Windows, j’ai un message qui attire mon attention. Il semblerait qu’il manque un chemin dans PATH.

Pas de soucis. Touche Windows, j’écris « path » et j’appuie sur entrée. Je me retrouve sur les propriétés système.

Un clic de plus sur « Variables d’environnement… » et je me retrouve devant deux choix.

  • Variables utilisateur pour MonOrdinateur
  • Variables système

Dans les deux cas j’ai accès à une variable PATH que je peux modifier. Je ne me pose pas plus de questions et je modifie la variable Path dans variables système et y ajoute mon chemin.

Je valide tout, je suis content, tout va marcher et la commande

django-admin --version

devrait enfin m’afficher quelque chose à l’écran. Mais ce n’est pas le cas…

Je retourne dans les propriétés système et je commence vraiment à avoir peur. Plus aucuns chemins n’est accessible dans la liste PATH des variables système. Je pose la question à mon moteur de recherche qui m’indique qu’une restauration est le seul moyen de retrouver mes données perdues. Mais pour cela, il faut un point de restauration.

Je n’ai pas de point de restauration actif, la protection du système semble désactivée.

Je continue les recherches avec de moins en moins d’espoir de pouvoir redémarrer mon système dans de bonne condition. Pour ce qui ne le savent pas, les variables système dans PATH conditionnent beaucoup de chemins vers des exécutables utiles au bon fonctionnement de votre ordinateur.

Plus d’une heure passe, en désespoir de cause je récupère quelques PATH sur un autre ordinateur et un ami m’envoie les siens, mais je vois bien qu’il n’y a pas tous les chemins que j’avais avant de tout casser.

Quand mes recherches prennent un tournant inattendu. Je trouve enfin quelque chose d’intéressant. On peut exécuter la commande set pour lister et modifier les variables d’environnement et système propre à l’exécution d’un interpréteur de commande (CMD). D’ailleurs si on modifie des chemins dans l’interpréteur et qu’on le quitte, les chemins ajoutés ne sont pas sauvegardés. De la même manière si j’ai modifié les variables PATH par l’interface graphique sans relancer l’interpréteur celui-ci connait encore les anciennes valeurs de PATH.

J’ai un sursaut d’excitation. Est-ce que j’ai encore une CMD ouverte ?

Malheureursment non. Je n’ai plus aucune CMD ouvertes dans la barre des tâches. Par contre il y a toujours MYSYS ouvert avec une connexion SSH en cours vers mon serveur.

Se pourrait-il que j’avais la solution pour récupérer mes variables système PATH sous les yeux depuis le début ?

Après avoir mis fin à la connexion ssh avec le serveur. Le verdict. Je tape au hasard la commande Windows « SET » dans l’interpréteur MYSYS Linux. Un résultat ! Peut être que j’ai de la chance après tout ? Je fracasse la molette pour remonter rapidement tout en haut de la sortie affichée, quand enfin j’ai ce que je cherchais !

Toutes mes variables PATH gardées en mémoire par MSYS2. Avec pour seul inconvénient un typage Unix et non Windows. Dix minutes plus tard j’ai mes variables système PATH d’origine. Et en bonus, j’ai même compris mon erreur. J’aurais du mettre mon chemin dans les variables utilisateur et vérifier qu’il était bien écrit. En plus j’aurais pu tester que tout fonctionne en le faisant avec la commande set en console avant de faire la modification réel.

Conclusion

Si vous perdez toutes vos variables système ou variables utilisateur sur Windows vous pouvez les récupérer en dernier recours si il vous reste une console ouverte avant la réalisation des modifications qui ont détruits vos chemins. Pour les trouver il suffit de taper la commande « set » ou « path » dans cette console et de récupérer et mettre en forme les chemins, puis de les réinsérer par l’interface graphique dans PATH en vérifiant si ce sont des variables utilisateur ou système.

Pour la petite astuce, ne faites pas comme moi et pensez à faire des points de restauration système réguliers.

Asus UX31E – Changement de clavier

Il y a de cela sept années environ, j’avais fait l’acquisition d’un ordinateur portable de marque Asus, à savoir le modèle UX31E. Celui-ci m’a accompagné pendant mes études et dans les pérégrinations qui ont suivi les années suivantes, lorsque le besoin d’emmener un ordinateur portable se faisait sentir.

Dernièrement, plusieurs touches du clavier ont commencé à dysfonctionner sérieusement, jusqu’à rendre quasiment impossible le processus de connexion et compromettant donc une utilisation apaisée de l’ordinateur. Résistant à l’envie de balancer le tout par la fenêtre après une vingtaine de tentative de connexion ratée, je me suis donc mis en tête de remplacer le clavier défectueux.

A l’aide d’une série de tournevis de précision, je me suis donc attelé au démontage pièce par pièce de l’ordinateur, afin de dégager le clavier des composants qui le recouvrent. L’opération en soi n’est pas spécialement compliquée, pour peu que l’on prenne son temps, que l’on note l’ordre de démontage et que l’on classe les vis retirées.

Pour avoir une idée des différentes étapes, j’ai pris connaissance du guide « Replacing an Ultrabook (Asus UX21E) keyboard« , qui ne correspond pas à 100%, mais dont les similitudes sont suffisantes pour être d’une aide précieuse. L’essentiel étant de ne surtout pas forcer pour le démontage des composants et autres câbles de connexion. Sur mon modèle en particulier, l’une des vis de la carte mère est cachée par la carte SSD elle-même vissée à la carte mère.

Une fois le clavier remplacé, on remonte tout en sens inverse, en prenant soin de ne pas oublier une quelconque connexion et on croise les doigts pour que ça démarre correctement. Après quelques secondes d’attente, le terminal apparaît, me demandant d’entrer mon login. Quelques appuis sur le nouveau clavier et les touches autrefois défectueuses, me confirme rapidement que la réparation est un succès.

Bref, une vingtaine d’euros, quelques tournevis, et un peu d’huile de coude m’auront permis de prolonger la vie de mon ordinateur. Si ce n’est pas forcément le modèle que je choisirais, si le choix était à refaire, il aurait été dommage de mettre l’ensemble de la machine au rebu, pour un simple problème de clavier. Cette petite réparation me permet donc de donner une deuxième vie à cet ordinateur; qui ne soit pas statique, un clavier externe pour prothèse, ni celle d’une reconversion en serveur. C’est sur ces quelques lignes que je vous laisse : j’ai 2GB de mises à jour à appliquer.