Comment fonctionne {yourcompany}os : couche processus, couche implémentation, schéma ouvert

Un nouveau projet démarre. Quelqu'un tape le nom dans l'ERP. Quelqu'un d'autre crée le dossier dans SharePoint. Une troisième personne configure la boîte aux lettres, et les plans arrivent dans le CDE. Cinq systèmes, chacun fonctionnant très bien de son côté, aucun ne sachant qu'ils décrivent tous le même projet. Personne n'a choisi cela. C'est ce qui arrive quand chaque outil garde sa propre version de la vérité et que les personnes sont la couche d'intégration entre elles.

{yourcompany}os est la couche qui se pose par-dessus ce stack et le tient ensemble. Elle ne remplace ni votre ERP, ni votre stockage, ni votre messagerie, ni vos outils spécialisés. Elle fait tourner le processus à travers eux, de sorte que le projet existe une seule fois en tant que processus, et que chaque système reçoive ce qu'il doit savoir.

En dessous, cette séparation est délibérée : le processus, les systèmes auxquels il parle et le modèle de données sont trois couches indépendantes plutôt qu'un seul bloc. Cet article parcourt ce que fait chaque couche, ce qu'elle vous épargne, et comment les trois se comportent quand un outil de votre stack change.

Ce qui reste, et ce qui change vraiment

Reste exactement tel quel	Ce qui change
Votre ERP, CRM, stockage, messagerie et CDE	Un processus les traverse, au lieu d'une personne qui porte le travail entre eux
Les outils que vos équipes connaissent déjà	Les tâches arrivent dans la boîte de réception et le classement existants, pas dans une interface de plus
L'endroit où vivent vos fichiers	C'est le processus qui répond à la question de la version courante, pas une convention de nommage
IFC comme format d'échange	Un schéma orienté workflow se pose dessus pour que les applications puissent interroger et valider

L'avantage concret d'être une couche plutôt qu'une plateforme : il n'y a pas de projet de migration. Rien ne doit être sorti des systèmes où il vit avant que le premier processus puisse tourner, et c'est pourquoi un premier processus clé passe en production en 1-2 jours au lieu d'attendre un déploiement. Personne n'a besoin d'être formé à une nouvelle interface, puisque le travail est livré dans les outils que les équipes ouvrent déjà chaque matin. Et quand la seule personne qui connaissait toutes les étapes part en vacances ou quitte l'entreprise, les étapes sont dans le processus et non dans sa tête.

Les trois couches

Couche	Ce que c'est	Ce que cela vous apporte
Processus	Des définitions BPMN que votre équipe écrit et possède	Le flux survit aux changements d'outils et de personnel, et reste auditable
Implémentation	Un connecteur par groupe de capacités (stockage, ERP, messagerie, IA, paiement, ...)	Changer de fournisseur est une modification de configuration, pas un projet de refonte
Modèle de données	Le schéma ouvert contre lequel entités et processus lisent et écrivent	Vous pouvez inspecter et exporter vos propres données sans demander la permission

La plupart des outils de workflow fusionnent tout cela : le "flow" est l'intégration est la structure de données, tout défini dans le même canvas no-code, et tout perdu ensemble si vous changez de fournisseur. {yourcompany}os garde les trois parties indépendamment remplaçables, ce qui est exactement ce qui rend sûr de la poser sur un stack dans lequel vous avez déjà investi.

Couche 1 : le processus, la partie qui survit à vos outils

Un processus dans {yourcompany}os est une définition BPMN, pas une exécution de flow. La distinction paraît théorique jusqu'à ce qu'un outil change. Une "exécution de flow" (Power Automate, Zapier, la plupart des outils iPaaS) est un passage unique qui démarre, fait son travail et se termine. Elle n'a aucune mémoire d'elle-même comme entité, donc dès qu'un projet s'étale sur des semaines et plusieurs transmissions, il n'y a rien de durable à montrer. Une définition de processus BPMN est un artefact : elle a des phases, des sous-processus, des gateways et un cycle de vie qui survit à chaque exécution individuelle.

Ce que cela donne au quotidien :

• Une seule identité de projet au lieu de cinq. Nommage, enregistrement dans l'ERP (dans SAP ou bexio, par exemple), configuration, exécution et clôture sont des phases d'un seul processus, chacune touchant des systèmes différents mais toutes pointant vers le même projet. C'est le problème de copier-coller de l'introduction, résolu structurellement. Le détail complet est dans Créer un projet : un ancrage stable à travers vos outils.
• Le travail long ne se casse pas aux transmissions. Configuration et livraison tournent comme leurs propres sous-processus à travers les outils, mais restent des phases du processus parent plutôt que des scripts autonomes qui se terminent et oublient.
• L'IA aide sans commander. Un agent peut rechercher, classifier ou rédiger à l'intérieur d'une étape ; des gateways et des personnes décident de la suite, et chaque étape est journalisée. Utile quand vous devez expliquer à un client ou à un auditeur pourquoi quelque chose a été approuvé.
• Vous pouvez lire votre propre processus. Comme c'est du BPMN et non du JSON de flow propriétaire enfoui dans un canvas SaaS, la définition est lisible et portable, et un nouvel employé peut regarder le diagramme au lieu de poser la question autour de lui.

