Free Mobile propose un système de filtrage des appels, entrants ou sortants, assez poussé.

Ça tombe bien, je suis client chez eux, et depuis le 1ᵉʳ janvier, les démarcheurs ne peuvent utiliser qu’une liste précise de numéros, à savoir :

01 62 ** ** **
01 63 ** ** **
02 70 ** ** **
02 71 ** ** **
03 77 ** ** **
03 78 ** ** **
04 24 ** ** **
04 25 ** ** **
05 68 ** ** **
05 69 ** ** **
09 48 ** ** **
09 49 ** ** **

Autrement dit, pour bloquer — en théorie — tous les démarcheurs, vous pouvez créer 10 règles de blocages et le démarchage sera du passé.
Bien-sûr, ça serait le cas si tous ces harceleurs publicitaires respectaient les règles. J’en doute. Néanmoins, un tel filtrage devraient en bloquer un certain nombre.

Si vous êtes client Free Mobile, allez dans votre espace client > mes services.

Activez l’option (gratuite) du filtrage des appels :

Ensuite, cliquez sur le petit crayon pour ajouter des règles :

Vous avez alors un formulaire comme ça :

Ce formulaire est assez rapide à comprendre, mais il est un peu bugué.

En particulier pour ce qui est de « entrante » et « sortante » : si vous cochez les deux, seul le « sortante » ne sera pris en compte. Le mieux est donc de ne cocher que le « entrante », et de remplir le reste exactement comme suit, puis de valider :

Ensuite, vous faites pareil pour les autres numéros, avec à chaque fois les 4 premiers chiffres de la plage de numéros de démarchage, puis un astérisque « * ».

À la fin, vous aurez toute la liste de bloquée :

Et voilà, normalement plus aucun numéro de démarchage — en tout cas ceux qui respectent la loi — ne devrait vous parvenir, quel que soit votre téléphone (Android, iOS…) car le filtre se fait directement au niveau de l’opérateur téléphonique.

Il est même possible (à vérifier, chez les clients Free pour le téléphone fixe) que ça bloque aussi sur votre fixe.

On verra si ça marche.
Autrement, quel que soit votre opérateur, il y a l’application Orange Téléphone qui est pas mal du tout. Elle a une grande base de données de numéros fumeux, renseigné par les utilisateurs. Une fois installée, l’application regarde le numéro appelant et bloque (ou rend silencieux) un appel détecté comme étant du spam.

L’appli Orange :

• sur iOS
• sur Android

image d’en-tête de Brecht Bug

gneugneugneu j’ai pas besoin de pneus neige, j’ai un 4x4.

Combien de fois faut pas l’entendre ça ?

Regardez les comparatifs : 4WD VS Winter Tyres - Do you need winter tyres if you have 4WD? - YouTube.

Là il fait le test, sur la neige :

• un 4x4 (AWD) en pneus été
• un 2x4 (2WD) en pneus neige

Le résultat est sans appel : ce sont les pneus qui font tout. Et pas qu’un peu : la différence est grande.

Maintenant deux choses très importantes que n’ont absolument pas compris ceux qui râlent contre la loi Montagne (la loi obligeant les équipements hivernaux dans certains départements) :

1. Les pneus neige ne sont pas juste des pneus avec plus de crampons.
2. Les départements concernés ne le sont pas seulement parce qu’il y a plus de neige.

Concernant le #1 : La gomme est différente également.
Par temps froid, le caoutchouc se vitrifie (au niveau moléculaire) et devient dure et lisse comme du verre. Dans les pneus été, la température de transition vitreuse (T°g) est à environ 7 °C.

Dans les pneus hiver, il est beaucoup plus bas (ce brevet de Michelin parle d’un T°g entre 0 °C et −80 °C) : la gomme reste tendre et le pneu conserve son adhérence et sa souplesse.

Donc on peut bien avoir un Hummer si on veut, mais si on a des pneus glissants comme du verre, ça reviendra à rouler sur des peaux de bananes.

Concernant le #2 : Les départements concernés sont montagneux, ce qui signifie qu’il y a des montés et des descentes partout. Je parle de pentes >5 % avec 100 à 400 m de dénivelés à chaque fois, quand c’est pas nettement plus localement, y compris sur autoroute, et globalement absolument partout. Ce n’est pas le Nord ou la Belgique (ni les Pays-Bas) où la seule montée est celle du trottoir que vous obstruez.

Voilà un autre exemple, où ils comparent une citadine en traction et 2 pneus hiver, et un 4x4 avec quatre pneus été. Certes, le 4x4 est bien plus lourd dans leur test. Mais il l’est aussi dans la réalité : votre 4x4 est plus lourd qu’une petite voiture, et finira dans le fossé dès qu’il y a un peu de neige.

Et concernant les pneus 4 saisons ?

Voir ici et là.

Là le résultat est plus mitigé :

• sur des transmissions identiques (2x4 à chaque fois), le pneu hiver/neige a très largement l’avantage.
• sur des transmissions différentes : 2x4 en pneu hiver VS 4x4 en pneu quatre saisons, le facteur « quatre roues motrices » tire son épingle du jeu : l’accélération est meilleure, tout comme le fait de grimper une montée (par contre il compare avec un pickup ; j’aurais aimé voir sur une citadine normale).

Si on devait classer tout ça, du meilleur au pire et en extrapolant sur les configurations qui n’ont pas été essayées :

1. 4x4 en pneu hiver
2. 4x4 en pneu quatre saisons
3. 2x4 en pneu hiver
4. 2x4 en pneu quatre saisons
5. 4x4 en pneu été
6. 2x4 en pneu été

On constate qu’avoir des pneus adapté est plus important qu’une transmission intégrale (4x4). Le pneu 4 saisons est un bon compromis, mais sur la neige, il ne vaut pas un pneu hiver (et en été, en termes de consommation de carburant et usure, il ne vaudra pas un pneu été).

En ce qui me concerne : je continuerais à faire changer mes pneus deux fois par an : pneus été en été, et pneus hiver en hiver.
En hiver, je le fais par souci de sécurité : j’ai déjà roulé dans la neige, et les pneus hiver s’en sortent parfaitement, y a pas à dire. Ça reste une conduite sur la neige, mais ça n’agit pas comme des skis.

Et en été, par souci d’économie.
Aucune loi n’interdit d’utiliser un pneu hiver en été, c’est juste que si c’est pour bouffer les pneus en 1 000 km, c’est pas la peine.

Si le pneu hiver est adapté en hiver car reste tendre et conserve son adhérence, en été il est beaucoup trop tendre et s’use très vite, en plus de provoquer une surconsommation importante (beaucoup de pertes de couple dans le caoutchouc).

J’estime, mais il faudrait tester (je ne les ferais pas), que jongler avec deux sets de pneus revient moins cher que conserver juste un set de pneus 4 saisons. Ok, y a pas le changement à faire, mais le pneu 4 saison sera bouffé plus rapidement que les autres dans leur saison respective. Qui plus est, en été, le pneu été offrira un net avantage en termes de consommation de carburant : moins de pertes élastiques dans la gomme.

Et faut pas oublier que ce n’est pas une dépense supplémentaire : pendant que vous roulez en pneus hiver, les pneus été ne s’useront pas, et vice-versa. Vos deux sets combinés dureront par exemple 5 ans, là où un set seul durera 2,5 ans (voire moins, vu que l’usure sera plus rapide à cause de l’usage par des temps inappropriés).

Nostalgie oblige, il m’arrive parfois de chercher de vieux jeux de GameBoy (GB, GBC, GBA…) en ligne ou sur les brocantes, mais il faut faire attention car il circule de fausses cartouches.

Les fausses cartouches sont des système de jeu fonctionnels, mais la cartouche et le circuit à l’intérieur ne sont pas authentiques. Généralement ce sont des circuits récents et dans lequel on a enregistré le jeu que l’on veut puis qu’on a mis dans une cartouche elle aussi « fausse ».

Personnellement j’ai surtout constaté ça avec les jeux Pokémon (rouge, bleu, jaune, or, argent, cristal…) car ce sont ceux que je recherche.
Si vous voulez simplement jouer, ces cartouches vous le permettront sans problème et pour sûrement moins cher.

Mais si vous souhaitez une cartouche de jeu authentique, il faudra faire attention. Cet article vise à montrer comment différencier les fausses cartouches de cartouches authentiques.

L’examen est purement visuel, mais ça se fait très bien. Il y a plusieurs indices qu’on va voir ici.

L’effet « cheap »

Les contrefaçons sont essentiellement « cheap » : la facture est mauvaise, le plastique mal ébavuré, et les deux faces de la cartouche (qui sont maintenues par une vis) ne sont pas forcément l’une en face de l’autre. On voit que c’est du travail bâché, qu’on qualifierait couramment de « chinoiserie » bas de gamme.

La vis de maintien

Sur la cartouche, repérez la vis au dos.
Sur les cartouches GameBoy, ou GameBoy Color (ou Compatible GameBoy Color), bref, les grandes cartouches, la vis est une étoile à 6 branches vers l’extérieur (forme mâle) :

La plupart des contrefaçons ont une vis à trois branches vers l’intérieur (les branches sont « femelles »). Sur la GameBoy elle-même, Nintendo utilise des vis à trois branches, mais sur les cartouches ils ont toujours utilisé des vis à 6 branches.
Les cartouches pour GameBoy Advance comportent-elles bien des vis à trois branches.

Les inscriptions sur la cartouche

Un signe qui ne trompe pas : la cartouche authentique indique « Game Boy® » et de l’autre côté une fine bande avec « Nintendo ».
La plupart des fausses cartouches montrent « Game » et rien de l’autre côté.

La fiche de connexion de la cartouche

Sur la plupart des jeux (tous ?), en tout cas sur les jeux Pokémon, la cartouche ferme entièrement au niveau de l’entrée.
Sur certaines contrefaçons, on note une ouverture :

La dimension du circuit

La plupart des jeux GB et GBC ont un circuit qui fait la dimension de la cartouche. Certains jeux parmi les plus récents ont une cartouche au format GB, mais un circuit au format GBA (moins haute).
Dans les contrefaçons, notamment des jeux Pokémon, le circuit est petit dans une grande cartouche. Nintendo n’a jamais fait ça.

Cela peut se voir par transparence :

Conclusion

Voilà comment déceler les faux jeux qui circulent.

Notez que si vous achetez un jeu qui semble authentique mais dont la sauvegarde ne fonctionne pas, c’est sûrement parce que la pile interne (de la cartouche) est morte. Ces cartouches, anciennes, portaient une pile bouton (CR1616 ou CR2032 typiquement qui permettait d’alimenter la mémoire et de maintenir la sauvegarde intacte. C’était avant l’utilisation de mémoires flash, qui elles n’avaient pas besoin d’être sous tension en permanence.

Ces piles pouvaient fonctionner 10 ans sans problème, mais pour un jeu Pokémon Rouge ou Jaune, dîtes vous que ces jeux sont sortis il y a environ 23 ans en France. La pile est donc vide depuis des lustres.

Pour continuer à jouer, il faut changer la pile en dessoudant l’ancienne et en en soudant une neuve (qu’on trouve facilement en ligne, avec les languettes de fixation).

Juste quelques solutions pour le ménage chez vous (oui j’ai envie de partager ça).

Eau + IPA

Pour la maison (ou les vitres intérieures de la voiture).
Faites un mélange 50/50 d’alcool isopropylique (IPA, ou isopropanol — trouvable ici) et d’eau déminéralisé, et nettoyez une vitre avec ça.

En voiture, j’ai horreur des traces sur les vitres, tout comme sur l’écran d’un ordi. Sur l’extérieur, c’est saleté et calcaire, mais à l’intérieur c’est des corps gras qui émanent des cuirs et des éléments en plastique. Dans la maison, le gras de la cuisine se colle également sur les vitres.
Pour ça, ce mélange 50/50 est radical.

Sur la vitre rapidement débarassée de la poussière avec de l’eau puis essuyée, vaporisez le mélange sur une microfibre (elle doit être juste humide, mais pas gouttant) puis essuyez la vitre. Utilisez ensuite une microfibre propre et neuf pour essuyer le surplus complètement.

Ça fonctionne aussi pour dégraisser la gazinière ou autre. Au besoin, rajoutez du bicarbonate de soude (ce dernier agit mécaniquement : il ne faut justement pas le dissoudre complètement).

Pour le calcaire

Sur la vitre arrière de ma voiture, qui est relativement peu inclinée dans mon cas, l’eau ruisselait pas et des traces de calcaire s’accumulaient et l’ensemble ressemblait plus à une vitre de salle de bain qu’autre chose. Ça en devenait suffisamment critique pour que je juge ça dangereux : à contre jour on ne voyait plus rien).

J’ai essayé absolument tous les remèdes grand-mère : vinaigre froid, vinaigre chaud, citron, antical, éponge magique, alcool, argile… mais rien n’y fit.
Juste avant de passer par un polissage professionnel, j’ai réussi à tout retirer avec ce produit.

Ça contient de l’acide sulfurique, c’est peut-être pour ça que ça marche. Sur une vitre lavée à l’eau puis séchée, étalez une fine couche de produit en frottant avec une microfibre, laissez agir 5-10 minutes, remuez un peu, puis lavez à l’eau. Séchez la vitre avec de l’IPA et enfin sur une microfibre propre et sèche. C’est radical.

En revanche, ça n’a rien fait pour ma salle de bain : j’ai beau avoir laissé agir une nuit, je crois que le calcaire fait partie de la vitre désormais. Peut-être de l’acide sulfurique pure fonctionnerait, mais je n’essayerais pas, c’est bien trop dangereux.

