OS d’entreprise : pourquoi les PME relient leurs outils, leurs données et leurs agents IA sur un seul socle
- Un OS d’entreprise est un ensemble d’outils métier sur mesure qui lisent et écrivent tous dans la même base de données, avec des agents IA qui agissent sur ces données
- Quand chaque SaaS garde sa propre base, les équipes ressaisissent les mêmes informations d’un outil à l’autre et l’entreprise paie une licence pour chacun
- Un agent IA donne des réponses fiables quand il lit des données reliées et à jour, sur lesquelles il a des droits définis
- Pour la comptabilité, la paie et la messagerie, l’entreprise garde des logiciels du marché, reliés à la base commune par leurs API
- Un OS d’entreprise se construit module par module, en commençant par celui qui supprime le plus de ressaisies
Un OS d’entreprise est un ensemble d’outils métier sur mesure (CRM, ERP, outils terrain, portail client) qui lisent et écrivent tous dans la même base de données, avec des agents IA qui travaillent directement sur ces données. Les PME et les ETI s’y mettent pour arrêter les ressaisies d’un SaaS à l’autre, rassembler leurs données éparpillées et réduire leurs licences, puis pour brancher l’IA sur des données propres. Cet article décrit la pile de SaaS au quotidien, les trois couches d’un OS d’entreprise, pourquoi ce choix est devenu accessible aux PME, les logiciels du marché à garder et comment démarrer par un premier module.
Une pile de SaaS fait ressaisir les mêmes données
Prenez une PME de 80 personnes. Les commerciaux suivent leurs affaires dans un CRM. Le chiffrage se fait dans un tableur, les commandes passent dans l’ERP, les techniciens remplissent leurs rapports d’intervention sur une application mobile, et le support répond aux clients dans un outil de ticketing. Le CRM, l’ERP, l’application mobile et l’outil de ticketing ont chacun leur propre fiche client. Quand un client change d’adresse de livraison, quelqu’un doit la corriger à quatre endroits, ou bien elle reste fausse dans trois outils sur quatre.
Les grandes entreprises vivent la même chose à une autre échelle. Zylo, éditeur d’un logiciel de gestion des abonnements, compte en moyenne 305 applications SaaS chez ses clients dans son index SaaS 2026. 36 % des licences payées par ces clients restent inutilisées. MuleSoft, filiale de Salesforce spécialisée dans l’intégration, a interrogé de grandes organisations pour son rapport 2025 : elles utilisent en moyenne 897 applications, dont 29 % seulement sont reliées entre elles.
Une PME qui empile les SaaS rencontre quatre problèmes concrets :
- Les équipes ressaisissent la même information d’un outil à l’autre, ou s’envoient des exports Excel.
- Personne ne sait quelle version d’une donnée est juste, parce que chaque outil garde la sienne.
- Les licences s’additionnent, outil par outil et siège par siège, y compris pour des modules que personne n’ouvre.
- L’IA reste cantonnée à un chatbot isolé, faute de pouvoir lire des données reliées.
Salto, la plateforme de streaming lancée par TF1, M6 et France Télévisions, ressaisissait les mêmes données d’une équipe à l’autre avant de faire construire son outil interne par Lonestone. Ses équipes suivaient l’acquisition des programmes dans un grand nombre de fichiers et ne savaient pas qui avait modifié quoi. Depuis Salto.run, elles saisissent une seule fois les données de chaque étape de la vie d’un programme, dans un outil partagé par tous les métiers.
Un OS d’entreprise réunit trois couches
Le terme est emprunté au système d’exploitation (OS) d’un ordinateur, qui gère les ressources que toutes ses applications partagent : la mémoire, les fichiers, les droits. Un OS d’entreprise fait la même chose pour les données de l’entreprise.
Un socle de données commun
Le client, le produit, la commande, l’intervention et le salarié existent une seule fois, dans une base unique. Chaque donnée a un identifiant stable, un historique de ses modifications et des droits d’accès par rôle. Les connecteurs vers les logiciels du marché que l’entreprise garde font aussi partie du socle.
Des modules métier
Chaque équipe travaille dans l’interface pensée pour elle : un CRM sur mesure pour les commerciaux, un ERP sur mesure pour la gestion des stocks et des commandes, une application mobile pour les techniciens, un portail pour les clients. Tous ces modules lisent et écrivent dans le même socle. Quand un technicien clôt une intervention sur le terrain, le commercial voit la mise à jour dans sa fiche client et la comptabilité peut facturer sans attendre un export.
Une couche d’agents IA
Les agents IA lisent les mêmes données que les équipes et agissent dessus, avec des droits définis : relancer un client dont le devis dort depuis dix jours, préparer une proposition à partir de l’historique des commandes, signaler un stock bas avant la rupture. Chaque action laisse une trace dans l’historique, comme celle d’un collaborateur.
graph TD
A[Agents IA : relances, devis, alertes] --> S[Socle de données commun : clients, produits, commandes, interventions]
B[CRM sur mesure] --> S
C[ERP sur mesure] --> S
D[Application terrain] --> S
E[Portail client] --> S
S -->|API| F[Comptabilité du marché]
S -->|API| G[Paie et SIRH du marché]
Les agents IA ont besoin de données reliées
Un agent IA branché sur une pile de SaaS doit interroger l’API de chaque outil, chacune avec ses quotas, ses formats et sa propre façon d’identifier un client. Il croise des fiches qui se contredisent et répond avec assurance à partir d’une adresse périmée. Dans le rapport de MuleSoft, 90 % des responsables informatiques interrogés disent que les silos de données leur posent des problèmes. La proportion monte à 94 % chez ceux qui utilisent déjà des agents.
Lonestone a rencontré ce besoin de données reliées sur les projets IA qu’elle a livrés. Pour Mom3nt, un logiciel de suivi commercial fondé sur des agents IA, l’équipe de Lonestone a passé une grande partie du projet à synchroniser les contacts, les affaires et les notes de HubSpot avec les échanges Gmail, puis à normaliser l’ensemble pour que les agents lisent des données fraîches et cohérentes. Pour Marvin Recruiter, éditeur d’un logiciel de recrutement, Lonestone a exposé les fonctionnalités existantes du logiciel sous forme d’outils utilisables par une IA conversationnelle, qui peut ainsi lire les fiches candidats, rédiger des documents et automatiser des recherches.
Dans un OS d’entreprise, ce travail de raccordement se fait une fois, au niveau du socle. Chaque nouvel agent lit directement des données propres, avec l’historique et les droits déjà en place. L’équipe qui lance une automatisation IA travaille alors dès le départ sur des données fiables.
Le sur mesure est devenu accessible aux PME
Il y a dix ans, une PME qui voulait relier tous ses outils sur une base commune lançait un projet de plusieurs années. Le développement sur mesure coûte aujourd’hui moins cher, pour trois raisons :
- Les frameworks modernes fournissent l’authentification, les droits et les formulaires, que les développeurs n’ont plus à réécrire.
- Les socles réutilisables, comme le boilerplate open source de Lonestone, apportent une architecture testée et des briques IA déjà câblées (appels aux LLM, RAG, agents, observabilité). Les développeurs construisent ensuite la logique métier par-dessus.
- L’IA écrit le code répétitif, ce qui laisse aux développeurs le temps de travailler les règles métier et l’UX.
Lonestone livre ainsi un premier outil métier utilisable en 2 à 4 semaines, puis le fait évoluer sprint après sprint. Un premier module d’ERP sur mesure coûte à partir de 30 000 €. Le coût d’un développement logiciel sur mesure dépend ensuite du type de projet.
Une entreprise qui part sur un mauvais périmètre, empile de la dette technique ou laisse traîner une faille de sécurité dépense bien plus que le prix du développement lui-même. L’entreprise gagne l’essentiel de son retour sur investissement au cadrage, en faisant les bons choix d’architecture pour le socle de données. Une fois le socle bien posé, chaque module supplémentaire coûte moins cher que s’il partait de zéro, parce qu’il réutilise les données, les droits et les connecteurs existants.
Les SaaS standards restent utiles là où ils suffisent
La comptabilité, la paie, la messagerie, la signature électronique ou la gestion des notes de frais suivent les mêmes règles d’une entreprise à l’autre. Les éditeurs de logiciels qui couvrent ces fonctions mettent leurs produits à jour à chaque évolution réglementaire, pour des milliers de clients. L’entreprise garde donc ces logiciels tels quels.
Le socle les relie par leurs API. Pour chaque donnée, l’entreprise choisit un outil maître, celui où la donnée est créée : la facture dans le logiciel de comptabilité, le salarié dans le SIRH, le client et la commande dans l’OS. Les autres outils lisent la donnée sans la modifier. Pour arbitrer fonction par fonction, appuyez-vous sur les trois questions pour choisir entre acheter et développer.
| Critère | Pile de SaaS juxtaposés | OS d’entreprise |
|---|---|---|
| Fiche client | Une par outil, à synchroniser | Une seule, partagée par tous les modules |
| Ressaisies | Fréquentes, par export ou à la main | Supprimées entre les modules du socle |
| Coût | Licences par siège, hausses décidées par chaque éditeur | Développement initial puis évolutions, sans licence par siège |
| Agents IA | Branchés outil par outil, sur des données qui se contredisent | Branchés sur le socle, avec historique et droits |
| Évolution d’un processus | Limitée par le paramétrage de chaque éditeur | Décidée par l’entreprise, à chaque sprint |
| Propriété | Données chez chaque éditeur, export souvent partiel | Code et données appartiennent à l’entreprise |
| Démarrage | Quelques jours par outil | Quelques semaines pour un premier module |
| Fonctions standard (paie, comptabilité) | Bien couvertes | Gardées en SaaS et reliées par API |
Démarrer par un premier module, puis étendre
Un OS d’entreprise se construit par étapes, sans grand soir. Le premier module doit être utile seul, dès sa mise en production.
- Repérez les ressaisies. Notez chaque endroit où une même information est saisie deux fois, et le temps que les équipes y passent chaque semaine.
- Choisissez le premier module. Prenez le processus qui génère le plus de ressaisies ou celui qui distingue l’entreprise de ses concurrents, souvent le suivi commercial, le chiffrage ou les interventions terrain.
- Posez le socle de données. Définissez les objets partagés (client, produit, commande), leurs identifiants, leurs droits et l’outil maître de chaque donnée.
- Livrez et reliez. Mettez le module en production en quelques semaines, branchez-le sur les logiciels du marché conservés et migrez les données depuis les tableurs.
- Étendez. Ajoutez un module ou un agent IA à chaque palier, dans l’ordre des priorités, en réutilisant le socle.
Salto a suivi ce chemin. Son outil interne couvrait au départ deux besoins, le suivi des acquisitions de programmes et le pilotage financier du catalogue. Lonestone a classé les autres besoins des métiers par priorité dans une feuille de route, avec un représentant de chaque équipe.
Trois risques à anticiper dès le départ
Un périmètre trop large
Quand une entreprise veut tout remplacer d’un coup, le projet s’éternise. Livrez un module utile, mesurez le temps gagné, puis décidez du suivant.
L’adoption de l’outil par les équipes
Quand les équipes contournent un outil, elles recréent des tableurs à côté. Observez les utilisateurs dans leur quotidien avant de concevoir les écrans, puis faites-leur tester ces écrans à chaque sprint. Les équipes utilisent vraiment un outil dont l’UX a été pensée avec elles.
La dépendance à un prestataire
Exigez la propriété du code et des données, un code typé, testé et documenté, et l’hébergement sur votre infrastructure ou chez un hébergeur de votre choix. Votre équipe ou un autre prestataire peut alors reprendre l’outil.
Questions fréquentes
Qu’est-ce qu’un OS d’entreprise ?
Un OS d’entreprise est un ensemble d’outils métier sur mesure (CRM, ERP, outils terrain, portail client) qui lisent et écrivent tous dans la même base de données. Des agents IA travaillent sur ces données, avec des droits définis, pour relancer un client, préparer un devis ou signaler un stock bas. Les logiciels standards de comptabilité ou de paie restent en place et sont reliés à cette base commune par leurs API.
Quelle différence entre un OS d’entreprise et un ERP ?
Un ERP du marché est un logiciel de gestion (achats, stocks, facturation) édité pour de nombreuses entreprises, avec le modèle de données de son éditeur. Un OS d’entreprise est construit pour une seule entreprise autour de ses propres données. Un ERP sur mesure peut en être l’un des modules, à côté d’un CRM, d’outils terrain et d’agents IA. Une entreprise peut partir des modules classiques d’un ERP et de leur rôle pour repérer ce que son OS doit couvrir.
Faut-il remplacer tous ses logiciels SaaS ?
Non. Pour la comptabilité, la paie, la messagerie et la signature électronique, qui suivent des règles communes à toutes les entreprises, les logiciels du marché restent le bon choix. Un OS d’entreprise remplace les outils qui obligent les équipes à ressaisir des données, ou qui gèrent mal un processus propre à l’entreprise. Les critères pour choisir entre acheter et développer s’appliquent fonction par fonction.
Combien coûte un OS d’entreprise ?
Un OS d’entreprise se finance module par module. Lonestone livre un premier outil métier utilisable en 2 à 4 semaines et facture un premier module d’ERP sur mesure à partir de 30 000 €. Le budget total dépend du nombre de modules, des intégrations et des agents IA. Les fourchettes de prix du développement logiciel sur mesure donnent des repères. Pour un chiffrage précis, Lonestone propose un échange, des conseils et un devis gratuits.
Peut-on brancher des agents IA sur ses outils actuels sans OS d’entreprise ?
Oui, une entreprise peut brancher un agent outil par outil, en passant par l’API de chaque logiciel. L’agent doit alors réconcilier des fiches qui se contredisent et respecter les quotas de chaque éditeur, ce qui limite sa fiabilité. Avec une base commune, l’agent lit une seule version de chaque donnée et chaque action reste tracée. Une entreprise peut lancer des agents IA et automatisations sur mesure sur ses outils actuels, puis les migrer vers une base commune.
Qui est propriétaire du code et des données d’un OS d’entreprise ?
Quand Lonestone développe l’OS, l’entreprise cliente est propriétaire du code source et des données. L’outil peut être hébergé sur son infrastructure. Son équipe technique peut aussi reprendre le code, qui est typé, testé et documenté.
Un premier module suffit pour commencer
Un OS d’entreprise se construit à partir des ressaisies que vos équipes font aujourd’hui. Repérez le processus qui en génère le plus, construisez le module qui les supprime sur un socle de données propre, puis ajoutez les modules et les agents IA suivants sur la même base. Lonestone a travaillé pour plus de 200 clients depuis 2014. Ses ingénieurs, qui ont pour la plupart 10 à 25 ans d’expérience, conçoivent et font évoluer ce type de logiciels métier sur mesure.
