Excel ou base de données : comment choisir ?

Excel et une base ne résolvent pas exactement le même problème

Un tableur combine données, formules et présentation dans une interface souple. Il est rapide pour une analyse ponctuelle, une simulation, un budget ou un petit suivi dont une personne maîtrise le contexte.

Une base relationnelle sépare la donnée structurée de ses multiples usages. Elle devient intéressante lorsqu’un site, un rapport, une API et plusieurs employés doivent partager les mêmes clients, commandes ou stocks avec des règles communes.

Cinq questions plus utiles que « combien de lignes ? »

Le volume compte, mais la collaboration et le cycle de vie des faits révèlent souvent le besoin plus tôt.

• Combien de personnes ou systèmes écrivent dans la source ?
• Les clients, produits et opérations doivent-ils être reliés ?
• Une règle doit-elle être imposée quelle que soit l’application ?
• Deux modifications peuvent-elles arriver au même moment ?
• Faut-il limiter les accès, historiser ou reproduire un rapport ?

Quand le tableur est un très bon choix

Une personne explore un export mensuel de 2 000 lignes, ajoute quelques calculs, vérifie des hypothèses et produit un graphique. La source est figée, l’analyse courte et les formules visibles par son auteur : un tableur offre une excellente vitesse de travail.

Il convient aussi pour un prototype. Tester un dictionnaire de données et une première structure dans une feuille peut éviter de construire trop tôt une base mal comprise.

Quand la base devient le meilleur socle

Une boutique reçoit des commandes toute la journée. Le site réduit le stock, le magasin vend au comptoir, le service client change une adresse et la comptabilité confirme le paiement. Les faits sont reliés, modifiés en continu et utilisés par plusieurs processus.

Une base permet d’identifier chaque objet, d’empêcher certaines incohérences et d’appliquer une transaction lorsque plusieurs changements doivent réussir ensemble. Les rapports et tableurs peuvent ensuite lire cette source.

Le modèle hybride est souvent le plus réaliste

La base conserve les faits partagés et contrôlés. Une vue SQL prépare un périmètre stable. Excel ou Power BI se connecte à cette vue pour l’analyse et la présentation. Chaque outil reste dans son rôle.

Cette architecture évite de transformer le tableur en serveur improvisé tout en préservant sa souplesse pour les utilisateurs métier.

CREATE VIEW ventes_mensuelles AS
SELECT DATE_TRUNC('month', date_commande) AS mois,
       SUM(montant) AS chiffre_affaires
FROM commandes
WHERE statut = 'payee'
GROUP BY DATE_TRUNC('month', date_commande);

Erreurs fréquentes de décision

Une technologie ne compense pas une définition métier ambiguë. Le passage à une base doit préciser le grain, les identifiants, les règles et les responsabilités.

• Migrer uniquement parce qu’un fichier paraît gros, sans comprendre les usages.
• Conserver plusieurs exports manuels sans propriétaire ni date de référence.
• Construire une base sans dictionnaire ni règles, puis reproduire les mêmes incohérences.
• Donner un accès direct en écriture à tous les utilisateurs alors qu’une application contrôlée serait préférable.

Mini-diagnostic en une minute

Choisissez une source réelle. Si elle est modifiée par une seule personne, peu reliée, temporaire et facile à vérifier, le tableur peut rester approprié. Si plusieurs processus l’écrivent, si des relations doivent être valides et si une erreur affecte des opérations, étudiez une base.

La prochaine étape consiste à voir comment tables, clés et contraintes transforment ces besoins en structure.