Je commencerai par dédicacer ce premier billet de l'année aux intrépides qui estiment pouvoir coder eux-mêmes leur algorithme de validation syntaxique d'adresses e-mail sans lire le sacro-saint RFC 2822, le document définissant ce qu'est une adresse e-mail valable.

Ceux qui ont vu mes informations de contact sur mon blog se sont sûrement aperçus que j'utilise un caractère inhabituel dans mon adresse mail : le signe « plus ».

Pour moi, cela me sert à créer des « alias » ad hoc, qui sont automatiquement redirigés vers mon adresse principale sans avoir à toucher à un quelconque fichier de configuration de Postfix. Ces alias me servent ensuite à trier mes mails plus efficacement (y compris pour les mettre directement à la poubelle lorsqu'un organisme abuse de mes coordonnées pour m'envoyer du spam).

Il m'est ensuite bien plus facile de créer des règles de tri fondées sur l'adresse e-mail du destinataire (ce destinataire étant l'un de ces nombreux alias) plutôt que sur des critères moins fiables. Certains fournisseurs, comme GMail, proposent également la même fonctionnalité.

RFC 2822, une lecture indispensable

La RFC 2822 (§ 3.2.4) donne la liste des caractères acceptables dans une adresse e-mail, mis à part le "@" qui sert de séparateur : tout caractère alphanumérique, mais aussi les symboles "!", "#", "$", "%", "&", "'" (apostrophe), "*", "+", "-", "/", "=", "?", "^", "_", "`" (backtick), "{", "|", "}", "~". Le point est aussi accepté, sauf en début ou en fin de chaîne de caractère.

Cela signifie donc qu'une adresse comme « !&'}.|`?@example.com » est tout à fait valable et que tous ceux qui rejettent cette adresse e-mail violent la RFC 2822. Je dispose d'une liste croissante de sociétés, dont des FAI (voyez l'ironie) et des banques, qui rejettent mes adresses contenant juste un « plus ». C'est consternant, car des bibliothèques faisant cette validation syntaxique cor­rec­tement existent déjà et qu'il est donc parfaitement inutile de réinventer une roue carrée.

Un petit plus qui casse tout

Maintenant que j'ai fait cette petite parenthèse sur tous les caractères qu'on peut mettre dans une adresse mail, revenons au sujet. L'histoire remonte à l'an dernier. À cause d'un mauvais algorithme de validation d'adresses e-mail et d'une ribambelle d'autres bugs, j'ai en effet réussi à "casser" le site moncompteformation.gouv.fr d'une façon que je n'aurais jamais cru possible.

J'ai voulu créer mon compte en remplissant le formulaire, où l'on demande : numéro de Sécurité sociale, nom, prénom, adresse e-mail et d'autres joyeusetés. Ce faisant, j'ai pris soin de saisir une adresse e-mail avec comme partie utilisateur « x0r+cpf ».

Je valide. Le formulaire passe. Mon adresse e-mail est acceptée et on me laisse donc passer à l'étape suivante, qui consiste à choisir un mot de passe. Je valide. Et là, erreur : impossible de créer le compte car mon adresse e-mail n'est pas valable.

Je me demande pourquoi cette validation ne s'est pas faite directement après avoir soumis le premier formulaire. Je reviens donc en arrière, en maugréant et en ajoutant un alias à la main dans la configuration Postfix ; je substitue alors un point au caractère plus dans mon adresse, ce qui devrait théoriquement passer.

Et là, nouvelle erreur : il existe déjà un compte avec ce numéro de Sécurité sociale.

Pourtant, c'est impossible : on m'avait pourtant dit que le compte ne pouvait pas être créé car « x0r+cpf » n'était pas valable. Je n'ai même pas reçu d'e-mail de confirmation. Il y avait bien eu un mail, en fait, d'après les logs de Postfix, mais il a dû se faire manger par SpamAssassin : un collègue m'a confirmé que le mail de confirmation était envoyé depuis une machine sans reverse DNS, ce qui va à l'encontre des bonnes pratiques. Étant donné que les spammeurs envoient souvent leurs spams depuis des machines sans reverse DNS, ce genre de messages finira dans les dossiers « Spams » à coup sûr chez beaucoup de monde.

Conclusion : je me retrouve avec un compte à moitié créé, auquel je n'ai pas accès car le mot de passe n'a jamais pu être défini pour ce compte. La base de données utilisant visiblement le numéro de Sécurité sociale comme clé primaire, il m'était impossible de recommencer.

La valse des analyseurs syntaxiques en mousse

La page de contact du site donne l'adresse e-mail du webmaster, que je m'empresse de contacter afin de lui expliquer les faits que je viens d'évoquer, et que je me retrouve du coup avec un compte inexploitable. En pensant que la plupart des clients e-mail de nos jours géreraient mon adresse correctement, je mets « x0r+cpf » dans le champ From. J'envoie.

Mes logs Postfix montrent ensuite que quelqu'un, ou un robot, a alors essayé d'envoyer un message à... « cpf ».

Non seulement ils valident mal les adresses, non seulement leurs machines n'ont pas de reverse DNS, mais quelqu'un ou quelque chose parvenait encore, en 2015, à mal extraire l'adresse e-mail du champ "From" d'un mail. L'e-mail tel qu'on le connaît existe pourtant depuis 1982.

Je crée donc encore un alias pour que les messages adressés à l'utilisateur « cpf » ne finissent pas à la cyber-poubelle, et je renvoie un deuxième mail pour informer le webmaster du dysfonctionnement. Même adresse From que le mail précédent, et même réponse sur la mauvaise adresse : c'était en fait un mail de confirmation envoyé par un robot d'une plate-forme d'e-mails destinée aux entreprises.

Enfin, à mon premier mail, je reçois en réponse un message à côté de la plaque me conseillant de faire des choses que j'avais déjà essayées : à savoir, m'inscrire, réinitialiser mon mot de passe, et ainsi de suite. J'avais pourtant déjà dit que j'avais essayé tout cela avant d'envoyer mon mail au webmaster.

En fin de compte, c'est seulement en décrochant le bon vieux téléphone (ou un téléphone IP chez moi, donc pas vraiment "bon vieux", certes) et en appelant le support technique que j'ai plus ou moins réussi à résoudre le problème : mon interlocutrice a su défaire cette tentative de création de compte qui avait échoué, puis tout a fini par rentrer dans l'ordre. Mais malheureusement sans caractère plus dans l'adresse e-mail.

Conclusion

Ce genre de situations montre bien ce à quoi peut aboutir plusieurs « petits » problèmes, qui, mis bout à bout, entraînent des résultats potentiellement catastrophiques :

• un algorithme de validation syntaxique d'adresses e-mail non conforme à la RFC 2822 ;
• une configuration de zone DNS non conforme aux bonnes pratiques (i.e. enregistrements PTR manquants pour les serveurs mail sortants) ;
• un processus de création de compte non atomique ;
• enfin, une plateforme e-mail de support technique buguée.

Ce qui me choque est surtout le fait que la création de compte ne soit pas atomique. L'atomicité signifie qu'à la fin, on a soit un compte parfaitement créé, soit rien du tout. Je vois d'ailleurs mal comment quelque chose d'aussi simple que l'ajout d'un seul tuple dans une seule table peut échouer de manière aussi catastrophique.

En fin de compte, si on dit que le développement informatique est le BTP des temps modernes, j'ai bien peur qu'on finira par être entouré de châteaux de cartes. Y compris dans le service public.

Avertissement : j'ai écrit ce billet à une époque où le service était uniquement disponible en béta fermée sur inscription. Beaucoup de choses ont sûrement évolué depuis.

Lorsqu'on met en place un site Web et qu'on souhaite servir son site en HTTPS, il faut tout d'abord obtenir un certificat SSL auprès d'une autorité de certification.

Ces certificats SSL sont généralement payants, pour des raisons diverses et variées. Il existe quelques autorités de certification gratuites mais de qualité très variable. Les AC gratuites ne sont en outre pas toujours reconnues par la plupart des navigateurs et ainsi, sans configuration spécifique côté client, un tel certificat peut entraîner l'affichage d'une alerte de sécurité. Alertes qui sont conçues pour faire peur, et pour une bonne raison.

Jusqu'à maintenant, il y avait CACert et StartSSL. Le premier fonctionne bien mais n'est pas reconnu. Le second se targue d'être reconnu, mais mes mauvaises expériences chez eux ne m'incitent pas à les recommander. Mais une troisième AC gratuite, reconnue et particulièrement prometteuse va bientôt voir le jour : Let's Encrypt.

Let's Encrypt est en effet une nouvelle autorité de certification SSL qui fournit gratuitement des certificats DV (Domain Validation). Cerise sur le gâteau, cette autorité de certification est reconnue par la plupart des navigateurs.

Il y a deux semaines, j'ai donc reçu dans ma boîte mail une invitation à la béta fermée de Let's Encrypt.

L'occasion parfaite pour, en guise de test, générer un certificat et une clé privée SSL par le biais de leur service pour x0r.fr. L'expérience est une réussite et je suis sûr que cette autorité de certification finira par modifier en profondeur le marché des certificats SSL.

J'expliquerai succinctement l'intérêt qu'a pour des blogueurs comme moi le fait de servir du HTTPS, avant de montrer comment j'ai mis en œuvre les outils de Let's Encrypt sous FreeBSD pour générer mon certificat SSL.

Pourquoi tout le monde devrait (en théorie) servir du HTTPS

Il fut un temps où l'on estimait que servir son site en HTTPS n'était utile que lorsqu'il y avait un vrai impératif de confidentialité, comme par exemple sur un site marchand où on est amené à saisir des informations sensibles (numéros de carte bleue, etc.). Mais ça, c'était en 1997.

Il ne faut pas oublier les autres avantages du HTTPS, qui sont entre autres la protection de la vie privée de l'utilisateur et la protection de l'intégrité des pages Web.

Par exemple, aux États-Unis, un fournisseur d'accès à Internet proposait des connexions Wi-Fi gratuites. Cependant ce FAI injectait des publicités dans les pages visitées par les utilisateurs. Ces publicités injectées étaient placées de telle manière qu'elles semblaient provenir du site Web lui-même.

Rien n'empêcherait non plus un fournisseur d'accès à lancer un petit tcpdump et à enregistrer tous les paquets ayant comme port de destination 80, afin de logguer les sites consultés par chaque utilisateur.

En fin de compte, servir du HTTPS ne signifie en rien qu'on a forcément quelque chose à cacher ; il est aussi utile pour se protéger des intermédiaires techniques parfois peu scrupuleux. Et il paraît absurde de nos jours de vouloir restreindre cette protection à ceux qui seraient prêts à mettre des dizaines voire centaines d'euros par an pour cela. Dans un Web universel, le HTTPS devrait donc être accessible à tous, tant consommateurs que producteur de contenus.

Mise en œuvre de Let's Encrypt

Un des buts de Let's Encrypt est d'automatiser le plus possible les tâches de génération de clés publiques et privées d'une part et la génération de la requête de certification d'autre part. Avouons-le, qui s'est rappelé de la ligne de commandes d'openssl(1) du premier coup ?

Pour cela, l'autorité de certification fournit un programme, letsencrypt, qui se charge de gérer de façon automatisée les certificats.

Les certificats de Let's Encrypt étant des certificats DV (Domain Validation), dont la seule garantie est de « prouver » qu'ils ont été distribués au propriétaire légitime du domaine, le programme letsencrypt se charge aussi d'apporter la preuve que le demandeur du certificat contrôle bien le nom de domaine qu'il demande.

Le serveur d'authentification effectue pour cela une authentification par défi-réponse : le défi est un chemin (relatif à la racine du domaine) généré au hasard et supposé ne pas exister auparavant. La réponse est une chaîne de caractères qui doit être servie au format MIME text/plain par le serveur HTTP en réponse à un GET sur l'URL du défi.

Par défaut, letsencrypt veut ouvrir les ports 80 et 443 et écouter sur ces ports pour effectuer la validation par défi-réponse. Ceci est généralement impossible ; après tout, la plupart des gens qui souhaitent mettre en œuvre HTTPS ont déjà leur site en HTTP uniquement, et vraisemblablement un Apache, lighttpd ou nginx qui écoute sur ces deux ports. Il existe heureusement deux solutions : une manuelle, l'autre automatique. Les deux nécessitent cependant de modifier les fichiers de configuration du serveur Web ; je ne montrerai ici que nginx car je n'ai pas testé d'autres configurations.

Première installation et mise en œuvre de letsencrypt-auto

Note importante : le logiciel évolue assez rapidement ; aussi les bugs exhibés dans ce paragraphe pour­raient être résolus depuis, de nouveaux bugs pourraient s'être glissés depuis et le fonctionnement et les messages affichés à l'écran peuvant différer de ce qui est transcrit ici.

Mise à jour du 12 janvier 2016 : sous FreeBSD, le logiciel est désormais disponible dans la collection des ports FreeBSD. Le port s'appelle security/py-letsencrypt et le package pkgng s'appelle py27-letsencrypt. Installez-le par ce biais, c'est plus propre.

L'installation de letsencrypt et de ses dépendances commence par le clonage du dépôt Github.

# git clone 'https://github.com/letsencrypt/letsencrypt.git'
# cd letsencrypt/

Sa première mise en place devait normalement être faite par la commande ci-dessous, mais qui ne fonctionnait pas au moment de mes essais :

# ./letsencrypt-auto --debug
Bootstrapping dependencies for FreeBSD...
./letsencrypt-auto: : Permission denied

Pour obtenir le même résultat, il a fallu que j'enchaîne les deux commandes :

# sh bootstrap/freebsd.sh
# sh -x ./letsencrypt-auto --debug

Authentification manuelle

Lors de mes premiers essais, j'ai uniquement trouvé la méthode manuelle. Celle-ci s'invoque de la manière suivante :

# ./letsencrypt-auto --server https://acme-v01.api.letsencrypt.org/directory -a manual certonly

L'outil affiche pas mal de texte avant d'imprimer ceci à l'écran :

Make sure your web server displays the following content at
http://example.com/.well-known/acme-challenge/N5_Uft_vn0XL0sGfsYsvNCfEzWkm77iHTlmY-hPBT6A before continuing:

N5_Uft_vn0XL0sGfsYsvNCfEzWkm77iHTlmY-hPBT6A.G_2TWMVNdOlzHIUDK_XG9n_c8Bkk3yrAiwb-U-HSNxM

Content-Type header MUST be set to text/plain.

(snip)

Press ENTER to continue

On modifie ensuite la configuration nginx pour ajouter la clause suivante :

location /.well-known/acme-challenge/N5_Uft_vn0XL0sGfsYsvNCfEzWkm77iHTlmY-hPBT6A {
    default_type 'text/plain';
    return 200 'N5_Uft_vn0XL0sGfsYsvNCfEzWkm77iHTlmY-hPBT6A.G_2TWMVNdOlzHIUDK_XG9n_c8Bkk3yrAiwb-U-HSNxM';
}

On reload nginx et on appuie sur ENTRÉE. Si tout se passe bien, on obtient le message suivant :

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at
   /etc/letsencrypt/live/example.com/fullchain.pem. Your cert will expire
   on 2016-02-04. To obtain a new version of the certificate in the
   future, simply run Let's Encrypt again.

Renouvellement automatique

Mise à jour du 12 janvier 2016 : l'option --accept-dev-preview a été remplacée par --accept-tos depuis la béta ouverte.

Les certificats fournis par Let's Encrypt ne sont valables que 90 jours. Cette durée de validité est très courte et semble prendre à contrepied la politique de la plupart des autorités de certification, qui proposent des certificats valables entre 6 mois et 2 ans.

Lorsqu'on administre qu'un seul site Web, ce n'est pas très fastidieux de devoir modifier seulement quatre lignes de configuration nginx tous les deux à trois mois. Mais à partir de deux, ça devient vite peu pratique.

Heureusement, la tâche de renouvellement se prête bien à l'automatisation, moyennant deux modi­fi­cations. La première est d'utiliser letsencrypt avec l'option -a webroot au lieu de -a manual. Cela demande à letsencrypt de faire l'authentification par challenge-response en plaçant un fichier adéquat dans le sous-répertoire .well-known/acme-challenge dans l'emplacement de son choix. La deuxième est de modifier la configuration de nginx pour servir le contenu des fichiers de ce sous-répertoire.

Ces informations (ainsi que le gist de renchap) me permettent de faire le script shell de renouvellement, dont voici le listing.

#!/bin/sh

LETSENCRYPT="/root/.local/share/letsencrypt/bin/letsencrypt"
DIR="/tmp/letsencrypt-auto"
DOMAINS="-d example.com -d www.example.com"

mkdir -p "${DIR}" && \
${LETSENCRYPT} certonly \
    --agree-tos --renew -a webroot --webroot-path "${DIR}" \
    --server https://acme-v01.api.letsencrypt.org/directory ${DOMAINS} && \
service nginx reload

J'associe ce script avec un fichier de configuration nginx que j'ai appelé letsencrypt.conf, dont voici le contenu :

location '/.well-known/acme-challenge' {
    default_type "text/plain";
    root /tmp/letsencrypt-auto;
}

Enfin, j'inclus ce fichier de configuration à l'aide d'un include 'letsencrypt.conf'; dans la configuration de chacun de mes vhosts.

J'ai pu vérifier que ce script renouvelle bien le certificat pour x0r.fr avec comme nom alternatif www.x0r.fr.

Lorsqu'on a plusieurs sites Web sur la même machine, il faudra lancer ce script plusieurs fois (une fois par site) afin de générer des certificats (et donc des clés privées) différents par site.

Place au test

Après avoir mis en place les certificats et adapté ma configuration nginx, mon site réussit haut la main le test SSL de SSL Labs. Il ne reste plus qu'à mettre en place HSTS pour avoir la note A+.

Conclusion

L'approche de Let's Encrypt tranche radicalement avec les habitudes des autres autorités de certification SSL que j'ai pu connaître. Le fait qu'il s'agisse d'un système entièrement automatisé, la faible durée de vie des certificats, la gratuité et le fait que l'autorité de certification soit reconnue dans la plupart des navigateurs en font quelque chose d'unique.

Let's Encrypt n'aurait à mon avis pas pu exister sans le contexte des écoutes en masse par la NSA qui ont été révélées par Edward Snowden, ni sans les problématiques du respect de la vie privée ou de la neutralité des réseaux. Il s'agissait là de donner la possibilité à n'importe qui de déployer du HTTPS facilement. Ce pari me semble bien parti pour être réussi.

Cela fait certes un bon moment que je n'ai pas écrit de billet sur monrer.fr. Il faut avouer que le site Web n'a connu que peu de dysfonctionnements (de ce que j'ai pu voir, en tout cas). J'ai eu peu de temps également cette année pour le faire réellement évoluer. Il n'y a pas non plus eu de grands bouleversements côté SNCF et Open Data de manière générale.

Je pense malgré tout qu'un petit billet à propos de ce petit site est le bienvenu, histoire quand même de traiter les quelques évolutions que j'ai faites et ce que j'envisage dans l'avenir.

Un exercice de responsive design

Jusqu'à récemment, je faisais encore partie des quelques réfractaires qui ne voyait pas l'utilité d'un smartphone. Mais j'ai fini par craquer, entre autres à cause de la mauvaise qualité de construction de mon précédent téléphone.

J'ai cependant fait l'acquisition d'un smartphone durant l'été dernier, et cela a été l'occasion pour moi de reprendre le design du site. Il avait en effet un grand besoin d'être refait en « responsive design », c'est-à-dire être capable de s'adapter dynamiquement en fonction de la largeur de l'écran. Ainsi, le site devient (à peu près) utilisable sur un smartphone.

Ce n'est pas encore parfait à mon goût, mais étant donné que je partais d'assez loin, c'est toujours mieux que rien.

Les quotas d'appels d'API

Rappelons cependant que les horaires temps réel de la SNCF sont fournis par une API Open Data que le site Web interroge dès qu'un visiteur demande de voir les horaires d'une gare particulière. Or l'accès à cette API est limité à 20 appels par minute, ce qui impose de mettre en œuvre des dispositifs afin de pouvoir assurer un service de qualité pour le plus de monde possible.

Pour m'assurer de cela, j'utilise depuis un moment un outil me permettant de surveiller l'utilisation de mon quota d'appels API, dont voici un exemple.

Les mesures techniques que j'ai mises en place consistent principalement en des mécanismes de mise en cache assez agressives mais qui donnent jusqu'à maintenant pleinement satisfaction. Je vais les détailler dans la section qui suit.

Mécanismes de mise en cache

La principale mesure technique, qui m'a permis jusqu'à maintenant de faire le maximum avec cette API, consiste à mettre en cache les résultats affichés sur le site. Ainsi, lorsque n personnes demandent simultanément la même gare, le site effectue une requête API SNCF pour la première personne, effectue les calculs de retard et autres traitements avant affichage, puis met en cache le résultat côté serveur. Ainsi, les n – 1 autres utilisateurs reçoivent une copie de ce qui a été mis en cache pour le premier. Étant donné que l'affichage de monrer.fr est rafraîchi toutes les 12 secondes, cela permet de servir n personnes en n'utilisant que 5 appels API par minute au lieu de 5n.

Cette première mesure technique permet donc de passer de 4 utilisateurs simultanés à un nombre illimité d'utilisateurs consultant au maximum 4 gares différentes.

La seconde mesure technique permet, pour un nombre n d'utilisateurs consultant une gare, de passer de 5 appels à un seul appel API par minute. En effet j'ai constaté que la SNCF met à jour les horaires temps réel une fois par minute. Afin de garder les données les plus fraîches possibles, je sollicite toujours l'API 5 fois par minute tant que les données renvoyées ne changent pas, puis je passe à 1 appel par minute dès la première différence. Autrement dit, le temps d'expiration du cache passe de 12 à 60 secondes.

Ce second mécanisme me permet donc de passer de 4 consultations de gares différentes simultanées à un nombre variant entre 4 et 20 sans pour autant trop perdre en délai.

Horaires temps réel du RER A et B : hélas pas pour tout de suite

Étant donné que les grands absents des horaires temps réel Open Data restent toujours ceux du RER A et B, j'ai contacté la RATP il y a un peu plus d'un mois pour savoir où en était une éventuelle mise à disposition. On m'a répondu que cela faisait partie de leurs souhaits mais qu'il ne leur était pas encore permis de le faire. J'espère bien entendu pouvoir vous faire profiter de ces horaires temps réel dès qu'ils sont disponibles et j'espère également pouvoir être au premier rang comme lorsque la SNCF était en train de mettre le système en place il y a deux ans.

Je dispose néanmoins des horaires théoriques pour ces deux lignes du RER, mais il m'est donc impossible pour le moment d'afficher les heures de passage prévus de chaque train, compte tenu de leur éventuel retard.

En conclusion : vous êtes de plus en plus nombreux…

Depuis le début du mois de septembre, vous êtes de plus en plus nombreux à utiliser ce site ; si bien que les dépassements de quota sont parfois quotidiens (cf. supra). Le principal symptôme est que le site n'affiche que les horaires théoriques de temps à autres.

J'ai essayé plusieurs fois de contacter le responsable Open Data Transilien (j'en profite pour le saluer au passage) afin de discuter d'un éventuel assouplissement de ce quota pour moi, mais je n'ai hélas reçu aucune réponse.

Je me retrouve maintenant face à une multitude d'options pour que monrer.fr puisse continuer à croître et à être utile pour le plus de gens possibles tout en limitant les abus. Ce que je voyais initialement comme un jouet semble plaire à d'autres et je vois cela comme un encouragement pour continuer.

Aujourd'hui, j'ai reçu un petit colis de WASD Keyboards.

J'avais franchement besoin de remplacer intégralement les touches de mon clavier mécanique. J'avais acheté en 2012 deux claviers Leopold, l'un avec des interrupteurs Cherry MX Blue, pour chez moi, et l'autre avec des Cherry MX Brown pour un usage au boulot. Ce dernier est mon outil de travail de prédilection, bien que j'aie été contraint d'installer des coussinets en mousse sous chaque touche pour absorber un peu le bruit.

Pour faire simple, j'aime beaucoup ce clavier. Je ne me vois certainement pas revenir en arrière vers des claviers traditionnels. Le principal problème que j'ai eu cependant est la qualité de construction des touches. Au bout de quelques années, les touches en plastique commençaient à montrer des signes de faiblesse.

Au bout de quelques années de Vim, voilà l'état dans lequel je pouvais retrouver une touche.

Une touche cassée comme ça n'est heureusement pas difficile à réparer : recollez avec de la Loctite®, pressez avec une pince plate, attendez un peu et c'est reparti. Mais quand c'est la trente-quatrième touche qu'on doit réparer comme ça, au bout d'un moment, j'ai craqué.

Le site WASD Keyboards propose un petit outil sympathique qui permet de concevoir sa propre disposition de clavier (on peut même leur envoyer un fichier .svg lorsqu'on souhaite modifier les impressions sur les touches). J'en profite aussi pour subsituer un logo Tux aux touches « Windows », un « awesomeface » à la touche F5, une touche Compose à la touche « Alt Gr » et à ajouter des flèches directionnelles sur les touches HJKL. Sept ans de Vim et plusieurs années de i3 et de awesome auront fait leur boulot. Enfin, quatre-vingt-sept changements de touches plus tard, voilà le résultat :

Bien que mon clavier soit un Leopold, toutes les touches de WASD Keyboards passent sans problème dessus… à l'exception de la barre d'espacement : les trois points d'attache de la barre d'espacement ne correspondent pas à ceux prévus à cet effet sur le Leopold. Il vous faudra donc garder la barre d'espacement de votre Leopold si vous envisagez de faire la même chose.

En tout cas, WASD Keyboards a l'air d'avoir fait un superbe boulot (les photos au smartphone ne font hélas pas vraiment justice). D'autant plus qu'on fait de son clavier mécanique un outil véritablement personnalisé. Il ne reste plus qu'à voir combien de temps ces touches vont tenir !

Il y a trois ans, lors du vide-greniers annuel que j'aime tant fréquenter, j'avais mis la main sur un Minitel 1B. Cette année, j'y ai mis la main sur un téléphone à cadran Socotel S63.

Pour la petite histoire, ce téléphone a été fabriqué par la Société des Constructeurs de Téléphone et dont les premiers modèles dateraient de 1963. Je suis hélas trop jeune pour les avoir connus, mais ces téléphones sont apparemment très répandus en France et en ouvrant un peu l'œil, on peut en trouver de nombreux exemplaires dans des vide-greniers.

Le mien sera bien entendu branché sur ma tour servant de PBX avec Asterisk, grâce à sa carte OpenVox A400P.

Numérotation à impulsions

Ce téléphone à cadrans utilise cependant l'ancien système de numérotation à impulsions, contrairement à la numérotation à fréquences vocales (DTMF) quasi-omniprésente de nos jours.

Le système de numérotation à impulsions (aussi appelée numérotation décimale) consiste à envoyer des trains d'impulsions sur la ligne téléphonique : une impulsion pour le chiffre 1, deux pour le chiffre 2, et ainsi de suite jusqu'à dix pour le chiffre 0. Ces impulsions consistent en une ouverture du circuit de la ligne pendant 33,3 ms (comme si on appuyait sur le bouton de raccrochage) puis une fermeture du circuit pendant 66,7 ms.

Ce système est toujours accepté sur les commutateurs téléphoniques de France Télécom (si vous possédez une ligne fixe « classique » non liée à une offre VoIP d'une box quelconque), mais n'est plus acceptée par les box Internet. Ces box nécessitent l'adjonction d'un boîtier de conversion de numérotation décimale vers DTMF au téléphone pour pouvoir numéroter correctement.

Cela dit, Asterisk accepte également la numérotation par impulsions. Cependant, pour que cela fonctionne correctement, il faut charger le module wctdm (pilote de la carte OpenVox A400P) avec l'option dialdebounce=32. Cette valeur est positionnée par défaut à 64 (millisecondes), empêchant la bonne détection des impulsions : un 1 qui n'est pas détecté du tout, un 4 qui devient un 2 ou un 3...

Mon fichier /etc/modprobe.d/dahdi.conf sur mon système est ainsi le suivant :

options wctdm opermode=TBR21 dialdebounce=32

Avec cette ligne, le Socotel marche à merveille, et il m'est alors possible de faire sonner mon téléphone IP sur mon bureau en composant son numéro interne sur le cadran du Socotel. Ou bien d'entendre la sonnerie si appréciée du Socotel en composant son numéro sur mon téléphone IP. Cerise sur le gâteau : je peux même passer des appels via ma ligne téléphonique Livebox, alors que la box elle-même n'accepte pas la numérotation à impulsions ; Asterisk faisant lui-même la conversion entre impulsions et DTMF.

Je tiens à préciser qu'aucune autre modification de la configuration d'Asterisk n'est nécessaire pour accepter la numérotation décimale.

Petite optimisation de sonnerie et de présentation du numéro

J'en profite pour documenter une petite optimisation que j'ai trouvée pour réduire le délai entre le début de la sonnerie d'une ligne analogique et l'affichage du numéro sur un téléphone analogique avec présentation du numéro.

En effet, en France, le numéro de l'appelant est transmis entre la première et la deuxième sonnerie. Or certains téléphones analogiques ne sonnent pas tant qu'ils n'ont pas reçu le numéro de l'appelant, ce qui les font systématiquement sonner avec 4 secondes de retard par rapport à mes téléphones IP...

C'est pour cela que France Télécom modifie sa cadence de sonnerie pour ne faire qu'une courte première sonnerie (250 ms), puis une pause de 2 secondes pour transmettre le numéro de l'appelant, pour ensuite continuer avec la cadence normale de sonnerie (1,5 s puis 3,5 s de silence).

Pour faire de même, il suffit de paramétrer /etc/asterisk/chan_dahdi.conf ainsi :

[channels]

progzone=fr
defaultzone=fr
cadence=250,-2000,1500,3500,1500,3500,1500,3500,1500,3500,1500,3500,1500,3500,1500,3500

Ensuite, il faut modifier son plan de numérotation (extensions.conf) afin de substituer les canaux DAHDI/Xr1 à DAHDI/X. Par exemple Dial(DAHDI/1) devient Dial(DAHDI/1r1).

Il ne reste plus qu'à recharger le module noyau wctdm (oui oui, il le faut) puis redémarrer Asterisk pour appliquer ces changements.