Du vinaigre chaud pour le tartre dans une bouilloire

Celle-là je la note aussi, mais j’en avais déjà parlé je crois : mettez 100 mL (1/2 verre) de vinaigre blanc dans la bouilloire et complétez d’eau du robinet (assez pour que toute la partie entartrée soit immergée).
Faites ensuite bouillir l’ensemble. Ça devrait détartrer tout l’appareil du premier coup. Jetez le produit chaud dans l’évier (ça détartrera l’éviter en même temps) puis rincez 2 ou 3 fois la bouilloire.

Si les vapeurs du vinaigre vous importunent, vous pouvez faire ça dehors.

La javel pour les boules à thé

Si vous avez des boules à thé en ferraille, le gris laisse peu à peu place au marron. Ce n’est pas dangereux, mais c’est pas joli.
Pour ça, mettez vos boules à thé dans un verre ou un saladier. Ajoutez 100 mL de javel pure puis ajoutez de l’eau froide jusqu’à inonder complètement les boules à thé. Mélangez pour que la javel ne soit pas juste au fond. N’utilisez pas d’eau chaude : ça décompose l’hypochlorite de sodium de la javel et en retire toutes les propriétés nettoyantes et bactéricides (en plus de dégager du chlore).

Laissez agit 15 à 30 minutes en remuant une fois entre-temps.
Elles seront comme neuves à la fin. Rincez bien : le mieux est de les laisser dans l’eau claire pendant une heure puis rincer de nouveau une dernière fois.

Par contre ne faites pas ça dans votre théière en porcelaine ou en céramique. Premièrement, il est normal qu’une théière s’imprègne du thé au fil des années. Et deuxièmement, la Javel risquerait de l’attaquer et de rester dans les pores, ce qui n’est pas l’idéal.

image d’en-tête de alabama extension

Safari sur iOS (et sur Mac) n’utilisent pas Blink, mais Webkit. Apple est parti de son côté avec Webkit et du coup fait un peu n’importe quoi. Ayant désormais un iPhone, je me retrouve à corriger mes sites et outils pour iOS.

Voici quelques trucs et astuces. Cet article sera emmené à être étendu avec le temps.

Zoom lors du tap sur un champ texte

Safari nous zoom la page quand on tape sur un champ texte. Ça part d’une bonne intention, mais premièrement ça déforme la page, et ensuite, quand on sort du champ texte, ça ne dézoome pas. C’est stupide.

La solution qui marche, sans toutefois interdire le zoom à l’utilisateur (ça c’est très important), c’est mettre ce HTML dans votre <head> :

<meta name="viewport" content="initial-scale=1, maximum-scale=1, user-scalable=yes"/>

La magie vient du « maximum-scale ». Notez bien qu’il s’agit de l’échelle automatique. Le user-scalable="yes" assure que le zoom à deux doigts reste possible. Si vous mettez « user-scalable="no" », je n’aurais que deux mots : au bûcher !!

Le :hover sur iOS

Sur Vivaldi comme Firefox mobile (android), le :hover est activé lors du tap. Sur iOS il n’en est rien (enfin pas toujours). Ça se résout en ajoutant l’attribut « onclick » sur l’élément. Juste l’attribut, pas de valeur. iOS considère en effet que si l’on click, le hover s’active. Ici on clique, ça n’a pas d’effet directement, mais ça déclenche tout de même le hover.

Alternativement, et en mieux, on peut mettre dans son JS :

document.addEventListener("click", function() { });

Ce qui rend la correction plus rapide que d’ajouter onclick="" partout dans la page.

Certains parlent de mettre un « cursor: pointer » en CSS. Ça aurait été tout à fait pertinent que iOS active le :hover sur un élément dont le curseur est un pointeur (la petite main qui clique), mais malheureusement cette solution ne semble pas fonctionner.

Pour le parsage des dates en JS

La plupart des navigateurs, en JS, quand on leur donne un texte représentatif d’une date, essayent de parser ça comme ils peuvent. C’est censé marcher même quand on leur donne une date en langage naturel, comme « vendredi 4 mars 2022 », qu’ils traduiront en le bon objet de date.

Perso j’utilisais une chaîne de date-heure égale à « 2022-03-04 18:30:59 ». Firefox et Chrome n’ont pas de problèmes pour parser ça. Safari exige qu’on mette un « T » entre la date et l’heure : « 2022-03-04T18:30:59 », sinon il renvoie une erreur.

Safari a raison : le T pour « time » provient de l’ISO 8601 étendue et il faudrait l’inclure tout le temps.
Ceci est donc un rappel que ce n’est pas parce que ça marche sans le T que c’est une bonne pratique.

Placeholder sur [type=date]

Si vous avez un input de type date sans placeholder, alors Firefox et Chrome (blink) mettront une date vide : « jj / mm / aaaa ».

Safari (sur Mac) mettra la date du jour… mais en placeholder, donnant l’illusion que la date est remplie, alors que ce n’est pas le cas. Vérifiez bien que ça soit effectivement le cas dans vos app.

Étrangement, sur iOS, je n’ai pas ce souci, mais il est bien réel sur certaines versions de Safari sur Mac que j’ai pu voir (pas pu regarder plus en détail, désolé).

Les événements load, beforeunload, unload

Ces événements sont dépréciés sur iOS, et ne sont pas forcément fiables ailleurs. En effet, le comportement des utilisateurs sur mobile est de changer d’appli ou d’onglet sans fermer la page, donc sans « unload ». Le problème se pose aussi sur Android, même sur iOS, ces fonctions ne semblent plus fonctionner du tout, ce qui pose effectivement problème dans le cas où l’on ferme l’onglet en cours.

À la place, il est préférable d’utiliser l’événement « visibilitychange » (qui se lance quand on change d’application ou d’onglet) et « pagehide », qui est lancée à la fois quand on change la visibilité de l’onglet et juste avant qu’on le ferme. Dans les faits, pensez à utiliser les deux car le premier agit sur mobile et le second sur desktop. De plus, un bug sur Webkit fait que le « pageHide » n’est pas déclenché quand on change de page lors qu’on clique sur un lien dans celui-ci.

Plus d’information ici (avec un tableau de compatibilité). Et voyez là sur les événements supportés par iOS.

Enfin, il en va de même pour l’événement « load », qu’il faudrait remplacer par « pageshow ».

TL;DR : Une fois que vous avez essayé 1 ou 2 mots sur Sutom, allez sur cet outil, puis mettez le format du mot et renseignez les lettres à inclure ou à exclure.

Le format du mot à mettre est de la forme « A . . . ER. $ » où A est la première lettre, E une lettre bien placée, $ indique la fin du mot et les points sont des lettres à trouver.

Attention, les téléphones ont tendance à remplacer trois points par le caractère unique des points de suspension.

---

S’il y a bien un truc puissant en programmation, ce sont les expressions régulières, ou « regular expressions », Regex pour les intimes.

J’en avais déjà fait une petite introduction que je vous conseille de lire.

Aujourd’hui, voyons un usage à ces choses-là.
Depuis le début de l’année, le jeu Wordle (en anglais) et Sutom (en français) sont devenus viraux. Leur principe est celui du jeu télévisé « Motus ».

Sutom ?

Le principe du jeu est le suivant.

Le but est de deviner un mot.
La première lettre nous est toujours fournie. On connaît également la longueur du mot.
On a droit à 6 essais pour deviner le mot :

À chaque fois qu’on essaye un mot, on a des indices :

• les lettres bien placées sont en rouge
• les lettres présentes mais à leur mauvaise place sont en jaune
• les autres lettres ne figurent pas dans le mot

Dans cet exemple, celui du 21 janvier 2022, si j’essaye le mot « Diamètre », j’obtiens :

Je sais désormais que :
– Le mot fait 8 lettres (incluant le D au début)
– D et I sont bien placés
– E et R sont mal placés (mais présents).
– A, T et M sont exclus (grisés sur le clavier)

D’essai en essai, on accumule les indices et la solution nous apparaît plus ou moins facilement.
Motus était un jeu télévisé, mais sur ces petits jeux en ligne, il n’y a rien à gagner. Il y a un seul mot par jour.

Si vous trouvez, vous recevez un code rigolo à partager sur les réseaux sociaux qui représentent les couleurs des cases du tableau. Comme personne n’essaie les mêmes mots, il est généralement unique à vous pour ce jour-là. C’est amusant :).

Utiliser les Regex pour jouer à Sutom

Sutom demande deux choses qu’un ordinateur a :

• de la mémoire (du vocabulaire)
• de la logique

Il suffit d’une liste de mots connus suffisamment complète ainsi que quelques règles de base pour permettre à un ordinateur de jouer à Sutom.

On pourrait créer un solveur où l’on prend la grille en photo et il nous donne la réponse. Ce serait un exercice intéressant à plusieurs niveaux, mais ce n’est pas ce que je vais faire ici.

Je me contenterai ici d’utiliser une liste de mots et les Regex mentionnées plus haut pour trouver la solution grâce aux indices du jeu.

J’ai fait cette page : Rechercher un mot. Elle contient 340 000 mots et un champ de recherche.
L’intérêt est que la recherche fonctionne par Regex !

Le but de cet article est de créer une Regex puissante qui va très vite filtrer les mots et nous sortir le bon, généralement après 1 ou 2 essais seulement.

Pour l’exemple du 21 janvier 2022, le mot commence par D et fait 8 lettres.

On a donc cette Regex :

D.{7}$

Vous pouvez copier ça dans le champ de recherche de la page de recherche de mots.

La Regex signifie « un “D”, suivi de 7 lettres » (donc bien 8 au total). Le « $ » à la fin signifie que c’est la fin du mot après ça. Si on ne le met pas, il va nous sortir les mots de 8 lettres ou plus. Or nous ne voulons que les mots de 8 lettres.

À ce stade, ma page me sort 37 042 mots. On peut en utiliser un de la liste ou en poser un qu’on connaitrait déjà.

Dans mon cas, j’essaye « DIAMETRE ». J’obtiens les informations suivantes :
– D et I sont bien placés
– E et R sont mal placés (mais présents).
– A, T et M sont exclus (grisés sur le clavier)

Il faut donc un mot qui débute par DI, qui ne contienne pas A, T, M, mais qui contienne E, R. et dont la longueur totale fasse toujours 7 lettres.

Le début de la Regex est simple : le mot commence par DI.

La Regex débute donc tout naturellement par :

di

Ensuite, il faut dire que parmi tous les mots commençant par « DI », on veut ceux comportant E et R.

Il s’agit d’utiliser une assertion positive avant (positive lookahead), pour dire « je veux un E et un R après le DI ». Il existe aussi des assertions arrière, pour vérifier ce qui se trouve avant, mais ça ne nous intéresse pas ici.
L’assertion positive est inclue dans notre Regex sous la forme (?=REGEX). Elle contient elle-même une sous-Regex.

Notre sous-Regex est la forme « une lettre suivie de E ou de R ». La regex est triviale, mais comme on veut un E et un R, qu’importe l’ordre mais il nous faut les deux, il nous faut deux assertions :

(?=.*e)(?=.*r)

Maintenant un peu de technique interne aux Regex.

Normalement quand on cherche « ABC », il cherche un « A » suivi d’un « B » suivi d’un « C ». La chaîne « A1B1C1 » ne marche pas, car les trois lettres ne se suivent pas.

Effectivement, après avoir matché le « A », le parseur se positionne après le A. Il regarde donc s’il y a un « B » juste après, et ainsi de suite, à chaque fois en venant avancer dans la chaîne. Ainsi, quand on matche notre « AB », on avance de deux lettres dans le mot.

Les assertions servent à matcher des trucs, mais ne font pas avancer dans notre Regex globale. Quand on utilise l’assertion, on va parcourir le reste du mot et renvoyer un TRUE si un E et un R sont trouvés, mais on vient se remettre juste après le DI.

À ce stade, la Regex entière a filtrée les mots débutant par DI et contenant un E et un R.

Il reste à filtrer les mots pour éliminer ceux avec A, T, M.

Pour ça, on veut exclure des lettres. On va utiliser une assertion négative avant (negative lookahead) pour dire « je ne veux pas de A, T, M après le “DI” ».

L’assertion négative se construit avec (?!REGEX). Elle est négative, car on retourne FALSE si la REGEX à l’intérieur de l’assertion retourne TRUE.

Dans notre cas, on veut refuser A, T et M. Une seule assertion suffit car on veut éliminer les mots contenant une ou plusieurs des lettres parmi A, T, M :
Ce qui donne :

(?!.*[atm])

Maintenant, il nous reste à dire qu’il nous faut 6 lettres.
Inutile de lister les lettres : on peut utiliser le simple « . ». Les assertions ont déjà filtré les lettres qui nous intéressent ou non. On a donc :

.{6}

Mis bout à bout, on a :

di(?=.*e)(?=.*r)(?!.*[atm]).{6}$

Le filtre me trouve 34 mots (sur 340 000). Pas mal, mais pas suffisant pour gagner au jeu. Il faut en essayer un au hasard. J’essaye donc le mot « DISPOSER ».

Qui donne :

J’apprends donc que le mot est de forme « DI...SER ». J’apprends également qu’on peut éliminer les lettres O et P, en plus de A, T, M.

On peut donc modifier notre assertion négative avant pour filtrer ces deux lettres supplémentaires. De plus, le E et le R sont bien placés : on sait où ils sont. Notre assertion positive avant devient inutile.

