Champ texte libre ou référentiel officiel : la dette qui pourrit votre base

Vous gérez une base de clients ou de prospects. Pour chaque entreprise, vous avez un champ “secteur d’activité”, un champ “code juridique”, un champ “code postal”. À la création de votre outil, ces champs sont en texte libre. C’est rapide, c’est simple, ça avance. Six mois plus tard, dans le même outil, vous lisez “BTP”, “btp”, “Batiment”, “Bâtiment”, “Construction” pour la même réalité. Trois ans plus tard, vous ne pouvez plus filtrer, ni segmenter, ni produire un rapport sans repasser chaque ligne à la main.

La mauvaise qualité de données coûte en moyenne 12,9 millions de dollars par an aux entreprises, selon une enquête Gartner souvent citée (source MIT Sloan Review). À l’échelle d’une PME, on n’est pas sur 12 millions, mais l’effet est identique : vous perdez la capacité de piloter sur vos propres données. Et tout commence par un choix anodin, fait au lancement de l’outil, par un développeur qui voulait livrer vite.

Le champ libre, ce mensonge confortable

Au lancement de votre outil métier, le champ texte libre est une bénédiction pour tout le monde. Vous ajoutez un attribut sans avoir besoin de migration. Le développeur livre en deux heures. L’utilisateur saisit ce qu’il veut. Tout le monde est content.

Le problème démarre à la troisième semaine d’usage. Vos utilisateurs tapent ce qu’ils ont en tête, avec leurs abréviations, leurs majuscules, leurs fautes, leurs synonymes. Vous croyez avoir une donnée structurée. Vous avez en réalité du texte étiqueté “secteur d’activité” qui n’est qu’un bloc-notes.

Les symptômes classiques apparaissent rarement en même temps, ce qui rend le diagnostic difficile :

• Vos exports vers Excel contiennent 47 variantes de “Restaurant” : “Restaurant”, “Restauration”, “RESTO”, “Resto”, “café-restaurant”, “Restauration rapide”, “restaur.”
• Votre filtre “secteur” ne sert à rien. Aucune des cases ne contient l’intégralité des entreprises concernées.
• Vos tableaux de bord croisent mal. “Combien de clients dans la santé ?” devient une réunion d’une heure pour s’accorder sur ce qui compte comme “santé”.
• Un nouvel utilisateur reproduit les divergences des anciens. Il invente sa propre orthographe, parce qu’il ne voit pas ce que les autres ont saisi.
• Le jour où vous voulez exporter vers un CRM, un outil de scoring ou un tableau de bord, vous découvrez qu’aucun champ n’est utilisable en l’état.

Il faut comprendre que ce piège est invisible parce que rien ne casse. Aucune erreur applicative, aucune alerte, aucun crash. Le formulaire tourne, les utilisateurs saisissent, la base se remplit. Le coût se révèle au moment où vous voulez exploiter la donnée. Et à ce moment-là, vous découvrez que vous n’avez pas une base, vous avez un cimetière de chaînes de caractères.

Le réflexe paresseux, appeler une API publique à chaque saisie

Quand vous décidez enfin de structurer le champ, le premier réflexe est d’appeler une API publique. “L’INSEE expose une API Sirene avec toutes les entreprises, on n’a qu’à interroger ça en direct au moment où l’utilisateur tape.”

C’est tentant pour trois raisons légitimes : pas de table à maintenir en interne, donnée toujours fraîche, pas de seed à recharger quand le référentiel évolue. C’est aussi fragile pour cinq raisons que personne ne mentionne au moment du choix.

Premièrement, vous dépendez du réseau à chaque frappe utilisateur. Votre formulaire fait un appel sortant chaque fois qu’un caractère est tapé. Si l’API tousse, votre formulaire tousse aussi. Si votre utilisateur est dans un train avec une connexion qui saute, le champ devient inutilisable.

Deuxièmement, les APIs publiques ont des plafonds. L’API Sirene de l’INSEE est limitée en accès standard et impose une authentification via le portail développeur (documentation officielle INSEE). À 5 caractères tapés par utilisateur, sur 12 utilisateurs en simultané, vous explosez la limite sans vous en apercevoir, sauf au support.