Remplacez un ERP, un fournisseur de stockage ou une visionneuse, et la définition du processus ne change pas. Seule l'implémentation résolue en dessous change, et c'est la couche suivante.

Couche 2 : les implémentations, là où la liaison se fait vraiment

Une étape de processus ne nomme jamais un fournisseur. Elle nomme un groupe de capacités, et exactement une implémentation est configurée pour servir ce groupe. Les groupes de capacités sont des choses comme le stockage, la messagerie, l'ERP et la comptabilité, le CDE, la visualisation de plans, le BIM, l'IA ou le paiement. Pendant l'onboarding, vous pointez chaque groupe nécessaire vers ce que vous exploitez déjà, et la logique du processus reste identique quel que soit votre choix.

Implémentations actuellement disponibles par groupe :

• Stockage : Nextcloud, Google Drive, Microsoft 365 (SharePoint ou OneDrive via Microsoft Graph)
• Messagerie : Outlook / Microsoft 365, Gmail, Nuntly (pour les boîtes de réception de projet et l'envoi système)
• ERP / comptabilité : bexio (adresses, ERP, comptabilité)
• CDE : Trimble Connect
• Visualisation de plans / BIM : moteur interne ou iolabs (visionneuse de plans), abstractBIM (BIM et IFC)
• IA : Infomaniak AI (hébergement suisse, par défaut), OpenAI, Anthropic, Google Gemini, ou votre propre modèle en BYO LLM
• Paiement : Stripe

La mécanique complète est dans Implémentations : connecter les systèmes du client.

Deux conséquences en découlent, et ce sont le genre de choses qu'on apprécie seulement au bout de deux ans :

1. Changer de système est une modification de configuration, pas un projet de refonte. Votre entreprise passe de Nextcloud à SharePoint, ou change de fournisseur d'IA à cause d'une évolution tarifaire. Le processus qui consomme "stockage" ou "IA" comme capacité continue de tourner sans être touché. Comparez cela à un flow no-code où le fournisseur est câblé dans chaque noeud.
2. Un système manquant s'ajoute, il ne bloque pas. Si quelque chose dans votre stack n'a pas encore d'implémentation, on en ajoute une pour ce groupe de capacités sans redessiner le processus qui l'utilisera. En pratique, cela se cadre par un Discovery Sprint (à partir de CHF 6'000) : la nouvelle implémentation est construite et raccordée au processus concerné en 1-2 jours, et non comme un projet d'intégration séparé avec son propre tour de budget.

Ce qui répond à la question que tout évaluateur technique pose dans les dix premières minutes, alors autant le dire clairement :

{yourcompany}os remplace-t-il mon ERP ? Non. Votre ERP, CRM, messagerie et outils spécialisés restent où ils sont, et les personnes qui les utilisent continuent de les utiliser. {yourcompany}os s'y connecte comme implémentations et orchestre les étapes entre eux. C'est une couche d'orchestration à côté de votre ERP, pas un concurrent.

Couche 3 : le modèle de données, schéma ouvert, sans login

Le schéma derrière {yourcompany}os est publié sous le nom de Pragmatic Data Contract, consultable sur schema.pragmaticbim.ch sans aucun compte. Vous pouvez inspecter les classes, les relations et les versions publiées avant d'intégrer ou de vous engager à quoi que ce soit, exactement l'inverse d'un modèle de données que vous ne voyez qu'après un entretien commercial.

Pourquoi cela compte pour vous, et pas pour nous :

• Le sens circule entre les outils. Des entités comme les projets, les espaces, les exigences, les modifications et les objets de processus partagent une URI de schéma publique stable et des relations de graphe, de sorte que le même projet signifie la même chose dans {yourcompany}os, dans iterthink et dans tout ce qui est construit sur le contrat, au lieu d'être recodé en colonnes propriétaires dans chaque système.
• Vous pouvez l'améliorer. Le schéma vit sur GitHub sous le nom de Pragmatic BIM Data Contract. Ouvrez des issues, proposez des entités, soumettez des pull requests. Si votre secteur a besoin d'un concept absent, vous n'attendez pas la feuille de route privée d'un fournisseur.
• La sortie est inspectable, pas théorique. Comme le schéma est public et versionné, vous pouvez l'auditer avant de vous engager, planifier un chemin de migration et exporter contre une version que vous pouvez figer. Vous savez à l'avance ce que sont structurellement "vos données", au lieu de le découvrir pendant un litige contractuel.

Tous les détails dans Un schéma ouvert au lieu d'une base de données boîte noire. Une clarification utile : ce n'est pas un remplacement d'IFC. IFC reste le format d'échange, et le schéma est un contrat orienté workflow posé dessus pour que les applications puissent interroger, valider et automatiser sans redériver la logique IFC à chaque fois.

Comment les trois couches interagissent : un cas déroulé

Reprenons l'événement de l'introduction, "un nouveau projet est créé", et suivons-le à travers les trois couches.

1. Le processus démarre. La définition Créer un projet commence et attribue un nom et une identité de projet. Défini une fois, en BPMN, et inchangé quels que soient les outils derrière.
2. Il atteint l'étape d'enregistrement dans l'ERP. Cette étape déclare une dépendance au groupe de capacités "ERP / comptabilité", pas à un fournisseur particulier.
3. L'implémentation configurée la résout. Si votre implémentation pour ce groupe est bexio, l'étape s'exécute contre l'API bexio. Pointez le groupe ailleurs et la même étape se résout différemment, la définition du processus restant intacte.
4. Le résultat est écrit contre le schéma ouvert. L'entité projet, son identité et ses relations sont persistées comme classes du contrat publié plutôt que comme une ligne opaque dans une table propriétaire, si bien que tout autre produit ou intégration sur ce schéma peut adresser le même projet de la même manière.
5. Configuration et clôture continuent sur la même colonne vertébrale. Chaque sous-processus résout les groupes de capacités dont il a besoin (stockage pour les documents, messagerie pour les notifications) tout en se référant à l'unique identité de projet créée à l'étape 1.

Comparez cela à la version que vous faites probablement tourner aujourd'hui, où l'étape 1 est une personne qui tape un nom à cinq endroits et où les étapes 2 à 5 sont un fil de discussion. Rien dans ce déroulé ne couple le processus à un fournisseur, et rien ne cache les données produites derrière un login. Chaque couche peut changer sans entraîner les autres.

Pourquoi les couches sont séparées ainsi

Cette structure est délibérément l'inverse d'une plateforme à ontologie fermée. Un système comme Palantir Foundry garde son ontologie propriétaire, parce que l'ontologie est le lock-in. {yourcompany}os publie le schéma ouvertement et traite vos définitions de processus, et non le schéma, comme ce que vous possédez et affinez. Votre avantage compétitif n'a jamais été le modèle de données ; c'est la façon dont votre entreprise fonctionne réellement. La comparaison complète, y compris les différences de prix et de modèle de livraison, est dans Comment {yourcompany}os apporte le modèle Palantir aux PME.

FAQ

{yourcompany}os remplace-t-il mon ERP ?
Non. Votre ERP (SAP ou bexio, par exemple) reste en place comme une implémentation derrière le groupe de capacités "ERP". {yourcompany}os orchestre les étapes autour de lui et ne reprend pas les fonctions de l'ERP.

Devons-nous migrer des données ou reformer les équipes avant de commencer ?
Non. C'est tout l'intérêt d'être une couche plutôt qu'une plateforme. Les données restent dans les systèmes qui les détiennent, et les tâches sont livrées dans la boîte de réception et le classement que les gens utilisent déjà, ce qui explique qu'un premier processus puisse passer en production en 1-2 jours.

Puis-je héberger moi-même ou sur ma propre infrastructure ?
L'hébergement suisse est le mode d'exploitation par défaut. Comme le schéma est public et versionné, vous pouvez inspecter et planifier la portabilité des données indépendamment du lieu d'hébergement.

Qu'advient-il de nos données si nous partons ?
Comme le modèle de données est publié et versionné plutôt que propriétaire, vous exportez contre un schéma que vous comprenez et avez déjà audité, au lieu de négocier un format d'export après coup.

En quoi est-ce différent d'un iPaaS comme n8n ou Zapier ?
Les outils iPaaS sont forts pour les connexions de courte durée entre applications mais faiblissent dès qu'un processus gagne des phases, des sous-processus et de la gouvernance, parce que le "workflow" et le "processus" sont le même objet jetable. {yourcompany}os garde le processus comme définition durable et versionnée, et les intégrations comme implémentations interchangeables en dessous.

Où se trouve la source de vérité du schéma ?
schema.pragmaticbim.ch pour la référence à jour et les instantanés versionnés, le contrat sous-jacent étant maintenu ouvertement sur GitHub sous le nom de Pragmatic BIM Data Contract.

Et si un système que nous utilisons n'a pas encore d'implémentation ?
Une nouvelle implémentation peut être ajoutée pour ce groupe de capacités sans redessiner le processus qui en dépend, y compris le raccordement de votre propre LLM en implémentation BYO pour le groupe IA. Cela se cadre par un Discovery Sprint (à partir de CHF 6'000, 1-2 jours), le même mécanisme que pour mettre un premier processus en production.