La Regex globale devient :

di(?!.*[atopm]).{3}ser$

Qui signifie :

• « di »
• puis « on ne veut pas de A, T, O, P, M »
• puis on revient après le « di », on met trois lettres n’importe lesquelles
• puis on met « ser »
• et c’est la fin du mot.

Et là, bim, mon outil de recherche ne me sort plus qu’un seul mot.

Il se trouve que c’est le bon :

SUTOM #14 3/6

🟥🟥🟦🟦🟡🟦🟡🟦
🟥🟥🟦🟦🟦🟥🟥🟥
🟥🟥🟥🟥🟥🟥🟥🟥

Bingo !
Ou plutôt « Motus » !
(ou Sutom)

Bien-sûr cela fonctionne, car tous les mots dans le dictionnaire utilisé par le jeu sont contenus dans le dictionnaire de ma page.

Ma page n’utilise pas le même dictionnaire. C’est volontaire, car je veux un dictionnaire plus large. Mais il arrive bien à filtrer des choses.

Notez que ma page permet de filtrer les accents et les tirets aussi. Sutom ne les affiche pas (ou plutôt il compte le É ou le È comme un E).

---

Enfin, j’ai aussi un outil de visualisation de Regex. Il est repris d’un code déjà existant (pas de moi) mais ça permet de visualiser ce que signifient les expressions assez compliquées de Regex.

Voici une magnifique subtilité du CSS, mais parfaitement logique quand-même :

• The surprising behavior of !important in CSS custom property values

Que se passe-t-il si on met !important dans une variable ?

Voyons ça :

div {
  --color: red !important;
  color: var(--color);
  color: yellow;
}

À votre avis ça donne quoi ça en CSS ? Le point litigieux, c’est bien-sûr la présence du !important
Sauf qu’il est à savoir que le !important n’est pas sur une déclaration de propriété, mais sur une déclaration de variable CSS.

Or, une variable ne peut contenir qu’une valeur. La valeur contenue dans --color est donc red. Il faut savoir que le !important ne fait pas partie de la valeur : il s’agit d’un élément de langage qui permet de jouer sur la spécificité, comme un drapeau (un flag).

Résultat : la couleur finale du texte sera décidée par le vainqueur des deux déclarations de color juste en dessous. Comme celle-ci ont la même spécificité, c’est la dernière qui gagne.

Conclusion : le texte est en jaune.

!important n’est pas sans effet !

Maintenant, utiliser un !important dans les variables CSS n’est pas sans effet pour autant.
Regardons :

div {
  --color: red !important;
  --color: blue;
  color: var(--color);
}

Ici, aucune ambiguïté sur la déclaration de la couleur, puisqu’il n’y en a qu’une seule : color prendra la valeur contenue dans la variable --color. Oui mais laquelle ?

Réponse : celle dont la déclaration a la spécificité la plus grande ! Autrement dit, la première.
Conclusion : ça donnera du rouge.

Il convient donc de distinguer deux cas de figure :

div {
  --color: red !important;
  color: var(--color);
  color: blue;
}

div {
  --color: red;
  color: var(--color) !important;
  color: blue;
}

Dans le premier cas, les deux déclarations de couleur ont la même spécificité. C’est donc la dernière qui gagne : le texte sera bleu.
Dans le second cas, c’est la première déclaration qui a la plus grande spécificité (à cause du !important).

Peu importe qu’elle ait une variable ou non, c’est elle qui gagne : cela donnera du rouge.

Le conflit ? Quel conflit ?

Dans sa conclusion, l’article dit qu’il y a deux niveaux de « scope » (traduction ?) sur lesquelles sont appliqués le !important. Une sur les variables, et une sur les propriétés. Je ne suis pas d’accord avec ça : pour moi il n’y a en a qu’une seule. En revanche, il a deux déclarations différentes à considérer : une sur une variable, et une sur une propriété.
Maintenant, dans les deux cas, on peut ajouter un !important si l’on veut. Et comme ce sont deux choses différentes, elles n’entreront pas en conflit.

Appliquer deux !important à deux propriétés différentes n’est pas un problème :

div {
  font-weight: bold !important;
  color: red !important;
}

Ces deux choses n’entrent pas en conflit.
Par conséquent, les deux choses suivantes non plus :

div {
  --color: bleu !important;
  color: red !important;
}

Notez que ci-dessus, la variable --color est déclarée, mais jamais utilisée, donc aucun conflit à l’horizon.

Dans ce qui suit, toujours aucun conflit :

div {
  --color: bleu !important;
  color: var(--color) !important;
}

Tout est clair : la variable reçoit du bleu. La couleur reçoit la variable. Donc la couleur finale est bleue.

Et même s’il y avait plusieurs déclarations de la variable, celle qui gagne est celle de la plus grande spécificité. Ensuite, c’est la déclaration de la couleur avec la plus grande spécificité qui gagne. Ainsi l’exemple suivant donnera du rouge :

div {
  --color: red !important;
  --color: blue;
  color: var(--color) !important;
  color: green;
}

Parmi les variables, c’est le rouge qui gagne sur le bleu.
Parmi les propriétés, c’est celui avec le var() qui gagne sur celui avec le vert. Or la variable contient du rouge. Donc le texte sera rouge.

Applications à un contexte plus large

Tout ceci est évidemment à mettre dans un contexte plus global avec des déclarations sur des sélecteurs de spécificité différente.

div {
  --color: blue !important;
  color: var(--color);
}

div#foo {
  --color: orange;
  color: var(--color);
}

Ici ça sera… Bleu !

Regardons la couleur pour commencer. La couleur reçoit ce que contient la variable. Aucune ambiguïté. Et la règle qui s’applique est celle dans le second bloc. Pourquoi ? Parce que le sélecteur y est plus spécifique.

Maintenant que contient cette variable ? Cette variable est celle qui est la plus spécifique. Donc celle avec le !important. Donc le bleu.

En effet, même s’il y a un #id sur le sélecteur du second bloc, la variable --color ne contient pas de l’orange, mais du rouge : le !important sur une propriété est plus spécifique que la même propriété placée sur un ID (Spécificité de 1-0-0-0-1 au lieu de 0-1-0-0-1).

Par contre, il en est différent si le !important sous le deuxième bloc avait été sur la variable au lieu de la propriété :

div {
  --color: blue;
  color: var(--color)!important;
}

div#foo {
  --color: orange;
  color: var(--color);
}

Dans ce cas, la variable qui s’applique est l’orange dans le second bloc (car cette variable est plus spécifique à cause de l’ID dans le sélecteur). Le texte est donc orange.

Notons de façon anecdotique que la propriété qui s’applique est bien celle du premier bloc (car cette propriété a un !important).

Le vocabulaire est important : la propriété et la variable sont deux déclarations différentes. Elles ont chacune leur spécificité (au sens de « priorité CSS »).

Si je ne conserve que les éléments qui s’appliquent réellement, ça donne ceci :

div {

  color: var(--color) !important;
}

div#foo {
  --color: orange !important;

}

La couleur reçoit une variable, comme indiqué dans le premier bloc. Mais cette variable a une valeur assignée dans le second bloc seulement.

Ça vous semble casse gueule ? Attendez la suite.

Cas des sélecteurs enfants

Jusqu’à maintenant, même si on utilise deux sélecteurs différents, ils ciblent le même élément HTML.
Poursuivons les complications par quelques exemples pour montrer ce qui se passe avec avec des sélecteurs enfants.

Voyons :

div {
  --color: red !important;
  color: var(--color) !important;
}

div a {
  --color: orange;
  color: black;
}

La question : quelle est la couleur du lien ?
Réponse : noire.

Noire ? Oui, noire. La déclaration tout à la fin.

En effet, le premier bloc a beau avoir des !important sur toutes les propriétés, ils s’appliquent au div, tout comme leur spécificité.
Or, la spécificité n’est héritée que si la valeur sur laquelle elle s’applique est également héritée. En réalité, seule la propriété la plus spécifique est alors héritée (et la spécificité devient inutile).

Ainsi, pour savoir ce qui s’applique à notre a, on regarde le code destiné au a. C’est alors lui qui s’appliquera, s’il y en a. Et le a possède une déclaration de couleur : color: black;.
L’hérédité ne s’applique donc plus : on applique le color: black;, point barre.

L’hérédité ne s’applique qu’en l’absence de déclaration.

Ainsi, si on avait mis :

div {
  --color: red !important;
  color: var(--color) !important;
}
div a {
  --color: orange;
}

Alors, le texte serait rouge. La couleur du a serait héritée du div, et contiendra var(--color), qui, dans le contexte du div (le contexte hérité, donc), est rouge.

Pas orange ?

Non : l’orange est du contexte de a. Or la propriété de couleur est héritée du contexte de div, et là, dans son contexte, c’est bien du rouge que contient la variable. Ce qui est héritée, c’est la propriété et sa valeur.

On aurait même pu mettre un !important dans le second bloc, cela ne changera rien :

div {
  --color: red !important;
  color: var(--color) !important;
}
div a {
  --color: orange!important;
}

Cela rester rouge, pour la même raison : la couleur est héritée, même si elle provient d’une variable.

Si l’on voulait du orange, on doit ajouter un color: var(--color) dans le second bloc. Comme ça, la couleur du a est déclarée et non-héritée. Mais il faut bien conserver la déclaration de la variable dans le a, sinon la variable n’est plus déclarée et elle hérite.

Il faut retenir que la variable s’applique sur les propriétés du même contexte. Le parent transmet une propriété ? D’accord, mais sa valeur est également transmise, même si c’est une variable.

Par contre, dans le code suivant, la variable est bien héritée :

div {
  --color: red !important;
}
div a {
  color: var(--color);
}

Le a sera rouge. Ici, l’on ne déclare pas la variable --color dans le a. Elle est donc héritée. Or son parent lui dit que la variable contient du rouge. Donc le texte est en rouge.

Et avec des variables partagées sur plusieurs propriétés ?

La blague n’est pas terminée !
On arrive ici à quelque chose de très drôle : quid des variables appliquées à plusieurs propriétés, l’une déclarée et l’autre héritée ?

div {
  --color: white;
  color: var(--color);
}
div a {
  --color: black;
  background-color: var(--color);
}

Ça va donner quoi ?
Ici le texte dans le a sera bien en blanc sur fond noir !

Décomposons :

• La couleur du texte : la couleur n’est pas déclarée sur le a. Elle est donc héritée. Et l’héritage contient du blanc : c’est donc du blanc.
• Le couleur du fond : le fond est déclaré sur le a. Le fond contient var(--color). Et --color, dans ce contexte, contient du noir. Le fond est donc noir.

Si l’on n’avait pas déclaré le --color: black;, alors la variable aurait été héritée, et on aurait eu du blanc sur fond blanc. Mais comme on l’a redéfini dans le contexte du a, elle prend une nouvelle valeur… dans son contexte seulement.

Notez que dans ce dernier exemple on n’a mis aucun !important : normal, car la spécificité n’est pas héritée si la propriété sur laquelle elle est appliquée n’est pas elle-même héritée.

On aurait pu en mettre partout dans le premier bloc, on aurait tout de même eu du blanc sur du noir.

Conclusion

Pour moi tout est logique, même si c’est parfois compliqué.
Il faut retenir :

• !important s’applique à la déclaration de la variable. Mais elle n’est pas dans la valeur assignée à la variable.
• une variable CSS peut être déclarée plusieurs fois. Tout comme on peut déclarer plusieurs fois une couleur. Dans ces conditions, c’est la déclaration la plus spécifique qui est retenue. Si toutes ont la même spécificité, la dernière est retenue. C’est du CSS de base.
• concernant l’hérédité, rien n’est nouveau là non plus : les valeurs, même avec un !important ne sont transmis aux éléments enfants que si ces derniers ne les redéclarent pas. Ça vaut pour les variables comme pour les propriétés CSS.

Bref, c’est compliqué, un peu curieux, parfois casse-gueule, mais rien de nouveau.