Troisièmement, la latence se voit. Un autocomplete qui prend 400 ms par caractère est inutilisable. L’utilisateur tape plus vite que la réponse n’arrive. Il finit par taper en aveugle, et choisit la mauvaise ligne.

Quatrièmement, vous donnez à un tiers la connaissance de qui consulte quoi. Selon votre contexte (B2B sensible, données RH, données santé), c’est une décision RGPD à documenter. Vous l’oublierez probablement au moment de la mise en production.

Cinquièmement, les APIs bougent. Une version qui change, un endpoint déprécié, un format de réponse modifié, et votre formulaire ne saisit plus rien. Vous l’apprenez par un ticket support à 9h08, un lundi matin, juste avant un comité de direction.

La bonne approche, seeder le référentiel en base

Pour un référentiel stable, qui change une fois par an au mieux, la bonne approche est de l’embarquer directement dans votre propre base de données. C’est ce qu’on appelle un seed : une donnée pré-chargée, versionnée avec votre code, indépendante d’un appel réseau.

La nomenclature française des activités, dite NAF, est l’exemple parfait. L’INSEE publie 732 sous-classes officielles dans la NAF révision 2, codifiées par 4 chiffres et 1 lettre, du “01.11Z” au “99.00Z” (source INSEE, NAF rév. 2). Cette nomenclature est en vigueur depuis le 1er janvier 2008, fixée par le décret n° 2007-1888 du 26 décembre 2007 (présentation INSEE). Elle est hiérarchique : 21 sections (A à U), 88 divisions, 272 groupes, 615 classes, 732 sous-classes.

À noter : une révision NAF rév. 3 entre en vigueur le 1er janvier 2027, approuvée par le décret n° 2025-736 du 31 juillet 2025 (Légifrance). C’est exactement le type d’évolution qui justifie une routine de mise à jour annuelle. Si vous embarquez aujourd’hui la rév. 2, vous aurez un seed à recharger début 2027. Document, planifié, six mois à l’avance, pas dans la panique.

Trois propriétés rendent ce référentiel idéal pour un seed local :

1. Il est officiel. Si l’utilisateur trouve un code via votre outil, c’est le même que celui de tout autre interlocuteur : banque, comptable, administration, partenaire B2B.
2. Il est exhaustif. 732 codes couvrent tous les cas. Pas besoin d’ajouter une case “Autre, à préciser” qui rouvre la porte au texte libre.
3. Il est stable. La dernière révision date de 2008. Vous ne mettez pas à jour la base tous les mois, ni même tous les ans.

C’est l’approche qu’on a prise pour Redof, notre plateforme de gestion d’événements et d’utilisateurs (redof.fr). Quand un utilisateur ajoute une entreprise dans Redof, le champ “code NAF” propose un autocomplete sur les 732 codes officiels, hiérarchisés. L’utilisateur tape “coiffure” ou “BTP”, la liste se filtre en temps réel, il valide. Aucun champ libre, aucune faute de frappe, aucun code obsolète qui traîne dans la base. Le libellé officiel est affiché partout où le code apparaît : fiche entreprise, rapports, exports.

Pourquoi avoir poussé jusqu’aux 732 codes et pas seulement aux 50 les plus courants ? Précisément pour éviter de retomber dans le piège initial. Dès qu’un utilisateur tombe sur un cas non couvert, il rouvre soit un champ libre, soit un ticket. Ni l’un ni l’autre n’est ce que vous voulez. L’exhaustivité du seed est ce qui vous évite de reproduire le problème que vous étiez en train de résoudre.

Seed ou API, la règle de décision

La question n’est pas “seed contre API” en absolu, mais “quelle donnée pour quel usage”. Voici comment trancher en réunion produit, sans discussion infinie.

La règle se résume en une phrase : référentiel stable = seed local, donnée vivante = API à la volée avec cache. Ne pas confondre les deux est la moitié du chemin.

Les pièges courants d’un seed mal fait

Seeder un référentiel n’est pas magique. Quatre erreurs détruisent le bénéfice attendu, et trois sont commises par défaut si personne n’a fait l’exercice.

