URL de préfixe automatique : un détail qui fait gagner des minutes
cutty.dev détecte lorsque vous collez une adresse sans https:// et l'ajoute automatiquement. Cela peut sembler anodin, mais en pratique, cela fait la différence entre attendre deux secondes et cliquer sur « réessayer ».
Dans le formulaire de raccourcissement de lien, vous saisirez allegro.pl. La plupart des services de raccourcissement vous indiqueront que ce n'est pas une URL valide et vous demanderont de la saisir à nouveau avec https:// au début. cutty.dev ajoutera simplement https:// automatiquement et continuera.
Cela ressemble à une fonctionnalité qui mérite à peine d’être mentionnée. En pratique, c’est la différence entre :
- "j’ai collé, j’ai un lien court, je ferme la fenêtre" (2 secondes)
- "j’ai collé, erreur, je lis le message, j’ajoute https, encore une fois, j’ai le lien" (15-20 secondes)
Multipliez par le nombre de fois où vous collez l’URL par mois, plus la frustration de lire l’erreur, plus le moment « ah oui, c’est le protocole ». Un détail qui se mesure en minutes par personne et par mois.
Ce que fait exactement cutty.dev
Vous avez collé du texte dans le formulaire. Avant l'envoi au serveur, JavaScript vérifie s'il commence par un protocole (http://, https://, ftp://, mailto: etc.). Si il ne commence pas par un tel protocole, le système suppose qu'il s'agit simplement d'un domaine sans protocole et ajoute https:// au début.
C'est-à-dire :
allegro.pl→https://allegro.plgithub.com/twoj-profil/projekt→https://github.com/twoj-profil/projektwww.gazeta.pl→https://www.gazeta.pl
Et si un protocole est déjà défini (même s’il est incorrect), le système laisse tel quel et continue la vérification :
http://example.com→ restehttp://example.com(autorisé)ftp://example.com→ refusé (seulement http/https)javascript:alert(1)→ refusé (protection XSS)
Pourquoi moi et pas les autres ?
La plupart des raccourcisseurs de liens effectuent une validation standard des URL via new URL(string). Le constructeur URL dans le navigateur/JavaScript est strict : s’il n’y a pas de protocole, il lance une erreur. La sortie par défaut pour new URL("allegro.pl") est un TypeError.
C’est un comportement correct pour la plupart des applications. Mais pour un formulaire de raccourcissement d’URL, où l’utilisateur colle une URL copiée depuis la barre d’adresse ou une autre application, cette rigidité est un obstacle plutôt qu’une aide.
La solution tient en cinq lignes de JavaScript :
function sanitizeUrl(input) {
const trimmed = input.trim();
const hasProtocol = /^[a-z][a-z0-9+.-]*:/i.test(trimmed);
const normalized = hasProtocol ? trimmed : "https://" + trimmed;
// dalsza walidacja przez new URL(normalized)
}
Cinq lignes de code, une quinzaine de secondes en moins de frustration par utilisateur par jour. Je ne sais pas pourquoi la plupart du marché ne le fait pas. Peut-être parce que « standard » signifie « comment fonctionne le constructeur d'URL ».
Les détails dans l'UX sont disproportionnellement importants
cutty.dev possède une douzaine de ces éléments qui ne figurent dans aucune liste de fonctionnalités, car chacun pris individuellement semble insignifiant :
- Trimmer les espaces blancs avant la validation — une URL collée avec un espace à la fin ne provoque pas d'erreur
- Hash conservé —
https://example.com/page#sectionconserve#sectionaprès le raccourcissement - Chaînes de requête conservées —
?utm_source=testpasse sans être tronqué - Mise à niveau automatique du protocole —
http://vershttps://lorsque l'URL source prend en charge TLS (prévu, pas encore en production) - Domaines IDN —
źdźbło.plest automatiquement converti en punycode - Caractères polonais dans le slug — automatiquement remplacés par de l'ASCII lors de la création d'une extension personnalisée (
różowy-link→rozowy-link) - Détection des protocoles dangereux —
javascript:,data:,file:,mailto:rejetés avec un message spécifique
Chacun de ces détails permet d’économiser 5 à 30 secondes et un moment d’irritation à quelqu’un. Ensemble, cela fait la différence entre « j’aime cette application » et « ça marche bien ».
Et ensuite pour les détails UX ?
Liste des choses que je souhaite faire dans le futur :
- Collage intelligent — détectez quand l'utilisateur colle du texte contenant une URL au milieu d'autres mots, et extrayez uniquement l'URL
- Collage en masse — une liste d'URL collée (une par ligne) crée plusieurs liens courts simultanément
- Suggérer des slugs — sur la base du titre de la page cible, proposez 3 extensions de marque au choix
- Aperçu automatique OG — affichez l'aperçu des cartes Open Graph immédiatement après le collage de l'URL, avant de raccourcir
Chacune de ces fonctions est une « fonction à cinq lignes qui ne semble rien faire ». L’ensemble fait la différence entre un outil qui est correct et un outil que vous souhaitez utiliser au quotidien.
Essayez par vous-même
Coller quelque chose — allegro.pl ou github.com ou news.ycombinator.com. Le système ajoutera automatiquement le protocole et continuera. Sans attente, sans erreur, sans « réessayer ».
Si ce type de détail UX vous intéresse, faites-moi savoir dans quelle direction aller ensuite. hello@cutty.dev.