Et rien de différent d’autre langages de prog non plus : les variables ont leur contexte et peuvent être redéfinies dans des boucles imbriquées d’où elles ne sortent pas (pensez au let en JS par exemple : deux variables redéclarées avec le même nom auront leur propre contexte :

let a = "bar";

function newScope() {
    let a = "foo";
    console.log(a); // "foo"
}

console.log(a); // "bar"

Ah et : ici on ne parle que de la propriété color. Je vous laisse imaginer ce que ça donne si l’on utilise des variables dans display, flex ou position, le tout assaisonnée de sélecteurs comme a ~ a et de pseudo-classes :not() ou :placeholder-shown. Ça promet, non ?

Ceci est une implémentation de l’idée que j’avais postée ici et qui concernait une gestion de cache basée sur le .htaccess et les erreur 404.

Le modèle habituel d’un cache statique PHP

Habituellement, pour gérer les caches de fichiers statique, on envoie une requête sur un fichier PHP qui va s’occuper de récupérer une ressource statique et l’envoyer vers le navigateur :

cache.php

<?php
    readfile($fichier_statique);
?>

Le $fichier_statique contient des données HTML déjà prêtes. Normalement, une fois que la page HTML est envoyée au visiteur, elle est oubliée de la mémoire de l’ordi. Si un autre visiteur fait la même requête, le serveur doit tout refaire.

L’idée d’un cache est de stocker le code HTML que l’on a envoyé au visiteur. Comme ça, si un second visiteur fait la même requête, on lui envoie ce qui se trouve en cache, sans avoir à tout recalculer : c’est beaucoup plus rapide.

Dans mon cas, je le fais avec des images d’avatar de chez Gravatar et avec des favicon que je met en face des sites dans mon lecteur RSS. Je ne fais pas une requête vers ces sites, mais vers mon lecteur RSS. C’est lui qui va faire une requête externe, sauver l’avatar ou la favicon localement, puis l’envoyer au client. La fois d’après, il envoie directement l’icône locale au client, sans faire de requête réseau. On gagne beaucoup en performances globales.

Le problème que je vois ici, c’est que le fichier cache.php est appelé pour chaque requête sur un fichier. C’est plus rapide que recalculer une miniature, mais une instance PHP est tout de même créée, ne serait-ce que pour lancer le readfile(), et éventuellement après quelques calculs rapides pour déterminer quel fichier cache on envoie au navigateur.

On peut s’affranchir de cette requête et de PHP.

Utiiliser .htaccess

On va prendre l’exemple du cache pour les images favicon et gravatar, car c’est ce que j’utilise et c’est ce pourquoi j’ai fait cette méthode.

Avant je faisais une requête vers cache.php?w=favicon&site=example.com
Et j’avais cette arborescence :

cache.php
var/
| - - cache/
      | - - favicon/
            | - - icone1.png
            | - - icone2.png
            | - - ...
      | - - gravatar/
            | - - avatar1.png
            | - - avatar2.png
            | - - ...
      | - - .htaccess

Quand je voulais une icône, je faisais un hit sur cache.php?get=icone1.png, et il m’envoyait l’icone1.png après l’avoir soit téléchargée, soit lue sur le disque.
Pour moi, l’image était située à l’URL cache.php?get=icone1.png, pas ailleurs.

Maintenant je fais autrement.

Je fais mon hit sur /var/cache/favicon/icone1.png. Plus besoin de PHP : si l’image existe, l’icône est envoyée directement.

Mais si le fichier n’existe pas, ça renvoie un 404, non ?

Exactement ! Mais ça, c’est uniquement si le fichier n’est pas là.
La distinction « fichier là / fichier pas là » n’est plus à faire par PHP comme avant : elle est déjà faite par le serveur (Apache, …), et on va s’en servir !

Il est possible d’utiliser une redirection en cas de 404. Dans le fichier .htaccess de notre arborescence, je vais mettre :

RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule (.*) ../../cache.php?w=gravatar&q=$1 [L]

L’important ici est le !-f de la première ligne.

Un simple -f signifierait « notre requête est un fichier ». Mais avec le point d’exclamation devant, ça signifie « notre requête n’est pas un fichier », dans le sens « un fichier qui n’est pas, qui n’existe pas ».

Si je demande un fichier qui n’est pas là (donc un 404), cette condition est est satisfait : « le fichier n’est pas ! » et on accède à la ligne suivante, c’est à dire le renvoie vers le script PHP.

Ce n’est pas une redirection 301 ou 302 : le serveur demande uniquement à PHP de s’occuper de la demande au lieu de s’en occuper lui-même par l’envoie d’une erreur 404.

Une fois que PHP a fait son boulot, il sauvegarde le fichier et la renvoie au navigateur : le navigateur ne reçoit jamais de 404 : si le fichier est là, le serveur lui donne. Si le fichier n’est pas là, PHP produit le fichier avant de lui donner également. Le fichier est également sauvegardé pour la prochaine fois.

En plus de ça, la requête est faite directement sur le fichier que l’on veut, pas sur une page à PHP qui devra lire le fichier. On gagne donc en logique aussi.

Pour aller plus loin

Comme je l’ai dit, j’utilise ce système à la fois pour des icônes de site et pour des avatars de commentaires. Il y a donc une distinction à un moment. Les images sont mis en cache dans deux répertoires dédiés :

var/
| - - cache/
      | - - favicon/
      | - - gravatar/
      | - - .htaccess

Aussi, une complication est de ne faire qu’un seul fichier .htaccess.

Pourquoi ? Car je ne veux pas mettre un .htaccess dans chaque dossier et ceci pour une raison simple : quand veux purger le cache (en supprimant le dossier et son contenu), je ne veux pas perdre mon fichier .htaccess.

Avec un seul fichier situé à un niveau plus haut, je supprime les dossier favicon/ et gravatar/ et c’est bon, ils seront recréés par PHP lors de la prochaine requête.

Mon .htaccess doit distinguer quel est le dossier où l’on fait la requête. Je fais ça comme ça :

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_URI} ./gravatar/(.*)$
RewriteRule (.*)gravatar/(.*)$ ../../favatar.php?w=gravatar&q=$2 [L]

Explication ligne par ligne :

RewriteCond %{REQUEST_FILENAME} !-f

↑ Je regarde si le fichier existe. Si oui, le fichier est envoyé au navigateur et ça s’arrête. Autrement on continue.

RewriteCond %{REQUEST_URI} ./favicon/(.*)$

↑ Je regarde sur la requête concerne un fichier dans /favicon

RewriteRule (.*)favicon/(.*)$ ../../favatar.php?w=favicon&q=$2 [L]

↑ Si oui et oui, on renvoie sur favatar.php?w=favicon&q=icone.png, et PHP fera son travail. Le [L] permet de dire qu’il s’agit de la dernière condition et que le traitement du .htaccess s’arrête.

Il reste une ligne à ajouter. En effet, si je fais une requête sur le dossier .favicon/, je ne veux pas que ça renvoie sur PHP. C’est un dossier, pas une image. Et même si je gère cette exception dans PHP pour plus de sécurité, il faut mieux mettre un garde-fou en plus.

Par conséquent, ça nous fait quatre lignes :

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_URI} ./gravatar/(.*)$
RewriteCond %{REQUEST_URI} !./gravatar/$
RewriteRule (.*)gravatar/(.*)$ ../../favatar.php?w=gravatar&q=$2 [L]

La ligne ajoutée, la troisième, dit « si le fichier est autre que le dossier gravatar/, on applique la règle ». Dans le cas contraire, on laisse faire (et on ne renvoie pas vers PHP.

Ceci est bon pour les avatars.
Reste à faire la même chose pour les favicon. Il suffit de dupliquer tout ça :

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_URI} ./gravatar/(.*)$
RewriteCond %{REQUEST_URI} !./gravatar/$
RewriteRule (.*)gravatar/(.*)$ ../../favatar.php?w=gravatar&q=$2 [L]

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_URI} ./favicon/(.*)$
RewriteCond %{REQUEST_URI} !./favicon/$
RewriteRule (.*)favicon/(.*)$ ../../favatar.php?w=favicon&q=$2 [L]

Et voilà !

Exemple de fonctionnement

Juste pour résumer ce qui se passe :

Une requête sur ./gravatar/fichier.png sera traité par le premier bloc ci-dessus. Une requête sur ./favicon/fichier.png sera traité par le seconde bloc ci-dessus.

Dans les deux cas, si fichier.png existe, il est envoyé normalement au navigateur. Sinon, il est créé par PHP puis envoyé. Il n’y a pas de 404 envoyé au navigateur.
Si le fichier demandé est invalide, on renvoie une erreur 400 (Bad Request) avec PHP. C’est par exemple le cas si on demande un fichier à Gravatar qui n’est pas un MD5 d’une adresse e-mail, ou si l’on demande un favicon pour une URL qui n’est pas une URL correcte.

Enfin, si je fais une requête sur un autre dossier (./foo/fichier.png par exemple), alors il est ignoré par ce .htaccess et par PHP. Pas de risque donc de faire tourner PHP sur d’autres fichiers que des icônes ou des avatars.

image d’en-tête de Ferenc Almasi

J’ai déjà fait un article sur Pourquoi mettre le JavaScript à la fin et le CSS au début ?, et je vous invite à le lire.

Les astuces ici sont en plus.

Utiliser preload pour précharger les ressources utiles

Bien que l’on puisse mettre le CSS dans l’entête, il faut se souvenir que dans le CSS, on peut lier d’autres CSS, avec les @import, ou même des polices, des images (avec background-image). Cela peut ralentir l’affichage.

Si les fichiers sont petits, il est préférable de les précharger : le téléchargement en parallèle est alors avantageux sur le téléchargement en série des fichiers.

Pour ça, dans le head de la page HTML, on peut utiliser ça :

<link rel="stylesheet preload" href="style/style.css" as="style" />
<link rel="preload" href="fonts/font.woff2" as="font" type="font/woff2" crossorigin />

Cela permet de précharger les ressources en même temps que la page.

Quelques remarques :

• pour le CSS, j’ai mis stylesheet et preload. Certains mettent juste preload, puis utilisent JS pour changer le preload en stylesheet quand la page est chargée, avec onload. Perso je vois pas l’intérêt d’utiliser JS pour ça : ça ne fait que retarder le rendu.
• pour le fichier woff2 (police), j’ai ajouté un crossorigin. Je ne sais pas pourquoi, les navigateurs en ont besoin (à la fois Firefox et Chrome), sinon il préchargent le fichier, le jettent, et le rechargent quand la requête réelle est demandée…
• on utilise preload et non prefetch. Prefetch sert à précharger des pages sur lequel vos lecteurs vont cliquer, afin de gagner du temps lors de la navigation entre plusieurs pages. Preload sert à charger des ressources pour la page courante.

Ne charger les scripts que quand ils sont utiles

Ensuite, les scripts doivent être mis à la fin (voir mon article lié plus haut).

Sauf que certains scripts dépendent du contenu d’une page.
Par exemple, sur Couleur-Science, les équations dans certains articles utilisent KaTeX (il existe un standard HTML pour afficher des équations (MathML), mais il n’est supporté que par Firefox, donc pour l’instant, on passe par une lib JS).

Certains de mes articles n’ont pas d’équations. Dans ce cas, pourquoi télécharger 150 ko de JS ?
Chez KaTeX, on identifie une équation en le plaçant entre des signes « $ ». Comme ça : « $ equation $ ».

Je fais donc un test : si le contenu de l’article contient un signe $, je charge Katex. Autrement, je ne le charge pas.

Ah et je fais ça seulement quand le reste de la page a fini de charger : rappelez-vous, si vous initiez le chargement d’un script, le rendu de la page se bloque.

Je fais donc ça :

document.addEventListener("DOMContentLoaded", function() {
	var contenuDom = document.getElementById('contenu').textContent;
	if (contenuDom.indexOf('$') !== -1) {

		// only if Katex needed is it added
		var newLink = document.createElement('link');
		newLink.rel = 'stylesheet';
		newLink.type = 'text/css';
		newLink.href = 'katex/katex.min.css';
		document.head.appendChild(newLink);

		var katexRes = document.createElement('script');
		katexRes.src = 'katex/katex.min.js';
		document.head.appendChild(katexRes);

		setTimeout(function() {
			renderMathInElement(
				document.getElementById('contenu'),
				{
					delimiters: [
						{left: "$$", right: "$$", display: true},
						{left: "$", right: "$", display: false},
					]
				}
			);
		}, 1000);
	}
});

Explications :

• j’attends le chargement de la page.
• ensuite, je regarde si le #contenu contient un « $ ». Si oui, j’initie le téléchargement du CSS de Katex, puis du Script de Katex.
• Enfin, j’attends un instant (1 s) et je dis à Katex d’afficher les équations qu’il trouve dans la page.
  Si je mets le renderMathInElement() dans un katexRes.onload(), ça ne marche pas. En effet, onload() se déclenche quand le fichier a fini de télécharger, pas quand il a fini d’être parsé. Il faut que le code dans le fichier soit parsé, pas juste téléchargé.

Pas de base64 pour le SVG inclus dans le CSS

Si l’image est très légère, une requête sera plus longue que le téléchargement, il est alors préférable de l’inclure directement dans la source. Quand on veut mettre des images très légères directement dans le CSS, on les inclut en Base64 : le fichier image se met sous une forme textuelle et on la copie-colle dans le CSS.

Inconvénient : le Base64 pèse 33 % plus lourd.

Si notre image est en SVG, tout ceci est inutile : le SVG est lui-même du texte. On peut dont le placer directement dans le code. Il suffit de dire que le format est du SVG :

background-image: url("data:image/svg+xml;utf8,<svg xmlns='http://www.w3.org/2000/svg' width='36' height='36' viewBox='0 0 36 36'><path d='M10.5 15l7.5 7.5 7.5-7.5z' /></svg>");

En prime, le SVG reste lisible. Il faut juste faire attention à correctement échapper les caractères (quotes, doublequotes…).

Pour les polices d’icônes

Concernant les petites images/icônes, j’utilise une police qui contient les glyphes. Les icônes que j’utilise sont les icônes de Google Material Design. Il y en a plus de 1 000 différentes.

Si vous n’utilisez que 10 icônes, il ne sert à rien de toutes les intégrer. Dans ce cas, on peut n’intégrer que les polices nécessaires.

Pour cela, j’utilise personnellement Icomoon, un outil en ligne. On peut lui donner ses propres SVG (ceux de Google Material par exemple) et produire une police en .woff ou un autre format.
Seul problème : il ne produit pas de .woff2 (dont la taille de fichier est moitié moindre). Il faudra donc utiliser un autre convertisseur pour transformer le .woff en .woff2.

Là aussi, si nécessaire, utilisez un préload pour ce fichier, ou bien incluez le directement dans le CSS en Base64.

Enfin, n’oubliez pas qu’il faut peut-être autoriser la mise en cache avec .htaccess (les formats .woff et .woff2 ne sont pas forcément pris en charge nativement dans ce fichier) :