Premier piège, seeder une sélection plutôt que le référentiel complet. Si vous ne mettez que les 50 codes NAF “les plus courants”, vos utilisateurs vont retomber sur le champ libre dès qu’ils manqueront un cas. Vous reproduisez le problème initial, en moins visible et avec moins d’excuses. Le seed doit être exhaustif. Toujours. Sinon, ce n’est pas un seed, c’est une suggestion.

Deuxième piège, oublier la mise à jour. Les référentiels officiels bougent, lentement, mais ils bougent. La nomenclature NAF a connu des révisions, les codes pays évoluent (Birmanie devenue Myanmar, code XK introduit pour le Kosovo). Prévoyez une routine annuelle de vérification, même 30 minutes par an. Documentez qui est responsable de cette routine, par écrit. Sans ça, dans 4 ans, vous travaillerez avec un référentiel obsolète sans le savoir.

Troisième piège, afficher le code et pas le libellé. Si votre interface montre “47.71Z” sans le rattacher à “Commerce de détail d’habillement en magasin spécialisé”, l’utilisateur ne sait pas ce qu’il choisit. Il sélectionne au hasard, et vos données redeviennent du bruit. Le code est pour la machine, le libellé est pour l’humain. Les deux doivent coexister à l’écran.

Quatrième piège, ne pas indexer la recherche en français normalisé. Sans normalisation (suppression des accents, conversion en minuscules), une recherche sur “boucherie” ne trouvera pas “Boucherie” et inversement. L’utilisateur conclut que “ce code n’existe pas” et invente une saisie alternative. Indexez sur la version normalisée, c’est cinq lignes de code et ça change tout.

Checklist, intégrer proprement un référentiel officiel

À copier-coller dans le ticket de votre prochain sprint, ou à transmettre tel quel à votre prestataire.

Choix de la source

• Choisir une source officielle. Si elle n’existe pas en open data, votre référentiel n’est pas un référentiel, c’est une liste maison qui se discutera à chaque réunion.
• Documenter l’URL source et la version (date, numéro de révision) dans le code, à côté du seeder. La personne qui reprendra le projet dans 3 ans vous dira merci.
• Seeder le référentiel complet, pas une sélection. L’exhaustivité est ce qui empêche le retour au champ libre.
• Versionner le seed dans Git, pas seulement la table en production. Une nouvelle instance doit pouvoir se reconstruire à l’identique.

Mise en oeuvre côté code

• Afficher le libellé officiel partout où le code apparaît : fiche, rapport, export, email automatique.
• Indexer la recherche en français normalisé (sans accent, en minuscules) pour que “Boulangerie” et “boulangerie” trouvent la même chose.
• Bannir le champ libre côté formulaire pour ce champ. Pas de “Autre, à préciser” qui rouvre la porte au texte non structuré.
• Ajouter un test automatisé : le picker doit répondre en moins de 200 ms côté client sur le 95e percentile.

Maintenance et gouvernance

• Prévoir une commande de réimport pour la mise à jour annuelle, idempotente, qui ne casse pas les données existantes.
• Documenter par écrit à qui revient la décision de mise à jour annuelle (PO, lead dev, ops). Sans propriétaire, la routine meurt à la première réorganisation.

Vous n’avez probablement pas conscience aujourd’hui de combien de champs texte libres dorment dans votre base de données. Ils sont la dette technique la plus invisible et la plus chère : invisible parce que rien ne casse, chère parce qu’elle vous prive de la capacité à piloter sur vos propres données. Et chaque mois qui passe, leur poids augmente.

Si vous avez un doute, faites un audit court ce trimestre. Listez vos 10 champs les plus saisis. Pour chacun, posez deux questions : “existe-t-il un référentiel officiel ?” et “à quoi sert cette donnée en aval ?”. Si la première réponse est oui et la seconde est “à filtrer / segmenter / exporter”, c’est probablement votre prochain chantier de hygiène de données.

Si vous voulez qu’on regarde votre cas, on propose des audits courts (90 minutes, à distance) sur la dette de données et les référentiels manquants : prenez contact via alpha-digital.fr/contact.