Le schéma est le livrable : modéliser avant d'outiller

La thèse tient en une phrase : le modèle de données précède l'outil et lui survit. Quand une PME change de CRM, de logiciel de facturation ou de base no-code, un schéma bien pensé — clients, produits, commandes, et leurs relations — se transporte. L'inverse est faux : personne ne reconstruit un modèle propre à partir d'un export confus.

L'histoire de l'informatique le prouve. En juin 1970, E. F. Codd (IBM Research) publie « A Relational Model of Data for Large Shared Data Banks » : décrire les données par leur structure naturelle, indépendamment de la machine et des programmes qui les exploitent. Cinquante-six ans plus tard, plus aucun outil de 1970 n'est en service ; le modèle relationnel, lui, reste le socle de la norme SQL, dont l'ISO a publié la dernière édition (ISO/IEC 9075) en juin 2023.

Le modèle relationnel de 1970 se lit toujours ; aucun logiciel de la même année n'a survécu. L'actif à longue durée de vie, c'est la structure ; l'outil, un consommable qu'on finit toujours par remplacer.

Nous appelons cette démarche structure-first : structurer ses données — entités, relations, référentiels — avant de comparer les outils. Le schéma est le premier livrable du projet, pas un sous-produit du paramétrage. Cette logique irrigue notre façon de construire.

Pas besoin d'être développeur pour modéliser. La documentation Microsoft résume la normalisation en dix mots — « Normalization is the process of organizing data in a database » — avec deux objectifs : éliminer les redondances et rendre la base plus flexible. William Kent avait vulgarisé les « formes normales » dès 1983 dans les Communications of the ACM, sans formalisme mathématique.

Les trois premières formes suffisent à un modèle de données PME. En langage courant :

L'exemple canonique vient de la même documentation Microsoft : si l'adresse d'un client existe dans la table Clients, mais aussi dans Commandes, Livraisons et Factures, chaque copie est une divergence en attente. Le client déménage, et trois tables sur quatre mentent.

La règle pratique : une information vit à un seul endroit ; partout ailleurs, on la référence. C'est l'essentiel de la normalisation pour non-développeurs — le reste est du raffinement.

Les chiffres publiés sont datés, mais convergents — et les dater vaut mieux que les recycler sans millésime. En 2020, une recherche Gartner estimait le coût moyen de la mauvaise qualité de données à 12,9 millions USD par an et par organisation. En 2017, une étude publiée dans la Harvard Business Review (Nagle, Redman, Sammon, 75 dirigeants auditant chacun 100 enregistrements récents) mesurait que 47 % des enregistrements nouvellement créés contenaient au moins une erreur critique ; seuls 3 % des lots atteignaient un seuil acceptable.

Son protocole, le « Friday Afternoon Measurement », se rejoue en interne : réunir l'équipe, sortir les 100 derniers enregistrements créés (contacts, commandes, tickets), surligner chaque erreur visible. Deux heures suffisent pour objectiver l'état de vos données — avant tout débat d'outils.

Le lien avec le schéma est direct. Un champ libre là où il fallait une liste de référence, une adresse recopiée dans quatre tables, deux fichiers « clients » tenus par deux services : autant d'erreurs que la structure aurait bloquées à la saisie. Chaque service les corrige ensuite dans son coin, refaisant sans le savoir la modélisation initiale.

Ce que ça coûte de ne rien faire — 12,9 millions USD par an et par organisation (Gartner, recherche 2020, ordre de grandeur daté) ; 47 % des nouveaux enregistrements erronés (HBR, 2017) ; 60 % des projets d'IA privés de données prêtes abandonnés d'ici fin 2026 (Gartner). Une PME n'a pas ces ordres de grandeur, mais chaque doublon se paie en heures de réconciliation.

L'empilement applicatif se mesure chaque année.

Le périmètre MuleSoft (1 050 responsables IT) couvre de grandes organisations ; les 101 applications d'Okta décrivent des structures plus proches des PME. La mécanique est la même : chaque application non modélisée ajoute un référentiel de plus à dédupliquer un jour.

Le pattern à retenir : ce n'est pas l'outil qui crée le silo, c'est l'absence de modèle partagé entre les outils. Deux applications alignées sur le même schéma — mêmes entités, mêmes identifiants — s'intègrent bien ; dix applications sans référentiel commun ne s'intègrent jamais vraiment.

L'IA rend le sujet urgent. Gartner prévoit que « organizations will abandon 60% of AI projects unsupported by AI-ready data » d'ici fin 2026 ; la même enquête (1 203 responsables data, juillet 2024) montre que 63 % des organisations n'ont pas — ou ne savent pas si elles ont — des pratiques de données adaptées à l'IA. Un schéma propre est le prérequis des cas d'usage IA proposés aux PME ; c'est le premier chantier de notre méthode.

La portabilité n'est pas un caprice, deux références l'attestent. D'abord la norme : ISO/IEC 25012 définit le modèle de qualité des données et y range la portabilité aux côtés de l'exactitude, de la complétude et de la cohérence. Des données de qualité sont, par définition normative, des données qui se transportent.

Ensuite le droit. Le règlement européen 2023/2854 (Data Act), applicable depuis le 12 septembre 2025, encadre le changement de fournisseur cloud ; son article 29 interdit les frais de migration entre services cloud à partir du 12 janvier 2027, comme le confirme le régulateur allemand Bundesnetzagentur. Sortir d'un outil devient un droit.

Mais exporter sans schéma, c'est déménager des cartons sans étiquettes : le droit garantit le camion, pas le plan. Un export n'a de valeur que si quelqu'un sait ce que signifie chaque colonne, quelle table référence quelle autre, et quel fichier fait foi. C'est ce que produit la démarche structure-first : un modèle documenté qui donne un sens aux exports et rend le changement d'outil réversible en pratique.

Avant tout comparatif, passez votre modèle — même dessiné sur une feuille — au crible de ces huit questions. Chaque « non » se reproduira dans n'importe quel outil. Pour un accompagnement sur ce diagnostic, voyez nos services.

Huit « oui » ne garantissent pas le bon outil ; ils garantissent que l'outil choisi héritera d'une structure saine — et que le suivant aussi.

La normalisation totale n'est pas toujours praticable — la littérature le reconnaît, de Kent (1983) à la documentation Microsoft. Trois formes normales suffisent à une PME ; viser la cinquième relève du zèle, et dénormaliser se justifie quand la simplicité d'usage l'exige. Pour tester une idée sur trente lignes de données, prototyper d'abord est raisonnable : le modèle s'apprend aussi en faisant. Le structure-first devient rentable dès qu'une donnée est partagée entre plusieurs personnes, plusieurs outils ou plusieurs années. En dessous de ce seuil, un tableur discipliné fait l'affaire — à condition de savoir qu'on contracte une dette de structure.