<IfModule mod_expires.c>
  AddType application/x-font-woff .woff
  AddType application/x-font-woff2 .woff2
  ExpiresActive On
  ExpiresDefault "access plus 1800 seconds"
  ExpiresByType application/x-font-woff "access plus 1 year"
  ExpiresByType application/x-font-woff2 "access plus 1 year"
</IfModule>

D’autres liens

J’espère que les quelques astuces ci-dessus seront utiles.
Ci-dessous, quelques autres astuces accumulées depuis les années :

Enfin, pour des astuces plus générales :

• pensez à utiliser break/continue
• rappelez-vous : ce qui compte, c’est la vitesse perçue ; dans cet exemple du lecteur RSS, il est inutile que tous les flux soient téléchargés immédiatement. L’internaute ne lira qu’après 1 ou 2 secondes, le temps qu’il choisisse quoi lire. Récupérez donc d’abord les titres des articles, puis, pendant qu’il choisit les titres qu’il va lire, on télécharge le contenu des posts. C’est comme quand vous êtes au restaurant : le cuistot ne prépare pas tous les plats en avance, mais commence par proposer le menu et proposer à boire. Comme ça, pendant que les gens boivent, il prépare le plat.
• utilisez les JPEG progressifs
• pour le JSON, utilisez type="application/json". Ça sera *beaucoup* plus rapide à parser
• et voyez tout ça

Passer en HTTP2

Enfin, et c’est probablement le plus gros gain que vous aurez, mais il faut que ça soit mis en place au niveau du serveur (ce qui peut ne pas dépendre de vous) : passez en HTTP2.

Voir ces liens : 1 , 2 , 3 , 4 .

(merci Thibault pour celui-ci)

Résultat

Résultat satisfaisant (pour ce que ça vaut, mais ça donne une idée) :

Donc non, il n’est pas nécessaire d’avoir un design ultra-flat tout blanc et noir si l’on veut qu’elles soient rapides.

image d’en-tête de Lucas Bravo

Ici un petit tuto sur l’installation d’une dashcam « en dur » dans sa voiture, avec branchement directement dans la boîte à fusibles et quelques astuces diverses en plus.

Mon matériel :

• ma voiture : (Hyundai Ioniq Plug-in)
• Dashcam : Thinkware F770 (site officiel ; lien Amazon)
• Câbles de branchement "hardwire" (lien Amazon)
• (facultatif) Carte micro-SD UHC1 (lien Amazon)
• (facultatif) Filtre polarisant pour éliminer les reflets du tableau de bord dans la vitre et sur la vidéo (lien Amazon — filtre polarisant pour drône DJI : le filtre seul, en verre, se colle très bien sur la dashcam).

Il y a une carte micro-SD de 16 Go fournie avec cette caméra, et qui suffit pour enregistrer environ 2 h de vidéo full-HD.

Si vous souhaitez pouvoir enregistrer davantage, prenez une carte plus grande. La carte doit être certifiée UHC-1, sinon votre dashcam ne la reconnaîtra pas. Pour info : une carte micro-SD de 64 Go certifiée UHC-1 coûte environ 10 € en ligne, en 2021.

Si possible, privilégiez en plus une carte avec une bonne capacité d’écriture / réécriture (les cartes « endurance » sont précisément faites pour ce genre d’usage, par exemple chez Samsung ou chez Sandisk).
À ces niveaux d’enregistrement en continu, la carte mémoire constitue un consommable, et une bonne carte vous évitera de devoir en changer tous les 4 matins.

La dashcam F770

Je ne suis pas spécialiste en dashcam, mais j’ai trouvé cette référence dans une vidéo où ils montrent comment l’installer dans une Ioniq, donc ma voiture. J’ai décidé de faire pareil.

En voici quelques caractéristiques rapides :

• prix : 169 €.
• image : full-HD
• format des vidéos : MP4
• support de stockage : micro-SD
• on peut y brancher un add-on pour ajouter une caméra arrière et ainsi filmer l’avant et l’arrière de la voiture.

Un truc cool : la dashcam peut envoyer le flux vidéo sur le téléphone via du Wifi (il devient un hotspot wifi sur lequel se connecte le téléphone). On peut alors avoir une vision directe de la caméra sur le téléphone, ce qui est très pratique lors de la mise en place et vérifier le centrage. C’est aussi pratique pour mettre en place le filtre polarisant : il doit être orienté correctement pour filtrer les reflets.
L’application permet aussi de récupérer la vidéo sans PC et sans débrancher la carte-SD.

À noter que les vidéos sont coupés en blocs d’une minute qui pèsent chacun environ 80 Mo (soit environ 4,8 Go par heure)

Si l’on n’utilise pas le Wifi, on peut toujours lire les vidéos depuis un PC en retirant la carte micro-SD : l’adaptateur μSD→SD et μSD→USB sont fournis avec. Les vidéos sont directement accessibles sur la carte sans besoin de lecteur spécifique.

Hardwire ou prise allume-cigare ?

De façon générale, il y a deux façons de brancher une dashcam dans une voiture.

La première consiste à brancher la dashcam sur la prise allume-cigare de la voiture.
C’est de loin ce qu’il y a de plus simple : on branche et ça marche.

Attention : normalement, l’allume cigare d’une voiture n’est pas alimenté quand le contact est coupé. C’est très important, sinon la caméra ou tout autre accessoire viderait votre batterie en une nuit et vous ne pourrez plus démarrer le lendemain. Sur certaines voitures, l’allume-cigare pourrait rester allumé ! Il faut s’en assurer avant de laisser la dashcam branché. Faites bien attention !

Cette façon d’installer la caméra laisse cependant apparaître sa prise et une partie du câblage. Pour ceux qui veulent un montage plus propre et discret, on peut utiliser ce qu’on appelle le « hardwire » (« câblage en dur »). C’est la seconde façon de faire.

Avec le hardwire, on branche la caméra directement dans le circuit de la voiture (en passant par la boîte à fusible). Cela demande un peu de bricolage, mais le résultat est nettement plus propre : tous les câbles sont cachés et la dashcam fait alors partie intégrante de la voiture (sans avoir l’air d’un accessoire ajouté après).
Il s’allume directement avec la voiture et s’éteint quand on coupe le contact.

Principe du hardwire

Chaque élément de la voiture (rétroviseur électrique, fenêtres, clignotants, sièges électriques, prises USB…) a son fusible dédié dans la boîte à fusible.

Bien-sûr, par défaut il n’y a pas de prise pour dashcam, mais on peut en créer une : pour ça, on va utiliser un dédoubleur de fusible pour pouvoir brancher un élément en plus dans le boitier. Ainsi, une prise du boitier aura le fusible qu’il avait déjà (par exemple : les vitres électriques) et un autre fusible pour brancher un accessoire tiers, c’est-à-dire votre dashcam.

Le dédoubleur, c’est le petit kit hardwire listé plus haut.

Avec ce système on n’a rien modifié dans la voiture. Pour tout annuler, il suffira de virer le kit et de remettre le fusible original à sa place.

Côté technique

Premièrement, il faut savoir que toutes les voitures n’ont pas les mêmes formats de fusibles. Il faut donc un kit hardwire spécifique. Pour la Hyundai Ioniq, il faut le kit micro-2.
Si vous achetez un kit, regardez bien celui qu’il vous faut.

Ensuite dans une voiture, il y a deux circuits électriques principaux :

• le circuit alimenté en permanence (qui comprend typiquement les accessoires comme l’alarme, les feux de détresse, le système de verrouillage à distance…)
• le circuit qui n’est alimenté que lorsque le contact est mis (qui comprend tout le reste : vitres électriques, radio, direction assistée, éclairage extérieur, système d’infodivertissement).

La dashcam doit être branchée sur le second circuit : celui qui n’est sous tension que quand la voiture est allumée (sinon il va rester brancher tout le temps et vider votre batterie en quelques heures).

Note : La dashcam F770 version Royaume-Uni vient directement avec le kit hardwire et sur deux fils : il a le mode normal quand on roule et un mode « parking » basse consommation (qui prend dix image par minute, par exemple) quand la voiture est éteinte. La caméra intègre une sécurité qui détecte la tension de la batterie et se coupe par sécurité quand elle est trop basse.
Cela permet d’avoir un enregistrement H24, voiture éteinte.

La dashcam F770 vendue sur le marché européen est capable de tout ça aussi (je suppose), mais le kit de connexion fourni avec ne le permet pas : le packaging UE ne contient que le connecteur prise allume-cigare (et ne peut donc as se brancher en mode parking).

Cela n’empêche pas de la brancher sur le boîtier à fusibles, mais pour ça il faudra sectionner le câble allume-cigare (avec une pince, donc, et irréversiblement)
À noter que dans mon cas, c’est le vendeur lui-même qui m’a conseillé de faire ainsi.

Bref, il vous faudra faire un choix :

• soit la brancher sur l’allume cigare (et dans ce cas il suffit d’acheter la dashcam ; recommandé si vous n’avez pas envie de risquer quoi que ce soit, ou pour tester avant).
• soit la relier à la boîte à fusibles et dans ce cas il faudra en plus prévoir un kit « hardwire » avec des dédoubleurs de fusibles (5-10 €) en s’assurant d’avoir le bon format de fusibles en plus de tout ça (ce kit peut être installé dans un second temps).

Ce qui suit est l’explication pour le hardwire, car c’est ce que j’ai fait.

Le branchement en dur de la dashcam

Quel fusible retirer pour le installer le kit ?

Sur la Ioniq, le boîtier à fusible se trouve à gauche sous le volant. Il y a une trappe qui s’enlève.

Vous voyez alors tous les fusibles avec des numéros 5, 10, 15, 25… écrit dessus : ce sont les courants maximums que permet ce fusible. Pour la dashcam, un fusible de 5 suffit, mais ce n’est pas tout.

Comme j’ai dit, il y a deux circuits sur une voiture :

• une alimentée 24/7
• une alimentée seulement après avoir mis le contact

Il faut mettre la dashcam sur le second. Vous pouvez utiliser le schéma de câblage dans le manuel de la voiture ou alors et détecter les accessoires non fonctionnels quand le contact est coupé : typiquement, vitres électriques, radio, éclairage intérieur.
Pour en être sûr, il faut utiliser un voltmètre et vérifier quel fusible se trouve effectivement hors tension quand le contact est coupé.

Les fusibles ont un petit point métallique sur le dessus, qui permet de les tester. Avec le voltmètre, on va mettre la borne rouge sur le fusible et la borne noire sur la masse de la voiture : c’est-à-dire la carcasse ou n’importe quel écrou non peint pas trop loin. Sur la Ioniq, il y en a une dans le boîtier à fusible.

En s’aidant du schéma orange sur la trappe du boîtier à fusible, repérez celui des vitres électriques par exemple :

• Contact coupé, la lecture doit être de 0 V.
• Contact mis, la lecture doit donner 12 V.

Pour comparer, essayez avec d’autres fusibles : certains afficheront toujours 12 V, même après avoir coupé le contact.

Il faut choisir un fusible : on peut utiliser celui que l’on veut qui réponde au critère ci-dessus. Perso j’ai utilisé celui d’un accessoire non essentiel (et que je n’ai pas) : le volant chauffant.

Dans tous les cas, évitez ceux des airbags ou de l’alarme. Si la dashcam pompe un peu trop de courant, cela peut influer sur leur déclenchement, ce qui serait dangereux.

Une fois que vous avez choisi un fusible, notez-le et repérez-le. Cela nous servira pour après.

Installation de la dashcam

Traditionnellement, on place la dashcam derrière le miroir central. Dans la Ioniq, il y a déjà la caméra de reconnaissance des panneaux et le détecteur d’humidité pour l’auto-désembuage.

Il reste de la place pour la dashcam du côté du conducteur. Prévoyez alors 2 cm de plus à droite pour pouvoir retirer la dashcam de son socle (la dashcam se clip sur son socle par la droite).

À ce stade, il est pratique de mettre le contact, brancher la dashcam sur l’allume-cigare et allumer la dashcam. Connectez-vous au Wifi de la cam avec votre téléphone et utilisez l’application Thinkware et affichez directement le flux vidéo. Vous pourrez alors juger du bon centrage et de la bonne orientation et inclinaison de l’image.

Quand vous êtes sûrs de votre positionnement, et que vous avez vérifié que vous pourrez toujours la retirer du socle, ôtez le film protecteur 3M pour permettre de coller la dashcam sur la vitre.

Je recommande de faire ça par temps chaud et ensoleillé : la colle 3M prend beaucoup mieux lorsqu’il fait chaud et il ne risquera pas de tomber en pleine conduite. Rassurez-vous, ça tient très bien : ça fait 3 mois que je l’ai mis, et elle n’est jamais tombée (encore heureux).

La dashcam collée, il faut maintenant masquer le câble. Dans la vidéo, le monteur a l’ingénieuse idée d’enrouler du ruban adhésif à l’envers (collant vers l’extérieur) autour du câble, et de pousser le câble sous la mousse du plafonnier. Ça marche très bien et ça ne bougera pas. Perso j’ai fait ça par endroit, pas sur tout le câble.

Débranchez la dashcam de l’allume-cigare mais laissez la cam elle-même fixée. En partant de la dashcam à côté du rétroviseur centrale, on va passer le câble sur la gauche, jusqu’à la portière puis descendre en passant derrière le joint en caoutchouc de la portière, et enfin quand on y sera, on passera dans le compartiment à fusibles.

Enfin, passez le connecteur dans la boîte à fusible :

