Modéliser correctement quand on n'est pas développeur

La normalisation des données s'enseigne en SQL, avec un vocabulaire qui décourage. Notre thèse : elle se pratique très bien dans une base no-code, et trois gestes couvrent l'essentiel des cas — une table par entité, des liens plutôt que des copies, des champs atomiques. Si vous savez créer un champ dans Airtable, vous savez normaliser.

L'idée n'est pas nouvelle. En 1970, dès la première phrase de son papier, E. F. Codd fonde le modèle relationnel sur une promesse : les futurs utilisateurs doivent être

« protected from having to know how the data is organized in the machine » — E. F. Codd, CACM, 1970

Séparer le sens des données de leur mécanique : c'est ce qu'une base no-code fait 55 ans plus tard. La théorie n'a pas changé ; l'outil est devenu accessible.

Pourquoi le schéma est le vrai livrable, nous l'avons montré dans modéliser avant d'outiller ; cet article est son compagnon appliqué — uniquement le comment. « Des tableurs utilisés comme base de données » figure parmi les sept points de départ réels de nos projets (données internes Ownward, 2026) : voici ce que nous corrigeons en premier.

La documentation Microsoft sur la conception de bases — la référence grand public, écrite sans une ligne de SQL — tient en deux principes : diviser l'information en tables par sujet, et enregistrer chaque fait une seule fois. La donnée dupliquée, écrit Microsoft, gaspille de l'espace et augmente la probabilité d'erreurs et d'incohérences.

Le geste : une table par entité — clients, commandes, produits. Le test : si vous tapez le même nom de client dans deux tables, il vous manque une table.

Chaque fait vit chez son propriétaire ; le reste se déduit par des liens et des champs calculés, jamais par de la re-saisie.

En 1983, William Kent résume les deuxième et troisième formes normales en une phrase canonique : un champ énonce un fait sur « la clé, toute la clé, rien que la clé ». En langage métier : chaque colonne décrit l'entité de sa table. L'email du commercial n'a rien à faire dans la table Commandes — il décrit le commercial.

Dans Airtable, ce principe s'appelle le champ linked record : une relation bidirectionnelle, reflétée automatiquement dans la table liée. C'est la clé étrangère du monde SQL, sans le mot ni la syntaxe : on lie, on ne recopie pas.

Le lien débloque deux champs calculés qui suppriment la re-saisie :

• le lookup affiche une valeur de l'enregistrement lié sans la recopier — la valeur reste chez son propriétaire ;
• le rollup agrège les enregistrements liés — somme, moyenne, comptage, parmi 19 fonctions, sur tous les plans. Le total d'une commande se calcule seul depuis ses lignes.

La documentation Airtable le formule sans détour : lier minimise la saisie redondante et garantit que l'information la plus récente est disponible partout. Kent, lui, rappelait que la normalisation existe pour prévenir les anomalies de mise à jour et les incohérences — pas un exercice académique, une assurance.

Ce que ça coûte de ne rien faire — Chaque valeur recopiée est une incohérence en attente : la recherche de référence sur le risque tableur (EuSpRIG, 2000 — historique) trouvait des erreurs dans au moins 86 % des tableurs audités à partir de 1997. La duplication se paie aussi en quota : 1 000 enregistrements par base en Free, 50 000 en Team (20 $/siège/mois), 125 000 en Business (45 $/siège/mois), constatés le 12 août 2026. Copier, c'est consommer deux fois son plafond.

Première forme normale, version académique : à chaque intersection ligne/colonne, une seule valeur, jamais une liste. Version Microsoft, sans jargon : découpez chaque information en ses plus petites parties utiles — ce sur quoi vous voulez trier, filtrer ou calculer mérite son propre champ.

Le geste Airtable, c'est le typage : une trentaine de types de champs — single select, email, téléphone, devise, date, durée. Un statut en texte libre produira « en cours », « En Cours » et « encours » ; un single select n'autorise qu'une option, dans une liste maîtrisée. Une adresse en un seul bloc interdit de filtrer par ville ; quatre champs l'autorisent.

La règle de poche : un champ = une information, du bon type. Une virgule qui sépare deux choses dans une cellule, c'est deux champs — ou deux enregistrements liés.

Reste le cas qui bloque la plupart des bases auto-construites : la relation plusieurs-à-plusieurs. Un livre a plusieurs auteurs, un auteur écrit plusieurs livres — la documentation Airtable décrit ces trois types de relations, exemples à l'appui.

Le piège : quand la relation elle-même porte de l'information. Une commande contient plusieurs produits, chacun avec sa quantité — où l'écrire ? Ni dans la commande, ni dans le produit : elle décrit le couple. Airtable recommande alors une table de jonction : une table « Lignes de commande » dont chaque enregistrement lie une commande et un produit, et porte la quantité.

La normalisation, traduite en gestes Airtable, tient en trois lignes :

Ce principe passe à l'échelle : notre moteur de synchronisation relie 6 CRM/ERP à un référentiel unique, piloté par un mapping stocké dans Airtable — zéro re-saisie, une nouvelle source = un nouveau mapping, pas de code (données internes Ownward, 2026). C'est le cœur de notre façon de construire : la structure d'abord — le « structure-first » —, l'outil ensuite.

Passez votre base au crible : chaque signe a son geste correctif, aucun ne demande de code.

Un signe coché : la correction est rapide et locale. Cinq ou plus : repartez du modèle avant d'ajouter le moindre champ.

Trois gestes couvrent l'essentiel des cas, pas tous. Une base no-code n'impose pas l'intégrité référentielle d'un moteur de base de données classique : pas d'unicité imposée sur le champ principal, pas de garde-fou à la suppression d'un enregistrement lié. La rigueur reste une discipline d'équipe — un sujet de gouvernance plus que d'outillage. Au-delà des volumes du plan, ou dès qu'il faut une isolation forte entre clients, le pattern à retenir est la migration vers une base relationnelle managée — un chemin fait sur 8 de nos applications de production (données internes Ownward, 2026). Enfin, la modélisation n'est jamais finie : une entité nouvelle dans le métier, c'est une table nouvelle dans la base.