Centraliser ses données dans un seul outil

Centraliser ses données dans un seul outil désigne trois chantiers qui n’ont ni le même prix, ni la même durée, ni le même effet. Le premier fait saisir toutes vos équipes dans un même logiciel. Le deuxième garde vos logiciels en place et désigne, pour chaque donnée, celui qui fait foi, les autres la recevant automatiquement. Le troisième ne déplace rien et rassemble seulement la lecture sur un écran. Une entreprise qui a besoin du troisième et achète le premier change la façon de travailler de ses équipes sans rien gagner sur ses chiffres. Ce qui suit sépare les trois chantiers, trie vos données entre celles qui réclament un endroit unique et celles qui n’en réclament aucun, dit ce que chaque déplacement coûte en migration, en plafonds d’appels et en gestion des accès, et finit sur la liste à écrire avant de choisir.

Un seul outil peut désigner trois chantiers différents

Les trois répondent à la même gêne, des données éparpillées entre des logiciels qui ne communiquent pas, ce qu’on appelle des silos de données. Ils interviennent à trois endroits différents de la chaîne : la saisie, l’origine de chaque donnée, l’affichage.

Tout saisir dans le même logiciel

Un logiciel de gestion complet, souvent appelé ERP, ramène la saisie dans une seule interface. Les devis, les commandes, les stocks et la facturation vivent dans le même produit. Ce qui se retapait d’un logiciel à l’autre, la ressaisie, se tape une fois dans le module concerné.

Ce chantier déplace surtout des habitudes de travail. Chaque service abandonne l’outil qu’il connaît pour un module qui fait la même chose autrement, avec d’autres champs à remplir et moins de souplesse sur les cas particuliers. Le coût de la bascule se lit moins dans le prix des licences que dans la période où vos équipes avancent au ralenti, le temps d’apprendre les écrans qui remplacent les leurs.

Cette réponse est la plus simple des trois tant que vos façons de travailler entrent dans le produit tel qu’il est livré. Le jour où un service tient un tableur à côté pour ce que le logiciel ne calcule pas, la centralisation est déjà défaite, et la question devient celle de la limite du paramétrage. Elle est traitée sur la page qui regarde jusqu’où un produit d’éditeur se configure avant de bloquer.

L’outil pivot, celui qui porte le plus de données partagées

Le deuxième chantier ne demande à personne de changer d’écran. Vos logiciels restent, et vous désignez pour chaque donnée celui qui la crée. Un client se crée dans le CRM, un article dans l’ERP, un salarié dans le logiciel de paie. Les autres outils la reçoivent automatiquement et ne l’écrivent pas. C’est ce que désigne l’expression source unique de la donnée : un endroit unique par donnée plutôt qu’un endroit unique pour tout.

Le logiciel qui récolte le plus de ces désignations est votre outil pivot, celui qui porte les valeurs que le reste du parc consulte. Il se déduit de ces désignations, une fois qu’elles sont posées à plat. Le logiciel qui affiche le plus de fonctions n’est pas forcément celui qui crée le plus de données chez vous, et c’est la seconde question qui décide.

Le sens de la synchronisation, quel outil écrit et quels outils lisent, se règle ensuite champ par champ. Ce réglage a sa propre page, celle qui traite de ce qui s’écrit et de ce qui se lit d’un logiciel à l’autre. Ce qui se tranche avant, et qui ne se délègue pas, c’est la liste des données qui méritent une désignation.

Rassembler la lecture sans toucher à la saisie

Le troisième chantier ne touche ni la saisie ni le stockage. Vos données restent dans les logiciels qui les produisent, et un écran va les chercher pour les afficher ensemble. Un chiffre d’affaires sorti de la facturation s’affiche à côté d’un carnet de commandes sorti du CRM et d’une charge d’atelier sortie du logiciel de production.

Il se distingue des deux autres sur un point, rien n’y est irréversible. Aucune donnée n’a changé de propriétaire, aucun service n’a changé d’écran, et débrancher l’affichage laisse le parc dans l’état où il était. Le premier chantier se défait au prix d’une seconde migration, le deuxième au prix d’une renégociation entre services. En contrepartie, la ressaisie reste entière : cet écran lit ce que vos équipes tapent aujourd’hui, il ne leur retire aucune saisie.

Toutes vos données ne réclament pas le même endroit

Un seul critère trie vos lignes pour cette question, le nombre d’outils qui ont besoin de la même valeur pour travailler. Il sépare deux familles, et une seule des deux pose un problème d’endroit.

Les données de référence, celles que plusieurs outils partagent

Vos clients, vos articles, vos tarifs, vos salariés et vos sites sont des données de référence. Elles décrivent des objets stables, elles bougent peu, et plusieurs outils les consultent en même temps. Le CRM, la facturation, la logistique et le service après-vente parlent tous du même client.

