Aujourd'hui
L'équipe sur un écran : ce qui est dû, ce qui est en retard, ce qui attend une décision.
- Aujourd'hui
Détails techniques
Pour votre équipe informatique : comment fonctionne Zagru One
Ce qui se trouve derrière la page destinée aux acheteurs : architecture, configuration, intégration, identité et séparation des données. Chaque affirmation de cette page a été vérifiée dans le code du produit ; ce qui n'est pas encore en production est signalé.
Demander un échange techniqueChiffres mesurés
Comptés dans le code, pas inventés pour le marketing.
- capacités mesurées
- 177
- 147 complètes, 20 partielles, 10 pas encore mesurées
- points de terminaison de l'API backend
- 1 700+
- documentés par une définition OpenAPI
- domaines de capacités
- 17
- entrepôt, transport, 3PL, facturation, douane et autres
- types de définitions configurables
- 35
- dans Studio, avec un cycle de vie soumis à validation
Source : rapport de couverture des capacités et définition de l'API de Zagru One, septembre 2026.
Ce qui change
Quatre points à vérifier dans toute démo.
Chacun est un mécanisme présent dans le code, pas un adjectif de brochure.
01Processus guidés
Une décision par étape, imposée sur le serveur.
Créer un site n'est pas un formulaire de vingt champs. C'est une suite de questions uniques, chacune résolue côté serveur et validée dans le chemin de commande.
Une question à la fois — Chaque étape demande ce dont elle a besoin et en énonce la conséquence : le code du site figure sur chaque document, étiquette et rapport, et ne pourra plus être modifié.
Les étapes sont des données, pas des écrans — Ordre, visibilité, obligation, valeurs par défaut et validation sont des règles résolues selon la plateforme, le locataire, le tiers, l'entrepôt, le processus et le rôle. Un seul moteur de rendu sert tous les processus.
La règle tient sans l'interface — Le backend valide chaque étape contre la même expérience effective : un client qui appelle l'API directement ne peut pas contourner une obligation.
Le travail non enregistré est défendu — Quitter un formulaire comportant des modifications déclenche un avertissement explicite au lieu d'abandonner silencieusement la saisie.
02Studio
Trente-cinq types de définitions, un seul cycle de vie contrôlé.
La configuration est un objet de premier rang doté d'une clé, d'une version et d'une trace d'approbation — pas une page de réglages modifiée par quelqu'un en mars dernier.
Une clé stable, volontairement définitive — Les définitions sont nommées par espaces de noms séparés par des points, et la clé ne peut plus changer après création : les références restent valides d'une version à l'autre.
La version un est un brouillon — Créer une définition crée une version brouillon. Publier est un acte distinct et délibéré.
Bac à sable et tests avant approbation — Une version est validée, portée en bac à sable puis testée avant de pouvoir être soumise à approbation.
Rédigé, non codé — Workflows, jeux de règles, écrans, formulaires, documents, étiquettes et mappages se composent à partir de composants du registre. La configuration les paramètre ; elle ne fournit jamais de code exécutable.
Cycle de vie d'une définition
- Brouillon
- Bac à sable
- Test
- Validation
- Publié
Les 35 types de définitions
- Flux de travail
- Règles
- Écrans
- Formulaires
- Écrans mobiles
- Tableaux de bord
- Rapports
- Documents
- Étiquettes
- Notifications
- Indicateurs
- Mappages d'intégration
- Jeux de permissions
- Agents
- Types de tâche
- Jeux de configuration
- Modèles sémantiques
- Champs personnalisés
- Types d'emplacement
- Statuts de stock
- Types de rôle tiers
- Types de frais
- Types de jalon
- Types d'exception
- Ensembles de réglages
- Caractéristiques
- Modes de transport
- Types de ressource
- Types d'équipement
- Profils d'expédition
- Parcours de processus
- Liaisons d'intégration
- Liaisons de documents
- Lots de documents
- Types de documents de conformité
03Hub du site
Chaque site dispose d'un endroit qui s'explique lui-même.
Pas une arborescence de réglages. Un hub d'actions nommées en langage clair, groupées selon ce qu'elles changent — et honnête sur ce qui n'est pas encore construit.
Groupé par intention — Structure, exploitation et le reste : la forme du site, le travail qui s'y impute et la trace des deux.
Chaque action dit ce qu'elle fait — Les zones sont décrites comme réception, stockage, front de préparation et mise à quai ; un emplacement est un casier, une position de rack, une porte de quai ou une voie de préparation.
L'inachevé est signalé — Les actions non encore disponibles restent visibles et marquées, plutôt que masquées pour donner l'illusion d'un produit fini.
La désactivation préserve l'historique — Arrêter un site arrête le travail nouveau tandis que sa structure et son historique restent consultables.
04Locataires et accès
Une isolation imposée par la base, pas par la requête.
Une architecture multi-locataires qui repose sur la mémoire de chaque développeur pour une clause WHERE n'en est pas une. Celle-ci s'impose sous l'application.
Une isolation que l'application ne peut pas contourner — Chaque table de locataire impose l'isolation dans la base de données elle-même, et le locataire actif est lié à la transaction avant la première requête, si bien que la règle s'applique pendant toute sa durée.
Aucun locataire par défaut — Sans contexte de locataire, les tables concernées ne renvoient aucune ligne. Il n'existe pas de repli implicite qui verrait tout.
Les rôles sont limités aux sites — Un rôle est accordé pour un entrepôt, ou — délibérément et visiblement — pour tous les entrepôts du locataire.
Vérifié au démarrage — La plateforme contrôle ses propres règles d'isolation au démarrage : une règle manquante empêche le démarrage au lieu de fuir en silence.
Architecture
La partie sur laquelle les achats vous interrogeront.
Huit couches, chacune avec une seule mission, et une frontière nette entre votre métier et la mécanique en dessous. C'est cette frontière qui permet à votre exploitation d'évoluer sans réécrire la plateforme.
Modèle canonique
Entrepôt, transport, douane et 3PL partagent une seule définition de chaque enregistrement : il ne reste rien à rapprocher entre eux.
Cœur d'exécution
Le moteur derrière la réception, la préparation, le chargement et la facturation. Un seul comportement pour tous les locataires, sans branche par client.
Système de référence
Stocks, mouvements et décisions sont stockés une seule fois, comme la version qui fait foi pour tous les autres systèmes.
Couche de configuration
Ce qui rend votre exploitation particulière vit en métadonnées, règles et écrans — versionné et publié, jamais en branche du code source.
Moteur de processus
Un traitement qui dure des heures ou des jours est mené à son terme étape par étape, chaque étape étant consignée dès qu'elle s'achève.
Dorsale d'événements
Chaque changement significatif est publié : les systèmes connectés sont prévenus au lieu d'avoir à interroger la plateforme.
Couche d'accès
Un seul endroit où les personnes, les rôles et les identifiants machine sont définis pour tous les domaines de la plateforme.
Couche analytique
Le reporting s'exécute sur un chemin conçu pour les questions lourdes : le terrain n'attend jamais le rapport d'un autre.
Les choix technologiques ne doivent pas laisser des concepts propres à un framework s'infiltrer dans le domaine métier.
Isolation des locataires
Aucun locataire n'atteint les données d'un autre. La règle est imposée dans la base de données elle-même, et si elle manque sur une table, la plateforme refuse de démarrer.
Piste d'audit
Qui a changé quoi et quand, consultable par site et à l'échelle du locataire, y compris le commentaire laissé avec une décision.
Identité
Authentification unique via votre propre fournisseur d'identité d'entreprise, rôles accordés entrepôt par entrepôt et identifiants d'API restreints aux permissions accordées.
Télémétrie
Chaque opération est traçable de bout en bout, avec santé et métriques accessibles à votre exploitation, les détails internes restant hors des réponses publiques.
Configuration versionnée
La configuration effective est horodatée par version, si bien que l'on peut reconstituer les réglages sous lesquels une décision a été prise.
Exécution durable
Les traitements longs sont durables : un redémarrage reprend le processus là où il s'est arrêté au lieu de le perdre.
Intégration
Un entrepôt n'est jamais le seul système du bâtiment.
Six canaux, chacun étant un vrai module côté serveur plutôt qu'un projet de conseil. Leur statut est indiqué un par un ci-dessous.
API REST
La même API que celle appelée par l'interface du produit. Rien n'est réservé à l'éditeur.
Webhooks
Des livraisons signées vers votre point de terminaison : le système tiers est prévenu au lieu d'interroger en boucle.
EDI
Lit les messages X12 850, 856, 940, 943, 944, 945, 947, 214 et EDIFACT ORDERS, DESADV, RECADV, IFTSTA. Écrit les messages X12 850, 856, 945, 997 et EDIFACT DESADV. Transport : fichiers et SFTP. Pas encore d'écran dédié à l'EDI ; correspondance des champs dans Studio.
Connecteurs
Le connecteur de fichiers (CSV, SFTP) est en production. Les connecteurs de commandes ERP, de places de marché et de transporteurs de colis fonctionnent sur des environnements de test ; leurs connexions en production sont en développement.
Événements
Une dorsale d'événements porte les événements métier entre modules et vers l'extérieur, avec des motifs génériques pour les abonnés.
Identifiants restreints
L'accès machine est un objet de premier rang doté de ses portées, de son compte d'audit et de sa révocation.
Un identifiant se crée dans le produit, porte le nom du système qui le détiendra, se rattache à un compte de service qui journalise tout ce qu'il fait, et reçoit le plus petit ensemble de portées permettant encore à l'intégration de fonctionner.
Le comportement métier sans fork.
Un pack porte les règles, statuts, types de document et validations qu'exige un secteur ou une juridiction, et s'installe comme configuration au lieu d'être branché dans le produit.
Packs métier
- Pharmaceutique
- Agroalimentaire
- Mode
- Automobile
- Chimie
- Électronique
- 3PL
Packs pays et réglementaires
- Union européenne
- Turquie
- Royaume-Uni
Carte des écrans
Les domaines et les écrans qu'ils ouvrent.
La navigation de l'application, section par section, avec les écrans que chaque domaine ouvre. Les domaines modélisés côté serveur mais encore sans écran sont signalés.
01Piloter
L'équipe en poste, telle qu'elle est à l'instant.
À traiter
Les exceptions réunies dans une file unique plutôt que dispersées entre les modules.
- À traiter
02Exécuter
Le travail physique : ce qui entre, ce qui sort, et le stock entre les deux.
Réception
De la réception attendue au rangement, blocage qualité compris.
- Réceptions attendues
- Poste de réception
- Contrôle qualité
Expédition
Les commandes deviennent des vagues, les vagues des préparations, et les préparations une remorque chargée.
- Commandes
- Vagues
- Poste d'emballage
- Poste d'expédition
Stock
Soldes, unités de manutention et lots, avec chaque mouvement qui les a modifiés.
- Soldes
- Unités de manutention
- Lots
- Mouvements
- Ajustements
- Comptages
Tâches
Une file unique pour le travail que le système affecte à une personne ou à une machine.
- Tâches
Processus
Les processus guidés en cours et les approbations qui les conditionnent.
- Instances
- Approbations
03Ressources
Les personnes, la cour et les quais par lesquels elles travaillent.
Effectifs
Qui est en poste, sur quoi cette personne est affectée et comment le travail se répartit.
- Effectifs
Cour / Quai
Rendez-vous, tableau des quais et remorques qui circulent entre les deux.
- Rendez-vous
- Tableau des quais
- Plan de cour
04Réseau
Tout ce qui se passe au-delà des quatre murs.
Transport
Chargements et expéditions, de l'appel d'offres à la livraison, avec les transporteurs derrière.
- Chargements
- Expéditions
- Appels d'offres
- Suivi
- Transporteurs
3PL
Les contrats et les événements facturables qu'ils transforment en factures.
- Contrats
- Facturation
Tour de contrôle
Une vue unique sur les sites, les transporteurs et les commandes.
- Tour de contrôle
Douane
En développementDéclarations, registre du stock sous douane et garanties. La connexion pour les déclarations officielles (BİLGE, Turquie) est en développement.
05Analyse
Des réponses tirées des mêmes enregistrements que le terrain écrit.
Opérations IA
Un assistant IA qui travaille sur les mêmes enregistrements, avec les droits de l'utilisateur. Accès anticipé ; désactivé par défaut.
- Opérations IA
Rapports
Reporting opérationnel sur le magasin analytique.
- Rapports
06Construire
Là où la plateforme se configure au lieu de se personnaliser.
Studio
Là où workflows, règles, écrans, formulaires, documents et étiquettes sont rédigés et publiés.
- Studio
07Administrer
Locataires, accès et trace de qui a changé quoi.
Paramètres
Locataires, accès, configuration de la plateforme et journal d'audit.
- Profil du locataire
- Organisations
- Utilisateurs
- Rôles
- Identifiants d'API
- Configuration
- Indicateurs de fonctionnalité
- Intégrations
- Journal d'audit
Écrans d'intégration et d'accès
Clés, webhooks, configuration : vus de l'intérieur du produit.
Capturés dans l'application en fonctionnement. Les enregistrements sont des données de démonstration.
Paramètres
Une clé agit comme un compte de service unique, limitée aux permissions choisies et révocable seule.
Paramètres
Des livraisons signées vers un point de terminaison https ; ceux qui échouent sont désactivés après des erreurs répétées.
Studio
Un nouveau jeu de règles naît en version un brouillon et se publie via bac à sable, test et approbation.
Paramètres
Entités juridiques, régions, sites et départements délimitent utilisateurs, configuration et reporting.
Paramètres
Une personne, son compte et chaque rôle détenu avec la portée qui s'y applique.
Capturés en 1440 × 900 · données de démonstration
Questions fréquentes
Les questions des équipes informatiques.
Comment fonctionne l'authentification unique (SSO) ?
Via OpenID Connect. Chaque client définit son propre fournisseur d'identité ; les utilisateurs sont créés à la première connexion et les rôles sont mis en correspondance. SAML se connecte via la fédération Keycloak.
Comment est-il déployé et où fonctionne-t-il ?
Sur conteneurs et Kubernetes. Dans le cloud, avec l'option d'un environnement qui vous est dédié : espace de noms Kubernetes, base de données, courtier de messages et stockage propres. Une installation sur vos propres serveurs est possible sur demande, dans le cadre d'un projet ; il n'existe pas aujourd'hui d'installateur hors ligne packagé.
Comment les données d'un client sont-elles séparées de celles d'un autre ?
Au niveau de la base de données, par des politiques de sécurité au niveau des lignes. Le client actif est fixé au début de chaque transaction ; sans ce contexte, les tables ne renvoient aucune ligne. Si une table n'a pas sa politique, la plateforme refuse de démarrer.
Comment utiliser l'API ?
C'est la même API que celle utilisée par l'interface du produit, documentée en OpenAPI. Les clés d'accès machine sont créées dans le produit, limitées par périmètre et par liste d'adresses IP autorisées, et révocables individuellement.
Comment récupérer nos données ?
Les listes et les rapports sont exportables, et toutes les données peuvent être lues via l'API. Il n'existe pas aujourd'hui d'outil d'export global en un clic ; notre équipe accompagne le transfert de vos données si vous partez.
Les terminaux portables fonctionnent-ils hors ligne ?
Oui. L'application Android conserve les tâches et les opérations en attente sur l'appareil et les envoie dans l'ordre au retour de la connexion. Les terminaux Zebra, Honeywell et Datalogic sont pris en charge, ainsi que la caméra et les lecteurs Bluetooth. L'application web ne fonctionne pas hors ligne.
Discutez de vos questions avec nos ingénieurs.
Demander un échange technique