Source de vérité unique : pourquoi vos logiciels ne se parlent pas
Par François-Guillaume Ribreau, cofondateur de NoBullshit Conseil. Publié le 5 octobre 2026.
Dans beaucoup de PME, chaque service a son logiciel, et ces logiciels se parlent mal. On recopie une adresse d'un outil à l'autre, on exporte un tableur le matin, on corrige à la main l'après-midi.
La plainte qui revient est toujours la même : la donnée n'est pas fiable. Avant de jeter les outils, il vaut la peine de comprendre pourquoi, car la cause est rarement celle qu'on croit.
« Nos données se désynchronisent entre logiciels, plus d'une fois sur deux. On a déjà essayé de les relier, ça n'a pas tenu. »
Quand chaque service vit dans son silo
Un silo, c'est un logiciel qui détient ses propres données et les garde pour lui. La gestion commerciale a les siennes, l'outil de production les siennes, et plusieurs petits outils annexes gravitent autour, parfois sans même se connaître.
Tant que chacun travaille seul, tout va bien. Les ennuis commencent quand une même information, un client, un produit, une commande, doit exister dans plusieurs outils à la fois. Faute de canal commun, on la recopie, et chaque copie prend le risque de diverger de l'originale.
Pourquoi la donnée semble non fiable
Il ne faut pas jeter le bébé avec l'eau du bain. Dans la plupart des cas, la donnée n'est pas fausse en elle-même, elle arrive au mauvais moment.
Les logiciels s'échangent souvent des fichiers à heures fixes, la nuit ou en début de journée. Une information modifiée juste après l'export part en retard, et deux routines programmées dans le mauvais ordre finissent par s'écraser l'une l'autre. Le problème vient rarement de la donnée elle-même, il vient du cadencement qui la transporte. Un diagnostic de ces routines révèle presque toujours la vraie cause.
Du fichier échangé à l'interface en temps réel
La réponse durable consiste à remplacer l'échange de fichiers par une interface, une API, qui laisse les logiciels se demander la donnée au moment où ils en ont besoin. L'information circule alors à jour, sans attendre le prochain export.
Désigner une source de vérité unique
Une interface ne suffit pas si deux outils prétendent chacun détenir la vérité sur le même client. Il faut donc désigner, pour chaque donnée importante, un logiciel propriétaire, celui qui fait foi.
Les autres s'y réfèrent. Quand l'information change, elle change à un seul endroit et se propage partout. Les versions contradictoires disparaissent, et la question « laquelle des deux fiches est la bonne » cesse de se poser.
Urbaniser le SI sans tout refondre
Mettre de l'ordre dans ces échanges porte un nom, l'urbanisation du système d'information. L'idée est d'organiser le SI comme un plan de ville : on décide qui détient quelle donnée et par quelles voies les outils communiquent, puis on raccorde les bâtiments un à un.
Chaque raccordement remplace un échange de fichier par une interface fiable, sans arrêter l'existant. On avance quartier par quartier, exactement comme pour sortir d'un logiciel propriétaire sans Big Bang, et chaque voie ouverte se repère d'abord sur la carte de l'existant.
La loi de Conway, et comment la retourner
Une observation ancienne du génie logiciel, la loi de Conway, dit qu'un système finit par ressembler à l'organisation qui l'a construit. Des services qui ne se parlent pas produisent des logiciels qui ne se parlent pas.
La retourner consiste à partir de l'architecture souhaitée pour en déduire la façon dont les équipes doivent se coordonner. Si l'on veut une donnée partagée, on fait travailler ensemble ceux qui la produisent et ceux qui la consomment, et le système suit. L'outil n'est jamais le premier chantier, l'organisation l'est.
Vos logiciels se contredisent et vous perdez du temps à réconcilier ?
Mettre de l'ordre dans vos données