De Google Sheet à un schéma relationnel expliqué simplement : repérer les groupes répétés, choisir les clés, cartographier les relations et éviter les données désordonnées par la suite.
Une feuille de calcul est parfaite pour une petite liste. Vous pouvez changer des colonnes à la volée, ajouter des notes n'importe où et corriger les problèmes à l'œil. Cette liberté commence à se fissurer quand le fichier devient une source de vérité partagée.
Quand les données grandissent, les mêmes problèmes reviennent sans cesse. Vous voyez des doublons parce qu'il n'y a pas d'endroit unique pour stocker un client ou un produit. Vous obtenez des valeurs contradictoires parce que deux lignes ne sont pas d'accord sur la même chose, comme un numéro de téléphone. Filtrer et produire des rapports devient frustrant parce que certaines colonnes cachent des listes ("Tags", "Products", "Attendees") ou mélangent des formats ("$1,200", "1200", "1.2k").
Passer d'un Google Sheet à un schéma relationnel, c'est choisir la sécurité. Une base de données impose une structure plus claire pour que vous puissiez interroger, valider et mettre à jour les données sans créer de nouvelles contradictions.
Un modèle mental utile : une ligne doit représenter une chose réelle. Si une ligne représente une affaire, un client et une liste de produits, mettre à jour l'un d'eux plus tard sera pénible.
Un test rapide : une seule ligne a-t-elle parfois besoin de deux valeurs pour le même champ ?
Si la réponse est oui, ce n'est pas un problème de « ligne large ». C'est un problème de « table séparée ». Une fois modélisé proprement, vous pourrez construire des formulaires et des validations dessus au lieu de compter sur des modifications manuelles fragiles.
Une feuille de calcul peut sembler organisée et pourtant signifier des choses différentes pour différentes personnes. Avant de convertir un Google Sheet en schéma relationnel, mettez-vous d'accord sur ce que la feuille suit.
Commencez par les objectifs, pas par les colonnes. Quelles décisions les données doivent-elles soutenir : un rapport hebdomadaire de revenus, une liste de tickets en retard, un workflow qui assigne des suivis, ou une recherche rapide lors d'un appel client ? Si vous ne pouvez pas nommer une décision, ce champ n'a souvent pas sa place dans la base de données.
Ensuite, repérez les noms cachés dans les en-têtes et les notes. Ceux-ci deviennent généralement vos futures tables : customers, orders, products, invoices, tickets, agents, locations. Si une colonne mélange deux noms (comme « Customer + Company »), vous stockez plusieurs choses au même endroit.
De petites différences de sens deviennent de gros nettoyages plus tard. Clarifiez les bases :
Exemple : si votre feuille a une ligne par « Order » mais que la cellule « Products » contient une liste séparée par des virgules, décidez si cette ligne représente un paiement, un envoi ou une facture. Chaque choix conduit à un schéma différent.
Gelez une copie de la feuille d'origine en lecture seule. Vous l'utiliserez pour vérifier que les nouvelles tables répondent toujours aux mêmes questions.
Avant de convertir un Google Sheet en schéma relationnel, faites en sorte que la feuille ressemble à des données, pas à un rapport. Les bases de données ont besoin de lignes et de colonnes cohérentes. Les mises en page décoratives cachent des motifs que vous devez modéliser.
Supprimez les astuces de mise en page comme les cellules fusionnées, les en-têtes multiples et les sous-totaux dans la plage de données. Gardez une seule ligne d'en-tête puis des lignes d'enregistrements uniquement. Si vous avez besoin de totaux, placez-les sur un onglet récapitulatif séparé pour qu'ils ne se mélangent pas aux enregistrements réels.
Ensuite, homogénéisez les formats par colonne. Une base de données ne peut pas deviner que « 1/2/24 », « 2024-02-01 » et « Feb 1 » sont la même date. Il en va de même pour les numéros de téléphone, les devises et les noms. Choisissez un format et utilisez-le partout, même si cela semble strict.
Un court passage de nettoyage qui rapporte souvent :
Enfin, signalez toute cellule contenant plusieurs valeurs, comme "red, blue, green" dans une colonne. Ne corrigez pas encore le schéma. Marquez simplement ces colonnes pour vous souvenir qu'elles deviendront des lignes séparées plus tard.
Le plus grand signe d'alerte dans la modélisation de données de feuille de calcul est la répétition. Les feuilles compressent souvent « plus d'une chose » dans une seule ligne en répétant des colonnes ou en mettant plusieurs valeurs dans une cellule. Cela fonctionne pour un suivi rapide, puis casse quand vous avez besoin de filtrer, de faire des rapports ou d'assurer des mises à jour cohérentes.
Parcourez ces formes :
Item 1, Item 2, Item 3 ou Phone 1, Phone 2.Exemple : si votre suivi des ventes utilise Order ID, Customer, Product 1, Qty 1, Product 2, Qty 2, vous allez vite atteindre une limite. Certaines commandes ont 1 article, d'autres en ont 8. La feuille s'étend soit indéfiniment vers la droite, soit commence à perdre des données. Dans un modèle relationnel, « Orders » devient une table et « Order Items » devient une autre table avec une ligne par produit de la commande.
Pour les « listes dans une cellule », traitez chaque valeur comme son propre enregistrement. Une cellule qui indique "Email, SMS" signifie généralement que vous avez besoin d'une table séparée (ou d'une table de jointure) pour suivre correctement les canaux.
Les colonnes mixtes sont plus sournoises mais tout aussi risquées. Scindez-les tôt pour que chaque champ stocke un fait clair.
Une fois que vous pouvez nommer les choses du monde réel présentes dans la feuille, transformez chacune en sa propre table. Votre feuille de calcul cesse d'être une grande grille et devient un ensemble de listes plus petites et ciblées.
Si une ligne mélange des détails sur deux choses différentes, elle a probablement besoin de deux tables. Une ligne de suivi des ventes peut inclure des informations client (nom, téléphone), des informations de commande (date, statut) et des informations produit (SKU, prix). Les clients ne changent pas à chaque commande, et les produits ne dépendent pas d'une commande unique. Les séparer évite les modifications en double et les valeurs discordantes.
Avant de finaliser quoi que ce soit, écrivez une phrase d'objectif pour chaque table. Si vous ne pouvez pas décrire ce qu'une table représente sans dire « et aussi », elle est probablement trop vaste.
Quelques règles pratiques :
Nommez ensuite les colonnes clairement et de manière cohérente. Préférez des noms simples et évitez des libellés vagues comme "Info" ou "Details".
Choisissez une clé primaire pour chaque table tôt. Une bonne clé est ennuyeuse : elle ne change jamais, est toujours présente et identifie une seule ligne.
Les clés naturelles (valeurs du monde réel) peuvent fonctionner, mais seulement si elles sont vraiment stables. Un SKU est souvent une bonne clé naturelle parce qu'il est conçu pour être permanent. Les adresses e-mail semblent stables, mais les gens changent d'e-mail, partagent des boîtes et créent des doublons comme "john@" et "john.work@". Les noms, téléphones et adresses changent et ne sont pas garantis uniques.
Un bon choix par défaut est un ID auto-généré (comme customer_id, order_id). Gardez l'identifiant naturel comme champ normal et ajoutez une règle d'unicité quand cela correspond à vos règles métier. Si un e-mail change, le customer_id reste le même et les commandes associées pointent toujours vers le bon client.
Règles simples pour les clés :
Exemple : dans une table Contacts, utilisez contact_id comme clé primaire. Gardez email unique seulement si votre règle stipule qu'un contact = un e-mail. Autorisez phone à être vide car tout le monde ne le partage pas.
La plupart des erreurs proviennent de suppositions sur les relations. Utilisez une règle simple : si une ligne « possède » beaucoup de quelque chose, c'est un un-à-plusieurs. Placez la clé étrangère du côté « plusieurs ».
Exemple : un Customer peut avoir beaucoup d'Orders. La table Orders doit stocker customer_id. Si vous gardez une liste de numéros de commande séparée par des virgules dans Customers, les doublons et les données manquantes apparaissent vite.
Le plusieurs-à-plusieurs est le piège courant des feuilles. Si une Order peut inclure plusieurs Products et qu'un Product peut apparaître dans plusieurs Orders, vous avez besoin d'une table de jointure (souvent appelée line items). Elle contient typiquement order_id, product_id, plus des champs comme quantity et le prix au moment de l'achat.
Les relations un-à-un sont rares. Elles ont du sens quand les données supplémentaires sont optionnelles ou séparées pour la confidentialité ou la performance (par exemple, User et UserProfile). Elles deviennent un signal d'alerte quand vous scindez une table juste parce que la feuille avait deux onglets.
L'historique a sa propre structure. Si des valeurs peuvent changer dans le temps (statut, prix, adresse), évitez d'écraser une seule colonne. Stockez les changements comme des lignes dans une table d'historique pour pouvoir répondre à « qu'est-ce qui était vrai à cette date ? »
Une règle simple : stockez un fait en un seul endroit. Si le téléphone d'un client apparaît dans cinq lignes, quelqu'un mettra à jour quatre d'entre elles et en manquera une.
La normalisation en termes simples :
La première forme normale (1NF) signifie que chaque cellule contient une seule valeur. Si une colonne contient "red, blue, green" ou "SKU1|SKU2|SKU3", c'est une liste cachée. Transformez-la en lignes dans une table liée.
La deuxième forme normale (2NF) apparaît souvent dans les articles de commande. Si vous avez OrderItems et que la clé est (OrderID, ProductID), alors des champs comme CustomerName n'ont pas leur place là-dedans. Ils dépendent de la commande, pas du produit.
La troisième forme normale (3NF) signifie que les champs non-clés ne doivent pas dépendre d'autres champs non-clés. Exemple : si vous stockez ZipCode et City, et que City est déterminée par ZipCode, vous risquez des incohérences.
Un rapide contrôle personnel :
Dénormalisez surtout pour des lectures intensives et faites-le prudemment : traitez la table de rapport comme une copie que vous pouvez reconstruire. Gardez les tables normalisées comme source de vérité.
Pour des valeurs dérivées comme des totaux, des soldes et des statuts, ne les dupliquez pas à moins d'avoir une règle claire de recalcul. Une approche pratique : stockez les transactions brutes, calculez les totaux dans les requêtes et ne mettez en cache les totaux que lorsque la performance l'exige.
La plupart des problèmes « ça marchait dans la feuille » viennent du sens, pas des outils. L'objectif est que chaque ligne dise une chose claire, de la même façon, à chaque fois.
Pièges fréquents :
Si votre table Orders a des colonnes comme Item 1, Item 2, Item 3, vous avez un groupe répétitif. Prévoyez une table Orders et une table OrderItems.
Avant de verrouiller le schéma, faites une dernière passe pour la clarté. La plupart des douleurs en base de données viennent de petits raccourcis qui semblaient inoffensifs au départ.
Demandez-vous si chaque table répond à une question simple. "Customers" doit signifier clients, pas clients plus leur dernière commande plus des notes d'appel. Si vous ne pouvez pas décrire une table en une courte phrase, elle mélange probablement trop de choses.
Vérifications finales :
Test de réalité : imaginez que quelqu'un saisisse le même client deux fois avec une orthographe légèrement différente. Si votre schéma le rend facile, ajoutez une meilleure clé ou une règle d'unicité.
Imaginez une feuille de suivi des ventes où chaque ligne est une affaire. Elle contient des colonnes comme Customer Name, Customer Email, Deal Amount, Stage, Close Date, Products (liste séparée par des virgules) et Notes (parfois plusieurs notes dans une cellule).
Cette ligne unique cache deux groupes répétitifs : products (une affaire peut inclure plusieurs produits) et notes (une affaire peut avoir plusieurs notes). C'est là que les conversions échouent souvent, car les listes dans les cellules sont difficiles à interroger et faciles à contredire.
Un modèle « après » propre qui correspond au comportement réel :
CustomerId, DealId et ProductId sont des identifiants stables. DealProducts résout la relation plusieurs-à-plusieurs : une affaire peut inclure plusieurs produits et un produit peut apparaître dans plusieurs affaires. DealNotes sépare les notes pour éviter d'avoir "Note 1, Note 2, Note 3" en colonnes.
Avant la modélisation, un rapport comme "revenu par produit" nécessite de scinder des chaînes et d'espérer que les noms aient été tapés de façon cohérente. Après modélisation, c'est une simple requête sur DealProducts jointe à Deals et Products.
Une fois que votre schéma semble correct sur le papier, mettez-le dans une vraie base de données et testez avec des données réelles. N'importe pas tout d'un coup. Chargez d'abord un petit lot, corrigez ce qui casse, puis répétez.
Un ordre pratique qui limite les risques :
Ajoutez des règles de validation tôt pour que les mauvaises habitudes de feuille ne reviennent pas. Rendez les champs obligatoires réellement obligatoires, limitez les valeurs autorisées (comme le statut), validez les formats (dates et e-mails) et utilisez des clés étrangères pour éviter de créer une commande pour un client qui n'existe pas.
Puis cessez d'utiliser la feuille pour les mises à jour. Protéger vos données devient beaucoup plus simple quand les gens ont des formulaires simples et des workflows clairs.
Si vous souhaitez transformer le schéma en un outil interne sans écrire de code, AppMaster (appmaster.io) peut aider : vous modélisez les tables et les relations visuellement, puis générez un backend prêt pour la production, une application web et des apps mobiles natives à partir du même modèle.
Quand dois-je arrêter d'utiliser une Google Sheet et passer à un schéma relationnel ?Commencez lorsque la feuille sert de source de vérité partagée et que vous voyez des doublons, des valeurs contradictoires ou des rapports pénibles. Si vous vous battez avec des listes séparées par des virgules, des colonnes Item 1/Item 2 ou des copiers/collers constants, un schéma relationnel vous fera gagner du temps rapidement.
Comment savoir si quelque chose nécessite une table séparée ?Si une seule ligne doit contenir plusieurs valeurs pour le même champ, vous avez un groupe répétitif. Exemples : plusieurs produits sur une commande, plusieurs adresses pour un client, plusieurs participants à un événement. Ceux-ci doivent devenir des tables enfants (ou des tables de jointure), pas des colonnes supplémentaires ou des listes dans une cellule.
Quel nettoyage devrais-je faire avant de concevoir les tables ?Gelez une copie en lecture seule de la feuille d'origine, puis supprimez les cellules fusionnées, les lignes d'en-tête multiples et les lignes de sous-totaux de la plage de données. Harmonisez chaque colonne (un seul format de date, un seul format de devise, une façon uniforme de représenter les valeurs manquantes) pour voir la structure réelle avant de la modéliser.
Dois-je utiliser l'adresse e-mail/nom comme clé primaire, ou ajouter un ID ?Par défaut, utilisez un ID auto-généré pour chaque table car il reste stable quand les gens changent d'e-mail, de nom ou de téléphone. Conservez les identifiants du monde réel (comme l'e-mail ou le SKU) comme champs normaux et ajoutez une règle d'unicité seulement quand les doublons sont vraiment problématiques pour votre activité.
Comment modéliser les relations un-à-plusieurs vs plusieurs-à-plusieurs ?Cartographiez par propriété : si un client peut avoir plusieurs commandes, mettez customer_id dans la table Orders. Si c'est plusieurs-à-plusieurs (commandes et produits), ajoutez une table de jointure comme OrderItems avec order_id, product_id, ainsi que la quantité et le prix au moment de l'achat.
Que signifie vraiment « normaliser suffisamment » dans cette conversion ?Cela signifie empêcher les contradictions. Stocker un fait à un seul endroit vous permet de le mettre à jour une fois et de rester cohérent. Il n'est pas nécessaire d'atteindre une normalisation parfaite, mais éliminez les doublons comme le même numéro de téléphone client disséminé sur de nombreuses lignes.
Que faire des listes séparées par des virgules (tags, produits, participants) ?Séparez-les en lignes appropriées. Une cellule comme “Email, SMS” est difficile à filtrer et à valider, et elle casse les rapports. Créez une table liée (ou une table de jointure) où chaque valeur sélectionnée devient son propre enregistrement lié à la ligne parent.
Comment gérer les champs qui changent dans le temps, comme le statut ou le prix ?Séparez l'« état courant » de l'« historique ». Conservez un champ de statut actuel si vous en avez besoin, mais enregistrez les changements comme des lignes dans une table d'historique/événements avec des horodatages lorsque le moment est important. Cela vous permet de répondre à des questions comme « quel était le statut le mois dernier ? » sans deviner.
Quelle est la façon la plus sûre de migrer les données sans tout casser ?Importez d'abord un petit lot (environ 50–200 lignes), puis rapprochez les totaux et vérifiez aléatoirement les enregistrements par rapport à la feuille gelée. Corrigez les mappings, les IDs manquants et les doublons, puis réimportez. Chargez tout seulement quand le processus est répétable et prévisible.
Puis-je transformer le schéma en un outil interne sans écrire de code ?Un outil no-code peut aider quand vous voulez que le schéma devienne une application fonctionnelle avec formulaires, validations et workflows, pas seulement des tables. Avec AppMaster (appmaster.io), vous pouvez modéliser visuellement les tables et les relations, puis générer un backend prêt pour la production, une application web et des applications mobiles natives à partir du même modèle.
21 janv. 2026
8 min
20 janv. 20268 min
20 janv. 20268 minExpérimentez avec AppMaster avec un plan gratuit.
Lorsque vous serez prêt, vous pourrez choisir l'abonnement approprié.
