Résumé

  • La RFC 2345 isolait un problème de localisation : trouver des informations web à partir d’un nom usuel, sans prétendre régler l’administration du DNS ni les droits sur ce nom.
  • Le serveur choisissait lui-même les variantes, abréviations et règles de correspondance ; le protocole ne garantissait pas qu’un rapprochement fût juste.
  • La réponse ne portait qu’une URL et un libellé libre. Elle ne contenait ni identifiant légal, ni provenance, ni date de vérification, ni preuve du contrôle du domaine.
  • Le démonstrateur classait les réponses, limitait la liste à dix et pouvait ouvrir automatiquement un résultat unique : unicité d’affichage ne signifiait donc ni unicité réelle ni exhaustivité.
  • Pour conclure à une identité ou à un service fiable, il fallait encore vérifier l’entité, le domaine, la délégation DNS, l’authenticité de la page et le résultat de la transaction.

Une réponse courte, une longue liste de décisions invisibles

Le dispositif proposé avait une élégance réelle. Le client ouvrait une connexion WHOIS sur le port 43, envoyait une ligne, recevait une ou plusieurs lignes, puis la connexion se fermait. Chaque réponse plaçait l’URL avant le nom affiché, les espaces servant de séparateur facile à reconnaître.

Ce format convenait au problème choisi. À mesure que le Web grandissait, deviner l’adresse d’une société sous la forme www.nom.com devenait moins crédible. Plusieurs entreprises pouvaient partager un nom court dans des métiers ou des pays différents. Une marque et une raison sociale ne se confondaient pas nécessairement. La RFC 2345 proposait donc un répertoire, au lieu de charger le DNS d’une fonction de moteur de découverte.

Mais la brièveté de la ligne masquait le travail antérieur. Quel jeu de données avait été consulté ? Comment les noms avaient-ils été normalisés ? Une filiale et sa maison mère avaient-elles été séparées ? Quelle source reliait le site à l’entreprise ? Quelle entrée avait été écartée par le classement ? Rien de cela n’apparaissait dans le résultat.

Le nom envoyé n’était pas un identifiant

La requête contenait un « nom d’entreprise » supposé. La RFC ne lui imposait pas de définition juridique. Elle laissait au serveur l’interprétation des variantes orthographiques, des abréviations et des formes acceptables. Elle précisait même que la justesse ou l’erreur du rapprochement n’était pas couverte par la spécification.

Cette réserve est décisive. Un protocole peut imposer une casse insensible, un codage et un séparateur sans résoudre l’identité. « Atlas », par exemple, pourrait désigner des entreprises sans lien entre elles. Une translittération peut produire plusieurs graphies. Le suffixe juridique peut disparaître dans l’usage courant. Une société absorbée peut continuer à exploiter une ancienne marque.

Le serveur devait prendre position sur ces ambiguïtés. Deux fournisseurs pouvaient adopter des règles différentes et rester tous deux conformes. La réponse attestait donc un choix effectué par un service, pas l’existence d’une clé universelle reliant le texte à une personne morale.

Le libellé de sortie restait libre

La seconde moitié de la ligne portait le nom que le client devait montrer à l’utilisateur. Pourtant, la RFC 2345 refusait volontairement d’en fixer la sémantique. Le serveur pouvait y mettre un nom seul, un nom accompagné d’un lieu ou d’un secteur d’activité, voire d’autres indications.

Ce champ était conçu pour faciliter le choix, non pour servir de certificat d’immatriculation. Il ne disait pas quel registre avait été consulté, à quelle date, dans quelle juridiction, ni sous quel numéro. Il n’indiquait pas non plus si l’entreprise avait fourni l’adresse, si un éditeur l’avait déduite, ou si une collecte automatisée l’avait reprise.

La simplicité diminuait le coût d’intégration pour le client. En contrepartie, elle supprimait les éléments qui auraient permis d’évaluer la valeur probante de l’association.

L’URL n’était pas un acte de propriété

Une URL sert à localiser et à accéder à une ressource. La RFC 1738 la décrivait dans ces termes et avertissait déjà qu’une adresse pointant vers un objet à un instant donné pouvait plus tard désigner autre chose.

Associer une URL à un nom ne démontrait donc pas que l’entreprise avait enregistré le domaine. Le titulaire pouvait être une maison mère, un prestataire, un distributeur ou une autre entité. La délégation DNS pouvait changer. La page pouvait rediriger vers un autre domaine. Un site authentique au moment de la vérification pouvait devenir obsolète ou compromis.

La RFC 2345 envisageait elle-même le cas d’un serveur de traduction usurpé qui renverrait une mauvaise adresse. Elle recommandait de prêter attention aux certificats, signatures et autres indices d’authenticité. Le mapping n’était donc pas présenté comme une preuve autonome ; il conduisait vers des contrôles supplémentaires.

