Auto-prefix URL — un petit détail qui fait gagner des minutes

Vous saisissez allegro.pl dans le formulaire. Vous cliquez. Et alors ?

Dans la plupart des réducteurs de liens, vous recevez à ce moment-là un message d'erreur. Quelque chose du style "ce n'est pas une URL valide". Parce qu'il manque le https:// au début. Alors vous revenez en arrière, vous ajoutez le protocole, vous cliquez à nouveau, et seulement maintenant vous avez votre lien court.

cutty.dev ne fait pas ça. Il se contente d'ajouter https:// et continue son chemin, comme si de rien n'était.

Je sais ce que cela semble être. Comme une fonctionnalité qui mérite à peine un paragraphe, sans parler d'un article entier. Et pourtant, je suis là en train de l'écrire, car ce petit détail est pour moi un petit manifeste de ma façon de penser la construction de l'outil auto-prefix URL et de tout le reste de ces facilités invisibles.

Deux secondes contre vingt

Calculons. Vraiment, avec des chiffres, car sinon ce n'est que du bavardage.

Premier chemin : vous collez, vous avez le lien, vous fermez la fenêtre. Deux secondes. Peut-être trois.

Deuxième chemin : tu colles, erreur, tu lis le message (une seconde ou deux pour comprendre de quoi il s'agit), tu ajoutes le protocole, tu cliques encore une fois, et seulement maintenant le lien. Quinze, vingt secondes. Plus ce petit moment d'irritation, ce "ah oui, c'est vrai, le protocole" silencieux, qui ne coûte rien individuellement, mais qui s'accumule.

Et maintenant, multipliez par le nombre de fois où vous collez une adresse par mois. Pour moi, c'est des dizaines. Pour quelqu'un qui gère des liens professionnellement — des centaines. Soudain, ce détail "à peine digne d'être mentionné" s'accumule en minutes par mois. Par personne.

C'est précisément cette arithmétique que la plupart des gens ignorent, car chaque cas individuel semble trop petit pour qu'on s'en préoccupe.

Qu'est-ce qui se cache réellement en dessous

Le mécanisme est banal et je ne le cache pas du tout. Vous collez le texte dans le champ. Avant que quoi que ce soit ne soit envoyé au serveur, un morceau de JavaScript vérifie si ce que vous avez saisi commence par un protocole — http://, https://, ftp://, mailto:, peu importe. Si ce n'est pas le cas, le système suppose que vous faites référence à un domaine ordinaire et ajoute https:// au début.

En pratique :

• allegro.pl devient https://allegro.pl
• github.com/twoj-profil/projekt en https://github.com/twoj-profil/projekt
• www.gazeta.pl en https://www.gazeta.pl

Et si le protocole est déjà présent, même s'il est étrange, le système ne l'écrase pas. Il le laisse et cherche ensuite quoi en faire. http://example.com passe (autorisé). ftp://example.com part à la poubelle, car nous n'acceptons que http et https. Et javascript:alert(1) est expulsé immédiatement, car ce n'est pas une adresse, mais une tentative d'injection de quelque chose de malveillant (XSS classique, merci, non).

Pourquoi je l'ai, alors que la moitié du marché ne l'a pas

Ça devient intéressant ici, car la réponse est un peu drôle.

La méthode standard pour valider une adresse dans un navigateur est le constructeur new URL(string). Et ce constructeur est dur. Sans compromis. S'il n'y a pas de protocole — il renvoie une erreur. new URL("allegro.pl") vous renvoie simplement une TypeError, c'est tout.

Et tu sais quoi ? C'est un comportement correct. Pour la grande majorité des applications, c'est exactement ce que tu veux. Mais dans un formulaire de réduction de lien, où l'on copie l'adresse depuis la barre du navigateur ou depuis le message de quelqu'un, cette rigueur se transforme d'un avantage en obstacle. Soudain, un outil qui est censé te faire gagner du temps te demande de corriger quelque chose que pourtant il comprend parfaitement.

Contourner cela ne prend littéralement que quelques lignes :

function sanitizeUrl(input) {
  const trimmed = input.trim();
  const hasProtocol = /^[a-z][a-z0-9+.-]*:/i.test(trimmed);
  const normalized = hasProtocol ? trimmed : "https://" + trimmed;
  // dalej leci normalna walidacja przez new URL(normalized)
}

Cinq lignes. Quelques secondes de friction en moins par jour, pour tous ceux qui collent des adresses. Honnêtement, je ne sais pas pourquoi ce n'est pas une norme partout. Je soupçonne que c'est parce que « le constructeur d'URL fonctionne simplement comme ça » et que personne n'a voulu s'en occuper. De l'inertie, pas de la mauvaise volonté.

Petite digression sur ce que signifie « normalement »

Car cette histoire avec new URL() est un excellent exemple de quelque chose de plus large. Beaucoup de choses qui, dans le logiciel, sont considérées comme "c'est ainsi que l'on fait", sont en réalité "c'est ainsi que les paramètres par défaut d'une certaine bibliothèque, que personne n'a remise en question, en ont décidé". Le mode strict du constructeur n'est pas une décision des concepteurs de cutty ni de la concurrence — c'est une décision des auteurs de la spécification URL, prise dans un contexte totalement différent, pour des usages totalement différents.

Et ensuite, tout le marché hérite de ce choix par défaut et l'appelle "standard". J'ai l'impression que les meilleurs produits naissent précisément dans ces endroits où quelqu'un s'est arrêté et a demandé : attendez, est-ce que ce comportement sert mon utilisateur, ou seulement ma bibliothèque ? Le plus souvent, la réponse est : la bibliothèque. Et c'est alors qu'il vaut la peine de revenir vers l'humain avec cinq lignes de code.

Il y a plus de ces détails qu'il n'y paraît

L'auto-préfixe n'est qu'un des nombreux éléments de ce type que vous ne trouverez sur aucune liste de fonctionnalités. Car si on les y inscrivait, chacun d'entre eux paraîtrait ridiculement petit :

• suppression des espaces avant la validation, pour qu'un espace accidentel à la fin de l'adresse collée ne casse pas tout
• conservation de l'ancre, c'est-à-dire que #section dans https://example.com/page#section ne disparaît pas après le raccourcissement
• les paramètres de requête (?utm_source=test) passent en entier, rien n'est coupé en chemin
• les domaines avec des caractères polonais, źdźbło.pl, sont automatiquement convertis en punycode
• les lettres polonaises dans la propre extension sont remplacées par de l'ASCII (różowy-link devient rozowy-link)
• les protocoles dangereux — javascript:, data:, file: — sont rejetés avec un message spécifique et compréhensible

(Il est encore prévu de faire un upgrade automatique de http:// vers https:// lorsque le serveur cible prend en charge le chiffrement. Cela ne fonctionne pas encore en direct, donc je ne vais pas prétendre le contraire.)

Chacun de ces détails fait gagner à quelqu'un cinq, dix, trente secondes et un soupir. Individuellement, rien. Ensemble, c'est la différence entre "ça fonctionne OK" et "j'aime l'utiliser".

Ce que j'aimerais encore ajouter

Liste de souhaits pour l'avenir, car y penser me procure tout simplement du plaisir :

• collage intelligent — détecter une adresse cachée au milieu d'une phrase et extraire l'URL seul entre les mots
• collage en masse — une liste d'adresses, une par ligne, et pour chacune, un lien court distinct immédiatement
• suggestions de terminaisons — proposer trois slugs de marque au choix basés sur le titre de la page de destination
• aperçu Open Graph immédiatement après le collage, avant même que vous ne cliquiez sur "raccourcir"

Chacun de ces éléments n'est qu'une "fonction de cinq lignes qui ne semble rien valoir". Et tous ensemble ? C'est précisément la frontière entre un outil qui est correct et celui que l'on utilise chaque jour sans réfléchir. Si vous voulez voir comment cela fonctionne dès maintenant, collez dans cutty.dev n'importe quoi sans protocole — allegro.pl, github.com, news.ycombinator.com — et voyez que rien ne vous met de bâtons dans les roues.

Enfin, un peu personnellement

J'ai longtemps pensé que les produits gagnaient grâce à de grandes fonctionnalités. Par cette chose spectaculaire unique, qui peut être présentée sur une diapositive et dont les gens parleront. Et oui, c'est parfois le cas.

Plus je construis de cutty, plus je sens fortement que la loyauté de l'utilisateur naît ailleurs — dans ces centaines de microsecondes que personne ne remarque consciemment. Vous ne vous souvenez pas que l'outil a ajouté lui-même https://. Vous vous souvenez seulement de l'impression générale que "c'est plutôt agréable à utiliser", que "ça n'énerve pas". Cette impression ne vient pas de nulle part. Elle est composée de dizaines de décisions de cinq lignes que personne ne défendrait individuellement comme étant "valant la peine d'y consacrer du temps".

C'est peut-être là que réside l'artisanat. Pas dans un seul grand geste, mais dans la persévérance à prendre systématiquement le parti de l'utilisateur face à un formulaire — même s'il ne s'agit que de deux misérables secondes. Et vous ? Qu'est-ce qui vous a agacé récemment dans un outil, de façon si infime qu'il est presque gênant de l'avouer ? Car c'est généralement là que se trouve le meilleur travail à accomplir.