Le même client apparaît sous trois noms. Son adresse se trouve dans un tableur, son dernier projet dans un courriel et son contact principal dans le téléphone d’un collègue. Un nouvel écran peut rendre tout cela plus joli. Il ne décide pas, à lui seul, quelles informations sont exactes ni comment les relier. Cette décision doit entrer dans le projet avant l’importation.
Dans la vidéo à l’origine de cet article, je compare une base de données à une bibliothèque organisée. L’image aide à comprendre, mais un logiciel d’entreprise demande davantage qu’un bon rangement. Structurer ses données consiste aussi à définir les relations, les règles de modification et les responsabilités. C’est ce travail qui permet de discuter du fonctionnement réel avant de multiplier les champs dans une interface.
Sommaire
Nommer les objets que l’entreprise manipule
Commencez par les mots employés au quotidien : client, contact, projet, intervention, produit. Demandez ce que chacun désigne exactement. Une entreprise cliente peut avoir plusieurs personnes de contact et plusieurs sites. Confondre ces éléments dans une seule ligne paraît simple au départ, puis oblige à dupliquer l’adresse de facturation chaque fois qu’un nouveau projet est ouvert.
Prenons un exemple fictif de suivi de projets. Un client représente l’organisation, un contact représente une personne et un projet représente un travail convenu. Le lien entre ces objets explique qui travaille pour qui et sur quoi. Cette séparation ne prescrit pas encore une technologie. Elle décrit le métier dans des termes que l’équipe peut vérifier avec de vrais exemples de dossiers.
Les exceptions sont utiles dès cette discussion. Une personne peut changer d’employeur, un client peut avoir deux adresses et un projet peut nécessiter plusieurs interlocuteurs. Évitez de répondre à chaque exception par un champ « autre » sans définition. Notez plutôt le cas, sa fréquence et les conséquences attendues. Le modèle doit être assez précis pour servir le travail, sans anticiper toutes les possibilités imaginables.
Identifier un dossier sans dépendre de son nom
Un nom est fait pour être lu ; il peut changer et être partagé par plusieurs personnes. Le système a besoin d’un identifiant stable pour reconnaître un dossier. Dans notre exemple, renommer une entreprise ne devrait pas détacher ses projets. De même, corriger une faute dans le nom d’un contact ne doit pas créer automatiquement une nouvelle personne sans lien avec son historique.
La présentation des concepts relationnels de PostgreSQL distingue tables, lignes et colonnes. Cette organisation peut aider à représenter les objets métier. Pour le porteur de projet, le point essentiel est de faire expliquer les liens : quel projet appartient à quel client, quels contacts peuvent lui être associés et ce qui se passe lorsqu’un élément devient inactif.
Préparez quelques questions concrètes avant de valider le modèle. Peut-on retrouver tous les projets d’un client sans chercher plusieurs variantes de son nom ? Peut-on changer le contact d’un projet sans modifier ceux des autres ? Peut-on comprendre pourquoi un dossier a été archivé ? Ces scénarios révèlent davantage qu’une liste impressionnante de champs ou qu’un schéma que personne dans l’équipe ne sait relire.
Donner un sens aux champs et aux statuts
Pour chaque information importante, précisez sa signification, son format et sa source. Une « date de fin » peut désigner une échéance prévue ou une réalisation effective : ce ne sont pas les mêmes données. Un montant peut être estimé, accepté ou facturé. Si ces distinctions restent implicites, un tableau de bord risque d’additionner des informations qui ne répondent pas à la même question.
Les statuts méritent la même attention. « En cours » signifie-t-il qu’une demande est reçue, que le travail a commencé ou qu’un responsable a été affecté ? Décrivez les passages autorisés et qui peut les effectuer. Dans un exemple de projet, une clôture peut demander une vérification préalable. La règle doit être discutée avec les personnes qui réalisent le travail, pas simplement déduite d’une couleur de badge.
Évitez de rendre tous les champs obligatoires pour obtenir des dossiers apparemment complets. Une personne bloquée peut saisir une valeur approximative pour avancer. Distinguez ce qui est nécessaire à la création de ce qui le devient plus tard. Un champ vide connu vaut parfois mieux qu’une information inventée, à condition que l’absence soit visible et que son traitement soit prévu.
Comparatif : trois supports pour organiser l’information
Le tableur pour explorer un besoin limité
Un tableur peut servir à inventorier les informations, préparer un import ou tester une organisation avec un petit groupe. Il est familier et facile à modifier. Sa limite apparaît lorsque plusieurs copies circulent, que les règles reposent sur la vigilance de chacun ou que les relations deviennent difficiles à maintenir. Utilisez-le pour rendre le besoin visible, en précisant qui tient la version de référence et comment les changements sont suivis.
Le modèle relationnel pour expliciter les liens
Une base relationnelle convient à de nombreux ensembles structurés : clients, projets, lignes de commande ou affectations. Elle permet d’exprimer des liens et des contraintes dans un modèle défini. Cela demande de réfléchir aux objets et aux règles avant de charger les données. Ce choix ne rend pas automatiquement les informations exactes ou les accès sûrs. La qualité des entrées, les autorisations et l’exploitation restent à concevoir et à vérifier.
Le modèle documentaire pour des ensembles variables
Une base documentaire peut être pertinente lorsque certains objets contiennent des structures variables que l’application traite comme un ensemble. Elle ne se résume pas à un tableur déguisé et ne dispense pas de règles. Il faut définir ce qui est attendu dans chaque document, comment rechercher les informations et comment gérer les liens nécessaires. La souplesse devient un coût si chaque équipe invente ses propres noms sans convention partagée.
Le choix dépend des usages et des contraintes techniques. Un projet peut combiner plusieurs supports, mais chaque copie supplémentaire demande une responsabilité claire. Avant de discuter du produit à installer, assurez-vous que les personnes concernées s’accordent sur les objets, leurs liens et les opérations à réaliser.
Préparer la reprise des données comme un travail à part entière
Un import ne se limite pas à déplacer des lignes. Rassemblez les fichiers disponibles, identifiez leur propriétaire et déterminez lequel fait référence pour chaque information. Conservez une copie des sources avant le nettoyage. Préparez ensuite une correspondance entre les anciennes colonnes et les nouveaux champs, en signalant les données ambiguës plutôt qu’en les transformant silencieusement.
Traitez les doublons avec prudence. Deux dossiers portant le même nom ne représentent pas forcément la même personne ou la même organisation. Définissez les critères de rapprochement et prévoyez une validation pour les cas incertains. Testez sur un échantillon représentatif qui contient des exceptions, puis comparez les dossiers obtenus aux sources. Un total de lignes correct ne prouve pas que les relations ont été conservées.
Décidez aussi ce qui ne sera pas importé. Des informations anciennes, inutiles ou sans origine claire peuvent compliquer la reprise. Les choix de conservation et d’accès doivent être examinés selon le contexte de l’entreprise, avec les personnes responsables. Le but n’est pas de tout accumuler, mais de disposer des données nécessaires, compréhensibles et utilisables pour les opérations prévues.
Organiser les modifications et la continuité
La création, la lecture, la modification et la suppression sont souvent résumées par CRUD. Derrière ce sigle se trouvent des décisions concrètes : qui peut corriger une adresse, consulter un dossier ou demander son retrait ? Définissez les permissions par rôle et vérifiez-les avec des comptes différents. Une interface qui cache un bouton ne constitue pas, seule, une règle d’accès suffisante.
Prévoyez ce que l’équipe doit pouvoir retrouver après une correction ou un incident : auteur d’un changement, valeur précédente lorsque c’est nécessaire, état d’un import, sauvegarde exploitable. Une sauvegarde doit pouvoir être restaurée et contrôlée ; sa simple présence dans un dossier ne démontre pas la reprise. Ces besoins influencent le travail du back-end de l’application.
Pour préparer un logiciel d’entreprise sur mesure, apportez quelques dossiers représentatifs, les fichiers utilisés et les questions auxquelles l’équipe cherche à répondre. Nous pourrons traduire ce vocabulaire métier en un modèle discuté et vérifiable. Les écrans auront alors une base claire : des informations définies, des relations utiles et des règles que les utilisateurs peuvent comprendre.
FAQ : organiser les données d’un logiciel métier
Faut-il choisir la base de données avant de définir les besoins ?
Il est préférable de clarifier d’abord les objets, les relations, les opérations et les contraintes du projet. Le choix technique peut ensuite être discuté avec l’équipe de développement. Un nom de technologie ne résout pas une ambiguïté entre deux notions métier ni une responsabilité de mise à jour mal définie.
Peut-on garder certains fichiers Excel ?
Oui, si leur rôle est clair : préparation d’import, analyse ponctuelle ou échange prévu. Le risque vient surtout des copies concurrentes que chacun considère comme exactes. Déterminez la source de référence et la manière de réintégrer les modifications avant de multiplier les échanges entre fichiers et logiciel.
Comment éviter de fusionner deux clients différents ?
Ne vous appuyez pas uniquement sur leur nom. Définissez plusieurs critères adaptés aux données disponibles et faites revoir les cas incertains. Conservez la possibilité de comprendre la décision de rapprochement. Une fusion automatique trop large peut créer des relations erronées plus difficiles à corriger qu’un doublon visible.
Une bonne structure suffit-elle à sécuriser les données ?
Non. Elle facilite la cohérence, mais la sécurité dépend aussi des autorisations, de la configuration, des mises à jour et des pratiques d’exploitation. Il faut examiner ces éléments ensemble et tester les comportements attendus. Aucun modèle de données ne remplace à lui seul ce travail de protection et de suivi.
Passer à l'action
Vous voulez le mettre en place chez vous ?
On peut vous aider à transformer ce sujet en système concret, utile et rentable pour votre entreprise.