Même l’enregistrement d’un domaine ne réglait pas les droits sur le nom. La RFC 1591 rappelait qu’un enregistrement ne conférait aucun statut de marque. Une entrée de répertoire, qui ne prouvait pas même cet enregistrement, ne pouvait raisonnablement porter une conclusion plus forte.

Le résultat unique créait une fausse sensation d’évidence

Le client envisagé pouvait demander confirmation lorsqu’il recevait une seule ligne, ou ouvrir directement l’URL. Le démonstrateur choisissait l’ouverture automatique : un seul rapprochement dans la base déclenchait le navigateur sans nouvelle intervention.

Le geste rendait le service agréable. Il rapprochait cependant deux événements distincts. « Un seul résultat dans cette base » devenait « voici l’entreprise recherchée » dans l’expérience utilisateur.

Or un résultat unique pouvait provenir d’une base incomplète, d’une graphie qui éliminait des candidats, d’une fusion excessive de noms ou d’une règle de classement. Un autre fournisseur pouvait répondre autrement. L’unicité était locale au fournisseur, à son jeu de données et à cet instant.

L’automatisation n’ajoutait aucune preuve. Elle augmentait seulement la conséquence d’un choix éditorial caché.

Dix réponses pouvaient en cacher d’autres

Le serveur de démonstration annonçait environ 209 000 fiches fournies par Dun & Bradstreet. Lorsque dix entrées ou plus correspondaient à la requête, seules les dix premières étaient renvoyées. Le client présentait deux à dix noms classés par score.

La liste n’était donc pas un inventaire complet. Son ordre dépendait d’un score que le protocole ne définissait pas. Le dixième élément marquait une limite d’affichage, pas la fin du monde observé.

Le message « Not found » avait la même portée locale. Il signifiait que le texte n’avait rien trouvé dans la base interrogée. Il ne démontrait ni l’inexistence de l’entreprise, ni l’absence de site, ni l’impossibilité de la trouver par une autre source.

Le démonstrateur ne prévoyait aucun mécanisme d’ajout ou de correction. Ses auteurs déclinaient la responsabilité de l’exactitude des données et reconnaissaient que certaines sociétés pouvaient manquer. Ces propriétés décrivaient directement la qualité accessible à l’utilisateur ; elles ne relevaient pas d’une hypothétique erreur d’implémentation.

La qualité était en amont du protocole

La RFC formulait sa limite la plus importante dans la comparaison avec les moteurs de recherche : la qualité dépendait de l’annuaire sous-jacent et du travail éditorial et documentaire consacré à sa construction. Le protocole ne traitait ni l’un ni l’autre.

Il pouvait garantir qu’une ligne était correctement délimitée. Il ne pouvait garantir que le dossier source était récent. Il pouvait transmettre de l’UTF-8. Il ne pouvait préciser la langue ni la juridiction de l’entité. Il pouvait renvoyer plusieurs candidats. Il ne pouvait rendre le classement neutre.

Une réponse techniquement parfaite pouvait donc transporter une association mal documentée. Inversement, un annuaire soigneusement vérifié pouvait employer le même format minimal. Pour distinguer les deux, il fallait une preuve hors protocole : sources, dates, méthode de rapprochement, politique de correction et responsabilité éditoriale.

La pluralité des fournisseurs faisait partie du résultat

La RFC ne voyait aucune raison technique d'imposer un fournisseur unique ou un registre des fournisseurs. Le client devait pouvoir choisir son serveur.

Cette ouverture favorisait des approches adaptées à différents marchés et langues. Elle signifiait aussi que l’identité du serveur était indispensable pour interpréter une réponse. Sans le nom du fournisseur, la date, la requête exacte et la version du jeu de données, une capture perdait une partie essentielle de sa provenance.

La concurrence pouvait améliorer la qualité au fil du temps. Elle ne certifiait pas automatiquement le résultat reçu par un utilisateur particulier. Un marché est un mécanisme d’incitation, pas une signature apposée sur chaque ligne.

Ouvrir la page ne terminait pas la vérification

Même un rapprochement exact ne promettait pas un service utilisable. Il restait à résoudre le DNS, atteindre l’hôte, examiner la chaîne de redirection, vérifier le contexte TLS, confirmer que la page relevait bien de l’entité annoncée et observer le résultat recherché.

Une page pouvait être officielle tout en décrivant un service arrêté. Un formulaire pouvait s’afficher sans accepter la transaction. Un domaine pouvait appartenir au groupe sans représenter la filiale attendue. Une réponse du serveur web n’établissait pas la qualité du support ou la continuité future.

Le répertoire répondait à « où regarder ? ». Il ne répondait pas à « qui contrôle ? », « qui s’engage ? » ou « le service fonctionnera-t-il ? ».