1. remontez le câble jusqu’au plafonnier
2. passez le câble sous le plafonnier, jusqu’à la gauche. Arrivé au bout, passez le câble sous le plastique ; attention à l’airbag qui se trouve à cet endroit (n’y allez pas au couteau)
3. Descendez le câble, caché par le joint de porte (côté intérieur)
4. passez le câble par derrière dans la boîte à fusible.

(voir en grand)

Installation du kit hardwire

Maintenant que l’on sait où brancher la dashcam et que la câble (avec sa prise cigare) se trouve dans le compartiment à fusibles, on va devoir commencer la partie électrique.

Il faut retirer le fusible que vous avez repéré. Le kit vient avec une pince spéciale pour ça, sinon vous en avez une dans le second boîtier fusible qui se trouve sous le capot (dans le cas de la Ioniq).

Retirez un fusible, insérez ce fusible dans le kit. Ensuite, ajoutez un fusible pour la dashcam (venu avec le kit) :

Enfin, branchez le kit dans l’emplacement libéré de la boîte à fusible.

C’est bon pour le kit.

Branchement de la dashcam

« Le fil vert sur le bouton vert, le fil rouge… »

Il faut alors sectionner le connecteur allume-cigare. Perso, j’ai coupé juste sous le connecteur, ne coupant pas trop de fil (si jamais je change de voiture, ça permettra de récupérer la cam et de ne pas manquer de fil).

Dénudez alors les câbles noirs (sur 5~10 cm) puis dénudez les deux petits fils (blanc et jaune sur la mienne) sur 2~3 cm.

Le fil jaune est à connecte au fil du kit hardwire. Au besoin, et avant de souder/nouer les deux fils, passez les fils dans un bout de gaine thermorétractable. Nouez ensuite les fils, glissez la gaine thermo sur la jonction et passez un peu de chaleur dessus pour serrer et fixer la gaine isolante. Branchez enfin le kit hardwire dans son emplacement fusible.

Et le fil blanc ?
C’est la masse : il faut le mettre sur la carcasse de la voiture. Dans la Ioniq, il y a un écrou pas loin : on peut enrouler le fil autour, tel quel, puis utiliser un boulon pour le fixer (le tout sans défaire quoi que ce soit de la voiture).

Il ne reste plus qu’à ranger un peu le fil de la dashcam dans la boîte à fusible (pour éviter que ça ne traîne partout) et à remettre le cache.

Démarrez la voiture et normalement la dashcam s’allume (on peut voir la petite LED du GPS qui s’allume).
Coupez le contact et la caméra s’éteint.

Fini !

Notes à l’utilisation

Si vous avez une vieille carte SD qui traîne chez vous, et que vous la mettez dans la dashcam, vous pouvez l’entendre dire qu’il y a une erreur avec la carte. Souvent au démarrage, mais parfois en pleine conduite.
Dans ce cas, la caméra reboot toute seule. C’est sûrement une section de la mémoire qui ne fonctionne plus, ou alors que la carte n’est pas (ou pas pleinement) compatible. Pour rappel : il faut une carte UHC-1 minimum, capable d’enregistrer de la vidéo HD à la volée.

Si ça se produit trop souvent, remplacez la carte SD par une neuve. Comme j’ai dit, pour ces applications intensives, les cartes mémoire sont des consommables. Il en existe qui sont adaptés à l’enregistrement continu, et qui devraient fonctionner plus longtemps (voir lien au début de l’article).

Parfois la dashcam émet une petite musique de quelques notes, parfois à l’allumage, parfois quelques minutes après le début de la conduite. Je ne sais pas du tout ce que c’est. En règle général par contre, la caméra se fait parfaitement oublier.

De temps en temps, la dashcam dit qu’il faut formater régulièrement la carte. Si les vidéos qui sont dessus ne vous importent pas, appuyez alors sur le bouton « format » de la caméra. La voix dira quand c’est bon.

Intérêt de la dashcam, assurances et législation

La dashcam est une caméra embarquée. Elle filme toute votre conduite, en particulier un accident qui pourrait survenir. Elle peut aussi enregistrer votre vitesse. Certains modèles envoient également tout ça directement dans « le cloud » (ce n’est pas le cas de la F770).

Cela permet donc d’analyser votre conduite, de filmer vos road-trips, ou un « événement » qui surviendrait sur la route. Mais surtout, l’intérêt est de filmer un accident et de fournir l’enregistrement à votre assureur, aux autorités ou au tribunal. Rien ne dit que ça soit accepté comme une preuve, mais ça peut faire pencher la balance et au moins prouver votre « bonne foi ».

Certains assureurs proposent (ou proposaient) des ristournes pour l’usage de dashcam. Pas forcément parce que cela constitue une preuve en cas de sinistre, mais aussi parce que les conducteurs, se sachant filmés, ont tendance à conduire de façon plus respectueuse du Code de la route, et seraient alors moins susceptibles de provoquer un sinistre responsable. Renseignez-vous auprès de votre assurance, et surtout voyez si ça vaut le coup pour vous (en combien de temps le coût de la caméra est rentabilité par la ristourne éventuelle) !

Pour info, certains pays (Russie) les rendent obligatoires. Certains pays (comme le Portugal, l’Autriche ou le Luxembourg) en interdisent l’utilisation pour des problèmes de confidentialité.

Les autres pays, comme la France, restent dans le flou. Et dans le flou juridique.

La loi ne dit rien sur les caméras embarquées, si ce n’est qu’en cas de diffusion, la vidéo doit être anonymisée : les visages et les plaques doivent être floutées.
Il doit également être indiqué (sur la voiture) que celle-ci enregistre tout. La dashcam F770 vient d’ailleurs avec un autocollant destiné à cet effet.

Pour le reste, même si le Cerfa-13806-3 existe pour déclarer la mise en place d’un système de vidéo surveillance protection, il n’est pas sûr que ça soit nécessaire pour une caméra embarquée et mobile : la déclaration est liée à un lieu, et on ne peut pas faire une déclaration pour chaque ville que l’on traverse…

La loi ne suit donc pas les usages actuellement. Ceci étant dit, je suis pas avocat.

Quelques liens :

• la légalité des dashcam
• les dashcam sont-elles un progrès ou un danger
• dashcam et assurances auto

Très récemment, j’ai été appelé à la rescousse pour un cas de « piratage » d’une webmail Orange.

La personne avait été appelée par sa banquière qui voulait savoir si sa demande par e-mail d’un virement de plusieurs milliers d’euros était bien légitime (ça ne l’était pas). Finalement, de ce côté-là, aucun dommage. Mais ça s’est joué à la vigilance de la banquière en personne. Pour le coup, bravo (et merci).

Dans la webmail d’Orange, on pouvait voir l’historique des connexions en provenance de France (connexions légitimes) mais aussi du Mali et d’Inde (totalement anormal). Par ailleurs, les contacts de la personne dont le compte a été piraté ont pour certains reçus un e-mail chelou de la part du pirate se faisant passer pour elle (je l’ai reçu également).

Voilà pour ce qui s’est passé.

Ce que j’ai fait

Premièrement : faire changer les mots de passe.
La personne avait déjà commencé : c’est très bien.

Les Webmails autorisent (généralement) le transfert des e-mail vers d’autres comptes, de façon automatique. Il a donc été vérifié que le pirate n’avait pas mis en place de redirection vers une adresse à lui. Ça n’était pas le cas, mais un compte « lié » d’un autre compte Orange a été trouvé. Ne sachant pas ce que c’était, il a été supprimé.

Et pas seulement sur la webmail : mais partout. Tous les comptes en ligne. Le pirate a eu accès à ses e-mails, il a pu voir quels sites on utilise. Il aurait pu utiliser cette webmail pour faire un changement de mot de passe partout.

Facebook, Amazon, Google, Apple/iCloud, mais aussi le site de son assurance, les impôts, l’Urssaf, le site de la sécurité sociale ainsi que tous les sites plus ou moins habituels.

Ceci fait, le pirate perd son accès au compte e-mail. Bien.

Que faire de plus ?

Activer la 2FA partout où c’est possible. Avec la 2FA (authentification à deux facteurs), on reçoit un SMS avec un code à usage unique lorsqu’on cherche à se connecter. Si ça avait été activé sur la Webmail d’Orange, la personne aurait reçu un SMS avec un code, et le pirate ne l’ayant pas reçu n’aurait pas pu se connecter. En plus, cela aurait alerté la victime que quelqu’un aurait demandé un changement de mot de passe.

Malheureusement, et là je dis honte à Orange, la 2FA n’est pas possible sur la webmail d’Orange si l’on n’est pas également client mobile chez Orange ou Sosh, ce qui n’est pas le cas ici (la webmail vient avec l’abonnement fixe, pas mobile).

Pour info, la webmail Orange n’est pas seule : chez Free c’est pas mieux a priori, Bouygues non plus. Quant à SFR, ils facturent cette option.
Bref, du n’importe quoi chez nos FAI français.

Comment tout ça est arrivé ?

Deux causes :

• l’usage du même mot de passe partout (avoué par la victime)
• le piratage d’une base de donnée chez qui on avait un compte (avec l’e-mail de la webmail et le mot de passe identique).

Comment on l’a vu ?

L’adresse e-mail apparaît dans les bases de données piratées.
Des services en lignes permettent de vérifier ça, comme ceux-là :

• Firefox Monitor (par Mozilla)
• have i been pwned? (par un dév indépendant)

Voilà.

Donc c’est un site tiers qui s’est fait pirater : la base de données des e-mails + mots de passe s’est retrouvée dans la nature et un pirate a récupéré ça.
Ensuite, il a essayé une des adresses (celle de la victime) et a utilisé le mot de passe du site piraté, en espérant que la victime utilise la même partout : c’était le cas, bingo.

Ensuite, le pirate entre sur la webmail, fouille tous les mails à la recherche d’informations, comme les correspondances avec sa banque, des numéros de comptes, des noms de famille… Puis à utiliser la webmail pour écrire à la banque de faire un virement. Encore une fois : ici la banquière a eu la présence d’esprit de demander confirmation par téléphone à la victime. C’est ce qui a sauvé les meubles.

Comment faire pour ne pas que ces choses arrivent ?

Choses très simple à mettre en place :

• ne pas utiliser le même mot de passe partout
• changer de mots de passe régulièrement, ou en cas de doute sur une intrusion.
• utiliser la 2FA (authentification à deux facteurs) partout où c’est possible.

Il faut mieux un SMS avec un code chiant à entrer à chaque connexion qu’un piratage.

Et dans le cas de la banque :

• toujours faire ses demandes via la « messagerie sécurisée » de votre banque, ou par téléphone, ou au guichet pour les gros montants.

D’ailleurs, tout comme votre banque vous dit régulièrement qu’ils ne font rien passer par e-mail, mais toujours par courrier, vous pouvez très bien leur dire aussi que vous ne passerez jamais par e-mail et viendrez toujours passer par le guichet (pour ceux qui font ça).
Les banques ajoutent alors cette information à votre dossier et ils sauront qu’un virement inopiné sera forcément frauduleux (et soit l’annuleront, soit vous appelleront).

Ceci est aussi utile quand vous avez un gros virement à faire : prévenez votre banque, ça évitera qu’ils fassent obstacle en pensant à un virement frauduleux (je l’ai fait quand j’ai acheté une voiture, par exemple).

Choses plus avancées à mettre en place :

• utiliser une adresse mail personnelle (pour parler avec les gens)
• et utiliser une adresse mail pour les inscriptions sur les sites (comme ça le piratage de la seconde n’expose que vous, pas vos correspondants, ce qui empêche au pirate d’avoir l’e-mail de la banque)

Choses à considérer dans l’idéal

• utiliser une webmail sécurisée (proposant la 2FA)
• ne pas utiliser celle de votre FAI (en général, car le jour où vous changez d’opérateur, vous perdez tout…).

Toutes considérations de vie privée et de l’hégémonie des GAFAM mis à part : préférez une GMail qu’une webmail de votre FAI. Idéalement, achetez-vous un nom de domaine chez un régistrar (comme Gandi ou OVH) : ils viennent avec une webmail suffisamment large pour n’importe quel usage perso. En plus d’avoir une adresse e-mail bien à vous, ça permet de ne plus dépendre de votre opérateur téléphonique, qui peut changer si vous changez de prestataire.
Et un nom de domaine peut se transférer d’un régistrar à un autre : il est à vous, donc si vous l’achetez chez l’un mais que vous voulez changer, transférez-le chez un autre régistrar. Ceci n’est pas possible avec une adresse chez Orange, SFR, Free…

Changez de temps en temps d’adresse e-mail pour les sites web. Rappelez-vous : si vous utilisez une adresse pour la correspondance et une pour les inscriptions, c’est celle pour les inscriptions sur les sites qu’il faut changer de temps en temps.

Des choses au niveau des sites web

Ici, vous n’y pouvez rien : vous n’êtes pas responsables si un site web se fait pirater. Du coup, ceci s’adresse aux éditeurs de services web : ne stockez pas les mots de passe en clair, bordel ! Un jour vous vous ferez pirater, et si vous les stockez en clair, tous vos clients seront victimes de ce genre de brèche, par votre faute.

Et n’utilisez pas un hashage MD5. Ce n’est plus sûr non plus.
Utilisez au moins du SHA256, voire SHA512, et avec un salt. Il existe des fonctions intégrées aux langages de programmation (comme PHP) pour utiliser tout ça d’un coup. N’utilisez pas des fonctions « maison » qui vous semblent meilleurs que ceux codés par les experts qui font les langages. Ça ne l’est probablement pas.