Cette catégorie est la seule qui exige vraiment un endroit unique. Quand deux outils créent chacun leur fiche client, la même société existe deux fois sous deux orthographes, et les totaux calculés dessus ne se recoupent plus. Ce doublon se traite au moment où les deux bases se rejoignent, avec des critères de correspondance écrits à l’avance, sujet développé sur la page qui explique comment rapprocher les fiches d’un CRM et celles des logiciels voisins.

L’identifiant retenu comme point commun mérite une vérification avant tout le reste, celle de sa stabilité dans le temps. Le Siret en donne l’exemple. L’administration le décrit comme les neuf chiffres du Siren suivis de cinq chiffres propres à chaque établissement, et précise que le Siret change à chaque fois que l’adresse d’une entreprise ou de l’un de ses établissements change, la partie Siren restant identique. Un client qui déménage sort donc de la correspondance établie sur son Siret et réapparaît sous une autre identité.

Les données d’activité, celles que produit le métier

Vos commandes, vos heures pointées, vos tickets, vos interventions et vos écritures comptables sont des données d’activité. Elles racontent ce qui s’est produit à une date, elles arrivent en continu, et elles naissent dans l’outil qui porte le métier concerné.

Tant que cet outil existe, elles n’ont pas de raison d’en changer. Un ticket de support vit dans l’outil de support, avec ses statuts, ses relances et son fil de messages. Ce qui intéresse la direction, c’est le nombre de tickets ouverts par semaine et le délai moyen de résolution, deux totaux qu’un écran calcule sans déplacer une seule ligne.

Une donnée d’activité échappe à ce classement, celle qui n’existe que dans un classeur, sans logiciel propriétaire : un suivi de litiges, un relevé d’heures, un carnet de sous-traitance. Elle n’a pas d’endroit d’origine à désigner, il faut lui en créer un, et c’est un chantier de collecte avant d’être un chantier de centralisation. L’ordre dans lequel remplacer un tel classeur se traite ailleurs, sur la page du passage d’un classeur de suivi à un outil qui prend sa suite.

Trois coûts qui ne figurent pas dans la demande de départ

Chacun des trois chantiers se paie ailleurs que sur la facture d’achat. Le déplacement d’une donnée se paie en migration, la liaison entre deux logiciels se paie en limites d’appels, et le rassemblement dans un seul stock se paie en gestion des accès et des durées de conservation.

Un champ sans équivalent dans l’outil d’arrivée

Faire passer une donnée d’un outil à un autre demande une migration des données : lire l’ancien format, le transformer, le charger, vérifier que les totaux se retrouvent des deux côtés. Le coût est dans la traduction plus que dans la copie. Les champs qui n’ont pas d’équivalent dans le nouvel outil se perdent, ou atterrissent dans une zone de texte libre où personne n’ira les chercher.

Cette distance entre les deux modèles commande aussi la reprise de l’historique. Reprendre trois ans de commandes coûte plus que reprendre les commandes en cours, et l’écart entre les deux grandit à mesure que les deux modèles s’éloignent. Sur des structures voisines, la profondeur reprise change peu de choses. Sur des structures éloignées, chaque année reprise se retraduit en entier.

Une autre réponse consiste à reprendre l’année en cours et à garder l’ancien outil en lecture seule pour le reste. Elle suppose d’écrire la date à laquelle cet outil cesse de faire foi, et cette date se décide au même titre que le propriétaire d’une donnée, avec les mêmes personnes autour de la table.

Une synchronisation travaille sous plafond

Une liaison entre deux logiciels s’appuie sur une API, l’interface par laquelle un logiciel met ses données à disposition d’un autre. Ces interfaces comptent les appels reçus et les limitent. HubSpot documente ainsi, pour les applications privées installées sur un compte, un plafond de 100 requêtes par tranche de 10 secondes et par application, et de 250 000 requêtes par jour et par compte, au palier gratuit ou Starter, avec une erreur 429 renvoyée aux appels qui dépassent la limite.

Ces plafonds se remarquent peu au fil de l’eau, quand la liaison ne transporte que les fiches modifiées depuis son dernier passage. Ils se rencontrent au premier chargement, celui qui reprend toute la base, et lors des rattrapages qui suivent une coupure. Trois choses se décident à ce moment, le périmètre repris d’un seul coup, la fréquence des passages suivants, et le comportement de la liaison quand un appel se fait refuser.

Un stock unique concentre les accès et mélange les durées

Rassembler des données personnelles dans un seul outil change la façon dont les accès se gèrent. La CNIL recommande de définir des profils d’habilitation en séparant les tâches et les domaines de responsabilité, et de limiter l’accès des utilisateurs aux seules données strictement nécessaires à l’accomplissement de leurs missions. Elle recommande aussi une revue a minima annuelle de ces habilitations, pour identifier et supprimer les comptes non utilisés. Sur trois logiciels distincts, cette séparation existait par construction, puisqu’un commercial n’avait pas de compte dans le logiciel de paie. Dans un outil unique, elle se paramètre et elle s’entretient.

