
Converged — une plateforme open-source pour les entreprises industrielles : elle centralise la gestion du parc d’équipements, y compris les imprimantes 3D, les machines CNC, les complexes robotiques, et intègre tous les processus métier autour d’eux. Au lieu d’un ensemble d’utilitaires « par appareil », la plateforme fournit un périmètre de gestion unique : vous voyez la charge, la qualité et l’économie de la production dans un seul système.
À la base, il y a k3s (Kubernetes léger) : Converged s’installe de manière uniforme et fonctionne aussi bien sur un ordinateur que sur un serveur d’entreprise. Ensuite, vous choisissez un profil de déploiement : de « tout dans un seul conteneur » à « un conteneur par microservice ». Les agents LLM coordonnent les actions via API : ils collectent la télémétrie, lancent les processus, aident à planifier les files d’attente et suggèrent à l’opérateur l’étape suivante.
Converged est fourni comme un système unifié prêt à l’emploi. Sous le capot, ce sont des microservices conçus pour ne peser que quelques dizaines de kilo-octets, chargés à la demande et sans surcharger le matériel. La logique métier est déplacée dans un moteur DAG — un générateur de processus, où les scénarios de workflow sont déjà prêts, et où vous réglez principalement les paramètres. Les données des clients sont isolées par espaces de travail : chaque entreprise obtient son propre stockage, son propre chiffrement et la possibilité de migrer vers un mode hors ligne sans douleur.
Converged est toujours installé sur k3s (Kubernetes léger). Cela fournit une méthode unique de déploiement et de mises à jour, sans infrastructure lourde : le système peut fonctionner sur un seul ordinateur dans un atelier ou sur un serveur en entreprise.
Ci-dessous — trois variantes de déploiement, qui ne diffèrent que par l’empaquetage des services en conteneurs. En règle générale, l’utilisateur ne « construit » rien manuellement : les scénarios de workflow sont déjà intégrés au produit, vous configurez les paramètres et activez les processus nécessaires.
Tous les services sont empaquetés dans un seul conteneur. Le démarrage le plus simple et le plus rapide, avec un minimum de surcharge.
Les services sont répartis sur 8 conteneurs selon les types de charge. Cela offre du parallélisme et une grande réactivité sur des CPU multicœurs, sans gaspillage inutile de mémoire.
Chaque microservice est dans un conteneur séparé. Une variante pour les machines puissantes : multitâche maximal, vitesse et isolation.
Pour les installations self-hosted, nous donnons un contrôle total : vous gérez l’installation, les sauvegardes et la disponibilité réseau, en échange d’une indépendance et d’une conformité aux exigences internes. La version cloud vous libère des tâches opérationnelles — la gestion des accès, la redondance et les mises à jour sont prises en charge par notre équipe. Un scénario hybride est également pris en charge : les données critiques sont stockées localement, tandis que le cloud sert de coordinateur des mises à jour et de point d’interaction pour les équipes distribuées.
Converged est livré comme un système unique « prêt à l’emploi ». Ici, la modularité concerne l’architecture interne, et non le fait que l’utilisateur doive activer ou désactiver quoi que ce soit manuellement.
Les frontends, backends et blocs d’intégration sont assemblés à partir de paquets JS compacts sous Bun, de sorte que des dizaines de services n’occupent que quelques mégaoctets et partagent un environnement commun de bibliothèques, comme s’ils fonctionnaient au sein d’une seule machine virtuelle. Ces paquets sont regroupés par type de charge : tout ce qui relève de la logique métier peut vivre dans un seul conteneur, tandis que les opérations sur les fichiers en occupent un autre. Au final, la plateforme conserve sa modularité sans en payer le prix en consommation mémoire.
L’orchestration repose sur k3s : une version allégée de Kubernetes, optimisée pour les appareils edge. Nous trouvons un équilibre entre consolidation et découpage : les services sont suffisamment petits pour ne pas devenir un « monolithe », mais aussi suffisamment grands pour ne pas gonfler les coûts d’orchestration. Chaque application reçoit son propre ensemble de stockages : clé-valeur, SQL, fichiers et colonnes. Les données du client vivent quant à elles dans son workspace, sans base mutualisée multi-tenant, ce qui simplifie la migration et offre des garanties supplémentaires de sécurité.
Nous avons choisi Bun comme base pour les modules serveur : il lance rapidement JavaScript et TypeScript, économise la mémoire et convient aux appareils edge. L’orchestration est assurée par k3s — une version compacte de Kubernetes, qui fonctionne de manière tout aussi stable sur des ordinateurs monocarte (SBC) que dans des centres de données. Pour les tâches de bas niveau, comme la journalisation haute performance ou le travail avec des protocoles matériels, nous intégrons Zig : il offre un contrôle des ressources et s’intègre bien à l’écosystème existant.
Les agents intelligents s’articulent autour des meilleurs modèles du marché. DeepSeek aide à analyser les cahiers des charges techniques, Claude évalue la complexité et le coût, ChatGPT communique avec les clients, Mistral optimise les processus de production, et Gemini prend en charge le contrôle visuel de la qualité. Au-dessus de cela fonctionne l’analyse prédictive : la plateforme surveille l’état des machines, avertit des pannes possibles et propose une maintenance planifiée.
Dans Converged, le LLM est le chef d’orchestre de l’écosystème de production. Nous connectons les modèles via des adaptateurs : aujourd’hui ce sont GPT, Claude, DeepSeek, Mistral, Gemini ; demain, n’importe quel moteur, s’il existe une demande de la part des clients. Le modèle ne se limite pas à la conversation : il extrait le contexte depuis la télémétrie, récupère les documents, regroupe les indicateurs dans un seul résumé et explique à l’utilisateur ce qui se passe avec une commande ou un lot de pièces.
Lorsque l’opérateur résout une tâche dans l’interface, le LLM pilote les composants UI, lance des microservices et, si nécessaire, transfère le contrôle à un moteur DAG. C’est ainsi que se construisent les scénarios : de « prends la commande, calcule le coût, choisis la machine » à « clôture la tâche si la machine a passé le contrôle qualité ». Le modèle détermine quelles fonctions appeler, et la plateforme veille à ce que cela se fasse dans le cadre des droits et des politiques.
Toutes les actions sont exécutées dans le cadre du même modèle d’accès que pour les humains : un ABAC adapté au LLM. Chaque modèle dispose de son propre profil d’autorisations, et chaque étape est journalisée — on voit pourquoi le service a été appelé, quelles données ont été concernées et comment le scénario s’est terminé. Grâce à cela, on peut confier la routine au LLM — il traite le flux de commandes, choisit l’itinéraire optimal et rend compte de manière intelligible — tandis que le contrôle reste entre vos mains.
Nous avons sorti la logique métier des microservices dans un moteur DAG séparé. C’est une couche d’intégration qui relie différents services en des processus métier unifiés : de la prise de commande à la production, l’approvisionnement, la livraison et les notifications. Il ressemble à n8n, mais est conçu pour des charges de production : des chaînes de lambdas, d’appels API et de décisions s’exécutent au sein de Converged.
Important : la plupart des utilisateurs ne « construisent » pas les graphes manuellement. Le produit contient déjà des scénarios de workflow prêts à l’emploi ; en général, vous configurez les paramètres (règles, SLA, intégrations, rôles, notifications) et activez les processus nécessaires.
La flexibilité reste disponible pour les déploiements avancés : l’équipe peut étendre les scénarios, et les développeurs peuvent connecter des agents LLM qui construisent les graphes dynamiquement. L’exécution est parallélisée entre les workers et les conteneurs, de sorte que la charge est répartie uniformément et que les chaînes s’exécutent sans délai.
Nous unifions toute machine sous une interface unique. Des adaptateurs pour Klipper, Marlin, les CNC industrielles et les bras robotiques « enveloppent » chaque machine et en font un robot industriel doté d’une API commune. Ainsi, Converged voit tout l’équipement de la même manière — qu’un module imprime du plastique, découpe du métal ou assemble des boîtiers sur un convoyeur.
Ensuite, le convoyeur entre en action. Grâce au constructeur de DAG des processus métier, il est possible de relier les machines en chaîne : la première imprime une pièce, la deuxième effectue le fraisage, la troisième réalise le contrôle qualité, et la quatrième assemble le produit. La plateforme orchestre ce flux numérique, assigne les tâches aux bonnes unités et réagit automatiquement si l’une des étapes nécessite une intervention.
L’opérateur n’a plus besoin de mémoriser des dizaines d’interfaces. L’état de n’importe quelle machine s’ouvre depuis une seule fenêtre : on peut voir qui est occupé, qui est à l’arrêt, combien de cycles restent. S’il faut intervenir manuellement, le contrôle est disponible depuis un ordinateur portable ou une tablette. En arrière-plan, le slicing parallèle et les files d’attente fonctionnent : le système équilibre les tâches entre les exécutants afin que le parc fonctionne de manière régulière et sans temps d’arrêt.
Converged a été conçue pour économiser la mémoire et démarrer rapidement. Les services backend sont des paquets compacts pour Bun, qui partagent un environnement de bibliothèque commun et démarrent en quelques millisecondes. Nous les regroupons par type de charge : au lieu d’une centaine de conteneurs, quelques blocs unifiés sont activés, ce qui réduit les surcharges et accélère le fonctionnement.
Le système utilise tous les cœurs CPU disponibles, en parallélisant les tâches entre les conteneurs et les workers dans k3s. Les stockages à l’intérieur des services restent légers : nous limitons les index et ne déplaçons pas de données superflues, de sorte que même une migration vers un nouveau matériel s’effectue rapidement. En conséquence, un environnement de production complet fonctionne de manière stable avec une mémoire de deux gigaoctets et se met à l’échelle dans les limites de la puissance d’un seul ordinateur ou serveur.
Nous regardons la plateforme à travers les yeux du client. Une entreprise ne vient pas pour une « fonctionnalité », mais pour résoudre une tâche précise : prendre une commande, faire passer un modèle dans le slicer, valider le coût, suivre la livraison. C’est pourquoi l’unité de valeur de base est la Solution : un scénario prêt à l’emploi qui couvre l’ensemble du processus.
Aujourd’hui, le catalogue comprend des solutions pour les bureaux de service d’impression 3D, la fabrication sous contrat et les équipes R&D. À l’intérieur : gestion des fichiers, communication avec le client, analytique et adaptateurs pour les équipements.
Si la tâche est unique, la Solution se configure comme un workflow : règles, parcours, rôles, SLA et intégrations — sans « assemblage de bricolage » manuel.
Converged est une plateforme ouverte, et nous comptons sur la contribution de la communauté. Pour ajouter une intégration ou une extension, il suffit de créer un microservice ou un microfrontend sur une API compatible, de publier le code source sur n’importe quel hébergement Git et de soumettre une demande au catalogue. La vérification par LLM analysera automatiquement le dépôt : présence éventuelle de binaires, d’injections malveillantes, d’opérations bloquantes pour le Bun mono-thread. Après validation, l’extension apparaît dans le catalogue et peut être utilisée dans les Solutions et les workflows.
Le code de base du noyau est disponible sous une licence ouverte. Les créateurs d’extensions peuvent choisir leurs propres conditions de distribution, mais pour une publication dans le catalogue, un code source transparent est requis — c’est ainsi que nous protégeons les utilisateurs et maintenons la confiance entre les membres de l’écosystème.
Nous avons abandonné l’approche standard avec des bases de données partagées. L’architecture Converged repose sur une isolation complète :
Espaces de travail isolés. Les données de chaque client sont stockées dans un répertoire séparé et chiffré. Aucune table ni aucun stockage partagé — vos données sont physiquement séparées de celles des autres entreprises. Cela exclut les accès accidentels et réduit considérablement la surface d’attaque.
Clés de chiffrement propres. Chaque espace de travail est chiffré avec sa propre clé. Vous êtes l’unique propriétaire de l’accès à vos données.
Micro-stockages. Au lieu d’une lourde base de données centrale, chaque microservice utilise son propre ensemble de stockages légers (key-value, SQL, fichiers), ce qui améliore la tolérance aux pannes et simplifie la gestion.
Cette architecture vous donne un contrôle sans précédent :
Exportation en un clic. À tout moment, vous pouvez obtenir un dump complet de toutes vos données et le déployer sur un serveur local. Si quelque chose ne vous convient pas, vous ne serez pas « enfermé » dans le cloud.
Déploiement flexible. Commencez à travailler dans le cloud, puis, si nécessaire, migrez des divisions spécifiques ou l’entreprise entière vers vos propres serveurs (même sur un Orange Pi compact), tout en conservant un contrôle total sur l’emplacement physique des données. Le cloud peut ne rester qu’un point de gestion pratique.
Converged est distribué sous AGPL‑3.0. Il s’agit d’une licence copyleft forte : si vous modifiez la plateforme et y donnez accès via le réseau, vous êtes tenu de divulguer les changements. Cette approche protège la communauté — le code reste ouvert, et les améliorations retournent dans l’écosystème.
Grâce à la licence ouverte, la version self-hosted peut être déployée gratuitement et offrir presque l’ensemble des fonctionnalités. C’est la voie pour les entreprises qui ont besoin d’un contrôle total, de se conformer aux politiques d’entreprise ou de la possibilité d’expérimenter sur leur propre infrastructure. En contrepartie, il faudra assumer l’installation, les sauvegardes et la disponibilité du service.
La livraison cloud est un service « prêt à l’emploi ». Elle se met en route presque instantanément, s’adapte automatiquement en capacité et bénéficie d’un SLA. Nous nous chargeons des sauvegardes, de la supervision et des mises à jour, de sorte que pour la plupart des clients cette option s’avère moins coûteuse et plus stable que de constituer des compétences en interne. Le prix ne dépend pas du coût du code, mais de la rapidité de mise en œuvre et de la prévisibilité du fonctionnement.
Le projet est en développement actif. Le plan de travail actuel, les tâches et les discussions sont suivis dans notre dépôt sur GitHub.
Rejoignez le développement et suivez les mises à jour : https://github.com/solenopsys/converged