Pour terminer

Pour finir : la victime de cette mésaventure s’est promise qu’on ne l’y reprendra plus à utiliser le même mot de passe partout. Tant mieux.

Il faut maintenant aussi penser à surveiller l’activité du compte (une connexion depuis le Mali n’est pas normale dans notre cas), et, en cas de doute, changer immédiatement de mot de passe. Idéalement, il faudrait changer de mot de passe régulièrement, mais attention à ne pas tomber dans la simplicité et changer pour des mots de passes plus simples pour compenser les changements fréquents.

Le « régulièrement » va dépendre : rous les ans, tous les 6 mois, tous les mois… il en va du niveau de paranoïa de chacun et de l’importance du compte en question.
Perso, je pense que changer son mot de passe une fois tous les ans est un minimum, au moins pour ses comptes critiques (banque, etc.).

Donc vous savez ce qui vous reste à faire : allez vérifier vos comptes en ligne (Gmail, Facebook…) et vérifiez l’historique de connexion, et changez vos mots de passe en cas de doute ou d’activité suspecte.

Attention : si vous changez votre mot de passe e-mail sur votre ordinateur, vous devrez le mettre à jour sur votre téléphone également, et partout où vous êtes connectés.

image d’en-teête de Jacob Rosen

Ça y est, je commence à regarder la présence de bornes de recharge pour savoir où je vais aller.

Même si je ne suis pas à quelques dizaines de kilomètres près, mais pouvoir recharger sa voiture pendant qu’on se balade à pied, qu’on boit un verre, qu’on fait ses courses, qu’on mange, qu’on dort à l’hôtel a quelque chose de satisfaisant.

Les bornes payantes avec tarification à la minute ne sont pas attractives pour une PHEV (qui chargent lentement et donc longtemps), mais le restent pour les EV. Vu que j’ai une PHEV, je reste donc uniquement sur les bornes gratuites quand il y en a.

Quoi qu’il en soit, je ne pense pas être le seul.

Et tant que les bornes sont rares, c’est un point d’intérêt pour ceux qui roulent en électrique. C’est aussi toujours une bonne surprise quand il y a une borne là où on va alors qu’on ne le savait pas, d’autant plus quand elle est gratuite.

Les aires d’autoroute ont désormais souvent des points de charge rapide, mais dès qu’on en sort, particulièrement à la campagne, c’est moins courant : il faut les chercher. Heureusement qu’il y a des applications comme ChargeMap, ou Alizée pour nous aider avec ça.

Y a 15 jours, j’en ai fait l’expérience : il restait un peu de temps et je voulais me balader, donc j’ai regardé les villages et activités alentour. Et j’ai donc choisi d’aller au seul village avec une station de charge, (qui était gratuite) pour aller voir.
Samedi dernier, je suis resté un peu plus longtemps dans un autre village, juste pour finir la charge et on a bu un verre.

Peut-être vous voyez où je veux en venir : installez une borne, et les gens viendront, et les gens dépenseront.

Le village où j’étais indiquait être excédentaire énergétique (c’est écrit sur la borne, avec un message du prestataire du service, etc.) : a priori donc, j’ai chargé ma voiture sur de l’énergie qui serait autrement parti « à la poubelle » ou dans du pompage hydraulique (et donc utilisé de façon moins efficiente).

Si je ne l’avais pas fait, j’aurais probablement brûlé un peu d’essence pour rentrer, ou j’aurais chargé ma voiture ailleurs, ni gratuitement, ni sur du courant excédentaire.

Un autre point, et ce n’est pas un mystère : les voitures électriques sont encore chères. Proposer un point de charge, c’est donc potentiellement attirer des personnes qui ont des moyens de dépenser. Y compris des touristes. Et un touriste qui vient dans un village il repart généralement avec des souvenirs, après un restau ou une nuit à l’hôtel du coin, bref, quelqu’un qui y injecte du pognon.

Sur les bornes de proximité, la recharge prend facilement une heure ou deux, c’est donc l’occasion de passer à table entre-temps.
Je sais que les points de charge coûtent cher (on parle de 3 000 à 6 000 € pour une borne de deux places), mais si ça s’amortit parce que ça attire du monde, pourquoi pas. Comme j’ai dit plus haut : ça attire une clientèle capable de dépenser.

D’un point de vue technique, une borne de 22 kW suffit pour la charger complètement une voiture de 50 kWh (soit une EV moyenne) en 2 heures, soit le temps d’un restau. Installez ça sur le parking du village, et on peut être sûr que celui qui passe pour charger viendra boire un verre ou casser la croûte sur place.

Dans le cas d’un hôtel, une borne 11 kWh ou 7 kWh suffiront amplement si le client y passe sa nuit. Ça rechargera la voiture tranquillement pendant qu’il dort. Et même sans ça, une prise murale renforcée (32 A) suffirait si le client a son chargeur avec lui (c’est le cas généralement).

Pour info, une borne 7 kW, c’est du 32 ampère monophasé (donc une ligne similaire à une ligne de camping « prise bleue », ou P17).
Le 11 kW, c’est du 16 A triphasé. Enfin, le 22 kW, c’est du 32 A triphasé : ça reste accessible techniquement, il faut juste le demander à EDF.

En tout cas, ce n’est pas du 50, 150 ou 300 kW qui demandent effectivement des installations (postes de transformation) très coûteuses, et qui ne sont utiles que pour les charges rapides, donc réservées pour les aires d’autoroute ou les stations EV à grand volume.

À titre d’exemple, Tesla est le seul constructeur qui possède son propre réseau de charge. C’est ce qui fait sa force devant tous les autres constructeurs (ces derniers ayant refusé de s’allier avec lui). Et peut-être remarquerez-vous qu’une grande partie des points de charge Tesla sont situés dans ces cours d’hôtels : ce n’est pas un hasard !
Tesla a créé des partenariats avec ces chaînes d’hôtels. Les conducteurs vont là-bas, boivent un café à la cafétéria de l’hôtel et après 20-40 minutes, la voiture est chargée et c’est bon.

Donc oui : si vous êtes Maire ou conseiller municipal en zone rural, et si votre village a un café, un restau ou 2-3 petits coins à visiter dans la ville, et si la question est sur la table : n’hésitez pas ! La borne sera rapidement visible dans les applications mobiles et on y voit aussi s’il y a des commodités (restos, etc.) à proximité.

Peut-être que je ne suis pas l’utilisateur moyen d’une EV, mais je ne suis sûrement pas le seul à aller à des endroits selon la possibilité d’y charger la voiture : entre deux villages inconnus à visiter, j’aurais bien plus tendance à aller explorer celui qui possède une borne pour EV…

J’avais déjà fait un article sur ça il y a longtemps, mais là aussi il semble qu’elle ne soit plus au goût du jour.

Après moult tests et quelques surprises, je mets ici quelques snippets de code, pour mémo, surtout pour moi.

Notes :

• Dans ce qui suit, si vous voyez un example.com, il faut remplacer ça par votre site à vous ;
• Ceci est adapté à mon site, mes préférences en termes d’URL.
• Vérifiez que votre serveur supporte les redirections et le fichier .htaccess.

Notes 2 :
Selon votre fichier et les règles qui s’y trouvent déjà, il peut être nécessaire d’y ajouter (une fois) les instructions suivantes :

RewriteEngine on

RewriteBase /

Je ne les fais pas figurer partout ci-dessous.

Forcer la redirection HTTPS

Les navigateurs le font tout seuls parfois, mais il vaut mieux l’ajouter :

## Force HTTPS
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301]

Supprimer le « www », au début du nom du site

Certains préfèrent le conserver, d’autres non. Dans tous les cas, il est préférable d’avoir un choix et de forcer la redirection de l’une des URL vers l’autre. C’est plus propre et c’est aussi mieux pour le référencement d’avoir une seule URL pour chaque ressource :

## Removes www.
RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
RewriteRule ^(.*)$ https://%1%{REQUEST_URI} [R=301]

Supprimer les slashes redondants

J’ai mis du temps à trouver un code qui fonctionne quelle que soit la position des doubles-slashs. Généralement les forums en proposaient plusieurs selon que le slash soit au début, à la fin ou au milieu de l’URL.

## Removes multiple consecutive slashes anywhere in URL
RewriteCond %{THE_REQUEST} \s[^?]*//
RewriteRule ^.*$ /$0 [R=301,NE]

Maintenant, les urls suivantes :

• exemple.com///dossier/fichier ;
• exemple.com/dossier///fichier ;
• exemple.com/dossier/// ;
• exemple.com////dossier///fichier

Sont toutes réécrites en :

• exemple.com/dossier/fichier

ÉDIT : les slashes multiples doivent être remplacées uniquement dans l’arborescence. S’il y a « ?paramètre=foo///bar », cela peut être légitime et ne n’est pas notre problème : ils doivent rester. C’est pour ça qu’on ne cible que les slashes multiples entre le premier espace dans %{THE REQUEST} et le premier « ? » dans l’URL.

Supprimer le code derrière le chemin d’un script

## Rewrite ^*.php/*$ to *.php$ (removes anything after a "*.php/")
RewriteCond %{REQUEST_URI} ^(.*)\.php/(.*)$
RewriteRule . %1.php [R=301]

Celui-là est plus compliqué.
Quand on appelle un fichier fichier.php, on en exécute le contenu. Si l’on l’appelle avec un paramètre fichier.php?parametre, c’est toujours le même fichier qui est exécuté, mais maintenant l’exécution tient compte de la valeur du paramètre.

Dans le cas suivant par contre, il y a possibilité de problèmes : fichier.php/.
Le fichier est appelé (et donc exécuté), mais il est traité comme un dossier (car il est suivi d’un slash et non d’un point d’interrogation), et avec lui la notion de profondeur de l’arborescence, etc.
C’est un problème assez sévère et je préfère l’éviter.

J’y vais donc assez lourdement : quand je vois un fichier .php qui est directement suivi d’un slash, on vire tout ce qui suit le slash, incluant ce dernier.

Les urls suivantes :

• exemple.com/fichier.php ;
• exemple.com/fichier.php/ ;
• exemple.com/fichier.php/blabla/autreblabla ;

Sont toutes réécrites en :

• exemple.com/fichier.php

Notez que ça ne visera que le script exécuté. Rien n’empêche en effet d’avoir la chaîne « .php » suivi d’un slash dans un paramètre d’un autre fichier php (celui exécuté).
Cette URL ne sera pas modifiée, par exemple : exemple.com/fichier.php?parametre=fichier.php/bla/bla

Supprimer le « index.php » à la fin des URL

## Rewrites "/index.php" to "/"
RewriteCond %{REQUEST_URI} ^(.*)/index\.php$ [NC]
RewriteRule . %1/ [R=301,L]

Quand on affiche un dossier sur un site, comme example.com/folder/, le « index.php » ou « index.html » qu’il contient est implicitement affiché. C’est la page par défaut. Le demander de façon explicite est donc généralement inutile.

Afin d’éviter d’avoir des URL redondantes, je préfère ne conserver que les URL sans le « index.php ». Les éventuels paramètres, eux, sont maintenus.

Pour résumer

Avec tout ça, toutes les URL suivantes :

• http://lehollandaisvolant.net/tuto/ (https)
• http://www.lehollandaisvolant.net/tuto/ (https ; www)
• https://lehollandaisvolant.net/tuto/ (url OK)
• https://lehollandaisvolant.net//tuto/ (double slash après le TLD)
• https://lehollandaisvolant.net/tuto/// (double slash à la fin)
• https://lehollandaisvolant.net/tuto/index.php (index.php)
• https://lehollandaisvolant.net/tuto/index.php/ (index.php + slash)
• https://lehollandaisvolant.net/tuto/index.php/folder/ (index.php + slash + faux-dossier)
• http://www.lehollandaisvolant.net//////tuto/index.php//dossier/sousdossier/foo/ (tout ce qui précède)

Renvoient toutes sur :

• https://lehollandaisvolant.net/tuto/

Petite note sur les cascades de fichers .htaccess

On peut mettre un fichier .htaccess dans chaque dossier et leurs sous-dossiers si l’on veut, et les directives seront appliquées à tous les fichiers inclus dans le dossier, y compris leurs sous-dossiers.

Par contre, mettre un RewriteEngine on dans un des sous-dossiers pourra avoir pour effet d’annuler les directives des fichiers situées dans les dossiers parents. C’était le cas chez moi récement, même si je n’ai pas souvenir d’un tel comportement lors de la mise en place de ces fichiers.
Il est possible que ça vienne de la configuration du serveur.

Il y a quelques années, j’avais fait un article pour expliquer comment mettre la barre de signets verticalement dans Vivaldi. Cette méthode n’est plus d’actualité et était de toute façon remise à zéro lors des mises à jour du navigateur.

La nouvelle méthode est elle persistante, et même si elle semble similaire, elle utilise des options qui n’étaient pas là dans Vivaldi avant.

Activer les modifs CSS de l’interface

Pour commencer, il faut activer 2-3 trucs dans les options du navigateur, y compris des options expérimentales.

Premièrement, activez les mods CSS. Pour ça, allez sur l’adresse vivaldi://experiments/ puis cochez la case « Allow for using CSS modifications ». Relancez le navigateur.

Rendez-vous ensuite dans les paramètres, et cherchez « CSS ». Vous devez alors voir apparaître une option qui permet de spécifier un dossier :