Les durées de conservation posent une question voisine. La CNIL rappelle que les données personnelles ne peuvent pas être conservées indéfiniment et qu’une durée doit être déterminée par le responsable de traitement selon l’objectif ayant conduit à la collecte, avec une conservation en base active, puis un archivage intermédiaire lorsque les données ne servent plus cet objectif mais gardent une utilité administrative ou légale. Un prospect jamais converti, un salarié parti et un client encore sous garantie ne relèvent pas de la même durée. Les réunir dans le même outil ne les aligne pas, cela oblige à tenir trois durées différentes à l’intérieur du même logiciel.

Cette concentration pose une troisième question, distincte de celle des habilitations : celle de l’exposition en cas d’incident. Sur trois logiciels séparés, un accès compromis ne donne accès qu’aux données de celui-là. Dans un stock unique, le même accès compromis donne accès aux données personnelles et professionnelles réunies, ce qui change l’ampleur d’une fuite ou d’un piratage sans changer la façon dont les habilitations sont accordées au départ.

Deux colonnes suffisent à trancher

La décision se prend sur une liste à deux colonnes, écrite avant toute démonstration commerciale. La première recense les données présentes dans au moins deux de vos outils. Elle est bien plus courte que votre parc, et c’est la seule qui pose un problème de centralisation. Une donnée qu’un seul logiciel utilise ne regarde personne d’autre, quelle que soit son importance pour le service qui la tient.

La seconde colonne nomme, pour chacune de ces données, l’outil où elle naît aujourd’hui. Cette désignation est une décision d’organisation avant d’être un réglage technique, parce qu’elle dit quel service répond de la valeur juste. Quand deux services revendiquent la création de la même donnée, la ligne reste vide et l’arbitrage remonte à la direction, qui tranche sur l’organisation avant que quiconque ouvre un écran de configuration.

Lue ligne à ligne, cette liste dit ce qui attend chaque donnée. Celles dont la seconde colonne est remplie et stable demandent une liaison vers les outils qui les consultent. Celles dont la ligne est vide demandent l’arbitrage avant tout développement. Celles qui ne sont pas dans la liste, parce qu’un seul logiciel les utilise, sortent du projet.

Cette même liste tranche aussi pour le premier chantier, celui de l’ERP unique. Quand la seconde colonne fait apparaître qu’une poignée de logiciels portent déjà presque toutes les données de référence et d’activité du parc, ajouter une liaison de plus coûte souvent plus cher qu’un logiciel unique qui les tiendrait toutes sous le même toit. Quand elle reste courte au regard du nombre d’outils utilisés, la liaison au cas par cas suffit, et regrouper la saisie dans un ERP ne réglerait rien que cette liste n’a pas déjà réglé.

L’ordre dans lequel nous construisons un écran de pilotage

Cette liste sépare deux besoins. Les données partagées entre plusieurs logiciels demandent des liaisons, avec un sens d’écriture décidé donnée par donnée. Les données d’activité demandent seulement d’être lues et additionnées.

C’est ce second besoin que couvre un écran de pilotage. Il se branche sur vos outils tels qu’ils sont, applique vos règles de calcul et affiche les totaux les uns à côté des autres, sans qu’aucune équipe change sa façon de saisir. Nos écrans qui vont chercher les chiffres dans vos logiciels actuels se construisent dans cet ordre : ce qui reste chez son propriétaire, ce qui circule d’un outil à l’autre, et seulement ensuite ce qui s’affiche.

Le point de départ que nous demandons est donc cette liste à deux colonnes, remplie avec les noms de vos logiciels. Elle nous dit quelles liaisons construire, quels totaux calculer, et sur quelles lignes il n’y a rien à faire. Ce point de départ ne change pas avec la taille du parc : une liste de trois logiciels ou de quinze se remplit et se lit de la même façon, ligne après ligne.

Sources

Comment obtenir un numéro Siren ou un Siret ?, Entreprendre.Service-Public.fr, vérifié le 30 janvier 2025, https://entreprendre.service-public.gouv.fr/vosdroits/F32135

Sécurité : gérer les habilitations, CNIL, 13 mars 2024, https://www.cnil.fr/fr/securite-gerer-les-habilitations

Les durées de conservation des données, CNIL, mise à jour du 2 avril 2026, https://www.cnil.fr/fr/passer-laction/les-durees-de-conservation-des-donnees

API usage guidelines and limits, HubSpot Developer Documentation, consulté le 8 septembre 2026, https://developers.hubspot.com/docs/developer-tooling/platform/usage-guidelines