Un index public vient d’être rebaptisé, et j’ai vu passer la nouvelle avec un mélange de satisfaction et d’agacement. Satisfaction parce que la décision est juste. Agacement parce qu’il aura fallu attendre des années pour corriger une erreur de bon sens que tout le monde avait pourtant sous les yeux. Le 3 juin 2026, le grand dépôt ouvert de données de crawl du web a annoncé que son index colonnaire, longtemps appelé Columnar Index, s’appellerait désormais URL Index. Rien d’autre n’a bougé : ni les fichiers, ni le schéma, ni l’emplacement de stockage, ni la façon d’interroger les données. Un simple changement de nom. Et pourtant, je vais le dire franchement, ce détail en apparence cosmétique est une des décisions les plus saines que j’aie vues dans l’écosystème des données ouvertes depuis longtemps, parce qu’il remet enfin le sens au-dessus de la technique.
Je travaille avec ce type de ressources depuis des années, et je vais vous expliquer pourquoi un mot remplacé par un autre mérite qu’on s’y arrête, ce que cette histoire révèle de nos travers de techniciens, et pourquoi je pense que la plupart des organisations feraient bien de s’en inspirer pour leur propre vocabulaire interne.
Pourquoi nommer une chose d’après son format est une faute de raisonnement
Le problème de l’ancien nom tient en une phrase : il décrivait la boîte, pas le contenu. Le terme colonnaire renvoie à un format de stockage de fichiers, en l’occurrence Apache Parquet, qui range les données par colonnes plutôt que par lignes. C’est une information technique tout à fait réelle et utile, mais elle ne vous dit absolument rien sur ce que l’index contient ni sur ce qu’il sert à faire. C’est comme baptiser une bibliothèque d’après le matériau de ses étagères. Vous savez que c’est en chêne, vous ne savez toujours pas s’il y a des romans ou des manuels de plomberie à l’intérieur.
Or cet index a une fonction parfaitement claire : il référence les URL et les fichiers d’archive du corpus, pour qu’on puisse retrouver et requêter une page précise sans avoir à parcourir des téraoctets de données brutes. Sa raison d’être, c’est l’URL. Pas le format. En l’appelant désormais URL Index, on dit enfin ce qu’il est et non comment il est rangé. Et croyez-en mon expérience de terrain : cette distinction, qui paraît évidente une fois posée à voix haute, est l’une des plus systématiquement bafouées dans nos métiers.
Je vois cette confusion partout. Des équipes qui appellent une table par le nom de la technologie qui l’héberge, des dossiers nommés d’après l’outil qui les a générés, des colonnes baptisées selon le type de données et non selon l’information qu’elles portent. À chaque fois, le raisonnement est le même : on nomme avec ce qu’on a sous les yeux au moment de la création, c’est à dire la mécanique, et on oublie que le nom va survivre à cette mécanique et servir pendant des années à des gens qui se moquent éperdument de la plomberie. Un nom n’est pas une étiquette pour celui qui crée la chose. C’est un contrat avec tous ceux qui l’utiliseront ensuite.
Le vrai déclencheur : anticiper un futur où tout sera colonnaire
La motivation profonde du changement n’est pas esthétique, elle est stratégique, et c’est ce qui la rend intelligente. L’organisation a expliqué qu’elle compte publier davantage de jeux de données dans des formats colonnaires. Et là, le piège devient évident. Si vous appelez un jeu de données le colonnaire, que faites-vous le jour où vous en avez cinq qui sont tous colonnaires ? Vous vous retrouvez avec cinq objets qui partagent la même caractéristique technique et qu’aucun nom ne permet plus de distinguer. Le format, qui était déjà une mauvaise base de nommage, devient carrément un facteur d’ambiguïté.
C’est exactement le genre d’anticipation que j’aimerais voir plus souvent. La plupart des dettes de nommage que je rencontre proviennent de ce manque de projection. On choisit un nom qui fonctionne tant qu’il n’existe qu’un seul objet de ce type, et le jour où le deuxième arrive, le nom du premier devient un mensonge ou une source de confusion. Renommer en amont, avant que la collision n’arrive, avant que des dizaines de tutoriels et de scripts ne gravent l’ancien terme dans le marbre, c’est de l’hygiène préventive. C’est moins coûteux maintenant qu’il n’y a qu’un index concerné, plutôt que dans deux ans avec une famille entière de jeux de données à désambiguïser.
Je veux insister sur un point que beaucoup négligent : les noms sont des actifs à durée de vie longue. Une requête écrite aujourd’hui sera peut-être encore exécutée dans cinq ans. Un article de documentation rédigé ce mois-ci sera lu par des gens qui n’étaient pas encore dans le métier. Quand vous choisissez mal un nom, vous ne créez pas un petit inconfort ponctuel, vous semez une confusion qui se démultiplie à chaque nouvelle personne qui croise le terme. Le coût d’un mauvais nom n’est jamais payé par celui qui le choisit. Il est payé, en petites coupures, par la longue file de ceux qui viennent après.
Ce que le format colonnaire change réellement pour qui travaille la donnée
Au delà du nom, il faut rappeler pourquoi ce format mérite tant d’attention, car c’est lui qui justifie l’existence même de cet index. Le stockage par colonnes n’est pas un caprice de spécialiste. Quand vous menez une analyse en masse, vous ne lisez généralement qu’une poignée de colonnes sur la totalité disponible. Un format orienté lignes vous oblige à parcourir des enregistrements entiers pour n’en extraire que deux ou trois champs. Un format orienté colonnes vous laisse ne lire que ce dont vous avez besoin. Sur des volumes pareils, cela se traduit par des requêtes plus rapides et une facture de calcul bien plus légère. C’est du temps gagné et des ressources économisées, ce qui n’est jamais un détail quand on raisonne à l’échelle du web entier.
L’autre force de ce choix, c’est l’interopérabilité. Le format est lisible par tout un éventail d’outils analytiques répandus, des moteurs de requête distribués aux bibliothèques d’analyse que les praticiens utilisent au quotidien sur leur propre machine. Autrement dit, on ne vous enferme pas dans un écosystème propriétaire. Vous attaquez les mêmes fichiers avec l’outil qui vous convient, selon que vous explorez un échantillon sur votre poste ou que vous lancez un traitement massif sur une infrastructure distribuée. Cette liberté est précieuse, et c’est précisément ce que de mauvaises décisions de nommage finissent par masquer : à force de parler du format, on oubliait de parler de ce que ce format vous permet de faire concrètement avec les URL.
Voilà pourquoi le renommage me semble doublement pertinent. Il ne se contente pas de clarifier l’étiquette, il recentre l’attention sur la finalité. On cesse de vendre un format pour parler enfin d’un usage. Et dans mon métier, où l’on passe son temps à expliquer à des gens pressés à quoi sert tel ou tel jeu de données, un nom qui dit sa fonction est un cadeau. Il fait la moitié de la pédagogie à ma place.
La leçon de méthode : nommez par l’intention, jamais par l’outil
Si je devais extraire une seule règle de toute cette affaire, ce serait celle ci : nommez vos choses par ce qu’elles servent à faire, pas par la technologie qui les fabrique. C’est un principe que je répète à chaque mission, et que je vois ignoré avec une régularité déprimante. Les technologies changent. Les formats évoluent. L’outil à la mode aujourd’hui sera remplacé demain. Mais l’intention, la fonction, le besoin auquel répond la donnée, tout cela reste stable bien plus longtemps. Ancrer un nom dans l’intention, c’est lui donner une chance de vieillir sans devenir absurde.
Le corollaire est rassurant, et l’annonce l’a souligné avec honnêteté : changer un nom n’oblige pas à tout casser. Les données restent identiques, le schéma ne bouge pas, l’emplacement de stockage est inchangé, et les requêtes existantes continuent de fonctionner sans la moindre modification. C’est la démonstration que la clarté sémantique et la stabilité technique ne sont pas ennemies. On peut corriger le vocabulaire sans imposer de migration douloureuse à qui que ce soit. Voilà un argument que j’oppose souvent aux équipes paralysées par la peur du changement : renommer ne veut pas forcément dire reconstruire. Parfois, c’est juste accrocher la bonne étiquette sur la bonne boîte.
Je terminerai cette partie par une mise en garde. Renommer tôt est sain, mais renommer sans cesse est destructeur. La valeur d’un nom tient en partie à sa stabilité. Si vous rebaptisez vos jeux de données tous les six mois au gré des humeurs, vous détruisez la confiance et la mémoire collective autour de ces ressources. Le bon réflexe, c’est de réfléchir suffisamment en amont pour ne renommer qu’une fois, au bon moment, pour la bonne raison, et de s’y tenir ensuite. Un changement réfléchi vaut mieux que dix corrections nerveuses. La sobriété dans le renommage est aussi importante que la lucidité qui le déclenche.
FAQ
Ce renommage va-t-il casser mes requêtes ou mes scripts existants ?
Non, et c’est tout l’intérêt de la démarche. Le changement est purement nominal. Les fichiers se trouvent au même emplacement de stockage, le schéma est identique, et la méthode d’interrogation n’a pas changé. Vos traitements actuels continueront de fonctionner sans aucune retouche. Seul le nom par lequel on désigne l’index a évolué, pour mieux refléter sa fonction. Vous n’avez donc rien à migrer, rien à réécrire, simplement un nouveau vocabulaire à adopter dans vos propres notes et documentations.
Pourquoi ne pas avoir gardé le nom d’origine puisque la donnée est la même ?
Parce qu’un nom n’est pas neutre : il oriente la compréhension. L’ancien terme décrivait le format de stockage, une information qui ne renseignait en rien sur le contenu réel. À mesure que d’autres jeux de données adopteront ce même format, désigner un seul d’entre eux par le format serait devenu une source de confusion permanente. Le nouveau nom dit ce que l’index contient, des URL, et règle ce risque par avance. C’est une correction préventive, faite tant qu’il était encore facile de la faire.
Quelle leçon en tirer pour mes propres jeux de données ?
La plus utile : nommez par la fonction, jamais par l’outil ou le format. Demandez-vous toujours à quoi sert une ressource avant de la baptiser, et projetez-vous dans un futur où vous en aurez plusieurs du même genre. Si le nom que vous envisagez devient ambigu dès qu’un deuxième objet similaire apparaît, c’est qu’il est mauvais. Un bon nom survit à la multiplication des objets et au remplacement des technologies. C’est un investissement discret qui vous épargnera des années de malentendus.
Ce qui me frappe le plus dans cette histoire, ce n’est pas le mot remplacé, c’est ce qu’il révèle de notre rapport collectif au langage technique. Nous passons un temps considérable à optimiser des formats, à affiner des schémas, à grappiller des secondes de calcul, et nous négligeons l’acte le plus simple et le plus durable de tous : appeler les choses par ce qu’elles sont. Un index qui dit enfin qu’il indexe des URL, ce n’est pas une révolution technique. C’est quelque chose de plus rare et de plus précieux, un rappel que la clarté est une discipline. Et si une organisation qui manipule l’un des plus grands corpus du web ouvert prend la peine de corriger un seul mot pour rendre service à ceux qui viendront après, je crois que nous avons tous, à notre échelle, une étiquette mal posée à aller décrocher.