Mettez-y un dossier de votre choix. Je vous conseille de choisir un sous dossier nommé « userChrome » dans le dossier de profil de Vivaldi. Sous GNU/Linux, le dossier de profil se trouve dans ~/.config/vivaldi/.

Ce dossier « userChrome » va contenir des fichiers CSS contenant le code CSS correspondant aux modifs de l’interface du navigateur.

Activer la barre de signets

Ensuite, dans les paramètres, toujours, assurez-vous que la barre de signets soit en haut, que les signets soient affichés sous formes d’icônes seulement :

Utiliser du CSS pour mettre cette barre verticalement sur la droite

Ce que mon code CSS va faire maintenant, c’est :

• pivoter la barre 90° dans le sens horaire (la barre se trouve alors à gauche et les icônes sur le côté)
• déplacer cette barre (sur la gauche) vers l’autre côté, à droite
• faire pivoter les icônes de −90° pour les remettre dans le bon sens.
• faire en sorte que la barre n’empiète pas sur la fenêtre principale du navigateur (la partie où s’affichent les pages)

Le code en question :

/* Bookmarkbar : turning it on the side, placing it on the right */
#app #browser #main .bookmark-bar {
	transform: rotate(90deg) scale(1, 1)!important;
	transform-origin: 0% 0%!important;
	position: relative!important;
	left: 100%;
	height: 34px;
}

/* flip back the individual icons */
#app #browser #main .bookmark-bar button {
	transform: rotate(-90deg)!important;
}

/* gives margins to the main frame */
#app #browser #main .inner {
	margin-right: 35px!important; /* gives place to the new bars position */
	margin-top: -35px!important; /* claims the place from its old position */
}

Ce code est à placer dans un fichier CSS dans le dossier créé précédemment. Donnez-lui le nom que vous voulez ; par exemple « vertical-bookmarks.css ».

Enregistrez ce fichier, puis redémarrez Vivaldi, et la barre devrait être vertical, à droite :

Quelques notes

Ceci est testé avec Vivaldi 3.7.2218.58 (Stable channel) (64 bits) sous Linux Mint 20.
Le code CSS utilisé est le même que celui de mon astuce d’il y a quelques années.

Vivaldi le dit bien : l’option pour le CSS peut, un jour, être modifié ou retiré. Dans ce cas, ce mod ne fonctionnera plus : la barre de signets sera alors de nouveau en haut, horizontalement. Ça ne sera pas grave (aucune perte de données), mais il faudra alors trouver autre chose.

À l’époque d’Opera, il était possible de mettre la barre de signets verticalement d’une simple option dans les réglages. On peut espérer que cette option revienne un jour dans Vivaldi. En attendant, ce bricolage permet de dépanner.

Toute l’interface de Vivaldi est accessible en CSS. Pour en explorer les éléments, il faut lancer Vivaldi dans un mode spécial, avec la commande vivaldi --debug-packed-apps --silent-debugger-extension-api, et ensuite utiliser les outils de développeurs pour l’explorer et moder ça.

En plus des traditionnels « favicon.png » ou « robots.txt », qu’on doit mettre à la racine de son site, il y a une ribambelle d’autres fichiers qu’il est possible (parfois recommandés, même) d’avoir sur son site.

En voici une petite liste.

Commençons par les fichiers très connus et très utilisés. Vous trouverez beaucoup de ressources à leur propos.

La favicon

Pour que votre site affiche une icône sur toutes les pages, le minimum est de mettre un fichier favicon à la racine de votre site :

/favicon.ico

Le format est spécifique, mais généralement, utiliser un fichier BMP renommé en .ICO fonctionne très bien. La favicon est traditionnellement carrée et de taille 16x16, 32x32 ou 48x48.
Une seule favicon à la racine de votre site suffit pour toutes les pages de votre site, quelque soit leur arborescence (sous-dossiers, etc.). Les navigateurs viendront automatiquement la chercher.

Vous avez la possibilité (en plus du fichier favicon.ico à la racine du site) de spécifier une autre icône dans le code source HTML, grâce à une balise <meta>. Dans ce cas, le format de fichier peut être PNG, SVG ou ce que vous voulez.

De plus, vous pouvez aussi pointer le chemin vers un autre chemin, comme un dossier spécial pour toutes les autres icônes.

Les autres icônes

Chrome, Safari, Edge, Windows 10, Android ou Mac OS peuvent parfois avoir besoin d’une icône spécifique.

Voici quelques exemples :

• Android utilise une icône dédiée quand on met un lien vers un site sur l’écran principal.
• Idem pour iOS.
• Edge utilise une icône spécifique pour quand le site est épinglé.
• Safari sur Mac OS utilise une icône spéciale dans les onglets épinglés aussi.
• Windows 10 a aussi son format d’image pour quand votre site apparaît dans le menu démarrer.

Il y en a tout un tas, et à chaque fois les formats et les dimensions varient (il n’y a pas encore de standard bien défini pour ça).

Chrome et Windows 10 utilisent aussi des fichiers .manifest en XML pour avoir d’autres informations sur le raccourcis que vous cherchez à faire : nom du raccourcis, couleur principale, quel application doit l’ouvrir, etc.

Créer toutes es icônes à la main est fastidieux. Aussi, le mieux est d’utiliser le site Real Favicon Generator pour cela. Vous lui donnez une seule icône (en PNG ou SVG) et il va vous donner un ZIP avec tous les fichiers. C’est très pratique.

robots.txt

Pour les moteurs de recherche, il faut spécifier un fichier destinés aux ordinateurs robots qui analyse les pages web du monde entier. Ce fichier permet de dire aux moteurs de recherche si oui ou non vous voulez apparaître dans les résultats de recherche. Et si oui, sous quels conditions, quels fichiers, etc.

C’est un petit fichier texte à placer à la racine du site également :

/robots.txt

La syntaxe est décrite ici : robots-txt.com.

Sachez seulement que même si les moteurs de recherche prennent généralement en compte ce fichier, rien ne les y oblige. Je vous conseille donc, si vous ne voulez absolument pas que vos fichiers ne se retrouvent en ligne, de ne pas les publier ou bien d’en protéger l’accès. C’est à vous, le détenteur d’un site, de faire en sorte que vos fichiers soient protégés.

/humans.txt

Si robots.txt est destiné aux robots, le fichier humans.txt est destiné aux… humains !
Rares sont les sites qui le mettent, mais il permet de donner un peu d’information supplémentaire sur le site ou l’auteur.

Là aussi, c’est à la racine qu’il faut le mettre :

/humans.txt

Il n’y a pas vraiment de syntaxe standard : le fichier humans.txt est fait pour des humains et par des humains.

Une idée de syntaxe est proposé sur le site humanstxt.org, mais vous pouvez y mettre tout ce que vous jugerez utile à transmettre aux visiteurs curieux sur votre site.

Mes site disposent de ce fichier aussi. N’hésitez pas à y jeter un œil.

Un sitemap

Ce fichier est une carte de votre site : il contient les différents liens des pages de votre site. À nouveau, il est à la racine de votre site site :

/sitemap.xml

L’idée est là aussi que les moteurs de recherche découvrent ce fichier et voient toutes les pages de votre site d’un seul coup.

Google ou Bing proposent des outils pour leur soumettre vos sitemap (DDG et Qwant n’ont pas d’outils dédiés) : ça leur permet d’enregistrer votre site dans leurs indexes et de savoir par où commencer.

La syntaxe est spécifique et bien décrite sur Wikipedia.

Un fichier manifeste

/manifest.xml

Il n’est pas obligé de le mettre à la racine du site, car il est lié dans une balise méta dans la page, vous pouvez donc le mettre où vous voulez tant que vous liez son chemin dans la balise méta.

Il s’agit d’un fichier qui contient quelques informations supplémentaires pour le navigateur, en particulier mobile : quand vous faites un raccourcis sur votre bureau Android, ce fichier peut être appelé. Par exemple, il permet d’afficher le site avec ou sans la barre de tâches Android, ou même avec ou sans les boutons du navigateur, avec ou sans une icône spécifique, faisant apparaître votre page web comme une application native.

C’est le début de l’intégration d’une application-web progressive (PWA). Ici l’app aura toujours besoin d’une connexion internet pour fonctionner, mais l’affichage se fera en (quasi-)plein-écran sur mobile, sans la barre d’adresse et l’interface du navigateur.

Voir là : Progressive Web App (PWA) — Le fichier Web App Manifest

Un fichier openSearch.xml

Idem : vous pouvez le mettre où vous voulez tant que vous liez son chemin dans la balise méta.

Vous avez déjà vu un site qui propose d’installer un moteur de recherche ? Et ben vous pouvez faire ça également. Notez que cette implémentation est passive : c’est le navigateur qui proposera d’installer le moteur de recherche lorsqu’il le détecte sur votre site, un peu comme quand un site propose un flux RSS et que votre navigateur vous en propose l’abonnement via l’affichage d’une petite icône.

Cela peut être un petit plus pour votre site et c’est très simple à mettre en plus : une simple balise meta et un tout petit fichier XML statique à la base du site. C’est tout. Cela suffit pour que votre site propose un moteur de recherche :

/opensearch.xml

Les explications se trouvent sur Alsacréations. Essayez de regarder dans les options de mon site, par exemple :).

À noter que ceci ne fonctionne que si votre site est doté d’une fonction de recherche (ce que font les moteurs de blog, généralement). On pourrait l’adapter pour qu’il renvoie sur un moteur de recherche existant comme Google ou DDG, avec le paramètre « site: » dans la requête.

Une page security.txt

Il s’agit d’une page indiquant à quelqu’un qui découvre une faille dans votre site comment vous en faire part.
En pratique, il faut utiliser le répertoire .well-known et y mettre le fichier :

/.well-known/security.txt

La syntaxe est décrite sur le site dédié de l’initiative : securitytxt.org.

/ads.txt

Pour les sites qui diffusent de la publicité, il peut être nécessaire de spécifier quels annonceurs sont vos partenaires. Il y a un fichier pour ça : /ads.txt. Il s’agit simplement de la liste des annonceurs présents sur votre site et ce qu’ils y font (vente directe, annonces, etc.). Le standard a été établi pour des questions de sécurité et de lutte contre la fraude dans le domaine de la publicité en ligne.

En soit, le visiteur lambda s’en fiche, mais les annonceurs disposent d’outils pour analyser le fichier /ads.txt :

/ads.txt

La syntaxe et le projet sont décrites là : IAB Tech Labads.txt Specification Version 1.0.2.

Pour ma part, mes sites ne diffusent pas de publicité via des annonceurs. Seuls quelques liens sur mes blogs sont effectivement des liens affiliés (Amazon, ou eBay, ainsi que le lien vers mon hébergeur, dans le pied de page), mais cela reste de simples liens qui n’ont aucune possibilité d’afficher quoi que ce soit ici.

Mon fichier /ads.txt est donc vide.

Des fichiers que je recommande

Ces fichiers là ne sont pas forcément standard, néanmoins je conseille de les avoir.

Votre clé Publique GPG

Pour ceux qui utilisent GPG pour chiffrer les e-mails, vous devriez mettre votre clé Publique GPG sur votre site, en particulier si vous utilisez une adresse e-mail sur votre propre domaine.
Je propose l’un des deux formats suivants :

/pubkey.txt

/pubkey.asc

Je propose de le mettre à la racine du site car c’est là qu’un utilisateur peut commencer à chercher et surtout de le mettre dans un format texte, en ascii.

Vous pouvez également utiliser le fichier humans.txt pour y spécifier votre fichier GPG (c’est ce que je fais personnellement).

Des pages courantes

Selon moi, certaines pages devraient se retrouver sur tous les sites personnels : une page « à propos » par exemple, ou une page de contact.
Dans ce cas, vous pouvez configurer votre serveur pour qu’il affiche des pages sur les chemins /contact ou /about

Les fichiers d’erreurs

Quand vos visiteurs tentent d’accéder à une page qui n’existe pas, le site renvoie une erreur : 404 Not Found. Si la page demandée produit une erreur au niveau du serveur, c’est l’erreur 500 Internal Server Error
Il y a toute une liste d’erreurs comme ça. Les serveurs sont configurés pour afficher une page relativement épurée en cas d’erreurs, mais il est possible de la personnaliser.

Ainsi, si un visiteur cherche un fichier inexistant, vous pouvez afficher une page à vous avec un message personnalisé et un lien de retour vers la page d’accueil.

Rien n’est obligatoire ici, mais c’est toujours sympa d’avoir un site personnalisé jusqu’au bout. Mon site, par exemple, dispose d’une page personnalisée pour l’erreur 404.

Il y a juste une chose à avoir en tête : en cas d’erreur, le serveur ne fonctionne plus normalement. Il faut donc faire une page HTML simple et tout mettre dans cette page (y compris les images, les scripts…), si possible en Base64 : comme ça, le serveur (en erreur) n’a que le fichier d’erreur à envoyer et pas de requêtes supplémentaire, qui pourraient produire des erreurs supplémentaires et possiblement tout planter (voir ici pour convertir en Base64).

Pour conclure

En fait, l’idée derrière ce genre de petits fichiers est d’être trouvables facilement, d’avoir un chemin d’accès identique sur tous les sites, et de contenir des informations utiles.

Avoir un nom identique sur tous les sites, par exemple « /humans.txt », permet à quelqu’un de commencer à chercher même s’il ne sait pas que le fichier est là. Il cherche, mais si le fichier est là, il trouve, c’est tout bénéfique. Un peu comme une page « à propos », ou une page de contact.