Un tableau de commandes commence souvent avec une ligne par client et quelques colonnes produit. Puis arrivent une commande à plusieurs articles, une remise particulière et un changement de prix. Le tableau devient difficile à corriger sans casser ses totaux. Dans Airtable, la solution consiste généralement à représenter séparément les objets du métier et leurs relations. Le point essentiel est de distinguer le produit du catalogue de la ligne qui décrit ce produit dans une commande donnée.
Repérer ce qui se répète pour de bonnes raisons
Un client peut passer plusieurs commandes, et une commande peut contenir plusieurs produits. Recopier les coordonnées du client sur chaque ligne crée une maintenance répétitive. En revanche, conserver le prix convenu au moment d’une commande répond à un besoin historique. Toute répétition n’est donc pas une erreur : il faut distinguer une information de référence d’une information qui décrit un engagement à une date précise.
Prenons un exemple fictif de vente de fournitures pour ateliers. Une entreprise achète deux boîtes de gants et un lot de lunettes. Le client est une entité, la commande en est une autre, et chaque quantité achetée forme une ligne de commande. Le catalogue décrit les produits proposés aujourd’hui. Cette distinction permet ensuite de répondre séparément à « quel est le prix actuel ? » et « quel prix a été accepté sur cette commande ? ».
Créer une table intermédiaire pour les lignes
Une structure de départ peut comporter quatre tables : clients, commandes, produits et lignes de commande. Chaque ligne est reliée à une commande et à un produit, avec une quantité et un prix convenu. Airtable documente les champs de relation entre enregistrements, qui permettent de représenter ces liens au lieu de les simuler avec du texte recopié.
Choisissez des identifiants stables pour retrouver les objets indépendamment de leur libellé. Un nom commercial peut changer ; une référence de commande doit rester exploitable. Évitez de dépendre uniquement de la position d’une ligne dans une vue, car un tri peut la déplacer. Définissez aussi les informations obligatoires à la création, puis celles qui seront complétées avant validation ou expédition.
Distinguer consultation et copie historique
Un champ de recherche, ou lookup, affiche une donnée d’un enregistrement relié. La documentation Airtable précise qu’il repose sur une relation existante et sur des liens effectifs entre les enregistrements. Il convient par exemple pour montrer une catégorie actuelle du produit. Il ne remplace pas automatiquement une valeur historique figée au moment où une commande est confirmée.
Si le prix de la ligne dépend toujours du prix actuel du catalogue, modifier le catalogue peut modifier la lecture d’une ancienne commande. Pour éviter cette ambiguïté, définissez un champ de prix convenu et une règle de remplissage au bon moment. Indiquez clairement qui peut le corriger après validation. La base doit pouvoir expliquer l’historique commercial sans demander de reconstituer les anciens tarifs à partir de souvenirs.
Un changement de prix comme test du modèle
Créez une commande de test puis modifiez le tarif du produit de référence. La commande déjà validée doit garder la valeur prévue par votre règle métier. Une nouvelle commande doit utiliser le tarif approprié à sa date. Si ces deux comportements ne sont pas distincts, le modèle mélange probablement consultation du catalogue et conservation d’un engagement. Corrigez cette confusion avant de connecter la base à d’autres outils.
Construire des totaux dont le sens est explicite
La quantité multipliée par le prix unitaire donne une première valeur de ligne, mais les remises, frais ou taxes demandent des règles supplémentaires. Définissez les unités, les arrondis et le moment où chaque calcul s’applique. Ne laissez pas un champ intitulé simplement « total » couvrir plusieurs notions. Des noms comme « montant des lignes » ou « frais ajoutés » rendent les écarts plus faciles à comprendre.
Les agrégations Airtable résument des champs provenant d’enregistrements liés. Vérifiez que la relation utilisée correspond bien au périmètre souhaité. Une ligne oubliée dans la relation peut manquer au total tout en restant présente dans sa table. Créez une vue de contrôle des lignes sans commande, sans produit ou avec une quantité incohérente pour repérer ces anomalies.
Préparer des interfaces qui limitent les erreurs
L’utilisateur qui prépare une commande n’a pas besoin de modifier toute la structure. Présentez-lui les champs nécessaires dans un ordre adapté : client, articles, quantités, contrôle et validation. Rendez visibles les informations manquantes avant la confirmation. Une base bien modélisée mais exposée sous forme de grande grille brute peut rester difficile à utiliser pour une personne qui intervient occasionnellement.
Définissez les permissions en fonction des tâches. Modifier un prix de catalogue, corriger une adresse et valider une commande sont des actions différentes. Vérifiez avec des comptes représentatifs ce que chaque rôle peut réellement lire et changer, selon les fonctions disponibles dans votre offre. Une vue masquant des colonnes ne doit pas être interprétée comme une garantie d’absence d’accès aux données sous-jacentes.
Migrer les anciens tableaux par étapes
Conservez une copie intacte des fichiers d’origine et ajoutez une référence de ligne permettant de revenir à la source. Nettoyez d’abord les clients et produits, puis créez les commandes et leurs lignes. Les rapprochements ambigus doivent rejoindre une liste à vérifier. Fusionner automatiquement deux entreprises parce que leurs noms se ressemblent peut déplacer l’historique d’un client vers un autre.
Comparez les nombres d’enregistrements et les montants selon un périmètre défini. Expliquez les différences liées aux doublons corrigés ou aux lignes rejetées. Testez ensuite une modification réelle : changement d’adresse, nouvelle commande, annulation et correction d’une quantité. Le succès de l’import ne prouve pas que le fonctionnement quotidien est correct. La migration est terminée lorsque l’équipe sait poursuivre son travail dans la nouvelle structure.
Définir la frontière avec les autres logiciels
Testez enfin la suppression d’un produit utilisé dans une ancienne commande. Selon votre organisation, il peut être préférable de l’archiver et de le retirer des sélections nouvelles tout en conservant son historique. Définissez cette règle avant de donner des droits de suppression. La même question se pose pour un client inactif ou une commande annulée dont les lignes servent encore au suivi.
Airtable peut servir de suivi opérationnel sans devenir la source unique de tous les chiffres de l’entreprise. Décidez quelles données sont confirmées dans la boutique, le logiciel de gestion ou l’outil de facturation. Documentez le sens des synchronisations et la règle en cas de conflit. Deux applications autorisées à corriger la même valeur peuvent se renvoyer des modifications contradictoires.
Notre expertise Airtable aide à structurer les bases et les interfaces autour de vos opérations. Pour étudier votre modèle, préparez quelques lignes anonymisées et trois questions auxquelles votre tableau répond mal. Elles permettront de dessiner des relations utiles et de construire une recette fondée sur votre travail réel.
Pour approfondir : Shopify : réussir un import CSV sans abîmer ses variantes.
Pour approfondir : Stocks en boutique et en ligne : comment éviter la double vente ?.
